8361055: Serial: Inline SerialHeap::process_roots

[albertnetymk]

Refactor roots processing in Serial (young-gc and full-gc) to clean up the control-flow and make is clearer what roots and closures are used in each context.

Test: tier1-8

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8361055: Serial: Inline SerialHeap::process_roots (Enhancement - P4)

Reviewers

• Stefan Karlsson (@stefank - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/26038/head:pull/26038
$ git checkout pull/26038

Update a local copy of the PR:
$ git checkout pull/26038
$ git pull https://git.openjdk.org/jdk.git pull/26038/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 26038

View PR using the GUI difftool:
$ git pr show -t 26038

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/26038.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back ayang! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@albertnetymk This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8361055: Serial: Inline SerialHeap::process_roots

Reviewed-by: stefank

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 36 new commits pushed to the master branch:

• 832bfbc: 8338474: Parallel: Deprecate and obsolete PSChunkLargeArrays
• 3066a67: 8361101: AOTCodeAddressTable::_stubs_addr not initialized/freed properly
• ce99869: 8359120: Improve warning message when fail to load hsdis library
• ... and 33 more: https://git.openjdk.org/jdk/compare/c2d76f9844aadf77a0b213a9169a7c5c8c8f1ffb...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[openjdk]

@albertnetymk The following label will be automatically applied to this pull request:

• hotspot-gc

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 01: Full - Incremental (0743d5e5)
• 00: Full (6088695a)

[tschatzl]

Not really convinced about this change: if there is need to add a root now, you need to look at three places instead of one.
The parameter to select particular additional roots seems clear enough to me.

[stefank]

Suggested change

	_old_gen->scan_old_to_young_refs(_old_gen->space()->top());
	// During young-gc, visit all (strong+weak) clds with the same closure.
	_old_gen->scan_old_to_young_refs(_old_gen->space()->top());
	// During young-gc, visit all (strong+weak) clds with the same closure.

I also wonder if the previous placement of scan_old_to_young_refs after the other roots were intentional and this PR changes that?

[albertnetymk]

Both orderings are fine. (ScavengeRootsTask processes old-to-young pointers first). I changed that to avoid a local variable. Can revert it back if you prefers that.

[stefank]

OK. I understand. It could be worth adding a comment explaining that we're scanning objects that were old before relocation started. FWIW, if you want to keep it at the top then I think you can get rid of "_old_gen->space()->top()" from this function and extract it inside scan_old_to_young_refs instead.

[albertnetymk]

Added comment and inlined space()->top() to the callee.

[stefank]

The old code treated !ClassUnloading differently. It's not clear to me why this change is correct.

[albertnetymk]

always_strong_cld_do does ClassUnloading checking internally.

Semantically, for full-gc marking, we process always-strong clds only. (Ofc, if class unloading is off, all clds are always-strong.)

[stefank]

I see.

After having not looked at this for a while I find the "always" part of the name both redundant and even slightly misleading. This function could be named "strong_cld_do" (or even strong_clds_do, but the other functions are also miss the s). This could be a cleanup for the future.

[albertnetymk]

Not really convinced about this change: if there is need to add a root now, you need to look at three places instead of one.

That's true and IMO desirable. If a new kind of roots are added, we need to think carefully, how (young/old) gcs and different phases process it.

The parameter to select particular additional roots seems clear enough to me.

Well, I guess it's different style. For example, with this refactoring (untanglement), I noticed that for young-gc, Threads::oops_do doesn't need the second argument (nmethod_cl can be set to null) to skip nmethod scanning. I suspect this redundancy will be hard to spot in the original style. (I will do that after this refactoring.)

[stefank]

Not really convinced about this change: if there is need to add a root now, you need to look at three places instead of one.

That's true and IMO desirable. If a new kind of roots are added, we need to think carefully, how (young/old) gcs and different phases process it.

The parameter to select particular additional roots seems clear enough to me.

Well, I guess it's different style. For example, with this refactoring (untanglement), I noticed that for young-gc, Threads::oops_do doesn't need the second argument (nmethod_cl can be set to null) to skip nmethod scanning. I suspect this redundancy will be hard to spot in the original style. (I will do that after this refactoring.)

FWIW, I tend to like these kind of untanglements. We've gone back and forth w.r.t. the style in the root processors and making them more generic tends to make the code harder to understand, IMHO.

[stefank]

To me this is OK. I'll leave it up to you and other reviewers to determine if this change should be made or not.