[14] RFR(XS): 8227236: assert(singleton != __null && singleton != declared_interface) failed

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Tue Aug 13 15:40:31 UTC 2019


http://cr.openjdk.java.net/~vlivanov/8227236/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8227236

There's a race between ciInstanceKlass::nof_implementors()/implementor()
and class loading for shared classes which may manifest as
inconsistency between consecutive calls to nof_implementors() and
implementor() (ciInstanceKlass::implementor() doesn't cache
InstanceKlass::implementor() for shared classes [1]). That's what
triggers the assert: the check sees 
declared_interface->nof_implementors() == 1,
but concurrent class loading introduces new implementor class before the
assert. Assert hits singleton == declared_interface case since
declared_interface->implementor() == declared_interface when
declared_interface->nof_implementors() > 1 [2].

The race has been there long before JDK-6986483 [3] (same sequence of
nof_implementors()/implementor() calls and the assert in C1 code), but
it seems recent JDK changes made it more likely to occur.

Proposed fix is to check for unique implementor using a single
implementor() call. If there's any concurrent class loading happening
which introduces more implementors, corresponding nmethod dependency
will invalidate the nmethod during installation attempt.

Testing: hs-precheckin-comp, tier1, tier2

Thanks!

Best regards,
Vladimir Ivanov

[1] 
http://hg.openjdk.java.net/jdk/jdk/file/9c0715c5bbf3/src/hotspot/share/ci/ciInstanceKlass.cpp#l617

[2] 
http://hg.openjdk.java.net/jdk/jdk/file/9c0715c5bbf3/src/hotspot/share/ci/ciInstanceKlass.hpp#l72

[3] https://jbs.oracle.com/browse/JDK-6986483


More information about the hotspot-compiler-dev mailing list