Java value layout constants

[Maurizio Cimadamore]

Thanks for the feedback.

To be clear, the proposed patch should not change the performance 
charateristics of your application, as long as clients adopts one of the 
two strategies below:

* manually declare a set of unaligned layouts, and use them for 
dereference (as seems to be the case for Lucene)
* always use get/setAtIndex - in which case we can dynamically infer 
whether the offset is always a multiple of the alignment, and omit the 
problematic check on the var handle side (we use a similar trick when 
constructing var handles from layout paths)

When 8277850 is fixed, then accessing at index and at offset should have 
same performance regardless of alignment.

Cheers
Maurizio


On 27/11/2021 10:00, Uwe Schindler wrote:
> Hi Maurizio,
>
>> For this reason, I'd like to propose a small tweak, which would
>> essentially revert alignment constraints for Java layout constants to
>> what they were in 17. In other words, let's keep the "good" JAVA_XYZ
>> names for the _true_ Java layouts (including alignment as seen by VM).
>> If clients want to create unaligned constants they can do so, as they
>> can also create big-endian constants where needed. In the majority of
>> cases, since access will be aligned (for performance reasons), this will
>> not really change much for clients. But some of those clients that need
>> to pack data structures more (Lucene?) will need to define their own
>> packed/unaligned layout constants.
> That's all fine. In my first JDK 18 branch of Lucene's new MMapDirectory, I did it like that:
> https://urldefense.com/v3/__https://github.com/uschindler/lucene/blob/ad3a81e3d348d6aa417aa785bdfe9e7a39c1ee53/lucene/core/src/java/org/apache/lucene/store/MemorySegmentIndexInput.java*L36-L40__;Iw!!ACWV5N9M2RV99hQ!fLIcQ7APXm6JbsHKLk9PFBi_YpF84eBNehTaedMyHoBVTKVJjYlFItYeVI2Y6-sg9wyaeVo$
>
> Basically we have layout constants anyways (as the file format has a defined byte order). At the time when I wrote this (in September) I was already thinking: "maybe add withBitAlignment(8) everywhere?"
>
> In general, when you define your own constant for on-disk layouts it is always adviseable to be specifc with byte order and alignment.
>
> Anyway, we are working on Lucene to have alignment in our files at least for those non-packed formats. E.g. we now align file slices (we call them CFS files) always with 8 bytes to not add additional misalignment there. At some point in future we may to enable the alignment checks, but this will be after several years (file format compatibility).
>
> Uwe
>