[11u] RFR JDK-8217362: Emergency dump does not work when disk=false is set

[Jie Kang]

On Mon, Sep 2, 2019 at 10:08 AM Langer, Christoph
<christoph.langer at sap.com> wrote:
>
> Hi Jie,
>
> thanks for putting effort in backporting this bug.
>
> First of all, a general remark: When you bring an upstream patch to backport, can you please use the workflow to export the patch from the upstream repo (e.g. hg export -r <changeset number> --git > <bugid>.patch) and then import it to the backport target repository (e.g. jdk11u-dev via hg qimport <bugid.patch> && hg qpush). More details can be taken out of https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix. This would make sure, the patch metadata, such as original author, description and reviewed-by comments remain intact. These are currently missing when I import the patch from your webrev.
>
> Furthermore, I agree, it would be beneficial to backport 8218935 before you do this item. So, can you request/process this before continuing with JDK-8217362?

Hello Christoph,

I have updated the webrev to include the original metadata from
jdk/jdk as well as work on top the latest in jdk-updates/jdk11u-dev
which now has the backport of 8218935. I tested with the reproducer,
tier one tests and jfr tests.

Webrev: https://cr.openjdk.java.net/~jkang/jdk-8217362/webrev.03/
Original Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/3cabb47758c9
Bug: https://bugs.openjdk.java.net/browse/JDK-8217362

How does it look?


>
> Best regards
> Christoph
>
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > Behalf Of Jie Kang
> > Sent: Freitag, 30. August 2019 22:33
> > To: jdk-updates-dev at openjdk.java.net
> > Subject: [11u] RFR JDK-8217362: Emergency dump does not work when
> > disk=false is set
> >
> > Hi all,
> >
> > Please review this backport of 8217362 to OpenJDK jdk11u-dev. The fix
> > did not apply cleanly and I have described my alterations below. This
> > fix has been applied on top of my backport request of 8213448 [1],
> > which I hope will be accepted. I have run the tier one tests as well
> > as the reproducer described in the bug report. It does not produce a
> > jfr without the patch and does with the patch applied. Let me know
> > what you think!
> >
> > Webrev: http://cr.openjdk.java.net/~jkang/jdk-8217362/webrev.01/
> > Original Changeset: http://hg.openjdk.java.net/jdk/jdk/rev/3cabb47758c9
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8217362
> >
> > Alterations:
> >
> > 1. test/jdk/jdk/jfr/jvm/TestDumpOnCrash.java.rej
> > [jdk/jdk hg rev] : [openjdk bug]
> > d7fc38d3fc8d : 8209856: Obsolete error reporter
> >
> > A one line difference caused rejects; I manually applied the changes.
> >
> > 2. src/hotspot/share/jfr/recorder/repository/jfrRepository.cpp.rej
> > 65deccd64f3a : 8218935: Make jfr strncpy uses GCC 8.x friendly
> >
> > Small differences caused rejects; I manually applied the changes.
> > Maybe it would be good to also backport 8218935? If maintainer's have
> > a stronger opinion I would appreciate it.
> >
> > 3. src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp.rej
> > 5d20b085d893 : 8203469: Faster safepoints
> > 881c5fbeb849 : 8218041: Assorted wrong/missing includes
> > 625a5bdde0c5 : 8210155: Lock ClassLoaderDataGraph
> >
> > Generally small changes missing; I manually applied the changes in this patch.
> >
> > [1]
> > http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-
> > August/001790.html
> > https://bugs.openjdk.java.net/browse/JDK-8213448
> >
> >
> > Regards,