为什么 memory mapped file I/O 可能会导致 Long Time to Safepoint？
letianqiu · 2022-07-28 15:12:49 +08:00 · 1442 次点击这是一个创建于 849 天前的主题，其中的信息可能已经有所发展或是发生改变。
Gil Tene 提到： https://groups.google.com/g/mechanical-sympathy/c/tepoA7PRFRU/m/7HbSINaFBgAJ
我的猜测是 mapped I/O 不走 jni ，但是不是很确定。看源码的话最终也是走到 native 方法，Gil Tene 在另一个 post 里提到 jvm 会把 internal 的 jni call 优化掉，但是如何知道哪些 jni call 被优化掉了？
 |
1
mrsatangel 2022-07-28 19:12:30 +08:00  1
你想想，mmap 的操作本质上就是通过 syscall 把文件 map 到一段内存，所有对文件的读写都变成了对文件的操作。既然是内存操作，又何来的 JNI 调用呢？
至于进入 safepoint 的问题，在进行 mmap 读写的时候，JVM 是不知道你操作的是内存还是 map 到内存的文件的，因此有可能进入到 safepoint 。如果不巧恰好出现了 page fault ，那这个 safepoint 的耗时就很长了。 |
 |
2
letianqiu OP @mrsatangel 主要是我看到 mapped I/O 的反应就是 mmap 这个 syscall ，一提到实际读写我就懂了。safepoint 这部分我是理解的。即使不发生 page fault ，在执行 mapped I/O 的时候也是没有机会去响应 safepoint request 的，一旦发生 page fault ，那就更没有 bound 了。
|
 |
3
secondwtq 2022-07-30 11:10:38 +08:00
这 mailing list 不错，收藏了
> Gil Tene 在另一个 post 里提到 jvm 会把 internal 的 jni call 优化掉 这个有没有原文链接？ |
|
4
letianqiu OP |
Select Language