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

[Tom Rodriguez]

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

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
>