Oracle OpenJDK团队已经发布了Valhalla项目LW2原型的早期访问（EA）构建版本（也称为“内联类”，以前称为“值类型”）。

该原型可以在这里下载，其目的是在未来几周内定期通过Bug修复和性能升级来更新二进制文件。

团队正在积极地寻找关于用户模型的反馈，并提醒说，该实现的许多主要方面还没有准备好接受检查。

LW2的命名表明内联类特性的实现已经达到了“L-World”设计的第二个里程碑。

当前原型通过使内联类型尽可能地与现有对象和接口（即L-Type系统或“L-World”）相似，将内联类型合并到现有类型系统中。

该原型于2019年7月5日发布，取代了之前的LW1里程碑。它将Valhalla和内联类的初步实验提供给更多的开发人员，尽管它仍然是非常实验性的。

它还迈出了重新审视泛型的第一步——其语法允许将内联类的可空引用投影（projections）用作泛型类型的参数。

由于这是一个早期原型，有一些限制，包括：

仅在x64 Linux、x64 Mac OS X及x64 Windows上可用；
不支持包含间接类型的原子字段；
不支持@Contended内联类型字段；
只支持解释器和C2，不支持C1，没有分层编译，也没有Graal；
内联类型没有不安全字段和数组访问器API；
解释器还没有优化，其重点是C2 JIT优化。

InfoQ就LW2的发布采访了Dan Heidinga（IBM Eclipse OpenJ9项目负责人）。

InfoQ：您认为LW2中最重要的新特性是什么？

Dan Heidinga：LW2早期访问构建给我们带来了很多东西，其中最重要的是内联类型的用户模型。以前的原型是用MethodHandles来定义的，有很高的进入门槛。

使用以前的原型编写重要的代码太困难了，即使对于MethodHandle专家来说也是如此，这使得提供反馈非常困难。LW2不同。它的目的是对用户友好，以便开发人员能够测试模型，了解内联类型如何工作，并向专家组提供反馈。

一个特别重要的特性是内联类型运算符“?”的引入，它允许用户显式地选择内联类型是要内联的候选类型，还是应该使用间接类型。

它还支持将内联类型与Java的集合库一起使用，这再次提高了开发人员使用原型的体验。只允许泛型使用“?”或者LW2中类型的可空版本，我们为将来的改进留有余地，比如内联类型的具体化泛型。

InfoQ：您能解释一下内联类与逃逸分析的关系吗？为什么这对性能很重要？

Heidinga：逃逸分析是一种JIT优化，它试图证明一个对象的生命周期完全包含在当前的编译单元中，不会“逃逸”到堆、另一个线程，甚至不会超出当前内联方法集的范围。

如果JIT能够证明对象没有逃逸，那么它就可以将对象分割成一组独立的字段。然后可以将它们放入寄存器中，以获得更好的优化机会，或者可以在栈而不是堆上分配对象。这两种方法都提供了更好的优化机会，并减少了垃圾收集的压力，因为对象永远不会结束在堆上。

虽然这听起来很棒，但并无保证。优化可能会失败，原因有很多——比如没有在方法中内联足够多的调用以确保对象真得没有逃逸，或者在给定的编译操作中可能无法运行。这可能是因为较低层的编译可能会跳过一些昂贵的优化以获得更快的代码编译速度。不仅如此，对代码的微小更改可能会导致对象逃逸，使优化无法成功，从而导致性能下降，而又没有明显的原因。

内联类是不可变的，没有标识。这使得这些类型成为逃逸分析的理想候选类型，因为JIT不再需要证明它们没有逃逸。它可以自由地将它们分割、放入寄存器并优化它们，但是它需要这样做，因为它总是可以在任何可能逃逸的位置重新构造内联类型。这里的关键是，由于内联类型没有标识，所以无法判断它们是否被重新创建。这消除了传统逃逸分析中的许多脆弱性。

在大多数程序中，有许多小类充当其他数据的封装器，这些小类将受益于这种有保证的逃逸分析。考虑下代码中封装int、long或String以赋予它们额外语义的位置。如果JIT能够栈分配所有这些实例不是很好吗？这是内联类型取得成功的部分原因。

InfoQ：内联类的实例是不可变的，所以您能解释一下为什么这会导致更新原子性问题吗？为什么我们不能使用乐观副本和比较与交换（CAS）来交换指针呢？

