RFR: 8256020: Don't resurrect objects on argument-dependency access

Roman Kennke rkennke at openjdk.java.net
Sun Nov 8 21:40:03 UTC 2020


In Shenandoah-testing, we noticed that compiler/jsr292/CallSiteDepContextTest.java fails with the following error:

Internal Error (/home/rkennke/src/openjdk/jdk/src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp:92), pid=906849, tid=907073
Error: Before Updating References, Marked; Must be marked in complete bitmap

Referenced from:
  interior location: 0x00000000fff87504
  0x00000000fff874f8 - 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: the offending CallSiteDepContextTest.java, tier1+UseShenandoahGC+ShenandoahVerify, tier2+UseShenandoahGC+ShenandoahVerify, hotspot_gc_shenandoah

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

Commit messages:
 - 8256020: Don't resurrect objects on argument-dependency access

Changes: https://git.openjdk.java.net/jdk/pull/1113/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1113&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256020
  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-compiler-dev mailing list