Request for review: 6976350 G1: deal with fragmentation while copying objects during GC

Tao Mao tao.mao at oracle.com
Tue May 21 00:11:38 UTC 2013


Hi all,

a new webrev
http://cr.openjdk.java.net/~tamao/6976350/webrev.04/

diff:
(1) John Cuthbertson and I figured out the way to handle "retire an old 
buffer, allocate and set a new one" and it can possibly make the usage 
of allocation buffer a little more efficient.
(2) Make the assertion as John suggested and provide some harness (i.e. 
making retire() a virtual function) to cope with it.

Thanks.
Tao

On 5/15/13 10:58 PM, John Cuthbertson wrote:
> Hi Tao,
>
> This looks excellent. One minor question: does it make sense to assert 
> that each buffer has been retired? It might save a missed call to 
> PSS::retire_alloc_buffers. I'll leave the decision to you. Ship it.
>
> JohnC
>
>
> On 5/14/2013 3:06 PM, Tao Mao wrote:
>> To the open list:
>>
>> new webrev:
>> http://cr.openjdk.java.net/~tamao/6976350/webrev.03/
>>
>> I took suggestion from many reviewers into consideration and came up 
>> with the current cleaner solution.
>>
>> Thank you.
>> Tao
>>
>>
>> On 5/14/13 2:26 PM, Jon Masamitsu wrote:
>>> What's the status of this review?
>>>
>>> The last mail I  could find in my mail boxes was a comment
>>> from Thomas.
>>>
>>> Jon
>>>
>>> On 1/28/13 12:21 PM, Tao Mao wrote:
>>>> 6976350 G1: deal with fragmentation while copying objects during GC
>>>> https://jbs.oracle.com/bugs/browse/JDK-6976350
>>>>
>>>> webrev:
>>>> http://cr.openjdk.java.net/~tamao/6976350/webrev.00/
>>>>
>>>> changeset:
>>>> Basically, we want to reuse more of par-allocation buffers instead 
>>>> of retiring it immediately when it encounters an object larger than 
>>>> its remaining part.
>>>>
>>>> (1) instead of previously using one allocation buffer per GC 
>>>> purpose, we use N(=2) buffers per GC purpose and modify the 
>>>> corresponding code. The changeset would easily scale up to whatever 
>>>> N (though Tony Printezis suggests 2, or 3 may be good enough)
>>>>
>>>> *(2) Two places of cleanup: allocate_during_gc_slow() is removed 
>>>> due to its never being called.
>>>>                                               access modifier 
>>>> (public) before trim_queue() is redundant.
>>>>
>>>>
>>>
>



More information about the hotspot-gc-dev mailing list