JDK-8253236 : [REDO] Investigate fast-path for scanning only objects with references during gc
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs25,8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-09-16
  • Updated: 2024-11-22
  • Resolved: 2020-09-22
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 16
16 b17Fixed
Related Reports
Cloners :  
JDK-8027761 - Investigate fast-path for scanning only objects with references during gc
Relates :  
JDK-8253169 - [BACKOUT] Improve large object handling during evacuation
Relates :  
JDK-8040978 - Investigate fast-path for scanning objects during marking and refinement
Description
During evacuation, after copying an object to survivor space, it is scanned for further references that may need to be fixed up. This scanning involves calling oop_iterate() on the object.

We noticed that in many benchmarks (dacapo, specjbb) a large part of the copied objects do not contain any references.

I.e. across all dacapo benchmarks, over all gcs, on average only 63% of objects contain references, on Specjbb2005 only 60% (looking at instanceOops, typeArrayOops and objArrayOops which make up >97% of the objects copied).

Investigate if it is possible to have a very fast check whether the copied object potentially contains references or not, skipping the oop iteration call otherwise (and hopefully improving performance in the process).
Comments
Changeset: 0e98fc1c Author: Kim Barrett <kbarrett@openjdk.org> Date: 2020-09-22 05:14:06 +0000 URL: https://git.openjdk.java.net/jdk/commit/0e98fc1c
22-09-2020
See JDK-8027761 for discussion of some approaches. The eventual suggestion there is to test whether the object is a typeArray and skip doing any scanning in that case. That provides pretty much all of the benefit. A non-array that doesn't contain any oops could be recognized by an extension of the _layout_helper bits, but the class would still need to be processed.
16-09-2020