RFR: 8191870: Remove badJNIHandle

[Daniel D. Daugherty]

Because it is a 'trueInDebug' option, we only do the ZAP'ing in non-product
builds... so we don't take the time to ZAP in product bits. As for the 
ZAP'ing,
it helps us diagnose stale JNI handle usage...

Dan


On 11/27/17 9:53 AM, coleen.phillimore at oracle.com wrote:
>
> Hi, This looks good.
>
> http://cr.openjdk.java.net/~kbarrett/8191870/open.00/src/hotspot/share/runtime/globals.hpp.udiff.html 
>
>
> Is there a point to this command line option?  It's a develop option- 
> can we just remove it?
>
> Thanks,
> Coleen
>
> On 11/25/17 12:35 AM, Kim Barrett wrote:
>> Please review this change to eliminate badJNIHandle and the special
>> debug-only handling of it when resolving JNI handles.
>>
>> For the intended purpose of catching bad JNI handle usage while
>> sometimes normalizing some to NULL, we mostly don't need such a
>> special value. We can instead use NULL directly, and get largely the
>> same effect.
>>
>> By filling blocks with NULL, rather than badJNIHandle, we avoid the
>> difficulties related to the Access protocol (see the CR).
>>
>> A NULL value is sufficient for local and non-weak global handles.  A
>> JNI handle is never allocated to refer to a NULL value; instead, a
>> NULL handle is used.  resolve and friends already treat the case of a
>> NULL pointee specially (asserting, except in the external guard case,
>> where it is allowed to pass through).
>>
>> Only weak global handles lose the protection afforded by badJNIHandle.
>> (This is because, unlike local and global handles, a weak global
>> handle can refer to a NULL value, because it may have been cleared by
>> the GC.)  That protection was already fairly minimal for such handles,
>> even when using badJNIHandle.  That protection only applied for
>> entries in a newly allocated block that have never yet been allocated.
>> Blocks in the global lists are currently never released, so the
>> setting to a "bad" value for released handles never occurs for weak
>> global handles.  So the most interesting use-case for badJNIHandle
>> (identifying uses of stale handles) doesn't even apply.
>>
>> There is one other use of badJNIHandle: throw_unsatisfied_link_error.
>> This function isn't currently called, only used as a marker. The
>> discussion in bug 4524377, where that function was added, suggested
>> using badAddress, so we're replacing badJNIHandle with badAddress.
>>
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8191870
>>
>> Webrev:
>> http://cr.openjdk.java.net/~kbarrett/8191870/open.00/
>>
>> Testing:
>> Mach5 hs-tier1-3
>> tonga: nsk.jvmti, nsk.stress, vm.runtime (for various JNI tests)
>>
>>
>