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

[Gilles Duboscq]

On 19/02/2019 19:54, Tom Rodriguez wrote:
>>> 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).
> 
> That's what I was thinking at first, but doesn't Truffle use ObjectLocationIdentity for array accesses?  And INIT_LOCATION is used for both array and field.  So I don't think LocationIdentity can be used here.  The existing BarrierType provides a more reliable indicator I think.

The question for Roman is:
- If it's an initialization, do you care about array vs field?
- How strict does array vs field need to be? For example if we answer field but it's actually an array at runtime, is it a problem?

I imagine it's not really a problem otherwise it's quite hard to do the right barrier on unsafe accesses. In turn, that would mean that the truffle ObjectLocationIdentity is not an issue (an we may later be able to modify `isArrayLocation` to give a tighter answer).

 Gilles

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