methoddata grows in metaspace jdk 1.8.0_40 64bit

Tue Mar 29 18:02:14 UTC 2016

On 3/29/2016 2:08 AM, Thomas Stüfe wrote:
> 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.

Yes, you're right that it is a C-heap leak and does not apply to this
situation.

Jon

>
> 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 <mailto: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 <mailto: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 list
>>>         hotspot-gc-use at openjdk.java.net
>>>         <mailto:hotspot-gc-use at openjdk.java.net>
>>>         http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>>
>>
>>         _______________________________________________
>>         hotspot-gc-use mailing list
>>         hotspot-gc-use at openjdk.java.net
>>         <mailto: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/1dca7cd3/attachment.htm>