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

[David Holmes]

On 9/01/2018 1:18 PM, David Holmes wrote:
> 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 ?

To clarify the above. oopStorage is an enabling technology that provides 
the support for potential parallel/concurrent JNI global handle 
processing. My concern is with any GC that in the future takes advantage 
of this and starts doing things outside of a safepoint, that is 
currently done at a safepoint, and which may impact the assumptions 
within the JNI checking code, within the IN_VM sections, that expects to 
execute atomically with respect to such code.

Cheers,
David

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