OpenJDK项目Valhall发布了一项，宣布了JVM值类型中一些初步的、尚处于极早期阶段的设计概念。

该项目的主要任务是“研究、孵化高级的Java JVM及语言的候选特性”。Brian Goetz解释了该项目的主要目标：

• 使JVM的内存分配模型与现代硬件的成本模型相一致； \\
• 扩展泛型，允许对所有的类型进行抽象，包括基本类型、值，甚至是void； \\
• 使现有的库，尤其是JDK，在演化的过程中保持兼容性，从而可以充分利用这些特性。\

一直到版本9，包括版本9在内，Java只有两种类型的值——基本类型和对象引用。换句话说，Java环境有意不提供内存分配的底层控制。举例来说，这意味着Java没有类似结构这样的东西，任何复合数据类型都只能通过引用访问。

这种内存分配模式在过去的20年里一直在发挥作用，是Java平台内存分配的主要实现模式。它的优点是非常简单，但伴随着大量的性能权衡，例如，对象数组的处理就涉及不可避免的间接寻址和随之而来的缓存未命中。

因此，许多性能导向的程序员会喜欢定义可以更高效分配内存的类型——值类型。

在这些新类型中，复合数据的每个数据项不需要有一个完整的对象头，这可以降低开销。消除对象头也同时消除了当前所有Java对象都具有的特定于实例的元数据。

这种方法的其中一个后果是对象标识会丢失，当且仅当所有字段都相等时值才相等。这使得值类型有和基本类型类似的行为——值的每一个副本根本就没有自己的标识。

为了顺应这一重大变化，需要引入一些新的字节码，但是目前，据说只需要新增2个操作码：

• vdefault会为特定的值类生成默认实例； \\
• withfield为值类型生成一个新值（及抛出无效值）\

部分已有的字节码也需要进行一些修改来处理值类型。

在VM层面上也需要做一些工作，以便核心库在演化过程中可以保持兼容性——例如，现在已经可以在方法中测试Object变量，看它是否真的包含值对象。

除了值类型这个简单的概念外，当前还有一些更深层次的设计问题。例如，值类型是否可以用作泛型类型的类型参数值？

如果不可以，那么这似乎会极大的限制值类型的使用。因此，有关值类型的设计讨论总是假设它们可以用作尚未确定的泛型增强形式的类型参数值。

Valhalla项目正在进行中的研究产生了以下尚处于早期阶段的设计概念。在VM层面应该有三种不同类型的JVM类及接口类型：

• 引用类型表示类实例的引用，该实例有一个标识（或者为空）； \\
• 值类型包含没有标识的值类实例； \\
• 通用类型可以是其他两种类型中的任意一种。\

这里有一个显而易见的问题——“应该如何理解现有类文件中的类型信息？”

也就是说，Java 9类文件中现有的对象类型究竟应该视为引用类型还是通用类型？这是只是个简单的例子，我们之前从未见过值类的实例。

当前的设计尚处于非常早期的阶段，还只是一个尚需数月才能成熟的提案，到生产就绪及代码交付可能还需要数年。

由于发布计划不断变化，现在还不能完全确定哪个Java版本最终会把值类型作为生产特性。

在Valhalla项目邮件列表上，相关的讨论、研究还在继续，对VM内部构件感兴趣的读者可以从那里了解更多细节，从中可以了解到，当前的工作距离供大多数开发人员使用还有很长的路，该项目仅是原型阶段。

查看英文原文：