RFR: 8256020: Shenandoah: Don't resurrect objects during evacuation on AS_NO_KEEPALIVE [v4]

[Aleksey Shipilev]

On Wed, 11 Nov 2020 15:17:15 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> In Shenandoah-testing, we noticed that compiler/jsr292/CallSiteDepContextTest.java fails with the following error:
>> 
>> CONF=linux-x86_64-server-fastdebug make run-test TEST=compiler/jsr292/CallSiteDepContextTest.java TEST_VM_OPTS="-XX:+UseShenandoahGC -XX:+ShenandoahVerify"
>> 
>> #  Internal Error (/home/rkennke/src/openjdk/jdk/src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp:92), pid=2318905, tid=2318938
>> #  Error: Before Updating References, Marked; Must be marked in complete bitmap
>> 
>> Referenced from:
>>   interior location: 0x00000000fff8514c
>>   0x00000000fff85140 - klass 0x000000010004ecd8 java.lang.invoke.MutableCallSite
>>         allocated after mark start
>>     not after update watermark
>>         marked strong
>>         marked weak
>>     not in collection set
>>   mark: mark(is_neutral no_hash age=0)
>>   region: | 2565|R  |BTE     fff80000,     fffc0000,     fffc0000|TAMS     fff80000|UWM     fffc0000|U   256K|T     0B|G   256K|S     0B|L     0B|CP   0
>> 
>> Object:
>>   0x00000000d80a9210 - klass 0x000000010004cf58 java.lang.invoke.DirectMethodHandle
>>     not allocated after mark start
>>     not after update watermark
>>     not marked strong
>>     not marked weak
>>         in collection set
>>   mark: mark(is_neutral no_hash age=0)
>>   region: |    9|CS |BTE     d8080000,     d80c0000,     d80c0000|TAMS     d80c0000|UWM     d80c0000|U   256K|T   256K|G     0B|S     0B|L 22464B|CP   0
>> 
>> Forwardee:
>>   (the object itself)
>> 
>> In other words, a reachable (marked) MutableCallSite references an unreachable DirectMethodHandle. That reference would subsequently become dangling and lead to crashes if accessed.
>> 
>> I narrowed it down to the access in Dependencies::DepStream::recorded_oop_at(int i) which is done as 'strong', which means that it would return the reference even if it is unreachable, e.g. during concurrent class-unloading. This resurrection of the unreachable DMH is potentially fatal: eventually the reference will become dangling (after GC) and lead to crashes when accessed. I believe that access should be 'phantom' instead which causes GCs like Shenandoah and ZGC to return NULL when encountering unreachable objects. 
>> 
>> (Notice that the bug only manifested after JDK-8255691, we accidentally applied the resurrection-preventing weak-LRB on strong access too)
>> 
>> Testing:
>>  - [x] the offending CallSiteDepContextTest.java +UseShenandoah
>>  - [x] hotspot_gc_shenandoah
>>  - [x] tier1+UseShenandoahGC+ShenandoahVerify
>>  - [x] tier2+UseShenandoahGC+ShenandoahVerify
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8256020
>  - Merge branch 'master' into JDK-8256020
>  - Merge branch 'master' into JDK-8256020
>  - Revert original fix; Prevent resurrection of unreachable objects during evacuation on AS_NO_KEEPALIVE
>  - 8256020: Don't resurrect objects on argument-dependency access

src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 115:

> 113:   // concurrent class-unloading.
> 114:   if (HasDecorator<decorators, AS_NO_KEEPALIVE>::value && obj != NULL &&
> 115:       _heap->has_forwarded_objects() &&

Why `has_forwarded_objects()` check here? It seems to me that without forwarded objects, the `load_reference_barrier` below would return the same `obj` anyway?

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

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