计数/未数的循环和安全性 - 是`while（＆＃x2b;＆＃x2b; i＆lt; someinint）`被考虑到未数的循环吗？

Question

我正在阅读这篇文章在上计数/未数循环和SafePoints。
它告诉我的是，对于无数循环，将有SafePoint Colls，这意味着无数环的性能比计数循环差。

在博客中有一个交织代码：

// 4. Should be counted, but treated as uncounted
int i = 0;
while (++i < reps) {
  // ...
}

// 5. Should be counted, but treated as uncounted
while (i++ < reps) {
  // ...
}

// 6. Should be counted, and is!
while (i < reps) {
  // ...
  i++;
}

基本上说在中进行变量增量，而（无论是i ++ 或++ ++ i）将使您的循环被视为无数循环。
鉴于此，我想对于绩效关键代码，我应该避免这样做吗？

其他问题是，由于循环展开，JVM不会进行SafePoint Colls进行计数？还是JVM足够聪明，即使没有循环展开，也不会这样做？

Answer 1

本文看起来已经过时了。
在现代JDK中，帖子中提到的所有6个循环都被计算在内：

// 1
for (int i = 0; i < reps; i++) { ... }

// 2
for (int i = 0; i < int_reps; i+=2) { ... }

// 3
for (long l = 0; l < int_reps; i++) { ... }

// 4
int i = 0;
while (++i < reps) { ... }

// 5
while (i++ < reps) { ... }

// 6
while (i < reps) { ...; i++; }

带有long变量的循环＃3在JDK 16中计数（由于 jdk-8223051 ）。自JDK 8以来，所有其他循环都被视为计数

。我使用以下程序来验证以下选项

public class LoopTest {

    public static void main(String[] args) throws Exception {
        int[] array = new int[1000];
        fill(array);
        System.out.println(Arrays.stream(array).sum());
    }

    static void fill(int[] array) {
        int reps = array.length;

        int i = 0;
        while (++i < reps) {
            array[i] = i * i;
        }
    }
}

的运行调试构建，并具有以下选项：

java -Xcomp -XX:-TieredCompilation -XX:+TraceLoopOpts
     -XX:CompileCommand=compileonly,LoopTest::fill
     -cp ../test/out/production/test/ LoopTest

traceloopopts traceloopopts的第一行被计数：

Counted        Loop: N140/N120  limit_check predicated counted [1,int),+1 (-1 iters)

其他问题是，JVM不会将SafePoint池进行
计数循环是因为循环展开？

不，SafePoint民意调查与循环展开无关。

计数循环的声明内部没有任何SafePoint Coll，也已经过时了。 loop strip挖掘 JDK 10中实现的允许JIT编译器将大型计数分为两个嵌套的环路：内部（热）一个没有SafePoint Coll指令的人，而外部则是SafePoint Coll。

例如，

for (int i = start; i < end; i++) {
   // loop
}

将这种优化转换为类似的东西，

for (int p = start; p < end; p += 1000) {
    for (int q = 0; q < 1000; q++) {
        int i = p + q;
        // loop
    }
    safepoint_poll();
}

降低了Safepoint Comhering的开销，同时使对任意大型计数循环的时间延迟延长。

最新的热点JVM在优化大多数计数循环的优化方面足够聪明，因此您通常不需要自己关心这个循环。

Answer 2

您链接到的博客发布的问题是，作者没有清楚地说明他们正在查看的Java版本。

安全点的放置详细信息绝对是JVM版本的特定于JVM版本。如果可以在位置不好的地方确定简单（和现实的）示例，那么我想，Java维护者将弄清楚如何使优化器更聪明。因此，要知道（事先）问题是否会影响您，您将知道您正在使用与作者相同的JVM版本。显然，字节码编译器版本也很重要……根据下面的评论

---

Q：您是否应该修改编码样式以避免（根据博客发布）不当的情况？

答：我的建议通常是 - 否：

1. 问题可能已经解决了您正在使用的Java版本中。
2. 该问题可以用新版本的Java或即将发布的未来版本解决。 进行大修的努力要小。
3. （升级要比对代码

但是，如果您＆lt;基准您的应用程序和您＆gt; do＆lt;发现安全点问题具有可测量的效果，一定要调整应用程序中的循环，即受影响的循环，以及2）热点。 （但不是您所有的循环！这可能是浪费时间。）

简而言之……提防过早优化。