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

[Damon Fenacci]

> # Issue
> An intermittent _Memory Pool not found_ error has been noticed when running  a few tests (_vmTestbase/vm/mlvm/meth/stress/compiler/deoptimize/Test.java_, _vmTestbase/vm/mlvm/meth/stress/compiler/sequences/Test.java_) on _macosx_aarch64_ (production build) with non-segmented code cache.
> 
> ## Origin
> The issue originates from the fact that aarch64 architecture is a weakly ordered memory architecture, i.e. it _permits the observation and completion of memory accesses in a different order from the program order_.
> 
> More precisely: while calling `CodeHeapPool::get_memory_usage`, the `used` and `committed` variables are retrieved
> https://github.com/openjdk/jdk/blob/138542de7889e8002df0e15a79e31d824c6a0473/src/hotspot/share/services/memoryPool.cpp#L181-L182
> and these are computed based on different variables saved in memory in `CodeCache::allocate` (during `heap->allocate` and `heap->expand_by` to be precise) .https://github.com/openjdk/jdk/blob/138542de7889e8002df0e15a79e31d824c6a0473/src/hotspot/share/code/codeCache.cpp#L535-L537
> The problem happens when first `heap->expand_by` gets called (which _increases_ `committed`) and then `heap->allocate` gets called in a second loop pass (which _increases_ `used`). Although stores in `CodeCache::allocate` happen in the this order, when reading from memory in `CodeHeapPool::get_memory_usage` it can happen that `used` has the newly computed value, while `committed` is still "old" (because of ARM’s weak memory order). This is a problem, since `committed` must be > than `used`.
> 
> # Solution
> 
> To avoid this situation we must assure that values used to calculate `committed` are actually saved before the values used to calculate `used` and that the opposite be true for reading. To enforce this we add an `acquire/release` ordering for `CodeHeap::_next_segment` ensuring that when `CodeHeap::allocated_capacity` is called, if `_next_segment` (which is used to calculate `used`) has already been updated in `CodeHeap::allocate`, then all values written before are going to be visible (the ones to calculate `committed`).
> 
> Acquiring a `CodeCache_lock` has been attempted in #15819 but resulted in deadlocks (that seem to be unavoidable).

Damon Fenacci has updated the pull request incrementally with three additional commits since the last revision:

 - JDK-8317661: use explicit barriers
 - Revert "JDK-8317661: [REDO] store/load order not preserved when handling memory pool due to weakly ordered memory architecture of aarch64"
   
   This reverts commit 3c33bd9901465da60969536f38a559890e54e1e2.
 - Revert "Update src/hotspot/share/memory/heap.cpp"
   
   This reverts commit 492ffbb9ab9cf7f17d1513e2d032d17cf91c1a8f.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16143/files
  - new: https://git.openjdk.org/jdk/pull/16143/files/492ffbb9..c6fa9674

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16143&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16143&range=00-01

  Stats: 6 lines in 3 files changed: 3 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16143/head:pull/16143

PR: https://git.openjdk.org/jdk/pull/16143