RFR: 8324492: Remove Atomic support for OopHandle [v2]

[Kim Barrett]

> Please review this change to the lazy initialization of the MemoryManager
> object and the associated MemoryPool objects.
> 
> They previously used an atomic access to the respective OopHandle member
> holding the associated Java object as the is-initialized sentinal, testing
> whether the handle was empty or had an associated OopStorage entry. When
> empty, initialization was performed using a lock to prevent races.
> 
> Now they use a separate atomic is-initialized flag as the sentinal.
> 
> As a result, the support for atomic access to an OopHandle's underlying handle
> (via a translator) is no longer needed and is removed.
> 
> While there, I moved the allocation of the associated OopStorage entries out
> from under the Management_lock.
> 
> Testing: mach5 tier1
> 
> A couple of notes for reviewers.
> 
> Once initialized with a Java object recorded in the associated OopHandle, the
> OopHandle and the value recorded therein is never changed.
> 
> The old is-initialized check makes use of OopHandle::resolve returning null if
> either the handle is empty (has no OopStorage entry yet) or the OopStorage
> entry contains null. The latter never happens in this case.

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:

  aboldtch review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17533/files
  - new: https://git.openjdk.org/jdk/pull/17533/files/b2a295ad..e9b455aa

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

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

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