On Tue, 11 Aug 2026 08:37:16 GMT, Volkan Yazici <[email protected]> wrote:
> Given `StringLatin1#equals(byte[], byte[])` is a duplicate of > `Arrays#equals(byte[], byte[])`, have you considered first rewiring > `StringLatin1::equals` to `Arrays::equals` (see #28717), and then optimizing > the latter? Such a direction would shave ~600 lines of duplicate code off, > ensure every optimization to `Arrays::equals` to have a wider impact, and > avoid future duplicate work in that area. Hi Volkan, That is a valid approach, although I see it as a broader architectural decision. x86 already shares much of the backend equality machinery between String and array equality. The current separation also allows AArch64 to keep highly specialized implementations for the different workloads. In particular, the current String.equals intrinsic is very small and inline-friendly, and its scalar 8-byte comparison is very effective for short strings and early mismatches, with very little setup overhead. Removing ~600 lines of duplicated source has a clear benefit. At the same time, for an intrinsic I think the generated code is an important part of the trade-off: keeping the implementations separate may give us freedom to optimize for different workload characteristics and keep the frequently used String path small and inline-friendly. I think consolidation is worth investigating separately, but it would require evaluating whether a common implementation can preserve these characteristics across different lengths and mismatch positions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/31400#issuecomment-5295563237
