Fwd: GC overhead limit exceeded

A. Sundararajan sundararajan.athijegannathan at oracle.com
Tue Jan 21 02:22:55 PST 2014

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.


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

More information about the nashorn-dev mailing list