JEP 173: Remove Rarely-Used Combinations of Garbage Collectors

Jon Masamitsu jon.masamitsu at
Wed Dec 19 16:34:01 UTC 2012

On 12/18/2012 8:01 PM, lordpixel at wrote:
> On Dec 18, 2012, at 11:45 AM, Jon Masamitsu<jon.masamitsu at>  wrote:
>>> Out of curiosity, is shrinking really a simple choice? Presumably leaving the heap larger means fewer collections and better performance overall if lots more garbage is created.
>> Hmmm.  Not sure I understand this question.
>> Using an implementation that allows shrinking
>> is a simple choice.  How it shrinks is more.
> Yes, sorry, that wasn't very clear. What I meant was is it a simple choice when to shrink the heap vs. when to leave it large and empty after a full collection.

Different answer depending on the collector.

1) DefNew and ParNew use MaxHeapFreeRatio / MinHeapFreeRatio to
try and leave some free spaces after a GC (by default at least 40% but
not more than 70%).

2) CMS has a hard time returning space because it uses freelists.  And
the resizing after a full GC has a bug.

3) ParallelGC tries to leave enough free space to accomodate its
throughput goal (more free space means less frequent GC's means
lower GC overhead means higher throughput).  And also there
is a bug in the resizing after a full GC.

4) Don't know about G1.

> I talked a little about the reasons why I am thinking about this back in Feb, but this thread has gone off topic so I'll drop this unless you want more details about what I was trying to solve for.
> AndyT (lordpixel - the cat who walks through walls)
> A little bigger on the inside
> 	(see you later space cowboy, you can't take the sky from me)

More information about the hotspot-gc-dev mailing list