JDK-8027761 : 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: Closed
  • Resolution: Fixed
  • Submitted: 2013-11-04
  • Updated: 2020-09-21
  • Resolved: 2020-09-15
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 b16Fixed
Related Reports
Cloners :  
JDK-8253236 - [REDO] 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: dafcf105 Author: Kim Barrett <kbarrett@openjdk.org> Date: 2020-09-15 12:18:24 +0000 URL: https://git.openjdk.java.net/jdk/commit/dafcf105
15-09-2020
Instead of adding this information to the Klass::_layout_helper, one could simply use the existing information (obj->is_typeArray()) for this decision. This is much less complicated than the previously suggested option, and yields almost the same benefit.
18-04-2014
This could also be used (to probably better effect) in marking.
04-11-2013
It may be too slow to simply call a helper method on the klass trying to find out this information. Maybe this information could be embedded in a bit somewhere, e.g. the klass pointer.
04-11-2013