<div dir="ltr">so does it mean that there may be a different bug which could cause this?<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 29, 2016 at 1:02 PM, Jon Masamitsu <span dir="ltr"><<a href="mailto:jon.masamitsu@oracle.com" target="_blank">jon.masamitsu@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<br>
<br>
<div>On 3/29/2016 2:08 AM, Thomas Stüfe
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi Jon,<br>
<br>
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.<br>
</div>
</blockquote>
<br></span>
Yes, you're right that it is a C-heap leak and does not apply to
this<br>
situation.<span class="HOEnZb"><font color="#888888"><br>
<br>
Jon</font></span><div><div class="h5"><br>
<br>
<blockquote type="cite">
<div dir="ltr"><br>
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.<br>
<br>
Thank you,<br>
<br>
Thomas<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Mar 25, 2016 at 5:28 PM, Jon
Masamitsu <span dir="ltr"><<a href="mailto:jon.masamitsu@oracle.com" target="_blank">jon.masamitsu@oracle.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> <br>
<br>
<div>On 3/24/16 4:07 PM, Dillip Pattnaik wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>hi Jon,<br>
</div>
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.<br>
<br>
java version "1.8.0_66"<br>
Java(TM) SE Runtime Environment (build
1.8.0_66-b17)<br>
Java HotSpot(TM) 64-Bit Server VM (build
25.66-b17, mixed mode)<br>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
You might be seeing<br>
<br>
<a href="https://bugs.openjdk.java.net/browse/JDK-8144581" target="_blank">https://bugs.openjdk.java.net/browse/JDK-8144581</a><br>
<br>
which isn't fixed 8u66. I don't know if it is in a
released <br>
version of an 8 update but it is fixed in jdk9 and is
available<br>
in an early availability build b93.<br>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div><br>
</div>
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?<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
I'm not familiar with the particulars of the contents of
MethodData<br>
other than it contains information that the JIT's and the
interpreter<br>
maintains about methods. I don't think it has pointers
to arguments<br>
but probably has information about what the arguments are.<br>
<br>
MethodData is not a Java object (i.e., it is not in the
Java heap) so<br>
it is not garbage collected per se. MethodData is
associated with<br>
a Java class and a Java class is associated with a class
loader. A<br>
class loader is a Java object so the class loader get
garbage<br>
collected. When the class loader is garbage collected, it<br>
means that all the classes loaded by the classes loader<br>
(and all associated data) are unloaded. <br>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div><br>
</div>
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?<br>
</div>
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?<br>
</div>
</div>
</div>
</blockquote>
It's obviously difficult to reason out memory leaks. I
don't have any good<br>
advice.<br>
<br>
If you can try running with -client. It uses a different
JIT and might<br>
affect MethodData usage. That would tell us something.<br>
<br>
Jon<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
Thank you <br>
</div>
Dillip<br>
<div>
<div>
<div>
<div><br>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Mar 24, 2016 at
4:32 PM, Jon Masamitsu <span dir="ltr"><<a href="mailto:jon.masamitsu@oracle.com" target="_blank"></a><a href="mailto:jon.masamitsu@oracle.com" target="_blank">jon.masamitsu@oracle.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Can you
run your test with the latest jdk8 and the
latest jdk9?<br>
<br>
And does<span><br>
<br>
<blockquote type="cite">But the MethodData
per class keeps growing in 20MBs.</blockquote>
<br>
</span> mean that the amount of MethodData
continues to grow as long as the<br>
application is running?<span><font color="#888888"><br>
<br>
Jon</font></span><span><br>
<br>
<div>On 3/23/2016 9:25 AM, Dillip Pattnaik
wrote:<br>
</div>
</span>
<blockquote type="cite"><span>
<div dir="ltr">
<div>hi,<br>
</div>
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?<br>
</div>
<br>
<fieldset></fieldset>
<br>
</span><span>
<pre>_______________________________________________
hotspot-gc-use mailing list
<a href="mailto:hotspot-gc-use@openjdk.java.net" target="_blank">hotspot-gc-use@openjdk.java.net</a>
<a href="http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use" target="_blank">http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use</a>
</pre>
</span></blockquote>
<br>
</div>
<br>
_______________________________________________<br>
hotspot-gc-use mailing list<br>
<a href="mailto:hotspot-gc-use@openjdk.java.net" target="_blank">hotspot-gc-use@openjdk.java.net</a><br>
<a href="http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use" rel="noreferrer" target="_blank">http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>