I agree that if the user repeatedly does deploy-undeploy and is running with class unloading disabled,<br>it would be good if he were to run out of native memory and realized his mistake :-) and turned on class unloading.<br>
<br>As regards yr policy suggestion of forcing a perm gen collection every so many cycles, i believe that is possible to do<br>so in a concurrent cycle rather than doing a stop-world collection for that purpose  --<br>there was talk at one time of making the cms class unloading flag a "manageable" flag (so it could be turned on or off<br>
on-the-fly) -- there's probably even a bug about adaptively collecting the perm gen with CMS.<br> If it was found that the cost of class unloading at each major CMS cycle was too expensive, one could,<br>as you suggest, do it ever so often.<br>
<br>How about a quick survey on the "-dev" and "-use" lists to see how many users who use CMS explicitly switch on class<br>unloading vs not?<br><br>In any case, as regards Jon's question, I would say that the changes should go back in woithout waiting for a decision<br>
on MaxMetaSpaceSize or CMSClassUnloadingEnabled. If they run out of native space they will probably quickly figure out what<br>happened (i am assuming the GC logs that inform one about one's usage of metadata space would clue one in fairly soon if one<br>
discovered how much space that was taking... I am assuming +PrintHeapAtGC would produce some information, even if<br>+PrintGCDetails didn't re metatdataspace use?).<br><br>my $0.02.<br>-- ramki<br><br><div class="gmail_quote">
On Thu, Sep 27, 2012 at 12:27 AM, Mikael Gerdin <span dir="ltr"><<a href="mailto:mikael.gerdin@oracle.com" target="_blank">mikael.gerdin@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Jon,<div class="im"><br>
<br>
On 2012-09-26 18:44, Jon Masamitsu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Mikael,<br>
<br>
Do you want a default value (less than max uint) for MaxMetaspaceSize<br>
before<br>
this change goes back?<br>
</blockquote>
<br></div>
While I see a value in setting some sort of "sensible" value for MaxMetaspaceSize this is not really the exact issue I was worried about.<br>
<br>
Consider this scenario:<br>
<br>
* Person runs a Java app server/container with +UseConcMarkSweepGC (but without +CMSClassUnloadingEnabled).<br>
* Some app is repeatedly deployed and un-deployed from the instance, every time an app is un-deployed its class loader and classes are made unreachable.<br>
<br>
In this case CMS would not opt to unload classes until MaxMetaspaceSize is hit or the process/system runs out of memory.<br>
<br>
Maybe there could be some sort of threshold for when to trigger a full collection (which includes class unloading) without that threshold value being a limit on the amount of memory available for meta data?<br>
<br>
I know this is a complicated policy issue, and I agree that it would be good if we could enable +CMSClassUnloadingEnabled and get rid of the issue altogether. The question is whether or not performance testing resources are available to evaluate that.<span class="HOEnZb"><font color="#888888"><br>

<br>
/Mikael</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Jon<br>
<br>
On 9/25/2012 11:09 AM, Mikael Gerdin wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2012-09-25 18:23, Jon Masamitsu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Mikael,<br>
<br>
Thanks for the review.<br>
<br>
The expand_and_allocate() does not do a GC.  It expands<br>
the Metaspace and does an allocation from the expanded<br>
space.  Only if that fails does the CMS case fall through to<br>
the full GC.<br>
</blockquote>
<br>
Yes.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The policy for CMS is<br>
<br>
1) Hitting the HWM should start a concurrent collection if<br>
CMS is doing class unloading.<br>
2) Always  expand the Metaspace and allocate from<br>
the expanded space.<br>
3) If expanding the Metaspace does not provide any free<br>
space, do a full GC to reclaim classloaders and class metadata<br>
and then retry the allocation.<br>
</blockquote>
<br>
But at what point does expanding the Metaspace not provide any free<br>
space? Is there some sort of back-off so that we don't just go ahead<br>
and allocate all available memory and then try to do a full gc when<br>
we've filled up the address space?<br>
I'm kind of concerned about the case with CMS without<br>
CMSClassUnloadingEnabled. What I'm mainly worried about is slow leaks<br>
and cases where an application loads a bunch of classes and then<br>
releases the java level references to them but does not unload them<br>
since we don't get to the expand_and_allocate returning null.<br>
<br>
/Mikael<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Jon<br>
<br>
<br>
On 09/25/12 07:23, Mikael Gerdin wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Jon,<br>
<br>
On 2012-09-24 23:46, Jon Masamitsu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
NPG: VM Does not unload classes with UseConcMarkSweepGC<br>
<br>
If CMS is not doing class unloading, don't start a concurrent<br>
collection for classloader (and metadata) collection (since<br>
it won't happen without class unloading).<br>
</blockquote>
<br>
It looks like you still unconditionally call expand_and_allocate when<br>
running with CMS, no matter the value of CMSClassUnloadingEnabled.<br>
I think that the code:<br>
<br>
 213       // For CMS expand since the collection is going to be<br>
concurrent.<br>
 214       _result =<br>
 215 _loader_data->metaspace_non_<u></u>null()->expand_and_allocate(_<u></u>size,<br>
_mdtype);<br>
<br>
Should be inside the "if (CMSClassUnloadingEnabled)" and if running<br>
without it set then CMS users will have to take the hit of a stw full<br>
gc when running into the metadata threshold.<br>
<br>
/Mikael<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<a href="http://cr.openjdk.java.net/%7Ejmasa/7198873/webrev.00/" target="_blank">http://cr.openjdk.java.net/~<u></u>jmasa/7198873/webrev.00/</a><br>
<br>
Also, refactored the code for readability and guarded extra<br>
output with Verbose.<br>
<br>
Thanks.<br>
<br>
Jon<br>
</blockquote>
<br>
</blockquote></blockquote>
<br>
</blockquote></blockquote>
<br></div></div><div class="HOEnZb"><div class="h5">
-- <br>
Mikael Gerdin<br>
Java SE VM SQE Stockholm<br>
</div></div></blockquote></div><br>