Loading article…
Da Vinci Machine （マルチランゲージ仮想マシンとも呼ばれる）は、動的言語のサポートを追加するためにJava仮想マシン（JVM）の拡張機能のプロトタイプを作成することを目的としたSun Microsystemsのプロジェクトでした。
JVM上で動的言語を実行することは既に可能でしたが、目標は新しい動的言語の実装を容易にし、そのパフォーマンスを向上させることです。このプロジェクトは、JSR 292（Javaプラットフォーム上での動的型付け言語のサポート）のリファレンス実装でした。 [ 1 ]
Java 7以前のJava仮想マシンには、動的型付け言語に対する組み込みのサポートがありませんでした。
JSR 292（Javaプラットフォーム上での動的型付け言語のサポート）[ 1 ]は、以下のことを提案しています。
invokedynamicJVM レベルで新しい命令を追加して、動的型チェックに依存するメソッド呼び出しを可能にする。[ 3 ] [ 4 ] [ 5 ]JRuby Java実装の成功を受けて、Da Vinciプロジェクトは2008年1月末に開始されました。[ 6 ] Da Vinciで実験された機能はJava 7に追加される予定でした。このプロジェクトは、このJSRだけでなく、他の優先度の低い拡張機能のプロトタイプを作成することを目的としています。[ 7 ] OpenJDKのパッチとして開発された最初の動作プロトタイプは、2008年8月末に発表され、利用可能になりました。[ 8 ] [ 9 ] [ 10 ]
それ以来、JRubyチームはコードベースに動的呼び出しをうまく組み込んできました。動的呼び出しは 1.1.5 リリースで出荷され、機能のないJVMinvokedynamicでは無効になります。[ 11 ]
それ以来、このプロジェクトはJDK 7コードベース[ 12 ]に統合され、その後Java 7リリースに統合されました。
動的呼び出しは、Javaが言語レベルでは非常に静的な言語であるにもかかわらず、バイトコードレベルでは型情報がはるかに少ないという事実に基づいています。
しかし、動的言語の実装では、良好なパフォーマンスを実現するために、ジャストインタイムコンパイル（リフレクションではなく）を使用する必要があり、実行時にスクリプトをバイトコードにコンパイルする必要があります。これらのバイトコードは、Java仮想マシンで実行できるようにするには、実行前に検証される必要があり、検証ツールはコード全体で型が静的であることを確認します。そのため、これらの実装では、メソッド呼び出しのさまざまなコンテキストに対して、引数のシグネチャが変わるたびに、多くの異なるバイトコードを作成する必要が生じます。
これは大量のメモリを使用するだけでなく、メタスペース（Java 8 より前のパーマネント ジェネレーション）と呼ばれるメモリ領域も満杯にします。これは、JVM がクラスに関する情報を格納するために使用するヒープの一部です。この領域で使用されるメモリは、Java プログラムのコンテキストで不変のデータを格納するため、ほとんどガベージ コレクションされません。そのため、動的言語の実装ではスクリプトのごく一部しかコンパイルできません。[ 13 ]
JSR 292は以下を提案する：
InvokeDynamic を JRuby のディスパッチ プロセスに直接接続することに成功しました! とても興奮しています! このコードはすでに JRuby のトランクにあり、JRuby 1.1.5 に同梱されます (ただし、InvokeDynamic のない JVM では当然無効になります)。
本日午前 4:00 (PDT) 頃、indy.patch の大部分が私のワークグループの統合リポジトリにある JDK7 VM に取り込まれました。
Hotspot を含むいくつかの JVM 実装の隠された秘密は、クラス定義、クラスメタデータ、場合によってはバイトコードや JIT 化されたネイティブコードなどの特殊なタイプのデータに使用される別のヒープ (または別のヒープ世代) があることです。そして、これ以上恐ろしい名前はありません。パーマネント世代です。まれなケースを除いて、PermGen にロードされたオブジェクトはガベージコレクションされません (パーマネントであるべきなので、わかりますか?)。非常に注意深く使用しないと、いっぱいになります (...)