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

[Axel Boldt-Christmas]

On Thu, 25 Jan 2024 05:51:37 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> 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

Marked as reviewed by aboldtch (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17533#pullrequestreview-1843384287