methoddata grows in metaspace jdk 1.8.0_40 64bit

[Jon Masamitsu]

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