RFR: 8276663: Cleanup NMT AccessLock [v3]

David Holmes dholmes at openjdk.java.net
Sat Nov 6 07:43:34 UTC 2021


On Fri, 5 Nov 2021 13:54:35 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Please review this cleanup patch to NMT AccessLock:
>> 
>> * Make LockState enum private, no external use.
>> * const lock location pointer
>> * Use memory_order_acquire/memory_order_release for lock counter updates.
>> 
>> Test:
>> - [x] hotspot_nmt on x86_64 and aarch64
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix memory ordering

I'm trying to reason about this but am struggling to understand how this "lock" is actually used. It isn't really a lock at all but a kind of access-latch: anyone can access things in normal operation but when we want to shutdown then we basically put up a closed sign, wait for all current users to leave and then do a reset. There are no critical sections as such and no related memory operations that this "lock" is guarding. So maybe it doesn't need any memory ordering after all. ??

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

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


More information about the hotspot-runtime-dev mailing list