<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 3, 2024 at 1:20 PM Ron Pressler <<a href="mailto:ron.pressler@oracle.com">ron.pressler@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"><br>
<br>
> On 3 May 2024, at 18:33, David Lloyd <<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a>> wrote:<br>> 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.<br>
> <br>
> Could such a thing be added into the plan?<br><br>
[redirecting to core-libs]<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Good call, I should have thought of that.</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br>
<br>
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?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.<br></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">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).</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">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.</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">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.</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">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.</div><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>