New candidate JEP: 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal

[David Lloyd]

On Fri, May 3, 2024 at 10:12 AM Mark Reinhold <mark.reinhold at oracle.com>
wrote:

> https://openjdk.org/jeps/471
>
>   Summary: Deprecate the memory-access methods in sun.misc.Unsafe for
>   removal in a future release.



We still use Unsafe fairly often in various Red Hat products (primarily
because our baseline support JDK for these products is typically 11 or 17
at present), in a variety of ways for a variety of reasons. Most of these
uses of Unsafe should be transitionable to `MemorySegment` using
multi-release JARs, and a bit of exploratory work has already been done on
this. However there is one unfortunate exception (that I know of).

In order to avoid false sharing in certain specific high-concurrency
situations, I have lately used arrays to space out certain value locations
by using the smallest data cache line size (which is detected via an
existing library) and dividing it by the array scale to determine the
length of array to allocate in order to accommodate these values. I then
use multiples of the cache line size (in bytes), offset from the array
base, to locate the elements to access.

It is possible to continue this more or less as-is for primitive types (at
least, it is if one assumes certain facts around primitive data type size
and alignment to be true), but for objects, without knowing their size, we
can't know how much padding to reserve around the value location to ensure
that the contended values are not falsely shared.

I seem to recall (years ago now so I might be a bit fuzzy on it) that the
lack of public API around `@Contended` was mildly controversial in the
past. The proposed remedy was to use arrays for this purpose, if I recall
correctly. However there does not seem to be any good way to do this
anymore (at least for objects) without simply guessing, and this seems like
a small but significant hole in this plan as it stands for now.

It seems to me that the JDK could fill this gap by introducing some API
which can construct and provide access to an array or something like it,
with striding and/or alignment guarantees that each element will reside on
a separate data cache line (or barring that, perhaps using a minimum
per-element size and/or alignment that is given as an argument to the
factory), and with the gamut of atomic accessors via a `VarHandle` or
similar. This could be especially valuable if/when objects start coming in
a variety of shapes and sizes in memory, once value types hit.

Could such a thing be added into the plan?

-- 
- DML • he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20240503/4ed468ed/attachment.htm>