Question about GC barriers work (precise vs. imprecise)
tom.rodriguez at oracle.com
Tue Feb 19 18:41:27 UTC 2019
> 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.
> Or maybe you guys have other/better ideas too?
> What do you think?
> Thanks & best regards,
More information about the graal-dev