JDK-8060025 : Object copy time regressions after JDK-8031323 and JDK-8057536
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 8u40,9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-10-09
  • Updated: 2018-03-28
  • Resolved: 2014-12-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u60Fixed 9 b45Fixed
Related Reports
Duplicate :  
JDK-7163196 - G1: Use two arrays for the fast cset test, put region type information in the arrays
Duplicate :  
JDK-8052167 - G1 wrongly counts PLABs not allocated in the originally intended allocation "generation"
Relates :  
JDK-8078669 - G1 applies SurvivorAlignmentInBytes to both survivor and old gen
Relates :  
JDK-8057536 - Refactor G1 to allow context specific allocations
Relates :  
JDK-8068036 - assert(is_available(index)) failed in G1 cset
Relates :  
JDK-8067920 - Rename InCSetState to something more understandable
Description
Object copy times regress with SPECjbb2005 (and any other workload that mostly copies around data in the young generation) by a few percent.

JDK-8031323 and JDK-8057536 seem to be the problem.

Change copy_to_survivor_space() and friends to fix this.
Comments
One minor related fix would be to have per-ParScanThreadState tenuring thresholds.
13-10-2014
This is an object copy time regression that is only a part of the gc pause. So impacts benchmarks or tests that stress that only that. Not even for benchmarks that stress that (specjbb2005) gc pause consists of 100% object copy time, but only a large part. Additionally total gc pause time is most of the time very low (low single percentage), so this difference is lost in noise.
10-10-2014
ILW: I: low -> no impact on end-to-end performance L: high -> always W: high -> none
10-10-2014
Some numbers of several attempts examining copy_to_survivor_space performance implications (jdk9 build, linux_x64, 5 samples each. All times in ms. "conf" is the 95% confidence interval): 1) Current Baseline: avg: 30.983, conf: 30.588 - 31.379 3) Remove load (00-remove-mark-load.patch) avg: 30.579, conf: 30.132 - 31.026 (+1.4%) (not significant) 4) Split out fast/slow path for the allocate call, based on 3) (01-split-allocation.patch) avg: 30.456, conf: 30.068 - 30.844 (+1.7%) (not significant) 5) Old Baseline (before Resman changes) avg: 30.552, conf: 30.152 - 30.952 (+1.4%) (not significant) 6) Removed survivor alignment based on 4) avg: 29.643, conf: 29.220 - 30.066 (+2.9%) (significant) (instead of the allocate_aligned() call in g1Allocator.hpp:205, call allocate() and merge the if-statement.
09-10-2014