RFD: 8252768: Fast, asynchronous heap dumps

[Florian Weimer]

* Volker Simonis:

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

Correction: On glibc.  Historically, musl did not have a working malloc
after multi-threaded fork because POSIX does not require it.  There have
been some discussions about supporting it like an extension, similar to
glibc, but I don't know the current state.

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

NSS functions such as getpwuid_r do not work reliably with glibc.  Even
the FILE * functions have issues.

The workaround is to collect this information before the fork, and not
use <stdio.h>.

Thinking about it, the crash dumper would be more problematic in this
regard, given the amount of information it collects.  The heap dumper
probably doesn't need all that.

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

Yes, that's true.

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

But you don't know where that coredump lands, and the coredump will also
contain non-heap data or non-live heap objects, potentially making it
much larger.

Thanks,
Florian