Skip to content

Conversation

albertnetymk
Copy link
Member

@albertnetymk albertnetymk commented Sep 9, 2025

Refactor PSScavengeCLDClosure and its "enclosing" PSScavengeFromCLDClosure so that all CLD logic is encapsulated in the CLD closure, without polluting the oop closure.

Test: tier1-3


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-8367240: Parallel: Refactor PSScavengeCLDClosure (Enhancement - P4)

Reviewers

Reviewers without OpenJDK IDs

  • @fandreuz (no known openjdk.org user name / role)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 27165

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

Using diff file

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

Using Webrev

Link to Webrev Comment

@bridgekeeper
Copy link

bridgekeeper bot commented Sep 9, 2025

👋 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
Copy link

openjdk bot commented Sep 9, 2025

@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:

8367240: Parallel: Refactor PSScavengeCLDClosure

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 15 new commits pushed to the master branch:

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 openjdk bot changed the title 8367240 8367240: Parallel: Refactor PSScavengeCLDClosure Sep 9, 2025
@openjdk
Copy link

openjdk bot commented Sep 9, 2025

@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.

@openjdk openjdk bot added hotspot-gc [email protected] rfr Pull request is ready for review labels Sep 9, 2025
@mlbridge
Copy link

mlbridge bot commented Sep 9, 2025

Webrevs

// if references are left in the young gen.
_oop_closure.set_scanned_cld(cld);
// Reset before iterating oops.
_oop_closure._has_oop_into_young_gen = false;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if this wouldn't be cleaner if you set up a new PSScavengeFromCLDClosure here instead. Then you wouldn't have to explicitly reset _has_oop_into_young_gen here.

    if (cld->has_modified_oops()) {
      PSScavengeFromCLDClosure oop_closure(_pm);

      // Clean the cld since we're going to scavenge all the metadata.
      cld->oops_do(&oop_closure, ClassLoaderData::_claim_none, /*clear_modified_oops*/true);

      if (oop_closure.has_oops_into_young_gen()) {
        cld->record_modified_oops();
      }
    }

Maybe you don't have to hide PSScavengeFromCLDClosure inside PSScavengeCLDClosure. I find it more distracting that what we had before. If you don't agree with that, maybe the PSScavengeCLDClosure name could be changed so that we don't repeat the PSScavenge prefix for the internal class.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have simplified the class name and moved it inside the do_cld method.

};
public:
// Records whether this CLD contains oops pointing into young-gen after scavenging.
bool _has_oop_into_young_gen;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment says oops but name says oop. Maybe use _has_oops_into_young_gen?

_scanned_cld = cld;
}
// Scavenges a single oop in a ClassLoaderData.
class CLDOopClosure : public OopClosure {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes the do_cld function much harder to read, IMHO. So, three alternatives:

  1. Keep the class outside PSScavengeCLDClosure, just like it was before this patch.
  2. Have the class inside PSScavengeCLDClosure, but not in a function
  3. Have the class inside a function inside PSScavengeCLDClosure.

I prefer (1) because it allows you to look at PSScavengeCLDClosure without having to see the details about the second class. I'm OK with (2) and like that it encapsulates the other class. I don't think we should do (3) because it significantly hurts the readability of do_cld.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have moved the oop-closure class def outside.

Copy link
Member

@stefank stefank left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for fixing the style. I've added two small nits, but otherwise I've approved the PR.

@@ -77,17 +77,19 @@ class PSRootsClosure: public OopClosure {
typedef PSRootsClosure</*promote_immediately=*/false> PSScavengeRootsClosure;
typedef PSRootsClosure</*promote_immediately=*/true> PSPromoteRootsClosure;


Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change

};

// Scavenges the oop in a ClassLoaderData.
class PSScavengeCLDClosure: public CLDClosure {
private:
PSScavengeFromCLDClosure _oop_closure;
PSPromotionManager* _pm;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To make the two classes consistent w.r.t. newlines.

Suggested change
PSPromotionManager* _pm;
PSPromotionManager* _pm;

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Sep 9, 2025
@openjdk openjdk bot removed the ready Pull request is ready to be integrated label Sep 9, 2025
@openjdk openjdk bot added the ready Pull request is ready to be integrated label Sep 9, 2025
@@ -97,43 +98,33 @@ class PSScavengeFromCLDClosure: public OopClosure {
oop new_obj = _pm->copy_to_survivor_space</*promote_immediately=*/false>(o);
RawAccess<IS_NOT_NULL>::oop_store(p, new_obj);

if (PSScavenge::is_obj_in_young(new_obj)) {
do_cld_barrier();
if (PSScavenge::is_obj_in_young(new_obj) && !_has_oops_into_young_gen) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you need to check !_has_oops_into_young_gen ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's to avoid writing _has_oops_into_young_gen multiple times, if it's already true. (Both versions are correct though.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I was curious why it's needed. What's the problem with just writing true if it's already true?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no problem; just redundant work.

@albertnetymk
Copy link
Member Author

Thanks for review.

/integrate

@openjdk
Copy link

openjdk bot commented Sep 10, 2025

Going to push as commit 385c132.
Since your change was applied there have been 18 commits pushed to the master branch:

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Sep 10, 2025
@openjdk openjdk bot closed this Sep 10, 2025
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Sep 10, 2025
@openjdk
Copy link

openjdk bot commented Sep 10, 2025

@albertnetymk Pushed as commit 385c132.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hotspot-gc [email protected] integrated Pull request has been integrated
Development

Successfully merging this pull request may close these issues.

3 participants