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

[guangyu.zhu]

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