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

[Denghui Dong]

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