Fwd: GC overhead limit exceeded

[Hannes Wallnoefer]

Hi Tal,

I'm sorry this problem still persists.

Back when I tried your app I threw a lot of apache bench requests at it 
but didn't see a leak. Looking at your dump again I notice that while 
there are a lot of LambdaForm related instances they don't occupy a 
large part of the heap.

The biggest part of the heap (over 40 %) is used for character arrays, 
mostly from Strings. A lot of them are GC-rooted in TimerThread or 
ThreadLocal instances. I don't understand the application well enough to 
know whether that is the root of the problem. Could it be that you're 
retaining some reference in some recurring/scheduler tasks you're running?

Hannes

Am 2014-03-06 07:28, schrieb Tal Liron:
> Well, I've reached the limits of my personal knowledge to work on this 
> problem. I'm happy to assist in any way I can, including providing 
> access to servers.
>
> As it stands, however, it seems that this problem will follow through 
> into the official release of OpenJDK 8, which means that I won't be 
> able to recommend Nashorn for production deployments of Prudence. 
> Perhaps there will be a fix later on?
>
> (By the way, there is no bug with Log4j 2.0 -- the high number of 
> instances is by design, an effect of using the innovative Disruptor 
> library for inter-thread communication.)
>
> On 02/25/2014 02:12 AM, Tal Liron wrote:
>> I've been away for a month. Has anyone with knowhow followed up on this?
>>
>> The issue is still present.
>>
>> On 01/18/2014 02:51 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.)
>