Regarding OOME, it's expected in this situation.
If you look at the end of the log, you'll see a set of consecutive Full
GCs. It means Java heap is almost full and reached it's maximum size.
And application is almost halted - VM collects the whole heap over and
over again (>98% of application running time is spent during
stop-the-world GC).
So, VM decides to preventively throw OOME to avoid further heap thrashing.
As Marcus already noted, it's caused by increase in dynamic footprint
due to JSR292 switch to LambdaForms in 7u40.
The workaround is to increase maximum heap size.
Best regards,
Vladimir Ivanov
On 1/8/14 11:12 AM, Tal Liron wrote:
It happened again, and here's the gc.log: http://pastebin.com/DFA7CYC1
Interestingly enough, the application kept working, though I was getting
intermittent 100% CPU use.
On 01/06/2014 01:57 PM, Benjamin Sieffert wrote:
Hi everyone,
we have been observing similar symptoms from 7u40 onwards (using
nashorn-backport with j7 -- j8 has the same problems as 7u40 and 7u45...
7u25 is the last version that works fine) and suspect the cause to be the
JSR-292 changes that took place there. Iirc I already asked over on their
mailing list. Here's the link:
http://mail.openjdk.java.net/pipermail/mlvm-dev/2013-December/005586.html
The fault might as well lie with nashorn, though. It's certainly worth
investigating.
Regards
2014/1/4 Tal Liron <tal.li...@threecrickets.com>
Thanks! I didn't know of these. I'm not sure how to read the log, but
this
doesn't look so good. I get a lot of "allocation failures" that look
like
this:
Java HotSpot(TM) 64-Bit Server VM (25.0-b63) for linux-amd64 JRE
(1.8.0-ea-b121), built on Dec 19 2013 17:29:18 by "java_re" with gcc
4.3.0
20080428 (Red Hat 4.3.0-8)
Memory: 4k page, physical 2039276k(849688k free), swap 262140k(256280k
free)
CommandLine flags: -XX:InitialHeapSize=32628416
-XX:MaxHeapSize=522054656
-XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps
-XX:+PrintTenuringDistribution -XX:+UseCompressedClassPointers
-XX:+UseCompressedOops -XX:+UseParallelGC
0.108: [GC (Allocation Failure)
Desired survivor size 524288 bytes, new threshold 7 (max 15)
[PSYoungGen: 512K->496K(1024K)] 512K->496K(32256K), 0.0013194 secs]
[Times: user=0.01 sys=0.00, real=0.00 secs]
On 01/04/2014 10:02 PM, Ben Evans wrote:
-Xloggc:<pathtofile> -XX:+PrintGCDetails -XX:+PrintTenuringDistribution
