On Mon, 7 Oct 2024 22:40:37 GMT, Sandhya Viswanathan <sviswanat...@openjdk.org> wrote:
>> Yes, and that is intentional. >> >> Say, haystack_len is 7, then the first block computes the adjustment of the >> haystack, which is 8 - (7 % 8) = 1. We adjust the haystack pointer one byte >> down, so that when we copy (multiple of) 8 bytes, we land on the last byte. >> We do copy a few bytes that are preceding the array, which is part of the >> object header and guaranteed to be >= 8 bytes. >> >> Then we compute the number of words to copy, but make it 0-based. That is >> '0' is 1 word, '1' is 2 words, etc. It makes the loop nicer. In this example >> we get 0, which means we copy one word from the adjusted haystack, which is >> correct. >> >> Then comes the actual loop. >> >> Afterwards we adjust the haystack pointer so that it points to the first >> array element that we just copied onto the stack, ignoring the few garbage >> bytes that we also copied. > > @rkennke Thanks for the explanation. I attach here a fix which is an > extension of existing way of copying while taking care of the smaller object > header. Also there are two instances of this in the intrinsic so I have > factored the new code into a method and call it from both the places. > [indexof_fix.patch](https://github.com/user-attachments/files/17285239/indexof_fix.patch) Thank you, @sviswa7! Yes this fix looks correct. I've intergrated it into this PR and re-enabled the indexOf intrinsic for compact headers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1791328427
