Tal - The GC people 10 meters behind me want to know if you have a repro of your full GC to death problem that they can look at? They’re interested.
/M On 09 Jan 2014, at 16:29, Kirk Pepperdine <k...@kodewerk.com> wrote: > 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. >> >
