Fwd: GC overhead limit exceeded
tal.liron at threecrickets.com
Thu Mar 6 05:23:19 PST 2014
Have you looked at the dump I linked to before?
Of course it could be a memory leak in my code, but by far the largest
amount of instances are held by lambda forms. It could be that they take
very little memory, so it might not be important. However, I understood
that this is actually a known issue in JVM 7, too. But I don't know
enough about how Nashorn uses it to comment.
On 03/06/2014 09:17 PM, Hannes Wallnoefer wrote:
> 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?
> 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
>>> 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