RFR: 8215395: Allow null oops in Dictionary and JNIHandle verification

Kim Barrett kim.barrett at oracle.com
Fri Dec 14 16:57:34 UTC 2018


> On Dec 14, 2018, at 3:18 AM, Per Liden <per.liden at oracle.com> wrote:
> 
> JDK-8214784 adjusted the Dictionary and JNIHandle verification, but failed to take into account that these oops can be null. We should be using oopDesc::is_oop_or_null() here rather than just oopDesc::is_oop().
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8215395
> Webrev: http://cr.openjdk.java.net/~pliden/8215395/webrev.0
> 
> /Per

For the case of JNIHandles, I don't think the closure will ever be
called with a pointer to a NULL oop.

A strong JNI global handle never contains NULL, by design.
(make_global when the argument is a NULL oop just returns NULL as the
handle, rather than making a handle that points to NULL.)

Verification calls JNIHandles::weak_oops_do with the verification
closure, which calls OopStorage::weak_oops_do with that closure, which
calls OopStorage::iterate_safepoint with a skip_null wrapper around
the closure.

That said, I don't strongly object to this change, if you want to make
a "belts and suspenders" argument for it.

The protection domain set change looks okay to me.



More information about the hotspot-runtime-dev mailing list