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

[Doug Simon]

(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