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.