methoddata grows in metaspace jdk 1.8.0_40 64bit
jon.masamitsu at oracle.com
Tue Mar 29 18:02:14 UTC 2016
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
> 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,
> 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
> 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
> If you can try running with -client. It uses a different JIT and
> affect MethodData usage. That would tell us something.
>> Thank you
>> 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?
>> On 3/23/2016 9:25 AM, Dillip Pattnaik wrote:
>>> 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>
>> hotspot-gc-use mailing list
>> hotspot-gc-use at openjdk.java.net
>> <mailto:hotspot-gc-use at openjdk.java.net>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-gc-dev