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

[Jon Masamitsu]

Tao,

These latest changes look good.

Jon

On 5/20/2013 5:11 PM, Tao Mao wrote:
> 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.
>>>>>
>>>>>
>>>>
>>