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

[David Lloyd]

On Fri, May 3, 2024 at 1:20 PM Ron Pressler <ron.pressler at oracle.com> wrote:

>
>
> > On 3 May 2024, at 18:33, David Lloyd <david.lloyd at redhat.com> wrote:
> > 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?
>
> [redirecting to core-libs]
>

Good call, I should have thought of that.

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

What I need - my actual use case - is some way to guarantee that some piece
of data is stored alone on its own cache line. This may be a subset of a
broader use case where some set of values should be stored alone on its own
cache line.

To achieve this use case I am presently making assumptions about objects in
an array - specifically that they are stored as oops, and that an oop is
smaller than a cache line (okay that's a fairly reasonable assumption I
guess), and that I can find out the size of an oop so that I can scale
things appropriately. But recognizing that this is not a good kind of
assumption to make, I would rather have an API that (for example) lets me
create and access an array (probably via VarHandle) such that I can
guarantee that each item is a of minimum size (and that size, for my use
case, is going to be what I can determine as the minimum data cache line
size).

A general API which does this would be cool, but I'd be hard-pressed to
imagine a use case for target size other than the data cache line size.

On preserving larger alignment of array contents - that would be generally
pretty interesting. It is not necessary for my use case though, and
probably would be very difficult to implement anyway.

As John suggests, I can probably work around the problem by being very
conservative in my estimates. I can assume that an oop is 4 bytes for
example, and this would work (possibly at the cost of a bit of extra empty
space, and in the hope that nobody will invent some even smaller oop
encoding). I can also assume that a `long` is 8 bytes (this is a safer
assumption) without too much risk.  But it feels like there could be a more
optimal solution in the JDK for this.

-- 
- DML • he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240504/048fe1db/attachment-0001.htm>