RFR: 8223147: JFR Backport (to jdk8u)

Tue May 7 11:42:20 UTC 2019

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
> 