On Fri, Sep 4, 2020 at 2:20 PM Florian Weimer <[email protected]> wrote: > > * Volker Simonis: > > > Please let me know what you think and if there's something I've > > overlooked? > > ZGC uses shared mappings for the heap, which will remain shared after > fork, so this trick does not work there. >
That's a good point. So this feature would have to be disabled for ZGC. I've also tested it now and it really crashes quite quickly if the parent is doing any allocations while the child is dumping. > The other issue is that formally, there are significant restrictions on > what kind of functionality is available after a fork call from a > multi-threaded process. Only async-signal-safe functions are supported, > and POSIX does not include malloc among them. glibc supports malloc as > an extension, but many other things are broken to varying degrees. > Well, as you said, on Linux malloc() is working and I haven't seen anything else broken until now. As far as I can see, dumping is only calling some basic I/O functions which are all async-signal-safe. Do you have anything concrete in mind for the "many other things are broken to varying degrees". > It would be safest to fork again and execve a helper process that > processes the original forked process via mappings from /proc. > The nice thing about this approach is that we're getting the functionality basically "for free" because it uses Hotspot's own dump routine without modifications. Processing memory mappings from /proc would require rewriting the whole dump logic. But there's another approach which I've also thought about. As I mentioned in my first mail, the SA tools can already create a heap dump from a core file. So we could immediately raise a SIGSEGV in the child (which is async-hread-safe :) and create a core file. This could then be processed later (and asynchronously) by the SA tools to extract a heap dump. The advantage is clearly that it would be much safer from a design point of view. The drawback is that extracting a heap dump from a core file with the SA tools (which are written in Java) is much slower and it requires another Java process so it probably can't be done on the same machine. Also, the core file is much bigger than the heap dump and the heap dump can't be compressed while it is being written. > Thanks, > Florian >
