RFD: 8252768: Fast, asynchronous heap dumps

Florian Weimer fweimer at redhat.com
Fri Sep 4 12:20:33 UTC 2020


* 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.

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.

It would be safest to fork again and execve a helper process that
processes the original forked process via mappings from /proc.

Thanks,
Florian



More information about the serviceability-dev mailing list