私は現在、jvmをカーネル空間で（おそらくLinux）カーネルモジュールとして実行するというアイデアを研究しています。私はこの考えに多くの利点があると思う。
もちろん、これらのシステムの最大の利点は、カーネル空間の開発が大幅に簡素化されることです。しかし、これはさまざまな側面によって引き起こされます。
1) 比較的低レベルの知識を持つすべてのJava開発者はカーネルモジュールを開発できます。はい、これは確かに良い可能性ではありません:-)、特にほとんどのオープンソースJavaユーザースペースプロジェクトの現在のコード品質を見ると...しかし...カーネルスペースで同じことが起こる必要はありません。
2）（また、実際に意図された目標）：JVMは、カーネル開発の最大の問題であるメモリ保護の欠如を解決できます。他の問題（fe jitコンパイラエラーまたは低レベルのハードウェア問題）がない場合、Javaでコンパイルされたバイナリコードセグメントはその範囲外のデータ構造を損なうことはありません。ただし、これらのバイナリコードのランタイムセーフチェックによりエラーが発生する可能性があります。肯定的な効果が大きい。速度の面で明らかな欠点があります。
まず、Javaバイトコードインタプリタである必要はありません。ジャストインタイムコンパイラ（JIT）はシステムユーザースペースに常駐でき、コンパイルされたバイナリ（実際にはカーネルモジュール）のみがカーネルスペースにマッピングされます。名前空間マネージャとガベージコレクタだけがカーネル空間で実行されます。
第二に、大きい、遅い、または怖い必要はありません。これは、ユーザー空間 JVM の場合、大規模で非効率的に使用されるライブラリが使用され、次の場合に同じライブラリを使用する理由がないためです。Javaで書かれたドライバ。
私が見ることができる唯一のステップはライブ機能です。もちろん、Javaでこれを行うことは、メモリ管理のマイナーな詳細に対する制御権限がはるかに少ないため、はるかに困難です。
そのようなプロジェクトがすでに存在するか（？＃1）、そうでない場合は明らかな主な代替（？＃2）があるかどうか疑問に思います。
ベストアンサー1
JVMの実装が必要なので、これは非常に大きなプロジェクトになると思います。Cで書かれたカーネル API のカスタム部分を使用します。 openjdkのホットスポットは次のとおりです。明らかに250K+ LOCCとC++で。 LinuxカーネルではC ++を使用できません。
私はこれが多くの問題を解決できると思います。人年実装。公式ソースツリーに含まれる可能性は低いですが、大きな問題ではありません。
「最も大きな利点」と呼ぶことに関連する規模を考えると、
もちろん、これらのシステムの最大の利点は、カーネル空間の開発が大幅に簡素化されることです。
どういう意味なのかよくわかりません。 Javaでコードを書くことができますが、Cは書けない人にとってはこれが明らかに真実だと思います。しかし、一般的な意味でそういう意味なら、なぜそうなのかわかりません。私はCとJavaの両方に精通しており、どちらかを好むことはありません（コンテキストや他の人が私のために決定を下す傾向があります）。たとえば、MMを実行する必要はないので（しかしMMは本当に難しいですか？）Javaが使いやすくなります。しかし、私の考えでは、より厄介で制限的に見えるかもしれません。
個人的に追求することではないと思いますが、不可能でも悪い考えでもありません。あなたの最大の障害は、貢献する他の人を見つけることです。