8279930: Synthetic cast causes generation of store barriers when using heap segments #97
8279930: Synthetic cast causes generation of store barriers when using heap segments #97
Conversation
|
@mcimadamore The following label will be automatically applied to this pull request:
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. |
Webrevs
|
|
||
OfByte(long offset, byte[] base, long length, int mask) { | ||
OfByte(long offset, Object base, long length, int mask) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible to retain the array type for the constructor?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, that should be harmless
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, no, sorry. If I sharpen the type, then dup
has to cast, so we go back to the original issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yes, i see. Maybe it's worth adding a general comment to the class doc of HeapMemorySegmentImpl
briefly explaining the reasons for use of Object
.
public void setup() { | ||
scope = ResourceScope.newConfinedScope(); | ||
nativeSegment = MemorySegment.allocateNative(ALLOC_SIZE, scope); | ||
heapSegment = MemorySegment.ofArray(new float[ELEM_SIZE]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The heap MemorySegment
wraps float[]
but is accessed as if int[]
, same bit size, but I suspect it was not intentional?
@mcimadamore This change now passes all automated pre-integration checks. After integration, the commit message for the final commit will be:
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 4 new commits pushed to the
Please see this link for an up-to-date comparison between the source branch of this pull request and the
|
/integrate |
Going to push as commit c6b0275.
Your commit was automatically rebased without conflicts. |
@mcimadamore Pushed as commit c6b0275. |
When looking at larger benchmarks, I noted a discrepancy between the performance of off-heap segments and on-heap segments. Looking at the assembly for the
MemorySegment::asSlice
method I could see some additional barriers in the off-heap case, but could not initially make sense of them. Vlad pointed me at G1 (in fact no such barrier was emitted when using a different GC, such as the serial GC, or ZGC), and later Erik narrowed the problem down to a failure in a C2 optimization to remove barriers around initializing stores. This problem was caused by a synthetic cast added by javac to a value (the base object) that initialized the newly created memory segment slice. Because of that case, C2 missed the store as an "initializing" one, and inserted additional barriers. This patch should make performance of on-heap segments a lot more reliable, especially when slicing is involved.Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk18 pull/97/head:pull/97
$ git checkout pull/97
Update a local copy of the PR:
$ git checkout pull/97
$ git pull https://git.openjdk.java.net/jdk18 pull/97/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 97
View PR using the GUI difftool:
$ git pr show -t 97
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk18/pull/97.diff