MinHeapFreeRatio / MaxHeapFreeRatio

[Srinivas Ramakrishna]

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@**
>>> oracle.com <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 <hotspot-gc-use at openjdk.java.net>
>>>> http://mail.openjdk.java.net/**mailman/listinfo/hotspot-gc-**use<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/20120510/8c3a7c8c/attachment.html