After switching to B4A 10.70, my 'larger project' reproduced some Dexer error conditions. I collected them here (perhaps to help other readers) along with a few questions.
Does installing a newer B4A release reset the MaxRamForDex back to 1024? I thought I had increased it some time ago due to dexer issues, but found it at 1024 after seeing the problems below.
First indication, was the optimized dex seemed like it would hang and then would timeout at 60s. Tried changing to Debug mode, and also tried Legacy Debugger (which prob didn't matter), to alter the situation. More time didn't seem like the right solution to make progress as it normally doesn't take even half that time.
I increased the timeout to 120s, then the dex would stop with [a very long message including] the unexpected top-level error and memory shortage. I don't recall increasing this timeout ever, but I may not recall. When recreating the failure, 120s wasn't always long enough (with the MaxRam at 1024 still) to get the longer message and memory shortage information, even 180s wasn't, unless I switched to the debugger (from Release).
Then I found the MaxRamForDex was down at 1024. Bumped up to 4096. I'm sure it was at 2048 or higher last time dexing issues came up.
After bumping that then the dexer would switch after 20-some seconds to the standard dexer and complete. Left the timeout at 180s for a best chance of the informative errors.
I'm guessing there is a good reason to keep the default maxRam at 1024?
Since all I changed at first was the timeout from 60s to 120s to make resolution progress, could a longer default value help users get to a solution quicker (the top-level / out of memory error was more informative) ?
- Except it appears that was long enough only for Debugger mode, not Release mode.
Could the IDE, upon a dexing failure due to memory or perhaps timeout, auto-retry with an increased MaxRam and prompt the user to make the change permanent?
Does installing a newer B4A release reset the MaxRamForDex back to 1024? I thought I had increased it some time ago due to dexer issues, but found it at 1024 after seeing the problems below.
First indication, was the optimized dex seemed like it would hang and then would timeout at 60s. Tried changing to Debug mode, and also tried Legacy Debugger (which prob didn't matter), to alter the situation. More time didn't seem like the right solution to make progress as it normally doesn't take even half that time.
error was: [
Convert byte code - optimized dex.
Error Process timed out.
You can change it under Tools - IDE Options. ]
Convert byte code - optimized dex.
Error Process timed out.
You can change it under Tools - IDE Options. ]
I increased the timeout to 120s, then the dex would stop with [a very long message including] the unexpected top-level error and memory shortage. I don't recall increasing this timeout ever, but I may not recall. When recreating the failure, 120s wasn't always long enough (with the MaxRam at 1024 still) to get the longer message and memory shortage information, even 180s wasn't, unless I switched to the debugger (from Release).
error given at end of long content (warnings): [
UNEXPECTED TOP-LEVEL ERROR:
java.lang.OutOfMemoryError: GC overhead limit exceeded ]
UNEXPECTED TOP-LEVEL ERROR:
java.lang.OutOfMemoryError: GC overhead limit exceeded ]
Then I found the MaxRamForDex was down at 1024. Bumped up to 4096. I'm sure it was at 2048 or higher last time dexing issues came up.
After bumping that then the dexer would switch after 20-some seconds to the standard dexer and complete. Left the timeout at 180s for a best chance of the informative errors.
I'm guessing there is a good reason to keep the default maxRam at 1024?
Since all I changed at first was the timeout from 60s to 120s to make resolution progress, could a longer default value help users get to a solution quicker (the top-level / out of memory error was more informative) ?
- Except it appears that was long enough only for Debugger mode, not Release mode.
Could the IDE, upon a dexing failure due to memory or perhaps timeout, auto-retry with an increased MaxRam and prompt the user to make the change permanent?
