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

[dean.long at oracle.com]

Looks OK, but what's the harm in memoizing for shared classes?

dl

On 8/13/19 8:40 AM, Vladimir Ivanov wrote:
> 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