Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8256106: Bypass intrinsic/barrier when calling Reference.get() from Finalizer #1140

Closed
wants to merge 3 commits into from

Conversation

rkennke
Copy link
Contributor

@rkennke rkennke commented Nov 10, 2020

Finalizer calls Reference.get() from the Finalizer to acquire the finalizee. Concurrent reference processing GCs like Shenandoah and ZGC would return NULL for unreachable referents, and thus would not call finalize() on them.

ZGC works around this by fixing the referent before enqueuing, so that the barrier would take the fast-path, but Shenandoah cannot do this.

It is ok to bypass the barrier altogether in this place, because the FinalReference is inactive and marking and reference-discovery treat inactive FinalReferences like strong references.

Testing:

  • hotspot_gc_shenandoah
  • tier1 +UseShenandoahGC +ShenandoahVerify
  • tier2 +UseShenandoahGC +ShenandoahVerify
  • tier1
  • tier2

Progress

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

Testing

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

Issue

  • JDK-8256106: Bypass intrinsic/barrier when calling Reference.get() from Finalizer

Reviewers

Download

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

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Nov 10, 2020

👋 Welcome back rkennke! 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 openjdk bot added the rfr label Nov 10, 2020
@openjdk
Copy link

@openjdk openjdk bot commented Nov 10, 2020

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

  • core-libs

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 the core-libs label Nov 10, 2020
@rkennke
Copy link
Contributor Author

@rkennke rkennke commented Nov 10, 2020

/cc hotspot-gc

@openjdk openjdk bot added the hotspot-gc label Nov 10, 2020
@openjdk
Copy link

@openjdk openjdk bot commented Nov 10, 2020

@rkennke
The hotspot-gc label was successfully added.

@mlbridge
Copy link

@mlbridge mlbridge bot commented Nov 10, 2020

Webrevs

Copy link
Contributor

@fisk fisk left a comment

I would prefer if we could make this look like less of a hack. We use the "raw" postfix usually to describe an access that will not have GC barriers applied. This is not true here. What it does, is rather to apply strong load barriers, which is not a raw access. So I think the name should suggest that this is treated like a strong access. Strong loads are semantically okay when the Reference is inactive, because then the referent switches over to strong semantics instead. So perhaps we could call it something that better captures this. Either something like getAsStrong() or getInactive(). I think I might prefer the latter. And new comments to describe what I just said. Oh and the comments should maybe be in java doc format like all the other comments in this file.

fisk
fisk approved these changes Nov 11, 2020
Copy link
Contributor

@fisk fisk left a comment

Looks good.

@openjdk
Copy link

@openjdk openjdk bot commented Nov 11, 2020

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

8256106: Bypass intrinsic/barrier when calling Reference.get() from Finalizer

Reviewed-by: eosterlund

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

  • 3c3469b: 8256020: Shenandoah: Don't resurrect objects during evacuation on AS_NO_KEEPALIVE
  • 2e19026: 8253064: monitor list simplifications and getting rid of TSM
  • 421a7c3: 8256182: Update qemu-debootstrap cross-compilation recipe
  • 6247736: 8256018: Adler32/CRC32/CRC32C missing reachabilityFence
  • 436019b: 8256166: [C2] Registers get confused on Big Endian after 8221404

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.

@openjdk openjdk bot added the ready label Nov 11, 2020
@rkennke
Copy link
Contributor Author

@rkennke rkennke commented Nov 11, 2020

/integrate

@openjdk openjdk bot closed this Nov 11, 2020
@openjdk openjdk bot added integrated and removed ready rfr labels Nov 11, 2020
@openjdk
Copy link

@openjdk openjdk bot commented Nov 11, 2020

@rkennke Since your change was applied there have been 5 commits pushed to the master branch:

  • 3c3469b: 8256020: Shenandoah: Don't resurrect objects during evacuation on AS_NO_KEEPALIVE
  • 2e19026: 8253064: monitor list simplifications and getting rid of TSM
  • 421a7c3: 8256182: Update qemu-debootstrap cross-compilation recipe
  • 6247736: 8256018: Adler32/CRC32/CRC32C missing reachabilityFence
  • 436019b: 8256166: [C2] Registers get confused on Big Endian after 8221404

Your commit was automatically rebased without conflicts.

Pushed as commit 96e0261.

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

@albertnetymk
Copy link
Member

@albertnetymk albertnetymk commented Nov 11, 2020

With getInactive, is the null check, if (finalizee != null still needed?

@rkennke
Copy link
Contributor Author

@rkennke rkennke commented Nov 11, 2020

With getInactive, is the null check, if (finalizee != null still needed?

Good point! I don't think it is. The GC should not clean the referent before we finalized it (or not at all), and no other code is clearing it either. Unfortunately, I just integrated this PR, do you think it'd be worth to open a follow-up issue?

* null, and would subsequently not finalize the referent/finalizee.
*/
T getInactive() {
return this.referent;
Copy link
Member

@mlchung mlchung Nov 11, 2020

Choose a reason for hiding this comment

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

It would be good to add assert this instanceof FinalReference to make this assertion clear.

Copy link
Contributor Author

@rkennke rkennke Nov 11, 2020

Choose a reason for hiding this comment

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

Right. And maybe also assert that the Reference is indeed inactive. I'll open a new issue for that (I already integrated this one, sorry I kinda jumped the gun a little.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core-libs hotspot-gc integrated
4 participants