RFR (L): 8060025: Object copy time regressions after JDK-8031323 and JDK-8057536
thomas.schatzl at oracle.com
Tue Dec 9 14:52:35 UTC 2014
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