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

mcimadamore · 2022-01-05T16:59:30Z

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

Paul Sandoz (@PaulSandoz - Reviewer) ⚠️ Review applies to 04a1e9f
Jorn Vernee (@JornVernee - Reviewer)

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 · 2022-01-05T17:00:06Z

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

mcimadamore · 2022-01-05T17:00:43Z

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java

-        } catch (ScopedMemoryAccess.Scope.ScopedAccessError ex) {
-            throw new IllegalStateException("This segment is already closed");
-        }
+        scope.checkValidStateSlow();


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

openjdk · 2022-01-05T17:02:10Z

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

mlbridge · 2022-01-05T17:07:33Z

Webrevs

PaulSandoz · 2022-01-05T17:23:41Z

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ResourceScopeImpl.java

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


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() { ... } }

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

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?)

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 · 2022-01-05T18:47:47Z

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

JornVernee · 2022-01-06T12:15:33Z

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ConfinedScope.java

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


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

Forgot to remove - well spotted

* Reuse `state` variable for confined lock count

mcimadamore · 2022-01-07T13:40:04Z

/integrate

openjdk · 2022-01-07T13:41:42Z

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 · 2022-01-07T13:41:58Z

@mcimadamore Pushed as commit d65c665.

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

Initial push

c608295

mcimadamore reviewed Jan 5, 2022

View changes

openjdk bot added the rfr label Jan 5, 2022

openjdk bot added nio core-libs labels Jan 5, 2022

PaulSandoz reviewed Jan 5, 2022

View changes

Use owner field instead of accessor in checkValidStateSlow

04a1e9f

PaulSandoz approved these changes Jan 5, 2022

View changes

openjdk bot added the ready label Jan 5, 2022

JornVernee approved these changes Jan 6, 2022

View changes

* Drop redundant owner field

e0bbc8f

* Reuse `state` variable for confined lock count

JornVernee approved these changes Jan 7, 2022

View changes

openjdk bot added the integrated label Jan 7, 2022

openjdk bot closed this Jan 7, 2022

openjdk bot removed ready rfr labels Jan 7, 2022

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

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

mcimadamore commented Jan 5, 2022 •

edited by openjdk[bot] bot

bridgekeeper bot commented Jan 5, 2022

mcimadamore Jan 5, 2022

openjdk bot commented Jan 5, 2022

mlbridge bot commented Jan 5, 2022 •

edited

PaulSandoz Jan 5, 2022

mcimadamore Jan 5, 2022

PaulSandoz Jan 5, 2022

mcimadamore Jan 5, 2022

openjdk bot commented Jan 5, 2022 •

edited

JornVernee Jan 6, 2022

mcimadamore Jan 6, 2022

mcimadamore commented Jan 7, 2022

openjdk bot commented Jan 7, 2022

openjdk bot commented Jan 7, 2022

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

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

Conversation

mcimadamore commented Jan 5, 2022 • edited by openjdk[bot] bot

Progress

Issue

Reviewers

Reviewing

bridgekeeper bot commented Jan 5, 2022

mcimadamore Jan 5, 2022

Choose a reason for hiding this comment

openjdk bot commented Jan 5, 2022

mlbridge bot commented Jan 5, 2022 • edited

Webrevs

PaulSandoz Jan 5, 2022

Choose a reason for hiding this comment

mcimadamore Jan 5, 2022

Choose a reason for hiding this comment

PaulSandoz Jan 5, 2022

Choose a reason for hiding this comment

mcimadamore Jan 5, 2022

Choose a reason for hiding this comment

openjdk bot commented Jan 5, 2022 • edited

JornVernee Jan 6, 2022

Choose a reason for hiding this comment

mcimadamore Jan 6, 2022

Choose a reason for hiding this comment

mcimadamore commented Jan 7, 2022

openjdk bot commented Jan 7, 2022

openjdk bot commented Jan 7, 2022

mcimadamore commented Jan 5, 2022 •

edited by openjdk[bot] bot

mlbridge bot commented Jan 5, 2022 •

edited

openjdk bot commented Jan 5, 2022 •

edited