RFR: 8223147: JFR Backport (to jdk8u)

Tue May 7 13:55:09 UTC 2019

Thanks for the work once again, I'll look at these after the main
patch is reviewed

Cheers,
Mario

On Tue, May 7, 2019 at 1:42 PM Andrey Petushkov <andrey at azul.com> wrote:
>
> In addition, Ekaterina Vergizova from Azul Systems (katya at azul.com) has backported bunch of JFR fixes atop of initial
> integration. The fixes are:
>
> 8041626: Shutdown tracing event
> 8165675: Trace event for thread park has incorrect unit for timeout
> 8202578: Revisit location for class unload events
> 8205516: JFR tool
> 8207829: FlightRecorderMXBeanImpl is leaking the first classloader which calls it
> 8210024: JFR calls virtual is_Java_thread from ~Thread()
> 8211239: Build fails without JFR: empty JFR events signatures mismatch
> 8212232: Wrong metadata for the configuration of the cutoff for old object sample events
> 8213015: Inconsistent settings between JFR.configure and -XX:FlightRecorderOptions
> 8213421: Line number information for execution samples always 0
> 8213617: JFR should record the PID of the recorded process
> 8213914: [TESTBUG] Several JFR VM events are not covered by tests
> 8213917: [TESTBUG] Shutdown JFR event is not covered by test
> 8213966: The ZGC JFR events should be marked as experimental
> 8214750: Unnecessary <p> tags in jfr classes
> 8214896: JFR Tool left files behind
> 8214906: [TESTBUG] jfr/event/sampling/TestNative.java fails with UnsatisfiedLinkError
> 8214925: JFR tool fails to execute
> 8215175: Inconsistencies in JFR event metadata
> 8215237: jdk.jfr.Recording javadoc does not compile
> 8215284: Reduce noise induced by periodic task getFileSize()
> 8215362: JFR GTest JfrTestNetworkUtilization fails
> 8215771: The jfr tool should pretty print reference chains
> 8216486: Possibility of integer overflow in JfrThreadSampler::run()
> 8216559: [JFR] Native libraries not correctly parsed from /proc/self/maps
> 8216578: Remove unused/obsolete method in JFR code
> 8216995: Clean up JFR command line processing
> 8217744: [TESTBUG] JFR TestShutdownEvent fails on some systems due to process surviving SIGINT
> 8217748: [TESTBUG] Exclude TestSig test case from JFR TestShutdownEvent
> 8218935: Make jfr strncpy uses GCC 8.x friendly
>
> Please could you also review these backports here http://cr.openjdk.java.net/~apetushkov/jfr_backports_katya/
> That is single webrev but created from set of individual commits. If one would like to see individual webrevs please let us know
> Relevant JFR jtreg tests have passed on all supported platforms
>
> Thanks,
> Andrey
>
> > On 7 May 2019, at 14:20, Andrey Petushkov <andrey at azul.com> wrote:
> >
> > Hi All,
> >
> > RFR for initial JFR backport to current state of jdk8u-jfr-incubator is here http://cr.openjdk.java.net/~apetushkov/8223147/
> > Please could you review and hopefully approve
> >
> > The changes are the same as in initial review request [1] except two fixes were added for the bugs found after integration
> > of Alibaba's implementation of thread sampling (note that according to the plan Alibaba's patches are not included into this RFR)
> > The webrev includes bug ids for all changes backported under it, however these are not separated on per-file basis
> >
> > One process question (thus Andrew in To), the new webrev currently only includes the code which applies to jdk8u-jfr-incubator
> > repo, but what about aarch64 and aarch32 ports which are not available there? I don't see a reason to prevent them from
> > having JFR and there is code ready for that ([1]). How could we proceed with integration of it?
> >
> > Thanks,
> > Andrey
> >
> > [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-February/008576.html
> >
> >> On 30 Apr 2019, at 18:49, Mario Torre <neugens at redhat.com> wrote:
> >>
> >> On Tue, Apr 30, 2019 at 5:27 PM Andrew John Hughes
> >> <gnu.andrew at redhat.com> wrote:
> >>>
> >>>
> >>>
> >>> On 30/04/2019 16:19, Mario Torre wrote:
> >>>> On Tue, Apr 30, 2019 at 5:15 PM Andrew John Hughes
> >>>> <gnu.andrew at redhat.com> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 30/04/2019 11:29, Mario Torre wrote:
> >>>>>> Hi all,
> >>>>>>
> >>>>>> I have sync'ed up jdku-dev post security with our staging repository:
> >>>>>>
> >>>>>> https://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/
> >>>>>>
> >>>>>> After discussing with Andrew we decided to be best to create a new bug
> >>>>>> rather than reusing the existing JFR and mark them as backports, so I
> >>>>>> went ahead and created it:
> >>>>>>
> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8223147
> >>>>>>
> >>>>>
> >>>>> Doesn't this mean that an issue won't show up as having been backported
> >>>>> to 8u when it has?
> >>>>
> >>>> Yes, this is why the initial thought was to have the backports bug,
> >>>> however this feature doesn't have one specific bug for the backport,
> >>>> it's more like a multitude of the bugs and doesn't apply cleanly
> >>>> either, so we decided to just have a separate bug to encompass
> >>>> everything else. I'm not sure what else we can do, what do you think?
> >>>>
> >>>> Cheers,
> >>>> Mario
> >>>>
> >>>
> >>> Note that you can mention multiple bug IDs in a commit:
> >>>
> >>> https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/bc0a3a91a074
> >>>
> >>> From my experience with a similar situation with getting the PPC port
> >>> into OpenJDK 7, I'd say a hybrid solution is the best option; use a
> >>> unique bug for the initial backport of the feature, but import later bug
> >>> fixes using the same changeset+bug ID relationship.
> >>>
> >>> e.g.
> >>>
> >>> there is:
> >>>
> >>> https://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/de5e8c8a9b87
> >>>
> >>> and then a run of other bugs:
> >>>
> >>> https://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/ccb68f77d07a
> >>> https://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/ccb68f77d07a
> >>> https://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/f2f5a053bd0d
> >>> etc.
> >>>
> >>>
> >>> Where possible, it's best to avoid the problem where someone does 'log
> >>> -k <bugid>', can't find it in the repo, starts to backport it and then
> >>> realises it's there in disguise :)
> >>
> >> That makes sense, and I'm all for going towards what makes the
> >> maintainers life easier.
> >>
> >> We can use the bug ID I created and then reference individual fixes
> >> one by one or go back to the first plan and use multiple bug ids (or
> >> just the core jfr even if the patch is reworked).
> >>
> >> Andrew Haley, what do you think? Given that this will be merged into
> >> 8u-dev at some point I think this should be really your decision on
> >> what bug to use.
> >>
> >> Cheers,
> >> Mario
> >>
> >> --
> >> Mario Torre
> >> Associate Manager, Software Engineering
> >> Red Hat GmbH <https://www.redhat.com>
> >> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
> >
>


-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898