chore(grunt): reduce JVM heap size hint on win #4831
Conversation
The current grunt scripts require at least 2GB of heap space to be allocated by the JVM, even though this is not needed to actually complete the build. Adding 64-bit to the mix, this means grunt package fails on machines without a whole 4GB of RAM free. Closes angular#4595
|
This was originally added because Travis kept falling over on builds. -Xmx (rather than -Xms) is "maximum" heap space not "initial". See http://docs.oracle.com/cd/E22289_01/html/821-1274/configuring-the-default-jvm-and-java-arguments.html. So this should not cause java to allocate 2Gb. That being said, the way different java compilers treat such flags is a bit unspecified. Before we can change this we need to ascertain exactly what is the minimum required. Is 512Mb enough? I have a feeling it may not always be. |
|
As the Issue I submitted states, I had to do this in order to get Angular to build successfully on my machine. Which is running Windows 7 64-bit with 16GB of RAM. It might be that I only have the 32bit version of the JVM installed locally... I'm not really a JVM memory allocation expert. Perhaps we need some sort of conditional check in the build scripts to switch that flag out under certain circumstances? |
|
To be clear... it wasn't a memory shortage that was causing the failure I was seeing... it was the JVM failing to even initialize. |
|
Same as @Blesh here: the JVM wouldn't initialize on my machine even with 3.9GB of free RAM. I'm using the 32-bit JVM, however it should support settings up to 4GB based on the Oracle doco. |
petebacondarwin
force-pushed
the
master
branch
from
02dc2aa to
fd2d6c0
Compare
jeffbcross
force-pushed
the
master
branch
2 times, most recently
from
cad9560 to
f294244
Compare
jeffbcross
force-pushed
the
master
branch
4 times, most recently
from
e8dc429 to
e83fab9
Compare
petebacondarwin
force-pushed
the
master
branch
from
4dd5a20 to
998c61c
Compare
|
@Blesh - is this still a problem for you? |
|
@petebacondarwin No, I have a mac now. ;) Haha. The referenced PR should be enough of a workaround for anyone else that runs into this I would think. |
|
I'd actually like to see if we can work with the smaller max size. I've seen this on two different Windows machines, one aborts during minify, ther other flat out refuses to start; reducing to 1024m makes it work. |
|
For what it's worth, I'm reproducing this issue as well. Changing java args to -Xmx1g instead of -Xmx2g served as a workaround. |
|
this is probably safe to land --- although if I had my way we'd just get rid of closure entirely. @Bit-Rot what do you think, is 1g a safer bet than 512m? |
|
1G seems like a more conservative adjustment from 2G, and safer in that regard. I'm not, however, well informed on closure's memory requirements; I'm just just shooting in the dark here. |
|
Let's go with 1G for now and see how it runs. |
The current grunt scripts set the maximum JVM heap space to 2GB. While this is only a maximum, and not an initial, it is preventing the JVM from even initializing on a number of people's machines. The build still runs successfully for me locally using only 512MB for this setting. See issue #4595 for reported instances.
Closes #4595