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

8258242: Type profile pollution occurs when memory segments of different kinds are used #19

Closed
wants to merge 2 commits into from

Conversation

@mcimadamore
Copy link
Contributor

@mcimadamore mcimadamore commented Dec 14, 2020

This patch fixes a problem with type profile pollution when segments of different kinds are used on the same memory access var handle, or on the same MemoryAccess static method.

In principle, argument profiling should kick in for VarHandles and MethodHandles, and that should be enough at least to avoid pollution when using var handles directly. In reality, this is not the case; as Vlad discovered after relatively intense debugging session (thanks!), the VarHandle implementation code has to cast the incoming segment to the MemorySegmentProxy internal interface. This creates problems for C2, as concrete segment implementations have two interface types: MemorySegment and the internal MemorySegmentProxy class. Side casts from one to the other are not supported well, and can cause loss of type profiling infomation.

To solve this problem we realized, in hindisght, that MemorySegmentProxy didn't really needed to be an interface and that it could easily be converted to an abstract class. Alone this solves 50% of the issues, since that makes direct var handle access robust to pollution issues. The remaining problems (using accessors in MemoryAccess class) can be addressed the usual way, by adding argument type profiling for the methods in that class (similarly to what we've done for ScopedMemoryAccess).

Here are some numbers before the patch:

Benchmark                                            Mode  Cnt   Score   Error  Units
LoopOverPollutedSegments.heap_segment_floats_VH      avgt   30  11.535 ? 0.039  ms/op
LoopOverPollutedSegments.heap_segment_floats_static  avgt   30  10.860 ? 0.162  ms/op
LoopOverPollutedSegments.heap_segment_ints_VH        avgt   30  11.479 ? 0.202  ms/op
LoopOverPollutedSegments.heap_segment_ints_static    avgt   30  10.562 ? 0.027  ms/op
LoopOverPollutedSegments.heap_unsafe                 avgt   30   0.240 ? 0.003  ms/op
LoopOverPollutedSegments.native_segment_VH           avgt   30  11.603 ? 0.154  ms/op
LoopOverPollutedSegments.native_segment_static       avgt   30  10.613 ? 0.128  ms/op
LoopOverPollutedSegments.native_unsafe               avgt   30   0.243 ? 0.003  ms/op

As you can see there is quite a big difference between unsafe access and all the other modes. Here are the results after the patch:

Benchmark                                            Mode  Cnt  Score   Error  Units
LoopOverPollutedSegments.heap_segment_floats_VH      avgt   30  0.244 ? 0.002  ms/op
LoopOverPollutedSegments.heap_segment_floats_static  avgt   30  0.301 ? 0.001  ms/op
LoopOverPollutedSegments.heap_segment_ints_VH        avgt   30  0.245 ? 0.003  ms/op
LoopOverPollutedSegments.heap_segment_ints_static    avgt   30  0.302 ? 0.004  ms/op
LoopOverPollutedSegments.heap_unsafe                 avgt   30  0.242 ? 0.003  ms/op
LoopOverPollutedSegments.native_segment_VH           avgt   30  0.246 ? 0.004  ms/op
LoopOverPollutedSegments.native_segment_static       avgt   30  0.295 ? 0.006  ms/op
LoopOverPollutedSegments.native_unsafe               avgt   30  0.245 ? 0.003  ms/op

That is, the situation is back to normal. Thanks to @JornVernee and @iwanowww for the help!


Progress

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

Issue

  • JDK-8258242: Type profile pollution occurs when memory segments of different kinds are used

Reviewers

Download

$ git fetch https://git.openjdk.java.net/jdk16 pull/19/head:pull/19
$ git checkout pull/19

* turn MemorySegmentProxy into an abstract class, to avoid loss of type profiling info
* Add benchmark
@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Dec 14, 2020

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

Loading

@openjdk openjdk bot added the rfr label Dec 14, 2020
@openjdk
Copy link

@openjdk openjdk bot commented Dec 14, 2020

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

  • core-libs
  • hotspot
  • security

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.

Loading

@mlbridge
Copy link

@mlbridge mlbridge bot commented Dec 14, 2020

Webrevs

Loading

Copy link

@iwanowww iwanowww left a comment

Looks good.

Loading

@openjdk
Copy link

@openjdk openjdk bot commented Dec 14, 2020

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

8258242: Type profile pollution occurs when memory segments of different kinds are used

Reviewed-by: vlivanov, redestad

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 no new commits pushed to the master branch. If another commit should be pushed before you perform the /integrate command, your PR will be automatically rebased. If you prefer to avoid any potential 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.

Loading

@openjdk openjdk bot added the ready label Dec 14, 2020
cl4es
cl4es approved these changes Dec 14, 2020
@mcimadamore
Copy link
Contributor Author

@mcimadamore mcimadamore commented Dec 15, 2020

/integrate

Loading

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

@openjdk openjdk bot commented Dec 15, 2020

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

  • 09e8675: 8255381: com/sun/jdi/EATests.java should not suspend graal threads

Your commit was automatically rebased without conflicts.

Pushed as commit 7ff9c85.

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

Loading

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
3 participants