OpenJ9项目中虚拟线程与原始监视器的交互问题分析

在OpenJ9项目的最新开发过程中，我们发现了一个关于虚拟线程(Virtual Thread)与原始监视器(Raw Monitor)交互的重要技术问题。这个问题出现在JDK24版本中，当启用YieldPinnedVirtualThreads特性(JEP491)时，会导致服务性测试RawMonitorTest失败。

问题背景

虚拟线程是Java平台引入的轻量级线程实现，而原始监视器是JVMTI(Java虚拟机工具接口)提供的一种同步机制。在OpenJ9的实现中，我们发现当前使用J9VMThread->ownedMonitorCount来同时跟踪对象监视器和原始监视器的所有权。

问题本质

问题的核心在于OpenJ9与参考实现(RI)在处理虚拟线程持有原始监视器时的行为差异。参考实现会固定(pin)持有原始监视器的虚拟线程，防止其被卸载(unmount)和重新装载(remount)。而OpenJ9当前实现允许虚拟线程在持有原始监视器时被卸载和重新装载，这导致了J9ThreadMonitor->owner指针变得无效，因为虚拟线程的J9Thread结构可能在卸载/重新装载过程中发生变化。

技术细节

更深入地说，当前OpenJ9实现存在以下技术限制：

1. 缺乏有效机制来跟踪虚拟线程拥有的原始监视器
2. 在虚拟线程卸载/重新装载过程中无法可靠更新J9ThreadMonitor->owner指针
3. 这会导致JVMTI函数返回错误，如JVMTI_ERROR_NOT_MONITOR_OWNER(51)和JVMTI_ERROR_WRONG_PHASE(112)

解决方案

为了与参考实现保持一致，我们需要修改OpenJ9的行为，使其在虚拟线程持有原始监视器时固定该线程。这可以通过两种方式实现：

1. 重用现有的J9VMThread->callOutCount计数器(原本用于本地调用)
2. 引入专门用于原始监视器的新计数器

经过技术评估，第一种方案更为合理，因为它：

• 减少了内存开销
• 保持了代码的简洁性
• 利用了现有的线程固定机制

实现影响

这一改动将影响以下方面：

1. 虚拟线程的调度行为：持有原始监视器的虚拟线程将不再被卸载
2. 性能影响：固定线程可能轻微降低虚拟线程的吞吐量
3. 兼容性：更好地与参考实现保持一致

总结

通过对OpenJ9中虚拟线程与原始监视器交互问题的分析，我们理解了参考实现与OpenJ9实现之间的关键差异。采用固定持有原始监视器的虚拟线程策略，不仅解决了测试失败问题，还提高了与标准实现的一致性。这一改进已经通过多个Pull Request实现，并重新启用了相关测试用例。

这个案例展示了在实现新Java特性时，保持与参考实现行为一致的重要性，特别是在涉及线程同步和JVMTI交互等复杂场景下。