そこで、Java を勉強しているときに頭に浮かんだ質問があります。Bytecode が JVM 上で実行されることはわかっています (間違っていたら訂正してください!)。では、JVM はバイトコードをそれが (JVM) 用に作成されたネイティブ マシン コードに変換しますか? もしそうなら、それは安全性が低くありませんか？
また、ジャストインタイムコンパイラとは正確には何ですか? そうするように求められたときにコンパイルされます...いくつかのリソースを調べましたが、それでもジャストインタイムの部分が明確になりませんでした。
助けてくれてありがとう！
では、JVM はバイトコードをその (JVM) 用に記述されたネイティブ マシン コードに変換しますか?
いいえ、必ずしもそうではありません。ただし、最近ではデフォルトでそうするのが最先端です。
もしそうなら、それは安全性が低くありませんか？
何よりも安全性が低いのですか？マシン コードで安全でない操作 (初期化されたポインターの逆参照や未割り当てメモリへのアクセスなど) を実行できるからといって、JIT がそのような安全でないコードを生成するわけではありません。
また、ジャストインタイムコンパイラとは正確には何ですか?
バイトコードをネイティブ マシン コードに変換するのは、JVM の一部です。「ジャスト イン タイム」という名前は、コードが実行中に (別のスレッドで) コンパイルされることを意味します。コンパイルが完了すると、JVM は、特定のメソッドがコンパイルされ、マシン レベルで呼び出すことができることを認識します。
それで、JVMはバイトコードをそれが書かれたネイティブマシンコード（JVM）に変換しますか？
これまで見てきたすべての JVM 実装は、バイトコードを VM 用に作成されたネイティブ マシン コードに変換しています。方法と理由はわかりませんが、そうしないと便利です。
また、ジャストインタイムコンパイラとは正確には何ですか?
これは、実行時にバイト コードをネイティブ コードに変換する単純なプロセスです。ただし、パフォーマンスの向上のために、プログラムの実行と並行して VM によって実行されています。また、通常は、コンパイルされたネイティブ コードのキャッシュや、その他のパフォーマンス向上の手法も含まれます。
もしそうなら、それは安全性が低くありませんか？
まあ、ある程度はそうです。非常に小さな程度。JITコンパイルを排除するさまざまなOSへのセキュリティ関連の変更がいくつかあります。たとえば、grsecurity Linux カーネル パッチは、実際には JIT を不可能にしています (実際には、JIT コンパイルされたコードを実行することは不可能です)。もう 1 つの事実は、同様のメモリ保護メカニズム (書き込み可能なメモリ ページを実行できない) が iOS に実装されているため、ユーザー モードで JIT コンパイルを実行することが不可能になっていることです。