New version gives "Java Heap Space"-Error

[ModernPatriot]

So I just wanted to update from an older to the newest recommended version, but it fails at "DecompileMC" with the error >Java Heap Space.

I checked my .bat and gradle files and they are correct.

I already tried to alter the memory args but daemon always gave errors back.

I even created a new workspace - same error.

So how would i be able to resolve that error and how could I give JVM more ram to work with?

[ThexXTURBOXx]

So I just wanted to update from an older to the newest recommended version, but it fails at "DecompileMC" with the error >Java Heap Space.

I checked my .bat and gradle files and they are correct.

I already tried to alter the memory args but daemon always gave errors back.

I even created a new workspace - same error.

So how would i be able to resolve that error and how could I give JVM more ram to work with?

I have had the same error, too.

I fixed it like this:

1. Go to Drive:/Users/YourName/.gradle

2. Create a new file called "gradle.properties"

3. Write that in this file: org.gradle.jvmargs=-Xmx2G

4. Gradle will now fork a new JVM using Daemon. That's normal, but Gradle will now run with 2GB RAM.

 

Hope this helps you! ^^

[ModernPatriot]

I personally had to use 1gb because everything else crashed.

But now Im getting following crash:

 

http://s17.postimg.org/kl2b3nftb/Screenshot_2.png[/img]

 

Why exactly does this happen and how can I fix this?

[ModernPatriot]

I can't allocate more than 1.5 gigs because of windows memory splitting. It really sucks that you can't even disable it.

It still gives the same error once I allocate more.

Because the gradle.properties way didnt work I searched for a while and came up with a way how I could change the memory allocation through the system variable _JAVA_OPTIONS.

It changes the memory now without any error but the whole process is now stuck at decompileMc and doesnt do anything once it reaches this step.

http://s24.postimg.org/bu92eqiqt/Screenshot_1.png[/img]

[jeffryfisher]

My experience with gradle.properties was that switches were not even read until after gradle started. It would then try to spawn a separate deamon on top of itself, causing an immediate crash.

 

What worked for me was to edit gradlew.bat, where I could inject a memory ceiling before gradle ran. Find the "set DEFAULT_JVM_OPTS=" line and give it a max heap system value such as "-Xmx1440m". In other words, instead of promising more memory that you don't have, limit the amount of memory that the JVM will attempt to take.

 

And D7 is correct that execution may be slow, but slow success is better than quick failure.

 

BTW, there's a whole child board for gradle, and it has many threads on this exact issue, including my advice posted last week.

[ModernPatriot]

Thank you so much Jeffrey!

Its slow but it finally works.

 

@diesieben07 Windows memory splitting is a windows 10 software "feature" which activates once you have more or exactly 16 gigs of memory. Windows basically "splits" the ram into 16 pieces and allocates the pieces accordingly. The problem is that programs which need to access more than one gig directly (like the JVM) cant run like this. Atleast not when they think that they can take more than one gig.

You cant really disable it. The best bet, according to some Users on stackoverflow is to run your program as fast as possible once windows starts up, because it takes some time till it starts the splitting.