Does openjdk8u need pre-barrier for jweak?

[Liu, Xin]

Aleksey, 

Okay. Thank you to introduce the full process.  
I will post webrev here(hotspot-gc-dev) with proper description and verification. Stay tuned. 

Thanks,
--lx

On 8/15/18, 10:00 AM, "Aleksey Shipilev" <shade at redhat.com> wrote:

    Hi Liu,
    
    Yes, I am committer in 8u. But this would require approval from current 8u maintainers. The
    maintainers for jdk8u project would normally look at what GC devs said in patch review for
    8u-specific patch. So, any patch to G1 in 8u should be RFR'ed on this list (hotspot-gc-dev@) first,
    to check with G1 folks that is a proper way to go.
    
    G1 and Shenandoah are definitely affected. I am not sure CMS has this problem: IIRC, remark is
    supposed to find live-but-disconnected objects like these.
    
    -Aleksey
    
    On 08/15/2018 06:42 PM, Liu, Xin wrote:
    > Agree. I will try to use the similar idea in G1. Aleksey, are you committer of JDK8u? I need to find a sponsor. 
    > IMHO, all concurrent GCs have this race condition, right?  Shall we fix CMS? 
    > 
    > Thanks,
    > --lx
    > 
    > On 8/15/18, 12:50 AM, "Aleksey Shipilev" <shade at redhat.com> wrote:
    > 
    >     Hi Kim,
    >     
    >     On 08/15/2018 07:01 AM, Kim Barrett wrote:
    >     > 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.)
    >     
    >     That is actually a much saner idea for Shenandoah as well, thanks! Should have thought about it at
    >     the time. We have moved the workaround block to root processor, which can also distinguish between
    >     root processing for concurrent mark and last-ditch STW Full GC:
    >       http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-August/007094.html
    >     
    >     I think/agree we can apply similar workaround to G1, and move on.
    >     
    >     -Aleksey
    >     
    >     
    >     
    >