Discouraging CMS Due To Fragmentation

[Highley, Ryan]

Ramki,

Thank you for your prompt response and suggestions.

As was mentioned in the Dev mailing list thread, the app instances we
tend to deal with typically remain up for weeks, if not months, at a
time.  For most, the allocation patterns are fairly constant and do not
require "forcing" a compacting collector to run periodically.  However,
there are a few requiring exactly that.

We will definitely be giving G1 a try, but won't be able to deploy it to
production until it's in a GA release.  (The PTBs get nervous when the
deployment documentation describes compiling a JVM. ;) )  CR 6631166
also looks extremely promising for many of our applications.

Ryan



-----Original Message-----
From: Y.S.Ramakrishna at Sun.COM [mailto:Y.S.Ramakrishna at Sun.COM] 
Sent: Friday, March 12, 2010 11:09 AM
To: Highley, Ryan
Cc: hotspot-gc-use at openjdk.java.net
Subject: Re: Discouraging CMS Due To Fragmentation

I agree with your stance below; that fragmentation is a concern
that needs to be managed by means of tuning promotion rates so
as to promote only medium- and long-lived objects (which usually,
but not always, have a stationary or quasi-stationary object size and
lifetime distribution). Jon Masamitsu has a blog that describes this
in some detail, and Tony Printezis and Charlie Hunt have a JavaOne
talk in which they provide tips for such tuning, and for dealing
with possible long-term fragmentation.

See also CR 6631166 which fixes some fragmentation issues, which
certain customers have found quite effective in reducing fragmentation.

There are indeed many, many customers who use CMS successfully despite
theoretical concerns regarding fragmentation.

All that having been said, there is probably a class of applications.
especially those that store medium- and long-lived string objects
with which CMS has historically performed poorly. (I do not know
whether such customers have tried CMS post-6631166 however.)
The reason is that if the size and lifetime distributions of
medium-lived objects is long/fat-tailed or flat or, as usually happens
in some cases of programs involving long-lived strings, very
non-stationary, then the coalition and splitting heuristics used
by CMS turn out to be much less effective. You might want to try the
G1 garbage collector for such applications because G1 will not suffer
from such concerns related to fragmentation.

-- ramki

Highley, Ryan wrote:
> Hello all,
> 
>  
> 
> My company has a cache-based application using a well-known Java
memory
> clustering framework for handling the usual failover and load
balancing
> concerns ensuring cache state is maintained when losing a node or two.
> 
>  
> 
> Naturally, application garbage collector choice has been explored
during
> conversations with the support staff for this framework.  The
> framework's support staff has insisted any application using their
> framework should use the ParallelOld collector due to issues regarding
> using CMS and its inherent memory fragmentation.  The latest exchange
is
> below with my questions first and the response following.  The
> framework's name has been removed.
> 
>  
> 
> Questions:  Are there specific outstanding reported Sun JVM CMS bugs
> that are the basis for the requirement to use ParallelOld?  If so,
what
> are they, as other applications may also be subject to the same issue?
> If not, what is so fundamentally different about <product>'s memory
> usage and garbage collector interactions that makes CMS a bad choice?
> 
>  
> 
>>From <product>:   This is not <product> specific but in Java in
general.
> Sun itself recommends staying away from CMS if possible due to
possible
> fragmentation issues. In other words, with CMS you are just delaying
the
> problem and will possibly hit a very long pauseful collection at some
> point.
> 
>  
> 
> In my now several years of reading Sun GC white papers, tuning guides,
> articles, blog posts, messages threads (here and elsewhere), and the
> like, I have never heard any assertion from Sun discouraging CMS use
> altogether simply due to the memory fragmentation inherent to CMS'
> design.  Everything I have seen, and everything we have implemented
> successfully tuning several other applications, has shown with CMS
> memory fragmentation is a concern to be managed through proper
promotion
> tuning, heap sizing and shaping, and setting a reasonable CMS
initiating
> occupancy fraction to be fairly certain a promotion failure is at best
> extremely unlikely.
> 
>  
> 
> However that nagging possibility that I've missed something along the
> way still exists.
> 
>  
> 
> Can I please get a definitive response from one (or more) of the Sun
> garbage collection software engineers on this list in this matter?
> 
>  
> 
> Thank you for your attention,
> 
>  
> 
> Ryan
> 
>  
> 
> 
> 
> 
>
------------------------------------------------------------------------
> 
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use