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

Jon Masamitsu jon.masamitsu at oracle.com
Fri Mar 25 16:28:58 UTC 2016

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 <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.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 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/20160325/c44157ba/attachment.htm>

More information about the hotspot-gc-dev mailing list