Javaのバリュータイプに対する設計が進んでいる

OpenJDKのProject Valhallaはメジャーアップデートを公開し、JVMでのバリュータイプに関する最初の、超初期段階の設計コンセプトをいくつか公表した。

プロジェクトの全体的なミッションステートメントは、"進化したJava VMと言語機能の候補を調査し生み出す場所"となること、である。Brian Goetz氏はプロジェクトの主な目標をこう説明している。

• JVMのメモリレイアウトの振る舞いを今のハードウェアのコストモデルでそろえる
• プリミティブやバリュー、voidさえ含むすべての型を抽象化できるようにジェネリクスを拡張する
• 既存のライブラリ、とくにJDKで互換性を保ったままこれらの機能を完全に利用できるようにする

バージョン9まで、Javaは2種類の値を持っているだけだった。プリミティブ型とオブジェクトの参照だ。それぞれ別のものとするために、Java環境ではメモリレイアウトに対する低レベルな制御方法を意図的に提供しなかった。特殊な場合として、Javaが構造体のようなものを持っておらず、あらゆる複合データ型は参照でのみアクセスできることを意味する。

このメモリレイアウトのパターンはJavaプラットフォームの主要な実装がここ20年間動作しているやり方であった。とても単純であるという利点があるが、多くのパフォーマンス上のトレードオフもついてくることとなった。オブジェクトの配列の扱いでやむを得ない間接化と付随するキャッシュミスのようなことだ。

結果として、パフォーマンスを求める多くのプログラマがメモリ内でより効率的にレイアウトできる型を定義する手段を求めることとなった。バリュータイプだ。

これらの新しい型は複合データの各項目への完全なオブジェクトヘッダを不要にし、オーバーヘッドも減らす。オブジェクトヘッダの削除で現在の全Javaオブジェクトが保持しているインスタンス特有のメタデータも取り除く。

この結果、オブジェクトの同一性は失われ、全フィールドが等しい場合に限り値が等しいとみなされる。これは値の振る舞いをプリミティブ型と同様にする。値42の各コピーはそれぞれのアイデンティティを持っていない。

この大きな変更を適用するために、新しいバイトコードをいくつか導入する必要があるが、新しいオペコードを2つだけ追加する必要があると現時点では考えられている。

• vdefault。これは与えられたバリュークラスのデフォルトインスタンスを生成する。
• withfield。これはバリュータイプの値を新規に生成する(そしてバリューでないものに引っ掛ける)。

既存のバイトコードもいくつかはバリュータイプを扱うために少し改良する必要がある。

VMのレベルより高いものでは、コアライブラリが互換性のある方法で進化できるようにする作業も必要だ。今それは必要不可欠となるだろう。たとえばObjectの変数に対して、バリューオブジェクトを実際に含むかどうかを確認するメソッド、といったものだ。

これ以上に、バリュータイプの単純な概念には目前にさらなる設計上の疑問がいくつかある。たとえば、ジェネリックな型に対してバリュータイプを型引数の値として使うことができるかどうかだ。

もしできないなら、これはバリュータイプの有用性を大きく制限するように思える。それゆえに、バリュータイプの設計議論ではつねにバリュータイプがまだ明示されていないジェネリクスの拡張された形態において型引数の値として有効であるという仮定を含んでいる。

Project Valhallaで進行中の研究では、以下の初期段階の設計コンセプトを導いている。VMレベルでは異なる3種類のJVMクラスとインタフェースの型がある。

• 参照型。これはアイデンティティを持つ(もしくはnullである)クラスのインスタンスへの参照を表す。
• バリュータイプ。アイデンティティがないバリュークラスのインスタンスを保持する。
• ユニバーサル型。他の2つの型のどちらかである。

これから当然の疑問が沸き起こる。"既存のクラスにある型情報はどのように解釈すべきなのか？"

すなわち、Java 9のクラスファイルにある既存の、現行のオブジェクトの型は実際には参照型とみなされるのか、もしくは実はユニバーサル型であり私たちは前もってバリュークラスのインスタンスを見ることはないという単純なことなのか？

現在の設計はまだ超初期段階であり、何ヶ月も煮詰められたものではないであろう単なる提案である。本番への準備とコードの出荷には何年もかかるかもしれない。

リリーススケジュールに変更があったため、結局どのJavaリリースが本番機能としてバリュータイプを含むのかまったくわからない。

議論と研究はProject Valhallaのメーリングリスト上で続いている。VM内部に馴染みのある読者は、詳細はそこから始めるのがよいだろう。そこで現在の作業が多くの開発者が使用できるものとなるところからははるかに遠く、まだプロトタイプの段階であるとわかるだろう。