为什么 memory mapped file I/O 可能会导致 Long Time to Safepoint？

[letianqiu]

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 被优化掉了？

[mrsatangel]

你想想，mmap 的操作本质上就是通过 syscall 把文件 map 到一段内存，所有对文件的读写都变成了对文件的操作。既然是内存操作，又何来的 JNI 调用呢？

至于进入 safepoint 的问题，在进行 mmap 读写的时候，JVM 是不知道你操作的是内存还是 map 到内存的文件的，因此有可能进入到 safepoint 。如果不巧恰好出现了 page fault ，那这个 safepoint 的耗时就很长了。

[letianqiu]

@mrsatangel 主要是我看到 mapped I/O 的反应就是 mmap 这个 syscall ，一提到实际读写我就懂了。safepoint 这部分我是理解的。即使不发生 page fault ，在执行 mapped I/O 的时候也是没有机会去响应 safepoint request 的，一旦发生 page fault ，那就更没有 bound 了。

[secondwtq]

这 mailing list 不错，收藏了

> Gil Tene 在另一个 post 里提到 jvm 会把 internal 的 jni call 优化掉
这个有没有原文链接？

[letianqiu]

@secondwtq https://groups.google.com/g/mechanical-sympathy/c/yL4Yaedgqg4/m/ubr4EvsdBQAJ