RFR: 8195972: Refactor oops in JNI to use the Access API

[Kim Barrett]

> On Mar 29, 2018, at 9:54 AM, Erik Österlund <erik.osterlund at oracle.com> wrote:
> 
> Hi Kim,
> 
> On 2018-03-29 01:35, Kim Barrett wrote:
>>> On Mar 28, 2018, at 9:40 AM, Erik Österlund <erik.osterlund at oracle.com> wrote:
>> Even those (temporary) costs could be mitigated if we weren't forced
>> to use the overly generic IN_CONCURRENT_ROOT decorator, and could
>> instead provide more precise information to the GC-specific backends
>> (e.g. something like IN_JNI_GLOBAL_ROOT), letting each GC defer its
>> extra barrier work until the changes to get the pause-time benefits
>> are being made.
> 
> Sure. But I'd like to avoid overly specific decorators that describe the exact root being accessed, rather than its semantic properties, unless there are very compelling reasons to do so.

I understand that.  The problems with that are (1) (I think) the semantics are pretty
non-obvious to someone not a GC expert, while I thought part of the point of the
GC interface (including Access) is to help non-GC folks to write “runtime” code that
will correctly interact with the GC, and (2) whether those semantics apply may vary
even between GCs that do (some) work concurrently.  Maybe we won’t have any
really interesting non-temporary cases of the latter?  Like I expect this one to be
temporary.  And maybe there will be very few uses of this decorator, and we’ve
already identified (nearly) all of them?

>> I'd forgotten about jniFastGetField.  [,,,]  Any idea how important an optimization
>> jniFastGetField might be?  How bad would it be to turn it off for ZGC?
> 
> I have no idea what the cost would be of turning it off. But I feel more compelled to fix it so that we do not have to turn it off. Should not be impossible, but can be done outside of this RFE.

Fixing it should be better.  I was just wondering if we have any idea how important
these optimizations really are.  On the surface they look like they could be fairly
important, but...

>> And there are two other pre-existing uses of IN_CONCURRENT_ROOT, both
>> of which seem suspicious to me.
>> 
>> […]
> 
> Yes, that sounds like it should be fixed in separate RFEs.
> 
> Your JNI handle changes look good.
> 
> Thanks,
> /Erik

Thanks.

I’ll file those additional RFEs (though maybe there is already one for accessorizing OopHandle).
And I will try to get a review of 8199417 done today.