RFR: 8189871: Refactor GC barriers to use declarative semantics

[coleen.phillimore at oracle.com]

On 11/16/17 8:28 PM, Kim Barrett wrote:
>> On Nov 16, 2017, at 6:48 PM, coleen.phillimore at oracle.com wrote:
>>>>> We were also trying to figure out how the runtime would know whether to use IN_CONCURRENT_ROOT vs IN_ROOT decorator, since it probably varies for GCs.  And requires runtime code to know whether the root is scanned concurrently or not, which we don't know.
>>>>>
>>>> The Access API needs to know whether this is scanned concurrently or not (because we *have* to perform different barriers then). So whatever data structure the access is performed on, needs to make sure this is known.
>>> The person writing the access call cannot be expected to accurately
>>> know whether or not the associated location will be scanned
>>> concurrently.  Even ignoring some of those people not being GC
>>> experts, there is the problem that the answer might not be knowable
>>> until runtime, because it may (will) depend on which GC is selected,
>>> and possibly other considerations as well.
>> So, yeah, this is pretty confusing.  The RootAccess() assumes that using it will have a barrier because it's *possibly* scanned concurrently by the GC.  The roots that are scanned at a safepoint, like the thread stacks, can't one assume that they do not need an access decoration?  I can't imagine that you are going to add the Access API to the interpreter code for the bytecodes that push objects to the stack for example.
> RootAccess uses the IN_ROOT decorator, which seems to be the one to use for locations which are *always* scanned at a safepoint.
>
>> So I have this in OopHandle::resolve() which is eventually going to be scanned concurrently by some GCs but probably not others:
>>
>> oop OopHandle::resolve() const {
>>    return _obj == NULL ? NULL : RootAccess<>(_obj);
>> }
>>
>> And a WeakHandle from the vm perspective, will have access like:
>>
>> oop WeakHandle::resolve() const {
>>    oop obj = RootAccess<ON_PHANTOM_OOP_REF>(_obj);
>>    // does this:  ensure_obj_alive(obj);
>>    return obj;
>> }
>>
>> Nowhere do I know or care that these are accessed concurrently, or rather I assume it could be accessed concurrently so not taking any chances.  I don't think we want a different decorator.
> Assuming IN_CONCURRENT_ROOT is conservative, and works for both “scanned at a safepoint” and “scanned concurrently”, then I think those resolve functions should be using Access<IN_CONCURRENT_ROOT …>(_obj).

Hm, ok.   I wish it could use the default, but I can see avoiding any 
sort of barriers for off heap objects that are scanned during root scanning.

thanks,
Coleen