RFR: 8233706: JFR emergency dump should be performed after error reporting

[Thomas Stüfe]

Hi Yasumasa,

very quick, not a full review yet.

can you please explain a bit more about:

- what does all this have to do with Windows MiniDumps?
- why do we have to open the file descriptor early and stow it away?
- Not sure why you bother changing the return-resourcearea pattern to a
caller provided buffer for create_emergency_dump_path()? I mean, using
resourcearea is bad in error handling, so in principle this makes sense,
but then the code creates another resourcearea buffer one frame up
inside build_dump_path()
anyway so why even bother.

Small nit, instead of passing a pointer and a comment "array should be of
length X" I would always do one of these:

void foo(char s[X]);
or
void foo(char* s, size_t len);

First variant is technically the same as passing a pointer but with clear
documentation of intent, no comment needed.

Cheers, Thomas


On Sun, Feb 2, 2020 at 5:31 PM Yasumasa Suenaga <suenaga at oss.nttdata.com>
wrote:

> Hi all,
>
> Please review this change.
>
>    JBS: https://bugs.openjdk.java.net/browse/JDK-8233706
>    webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8233706/webrev.00/
>
> Error reporting (hs_err log) should happen as close as possible to the
> error point.
> However JFR emergency dump would be performed before it.
>
> JFR emergency dump should be performed after error reporting (e.g. NMT
> reporting, CI Replay)
>
> This webrev separates opening FD like minidump for Windows and writing
> flight record.
> Also create_emergency_dump_path() is no longer dependent on ResourceMark.
>
>
> Thanks,
>
> Yasumasa
>