[GR-37191] Record equals/hashCode use reflection

[TheMode]

Describe the issue
Record equals (and I assume hashCode, even if untested) currently use reflection, and effectively run much slower (about x10-20 in my case compared to my specialized method comparing the fields directly)

Describe GraalVM and your environment:

• GraalVM 22.0.0.2
• JDK major version: 17
• OS: Linux/PopOS
• Architecture:AMD64

More details
I have noticed the issue due to a hot path in my code being weirdly expensive:
https://github.com/Minestom/Minestom/blob/2c0b026e46f271a88cd9824e00f211c25980a7f1/src/main/java/net/minestom/server/listener/PlayerPositionListener.java#L36
https://github.com/Minestom/Minestom/blob/2c0b026e46f271a88cd9824e00f211c25980a7f1/src/main/java/net/minestom/server/entity/Entity.java#L1239
(notice the Pos#equals calls)

Flamegraph obtained with perf:

[TheMode]

Is there any plan to "fix" it? It does make native-image unsuitable for any jdk16+ project, and seem to be, I assume, easily fixable.

[oubidar-Abderrahim]

Hi, Thank you for reporting this, We will take a look into it and get back to you.

[oubidar-Abderrahim]

Tracked internally on GR--37191

[loicottet]

This is due to our current method handle implementation, which uses reflection internally and has quite poor performance as a result. We are planning on changing this implementation in the near future, which should make this code run faster.

[TheMode]

What about specializing those record methods to do not use method handles? I assume that it would give you more implementation freedom.

[loicottet]

The problem is that these record methods do not simply use method handles, they are method handles. This makes it more difficult to substitute them out, since we would have to generate alternative methods for every record class in the image. We also want to introduce substitutions only when strictly necessary, and will therefore primarily focus on improving the performance of our method handle implementation.

[TheMode]

My issue in this case is that improving the performance of method handles may not be enough, as equals/hashCode are likely to be present in a lot of hot path. I would consider it a bug for my hand-coded methods to perform better.

I can however understand that exceptions to the rule are not always desirable.

[loicottet]

Our goal for this reimplementation would be to use JDK-generated, optimized bytecode method handle invokers when the handle is known at build time, which is the case for record methods. We expect to see a performance similar to a hand-written method in that case.

[kkriske]

What is the current state of this? Did the mentioned rewrite happen or is there possibly an indication of a timeline when it will happen?

[loicottet]

This is still on the to-do list with a fairly high priority, but there is no fixed timeline for this change yet.