JIT 性能是否会因可写页面而受到影响?
在书中 链接器和加载器,其中提到可执行文件具有单独代码段的原因之一是代码段可以保存在只读页中,从而提高性能。 对于现代操作系统来说仍然如此吗? 鉴于即时编译器正在动态生成代码,我认为它们需要可写页面。 这是否意味着 JIT 生成的代码相比之下总是会受到性能影响? 如果是这样,它的影响力有多大?
In the book Linkers and Loaders, it's mentioned that one of the reasons for executables to have a separate code section is that the code section can be kept in read only pages, which results in a performance increase. Is this still true for a modern OS? Seeing as Just in Time compilers are generating code on the fly, I assume they need writable pages. Does this mean that JIT generated code will always suffer a performance hit in comparison? If so, how significant a hit is it?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
除了内存管理的影响(在其他答案中对此进行了解释)之外,CPU 不需要不断检查当前指令流是否被修改,并且管道中的中间结果应该被丢弃并且需要读取新代码。 在 jit 编译的情况下,这种情况可能经常发生,具体取决于编译器的设计、CPU 管道的深度、CPU 上代码缓存的大小以及可能修改该代码的其他 CPU 的数量。 在设计良好的现代系统中,通常不允许发生这种情况,在现代系统中,代码生成到可写页面,然后标记为可执行和只读。 当然这并不是 jit 所独有的。 它可能发生在各种自修改代码中。
Effects of memory management aside (which are explained in other answers), CPU doesn't need to continuously check if the current stream of instructions are modified and the intermediate results in the pipeline should be thrown away and new code needs to be read. In the case of jit compilation, this scenario may occur often depending on the design of the compiler, depth of CPU pipeline, size of code cache on CPU and number of other CPUs which may modify that code. It isn't normally allowed to occur in well designed modern systems where code is generated to a writeable page and marked as executable and readonly afterwards. This is not unique to jit of course. It can happen in all kinds of self modifying code.
是的,它应该遭受某种打击,因为内存中的代码不直接由可执行文件支持,因此必须将其调出而不是直接删除。 话虽如此,各种形式的链接也会弄脏常规代码页,使它们不再与磁盘映像匹配,从而产生相同的后果,所以我不确定这是否是一个大问题。
Yes, it should suffer some sort of hit because the code in memory is not backed directly by the executable, so it would have to be paged out instead of just dropped. Having said that, various forms of linking can also dirty up regular code pages so that they no longer match the disk image, with the same consequences, so I'm not sure that this is a big deal.
性能的提高并不是因为页面是否只读。 优点是只读页面可以在进程之间共享,因此您使用更少的内存,这意味着更少的交换(无论是到 L1/L2/L3 缓存,还是在极端情况下到磁盘)。
JIT 试图通过不进行不必要的 JIT 操作,而仅对热函数进行 JIT 操作来缓解这种情况。 由于热函数的数量相对较少,这只会导致内存的适度增加。
JIT 编译器也可以很智能,可以缓存 JITting 的结果,以便(理论上)可以共享它。 但不知道实际中是否这样做。
The performance increase is not because of whether the pages are read only or not. The advantage is that read only pages can be shared between processes, so you use less memory which means less swapping (both to L1/L2/L3 caches as well as to disk in extreme cases).
JIT tries to mitigate this by not needlessly JITting, but only JITting the hot functions. This will result in only a modest increase in memory since the number of hot functions are relatively small.
A JIT compiler could also be smart and cache the result of the JITting so it could (theoretically) be shared. But I don't know whether this is done in practice.