JEP 173: Remove Rarely-Used Combinations of Garbage Collectors
jon.masamitsu at oracle.com
Wed Dec 19 16:34:01 UTC 2012
On 12/18/2012 8:01 PM, lordpixel at me.com wrote:
> On Dec 18, 2012, at 11:45 AM, Jon Masamitsu<jon.masamitsu at oracle.com> 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