RFR: 8251358: Clean up Access configuration after Shenandoah barrier change

[Erik Österlund]

On Wed, 16 Sep 2020 06:32:07 GMT, Aditya Mandaleeka <adityam at openjdk.org> wrote:

>> Thanks for fixing this. It's nice to see build-time decorators go. Naturally, when removing the resolve() function, we
>> can also remove a bunch of "_raw" functions in the runtime. Like there is no longer a need to distinguish between
>> field_addr and field_addr_raw. Or between base and base_raw. They were all introduced so that one of them could apply
>> the resolve barrier. The same goes for mark vs mark_raw and the other related mark accessor functions on oopDesc. I
>> think we want to get rid of that too, right?
>
> @fisk Good point. It's clear that the field_addr and base ones can be changed, and I'll do that in the next update I
> send. I'll take a closer look at the marking functions you mentioned as well. I want to understand the decorators
> they're using and see whether they still do anything meaningful before I get rid of them.

The only supported decorators for primitives is memory ordering decorators. These functions use MO_RELAXED. Specifying
MO_RELAXED is equivalent to using Atomic::load/store.

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

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