由于可写页面，JIT性能是否受损？

Question

在书Linkers and Loaders中，提到可执行文件具有单独代码部分的原因之一是代码部分可以保存在只读页面中，这会导致性能提高。现代操作系统仍然如此吗？看到Just in Time compilers正在生成代码，我认为它们需要可写页面。这是否意味着JIT生成的代码总是会遭受性能损失？如果是这样，它有多重要？

Answer 1

是的，它应该遭受某种打击，因为内存中的代码不是由可执行文件直接支持的，所以它必须被分页而不是被删除。话虽如此，各种形式的链接也会污染常规代码页，使它们不再与磁盘映像匹配，产生相同的后果，所以我不确定这是一个大问题。

Answer 2

性能提升不是因为页面是否是只读的。优点是可以在进程之间共享只读页面，因此您使用更少的内存，这意味着更少的交换（在极端情况下，无论是L1 / L2 / L3缓存还是磁盘）。

JIT试图通过不必要的JITting缓解这个问题，但只是JITting热门函数。由于热函数的数量相对较少，这将导致内存仅适度增加。

JIT编译器也可以是智能的并缓存JITting的结果，因此可以（理论上）共享它。但我不知道这是否在实践中完成。

Answer 3

除了内存管理的影响（在其他答案中有解释），CPU不需要连续检查当前的指令流是否被修改，管道中的中间结果是否应该被丢弃，新代码需要是读。在jit编译的情况下，这种情况可能经常发生，这取决于编译器的设计，CPU管道的深度，CPU上的代码高速缓存的大小以及可能修改该代码的其他CPU的数量。通常不允许在设计良好的现代系统中进行，其中代码生成到可写页面并且之后标记为可执行和只读。这当然不是jit独有的。它可以发生在各种自修改代码中。