RFR: 8191870: Remove badJNIHandle

[coleen.phillimore at oracle.com]

My question was why there's a command line option, which seems like 
nobody on earth should use it.  Yes, we don't need to zap for product, 
only for debug.
Coleen

On 11/27/17 10:02 AM, Daniel D. Daugherty wrote:
> 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)
>>>
>>>
>>
>