jvmをカーネルスペースに移植しますか?

jvmをカーネルスペースに移植しますか?

私は現在、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が使いやすくなります。しかし、私の考えでは、より厄介で制限的に見えるかもしれません。

個人的に追求することではないと思いますが、不可能でも悪い考えでもありません。あなたの最大の障害は、貢献する他の人を見つけることです。

答え2

カーネル内のJVMを使用しても多くの問題が解決されるようには思えません。ポインタがないため、独立したコードフラグメントを合理的に分離できますが、Javaバイトコードソルバー(常に基本コードよりも遅い)またはJITコンパイラ(最初は非常に遅い)も導入されます。私はガベージコレクターについて言及していません。おそらくいくつかの問題を自動的に解決したいかもしれませんが、そうではありません。

解決すべきもう一つの問題は、ハードウェアを接続することです。 Javaコードがネットワークカード、SATA、(i)SCSI、USB、ファイバーチャネル、および他の多くのコントローラ、サウンドカード、および(最も難しい部分の1つであるようです)グラフィックスアクセラレータにアクセスできるように、かなり複雑なコードが必要です。 。これにより、多くのコードがベアメタルに近い他の言語(アセンブリであれC / C ++であるかにかかわらず、実際にはより高いレベルの抽象化を備えたより読みやすいアセンブリ言語のみ)で書かれます。

最後に、Javaでカーネルコードを書くことが最終的な目標である場合は、少し異なる操作を実行することにすることもできます。つまり、Javaでカーネルコードを作成し、ネイティブコードに直接コンパイルすることです。

1) 比較的低レベルの知識を持つすべてのJava開発者はカーネルモジュールを開発できます。

90%の場合、カーネルモジュールの作成はいハードウェアに関連するには、「マイナーな」ハードウェア知識以上が必要です。 Javaを知っているがCについて深く知らない人は、確かにハードウェアドライバ(または他のカーネルモジュール)を書くのに適した人ではありません。

他の観点からは、最も重要なデータ(これらのカーネルによって制御される生命維持については言うものではありません)をカーネルで実行されているデータに信頼していますか?Cやアセンブリを知らない人が書いたものです。合理的なドライバを書くだけで十分ですか?

2)(また、実際に意図された目標):JVMは、カーネル開発の最大の問題であるメモリ保護の欠如を解決できます。他の問題(fe jitコンパイラエラーまたは低レベルのハードウェア問題)がない場合、Javaでコンパイルされたバイナリコードセグメントはその範囲外のデータ構造を損なうことはありません。ただし、これらのバイナリコードのランタイムセーフチェックによりエラーが発生する可能性があります。肯定的な効果が大きい。速度の面で明らかな欠点があります。

メモリ保護にJITを使用していますか?ページは書き込み可能で実行可能でなければなりません。直接的なメモリアクセスが不足しても(ポインタを使用できるという意味で)、これはセキュリティ上の悪夢です。

セキュリティ(およびその他のコード分離)に興味がある場合は、マイクロカーネルが適しています。一つ持つこともできます。正式な検証。繰り返しますが、コードは最悪のプログラマーと同じくらい優れており、最良の場合はコードがまだ存在します。言語自体が重要ではなく、それを使用する人が重要です。

ところで、私は読んでお勧めしますさまざまな言語のシステムプログラミングへの答えです。それはすべてです。

関連情報