[concurrency-interest] Fences and card tables

Gil Tene gil at azulsystems.com
Fri Aug 28 11:01:17 EDT 2015


The compiler doesn't treat safepoint polling opportunities as a fence at all (at least in the normal store & load ordering sense). Unless otherwise prevented, loads and stores are free to float across safepoint polling opportunities even when they are preceded or followed by the various fences (acquire/release/StoreStore/etc.).

While an actually taken safepoint poll does apply a full fence from the CPU's point of view the ref_store in the example below could have floated back across that safepoint and show up (in the CPUs instruction stream) before the safepoint poll was made (if all that was ordering it was the StoreStore in the example).

To safely avoid separating a ref store and its related card table store with a safepoint, additional "safepoint related fencing" capabilities are needed in the JIT. Note that these never apply to program semantics, and only to the JVM's internal implementation of bytecode sub-parts. So only Runtime and JIT implementers need to be aware of them.

The simplest way to handle this is/was for JITs to consider the entire sequence (ref store and card mark store) to be inseparable from scheduling point of view. Often by using a single IR node to represent the combo. But as scheduling benefits for the two parts are sought (and there are some) and the sequence is split into separate IR nodes, scheduling rules relating to those nodes' ability to cross safepoints apply. 

One way to achieve this ordering restriction is for the JIT to treat all safepoint polling opportunities as if they both consume and potentially modify all references stored to memory, as well as all cards stored to memory. This then prevents them from being reordered with either regardless of fences. Unfortunately, this strong approach prevents some useful optimizations. As you weaken the restriction (allowing e.g. hoisting repeated reference loads out of loops that have safepoints in their back edge), stating the actual ordering needed for things like card marks becomes more specific.

Sent from Gil's iPhone

> On Aug 28, 2015, at 1:13 AM, Andrew Haley <aph at redhat.com> wrote:
> 
>> On 08/28/2015 01:27 AM, Gil Tene wrote:
>> For two specific "bad thing" examples:
>> 
>> 1) Imagine the sequence was: ref_store; StoreStore_fence; card_store;
>> 
>> The ref_store is free to float back across a previous safepoint polling opportunity.
> 
> I don't see how.  Any safepoint poll which actually traps is a full barrier; if
> it doesn't trap it doesn't matter.  I must be missing something...
> 
> Andrew.
> 



More information about the Concurrency-interest mailing list