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