GC overhead limit exceeded

[Kirk Pepperdine]

Hi Marcus,

Looks like some of the details have been chopped off. Is there a GC log available? If there is a problem with MethodHandle a work around might be a simple as expanding perm.. but wait, this is meta space now and it should grow as long as your system has memory to give to the process. The only thing I can suggest is that the space to hold compressed class pointers is a fixed size and that if Nashorn is loading a lot of classes is that you consider making that space larger. Full disclosure, this isn’t something that I’ve had a chance to dabble with but I think there is a flag to control the size of that space. Maybe Colleen can offer better insight.

Regards,
Kirk

On Jan 9, 2014, at 10:02 AM, Marcus Lagergren <marcus.lagergren at oracle.com> wrote:

> This almost certainly stems from the implementation from MethodHandle combinators being implemented as lambda forms as anonymous java classes. One of the things that is being done for  8u20 is to drastically reduce the number of lambda forms created.  I don’t know of any workaround at the moment. CC:ing hotspot-compiler-dev, so the people there can elaborate a bit.
> 
> /M
> 
> On 06 Jan 2014, at 06:57, Benjamin Sieffert <benjamin.sieffert at metrigo.de> 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
>>>> 
>>> 
>>> 
>> 
>> 
>> -- 
>> Benjamin Sieffert
>> metrigo GmbH
>> Sternstr. 106
>> 20357 Hamburg
>> 
>> Geschäftsführer: Christian Müller, Tobias Schlottke, Philipp Westermeyer
>> Die Gesellschaft ist eingetragen beim Registergericht Hamburg
>> Nr. HRB 120447.
>