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

[Erik Österlund]

Hi Kim,

I noticed that jobjects are now IN_CONCURRENT_ROOT in this patch. I 
wonder if this is the right time to upgrade them to IN_CONCURRENT_ROOT. 
Until there is at least one GC that actually scans these concurrently, 
this will only impose extra overheads (unnecessary G1 SATB-enqueue 
barriers on the store required to release jobjects) with no obvious gains.

The platform specific code needs to go along with this. I have a patch 
out to generalize interpreter code. In there, I am treating resolve 
jobject as a normal strong root. That would probably need to change. It 
is also troubling that jniFastGetField shoots raw loads into (hopefully) 
the heap, dodging all GC barriers, hoping that is okay. I wonder if 
starting to actually scan jobjects concurrently would force us to 
disable that optimization completely to be generally useful to all 
collectors. For example, an IN_CONCURRENT_ROOT load access for ZGC might 
require a slowpath. But in jniFastGetField, there is no frame, and hence 
any code that runs in there must not call anything in the runtime. 
Therefore, with IN_CONCURRENT_ROOT, it is not generally safe to use 
jniFastGetField, without doing... something about that code.

I would like to hear your thoughts about this. Perhaps the intention is 
just to take incremental steps towards being able to scan jobjects 
concurrently, and this is just the first step? Still, I would be 
interested to hear about what you think about the next steps. If we 
decide to go with IN_CONCURRENT_ROOT now already, then I should change 
my interpreter changes that are out for review to do the same so that we 
are consistent.

Otherwise, this looks great, and I am glad we finally have jni handles 
accessorized.

Thanks,
/Erik

On 2018-03-28 04:06, Kim Barrett wrote:
> Please review this change to the JNIHandles class to use the Access
> API.  The handle construction, deletion, and value access (via resolve
> &etc) are updated to use the Access API.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8195972
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8195972/open.00/
>
> Testing:
> local jck-runtime:vm/jni, tonga:nsk.jvmti
>    jtreg:fromTonga_nsk_coverage, jtreg:fromTonga_vm_runtime,
>    jtreg/runtime/jni
> Mach5 {jdk,hs}-tier{1,2,3}
> Mach5 hs-tier{5,6,7}-rt (tiers containing additional JNI tests)
>
>
>