Traditionally, we have never had barrier support for IN_NATIVE oop atomics. Seems like we added support for it in ZGC because we are paranoid about future uses, but G1 does not have any write barriers for this. JDK-8338383 introduced the first runtime use of IN_NATIVE oop atomics, and since then we have a bug that the previous value is not kept alive during concurrent marking, used to store the head of some list of virtual threads to be unparked from an unparker thread.

The virtual threads are seemingly kept alive in other ways because they are blocked on an object monitor, and other logic needs to keep the parked threads alive, but nevertheless we should fix the barriers so we don't rely on that, and nobody stumbles on this in the future. The OopHandle::xchg/cmpxchg APIs we expose don't work reliably otherwise.