BUILD: Exception in thread "main" java.lang.OutOfMemoryError: Java heap space

I need your help...

When I try to Run my Configuration in Eclipse, I get:

BUILD: Exception in thread "main" java.lang.OutOfMemoryError: Java heap space

Any help...

Thanks
  • Former Member
    Former Member over 7 years ago
    I haven't seen that error before, but I haven't seen the run configurations take up an unreasonable amount of memory on my system either. Is there any chance you have an anti-virus installed that limits the heap size available to java programs? If that is not the case, you could try setting an arbitrarily large default heap size for the JRE on your system. That isn't a fix to the issue, but it might be a sufficient work around until the actual root cause is discovered.

    Also, it might help in the process of creating a bug report to include the versions of your java install, eclipse install, ciq plugin, ciq sdk, and OS, if you are willing.
  • I already have in my eclipse.ini:

    --launcher.appendVmargs
    -vmargs
    -Dosgi.requiredJavaVersion=1.8
    -XX:+UseG1GC
    -XX:+UseStringDeduplication
    -XX:MaxPermSize=1024m
    -Dosgi.requiredJavaVersion=1.8
    -Xms512m
    -Xmx2048m
  • o My Environment:
    Windows 10 64bit
    Eclipse Neon.2 (4.6.3)
    ConnectIQ 2.4.1
    java 1.8.0_131
  • Former Member
    Former Member over 7 years ago
    Hey prenard59115,

    I'm trying to reproduce this and I'm not able to find a place to download Eclipse Neon.2 (4.6.3). All I'm finding is Neon.3 (final release before the switch to Oxygen). Have you tried upgrading to Eclipse Oxygen? I'm really not sure why you are getting a Java out of memory error. If you are using run configurations, have you tried recreating it? Have you tried doing a "Right click > Run As > Connect IQ App" run of your project? Do you get the same results?

    Thanks,
    -Coleman
  • I am getting the same error:"Exception in thread "main" java.lang.OutOfMemoryError: Java heap space"

    Mac Monterey, VSCode Version: 1.65.2, watch app, SDK 4.0.9

    I have narrowed the cause to the size of my drawables resources. The app compiles fine for devices requiring smaller images, but fails when I scale them up to display nicely on higher-res screens. It's OK with 280x280, but fails when I build for a Venu2 at at 416x416

    There is lots of advice on code forums, suggesting changing the Java configuration, but they all assume Java configuration knowledge, which I don't have.

    I suspect I'll have to add  "-Xmx2g" to increase the maximum memory in the JVM launch:

    "java '-Xms1g', '-Dfile.encoding=UTF-8', '-Dapple.awt.UIElement=true', '-jar', '/Users/alansmith/Library/Application Support/Garmin/ConnectIQ/Sdks/connectiq-sdk-mac-4.0.9-2022-01-24-2154651d3/bin/monkeybrains.jar', '-o', 'bin/raceQs.prg', '-f', '/Users/alansmith/Documents/watchApp/raceQs/monkey.jungle', '-y', '/Users/alansmith/developer_key.W10', '-w', '-d', 'venu2_sim'"

    but I haven't worked out where that should go.

    [EDIT]

    I have found and added -Xmx2g to the "monkeyc"  script:

    #!/bin/bash
    
    MB_HOME="$( cd "$( dirname "$0" )" && pwd )"
    java -Xms1g -Xmx2g -Dfile.encoding=UTF-8 -Dapple.awt.UIElement=true -classpath "$MB_HOME"/monkeybrains.jar com.garmin.monkeybrains.Monkeybrains "$@"
    

    in my SDK/bin folder: (/Users/alansmith/Library/Application Support/Garmin/ConnectIQ/Sdks/connectiq-sdk-mac-4.0.9-2022-01-24-2154651d3/bin)

    But it's not being read by the Build process. It must be getting cached somewhere.

    (I think I have confirmed some caching by renaming monkeyc to Xmonkeyc and it still builds with the cached version!)

    [EDIT 2]

    Successful compilation from the command line with Xmx4g:

     java -Xms1g -Xms4g -Dfile.encoding=UTF-8 -Dapple.awt.UIElement=true -jar '/Users/alansmith/Library/Application Support/Garmin/ConnectIQ/Sdks/connectiq-sdk-mac-4.0.9-2022-01-24-2154651d3/bin/monkeybrains.jar' -o bin/raceQs.prg -f /Users/alansmith/Documents/watchApp/raceQs/monkey.jungle -y /Users/alansmith/developer_key.W10 -w -d venu2_sim
    And running in the simulator with

     monkeydo raceQs.prg venu2

    And it runs:

     

    But the Simulator is smudging the letters - that are 100% clear in the bitmap .png. I don't have a venu2 so can't verify on a physical device.

    So the problem was overcome by increasing the heap memory.

    HOWEVER....

     I still haven't found how to apply the Xmx4g in the SDK to be able to build from VSCode. Any assistance will be much appreciated.

  • Not to state the obvious, but the VS Code Monkey C extension doesn't seem to use the monkeyc script at all. I'm guessing the same is true for the Eclipse plugin.

    You can set global java options using the _JAVA_OPTIONS environment variable:

    • Windows
      Win key (search) > Edit the system environment variables > Environment Variables > User variables for ... > New:
      Variable name: _JAVA_OPTIONS
      Variable value: -Xms4g
    • Mac
      Add the following line to ~/.zshrc:
      export _JAVA_OPTIONS=-Xms4g
      EDIT: This won't work unless your default shell is zsh and you always launch VS Code from the command line (which most people won't). See alternate solution here: forums.garmin.com/.../1391717

    If it worked properly, you should see the following output in the VS Code or Eclipse terminal when you build a CIQ app:

    Picked up _JAVA_OPTIONS: -Xmx4g

  • Not to state the obvious, but the VS Code Monkey C extension doesn't seem to use the monkeyc script at all.

    Ah, so that's why it appeared to be cached!

    I'm sure you're on top of this, and many thanks for your advice.

    I was unable to find ~/.zshrc. 

    I did find one in /Applications/Android Studio.app/Contents/plugins/terminal/.zshrc where I made your recommended change:

    (unable to post the code... Access Blocked!)

    And, I changed my default shell to zsh 

    But no change in VSCode build (after a full restart):

    Executing task: java -Xms1g -Dfile.encoding=UTF-8 -Dapple.awt.UIElement=true -jar /Users/alansmith/Library/Application Support/Garmin/ConnectIQ/Sdks/connectiq-sdk-mac-4.0.9-2022-01-24-2154651d3/bin/monkeybrains.jar -o bin/raceQs.prg -f /Users/alansmith/Documents/watchApp/raceQs/monkey.jungle -y /Users/alansmith/developer_key.W10 -w -d venu2_sim <

    So it's not quite working yet. My Unix skills are only moderate, so any further assistance will be most welcome.

    P.S. I wonder where the command line comes from if not from the monkeyc script?

  • I did find one in /Applications/Android Studio.app/Contents/plugins/terminal/.zshrc where I made your recommended change:

    That wouldn't work, but .zshrc is the wrong place anyway (sorry, bad advice), since it won't apply to apps which aren't started from Terminal.

    Try this instead:

    https://stackoverflow.com/a/14339426

    [https://github.com/hschmidt/EnvPane]

    I haven't tried it myself, so if it doesn't work, please try one of the other answers to the linked stackoverflow question.

    P.S. I wonder where the command line comes from if not from the monkeyc script?

    I suppose the logic for generating the command line is hardcoded in the VS Code extension or Eclipse plugin.

  • This all looked very complicated,  time-consuming and high-risk, but I realised at 03:30 that my problem might be resolved by using some further tricks to reduce the size of my bitmaps. After all they are only B&W or, actually black, dark grey, light grey and white!
    And it paid off.

    I generated palleted images in PHP with just 4 colours which reduced the size of the png's from 10K to 2Kb and then used some of the bitmap attributes as well:

    <bitmap id="compass01" filename="compass01.png" compress="true">

    <palette disableTransparency="true">

    <color>000000</color>

    <color>555555</color>

    <color>aaaaaa</color>

    <color>ffffff</color>

    </palette>

    </bitmap>

    Now it compiles successfully, very fast and the resultant .prg is down from 4Mb to 300Kb!

    But on a positive note, I have gained a bit better understanding about the inner workings of MacOS and the Garmin SDK plugin to VSC as well.

    I must say I'm a bit mystified about why Garmin is using Java in this process. I guess it's about cross-platform compatibility.

    Thanks for your assistance.