[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