Question about GC barriers work (precise vs. imprecise)
Roman Kennke
rkennke at redhat.com
Tue Feb 19 15:34:47 UTC 2019
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
More information about the graal-dev
mailing list