在Linkers and Loaders一书中提到,可执行文件具有单独代码段的原因之一是代码段可以保存在只读页面中,从而提高了性能。对于现代操作系统来说,这仍然适用吗?看到即时编译器正在动态生成代码,我认为它们需要可写页面。这是否意味着 JIT 生成的代码相比之下总是会受到性能影响?如果是这样,它的打击有多大?
问问题
186 次
3 回答
1
是的,它应该受到某种打击,因为内存中的代码不是由可执行文件直接支持的,所以它必须被分页而不是被删除。话虽如此,各种形式的链接也会弄脏常规代码页,使它们不再与磁盘映像匹配,后果相同,所以我不确定这是什么大问题。
于 2009-07-20T19:48:56.553 回答
1
性能提升不是因为页面是否为只读。优点是只读页面可以在进程之间共享,因此您使用更少的内存,这意味着更少的交换(对于 L1/L2/L3 缓存以及极端情况下的磁盘)。
JIT 试图通过不是不必要的 JITting 来缓解这种情况,而只是 JITting 热函数。由于热函数的数量相对较少,这只会导致内存适度增加。
JIT 编译器也可以是智能的并缓存 JITting 的结果,因此它可以(理论上)被共享。但我不知道这是否在实践中完成。
于 2009-07-20T20:00:26.077 回答
1
除了内存管理的影响(在其他答案中进行了解释),CPU 不需要持续检查当前指令流是否被修改,并且应该丢弃管道中的中间结果并需要读取新代码。在 jit 编译的情况下,这种情况可能经常发生,具体取决于编译器的设计、CPU 管道的深度、CPU 上代码缓存的大小以及可能修改该代码的其他 CPU 的数量。在设计良好的现代系统中通常不允许发生这种情况,其中代码生成到可写页面并随后标记为可执行和只读。这当然不是 jit 独有的。它可能发生在各种自修改代码中。
于 2009-07-20T21:26:50.583 回答