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