The JFR leak profiler associates an Edge* with an object by putting the Edge* into an array, and storing the index to the Edge* into the object's mark-word, and setting the lowest two bits of that mark-word.
However, in Shenandoah, a similar scheme is used to indicate forwarding objects: the lowest two bits in object's mark are set, and the reference to the forwarding object in the upper bits of the header. We may go through the load-reference-barrier of an object that has an associated Edge* in BFSClosure::do_oop(), which would decode the assumed forwarding pointer, get the index instead of the reference, and eventually crash, when trying to dereference anything from there.

Notice that JDK-8275415 changed the association scheme from full Edge* in the mark-word to the index, but the general problem was pre-existing.

As an aside, in Shenandoah, we distinguish forwarding pointers from JVMTI heap-walk 'marked' objects by checking for the upper mark-bits to be NULL. JFR breaks this scheme (which is rather brittle in itself) by putting the Edge* association in the mark-word too.

We may want to consider something similar to: https://github.com/openjdk/lilliput/pull/18