[8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start() start-up order for correct option parsing

Mario Torre neugens at redhat.com
Mon Jun 8 18:41:19 UTC 2020


On Mon, Jun 8, 2020 at 6:41 PM Jaroslav Bachorík
<jaroslav.bachorik at datadoghq.com> wrote:
>
> Hi Andrew,
>
> On Mon, Jun 8, 2020 at 5:08 PM Andrew Hughes <gnu.andrew at redhat.com> wrote:
> >
> > On 08/06/2020 11:34, Jaroslav Bachorík wrote:
> >
> > snip...
> >
> > >>
> > >> My initial thought is that, if a patch takes a long time in review,
> > >> that's probably a sign that it required a lot of debate and alteration,
> > >> and so shouldn't be going into a release late, rather than the opposite.
> > >
> > > I do not think this is a good example of a contentious issue. The RFR
> > > spent most of its time being idle waiting for review - the only issues
> > > were related to formatting and non-existent test (which does not exist
> > > upstream either). So the point about debate and alteration is rather
> > > moot here.
> > >
> >
> > Ok. I was speaking generally with regard to your comment "this patch
> > missed the cutoff date for 8u262 mostly due to review". In many cases,
> > that alone would be a reason not to include, rather than to include.
> >
> > I haven't followed the discussion that closely, but what you say about
> > this particular patch seems acceptable.
> >
> > >>
> > >> However, I'm of course open to hearing why this is critical to the 8u262
> > >> release and can't wait until 8u272.
> > >
> > > Well, not having JVM segfault on a valid use of JFR would be nice. But
> > > it's your call as the maintainer.
> > >
> >
> > Well, I need information to make such a decision :-)
> >
> > So it would help if you could answer the following:
> >
> > 1. How prolific is such usage of JFR?
>
> I guess not much since till recently each attempt would have resulted
> in segfault.
> But in general I would say that any APM/Profiler based on JFR would be
> happy not to run a special delay code to prevent segfaults.

I think at this stage there's probably no code that segfaults on 8u
because JFR is only available since the next release ;)

But 11 has been patched:

https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/9982cb61e9ca

Also 13 is in the process.

So I think eventually without this patch 8u would be the only one
failing, and we don't really have the safeguard that the same failures
happen in the other releases.

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



More information about the jdk8u-dev mailing list