8300657: Remove null filtering in CLD oop handle area

[fisk]

In the CLD oop handle area, there is a null check before calling do_oop. This is unnecessary, as the closures all perform the same null filtering. Since it's a raw access, it also causes trouble for generational ZGC.

---

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-8300657: Remove null filtering in CLD oop handle area

Reviewers

• Coleen Phillimore (@coleenp - Reviewer)
• David Holmes (@dholmes-ora - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 12145

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

Using diff file

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

[bridgekeeper]

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

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

• hotspot-runtime

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

• 00: Full (7909ef29)

[coleenp]

Nice, and trivial. Thanks!

[openjdk]

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

8300657: Remove null filtering in CLD oop handle area

Reviewed-by: coleenp, dholmes

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

• 2292ce1: 8294677: chunklevel::MAX_CHUNK_WORD_SIZE too small for some applications
• 6dd8723: 8290918: Initial nroff manpage generation for JDK 21
• b3822f5: 8300589: Use @snippet and @linkplain in java.text.CollationKey and java.text.CompactNumberFormat
• afd5921: 8298610: Refactor archiving of ConstantPool::resolved_references()
• 937ba1c: 8300111: Add rpath for common lib locations for jpackageapplauncher
• 2da2e5a: 8300946: Add sun/security/provider/certpath/OCSP/OCSPNoContentLength to ProblemList
• 0323609: 8300706: Use @snippet in java.text
• b5ee3d1: 8299497: Usage of constructors of primitive wrapper classes should be avoided in java.desktop API docs
• 77a5010: 8286775: Remove identical per-compiler definitions of unsigned integral jtypes
• f79e587: 8300828: Avoid unnecessary array fill after creation in com.sun.media.sound
• ... and 13 more: https://git.openjdk.org/jdk/compare/5a4945c0d95423d0ab07762c915e9cb4d3c66abb...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.

[fisk]

Nice, and trivial. Thanks!

Thanks for the review!

[dholmes-ora]

Seems fine.

Aside: Not obvious to me whether closures should be responsible for doing their own null checks or whether the framework should guarantee no nulls get passed to them. You could go either way of course, just depends on the number of closure types versus the number of closure call sites, as to which approach minimises the code. At runtime hopefully there is only ever one null check per data item.

[fisk]

Seems fine.

Aside: Not obvious to me whether closures should be responsible for doing their own null checks or whether the framework should guarantee no nulls get passed to them. You could go either way of course, just depends on the number of closure types versus the number of closure call sites, as to which approach minimises the code. At runtime hopefully there is only ever one null check per data item.

Thanks for the review! We have discussed this policy before, and I think the general consensus is that checking inside of the closure is what we want to do for global roots. That is typically the case already, so this change aligns this policy a bit.

[fisk]

/integrate

[openjdk]

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

• 95fafd0: 8300644: Remove gc/shenandoah/jni/TestStringCriticalWithDedup.java
• 5a478ef: 8297730: C2: Arraycopy intrinsic throws incorrect exception
• 7465de4: 6603771: Nimbus L&F: Ctrl+F7 keybinding for Jinternal Frame throws a NPE.
• fbe5ab0: 8300830: Remove redundant assertion in src/hotspot/share/runtime/javaCalls.cpp
• 1339461: 8300981: Build failure on 32-bit platforms after JDK-8281213
• 81d523d: Merge
• 60b8a98: 8300591: @SuppressWarnings option "lossy-conversions" missing from jdk.compiler module javadoc
• a3ed7e9: 8300623: Lambda deserialization regression involving Enum method reference
• cf46004: 8300272: Improve readability of the test JarWithOneNonDisabledDigestAlg
• b678e70: 8300942: JDK-8299684 breaks x86 build
• ... and 28 more: https://git.openjdk.org/jdk/compare/5a4945c0d95423d0ab07762c915e9cb4d3c66abb...master

Your commit was automatically rebased without conflicts.

[openjdk]

@fisk Pushed as commit b2071f7.

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