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

[John Cuthbertson]

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