JVM架构师John Rose 提出了一个新的OpenJDK项目，名为“ Project Metropolis”。 根据最初的消息 （讨论线程已更改，“以便使档案更好”），Project Metropolis是一个尝试使用先进的JVM实现技术的孵化器。

Metropolis项目概述：Java-on-Java

Rose解释说，他们的目标是在Java本身中重新实现Hotspot的C ++运行时的重要部分-他们称此为Java-on-Java。

关键实验将围绕以下两种模式研究Graal作为JVM的代码生成器：

  • 作为替换Hotspot现有JIT的一个或多个的在线编译器，以及作为Java代码的离线编译器，旨在替换Hotspot中的现有C ++代码。
  • 在后者的角色中，他们打算尝试使用静态编译技术（例如Substrate VM [3]）将Java编译为静态受限格式，这些格式可以轻松地与Hotspot中使用的C ++集成。

Metropolis项目将是一个实验技术孵化器，类似于Lambda ， Panama ， Valhalla和Amber项目。 Rose解释说，这些孵化器项目“吸收了当前Java版本的更改，但没有直接推送到Java版本。 相反，他们累积了原型更改，有时将其丢弃，有时（在进行了适当的审查之后）有时会手工合并到Java版本中。”

还请参见： 每年发布两个Java功能：Oracle提出了新的基于时间的模型

以Java-on-Java样式实现Java运行时的优点

  • 自我优化：他们获得了对用于编译JVM本身的优化技术的更完全控制。
  • 自决：他们可以将JVM与其他实现语言（C ++ NN）的更改（可能会使不稳定）脱钩。
  • 简化：更一致地使用Java生态系统的“本机”语言，从而降低了贡献者和维护者的成本。
  • 速度：更快地交付新的JVM后端（未来的硬件），新的JVM前端（值类型的字节码），新的字节码形状（流优化）和应用程序格式（静态应用程序组装）。

风险性

  • 启动：Java代码的启动开销必须不会损害JVM的总体启动。
  • 隔离：Java-on-Java执行所需的GC或JIT活动不得干扰应用程序的执行。
  • 密度：基于Java的数据结构可能需要增强（例如值类型）以支持与C ++竞争的密集数据结构。
  • 继承：Java-on-Java实现的采用不会对依赖现有模块的质量和性能的客户造成退步。

罗斯表示，“大都会”项目的关键实验将包括：

  • 运行Graal以“本机编译模式”静态编译Java代码，以准备可以替换C ++组件的JVM组件。 （这将扩展与AOT和/或Substrate VM的现有工作。）
  • 静态地编译Graal本身（再次以本机编译模式）以作为JIT运行，并将其评估为C2的后继者。
  • 从应用程序代码中分离出所得的Java-on-Java组件（即，作为JIT运行的Graal），尤其是在GC动态，名称解析和副作用方面。

将开发和跟踪有关启动，占用空间，峰值性能和应用程序延迟的指标，这些指标将用于表征在Java上实现Java的效果（启动，隔离，密度和质量）。

这些指标，社区评估和回归测试的迭代周期将帮助他们评估进度
在Java的HotSpot参考实现中，用Java代码替换C ++代码，尤其是用Graal替换C2，以实现其“最终目标”。

如果这些实验证明是成功的，他们将能够进行其他实验，以实现Java-on-Java：

  • 使用Graal替代客户端JIT（C1）。
  • 使用Graal代码生成字节码解释器。
  • 使用Graal旋转适配器，例如本机到Java的绑定。
  • 使用Graal动态自定义其他JVM热路径。
  • 在Graal中对新的JVM功能（例如值类型）进行原型设计。
  • 在静态编译的Java中编码本机方法。
  • Java中的编码元数据访问和处理。
  • 用静态编译的Java对较小的JVM模块进行编码，例如类文件解析或验证。
  • 在静态编译的Java中编码GC逻辑。

实现这个第一个目标是将来对Java技术堆栈进行许多升级的重要一步。

该项目将由HotSpot集团赞助。 HotSpot团队成员（包括JIT，GC，运行时和性能团队），Oracle Labs的Graal项目成员以及对Java-on-Java问题感兴趣的组织的非Oracle开发人员将在此项目上共同努力。

