Linkers and Loadersの本では、実行可能ファイルが別のコードセクションを持つ理由の1つは、コードセクションを読み取り専用ページに保存できることで、パフォーマンスが向上することです。現代のOSでこれは本当ですか？ Just in Time compilersがオンザフライでコードを生成しているのを見ると、書き込み可能なページが必要だと思います。これは、JITで生成されたコードが常に比較結果でパフォーマンスヒットを受けることを意味しますか？もしそうなら、どれくらいヒットしますか？書き込み可能なページのためJITパフォーマンスが低下しますか？
メモリ管理の効果（他の回答で説明されています）は、現在の命令ストリームが変更され、パイプラインの中間結果が破棄され、新しいコードが必要であるかどうかを継続的に確認する必要はありません読まれる。 jitコンパイルの場合、このシナリオは、コンパイラの設計、CPUパイプラインの深さ、CPU上のコードキャッシュのサイズ、およびそのコードを変更する可能性のある他のCPUの数によって頻繁に発生することがあります。コードが書き込み可能なページに生成され、その後実行可能かつ読み取り専用とマークされたうまく設計された最新のシステムでは、通常は許可されません。これはもちろんジットに固有のことではありません。それはあらゆる種類の自己修正コードで起こる可能性があります。
メモリ内のコードが実行可能プログラムによって直接サポートされていないため、ある種のヒットが発生するはずです。そのため、単に破棄するのではなくページアウトする必要があります。言いましたが、さまざまな形式のリンクでは、通常のコードページが汚れてしまい、ディスクイメージと同じ結果が得られなくなってしまいます。これは大きな問題ではありません。
パフォーマンスの向上は、ページが読み取り専用かどうかによって異なります。利点は、読み取り専用ページをプロセス間で共有できるため、より少ないメモリ（L1/L2/L3キャッシュと極端な場合はディスクの両方）のスワップを意味します。
JITは、不必要にJITするのではなく、ホット機能をJITするだけでこれを緩和しようとします。これは、ホット機能の数が比較的少ないため、わずかなメモリの増加しかもたらさない。
JITコンパイラはスマートで、JITtingの結果をキャッシュして（理論的に）共有できるようにすることもできます。しかし、これが実際に行われたかどうかはわかりません。
.NETです。NGENで。 –
実行時に読み取り専用ページを変更することは考えていませんでした。どのように通常それを行うのですか？私はLinux上で特にシステムコールを見ることは思い出せません。 –
セキュリティ上の理由からだけ.NETがページをR/Oとしてマークしていることは間違いありません。 –
システムコールはmprotectであり、POSIXの一部です。 –