Narrow oop address could be used as a constant in JITed code, so relocation is set to patch the address after GC possibly move the oop.
Generated code looks like

   0x00003fffa01c06fc: lis r14,-16076
   0x00003fffa01c0700: ori r14,r14,41528
   0x00003fffa01c0704: clrldi r14,r14,32

and relocation is set on `ori` instruction. Patching performed by NativeMovConstReg::set_narrow_oop, which uses MacroAssembler::patch_set_narrow_oop return value to calculate icache invalidation range. Due to bug in macroAssembler, invalidation range omits first instruction in the sequence, so it's possible to load high bits of old address value, and low bits of new address value. Such incorrect address could lead to VM crash.

JDK jtreg test java/util/Properties/ConcurrentLoadAndStoreXML really reproduces the crash on NXP e6500 CPU. To make reproducing more stable, one could use next VM flags:
-XX:+UseSerialGC
-XX:+VerifyBeforeGC
-XX:+VerifyAfterGC
-XX:VerifySubSet=heap

There is similar issue with NativeMovConstReg::set_data_plain and MacroAssembler::patch_calculate_address_from_global_toc_at

As I can see, bug persists in jdk8u, jdk9 and jdk10 repo