Integrated: 8324492: Remove Atomic support for OopHandle

[Kim Barrett]

On Tue, 23 Jan 2024 10:52:06 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.

This pull request has now been integrated.

Changeset: 39b756a0
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/39b756a0d163d60d1b69fbc9bf6e8235080c3721
Stats:     101 lines in 5 files changed: 24 ins; 14 del; 63 mod

8324492: Remove Atomic support for OopHandle

Reviewed-by: aboldtch, coleenp

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

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