Does openjdk8u need pre-barrier for jweak?

[Kim Barrett]

> On Aug 14, 2018, at 9:56 PM, Liu, Xin <xxinliu at amazon.com> wrote:
> 
> Hi, Kim and Aleksey, 
> Thank you for answering me.  I am new in both hotspot and GC. 
> 
> @Alekey, 
> In your way, you miss the chance to clear JNI weak reference here. 
> http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/b4ee249eb1c4/src/share/vm/runtime/jniHandles.cpp#l393
> 
> Our service generates many MemberName objects  on-the-fly. They are cached in MemberNameTable.  
> http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/b4ee249eb1c4/src/share/vm/prims/methodHandles.cpp#l954
> it will create memory leak right? Because the table is bigger and bigger. 
> 
> Except JVM exit, I can't find any chance to release those oops in table. Can full GC collect them?
> 
> Tag JNI reference is an Arch/GC-independent way. I found jdk12 repo uses C++ metaprogramming to emit proper barriers for different GCs.
> We can use if/elif for both G1 and Shenandoah if you don’t want to keep simple.  
> 
> Can we consider my backported patch? I don't have permission to submit sandbox repo, But I ran SPECjvm2008 and didn't observe any performance impact. 
> 
> @Kim, 
> Thank you give me the point to the test. Yes, indeed, it's basing on whitebox. 
> I can mimic the race condition by generating many global weak references, but it cannot be deterministic. I don't know how to write a reproducible and deterministic jtreg test.
> 
> Thanks,
> --lx

[Note: I am not a Reviewer for JDK 8.  Actually, not even a committer.
And I have very little knowledge about what sorts of things ought or
ought not be backported to JDK 8.]

I really think trying to backport the new jweak tagging and everything
that goes with it would be very risky.  I don't remember for sure, but
I think there were more follow-on issues even after the [REDO][REDO].

On further consideration, I think the Shenandoah patch might be
actively bad.

However, I think there might be a much simpler solution that retains
at least some clearing of jweaks.  Change the initial mark pause to
always scan and mark the JNI weak globals too, just as the normal JNI
globals are marked.  Leave process_phaseJNI alone (i.e. don't use
Shenandoah's patch.)

With that change, I think young and mixed GCs can collect objects in
the collection set that are only referred to by weak references.
Similarly, I think a full GC will also be able to collect such
objects.  It's only a concurrent collection cycle that won't be able
to reclaim them.