RFR: 8189871: Refactor GC barriers to use declarative semantics

[Kim Barrett]

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