MinHeapFreeRatio / MaxHeapFreeRatio

[Srinivas Ramakrishna]

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...


>
> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20120511/230ec11b/attachment.html