Query regarding ordering in G1 post-write barrier

Thomas Schatzl thomas.schatzl at oracle.com
Mon Jul 20 13:44:47 UTC 2015


On Mon, 2015-07-20 at 14:22 +0100, Andrew Dinn wrote:
> $SUBJECT is in relation to the following code in method
> GraphKit::g1_mark_card()
> The StoreCM is 'ordered' i.e. it is flagged with mem ordering type =
> mo_release. However, the latter pair of instructions are 'unordered'. I
> looked at the G1 code which processes dirty queues and could not make
> head nor tail (oops, apologies for any undercurrent of a pun) of when it
> gets run.
> So, the question is this: does dirty queue processing only happen in GC
> threads when mutators cannot be writing them? or is there a need on
> non-TCO architectures to maintain some sort of consistency in the queue
> update via by serializing these writes?

Mutator threads and refinement threads are running concurrently. While
GC threads are working on the queues, mutators never run.

While refinement threads may set and clear the mark on the card table
concurrently because they were processing that card concurrently, there
is afaik sufficient synchronization between the card mark and the
reference write on that in the code (in
HeapRegion::oops_on_card_seq_iterate_careful()). The refinement threads
do not modify or assume any value of the buffer's members, so there does
not seem to be a need in the write barrier for further synchronization.

Refinement threads and mutator threads take a lock to push and pop a new
buffer (in SharedRuntime::g1_wb_post) to and from the buffer queue,
which means that there is at least one cmpxchg/synchronization between
the thread pushing the buffer and the refinement thread popping it.

Which should be sufficient that the buffer's members are visible to all
participants of this exchange.

Note that GC threads do access the buffers, but there is a safepointing
operation between the accesses.

That should cover the eventualities. You can now tell us where I am
wrong :)

> Hmm, ok that seems to be two questions. Let's make that a starter for 10
> and a bonus for whoever buzzes fastest.

Not sure if that answers your question. So what did I win? :-)


More information about the hotspot-compiler-dev mailing list