RFR: JDK-8226878: zero crashes after JDK-8191278

[Ao Qi]

On Thu, Jun 27, 2019 at 7:38 PM Aleksey Shipilev <shade at redhat.com> wrote:
>
> On 6/27/19 1:04 PM, Ao Qi wrote:
> > Hi,
> >
> > On zero, StubRoutines::unsafe_arraycopy() may return
> > ShouldNotCallThisStub() but not NULL. Is it ok to use
> > Copy::conjoint_memory_atomic instead of
> > StubRoutines::UnsafeArrayCopy_stub()(src, dst, sz) on zero?
> >
> > JBS:
> > https://bugs.openjdk.java.net/browse/JDK-8226878
> >
> > Fix:
> > diff --git a/src/hotspot/share/prims/unsafe.cpp
> > b/src/hotspot/share/prims/unsafe.cpp
> > --- a/src/hotspot/share/prims/unsafe.cpp
> > +++ b/src/hotspot/share/prims/unsafe.cpp
> > @@ -401,7 +401,7 @@
> >    void* dst = index_oop_from_field_offset_long(dstp, dstOffset);
> >    {
> >      GuardUnsafeAccess guard(thread);
> > -    if (StubRoutines::unsafe_arraycopy() != NULL) {
> > +    if (StubRoutines::unsafe_arraycopy() != NULL ZERO_ONLY(&&
> > StubRoutines::unsafe_arraycopy() != ShouldNotCallThisStub())) {
> >        StubRoutines::UnsafeArrayCopy_stub()(src, dst, sz);
> >      } else {
> >        Copy::conjoint_memory_atomic(src, dst, sz);
> Hold on. I think stubGenerator_zero.cpp should just return NULL when stub is not generated. It looks
> like a Zero-specific problem to return "fake" stubs when they are not actually generated. Like this:
>
> diff -r 91b38bfb9079 src/hotspot/cpu/zero/stubGenerator_zero.cpp
> --- a/src/hotspot/cpu/zero/stubGenerator_zero.cpp       Thu Jun 27 18:00:54 2019 +0800
> +++ b/src/hotspot/cpu/zero/stubGenerator_zero.cpp       Thu Jun 27 13:37:47 2019 +0200
> @@ -157,7 +157,9 @@
>
>      StubRoutines::_checkcast_arraycopy       = ShouldNotCallThisStub();
> -    StubRoutines::_unsafe_arraycopy          = ShouldNotCallThisStub();
>      StubRoutines::_generic_arraycopy         = ShouldNotCallThisStub();
>
> +    // Shared code tests for "NULL" to discover the stub is not generated.
> +    StubRoutines::_unsafe_arraycopy          = NULL;
> +
>      // We don't generate specialized code for HeapWord-aligned source
>      // arrays, so just use the code we've already generated
>

I'm fine with this fix.

Thanks,
Ao Qi

> --
> Thanks,
> -Aleksey
>