[15]: RFR(S): 8241718: assert ((klass)->trace_id()) & ((JfrTraceIdEpoch::method_and_class_in_use_this_epoch_bits()))) != 0 in ObjectSampleCheckpoint::add_to_leakp_set

[David Holmes]

Hi Markus,

On 22/06/2020 3:44 am, Markus Gronlund wrote:
> Greetings,
> 
> Kindly asking for review for the following change set to fix an interoperability issue between JFR and CDS.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8241718
> Webrev: http://cr.openjdk.java.net/~mgronlun/8241718/webrev00/
> Testing: jdk_jfr, runtime/cds
> 
> Summary:
> General: Method* trace flags should not be serialized to the CDS archive and must therefore be removed in Method::remove_unsharable_info().
> JFR specific: CLEAR_METHOD_LEAKP(method) removes the leakp flag on first method write to have it serialize only once.

The fix seems reasonable given the description of the problem.

I'm wondering though how this arises in practice. I can see this could 
be an issue with dynamic archiving as one might expect JFR to be active 
when running the app that will do the dynamic archiving. But for a 
static archive I would (naively perhaps) expect dumping to disable JFR. 
Regardless, incidental state changes due to VM configuration at dump 
time should not be stored in the archive, so I hope there is nothing 
else that we may be storing of a similar nature.

Thanks,
David
-----

> Thanks
> Markus
> 
> 
> 
>