JIT优化预防技术

Question

在java-8源代码中，我们可以在类Class中找到相当复杂的JIT优化方法。

/*
 * Private constructor. Only the Java Virtual Machine creates Class objects.
 * This constructor is not used and prevents the default constructor being
 * generated.
 */
private Class(ClassLoader loader) {
    // Initialize final field for classLoader.  The initialization value of non-null
    // prevents future JIT optimizations from assuming this final field is null.
    classLoader = loader;
}

因此，这个构造函数从未被调用过，但是JIT将被这个技巧“欺骗”。

我的问题是:它是否能以稍微不同的方式来实现呢？

private Class() {
    classLoader = (ClassLoader)(new Object());
}

这绝对是毫无意义的逻辑，但如果构造函数永远不会被调用，有关系吗？

这样的伎俩也会阻止JIT进行这种优化吗？

Answer 1

在Java6和Java 7(更新40之前的Java 8)中，构造函数与private Class() {}一样简单，但是在这些版本中也没有classLoader字段。

这意味着Class和ClassLoader之间的关联必须以特定于JVM的方式维护，因此，getClassLoader()必须调用native方法，不一定涉及JNI，而是作为JVM内部操作处理，但仍然需要在JVM的本地代码中进行特殊处理。此外，垃圾收集器必须了解这种特殊的关系。

相反，在反射中隐藏字段并不那么复杂，而现在有一个普通字段简化了JVM的本机代码，最显著的是getClassLoader()操作和垃圾回收器实现。如果优化器是一个普通字段，那么内联字段访问也可能更简单。

现在，当Class对象是通过特定的JVM代码创建的，而不是使用声明的构造函数时，它可能与通过分析构造函数的实际代码来预测这个final字段的可能值而进行的优化JIT假设相矛盾。

请注意，没有人说当前的JIT是那么聪明。这篇评论谈到了假设的“未来JIT优化”。使用参数值初始化字段的构造函数与JVM的实际操作是一致的。

相反，像您建议的classLoader = (ClassLoader)(new Object());这样的构造函数可能导致假设的优化器得出结论，即不能用实际的ClassLoader实例初始化该字段，因为该代码永远无法正常完成。

Answer 2

“classLoader源”中的评论指出，初始化值使未来的JIT优化知道字段不是空的。因此，优化器将来可能会做得更好。

要防止优化，只需声明字段volatile。