[8u] [JFR] 8246310 : Clean commented-out code about ModuleEntry andPackageEntry in JFR

[Mario Torre]

On Wed, Jun 3, 2020 at 11:18 AM Andrew Dinn <adinn at redhat.com> wrote:
>
> On 02/06/2020 13:25, Andrew Dinn wrote:
> > On 02/06/2020 12:26, Denghui Dong wrote:
> >> Thank you!
> >>
> >> Webrev has been updated. Some other related code missing in the previous
> >> patch was also removed in the new patch.
> > Ok, I think that counts as reviewed.
> >
> > I am not sure if it can be pushed just yet. jdk8u-dev was frozen
> > yesterday and I have not see a note from Andrew Hughes to say it has
> > been re-opened. Perhaps he can confirm.
> Andrew Hughes has opened up the jdk8u repo today for critical fixes.
>
> Clearly, this current patch is not in itself a critical fix. However, it
> does pave the way for the follow-up JFR leak analysis fix. My view is
> that the follow-up patch also should not be regarded as critical. The
> performance problem the follow-up patch fixes can be avoided by not
> using leak analysis. Clearly users of jdk8u should be able to continue
> to operate their deployments without leak analysis if they are already
> doing so.
>
> So, I suggest that this patch and the follow-up are not pushed until
> after the next jdk8u release. I'll be happy to review the follow-up once
> you provide the extra requested details of the changes made.
>
> Of course, I am not a jdk8u maintainer. If you disagree with me about
> the criticality of these patches you can ask one of the maintainers to
> comment.

We can push to jdk8u-dev normally, I understand this is open for
business as usual, so we don't need to wait the release. I agree the
patch is not critical for jdk8u (the actual July release), and given
the complexity we need more time.

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