众神进入瓦尔哈拉_一时冲动：“通往瓦尔哈拉之路的冒险”

众神进入瓦尔哈拉

通过所有有关Java 9和Project Jigsaw的讨论，我们不应忽视Java的另一重大变化。希望在第10版或第11版中， Valhalla项目能够实现并介绍价值类型和专业化。

那么，这是什么一回事，项目进展如何，面临什么挑战？几天前，Oracle的Java语言架构师和Valhalla的项目负责人Brian Goetz在JVM Language Summit 2015上的一次演讲中回答了这些问题。

我们来看一下。

总览

这篇文章将介绍Goetz演讲“冒险之路到Valhalla”的四个部分中的三个。

他以序言开头，我为那些尚不了解Valhalla项目的人提供了一些补充说明。 Goetz继续展示这两个原型，其中第一个原型于去年公开发布，而第二个原型仅在两周前发布。由于这篇文章已经足够长了，因此我将不讨论他关于未来实验的最后一部分。如果您觉得这个话题很有趣，那么一定要看整个演讲！

全文中的所有引用均来自幻灯片或逐字记录。

谈话

这里是谈话：

（顺便说一句，JVMLS团队在几个小时内就将所有讨论都在线上获得了赞誉！）

如果您可以节省50分钟，那就去看吧！然后，无需阅读这篇文章。

要点

序幕

Valhalla项目涉及的两个主要主题是价值类型和通用专业化。

值类型

前者将允许用户定义具有相同属性（如不变性，相等性而不是标识）的“类似int”的类型，以及由此产生的性能优势。它们之前是Java 8的基于值的类。

（除非另有说明，否则当本文章的其余部分讨论基元时，将包括值类型。）

通用专业化

随着每个人都声明自己的原始类型，泛型无法在它们之上工作的事实（即，没有ArrayList<int> ）引起的问题变得令人无法忍受。从概念的角度来看，虽然必须对原语进行装箱，但它具有显着的性能成本。

首先，存储对象而不是基元会花费额外的内存（例如，用于对象标头）。然后，更糟的是，装箱会破坏缓存的局部性。当CPU缓存一个Integer数组时，它仅获取指向实际值的指针。提取这些是额外的随机内存访问。当CPU主要在等待高速缓存未命中时，这种额外级别的间接开销会付出巨大的代价，并可能破坏并行化。

因此，Valhalla项目的另一个目标是扩大参数多态性的范围，以使泛型能够覆盖基元。为了获得成功，JVM应该使用基元而不是用于通用类中的通用字段，参数和返回值的框。

由于可能的实现方式，这称为通用专业化 。

因此，泛型需要与值类型很好地配合使用，并且原语可以伴随而来。

泛型的现状

由于擦除，类型变量被擦除到其边界，即ArrayList<Integer>实际上变为ArrayList<Object> （或者仅仅是ArrayList ）。这样的界限必须是所有可能实例化的超类型。但是Java在基本类型和引用类型之上没有类型。

另外，JVM字节码指令通常是正交的，即沿同一行分割。一个aload或astore只能移动引用。专业变体具有用于原语，如iload或istore为int 。没有字节码可以同时移动引用和int 。

因此，类型系统和字节码指令集都无法完成生成原语的任务。十多年前开发出仿制药时，这已广为人知，作为妥协，决定只是不允许这样做。

今天的问题来自昨天的解决方案...

兼容性！

当然，Valhalla项目下发生的所有事情都必须向后兼容。这有几种形式：

二进制兼容性：现有字节码（即已编译的类文件）必须继续表示同一意思。这样可以确保依赖项继续工作而无需重新编译。
源代码兼容性：源文件必须继续具有完全相同的含义，因此重新编译它们一定不能“仅仅因为语言已更改”而更改任何内容。
迁移可竞争性：来自不同Java版本的编译类必须协同工作，以允许一次迁移一个依赖项。

另一个要求是不要使JVM模仿太多的Java语言。这样做将迫使其他JVM语言处理Java语言的语义。

原型模型1：使其工作

