On Mon, 18 Nov 2024 14:23:24 GMT, Roman Kennke <rken...@openjdk.org> wrote:
>>> @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. @rkennke It just will (silently) not vectorize, thus running slower but still correct. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483202341
