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

[Mario Torre]

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.

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