G1 question: concurrent cleaning of dirty cards
martin.doerr at sap.com
Fri May 17 08:29:39 UTC 2013
we have a question about the interaction between G1 post barriers and the refinement thread's concurrent dirty card cleaning.
The case in which the G1 post barrier sees a clean card is obviously not problematic, because it will add an entry in a dirty card queue.
However, in case in which the Java thread (mutator thread) sees the card already dirtied, it won't enqueue the card again. Which is safe as long as its stored oop (1) is seen and processed (3') by the parallel refinement after having cleaned the card (1'):
Java Thread (mutator) Refinement Thread (G1RemSet::concurrentRefineOneCard_impl calls oops_on_card_seq_iterate_careful)
( StoreLoad required here ?)
(2') StoreLoad barrier
So the refinement thread seems to rely on getting the oop which was written BEFORE the (2) load(card==dirty) was observed.
We wonder how this ordering is guaranteed? There are no StoreLoad barriers in the Java Thread's path. (StoreLoad ordering needs explicit barriers even on TSO platforms.)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-gc-dev