RFR: 8223147: JFR Backport (to jdk8u)

[Andrey Petushkov]

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