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