与其他项目的关系：

  • 该项目将以JDK源库的完整副本开始。
  • 该项目将通过跟踪这些资源来保持相关性。
  • 该项目将包含Graal存储库或其副本。
  • 该项目不会将变更集直接提供给任何JDK版本。
  • 该项目将按常规将更改推送到Graal存储库。

对Graal存储库的更改可能包括：

  • 支持静态编译（包括AOT更改）。
  • 与JVM集成的API（超出了当前的JVMCI）。
  • 针对运行Java-on-Java模式的代码的特定优化。
  • 通用优化（替代C2）。
  • 新的平台优化（例如AVX）。
  • 建议的新指令（例如值类型）。

更改将与Graal开发团队进行协调（因此要遵循Graal项目建立的实践）。 此举的目的是确保“任何一个项目的更改都不会导致回归。” 结果，“每个项目将对两个项目执行一定数量的集成测试。 由于Graal项目本身就是一个活跃的项目，因此项目之间的协调以及团队之间的重叠是Java on Java实验成功的必要条件。”

罗斯提议任命HotSpot JIT主管VOT或首席AOT工程师Vladimir Kozlov担任Project Metropolis的主管。

来自Red Hat的Andrew Dinn的赞许

RedHat高级首席软件开发人员Andrew Dinn 对 Rose的建议表示欢迎 。 他补充说：“用Java-on-Java的实现替代更加坚硬的黑匣子特别有价值，黑匣子通过更加流畅，透明的边界层将当前的VM技术与JDK技术分开。”

但是，他敦促社区不要以他的发言代表Red Hat的回答。

在Mark Reinhold提醒他OpenJDK没有“ RFC”操作之后，Rose后来纠正了消息中的主题行。 主题行现在称为“ 征集讨论：新项目：都市” 。

任何贡献者都可以提议创建一个新项目。

步骤0：讨论[选填]

建议对新项目的任何提案进行公开讨论，然后再进行表决。 向一般讨论列表发送电子邮件，描述拟议项目的动机，目标和最初的领导。 包括任何建议的初始作者，提交者和审阅者（如果已知）。 （只有在项目需要进行正式变更审核时，审阅者才有意义。）描述现有的代码体（如果有），将其用作项目的起点。 提议的参与者应积极参与任何后续讨论，并应根据评论意见对建议进行必要的细化。

至少一名小组负责人必须声明他们的小组是所提议项目的发起人。 （与要求小组成员投票表决赞助的临时准则不同，小组负责人有权宣布小组是该项目的发起者。）

步骤1：提出建议

发送合并议案，以创建项目和任命其最初领导到公告清单 。 电子邮件中应包含项目名称，描述，最初的牵头名称和资格，发起人小组以及建议的最初的作者，提交者，审稿人（如果有）。 投票方法是“ 惰性共识” ，只有当前的OpenJDK成员才有资格投票。

章程对OpenJDK成员创建新项目以及由赞助团体的团体负责人任命其初始负责人分别进行表决。 因此，任何此类小组负责人都可以要求对两个动议进行独立表决，尽管这在通常情况下并不理想。

步骤2：投票

合格的选民通过将电子邮件发送到一般讨论列表来投票。 对于那些邮件程序认可Reply-To标头的人，回复提案将自动实现这一目标。 邮件正文的第一行应采用以下格式： 

Vote:<vote>

其中<vote>是yes ， veto或abstain 。 可以在随后的各行中提供投票理由，这是使veto票有效的必要条件。 允许多次投票，但仅计算最近投票。 必须在公开讨论总表上公开投票； 作为私人答复发送的票数将不计算在内。

步骤3：宣布结果

一旦所有OpenJDK成员都投票或截止日期过去，提议的贡献者必须将结果发送到公告列表 。 如果公告得到批准，则还必须将其发送给注册服务商 。

步骤4：任命

注册服务商将向新的项目负责人发送电子邮件调查表，以收集在OpenJDK上启动该项目所需的信息。 除了网页，文件存储库和邮件列表的信息外，还将要求线索负责人选择初始的作者，提交者和审阅者（如有必要）。 注册服务商将酌情发出注册邀请，并将更新人口普查。

翻译自: https://jaxenter.com/openjdk-project-metropolis-137318.html