java - 为什么 Hotspot JIT 不为长计数器执行循环展开？

Question

我刚刚阅读了 Java 杂志文章 Loop Unrolling .作者在那里演示了简单的 for带有 int 的循环计数器是用循环展开优化编译的:

private long intStride1()
{
    long sum = 0;
    for (int i = 0; i < MAX; i += 1)
    {
        sum += data[i];
    }
    return sum;
}

然而，他们随后表明，通过将计数器类型切换为 long，一切都会发生变化。 :

private long longStride1()
{
    long sum = 0;
    for (long l = 0; l < MAX; l++)
    {
        sum += data[(int) l];
    }
    return sum;
}

这会通过以下方式更改输出程序集:

介绍安全点

不执行展开

这会显着降低吞吐量性能。
为什么 64 位 HotSpot VM 不为 long 执行循环展开柜台？为什么第二种情况需要安全点，而第一种情况不需要？

Answer 1

从 JDK 16 开始，HotSpot JVM 支持循环展开和对具有 64 位计数器的循环进行其他优化。
JDK-8223051的说明回答您的两个问题:

Many core loop transformations apply to counted loops, which are thosewith a calculated trip count. Transformations include unrolling,iteration range splitting (array RCE), and strip mining (JDK-8186027).The optimizer performs many complicated pattern matches to detect andtransform counted loop.

Most or all of these pattern matches and transformations apply toloops with 32-bit control variables and arithmetic. This makes senseas long as bulk operations apply only to Java arrays, since thosearrays can only span a 31-bit index range. Newer APIs for largerblocks of bulk data will introduce 64-bit indexes, such as Panama'snative arrays and (possibly) range-expanded byte buffers. Under thehood, the Unsafe API routinely works with 64-bit addresses and addressarithmetic. Loops which work on such data structures naturally use64-bit values, either as direct Java longs, or as wrapped cursorstructure with incrementing long components (Panama pointers).

There needs to be a story for transforming such long-running loops.This RFE is a request for that story.

A complicating factor is that sometimes counted loops have nosafepoints, on the assumption that the largest possible iteration(across 32 bits of dynamic range) won't cause the JVM's safepointmechanism to malfunction due to a non-responsive thread stuck in sucha counted loop. This assumption is invalid in the 64-bit case.Luckily, we have a (relatively new) optimization which can addressthis problem, by strip-mining a single very long running loop into asequence (outer loop) of loops of with appropriately bounded tripcounts.