java - 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

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

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

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

---

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

请注意，没有人说当前的 JIT 如此智能。该评论谈到了假设的“ future 的 JIT 优化”。让构造函数使用参数值初始化字段符合 JVM 的实际操作。

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