MinHeapFreeRatio / MaxHeapFreeRatio

[Jon Masamitsu]

On 5/11/2012 10:49 AM, Srinivas Ramakrishna wrote:
> On Fri, May 11, 2012 at 10:16 AM, Jon Masamitsu<jon.masamitsu at oracle.com>wrote:
>
>>   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.
>>
> :-) Sorry i can't remember off-hand, but if i were to grok through the hg
> history i might remember
> when and why that was done... I'll try and take a look at the code over the
> weekend...

Not worth groveling through hg history.  I was just curious.  My memory
says that we used to call do_collection() and it did the resizing.  Then,
as you say, we realized the resizing done by 
TenuredGeneration::compute_new_size()
wasn't what we really wanted.  But really, that is neither here nor there.

Jon

>
>> 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?
>>
> Completely! I think this makes sense. BTW you may have some of the
> "last big chunk" code in the adaptive sizing work for CMS that was put away
> in the attic a while ago (it might need the cobwebs dusted off as some of
> the
> original assumptions and interfaces may have changed.)
>
> -- ramki
>
>
>> 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>wrote:
>>
>>>   On Fri, May 11, 2012 at 1:35 AM, Jon Masamitsu<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>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
>>>>>> 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
>>>
>>>