RFR(M) JDK-8014555: G1: Memory ordering problem with Conc refinement and card marking
mikael.gerdin at oracle.com
Wed Oct 2 05:28:54 PDT 2013
Please review my fix for the issue discussed in the "G1 question:
concurrent cleaning of dirty cards" thread on the hotspot-gc-dev mailing
I'd like someone from the compiler (and runtime? the interpreter uses
macroAssembler_*, right?) teams to at least look at the changes to:
G1 has a race where the concurrent refinement thread may miss object
references in a dirty card.
The problem arises if the CPU re-orders the load of the old card value
(which G1 checks to determine if it can skip the barrier)
before the store to the actual object.
If that occurs the concurrent refinement thread may have set the card to
"clean" and proceeded to scan the card but the java thread may have seen
the "dirty" value and skipped the post barrier.
* Add a memory fence between the store to a java object and the reading
of the previous card value.
* Modify the code for handling young regions so that all writes to young
regions can skip the fence (since it will never be needed for such
writes). This introduces a new value in the card table for G1 which
indicates a young region.
* This fix has a negative throughput performance impact of 1-1.5%
(tested on x86-AMD x86-Intel and SPARC).
* We may want to try to get rid of this race at some point by
redesigning G1's post barrier but there is not enough time to do that
Performance numbers for x86 platforms can be seen here:
Unfortunately the JIRA issue is not externally visible, but the major
parts of the discussions about this are present in the mailing list
thread. The bug mostly contains my analysis of the crashes which seems
to have been caused by this bug.
Bug link: https://bugs.openjdk.java.net/browse/JDK-8014555
More information about the hotspot-dev