methoddata grows in metaspace jdk 1.8.0_40 64bit

Thomas Stüfe thomas.stuefe at gmail.com
Wed Mar 30 06:46:50 UTC 2016


Jon, thank you for clarifying!


On Tue, Mar 29, 2016 at 8:02 PM, Jon Masamitsu <jon.masamitsu at oracle.com>
wrote:

>
>
> 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>
> 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>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: <http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20160330/1658dce3/attachment-0001.html>


More information about the hotspot-gc-dev mailing list