RFR: 8233375: JFR emergency dump do not recover thread state

[Markus Gronlund]

Hi Thomas,

Thanks for bringing this to attention. I agree with you that it should move to a better location to have minimal impact on error reporting.

Thanks again
Markus

-----Original Message-----
From: Thomas Stüfe <thomas.stuefe at gmail.com> 
Sent: den 1 november 2019 11:37
To: Yasumasa Suenaga <suenaga at oss.nttdata.com>
Cc: hotspot-jfr-dev at openjdk.java.net; yasuenag at gmail.com; Hotspot dev runtime <hotspot-runtime-dev at openjdk.java.net>
Subject: Re: RFR: 8233375: JFR emergency dump do not recover thread state

Hi Yasumasa,

I see that we do JFR::on_vm_shutdown() before error reporting ran. Is that really necessary? Error reporting should happen as close as possible to the error point - ideally, as little code as possible should run between the crash/assert and the generation of the hs-err file. I suggest moving the call to JFR::on_vm_shutdown() down to a point after error reporting, e.g. to where we print the NMT report on shutdown.

Cheers, Thomas


On Fri, Nov 1, 2019 at 10:41 AM Yasumasa Suenaga <suenaga at oss.nttdata.com>
wrote:

> Forward to hotspot-runtime-dev.
>
> As David commented in JBS, it may need to be fixed in JFR code.
> But I'm not unclear why thread state is not recover.
>
> I'd like to hear about this from JFR folks.
> If it is just a bug in JFR, I will create a patch which recover it in 
> JFR code.
>
>
> Thanks,
>
> Yasumasa
>
>
> -------- Forwarded Message --------
> Subject: RFR: 8233375: JFR emergency dump do not recover thread state
> Date: Fri, 1 Nov 2019 17:08:42 +0900
> From: Yasumasa Suenaga <suenaga at oss.nttdata.com>
> To: hotspot-jfr-dev at openjdk.java.net
> CC: yasuenag at gmail.com <yasuenag at gmail.com>
>
> Hi all,
>
> Please review this change:
>
>    JBS: https://bugs.openjdk.java.net/browse/JDK-8233375
>    webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8233375/webrev.00/
>
> If JFR is running when JVM crashes, JFR will dump data to 
> hs_err_pid<PID>.jfr .
> It would perform in prepare_for_emergency_dump().
> However this function transits thread state to "_thread_in_vm".
>
> This change has been tested on submit repo as 
> mach5-one-ysuenaga-JDK-8233375-20191101-0651-6334762.
> It failed at compiler/types/correctness/CorrectnessTest.java
> However this test is for JIT compiler, and related issue has been 
> reported as JDK-8225620.
> So I think this patch can go through.
>
>
> Thanks,
>
> Yasumasa
>