Does openjdk8u need pre-barrier for jweak?

[Kim Barrett]

> On Aug 14, 2018, at 5:04 AM, Aleksey Shipilev <shade at redhat.com> wrote:
> 
> On 08/14/2018 02:30 AM, Liu, Xin wrote:
>> Another question is which regression test can trigger the issue? Why did you only identify the
>> problem on jdk9+?
> 
> This sounds familiar. In Shenandoah JDK 8 backport, we "just" disable jweak processing wholesale
> because of bugs around jweak handling. It seems risky to backport the fixes to 8u. Shenandoah's
> workaround also includes the test that fails:
>  http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/ba692039a40a
> 
> Maybe the way to avoid G1 crashes would be to workaround the bug the same way for G1?
> 
> -Aleksey

The lack of a SATB barrier for jweak was a day1 G1 bug, so it is
indeed present in JDK 8.  I'm not sure why 8 wasn't listed in the
original bug's Affects Version.

There is a regression test for this:
test/hotspot/jtreg/gc/g1/TestJNIWeakG1/TestJNIWeakG1.java
However, this test uses a WhiteBox feature that was added in JDK 10
(requestConcurrentGCPhase and friends).

I agree with Aleksey that backporting all the relevant stuff to JDK 8
would be pretty risky.  The workaround described for Shenandoah seems
okay to me (treat the JNI weak globals just like the normal JNI
globals for concurrent marking, e.g. also scan the weak globals in the
initial mark pause).  This may prevent reclamation of some objects
that otherwise could be, but that's safer than premature reclamation.
(I think the Shenandoah patch's implementation of the workaround is
wrong, but that's a different issue.)

I suspect that at the time we expected JDK 8 to soon be supplanted by
JDK 9 and later, so didn't worry about addressing the problem in JDK
8.  With an extended lifetime for JDK 8, some decisions like that may
need to be revisited.