JDK-8072809 : Further cleanups after Generation array removal: gen_process_roots and OopsInGenClosure::set_generation
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Other
  • Submitted: 2015-02-09
  • Updated: 2020-09-24
  • Resolved: 2020-09-24
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.
Other
tbdResolved
Related Reports
Blocks :  
Relates :  
Description
GenCollectedHeap::gen_process_roots() is a bit of a mess now. It first calls SharedHeap::process_roots. It then does completely different things, depending on the value of the first (level) argument. That's not at all obvious from the way the code is written though. Retaining the structure from the old iteration through _gens[] is not helpful in the new world where we have exactly two generations.

There are two overloads for gen_process_roots(). The first does most of the work. The second constructs an additional closure and calls the first with that closure plus some other argument adjustments. If all client callers call the second; the first could be hoisted into the second and eliminated as a separate function.

We can determine the level value for all callers. This and the fact that this function does very different things according to the level suggests splitting this function into two distinct functions.

Caller levels are as follows:

- MarkSweep always calls with level = 1 (assertion)
- CMS always calls with level = _cmsGen->level() which is 1
- ParNewGeneration::work calls with level = _gen->level(), where _gen is the young generation, so level is always 0 here
- DefNewGeneration::collect calls with level = _level where _level is 0, since this is young generation

The two callers apparently providing 0 as the level also always provide true as the second (younger_gens_as_roots) argument. Further argument simplifications would likely result from splitting.

Comments
This has already been taken care of with JDK-8139800 and associated changes.
24-09-2020

When reviewing this cleanup it was noted that the generation field in OopsInGenClosure is only set once and never changed. Still the code keeps setting the value (to the same value) and resetting it (to the same value) over and over again. It was decided to include the removal of this behaviour in this change. The title of the bug was updated accordingly.
19-10-2015