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

[Markus Gronlund]

Hi,

I don't follow this change as it stands in isolation.
Ok, there is a call to attempt to create the file descriptor early, but there is no state saved in relation to it, for example, the path constructed is not saved so it can be reported in the next step in the hs_err file? One has to question the reason for this early creation then. Is this the way you envision to accomplish this? To query later on the status of the FD to determine what path(s) to report during hs_err.log printing? And rely on the ability to reconstruct the same path again just in the next couple of instructions? If so, maybe create and save the actual path you want reported as part of the FD operation (success / failure) state?

Can you provide a complete webrev with the entire solution (even if you have to bring in patches from two bugs), so this becomes self-contained. It is very hard to determine the correctness of this otherwise.

Thanks
Markus

-----Original Message-----
From: Yasumasa Suenaga <suenaga at oss.nttdata.com> 
Sent: den 2 februari 2020 17:32
To: hotspot-jfr-dev at openjdk.java.net
Cc: Thomas Stüfe <thomas.stuefe at gmail.com>; Markus Gronlund <markus.gronlund at oracle.com>; yasuenag at gmail.com
Subject: RFR: 8233706: JFR emergency dump should be performed after error reporting

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