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

[Ron Pressler]

> On 3 May 2024, at 18:33, David Lloyd <david.lloyd at redhat.com> wrote:
> 
> 
> 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

[redirecting to core-libs]

Adding some VarHandle operation that takes into account the cache lines size is interesting — although preserving cache-line *alignment* could be tricky as the GC relocates arrays, so an array element that’s at the start of a cache line at time t0 might not be at the start of a cache line at time t1 — but that’s unrelated to this JEP.

What is related to this JEP is that you’re using Unsafe to determine the size of an oop (in particular, to tell if oops are compressed or no)t. Is that what you’re asking for?

— Ron