PING: RFR: 8233706: JFR emergency dump should be performed after error reporting
Yasumasa Suenaga
suenaga at oss.nttdata.com
Mon Feb 24 13:57:53 UTC 2020
PING: Could you review it?
JBS: https://bugs.openjdk.java.net/browse/JDK-8233706
https://bugs.openjdk.java.net/browse/JDK-8233373
webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8233373/webrev.03/
Thanks,
Yasumasa
On 2020/02/11 22:46, Yasumasa Suenaga wrote:
> Hi Markus,
>
> I uploaded new webrev which contains both 8233706 and 8233373.
> Also it contains the fix which are commented by Thomas.
>
> http://cr.openjdk.java.net/~ysuenaga/JDK-8233373/webrev.03/
>
> This change passed all tests in submit repo (mach5-one-ysuenaga-JDK-8233373-3-20200211-1212-8648983).
>
>
> Thanks,
>
> Yasumasa
>
>
> On 2020/02/10 21:12, Markus Gronlund wrote:
>> 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
>>
More information about the hotspot-jfr-dev
mailing list