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

Andrey Petushkov andrey at azul.com
Tue Mar 5 16:34:49 UTC 2019

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

> 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

More information about the jdk8u-dev mailing list