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

guangyu.zhu guangyu.zhu at
Thu Mar 14 02:39:55 UTC 2019

Ok. I look forward to the feedbacks from both of you.

Sender:Mario Torre <neugens.limasoftware at>
Sent At:2019 Mar. 13 (Wed.) 19:26
Recipient:Andrey Petushkov <andrey at>
Cc:guangyu.zhu <guangyu.zhu at>; jdk8u-dev <jdk8u-dev at>; denghui.ddh <denghui.ddh at>
Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u


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

On Tue 12. Mar 2019 at 09:35, Andrey Petushkov <andrey at> 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)


 > On 12 Mar 2019, at 16:29, guangyu.zhu <guangyu.zhu at> wrote:
 > Hi Andrey, Mario
 > Is there any progress in backporting? We have completed the patch for the missing features. Please review. 
 > - thread sampling: 
 > - biased locking events: 
 > - G1 heap region (heap summary is still missing, Alibaba's patch does not support heap summary either):
 > Thanks,
 > Guangyu
 > ------------------------------------------------------------------
 > Sender:Andrey Petushkov <andrey at>
 > Sent At:2019 Mar. 6 (Wed.) 00:34
 > Recipient:Mario Torre <neugens at>
 > Cc:guangyu.zhu <guangyu.zhu at>; jdk8u-dev <jdk8u-dev at>; denghui.ddh <denghui.ddh at>
 > Subject:Re: [Preliminary Review]: Proposal for back-porting JFR to OpenJDK8u
 > Hi Mario,
 > > On 4 Mar 2019, at 14:19, Mario Torre <neugens at> wrote:
 > > 
 > > On Fri, Mar 1, 2019 at 8:09 PM Andrey Petushkov <andrey at> 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 <>
 > > 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

More information about the jdk8u-dev mailing list