performance - 書き込み可能なページが原因で JIT のパフォーマンスが低下しますか?

Question

Linkers and Loadersという本の中で、実行可能ファイルに別のコード セクションがある理由の 1 つは、コード セクションを読み取り専用ページに保持できるため、パフォーマンスが向上すると述べられています。これは最新のOSにも当てはまりますか？ジャストイン タイム コンパイラがオンザフライでコードを生成していることを考えると、書き込み可能なページが必要だと思います。これは、JIT で生成されたコードが常にパフォーマンスに影響を与えることを意味しますか? もしそうなら、それはどのくらい重要なヒットですか？

Answer 1

はい、メモリ内のコードは実行可能ファイルによって直接バックアップされないため、何らかのヒットが発生するはずです。そのため、単にドロップするのではなく、ページアウトする必要があります。そうは言っても、さまざまな形式のリンクによって通常のコードページがダーティになり、ディスクイメージと一致しなくなり、同じ結果になる可能性があるため、これが大したことかどうかはわかりません。

Answer 2

パフォーマンスの向上は、ページが読み取り専用かどうかによるものではありません。利点は、プロセス間で読み取り専用ページを共有できるため、メモリの使用量が少なくて済むため、スワッピング (L1/L2/L3 キャッシュと極端な場合にはディスクの両方) が少なくなることです。

JIT は、不必要に JIT を行うのではなく、ホットな機能のみを JIT することで、これを軽減しようとします。ホット関数の数が比較的少ないため、これによりメモリがわずかに増加するだけです。

JIT コンパイラーもスマートで、JITting の結果をキャッシュして (理論的には) 共有できるようにすることができます。しかし、これが実際に行われているかどうかはわかりません。

Answer 3

メモリ管理の影響 (他の回答で説明されています) は別として、CPU は現在の命令ストリームが変更されているかどうかを継続的にチェックする必要はなく、パイプラインの中間結果を破棄して新しいコードを読み取る必要があります。jit コンパイルの場合、コンパイラの設計、CPU パイプラインの深さ、CPU 上のコード キャッシュのサイズ、およびそのコードを変更する可能性のある他の CPU の数に応じて、このシナリオが頻繁に発生する可能性があります。通常、コードが書き込み可能なページに生成され、後で実行可能および読み取り専用としてマークされる、適切に設計された最新のシステムでは発生することは許可されていません。もちろん、これは jit に限ったことではありません。あらゆる種類の自己変更コードで発生する可能性があります。