methoddata grows in metaspace jdk 1.8.0_40 64bit
Jon Masamitsu
jon.masamitsu at oracle.com
Tue Mar 29 21:07:05 UTC 2016
On 3/29/2016 2:00 PM, Dillip Pattnaik wrote:
> so does it mean that there may be a different bug which could cause this?
Yes, that is likely.
Jon
>
> On Tue, Mar 29, 2016 at 1:02 PM, Jon Masamitsu
> <jon.masamitsu at oracle.com <mailto: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 <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/fe806519/attachment.htm>
More information about the hotspot-gc-dev
mailing list