OpenJ9 JIT优化System.nanoTime导致Liberty InstantOn事务超时问题分析

在Liberty应用服务器25.0.0.4版本的InstantOn功能中，我们发现了一个在zLinux/s390x架构OpenShift平台上特有的问题：当部署InstantOn检查点镜像应用时，服务器启动过程中会出现jakarta.transaction.TransactionRolledbackException: Transaction is ended due to timeout异常。经过深入调查，我们发现这与OpenJ9 JIT编译器对System.nanoTime方法的特殊处理有关。

问题现象

在zLinux OCP环境中，Liberty InstantOn服务器启动时，事务处理会在120秒后超时并回滚。从日志中可以观察到以下关键信息：

1. 事务超时警告：WTRN0006W: Transaction has timed out after 120 seconds
2. 最终抛出异常：jakarta.transaction.TransactionRolledbackException: Transaction is ended due to timeout
3. 问题仅出现在zLinux OCP环境，其他平台不受影响

根本原因分析

通过对比测试，我们发现：

1. 使用-Xnoaot参数(禁用AOT编译)时，问题不再出现
2. 当限制AOT编译代码加载时，问题复现率显著降低
3. 关键方法java/util/concurrent/ScheduledThreadPoolExecutor$ScheduledFutureTask.getDelay的AOT编译存在问题

深入分析AOT编译日志发现，JIT编译器对System.nanoTime方法进行了特殊处理。在zLinux架构上，这个处理会使用s390x特有的指令来获取高精度时间。

技术细节

在AOT编译过程中，JIT编译器识别到System.nanoTime调用，并生成了如下处理代码：

STCKF    Auto[<temp slot 3>] ?+0(GPR5)
LG      GPR_0037, Auto[<temp slot 3>] ?+0(GPR5)
LARL    GPR_0038, &<LiteralPool Base Address>
SLG     GPR_0037,#457 =X(7d91048bca000000) 0(GPR_0038)
SRLG    GPR_0037,GPR_0037,1

这段处理代码直接使用s390x的硬件指令来获取时间，而不是通过常规的Java方法调用路径。在InstantOn的检查点/恢复场景下，这种处理可能导致时间计算出现偏差，进而引发事务超时。

解决方案

经过验证，我们确认以下解决方案有效：

1. 在AOT编译阶段，针对zLinux平台调整对System.nanoTime的处理方式
2. 或者在InstantOn模式下，阻止加载包含此类处理的AOT代码

临时解决方案已经通过修改OpenJ9代码实现，在20次测试运行中均未再出现该问题。长期解决方案需要考虑更精细地控制AOT代码在检查点/恢复场景下的加载行为。

影响范围

该问题影响：

• 使用Liberty 25.0.0.4及以上版本的InstantOn功能
• 运行在zLinux/s390x架构的OpenShift平台
• 使用Java 11或17的UBI9-minimal容器镜像

其他平台和架构不受此问题影响。

结论

这个问题展示了JIT编译器处理与检查点/恢复机制交互时可能出现的微妙问题。时间相关的系统调用处理在常规场景下能提升性能，但在检查点恢复场景下可能导致不一致。这提醒我们在实现系统级处理时，需要考虑各种运行时场景的特殊需求。