jdk 8 怎么和 jdk 15.1 差距这么大？

[GTD]

楼主写了两个排序方法，一个是选择排序，一个是插入排序，代码肯定是没有任何问题的

在 macOS 下的 jdk 15.1，跑出来是这样的：

在虚拟机 ubuntu 的 openjdk 8 中，跑出来是这样的：

为什么会这样呢？同样一份代码，在 jdk 15.1 下，插入排序的 random array 怎么比选择排序慢了这么多？

[acmore]

从 Java 9 开始默认 GC Collector 从 Parallel GC 切换为了 G1 。再根据你切换垃圾回收策略对结果的影响来看，GC 应该是主要问题，可以找找看不同策略的侧重和注意事项。

[securityCoding]

@secondwtq jmh,压测一定要用这个

[sagaxu]

就是 gc 不同，试试 zgc 和 epsilongc

[secondwtq]

分代 GC 需要加 Write Barrier 跟踪不同代对象之间的相互引用，G1 GC 相比 Parallel GC，Write Barrier 涉及的指令更多（实际并没有触发 GC，而是多执行了 10%-20% 的指令）。

Epsilon GC 作为 placeholder，并不需要 Write Barrier 。但是直接用 Epsilon GC 效果并不会更好，原因应该是 C2 犯了傻逼，在 JIT 时把一个判断子类型的检查提到了外面，正常情况这个检查不会被触发，但是只要被触发很有可能失败，所以 JIT 的函数没法用，只能用 OSR 的。OSR 的循环并没有 JIT 更优化，特别是 CompressedOops 这时又占了很多指令，用 -XX:-UseProfiledLoopPredicate 可以把这个行为纠正回来（ JDK 8 好像没有这个参数）。再加 -XX:-UseCompressedClassPointers 可以进一步减少指令数。
（或者可以不用 -XX:-UseProfiledLoopPredicate，换成 -XX:-UseCompressedOops，但是这样还是会跑 OSR 循环，效果不如 JIT 好，尤其是变量 t 的访问没有优化）

至于为啥倒霉的是插入排序，因为只有插入排序才需要在 inner loop 里面折腾引用值的赋值。别问，问就是天灭 Type Erasure，退 Java 保平安。祝楼主早日获得新生。