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

[Yasumasa Suenaga]

On 2019/11/05 22:42, Thomas Stüfe wrote:
> 
> On Sat, Nov 2, 2019 at 1:46 PM Yasumasa Suenaga <suenaga at oss.nttdata.com <mailto:suenaga at oss.nttdata.com>> wrote:
> 
>     Hi Thomas,
> 
>     I agree with you. Also CI Replay will be generated after NMT report.
>     But I think it should be another issue.
> 
>     If you are ok, I file it to JBS and create a patch.
> 
> 
> 
> Why not fix it in this patch, while you are on it?

It is not affect thread state directly.

In addition, I've sent review request of JDK-8233373. This change affects to the location of JFR::on_vm_shutdown().
Thus I want to fix it after JDK-8233373 and JDK-8233375.


Yasumasa


> ..Thomas
> 
>     Thanks,
> 
>     Yasumasa
> 
> 
>     On 2019/11/01 19:36, Thomas Stüfe wrote:
>      > 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 <mailto:suenaga at oss.nttdata.com> <mailto:suenaga at oss.nttdata.com <mailto: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 <mailto:suenaga at oss.nttdata.com> <mailto:suenaga at oss.nttdata.com <mailto:suenaga at oss.nttdata.com>>>
>      >     To: hotspot-jfr-dev at openjdk.java.net <mailto:hotspot-jfr-dev at openjdk.java.net> <mailto:hotspot-jfr-dev at openjdk.java.net <mailto:hotspot-jfr-dev at openjdk.java.net>>
>      >     CC: yasuenag at gmail.com <mailto:yasuenag at gmail.com> <mailto:yasuenag at gmail.com <mailto:yasuenag at gmail.com>> <yasuenag at gmail.com <mailto:yasuenag at gmail.com> <mailto:yasuenag at gmail.com <mailto: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
>      >
>