On Mon, 18 Nov 2024 14:35:41 GMT, Roman Kennke <rken...@openjdk.org> wrote:
>>> @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. > > Ok, I think we can live with that for now. > > As said elsewhere, we are currently working on 4-byte-headers, which would > make that problem go away. > > The tests need fixing, though. > @rkennke > > > As said elsewhere, we are currently working on 4-byte-headers, which would > > make that problem go away. > > Ah. So we would eventually have not a `12-byte` but `8-byte` offset from base > to payload? Would that happen in all cases? And could that happen before > `UseCompactObjectHeaders` leaves experimental status? Because it is going to > be a little annoying to adjust all vectorization tests for the special case > of `UseCompactObjectHeaders + AlignVector`. Though I can surely do it. I am not sure if and when this is going to happen. When I presented the idea at JVMLS, I got some resistance. I am also not sure if we first leave experimental status for UCOH, and then introduce 4-byte headers under a new flag (or no flag?), or if we first do 4-byte headers and only leave experimental status once that is done. The latter sounds more reasonable to me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483304257
