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

Doug Simon doug.simon at oracle.com
Tue Feb 19 18:49:52 UTC 2019

(moving conversation to graal-dev)

> Begin forwarded message:
> From: Gilles Duboscq <gilles.m.duboscq at oracle.com>
> Subject: Re: [graalvm-dev] Question about GC barriers work (precise vs. imprecise)
> Date: 19 February 2019 at 19:15:56 CET
> To: graalvm-dev at oss.oracle.com
> 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
> _______________________________________________
> GraalVM-Dev mailing list
> GraalVM-Dev at oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/graalvm-dev

More information about the graal-dev mailing list