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

[Aleksey Shipilev]

On Wed, 11 Nov 2020 17:56:12 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 incrementally with one additional commit since the last revision:
> 
>   Narrow phase in which to prevent resurrection-by-evacuation

Yes, that matches the synopsis better too.

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

Marked as reviewed by shade (Reviewer).

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