GC overhead limit exceeded

[Tal Liron]

Just run the Prudence example applications. There's the default
example that comes with the distribution, but it's not data-driven.
You can try the MongoVision application to test a MongoDB backend. Or
the Stickstick demo to test relational databases (comes with H2 built
in, but can be easily modified to run against MySQL).

On Tue, Jan 21, 2014 at 8:46 PM, Marcus Lagergren
<marcus.lagergren at oracle.com> wrote:
> 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.athijegannathan at 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
>>>>>
>>>>
>>>
>>
>