RFR: 8194312: Support parallel and concurrent JNI global handle processing

[David Holmes]

Hi Kim,

As per direct email I'm concerned about the impact the parallel 
processing may have on the ability of jni checking to work correctly. At 
the moment most (all?) checking is done IN_VM so that no safepoint can 
occur and the data being examined is 'stable'. I think it safe to say 
that jniCheck does not (and probably was not intended to) handle race 
conditions with other JNI using threads (ie thread B deletes a handle 
being checked in thread A). But the IN_VM ensures the check is not 
racing with the GC or other relevant safepoint VM ops. With these 
changes it is far from clear if such races have now been introduced and 
that jniCheck will become unreliable for the limited checking it does ?

Thanks,
David




On 3/01/2018 7:41 AM, Kim Barrett wrote:
> Please review this change to the implementation of JNI global and weak
> global handles, providing infrastructure for parallel and concurrent
> processing of such handles.
> 
> This change introduces OopStorage, a data structure for managing
> off-heap references to objects allocated in the Java heap. JNI global
> and weak global handles are reimplemented using OopStorage, rather
> than using JNIHandleBlock. (JNI local handles continue to use
> JNIHandleBlock; the lifetime management and concurrency issues are
> very different for local vs global handles.)
> 
> This change does not change any GCs to use the new parallel and
> concurrent capabilities, only laying the foundations for doing so.
> 
> Other uses of OopStorage are also being considered, in the context of
> runtime latency improvements for ZGC and other collectors. The idea is
> to change some (often weak) oop references in runtime data structures
> to OopStorage-managed handles, simplifying the GC processing and
> avoiding (potentially concurrent) GC walks of runtime data structures.
> 
> As a side effect, this enhancement fixes these bugs:
> 8174790: Race adding (weak) global JNI handles and determining type of handle
> 8176454: Performance: jweak references not suitable for robust cache architecture
> 
> Some things not addressed by this change include:
> 
> - 8194309: JNI handle allocation failure not reported correctly
> For now, the pre-existing vm_exit_out_of_memory behavior is retained.
> 
> - Updating JNIHandles to use the new Access protocol.
> 
> - Serviceability Agent updates for OopStorage and JNI usage.  Just
> enough has been done to allow existing SA tests to "pass".  This will
> be addressed as a followup.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8194312
> 
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8194312/open.00/
> 
> Testing:
> Mach5 hs-tier1 through hs-tier5, jdk-nightly
>