MinHeapFreeRatio / MaxHeapFreeRatio

[Jon Masamitsu]

Ramki,

Do you remember if there was originally a call to
do_collection() in the CMS do_compaction_work()?
It currently has a call to GenMarkSweep::invoke_at_safepoint()
to do the collection.

For shrinking the CMS generation I had in mind looking
at the free chunk at the end of the generation and shrinking
the generation according to policy (the FreeRatio's) and
the size of that free chunk.  After a mark-sweep-compact
the free chunk at the end of the generation would be
everything free.  So in this case the current interfaces
would work if CMS::compute_new_size() were just
called at the end of do_compaction_work().  And if
CMS::compute_new_size() were fixed.  Do you believe?

Jon


On 05/10/12 23:05, Srinivas Ramakrishna wrote:
> Jon, Kris -- I agree that there is an easily fixed bug here which 
> could be fixed by (more or less) having the CMS generation
> basically do after a stop-world collection what TenuredGeneration 
> does, modulo appropriate parameters
> (CMS needs more headroom etc. which are really different free ratio 
> defaults). Looks like the
> expansion/shrinking/resizing really belonged to a Policy class which 
> would take a generation
> as a parameter and resize it appropriately based on the state of the 
> generation and policy
> parameters (which could be obtained from the generation). That would 
> allow for sharing of
> the code without the kind of duplication that we have today with small 
> modifications at various
> places...
>
> -- ramki
>
> On Thu, May 10, 2012 at 9:24 PM, Krystal Mok <rednaxelafx at gmail.com 
> <mailto:rednaxelafx at gmail.com>> wrote:
>
>
>     On Fri, May 11, 2012 at 1:35 AM, Jon Masamitsu
>     <jon.masamitsu at oracle.com <mailto:jon.masamitsu at oracle.com>> wrote:
>
>
>         Not quite.   Damon was using System.gc() to try to resize and
>         System.gc() (not using the concurrent
>         collection but the STW collection) uses the MarkSweep code.
>          That code can use the compute_new_size()
>         and shrink the heap.
>
>     Oops, should have made myself clearer.
>     I meant shrinking is part of the generational GC framework's
>     interface, but the implementation in CMS generation is empty:
>
>     void ConcurrentMarkSweepGeneration::shrink_by(size_t bytes) {
>       assert_locked_or_safepoint(Heap_lock);
>       assert_lock_strong(freelistLock());
>       // XXX Fix when compaction is implemented.
>       warning("Shrinking of CMS not yet implemented");
>       return;
>     }
>
>     And ConcurrentMarkSweepGeneration::compute_new_size() currently
>     handles expansion but not shrinking.
>
>     So even if one were to resize the space at the end of a STW full
>     GC, the CMS old / perm gen still could handle shrinking.
>     In fact, my original motivation to implement shrinking in CMS
>     (generation, not concurrent collection) was almost the same as
>     what Damon is asking for, that is to release memory back to OS
>     after a full GC.
>
>     - Kris
>
>         You're right about the CompactibleFreeListSpace used by CMS
>         where the free space is on
>         a free list.  Live objects at the end of the generation make
>         it impossible to shrink the
>         generation.
>
>         Jon
>
>             - Kris
>
>             On Fri, May 11, 2012 at 12:31 AM, Jon
>             Masamitsu<jon.masamitsu at oracle.com
>             <mailto:jon.masamitsu at oracle.com>>wrote:
>
>                 Damon,
>
>                  From inspection of the code I think that CMS does not
>                 do a
>                 resizing of the heap after it does a System.gc().
>                  That resizing
>                 would be the code that adjusts the generations for
>                 MinHeapFreeRatio / MaxHeapFreeRatio and returns
>                 memory to the OS.
>
>                 I've created CR 7167923 to investigate this bug.
>
>                 Jon
>
>                 On 5/9/2012 2:34 AM, Damon Hart-Davis wrote:
>
>                     Hi,
>
>                     No, because when I explicitly call System.gc() I
>                     want it to try as hard
>
>                 as it can, even to the point of stopping the world...
>
>                     Rgds
>
>                     Damon
>
>
>                     On 9 May 2012, at 10:27, Jon Masamitsu wrote:
>
>                         Damon,
>
>                         Do you turn on ExplicitGCInvokesConcurrent?
>
>                         Jon
>
>                 _______________________________________________
>                 hotspot-gc-use mailing list
>                 hotspot-gc-use at openjdk.java.net
>                 <mailto: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
>     <mailto:hotspot-gc-use at openjdk.java.net>
>     http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20120511/9fc3d643/attachment-0001.html