RFR: 8316955: Unnecessary memory barrier for reading OopMapCacheEntry from OopMapCache

David Holmes dholmes at openjdk.org
Thu Sep 28 04:13:22 UTC 2023


On Wed, 27 Sep 2023 13:22:43 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> OopMapCacheEntry is installed by CAS with memory_order_conservative, there is no need a memory barrier on read side.
> 
> Test:
>   hotspot_gc on MacOSX (fastdebug and release)

The general pattern we use for lock-free reads is to use load_acquire to match the (implicit) release_store done by the writer - even if the write is actually done by a CAS. IIRC not all platforms use the same strength of barrier for CAS even when in the default conservative mode, so I cannot say for sure that the acquire on the reader side is unnecessary. Conversely if it is necessary then removing it would likely lead to some very obscure bugs. Unless this is causing a significant performance issue I would not contemplate changing it without a detailed analysis of each platform's CAS code.

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

PR Comment: https://git.openjdk.org/jdk/pull/15944#issuecomment-1738404376


More information about the hotspot-gc-dev mailing list