Read Barrier for CompareAndSwapObject #1573
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
amicic
force-pushed
the
master
branch
2 times, most recently
from
3a6313d to
d516fb0
Compare
|
Jenkins test sanity |
| protectIfVolatileBefore(vmThread, true, false, false); | ||
|
|
||
| /* One of these conditions will evaluate to true at compile time based on whether fields are 32 or 64 bits */ | ||
| if (sizeof(fj9object_t) == sizeof(UDATA)) { |
There was a problem hiding this comment.
Could this just become a compile time check with a #error in the else?
#if (sizeof(fj9object) == sizeof(UDATA))
....
Not sure if sizeof gets evaluated at the right time though.
There was a problem hiding this comment.
I did not change this (it only got indented), but if we are to change, I believe it the cleanest is to rely on
#if defined (OMR_GC_COMPRESSED_POINTERS)
and then there is no need for error clause at all
There was a problem hiding this comment.
... or J9VM_GC_COMPRESSED_POINTERS?
There was a problem hiding this comment.
Replaced the check with J9VM_GC_COMPRESSED_POINTERS (and swapped the order of two lines)
Compare-And-Swap on object reference (like one used in sun/misc/Unsafe but also any other used internally by JVM), while primarily is a store operation, it is also an implicit read (it reads the existing value to be compared with a provided compare value, before the store itself), hence needs a read barrier. This change introduces the pre-read barrier in all VM/GC CompareAndSwapObject helpers, that is used in Evacuating read barrier triggered by the read value, used in Concurrent Scavenger. An interesting dilemma is which out of two pre operations (read and store) is to be executed first. Currently in OpenJ9, we do not have any collector that have both of them active at the same time, so the order ATM is not important. However, in theory (and it actually may happen later in OpenJ9), they could both be active. An example, for Gencon GC policy, is the same read barrier on reference value (Concurrent Scavenger) and Snap-Shot-At-The-Beginning store barrier (for concurrent global marking). Since read barrier can modify the value, and SATB cares about the value being overwritten, read barrier should go first to bring it up to date, before SATB evaluates it. On the other side, from SATB perspective, we do not care about the very original value of the field (even before read barrier modifies it), since it is an object being evacuated/collected and is not part of the Snapshot (it is the copy of that object that we want to be preserved as part of the Snapshot). Signed-off-by: Aleksandar Micic <amicic@ca.ibm.com>
charliegracie
approved these changes
Apr 3, 2018
|
@dmitripivkine you can merge at your leisure. |
fjeremic
added a commit
to fjeremic/openj9
that referenced
this pull request
May 23, 2018
Compare-And-Swap on object reference, while primarily is a store operation, it is also an implicit read (it reads the existing value to be compared with a provided compare value, before the store itself), hence needs a read barrier. This change is an extension of eclipse-openj9#1573 with JIT support. Signed-off-by: Filip Jeremic <fjeremic@ca.ibm.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Compare-And-Swap on object reference (like one used in sun/misc/Unsafe
but also any other used internally by JVM), while primarily is a store
operation, it is also an implicit read (it reads the existing value to
be compared with a provided compare value, before the store itself),
hence needs a read barrier.
This change introduces the pre-read barrier in all VM/GC
CompareAndSwapObject helpers, that is used in Evacuating read barrier
triggered by the read value, used in Concurrent Scavenger.
An interesting dilemma is which out of two pre operations (read and
store) is to be executed first. Currently in OpenJ9, we do not have any
collector that have both of them active at the same time, so the order
ATM is not important.
However, in theory (and it actually may happen later in OpenJ9), they
could both be active. An example, for Gencon GC policy, is the same read
barrier on reference value (Concurrent Scavenger) and
Snap-Shot-At-The-Beginning store barrier (for concurrent global
marking). Since read barrier can modify the value, and SATB cares about
the value being overwritten, read barrier should go first to bring it up
to date, before SATB evaluates it. On the other side, from SATB
perspective, we do not care about the very original value of the field
(even before read barrier modifies it), since it is an object being
evacuated/collected and is not part of the Snapshot (it is the copy of
that object that we want to be preserved as part of the Snapshot).
Signed-off-by: Aleksandar Micic amicic@ca.ibm.com