JNI_FastGetField::generate_fast_get_int_field0 (in jniFastGetField_x86_64.cpp) calls the barrier set's try_resolve_jobject_in_native, with rtmp available as a temporary. After that call, there is a debug-only clobber of rtmp.

rtmp is r8. Quoting from the RFR for 8202381, where the use of r8 was introduced:

  [r8] like the other registers used in this code, a caller saved
  register, that does not intersect with the input registers of the
  function arguments.

That statement isn't true for Windows, where r8 is c_rarg2, which contains the jfield id argument.

If the speculative fast path that follows is abandoned (with fallback to the slowpath) due to a change of the safepoint counter, the slowpath will be called with that clobbered c_rarg2. The likely result is a failed assertion in the slowpath code, due to the clobbering value being an invalid index into the object.

For the x86 platform and GCs currently in OpenJDK, none use that temp register in try_resolve_jobject_in_native, so the only failure case right now is an abandoned fast path, and that only in a (fast)debug build.