This is reproducible with x86_32, but the bug is generic, introduced by JDK-8231086. ShenandoahRuntime::shenandoah_clone_barrier expects src to be the base pointer for the clone barrier to act. C2, however, passes in the interior ptrs to the object contents. This leads to crashes like:
$ CONF=linux-x86-server-fastdebug make images run-test TEST=vmTestbase/jit/escape/AdaptiveBlocking/AdaptiveBlocking001/AdaptiveBlocking001.java TEST_VM_OPTS="-XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:-TieredCompilation"
#
# Internal Error (/home/shade/trunks/jdk-jdk/src/hotspot/share/gc/shenandoah/shenandoahRuntime.cpp:80), pid=19219, tid=19220
# Error: Shenandoah assert_correct failed; Object klass pointer must go to metaspace
Referenced from:
no interior location recorded (probably a plain heap scan, or detached oop)
Object:
0xa3d8db50 - safe print, no details
region: | 2|R |BTE a3d80000, a3e00000, a3e00000|TAMS a3d80000|U 512K|T 512K|G 0B|S 0B|L 0B|CP 0|SN 3, 3, 0, 0
Raw heap memory:
0xa3d8db30: 00000000 00000000 00000000 00000000
0xa3d8db40: 00000000 00000000 00000001 a110ac90
0xa3d8db50: 00000001 a3d8db58 00000005 a0eda228
0xa3d8db60: 00000100 00000000 00000000 a3d8db88
0xa3d8db70: 00000000 a3d8db78 00000005 a10b2c10
0xa3d8db80: a3d8db58 00000000 00000001 a10b2690
0xa3d8db90: 00000000 00000000 00000001 a110ac90
0xa3d8dba0: 00000001 baadbabe baadbabe baadbabe
0xa3d8dbb0: baadbabe baadbabe baadbabe baadbabe
0xa3d8dbc0: baadbabe baadbabe baadbabe baadbabe