大约一年前，Goetz和他的同事展示了专业化的第一个实验性实现。

想法

在此原型中，编译器继续生成已擦除的类文件，但使用其他类型信息对其进行了扩充。

VM会忽略此信息，但将由专化器使用 ，这是类加载器的新组成部分。后者将识别何时需要带有原始类型参数的类，并让专业化工具从已删除但已增强的类文件中即时生成它。

通过擦除，一个类的所有通用实例都使用相同的类文件。相反，为每种原始类型创建一个新的类文件称为specialization 。

细节

在该原型中，使用“名称处理技术”描述了专门的类。类名后面附加一个字符串，该字符串指示哪种类型参数专用于哪个原语。例如， ArrayList${0=I}表示“用第一个类型变量int实例化的ArrayList ”。

在专业化期间，必须更改签名和字节码。为了正确地做到这一点，专门化者需要知道哪些Object出现（所有通用类型都被擦除了）必须专门化为哪种类型。所需的签名信息已经大部分存在于类文件中，并且原型使用附加的类型元数据注释字节码。

从Goetz的8:44起，我们给出了几个如何进行的示例。他还使用它们来指出这种实现必须要注意的一些细节，例如泛型方法的主题。

我知道那是很多快速的挥手。关键是，这很简单，但是却有很多复杂性。

摘要

该实验表明，基于类文件元数据的即时专业化无需更改虚拟机即可工作。这些都是重要的成就，但也有不利的弊端。

首先，它需要实现一组复杂的细节。

其次，也许是最重要的是，它具有有问题的类型系统特征。在不更改VM的情况下，仍然没有int和String公共超类型，因此也没有ArrayList<int>和ArrayList<String>公共超类型。这意味着无法声明“ ArrayList任何实例化”。

第三，这具有可怕的代码共享属性。即使ArrayList<int>和ArrayList<String>大部分代码是相同的，也可以在ArrayList${0=I}和ArrayList复制它们。

死亡减少1000点。

原型模型2：抢救通配符

第二个非常新的原型解决了有问题的类型系统特征。

问题

当前，无界通配符表示“类的任何实例”，例如ArrayList<?>表示“任何ArrayList ”。它们被大量使用，尤其是库开发人员。在ArrayList<int>和ArrayList<String>是不同类的系统中，通配符可能更为重要，因为它们弥合了它们之间的鸿沟并“表达了基本的ArrayList -ness”。

但是，如果我们假设ArrayList<?>是ArrayList<int>的超类型，那么我们最终会遇到需要多个类继承的情况。原因是ArrayList<T>扩展了AbstractList<T>所以我们也希望ArrayList<int>扩展AbstractList<int> 。现在， ArrayList<int>将扩展ArrayList<?>和AbstractList<int> （它们没有继承关系）。

在冒险途中，Valhalla的多重继承

（请注意，与当前泛型的区别在于擦除。在VM中， ArrayList<Integer>和ArrayList<?>是同一类ArrayList，可以自由扩展AbstractList。）

根本原因是，虽然ArrayList<?>看起来像是“ any ArrayList ”，但实际上是ArrayList< ?。扩展Object> ，即“引用类型上的任何ArrayList ”。

想法

原型引入了带有ref ， val和any的通配符新层次结构：

ref包含所有引用类型并替换?
val包含所有原语和值类型（原型当前不支持该值，并且在谈话中未提及，但已在Valhalla邮件列表中宣布）
any包含ref和val

专用类的多重继承将通过使用合成接口表示任意类型来解决。 ArrayList<int>将因此扩展AbstractList<int>并实现ArrayList<any> 。

细节

层次结构

ArrayList<ref> （即ArrayList<?> ）将继续为已擦除类型。

为了表示ArrayList<any> ，编译器将创建一个接口ArrayList$any 。它将由ArrayList生成的所有类（例如ArrayList<int>和已擦除的ArrayList ）实现，并将扩展与超类相对应的所有综合接口，例如AbstractList$any的AbstractList<any> 。

在通往Valhalla任何接口的道路上冒险