methoddata grows in metaspace jdk 1.8.0_40 64bit

[Thomas Stüfe]

Hi Jon,

short question, would JDK-8058563 not result in a C-Heap leak, not a
Metaspace leak? The bug description talks about leaking nmethodBucket
instances, which are allocated on C-Heap.

I am asking because we also see Out-of-metaspace errors from time to time,
and I want to understand the symptoms JDK-8058563 would cause.

Thank you,

Thomas

On Fri, Mar 25, 2016 at 5:28 PM, Jon Masamitsu <jon.masamitsu at oracle.com>
wrote:

>
>
> On 3/24/16 4:07 PM, Dillip Pattnaik wrote:
>
> hi Jon,
> Thanks for replying. We just tried following(1.8.0_66) jdk version as
> well  but we had the similar growth in the metaspace, we also thought it
> may be due to old minor version. And we kicked off our tests yesterday
> morning.
>
> java version "1.8.0_66"
> Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)
>
>
> You might be seeing
>
> https://bugs.openjdk.java.net/browse/JDK-8144581
>
> which isn't fixed 8u66.  I don't know if it is in a released
> version of an 8 update but it is fixed in jdk9 and is available
> in an early availability build b93.
>
>
> The test that we ran was to hit the server with a predefined set of
> requests continuously. So yes, the methodData continues to grow even if the
> same request is resent to the server. What information is actually in
> MethodData? Does it have pointers to the methods' arguments that are
> currently executed? Should the methodData be ever GCed? If yes, when does
> that take place?
>
> I'm not familiar with the particulars of the contents of MethodData
> other than it contains information that the JIT's and the interpreter
> maintains about methods.  I don't think it has pointers to  arguments
> but probably has information about what the arguments are.
>
> MethodData is not a Java object (i.e., it is not in the Java heap) so
> it is not garbage collected per se.  MethodData is associated with
> a Java class and a Java class is associated with a class loader.  A
> class loader is a Java object so the class loader get garbage
> collected.  When the class loader is garbage collected, it
> means that all the classes loaded by the classes loader
> (and all associated data) are unloaded.
>
>
> The methodData does grow slowly over the time, sometimes suddenly in size
> of 20-30 MB.  When we stopped the request to the server and took a snapshot
> of the memory , the GC cleaned up the space in heap (both young and old
> gen), but the MetaSpace memory did not come down. Any advice pleae?
> We ran the same application code and tests in jdk 7 and the perm gen
> growth was not that steep. Also we have metaspace assigned around 3.5GB.
> And almost 300K classes get loaded into memory as part of the application.
> So the metaspace starts some where around 2.7GB and eventually it runs out
> of 3.5GB after running the test for 1.5 days. Is there a way to debug it
> more to find out what is exactly being held up in the MethodData area of
> theses loaded classes?
>
> It's obviously difficult to reason out memory leaks.  I don't have any good
> advice.
>
> If you can try running with -client.  It uses a different JIT and might
> affect MethodData usage. That would tell us something.
>
> Jon
>
>
> Thank you
> Dillip
>
>
> On Thu, Mar 24, 2016 at 4:32 PM, Jon Masamitsu <jon.masamitsu at oracle.com>
> wrote:
>
>> Can you run your test with the latest jdk8 and the latest jdk9?
>>
>> And does
>>
>> But the MethodData per class keeps growing in 20MBs.
>>
>>
>> mean that the amount of MethodData continues to grow as long as the
>> application is running?
>>
>> Jon
>>
>> On 3/23/2016 9:25 AM, Dillip Pattnaik wrote:
>>
>> hi,
>> We were running an application in java 7 with lot of reflection and
>> custom class loader. The perm gen normally reaches a high threshold and
>> stabilizes. But once we moved to 1.8.0_40 64 bit recently, the metaspace
>> keeps growing. After using gc class_stat we found that the number of
>> classes loaded are constant. But the MethodData per class keeps growing in
>> 20MBs. Could you please advise why the method data is growing and if there
>> is a way to debug it more and find out what is causing it?
>>
>>
>> _______________________________________________
>> hotspot-gc-use mailing listhotspot-gc-use at openjdk.java.nethttp://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>>
>>
>>
>> _______________________________________________
>> hotspot-gc-use mailing list
>> hotspot-gc-use at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20160329/4321d127/attachment.htm>