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.lagerg...@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.sieff...@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.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 >>>> >>> >>> >> >> >> -- >> 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. >
