RFR 8217647: [backport] JFR: recordings on 32-bit systems unreadable

[Mario Torre]

That makes sense to me.

Patch is OK for jdk8u-dev, we need to get a maintainer's approval still.

Cheers,
Mario

On Wed, Jun 17, 2020 at 9:47 AM Denghui Dong
<denghui.ddh at alibaba-inc.com> wrote:
>
> In fact, the main reason I backport this issue to 8u is to make the backport of JDK-8225797 more cleaner,
> so it's okay for me to only push it to jdk8u-dev.
>
> Thank you
> Denghui
>
> ------------------------------------------------------------------
> From:Mario Torre <neugens at redhat.com>
> Send Time:2020年6月16日(星期二) 19:37
> To:Andrey Petushkov <andrey at azul.com>
> Cc:董登辉(卓昂) <denghui.ddh at alibaba-inc.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>
> Subject:Re: RFR 8217647: [backport] JFR: recordings on 32-bit systems unreadable
>
> On Tue, Jun 16, 2020 at 1:02 PM Andrey Petushkov <andrey at azul.com> wrote:
> >
> > Ok. I fully do support idea of code unification.
> > Just one note on the problem, it definitely has existed early on. During
> > backporting to 8u all known to Azul problems have been fixed (in all
> > open code bases which are relevant to 8u). Later, these problems were
> > addressed in upstream separately by the community, and what you're
> > backporting is what, I believe, these fixes in upstream brought. The
> > approach of addressing the problems is different between the two, hence
> > you see the difference and merge conflicts.
>
> I noticed this while reading the code as well, there are lots of
> consolidation but some data types are already 64bits and the few
> places where they would be truncated seem that were already addressed
> before hand.
>
> > So in my understanding 8u codebase does not need this fix per se, but as
> > I said, it's beneficial to have it for the purpose of code unification
> > and simplification of further backports
>
> I can't test 32bit right now, if there are no pending issues and this
> patch doesn't fix anything other than some code consolidation, then I
> suggest to only push this in jdk8u-dev and skip the release train for
> this round (i.e. no critical-fix label).
>
> 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



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