Skip to content
This repository has been archived by the owner. It is now read-only.

8279527: Dereferencing segments backed by different scopes leads to pollution #82

Closed
wants to merge 3 commits into from

Conversation

mcimadamore
Copy link
Contributor

@mcimadamore mcimadamore commented Jan 5, 2022

This patch fixes a performance issue when dereferencing memory segments backed by different kinds of scopes. When looking at inline traces, I found that one of our benchmark, namely LoopOverPollutedSegment was already hitting the ceiling of the bimorphic inline cache, specifically when checking liveness of the segment scope in the memory access hotpath (ResourceScopeImpl::checkValidState). The benchmark only used segments backed by confined and global scope. I then added (in the initialization "polluting" loop) segments backed by a shared scope, and then the benchmark numbers started to look as follows:

Benchmark                                              Mode  Cnt  Score   Error  Units
LoopOverPollutedSegments.heap_segment_floats_VH        avgt   30  7.004 ? 0.089  ms/op
LoopOverPollutedSegments.heap_segment_floats_instance  avgt   30  7.159 ? 0.016  ms/op
LoopOverPollutedSegments.heap_segment_ints_VH          avgt   30  7.017 ? 0.110  ms/op
LoopOverPollutedSegments.heap_segment_ints_instance    avgt   30  7.175 ? 0.048  ms/op
LoopOverPollutedSegments.heap_unsafe                   avgt   30  0.243 ? 0.004  ms/op
LoopOverPollutedSegments.native_segment_VH             avgt   30  7.366 ? 0.036  ms/op
LoopOverPollutedSegments.native_segment_instance       avgt   30  7.305 ? 0.098  ms/op
LoopOverPollutedSegments.native_unsafe                 avgt   30  0.238 ? 0.002  ms/op

That is, since now we have three different kinds of scopes (confined, shared and global), the call to the liveness check can no longer be inlined. One solution could be, as we do for the base accessor, to add a scope accessor to all memory segment implementation classes. But doing so only works ok for heap segments (for which the scope accessor just returns the global scope constants). For native segments, we're still megamorphic (as a native segment can be backed by all kinds of scopes).

In the end, it turned out to be much simpler to just make the liveness check monomorphic, since there's so much sharing between the code paths already. With that change, numbers of the tweaked benchmark go back to normal:

Benchmark                                              Mode  Cnt  Score   Error  Units
LoopOverPollutedSegments.heap_segment_floats_VH        avgt   30  0.241 ? 0.003  ms/op
LoopOverPollutedSegments.heap_segment_floats_instance  avgt   30  0.244 ? 0.003  ms/op
LoopOverPollutedSegments.heap_segment_ints_VH          avgt   30  0.242 ? 0.003  ms/op
LoopOverPollutedSegments.heap_segment_ints_instance    avgt   30  0.248 ? 0.001  ms/op
LoopOverPollutedSegments.heap_unsafe                   avgt   30  0.247 ? 0.013  ms/op
LoopOverPollutedSegments.native_segment_VH             avgt   30  0.245 ? 0.004  ms/op
LoopOverPollutedSegments.native_segment_instance       avgt   30  0.245 ? 0.001  ms/op
LoopOverPollutedSegments.native_unsafe                 avgt   30  0.247 ? 0.005  ms/op

Note that this patch tidies up a bit the usage of checkValidState vs. checkValidStateSlow. The former should only really be used in the hot path, while the latter is a more general routine which should be used in non-performance critical code. Making checkValidState monomorphic caused the ScopeAccessError to be generated in more places, so I needed to either update the usage to use the safer checkValidStateSlow (where possible) or, (in Buffer and ConfinedScope) just add extra wrapping.


Progress

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

Issue

  • JDK-8279527: Dereferencing segments backed by different scopes leads to pollution

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk18 pull/82/head:pull/82
$ git checkout pull/82

Update a local copy of the PR:
$ git checkout pull/82
$ git pull https://git.openjdk.java.net/jdk18 pull/82/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 82

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk18/pull/82.diff

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Jan 5, 2022

👋 Welcome back mcimadamore! 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.

} catch (ScopedMemoryAccess.Scope.ScopedAccessError ex) {
throw new IllegalStateException("This segment is already closed");
}
scope.checkValidStateSlow();
Copy link
Contributor Author

@mcimadamore mcimadamore Jan 5, 2022

Choose a reason for hiding this comment

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

Not to be confused with ResourceScope::checkValidState - this method is only really used by other non-performance critical code around AbstractMemorySegmentImpl.

@openjdk openjdk bot added the rfr label Jan 5, 2022
@openjdk
Copy link

@openjdk openjdk bot commented Jan 5, 2022

@mcimadamore The following labels will be automatically applied to this pull request:

  • core-libs
  • nio

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

@openjdk openjdk bot added nio core-libs labels Jan 5, 2022
@mlbridge
Copy link

