On Fri, May 3, 2024 at 1:20 PM Ron Pressler <ron.press...@oracle.com> wrote:
> > > > On 3 May 2024, at 18:33, David Lloyd <david.ll...@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
