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

[Aditya Mandaleeka]

On Thu, 24 Sep 2020 07:27:17 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

>> Oops seems like I didn't publish the comments somehow.
>
>> Thanks @shipilev and @fisk . I had left `cas_set_mark_raw` alone since there's a caller that specifies
>> `memory_order_release` and I didn't want to change any behavior with the cleanup:
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp#L242
>> 
>> That said, I haven't looked into how necessary that is; perhaps it's okay to change it to relaxed order.
>> 
>> 
>> 
>> @fisk Thanks for taking another look. I don't see the new comments you added yet. Have you submitted them?
>> 
>> 
>> 
>> I'll follow up on this PR tomorrow since it's quite late here ��
>> 
>> 
> 
> A lot of thought has gone into the memory ordering flags. This change should definitely not change any of that. Having
> said that, I can't see why we can not rename raw functions to not raw functions, while maintaining the same memory
> ordering.

That makes sense, and I just pushed an update that renames those functions. `cas_set_mark_raw` had a default argument
for the memory order which I've turned into a required argument in order to disambiguate after the rename. The only
caller that was relying on the default argument was in the Shenandoah forwarding code, and I've updated it to pass in
the memory order.

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

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