RFR: 8191870: Remove badJNIHandle

[coleen.phillimore at oracle.com]

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