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

[Roman Kennke]

Hi Gilles,

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

Ok.

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

That is fine by me.

> 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.

Hmm, well. I'm ok with putting 'GC knowledge' in the graph at parse
time. What I would like to avoid is to put some kind of 'GC specific
knowledge' there, either explicitely (e.g. by using useG1GC..) or
implicitely (like the precise/imprecise stuff). For example, I think it
is ok to record 'this is an object store into an array' or 'this is a
primitive load of a field' etc. But I don't think 'this requires precise
barrier' is reasonable. It does not have meaning when constructing the
graph, except you know which GC you are talking to. (E.g. Shenandoah
doesn't have any such notions.)

> 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).

Ok, I will look into how far I can get with those, also referring to
Tom's reply.

The use-cases that I have in mind, Shenandoah and ZGC, need to insert
barriers after oop loads (and similar ops like CAS-obj). This means that
we need to disconnect the Load from its users, and insert a LoadBarrier
in between.

We also need to walk the graph and look at the inputs and outputs of the
oop-load to see if the barrier is actually needed. For example, if the
load only feeds into cmp-with-null(s), then we don't need the barrier
(and that is fairly frequent).

I'm assuming something like this would be possible in
WriteBarrierAdditionPhase? Otherwise you need to stop me and we need to
consider what to do.

Thanks for your advice!!

Roman


> 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
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
Url : http://oss.oracle.com/pipermail/graalvm-dev/attachments/20190219/e9908ba5/attachment-0001.bin