RFR (L): 8060025: Object copy time regressions after JDK-8031323 and JDK-8057536
jon.masamitsu at oracle.com
Wed Dec 10 23:59:01 UTC 2014
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:
>> 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
>> 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
> Only if allocating in the next generation (whatever this is, depending
> on the source generation) fails, the thread will signal an evacuation
>> Also maybe allocate_in_next_plab() gets in-lined but if it doesn't
>> it's a function call that could be saved.
>> 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.
More information about the hotspot-gc-dev