Fwd: GC overhead limit exceeded
Vladimir Ivanov
vladimir.x.ivanov at oracle.com
Thu Jan 9 01:48:46 PST 2014
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.liron at 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
>>>>
>>>
>>
>
More information about the nashorn-dev
mailing list