RFR: 8139457: Array bases are aligned at HeapWord granularity [v33]

[Roman Kennke]

On Tue, 15 Aug 2023 14:14:01 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> I was looking at this again, and my review is NOT a full review.  I only reviewed the metadata changes.
>
> I think it'd be a good time to move this forward and get it into jdk22 asap, as preparation for the upcoming Lilliput. As far as I can tell, this PR is in good shape now. @coleenp and others, what do you think?

> @rkennke I have not yet had a chance to look at the code in detail here. But have you considered the impact on SuperWord yet?
> 
> First about terminology. In SuperWord, we talk about the `base`, which is the beginning of the array object, but not where the first entry starts (at some "base" = `base + offset`). You (or at least the title of the RFE) seem to call the "base" where the first entry starts.
> 
> I see that with `-XX:-UseCompressedClassPointers`, before we used to have:
> 
> ```
> UNSAFE.ARRAY_BYTE_BASE_OFFSET: 24
> UNSAFE.ARRAY_SHORT_BASE_OFFSET: 24
> UNSAFE.ARRAY_INT_BASE_OFFSET: 24
> UNSAFE.ARRAY_LONG_BASE_OFFSET: 24
> ```
> 
> and now have:
> 
> ```
> UNSAFE.ARRAY_BYTE_BASE_OFFSET: 20
> UNSAFE.ARRAY_SHORT_BASE_OFFSET: 20
> UNSAFE.ARRAY_INT_BASE_OFFSET: 20
> UNSAFE.ARRAY_LONG_BASE_OFFSET: 24
> ```
> 
> I looked at a simple byte array loop. And I do see that without this patch, the memref has an `offset = 24`, and with you patch a `offset = 20`. So to me that means that SuperWord gets the correct information, and can do the alignment checks with this correct information.
> 
> At first the title had me worried, because in SuperWord we do assume that the `base` is aligned, and the title here suggests that you are about to break that. But as mentioned above `base` != "base".
> 
> Still, there may be some subtle alignment differences now. The offsets are moved by 4 bytes for some types. That could have some impact on what vectorizes when `-XX:+AlignVector` or on platforms where `Matcher::misaligned_vectors_ok() = false`. But that is probably not bad enough to block this change here. What do you think @fg1417 @vnkozlov ?

Thanks Emanuel, for checking how this PR affects superword opts. I have checked that superficially earlier, but not in such depth. Do you have any tests or benchmarks which you can recommend which exercise these sort of optimizations and which may give some insight on the performance impact (if any)?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11044#issuecomment-1680909105