RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v13]

[Claes Redestad]

On Sat, 12 Nov 2022 15:27:09 GMT, Piotr Tarsa <duke at openjdk.org> wrote:

> Out of curiosity: how does this intrinsic affect time-to-safepoint? Does it matter? I don't see any safepoint poll, but then I don't precisely know how safepoints work, so I could be missing something. Theoretically, with 2^31 elements count limit in Java, the whole computation is always a fraction of a second, but maybe it would matter with e.g. ZGC, which could ask for a safepoint while the thread is hashing an array with 2 billion ints.

This intrinsic - like several others before it - does not add safepoint checks. There's at least one RFE filed to address this deficiency, and hopefully we can come up with a shared strategy to interleave safepoint checks in the various intrinsics that operate over Strings and arrays: https://bugs.openjdk.org/browse/JDK-8233300

When I brought this up to an internal discussion with @TobiHartmann and @fisk last week several challenges were brought up to the table, including how to deal with all the different contingencies that might be the result of a safepoint, including deoptimization. I think enhancing these intrinsics to poll for safepoints is important to tackle tail-end latencies for extremely latency sensitive applications. In the meantime those applications could (should?) turn off such intrinsics, avoid huge arrays altogether, or both.

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

PR: https://git.openjdk.org/jdk/pull/10847