<div dir="ltr"><div><div><div><div><div>Thomas, my recollection is from a while back and I haven't looked at the code recently, but<br></div>CMS does increase perm size as the heap fills up. However, as you may be<br></div>
implying, the heap size increase is not tied to the CMS perm trigger setting.<br></div>Thus, it's possible that the occupancy of the perm gen is such that it exceeds<br></div>the perm trigger ratio, but is not sufficiently large that the perm gen will be increased<br>
in size.<br><br></div><div>As to Kirk's original question, well, it seems strange that the Perm trigger ratio is being used<br></div><div>as a CMS trigger when CMS class unloading is disabled. I thought that the CMS initiating<br>
</div><div>trigger was tied to the occupancy of the perm only when class unloading was enabled,<br></div><div>and was otherwise only affected by the occupancy of the old generation. You can enable<br>a flag that makes CMS more talkative about why it's starting a CMS collection and that<br>
might provide a clue. Perhaps there's a bug in the trigger.<br></div><div><br></div>-- ramki<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Oct 2, 2013 at 12:12 AM, Thomas Viessmann <span dir="ltr"><<a href="mailto:thomas.viessmann@oracle.com" target="_blank">thomas.viessmann@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">
Hi Kirk,<br>
<br>
Disclaimer: I'm in support and all I can share is my experience:<br>
<br>
You always need a full GC if heap resizing is needed.<br>
CMS AFAIHS cannot initiate an increase of perm.<br>
Sooner or later it will bail out.<br>
I always start with the heap sizing first. Making sure that<br>
all areas have sufficient capacity and a fixed size in order<br>
to avoid constant CMS runs or even bail outs.<br>
<br>
Thanks and Regards<br>
<br>
Thomas <br><div><div class="h5">
<br>
<br>
<div>On 10/02/13 04:38, Kirk Pepperdine
wrote:<br>
</div>
<blockquote type="cite">
<pre>Hi,
I've just witnessed in 1.7.0_17-b02 (Solaris AMD) CMS cycles being initiated every 7.390 seconds. The system is idle and there are no foreground (ParNew) collections running. Perm occupancy is quite close to it's configured size so it's quite likely that the cause of the CMS cycle is this. However, Class unloading is not enabled and thus the CMS cycle doesn't "fix" the trigger by cleaning out perm or being able to enlarge it (configured size < max size) and there isn't any pressure for a Full collection (CMF??). Triggering a collection (System.gc()) of course "fixes" the problem (facilitates a perm space expansion).
Ok, so there are work arounds for this but it really confused the person who contacted me with the problem and he's no slouch when it comes to GC. I've advised him to turn on perm space sweeping with class unloading. That said, it seems that CMS should know that it's not going to be able to fix the problem that triggered to to run and it should degrade into a CMF, reason perm space needs resizing. My questions are, have I missed something? Should this be filed as a bug? Or, is this as intended?
On a side note I found the 7.390 second period to be an interesting distraction.
Regards,
Kirk</pre>
</blockquote>
<br>
</div></div><div>-- <br>
<a href="http://www.oracle.com" target="_blank"><img style="border:0px solid;width:114px;min-height:26px" src="cid:part1.03020101.00000401@oracle.com" alt="Oracle"></a><br>
<font color="#666666" face="Verdana, Arial, Helvetica, sans-serif">THOMAS VIESSMANN | Senior Principal Technical Support
Engineer - Java<br>
Phone: <a href="tel:+49814302496" target="_blank">+498914302496</a> | Mobile: <a href="tel:+491743005467" target="_blank">+491743005467</a> <br>
<font color="#ff0000">Oracle</font> Customer Technical Support -
Java<br>
<br>
ORACLE Deutschland B.V. & Co. KG | Riesstr.25 | D-80992
Muenchen </font><br>
<br>
<font color="#666666" face="Verdana, Arial, Helvetica, sans-serif" size="1">ORACLE Deutschland B.V. & Co. KG<br>
Hauptverwaltung: Riesstr. 25, D-80992 Muenchen<br>
Registergericht: Amtsgericht Muenchen, HRA 95603<br>
Geschäftsführere: Juergen Kunz<br>
<br>
Komplementärin: ORACLE Deutschland Verwaltung B.V.<br>
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande<br>
Handelsregister der Handelskammer Midden-Niederlande, Nr.
30143697<br>
Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher<br>
</font>
<br>
<hr>
<hr>
<a href="http://www.oracle.com/commitment" target="_blank"><img style="border:0px solid;width:44px;min-height:28px" src="cid:part5.02030001.03080903@oracle.com" alt="Green
Oracle" align="middle"></a>
<font color="#4b7d42" face="Verdana, Arial, Helvetica, sans-serif" size="1">Oracle is committed to developing practices and
products that help protect the environment</font>
</div>
</div>
</blockquote></div><br></div>