[Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u

[Mario Torre]

Thanks!

I’m currently traveling but I’ll offer my review as soon as I get back next
week.

Cheers,
Mario
On Tue 12. Mar 2019 at 09:35, Andrey Petushkov <andrey at azul.com> wrote:

> Hi Guangyu,
>
> Cool! Thank you so much! Will review changes ASAP
> The backporting is still in progress. There are quite a lot of changes to
> consider so we'll likely finish some time after
> April update release (mostly limited by testing resources capacity)
>
> Regards,
> Andrey
>
> > On 12 Mar 2019, at 16:29, guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
> >
> > Hi Andrey, Mario
> >
> > Is there any progress in backporting? We have completed the patch for
> the missing features. Please review.
> >
> > - thread sampling:
> > http://cr.openjdk.java.net/~luchsh/thread_sampling/
> >
> > - biased locking events:
> > http://cr.openjdk.java.net/~luchsh/hs_biasedlock/
> > http://cr.openjdk.java.net/~luchsh/jdk_biasedlock/
> >
> > - G1 heap region (heap summary is still missing, Alibaba's patch does
> not support heap summary either):
> > http://cr.openjdk.java.net/~luchsh/g1region_type_change_event
> >
> > Thanks,
> > Guangyu
> >
> >
> > ------------------------------------------------------------------
> > Sender:Andrey Petushkov <andrey at azul.com>
> > Sent At:2019 Mar. 6 (Wed.) 00:34
> > Recipient:Mario Torre <neugens at redhat.com>
> > Cc:guangyu.zhu <guangyu.zhu at aliyun.com>; jdk8u-dev <
> jdk8u-dev at openjdk.java.net>; denghui.ddh <denghui.ddh at antfin.com>
> > Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to
> OpenJDK8u
> >
> > Hi Mario,
> >
> > > On 4 Mar 2019, at 14:19, Mario Torre <neugens at redhat.com> wrote:
> > >
> > > On Fri, Mar 1, 2019 at 8:09 PM Andrey Petushkov <andrey at azul.com>
> wrote:
> > >
> > >>> I'm going through the patch right now, but yes, from what I see the
> > >>> trace is removed. I had too a concern about this and was about to
> send
> > >>> a note. I'm not quite sure what to do, because Trace has been removed
> > >>> in 11 as far as I know, but removing mid stream in 8 may be a more
> > >>> interesting issue, however this isn't a user facing API, it was
> always
> > >>> meant to be internal to the JVM, so I don't quite know if there's
> > >>> really a reason we shouldn't change it. This is one question for the
> > >>> CSR group I think.
> > >> Since trace was removed by the same commit as JFR was added to jdk11
> my guess is that trace
> > >> was used internally at Oracle to integrate closed implementation of
> JFR. With this sense I see no point
> > >> to keep it. However if the guess is wrong and there some alternative
> implementation of trace event consumer
> > >> I will be happy to return it back
> > >
> > > Yes, I tend to agree with you, I do believe this is mostly an internal
> > > API for easy of patching with the JFR code (which is almost
> > > identical). The only concern is in the way the logging would be
> > > triggered externally and the compile time options for it (I still see
> > > a couple of instance where INCLUDE_TRACE is being used). As for
> > > triggering the logs, I don't recall that 8 has any means of doing
> > > this, I think some infrastructure came with 9 with the -Xlog option (I
> > > didn't follow this however, I'm not sure the option ever landed in 9)?
> > > In that case I guess it's safe to go after all.
> > Right, the new logging infrastructure is badly missing here. Both
> Alibaba and Azul have added means of
> > some JFR logging but far from what jdk11 could do. Let me check the rest
> of INCLUDE_TRACE places,
> > IMHO we should get rid of all of them, but cannot tell for sure now
> >
> > Andrey
> > >
> > > 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
> >
>
>