On Thu, 18 May 2023 09:35:36 GMT, Kevin Walls <kev...@openjdk.org> wrote:
> I'm interested in if it is faster in STW time with the parallel write to use > compression or not? (Does not compressing take time, or does compressing mean > we write fewer bytes, so ends up being faster.) Hi @kevinjwalls, so far all benchmark data are based on parallel dumps without compression. I will add more benchmark data about parallel dump data with compression later. > The idea of forking a child to do the write seems appealing, although it is a > non-Windows solution. Isn't the point of a fork that the parent can keep > running without any pause at all? The child gets a copy of all memory, the > fork happened at a safepoint so the Java heap is in a good state, and it can > take its time to do the write, then exit without affecting the parent. The > child probably must not make any Java calls or interact with other existing > JVM threads. (fork not vfork. The child is making no writes to the Java heap so should not cause the entire Java heap to be duplicated in memory. That overhead might be large though particularly if the app is making changes...) I think the real pauseless is impossible, long time STW is amortized by minor STWs as once writing happens in parent process, child process observes them by userfaultfd and corresponding pages are prioritized for dumping in safepoint region. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13667#issuecomment-1552891620
