-
Notifications
You must be signed in to change notification settings - Fork 728
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
Fix a missing allocationFence in process_java_lang_StringUTF16_toBytes() #18154
Fix a missing allocationFence in process_java_lang_StringUTF16_toBytes() #18154
Conversation
TR::TreeTop* newTT = treetop->insertAfter(TR::TreeTop::create(comp(), TR::Node::create(node, TR::treetop, 1, newCallNode))); | ||
// Insert the allocationFence after the arraycopy because the array can be allocated from the non-zeroed TLH | ||
// and therefore we need to make sure no other thread sees stale memory from the array element section. | ||
newTT->insertAfter(TR::TreeTop::create(comp(), allocationFence)); |
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.
Are allocation fence nodes generated in general after allocations on platforms such as X86, that do not have weak memory model ? I ask, because this insertion of an allocation fence seems to be unconditional in that sense, it will add it across platforms. This may not be incorrect, but I thought I'd check if it was unconventional (e.g. if no one code ever generated an allocation fence on non-weak ordered platforms) since that could lead to bugs in its own way (i.e. IL that is unexpectedly different).
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, good catch.. I had looked at this but somehow missed the cg()->getEnforceStoreOrder()
check in the genFence() routine used in ILGen. I added that check now.
When we transform a StringUTF16.toBytes() into a newarray and a call to String.decompressedArrayCopy(), we neglected to add an allocationFence. This change will introduce an allocationFence after the decompressedArrayCopy() call to ensure that all threads see the new contents of memory on weak memory coherency machines like POWER and AArch64. Signed-off-by: Kevin Langman <[email protected]>
a826d1a
to
c60f998
Compare
jenkins test sanity all jdk17 |
Looking through the failures I believe the root of the issues are: zLinux:
Linux x86_64:
Mac AArch64:
Linux PPC64le:
I haven't found any previous examples of these issues. Maybe we can try to retest since some of these failure seem to stem from a failure to reach machines. |
As I expected, |
The zlinux failure I see is cmdLineTester_criu_jitserverPostRestore_0 |
Right... I copied from the wrong browser tab when I got the z error text. So ya, ignore all I said about the z failure. |
jenkins test sanity amac jdk17 |
jenkins test sanity xlinux jdk17 |
jenkins test sanity amac jdk17 |
jenkins test sanity xlinux jdk17 |
There appear to be some infra issues preventing tests from passing. This change is conservative in that it adds a fence operation on weakly ordered platforms and so I don't expect any issues. I am merging it now with this reasoning. |
When we transform a StringUTF16.toBytes() into a newarray and a call to String.decompressedArrayCopy(), we neglected to add an allocationFence. This change will introduce an allocationFence after the decompressedArrayCopy() call to ensure that all threads see the new contents of memory on weak memory coherency machines like POWER and AArch64.