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

Roman Kennke rkennke at openjdk.java.net
Wed Nov 11 17:56:12 UTC 2020


> 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

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1113/files
  - new: https://git.openjdk.java.net/jdk/pull/1113/files/492255ed..65f902cd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1113&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1113&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1113.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1113/head:pull/1113

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



More information about the hotspot-gc-dev mailing list