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

[Andrew Hughes]

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?

2. What are the risks of including this patch?

3. Do we now have a final version of this patch, with test?

4. Was a bug filed for the additional test?

I've no issue with this going in before the test makes it into later JDK
versions, but we should be tracking that this happens.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222