RFR: 8191870: Remove badJNIHandle (original) (raw)

Daniel D. Daugherty daniel.daugherty at oracle.com
Sat Nov 25 14:20:47 UTC 2017

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: throwunsatisfiedlinkerror. 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/

src/hotspot/share/runtime/globals.hpp     No comments.

src/hotspot/share/runtime/jniHandles.cpp     No comments.

src/hotspot/share/runtime/jniHandles.hpp     No comments.

src/hotspot/share/runtime/sharedRuntime.cpp     No comments.

src/hotspot/share/utilities/globalDefinitions.hpp     No comments.

Thumbs up!

Thanks for leaving JNIHandles::resolve_external_guard() so that JVM/TI can still do its (limited) bad parameter checks.

Dan

Testing: Mach5 hs-tier1-3 tonga: nsk.jvmti, nsk.stress, vm.runtime (for various JNI tests)

More information about the hotspot-dev mailing list