x86: Implement String.hashCode with vectorizedHashCode()

[BradleyWood]

Leaving as draft until #21000 is resolved.

[BradleyWood]

@vijaysun-omr Would you mind reviewing?

[vijaysun-omr]

Looks fine to me, but I'll also get @0xdaryl to look since this is x86 codegen

[0xdaryl]

Seems like a good change to me.

[vijaysun-omr]

If/when the WIP is taken off this PR, one of Daryl or I can start testing, thanks.

[BradleyWood]

@vijaysun-omr @0xdaryl I have undrafted this PR. The fix for #21000 was merged in OMR (not promoted yet)

[vijaysun-omr]

jenkins test sanity all JDK21

[BradleyWood]

@vijaysun-omr I am seeing erroneous NullPointerExceptions and NoClassDefFoundError, I couldn't find any know issue for the way these are produced. I think a string hashCode() problem could easily cause these kinds of issues. I also noticed that since OMR hadn't promoted at the time you launch the build (it has now), the fix for #21000 was not in the build. I would suggest relaunching the build now that OMR has promoted, and if the same issues reproduce, a further investigation is warranted.

[vijaysun-omr]

jenkins test sanity all JDK21

[BradleyWood]

@vijaysun-omr Build looks good to me.

I count 1 CRIU issue, 2 infrastructure issues, and 1 other known issue.

CRIU

Infrastructure - sha checksum error

Infrastructure - ubu24-x86-1: Name or service not known

cmdLineTester_jfr_0 - #21181

[pshipton]

Causing failures on 32-bit.

Assertion failed at /tmp/bld_88867/bld_linux_x86/compiler/../omr/compiler/x/codegen/OMRMachine.cpp:558: considerVirtAsSpillCandidate
VMState: 0x0005ff06
	freeBestGPRegister(): could not find any GPR spill candidates for VRF_0xce6f9070

[pshipton]

Reverted via #21199

[BradleyWood]

That assert sounds like the register assigner is trying to spill a vector register into a general purpose register 🤦

[BradleyWood]

This could be a 64 bit issue too. It's possible there is low register pressure on 64-bit due to the extra vector registers.

[BradleyWood]

@vijaysun-omr @0xdaryl VectorHashCode is capable of using more vector registers then are available on 32-bit mode. There is a bug somewhere in assigning registers for register dependency conditions, where if more registers of the same type are listed (even without requesting specific registers) that it fails to spill registers where needed.

I was able to reproduce the issue on 64-bit by adding a few extra vector registers to the register dependency conditions and keeping them live across the entire function. If you do not add them to the register dependencies conditions, there is no issue, and spilling happens when needed. This issue shouldn't be able to reproduce organically on 64-bit because we currently support 16 vector/fpr/gpr registers, and no intrinsic uses that many registers.

I have opened an issue: eclipse-omr/omr#7672