RFD: 8252768: Fast, asynchronous heap dumps

[Volker Simonis]

On Fri, Sep 4, 2020 at 2:20 PM Florian Weimer <fweimer at redhat.com> 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
>