@mlbridge mlbridge bot commented Jan 5, 2022

Webrevs

public abstract void checkValidState();
@ForceInline
public final void checkValidState() {
if (owner != null && owner != Thread.currentThread()) {
Copy link
Member

@PaulSandoz PaulSandoz Jan 5, 2022

Choose a reason for hiding this comment

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

For consistency we could change code checkValidStateSlow to refer directly to owner.

It would be satisfying, but I don't know if it's possible, to compose checkValidStateSlow from checkValidState e.g.

public final checkValidStateSlow() {
    checkValidState();
    if (!isAlive() { ... }
}

Copy link
Contributor Author

@mcimadamore mcimadamore Jan 5, 2022

Choose a reason for hiding this comment

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

I'll change use of owner. It's not really possible to write checkValidStateSlow in terms of checkValidState, because the latter does a plain read of the state, whereas the former does a volatile read. Reusing one from the other would result in two reads (a plain and a volatile).

Copy link
Member

@PaulSandoz PaulSandoz Jan 5, 2022

Choose a reason for hiding this comment

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

Ok. My thought was that since this is slow two reads do not matter, but i did not reason fully about the concurrent implications (if the fast alive check returns false, the slow alive check can still return true so that seems good, if the fast check returns true i was presume the slow alive check would also be true, given the way state changes monotonically?)

Copy link
Contributor Author

@mcimadamore mcimadamore Jan 5, 2022

Choose a reason for hiding this comment

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

If we're ok with a redundant plain read, then I don't think there are issues. You just do two reads, and the latter (the volatile one) is the one that counts. I don't think we can rely much on dependencies between what the plain read and what the volatile read will see. The state is updated in both direction (for shared segments) e.g. we can go from ALIVE to CLOSING then back to ALIVE. Or we could go from ALIVE to CLOSING to CLOSE.

That said, I guess my main reservation for writing one routine on top of the other is that we really want checkValidState to be only used in critical hot paths. It has a non-volatile semantics and an exception handling which only really makes sense when combined with ScopedMemoryAccess - for this reason, using it as an internal building primitive didn't seem to me as a great idea.

@openjdk
Copy link

@openjdk openjdk bot commented Jan 5, 2022

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

8279527: Dereferencing segments backed by different scopes leads to pollution

Reviewed-by: psandoz, jvernee

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:

  • 967ef0c: 8278020: ~13% variation in Renaissance-Scrabble
  • 7c792f2: 8279333: Some JFR tests do not accept 'GCLocker Initiated GC' as a valid GC Cause
  • 564c8c6: 8279529: ProblemList java/nio/channels/DatagramChannel/ManySourcesAndTargets.java on macosx-aarch64
  • 590fa9d: 8278612: [macos] test/jdk/java/awt/dnd/RemoveDropTargetCrashTest crashes with VoiceOver on macOS
  • 5cd9515: 8279525: ProblemList java/awt/GraphicsDevice/CheckDisplayModes.java on macosx-aarch64

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 Jan 5, 2022
@@ -39,7 +40,6 @@
*/
final class ConfinedScope extends ResourceScopeImpl {

private boolean closed; // = false
private int lockCount = 0;
private int asyncReleaseCount = 0;
private final Thread owner;
Copy link
Member

@JornVernee JornVernee Jan 6, 2022

Choose a reason for hiding this comment

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

Is this owner field still needed now that the super class also has it?

Copy link
Contributor Author

@mcimadamore mcimadamore Jan 6, 2022

Choose a reason for hiding this comment

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

Forgot to remove - well spotted

* Reuse `state` variable for confined lock count
@mcimadamore
Copy link
Contributor Author

@mcimadamore mcimadamore commented Jan 7, 2022

/integrate

@openjdk
Copy link

@openjdk openjdk bot commented Jan 7, 2022

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

  • 967ef0c: 8278020: ~13% variation in Renaissance-Scrabble
  • 7c792f2: 8279333: Some JFR tests do not accept 'GCLocker Initiated GC' as a valid GC Cause
  • 564c8c6: 8279529: ProblemList java/nio/channels/DatagramChannel/ManySourcesAndTargets.java on macosx-aarch64
  • 590fa9d: 8278612: [macos] test/jdk/java/awt/dnd/RemoveDropTargetCrashTest crashes with VoiceOver on macOS
  • 5cd9515: 8279525: ProblemList java/awt/GraphicsDevice/CheckDisplayModes.java on macosx-aarch64

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated label Jan 7, 2022
@openjdk openjdk bot closed this Jan 7, 2022
@openjdk openjdk bot removed ready rfr labels Jan 7, 2022
@openjdk
Copy link

@openjdk openjdk bot commented Jan 7, 2022

@mcimadamore Pushed as commit d65c665.

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
core-libs integrated nio
3 participants