RFR: 8191870: Remove badJNIHandle

[Erik Osterlund]

Hi Kim,

This change is absolutely fantastic. 
No more nightmares about zapped JNI handle values. Thank you for doing this.

Looks magnificent.

Thanks,
/Erik

> On 25 Nov 2017, at 06:35, Kim Barrett <kim.barrett at oracle.com> 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)
> 
>