CMS cycles triggered by Perm almost being full

[Kirk Pepperdine]

Hi Thomas,

No disclaimers needed. Point noted on the getting sizes right. In this case it took me about a minute to realize that the problem was with perm. However there is other data in the logs that confuses. The data provided by jstat is also or should I say, can be misleading in that it both report max size reserved as apposed to currently configured size. You need a full GC to get the truth. Then you get one data point that is seemingly inconsistent with 100s of data other data points that make sense in that they match command line configs.. and it is expected that if you have head room and you need it, you'll get it... and that doesn't happen in this edge case though it seems that this case can and should be detected so that instead of getting back to back CMS cycles that do nothing, the correct action can be taken. I'm currently working on another problem that deals with soft references that is fairly similar in that the VM does the wrong thing often even though the correct thing to do is both obvious and easily calculated for.

As for resizing... I need to go back and take a look at that code again. There are parts in there that trigger a realloc of at least young when a resize is in order however this can't happen in old space. There I'm not sure if size up or down is an adjustment to the free list. At any rate, adjustments down can only from memory at the top of heap and if that is occupied, which is highly likely, space cannot be returned. There maybe other restrictions that just make it easier to resize on a CMF.

-- Kirk

On 2013-10-02, at 9:12 AM, Thomas Viessmann <thomas.viessmann at oracle.com> wrote:

> Hi Kirk,
> 
> Disclaimer: I'm in support and all I can share is my experience:
> 
> You always need a full GC if heap resizing is needed.
> CMS  AFAIHS cannot initiate an increase of perm.
> Sooner or later it will bail out.
> I always start with the heap sizing first. Making sure that
> all areas have sufficient capacity and a fixed size in order
> to avoid constant CMS runs or even bail outs.
> 
> Thanks and Regards
> 
> Thomas 
> 
> 
> On 10/02/13 04:38, Kirk Pepperdine wrote:
>> 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
> 
> -- 
> <oracle_sig_logo.gif>
> THOMAS VIESSMANN | Senior Principal Technical Support Engineer - Java
> Phone: +498914302496 | Mobile: +491743005467 
> Oracle Customer Technical Support - Java
> 
> ORACLE Deutschland B.V. & Co. KG | Riesstr.25 | D-80992 Muenchen 
> 
> ORACLE Deutschland B.V. & Co. KG
> Hauptverwaltung: Riesstr. 25, D-80992 Muenchen
> Registergericht: Amtsgericht Muenchen, HRA 95603
> Geschäftsführere: Juergen Kunz
> 
> Komplementärin: ORACLE Deutschland Verwaltung B.V.
> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
> Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher
> 
> <green-for-email-sig_0.gif> Oracle is committed to developing practices and products that help protect the environment

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20131002/ccf3dcc0/attachment.htm>