RFR: [8u] Workaround VM crash with JNI Weak Refs handling

[Roman Kennke]

Sounds like it requires a keep_alive_barrier() in the place where the
oop is moved from jweak -> local?

As a workaround, the patch is ok.

Roman

On Mon, Feb 19, 2018 at 12:05 PM, Aleksey Shipilev <shade at redhat.com> wrote:
> http://cr.openjdk.java.net/~shade/shenandoah/8u-workaround-jweak/webrev.01/
>
> Found this during sh/jdk8u backports, which brought the TestJNIGlobalRefs test. This test crashes
> current VM with SEGV, or fails in Verifier like this:
>
> #  Internal Error
> (/home/shade/trunks/shenandoah-jdk8/hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp:146),
> pid=34021, tid=0x00007f2a54bfb700
> #  Error: Shenandoah verification failed; After Mark, Roots: Object must belong to region with live data
>
> Referenced from:
>   interior location: 0x00007f2a6c6d3810
>   outside of Java heap
>   0x00007f2a6c6d3810 is pointing into the stack for thread: 0x00007f2a6400c800
>
> Object:
>   0x0000000082400008 - klass 0x0000000800000b70 [I
>     not allocated after complete mark start
>         allocated after next mark start
>     not marked complete
>         marked next
>     not in collection set
>   region: |0x00007f2a64086060|    1|R  |BTE 0x0000000082400000, 0x0000000082500000,
> 0x0000000082800000|U  25%|T  25%|G   0%|S   0%|L   0%|CP   0|TAMS 0x0000000082500000,
> 0x0000000082400000|
>
> It seems to be caused by a race between reading the jweak into the local (and thus it appears on
> thread stack), and marking that is supposed to reveal its strong reachability from that root.
>
> My attempts in fixing this easily have not been successful so far. There are upstream jdk9/10
> changes that rework jweak handling and fix some related G1 bugs, but those are not trivially
> backportable. Until we figure that out, I suggest we workaround that failure by assuming JNI Weak
> Refs are always alive.
>
> Testing: hotspot_gc_shenandoah, including new test
>
> Thanks,
> -Aleksey
>