Fwd: GC overhead limit exceeded
hannes.wallnoefer at oracle.com
Thu Mar 6 05:17:01 PST 2014
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?
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:
>>> 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.)
More information about the nashorn-dev