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

Erik Osterlund erik.osterlund at oracle.com
Sat Nov 25 08:44:11 UTC 2017

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: 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/ Testing: Mach5 hs-tier1-3 tonga: nsk.jvmti, nsk.stress, vm.runtime (for various JNI tests)

More information about the hotspot-dev mailing list