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

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Mon Nov 27 15:19:20 UTC 2017

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