RFR (L): 8060025: Object copy time regressions after JDK-8031323 and JDK-8057536

[Jon Masamitsu]

On 12/9/2014 6:52 AM, Thomas Schatzl wrote:
> Hi Jon,
>
>    thanks for looking at the change.
>
> On Wed, 2014-12-03 at 19:40 -0800, Jon Masamitsu wrote:
>> Thomas,
>>
>> http://cr.openjdk.java.net/~tschatzl/8060025/webrev.0/src/share/vm/gc_implementation/g1/g1ParScanThreadState.cpp.frames.html
>>
>> G1ParScanThreadState::allocate_in_next_plab() basically tries to
>> allocate from InCSetState::Old and changes some state variables
>> (_tenuring_threshold and parameter dest).  I'm not sure it's worth
>> having a method to do that.   Would it make it simpler to
>> understand if copy_to_survivor_space() called
>>
>> _g1_par_allocator->allocate()
>>
>> directly and the resetting of _tenuring_threshold and parameter dest
>> were set in handle_evacuation_failure()?
> The failing path (where _tenuring_threshold and dest are set) does not
> mean that there will be an evacuation failure. It just means that there
> is no more space in the survivor space for this thread. The thread will
> continue to run by allocating everything directly in the old gen (by
> setting its local tenuring threshold) next time there is something to
> allocate.
>
> Only if allocating in the next generation (whatever this is, depending
> on the source generation) fails, the thread will signal an evacuation
> failure.

Ok.

>
>> Also maybe allocate_in_next_plab() gets in-lined but if it doesn't
>> it's a function call that could be saved.
>>
>> http://cr.openjdk.java.net/~tschatzl/8060025/webrev.0/src/share/vm/gc_implementation/g1/g1Allocator.cpp.frames.html
>>
>> The old code used a HeapWord* obj
>>
>>    117   HeapWord* obj = NULL;
>>
>>
>> that it returns at t he end of the method.  Is the change you made to not
>> use the "obj" a style change?  Or was better performance expected? Style
>> reason is fine.  I just want to know the reason.
> You meant allocate_direct_or_new_plab() I think. There is no particular
> reason for this change. Probably because there is already an early exit
> at line 127. If you do not mind I will keep it.

That's fine.

Jon

>
> Thanks,
>    Thomas
>
>