RFR: 8251358: Clean up Access configuration after Shenandoah barrier change [v2]

[Erik Österlund]

On Thu, 24 Sep 2020 06:03:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> No, wait a second. I agree with some `_raw` removals, but not the other. The point of many `_raw` calls is using them
> from internal GC code when we *know* barriers are not required (because GC already knows in which state the object is
> in) or even correct to perform (for example, setting marks on incomplete objects). Changing e.g. `set_mark_raw` to
> `set_mark` on those paths exposes objects to GC barriers.

We did not have said raw functions before Shenandoah. They were added to distinguish between barriers vs no barriers.
And people would have to figure out which one to call. Now we never use barriers, so there is no difference. Sure the
GC code knows there are no barriers. Agreed. But so does everybody else. Because we are removing barriers for
primitives support. And mark words are simply primitives. Or do you have any other need for actually having barriers on
mark word reads and writes?

-------------

PR: https://git.openjdk.java.net/jdk/pull/146