[11u] RFR: 8257602: Introduce JFR Event Throttling and new jdk.ObjectAllocationSample event (enabled by default)

[Mario Torre]

Hi Christoph, Jaroslav,

Sorry for the late reply, I missed this conversation back in December :/

I went through the changes and although they seem to be mostly self
contained in the allocation tracer, I still tend to agree with
Christoph and Erik that there's a risk involved in changing the
configurations and metadata and I too think we should have this change
in upstream for a bit longer before considering it for a backport.

With another LTS expected soon I don't think it's a big loss and in
fact, it may be a good reason to update in the first place.

Cheers,
Mario

On Wed, Dec 23, 2020 at 12:34 PM Langer, Christoph
<christoph.langer at sap.com> wrote:
>
> Hi Jaroslav,
>
> I think this is a great enhancement for JFR - but as the word "enhancement" says, it's not a bugfix. So it's not a "must have" for a backport to the LTS. With enhancements we need first of all be very cautious not to endanger stability.
>
> I suggest you get in touch with Red Hat's team around Mario Torre to discuss the idea and feasibility of backporting this to 11u. I think it really has to be discussed whether this item is a good candidate for a backport at all and if so, what testing and other precautions need to be taken before letting this in.
>
> So, for the moment I'll flag the bug with a jdk11u-fix-no. But feel invited to re-request approval via removing that flag after more discussion has been done and a consensus is reached in the community.
>
> Thanks for your understanding!
>
> Best regards
> Christoph
>
>
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> > Behalf Of Jaroslav Bachorík
> > Sent: Montag, 21. Dezember 2020 16:23
> > To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> > Subject: Re: [11u] RFR: 8257602: Introduce JFR Event Throttling and new
> > jdk.ObjectAllocationSample event (enabled by default)
> >
> > Greetings,
> >
> > The original attempt to generate webrev from two changesets failed
> > miserably. Therefore I am updating the webrev links as follows:
> > * Main issue:
> > http://cr.openjdk.java.net/~jbachorik/8257602/jdk11/00/webrev/
> > * Followup AIX build fix:
> > https://cr.openjdk.java.net/~jbachorik/8258094/jdk11/00/webrev/
> >
> > Regards,
> >
> > -JB-
> >
> > On Tue, Dec 15, 2020 at 9:21 AM Jaroslav Bachorík
> > <jaroslav.bachorik at datadoghq.com> wrote:
> > >
> > > Greetings,
> > >
> > > I would like to ask for review of this JDK11u backport patch:
> > >
> > > Issue   :  https://bugs.openjdk.java.net/browse/JDK-8257602
> > > Webrev:
> > http://cr.openjdk.java.net/~jbachorik/8257602/jdk11/00/webrev/
> > >
> > > The webrev contains the main change backported from JDK-8257602 and
> > > the followup patch for AIX build failure resolved as JDK-8258094. I
> > > decided to roll both changesets into one webrev to get a fully
> > > buildable system once this backport request is approved.
> > >
> > > The original changeset of JDK-8257602 had to be slightly adjusted for
> > > the following:
> > > * hunk offsets not matching because of larger structural changes
> > >    resolution: the appropriate code was inserted manually
> > > * missing Atomic::load_acquire and Atomic::release_store functions
> > >    resolution: used OrderAccess::* equivalents
> > > * different argument order for Atomic::cmpxchg and Atomic::store
> > >    resolution: modified the call-site argument order to match what is
> > > provided by Atomic::*
> > > * [test] missing support for event streaming
> > >    resolution: used the recording in non-streaming mode while keeping
> > > the test semantics
> > >
> > > All tier1, tier2 and jdk_jfr tests are passing with the changes applied.
> > >
> > > Cheers,
> > >
> > > -JB-



-- 
Mario Torre
Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898