We can safely disable function node snapshots (which are going away anyway) since lazy code generation will be done differently in 8u20, is the only thing that uses this and is not enabled or supported. Should be fairly simple and low risk to do.
Tal - is there a way to set up your reproduction environment locally - sounds like a good Nashorn torture test to me. /M On 21 Jan 2014, at 11:22, A. Sundararajan <sundararajan.athijegannat...@oracle.com> wrote: > I looked at the heap dump - in particular Nashorn objects in it. Lots of > codegen Label /Frame retained from RecompilableScriptFunctionData. Didn't > find any specific leak as such - but lots of stuff is retained for > recompilation. We'll check if we can avoid that. > > -Sundar > > On Monday 20 January 2014 06:53 PM, A. Sundararajan wrote: >> Hi, >> >> Haven't had chance yet to look at the zip. But, I plan to look at it before >> EOD. >> >> -Sundar >> >> On Saturday 18 January 2014 12:21 PM, Tal Liron wrote: >>> I have a new dump that will hopefully be more useful: >>> >>> https://dl.dropboxusercontent.com/u/122806/jvm8_gc2.zip >>> >>> From what I can tell, indeed lambda forms are way out of control here. >>> Generally, too, there is a huge amount of Nashorn-related instances, which >>> may be related. >>> >>> (Note that Log4j 2.0 also seems to be having a serious memory leak! I have >>> opened a bug about it over there.) >>> >>> 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 >>>> >>> >> >
