[graalvm-dev] Question about GC barriers work (precise vs. imprecise)

Gilles Duboscq gilles.m.duboscq at oracle.com
Tue Feb 19 10:15:56 PST 2019


Hi Roman,

I think that answering those 3 questions for all our writes should be feasible (oop? array? init?).

I don't think we want to generate the expanded access during parsing, that would go against the "gradual lowering" design.

I think it also makes sense to keep some knowledge about barriers in the compiler and not only have a blind lowering since some optimizations such as barrier elimination can be performed before expanding those barriers.

Regarding those questions:
- stamps/kinds of the written value should be enough to figure out if it's an oop read/write.
- location identity should be enough (or can be improved) to know if it's an array location or not (see NamedLocationIdentity#isArrayLocation).
- we also use a special location for initialization writes (see LocationIdentity#init).

Kind regards,
 Gilles


On 19/02/2019 13:51, Roman Kennke wrote:
> Hello,
> 
> I am currently working on a better GC barriers interface. You may have
> noticed my initial refactoring:
> 
> https://github.com/oracle/graal/pull/977
> 
> One thing that is missing is the notion of precise/imprecise barrier
> strength, which is currently dragged through WriteNode and some others.
> The problem that I see is that there semantic is fairly specific to the
> GCs/barriers that are currently implemented (card-table and G1). Other
> GCs, like ZGC and Shenandoah, have no use for such a notion, but may
> require other information.
> 
> As far as I can tell, the logic currently is:
> - If access is not for object fields/array-elements, barrierType is NONE
> - object field store -> barrierType == IMPRECISE
> - array element store -> barrierType == PRECISE
> 
> probably with the exception of initializing stores, which may or may not
> require barriers, depending on a runtime flag (usually not).
> 
> What I would like to achieve is that this information is not encoded at
> parse-time, but later inferred when the barriers get inserted (in
> WriteBarrierAdditionPhase), if possible.
> 
> 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
> - if the field is an array or object field
> - if it's an initializing store or not
> 
> ?
> 
> 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
> - 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
> 
> Or maybe you guys have other/better ideas too?
> 
> What do you think?
> 
> Thanks & best regards,
> Roman
> 
> 
> _______________________________________________
> GraalVM-Dev mailing list
> GraalVM-Dev at oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/graalvm-dev
> 



More information about the GraalVM-Dev mailing list