RFR: 8233375: JFR emergency dump do not recover thread state
Thomas Stüfe
thomas.stuefe at gmail.com
Tue Nov 5 15:51:37 UTC 2019
Okay, fair enough. Thanks for fixing this.
..Thomas
On Tue, Nov 5, 2019 at 3:35 PM Yasumasa Suenaga <suenaga at oss.nttdata.com>
wrote:
> 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
> > >
> >
>
More information about the hotspot-runtime-dev
mailing list