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


More information about the hotspot-gc-dev mailing list