On Mon, 18 Nov 2024 14:13:17 GMT, Roman Kennke <rken...@openjdk.org> wrote:
>> @mur47x111 it's now intergrated in jdk24. do your magic in Graal ;-) > >> @rkennke How important is the 4-byte saving on `byte, char, short, int, >> float` arrays? I'd assume they are not generally that small, at least a few >> elements? So could we make an exception, and have a `16-byte` offset to the >> payload of all these primitive (and maybe all) arrays, at least under >> `AlignVector`? > > For byte[] and to some extend for char[] it is quite important, because those > are the backing types for String and related classes, and Java apps often > have *many* of them, and also quite small. I would not want to to sacrifize > them for vectorization, especially not for the relatively uncommon (I think) > case of mixed type access. > @rkennke Ok, fair enough. As far as I know, we at Oracle do not super care > about strict alignment `AlignVector`. But maybe other people care, and have > to make that tradeoff between vectorization and small object headers. BTW, this problem is not specific to UseCompactObjectHeaders - I think the same problem would happen with -UseCompressedClassPointers. With uncompressed class-pointers, byte[] would start at offset 20, while long[] start at offset 24. But nobody cares about -UCCP I think. What is the failure mode, though? When running with -UCOH and +AlignVector, would it crash or misbehave? Or would it (silently?) not vectorize? I think we could live with the latter, but not with the former. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483195304
