RFR: 8331098: [Aarch64] Fix crash in Arrays.equals() intrinsic with -CCP [v4]

Roman Kennke rkennke at openjdk.org
Tue May 7 11:07:54 UTC 2024


On Tue, 7 May 2024 08:17:43 GMT, Andrew Haley <aph at openjdk.org> wrote:

> This still looks too complicated for such a simple thing. Why not read the whole array, fully aligned, until the final word (at start+length*elementSize-wordSize) which is possibly unaligned? That would work regardless of alignment. Check the lengths agree first, and the first whole read may or may not include the length field.

I disagree. This means we would access the length 2x unconditionally (at least in the -CCP/Lilliput path), and need to generate extra code (in the +CCP path for the length check, in the -CCP path to also increase the cnt2 length counter). I suspect that reading lengths 2x could add up pretty quick when comparing short arrays (which is pretty common, e.g. strings).

What we *could* do instead is unconditionally compare the lengths in the loop. This means that in the +CCP path, we would also have to compare the compressed Klass*, but I think this should be ok. I don't think that 8-byte loads are any slower than 4-byte loads, and we're actually saving the extra instructions ahead of the loop. And we would not have 2 different paths for -CCP vs +CCP.

What do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/18948#issuecomment-2098139105


More information about the hotspot-dev mailing list