JDK-8199735 rewired mark() and set_mark() to use HeapAccess, thus exposing them to GC barriers. This was needed for old Shenandoah code that needed to handle all accesses to from-copy objects, which included the mark words. GC code was isolated from HeapAccess paths by introducing mark_raw() and set_mark_raw().

Later, Shenandoah switched to strong to-space invariant. Then, JDK-8251358 cleaned up the access layer, dropping mark_raw(), set_mark_raw() and only keeping mark() and set_mark(). But then, GC code started going through HeapAccess.

This is innocuous at this point, since such HeapAccess would eventually resolve to raw access anyway for all current GCs. But this is awkward and would not even work if any GC tries to do something else than RawAccess when handling the primitive access. It would quite probably need to restore _raw versions then.

It would be more straight-forward to use direct (raw) accesses to mark word in mark() and set_mark(). It would also match the accesses to klass word. This does not look affecting performance, as current accessors seem to be compiled down to raw accesses.

It is a design question whether we want to keep all heap accesses decorated with Access API. If we do, then accesses to klass word should probably be decorated as well. If we don't, then ripping out primitive heap accessors would further simplify Access API.

Draft PR: https://github.com/openjdk/jdk/pull/5166