RFR: JDK-8317661: [REDO] store/load order not preserved when handling memory pool due to weakly ordered memory architecture of aarch64

[Andrew Haley]

On Mon, 23 Oct 2023 07:49:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I can't help but think that the clearest fix here is to use explicit barriers as discussed before the locking solution was proposed. The problem using `release_store` and `load_acquire` in the bottom level code is that those semantics are only needed in this higher-level code for the `codeHeap`, not for every kind of `heap` the code applies to.
> 
> I wonder if perhaps the following is clearer:
> 
> ```
>  while (true) {
>     cb = (CodeBlob*)heap->allocate(size);
>     if (cb != nullptr) break;
>     if (!heap->expand_by(CodeCacheExpansionSize)) {
>       // ...
>     } else {
>       OrderAccess::release(); // ensure heap expansion is visible

"visible to an asynchronous observer (e.g. CodeHeapPool::get_memory_usage())"

> before we allocate on next iteration
>     }
> ```
> 
> coupled with:
> 
> ```
> size_t used      = used_in_bytes(); 
> OrderAccess:acquire();
> size_t committed = _codeHeap->capacity(); 
> ```
> 
> Thoughts?

As long as it's more thoroughly commented, i guess so.

A floating release is, however, a pretty bad code smell. The only reason we're aren't solving this problem (IMHO) properly is that the code cache lock isn't re-entrant.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16143#discussion_r1369835049