Java の JVM と .NET の CLR の内部動作の違いは何ですか?
おそらく出発点は、それぞれの環境 (Java > JVM > マシン コード) (C# > CLR > IL) で基本的に同じことでしょうか。
更新: 何人かの人々が、私がカバーしようとしていたポイントをほのめかしています:
@George Mauer - これは非常に興味深いですね:
これはすでに 1 回投稿されていますが、c# のチーフ言語デザイナーである Anders Hejlsberg との一連のインタビューです。
これは素晴らしいスレッドになるはずです。
CLR と JVM の最大の違いの 1 つは、ジェネリックが CLR にネイティブに統合されていることです。
代わりに、Java はジェネリック型を削除し、JVM は疑似ジェネリックと思われるオブジェクトをオートボックス化することによってのみ、オブジェクトを操作できます。
ここから。私はそれをうまく言うことができませんでした（まあ、炎の戦争を除いて、これは炎のない場所です:-)）。
こんにちは、
あなたの質問に答えることは、火炎戦争を開始する危険をはらんでいると思われるので、慎重に進めます。
Java ランタイムと共通言語ランタイムの間には、ガベージ コレクション メモリ、中間言語 (Microsoft IL と Java ByteCode)、コア システム ライブラリ、かなり高レベルの言語のサポート、コード セキュリティなど、多くの基本的な技術的類似点があります。展開。
ただし、これらの「類似」領域のそれぞれには、多数の大きな相違点と小さな相違点もあり、それらのほとんどを説明する単純なフォーラムの投稿の範囲を超えています。
さまざまなランタイム機能とコンポーネント領域 (メモリ管理、コンパイル、システム ライブラリ、セキュリティなど) について、より的を絞った質問をすることをお勧めします。その後、より的を絞った回答 (ブログ、技術記事など) を提供できます。 、またはいくつかの本)。
本質的な違いの1つは、JVMがプラットフォーム間で移植可能であり、Linux、Macintosh、および多くの携帯電話や組み込みデバイスで実行されることです。
CLRは、Microsoftがサポートするプラットフォームで実行され、Monoプロジェクトは、古いバージョンのCLRをさらにいくつかサポートします。
内部的には、これは、JVMのパフォーマンスが、プラットフォーム自体によって提供される機能に基づいて、これらの異なるプラットフォームで異なることを意味します。
CLR と JVM には、想像以上に異なる目標と哲学があります。一般に、JVM はより動的で高レベルのコードを最適化することを目的としていますが、CLR は、この種の最適化を自分で行うための低レベルのツールを提供します。
良い例は、スタック割り当てです。CLR では、カスタム値型の明示的なスタック割り当てがあります。JVM では、唯一のカスタム型は参照型ですが、JVM は特定の状況で Escape Analysis を介してヒープ割り当てをスタック割り当てに変換できます。
もう一つの例。Java では、メソッドはデフォルトで仮想です。少なくとも C# では、そうではありません。特定の呼び出しサイトで実行されるコードは静的に決定できないため、仮想メソッド呼び出しを最適化することははるかに困難です。
内部では、それらの実行システムはまったく異なります。ほとんどの JVM (特に Hotspot) はバイトコード インタープリターから開始し、タイトなループなど、頻繁に実行されるコードの部分のみを JIT コンパイルします。また、以前の実行から収集された実行統計を使用して、これらを何度も再コンパイルして最適化を促進することもできます。これにより、最適化を最も必要とするプログラムの部分により多くの最適化作業を適用できます。これは適応最適化と呼ばれます。
CLR は、事前にすべてを 1 回だけコンパイルします。コンパイルするコードが多いため高速である必要があるため、また最適化にフィードするために使用される実際の実行パスの統計がないため、最適化が少なくなります。このアプローチには、プロセス間でコンパイル結果をキャッシュできるという非常に大きな利点があります。これは、CLR にはありますが、JVM にはありません。
Hotspot JVM コードの大部分は、これらの適応最適化に専念しており、2000 年代初頭のほとんどの汎用計算において Java をネイティブ コードと同じパフォーマンスの球場に置いたのはこのためです。それらはまた、JVM を動的言語のまともなターゲットにするものでもあります。DLR について十分な知識がないため、ここでは動的言語ランタイムと invokedynamic の最近の開発を除外しています。
ミゲル・デ・イカザはここで言及しています：
ベテランの業界プログラマーは、上記が Java および Java VM に非常によく似ていることに気付くでしょう。そうです、上記は Java のようなものです。
ただし、CIL には Java にはない機能が 1 つあります。それは、C++、C、Fortran、Eiffel から、Java、C#、JavaScript などを含む Lisp や Haskell まで、多くの言語のターゲットとして使用できるほど強力なバイト コード表現です。と Visual Basic が混在しています。
もっと詳しく説明する時間があればいいのですが、この議論のためには、上記で十分です。
ただし、テール コールの最適化など、いくつかの詳細についてコメントが記載されています。ただし、2002 年以降、多くの変更がありました。CLR と JVM の両方が、それを対象とする複数の言語を持つようになりました。しかし、それでも読む価値があります。
私の知る限り、.Net CLR は依然として、はるかに柔軟で強力なコード アクセス セキュリティをランタイムに組み込み、よりきめ細かなパーミッションと実行ポリシーを許可しています。
Vinko が言ったように、完全な詳細はフォーラムの投稿の範囲をはるかに超えています. 相違点/類似点は次のとおりです。
どちらもランタイム環境の "サンドボックス" であり、中間言語 (MSIL または ByteCode) のプログラム命令をネイティブ マシン コードに変換する "ジャストインタイム" コンパイラを含み、自動メモリ管理 (ガベージ コレクション) を提供します。それぞれのランタイム環境の上に位置するのは、開発タスクを簡素化するために開発者に高レベルの抽象化を提供する一連のクラス ライブラリです。
これらのランタイム環境が実際にどのように実装されるかの内部構造は、ほとんどの場合、Microsoft と Sun に固有のものです。たとえば、ガベージ コレクション システムで使用されるアルゴリズムは、おそらく技術的な機能は似ていますが、実装が異なります。
ガベージコレクションにも違いがあります。JVM は、コピー コレクターとマーク アンド スイープを使用します。.NET ユーザー コレクターとマークをコピーしてコンパクトにします (実装がはるかに困難です)。
また、Flyswat で言及されている型消去も重要です。JVM はジェネリックについての手がかりがなく、すべてがオブジェクトと関連するパフォーマンスです。ボクシングとアンボクシングのペナルティ。また、リフレクションは一般的な情報を提供しません。CLR はジェネリックをネイティブにサポートします。