Question about GC barriers work (precise vs. imprecise)

[Tom Rodriguez]

> So the question is:
> - Given a WriteNode, for example (we might need to get the same info out
> of a ReadNode, LoweredAtomicReadAndWriteNode, AbstractCompareAndSwapNode
> or ArrayRangeWrite), can we figure out:
> - if the element being written is object or primitive

The JavaKind of the value being written tells you that. 
ValueNode.getStackKind() == JavaKind,Object for example.

> - if the field is an array or object field

Generally that information drives the setting of the BarrierType field. 
In almost all cases we know the correct answer by construction except in 
things like Unsafe operations where you might not have the type of the 
underlying object.  In those cases it's always safe to emit a precise 
barrier with HotSpot.  I don't know how that would be handled in other 
GCs.  Maybe the barrier enum needs to be None, Array, Field, Either and 
let the GC backend decide what to emit for the Either case?

> - if it's an initializing store or not

The Graal LocationIdentity class roughly represents our alias classes in 
the compiler and we have separate subclasses for Java fields and Java 
arrays along with other special case memory locations like C++ memory 
locations and the mark word plus others.  Additionally there's a 
INIT_LOCATION which represents newly allocated memory.  So you can check 
for that value.

> 
> ?
> 
> If this is currently not possible, I'd suggest two ways out of it:
> - Instead of carrying a BarrierType, encode all the information we need
> in some sort of GC agnostic GCAccessInfo, and figure out the exact
> barriers from that info

We could do that as well.  We would need some sort of provider that's 
available throughout the compiler to produce this information which 
might be overkill.  It seems like most of the information you need is 
available apart from the ambiguity in the current BarrierType for the 
precise case.  So if you can make that work it seems simpler to me.

> - Do like it's done in C2, C1 and hotspot interpreter, and ask the
> BarrierSet implementation to generate the actual access nodes *plus* the
> required barriers, during parsing

Capturing information during parsing is fine but I don't think we want 
to introduce those nodes early like C2 does.  We really want the barrier 
lowering to be done in WriteBarrierAdditionPhase so that the barrier 
code doesn't bloat the graph early in the compilation.

tom

> 
> Or maybe you guys have other/better ideas too?
> 
> What do you think?
> 
> Thanks & best regards,
> Roman
> 
>