Posted February 11, 20169 yr While recently installing a decomp workspace for recommended build 1722, I ran into the dreaded heap failure at 56% of decomp. After following a whole bunch of bad advice that only made more errors earlier in the process, I finally hit on a solution: Prevent the JVM from asking for more memory than it can use. NB: Don't ask for a daemon, because it will claim even more memory. NB: Don't use gradle.properties, because it will cause a daemon to be spawned. The solution for older, limited machines is to edit gradlew.bat, changing the JV OPTIONS. I had less than 2000 megabytes of free (physical) RAM, so I set a max heap of 1536 MB thusly: set DEFAULT_JVM_OPTS="-Xmx1536m" Your number after the mx may vary, depending on how much free physical RAM your machine has (gradle seems to be unable to use virtual memory, so the size of your swap file is irrelevant). The key, if you're running out of heap space, is to enforce a limit so Java stays under it. setting a higher minimum (as many other forum posts advise) will only get you into more trouble sooner. PS: Setting a ceiling will make you pay in time for the memory you don't provide at start, so only go this route if the default generates a heap error. The debugger is a powerful and necessary tool in any IDE, so learn how to use it. You'll be able to tell us more and get better help here if you investigate your runtime problems in the debugger before posting.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.