8254015: copy_to_survivor_space should use in-hand klass for scanning

[kimbarrett]

Please review this small change to G1 evacuation. When scanning the oops
in an instance, the existing code calls obj->oop_iterate_backward(closure).
That function gets the klass of obj and forwards to another function with
the obj, closure, and the just obtained klass. But the caller of
oop_iterate_backward has already obtained the klass for other reasons.
Rather than refetching it (including dealing with
UseCompressedClassPointers), change to use a new oop_iterate_backward
overload taking the klass. This saves a small amount of work for non-array
objects being evacuated.

Testing:
tier1
Generic performance testing didn't find any significant difference.
Looking at just GCBasher evacuation rate, there may to be a small
improvement, though it's hard to measure.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed

Testing

	Linux x64	Windows x64	macOS x64
Build	⏳ (5/5 running)	⏳ (2/2 running)	⏳ (2/2 running)

Issue

• JDK-8254015: copy_to_survivor_space should use in-hand klass for scanning

Reviewers

• Thomas Schatzl (@tschatzl - Reviewer) ⚠️ Review applies to e48daed
• Stefan Johansson (@kstefanj - Reviewer) ⚠️ Review applies to e48daed
• Albert Mingkun Yang (@albertnetymk - Author) ⚠️ Review applies to e48daed

Download

$ git fetch https://git.openjdk.java.net/jdk pull/504/head:pull/504
$ git checkout pull/504

[bridgekeeper]

👋 Welcome back kbarrett! 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]

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

• hotspot

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.

[kimbarrett]

/label remove hotspot
/label add hotspot-gc

[openjdk]

@kimbarrett
The hotspot label was successfully removed.

[openjdk]

@kimbarrett
The hotspot-gc label was successfully added.

[mlbridge]

Webrevs

• 01: Full - Incremental (b0db7f3)
• 00: Full (e48daed)

[openjdk]

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

8254015: copy_to_survivor_space should use in-hand klass for scanning

Reviewed-by: tschatzl, sjohanss, ayang

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 1 new commit pushed to the master branch:

• 76a5852: 8253756: C2 CompilerThread0 crash in Node::add_req(Node*)

Please see this link for an up-to-date comparison between the source branch of this pull request and 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.

[kstefanj]

Looks good.

[albertnetymk]

Does it make sense to drop oop_iterate_backwards(OopClosureType* cl) and only have the method with two args so that klass will never be re-fetched?

[mlbridge]

Mailing list message from Kim Barrett on hotspot-gc-dev:

On Oct 5, 2020, at 9:33 AM, Albert Mingkun Yang <ayang at openjdk.java.net> wrote:

Does it make sense to drop `oop_iterate_backwards(OopClosureType* cl)` and only have the method with two args so that
klass will never be re-fetched?

I don't think so. Not all uses both already have the klass in hand and are
performance critical. Though there are very few uses of this function.

I don't think so. Not all uses both already have the klass in hand and are
performance critical to care. Though there are very few uses of this
function, the other oop_iterate variants probably ought to have similar
treatment. I was planning to file an RFE to add klass-taking overloads for
them. When you include those I think the convenience for not requiring the
klass argument is more obvious.

[albertnetymk]

I was planning to file an RFE to add klass-taking overloads for them. When you include those I think the convenience for not requiring the klass argument is more obvious.

OK; thanks for the explanation.

[kimbarrett]

/integrate

[openjdk]

@kimbarrett Since your change was applied there has been 1 commit pushed to the master branch:

• 76a5852: 8253756: C2 CompilerThread0 crash in Node::add_req(Node*)

Your commit was automatically rebased without conflicts.

Pushed as commit 66f27b5.

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

[kimbarrett]

Thanks for reviews, Thomas, Stefan, and Albert.