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 内部构件感兴趣的读者可以从那里了解更多细节，从中可以了解到，当前的工作距离供大多数开发人员使用还有很长的路，该项目仅是原型阶段。
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论