RFR: 8263427: Shenandoah: Trigger weak-LRB even when heap is stable

[Roman Kennke]

On Thu, 11 Mar 2021 18:50:48 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We currently guard all LRBs, including weak-LRB, by a test for heap-stable and only enter the LRB when heap is unstable (e.g. evacuation or update-refs in progress). However, the weak LRB must also be entered when heap is stable and concurrent refs is in progress, otherwise we may accidentally resurrect otherwise unreachable weak referents. This can happen when we take the shortcut cycle and skip evac&update-refs.
>> 
>> I believe this might be the root cause for JDK-8262852. 
>> 
>> Testing:
>>  - [x] New testcase failed without change, passes now
>>  - [ ] hotspot_gc_shenandoah
>>  - [ ] tier1 (+Shenandoah)
>
> src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp line 607:
> 
>> 605:   VerifyThreadGCState(const char* label, char expected) : _label(label), _expected(expected) {}
>> 606:   void do_thread(Thread* t) {
>> 607:     char actual = ShenandoahThreadLocalData::gc_state(t) & ~((char)ShenandoahHeap::WEAK_ROOTS);
> 
> Why these adjustments are needed? I think it shows we don't play well with GC-state lifecycle here...

The verifier would complain about the extra bit being set or maybe not set (e.g. concurrent cycles would set it, but degen cycles would not). We haven't verified conc-weakroots-in-progress before, so I figured it would be easiest to keep it that way and mask it out.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2945