hotspot-gc-dev Digest, Vol 33, Issue 7

Fri Mar 12 21:33:57 UTC 2010

I think an important factor with CMS and fragmentation (amongst the
several others) is how long the process runs. We here have combated the
issue that crops up due to extreme short term changes in object
allocation patterns. Some times successfully, some times not. The
fragmentation death spiral is a horrible thing to have to watch.
Fortunately we ended up being able to greatly expand the heap sizes
thanks to -d64 and UseCompressedOops. 

What we have never had to deal with is fragmentation that happens over
long periods of time. Several days of running between bounces for
example. I don't know what if anything you can do about that other than
force a compacting GC when it's safe.

Paul Ciciora 

-----Original Message-----
From: hotspot-gc-dev-bounces at openjdk.java.net
[mailto:hotspot-gc-dev-bounces at openjdk.java.net] On Behalf Of
hotspot-gc-dev-request at openjdk.java.net
Sent: Friday, March 12, 2010 2:00 PM
To: hotspot-gc-dev at openjdk.java.net
Subject: hotspot-gc-dev Digest, Vol 33, Issue 7

Send hotspot-gc-dev mailing list submissions to
	hotspot-gc-dev at openjdk.java.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-dev
or, via email, send a message with subject or body 'help' to
	hotspot-gc-dev-request at openjdk.java.net

You can reach the person managing the list at
	hotspot-gc-dev-owner at openjdk.java.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of hotspot-gc-dev digest..."

Today's Topics:

   1. Re: Discouraging CMS Due To Fragmentation
      (Y. Srinivas Ramakrishna)

----------------------------------------------------------------------

Message: 1
Date: Fri, 12 Mar 2010 09:08:47 -0800
From: "Y. Srinivas Ramakrishna" <Y.S.Ramakrishna at Sun.COM>
Subject: Re: Discouraging CMS Due To Fragmentation
To: "Highley, Ryan" <Ryan.Highley at sabre-holdings.com>
Cc: hotspot-gc-use at openjdk.java.net
Message-ID: <4B9A751F.6090501 at sun.com>
Content-Type: text/plain; charset="us-ascii"

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

_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use

End of hotspot-gc-dev Digest, Vol 33, Issue 7
*********************************************