OpenJ9项目中DoubleToDecimalTest测试超时问题的技术分析

问题背景

在OpenJ9项目的持续集成测试中，发现了一个关于jdk/internal/math/ToDecimal/DoubleToDecimalTest.java测试用例的超时问题。该问题主要出现在aarch64和x86架构的Linux/Mac系统上，且与Balanced GC策略相关。测试会在执行过程中卡住，最终因超时而失败。

问题现象

测试失败时，线程堆栈显示主线程卡在jdk.internal.math.FloatingDecimal$ASCIIToBinaryBuffer.doubleValue方法中。从多个失败的测试日志中可以看到，测试在处理特定数值"9.999999999999E82"时会出现问题。

技术分析

1. 测试用例分析

DoubleToDecimalTest测试主要验证浮点数到十进制字符串的转换功能。测试包含多个子测试，其中testPowersOf10子测试会遍历约130万个不同的测试值。正常情况下，整个测试执行时间约为65秒，其中testPowersOf10部分约占20%的时间。

2. 根本原因定位

经过深入分析，发现问题出在FDBigInteger.mult方法的JIT编译过程中。该方法包含一个嵌套循环结构，用于执行大整数乘法运算。在Scorching优化级别下，JIT编译器对循环进行了不正确的优化。

具体来说，问题出现在循环步幅(LoopStrider)优化阶段。编译器错误地将数组数据地址计算(dst[i + s2Len])中的s2Len加法操作提升到了循环外部，但却遗漏了s2Len的加法部分(在本例中s2Len是常量24)。这导致计算结果错误，进而引发了后续的无限循环。

3. 代码细节

问题方法的核心代码如下：

private static void mult(int[] s1, int s1Len, int[] s2, int s2Len, int[] dst) {
    for (int i = 0; i < s1Len; i++) {    // 外层循环
        long v = s1[i] & LONG_MASK;
        long p = 0L;
        for (int j = 0; j < s2Len; j++) {    // 内层循环
            p += (dst[i + j] & LONG_MASK) + v * (s2[j] & LONG_MASK);
            dst[i + j] = (int) p;
            p >>>= 32;
        }
        dst[i + s2Len] = (int) p;  // 问题出在这一行的地址计算
    }
}

在优化前，dst[i + s2Len]的地址计算是完整的。但在优化后，编译器将dst的基地址提升到了循环外部的临时变量中，却错误地省略了s2Len的加法部分。

4. 潜在风险

除了已经发现的无限循环问题外，这种优化方式还存在另一个潜在风险：在OffHeap场景下，将数据地址指针(dataAddrPtr)存储在临时变量中，而循环体内又包含异步检查点(asynccheck)，可能会触发GC。如果在GC发生时临时变量中仍持有数据地址指针，可能导致程序崩溃。

解决方案

针对这个问题，修复方案需要从以下几个方面考虑：

1. 修正LoopStrider优化阶段对数组地址计算的处理，确保不会错误地省略必要的加法操作。

2. 在OffHeap场景下，需要特别处理数据地址指针的存储方式，避免在可能触发GC的点上持有这类指针。

3. 增加对类似优化模式的验证机制，确保优化后的代码语义与原始代码保持一致。

总结

这个案例展示了JIT编译器优化可能带来的微妙问题。即使在处理看似简单的循环结构时，优化也可能引入难以察觉的错误。对于虚拟机开发者而言，这类问题特别具有挑战性，因为它们通常只在特定条件下才会显现，且难以通过常规测试发现。

通过这个问题的分析，我们也看到在编译器优化过程中，对内存访问模式的正确处理至关重要。特别是在涉及数组访问和指针运算时，需要格外小心确保优化不会改变程序的原始语义。