<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><div class="gmail_quote" style="font-family:Arial,Helvetica,sans-serif"><div dir="ltr" class="gmail_attr"><br class="gmail-Apple-interchange-newline">On Fri, May 3, 2024 at 10:12 AM Mark Reinhold <<a href="mailto:mark.reinhold@oracle.com">mark.reinhold@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><a href="https://openjdk.org/jeps/471" rel="noreferrer" target="_blank">https://openjdk.org/jeps/471</a><br><br>  Summary: Deprecate the memory-access methods in sun.misc.Unsafe for<br>  removal in a future release.</blockquote></div><div style="font-family:Arial,Helvetica,sans-serif"><br></div><span class="gmail_signature_prefix" style="font-family:Arial,Helvetica,sans-serif"><br class="gmail-Apple-interchange-newline"></span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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).</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Could such a thing be added into the plan?</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">- DML • he/him<br></div></div></div>