methoddata grows in metaspace jdk 1.8.0_40 64bit (original) (raw)

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.066) 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.066" Java(TM) SE Runtime Environment (build 1.8.066-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.040 64 bit recently, the metaspace keeps growing. After using gc classstat 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/20160330/1658dce3/attachment.htm>

More information about the hotspot-gc-dev mailing list