Heidinga：请记住，项目的口号是“让和类一样的代码像int一样工作”。当将一个基本的int类型写入局部变量、字段甚至数组时，我们不修改int类型。相反，我们覆盖了全部内容。LW2的内联类就是以这种方式像基本类型一样工作。

虽然这在概念上是一个干净的模型，但是它重新引入了一个自从64位系统成为常态以来Java开发人员一直都可以忽略的问题：分裂（tearing），也就是非原子更新。

回顾早期32位Java实现处理long或double的方式有助于理解这个问题。CPU保证其本机字大小的写操作是自动发生的。在一个32位系统上写32位是不会分裂的。但long是64位的，这意味着它不能在没有向硬件发送特别请求的情况下在32位系统上自动写入。

Java语言规范在“17.7. Double和long的非原子处理”这一节中承认了这一点：

就Java编程语言内存模型而言，对非易失性long或double值的一次写操作被视为两次单独的写操作：

一次32位。这可能导致这样一种情况：一个线程从一次写入中看到了这个64位数值的前32位，从另一次写入中看到后32位。

内联类会将分裂问题重新带回到用户需要关注的问题集里，因为内联类型的读写必须复制该类型的全部内容。

这里有一个例子来帮助理解为什么内联类的分裂对开发人员来说是一个新问题。

考虑内联类Customer：

    inline class Customer {
        String firstName;
        String lastName;
        long customerID;
    }

以及一个用于跟踪前三名客户的数组：

    Customer topCustomers[3];

该数组由两个线程并发访问。第一个线程尝试将一个新客户写入数组：

    Customer c = getTopCustomer();
    topCustomers[0] = c;

同时，第二个线程则尝试读取数组：

    Customer b = topCustomers[0];

如果读和写同时发生，则有可能读取到一个新老客户合并而成的客户，从而产生一个不可能的客户对象。这是一次数据竞争，但在此之前（大部分情况下）是良性的，因为运行时一直在数组中原子性地用一个指针替换另一个指针。

一旦内联类型大于处理器提供的最大原子更新（通常是字长的两倍，所以64位系统上是128位），那么分裂就成为一个潜在的问题——如果内联类型上有任何数据竞争的话。内联类型太大，CAS无法成功，因为它需要更新整个内容，而不仅仅是指向它们的指针。由于该类型的所有内容都内联在容器中，所以没有方便更新的指针。

Valhalla专家组仍在研究如何将内联类型标记为“原子类型”，这样它们就只能以不可分裂的方式写入，这将解决其中的一些问题，但是LW2目前还没有包含这个建议。

内联类型的设计建议，内联类型应该是很小的数据聚合（此处的关键字是“小”），分裂是提出这项建议的另一个原因。

InfoQ：您认为目前开发人员社区对内联类的最大误解体现在哪一方面？

Heidinga：我将给出两个答案。第一个常见的误解是内联类型是可变的，就像C的结构一样。虽然IBM的PackedObjects或Azul的ObjectLayout等早期建议支持可变类型，但LW2的内联类型严格来说是不可变的。这是Java新特性的总体趋势的一部分，它支持不变性，以便更容易编写正确的并发应用程序。

第二个常见的误解是内联类型让用户显式地控制对象的布局。内联类型允许用户要求JVM将数据直接内联到容器中（对象或数组），但不允许用户控制类型中字段的布局。布局算法仍然完全在JVM的控制之下，JVM可能会对字段进行重新排序，从而对它们进行分组，从而提高垃圾收集的效率。

InfoQ：您还有其他什么想和我们的读者分享吗？

Heidinga：在LW2早期访问二进制文件和经过更新的JVM规范中有很多内容。请查看并给我们提供反馈。在设计中有许多打开的问题，我们期待你关于该设计在你的用例中表现如何的经验报告。

我们正在寻求反馈的一些领域包括==对于内联类型的行为、在Object[]和内联类型数组之间引入的数组协方差，以及你在你的代码库中试验内联类型时的体验。

Valhalla项目的LW2二进制文件现在已经发布，并且正在积极地寻求来自普通Java开发人员的反馈（在已经准备好的领域，例如用户模型）。

原文链接：

OpenJDK Project Valhalla Releases LW2 Prototype

创作场景

OpenJDK 项目 Valhalla 发布 LW2 原型