On Sat, 12 Nov 2022 15:27:09 GMT, Piotr Tarsa <d...@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
