RFR (16): JFR: Separate metadata per JVM-feature

[Erik Gahlin]

Hi Roman,

What is the problem you are trying to solve? 

Speed up compilation, or exclude metadata from recordings?

Having metadata per JVM-features adds complexity with little added benefit from what I can see. 

Thanks
Erik

> On 23 Jul 2020, at 19:48, Roman Kennke <rkennke at redhat.com> wrote:
> 
> This is a fall-out from my Shenandoah upstreaming work in JDK11, where
> I made a similar change in order to separate-out Shenandoah parts from
> JFR build when Shenandoah is disabled.
> 
> Currently, all JFR metadata is collected in a single metadata.xml file.
> From those, the build machinery generates headers and some other things
> from it. For JVM-feature-specific metadata, this leads to stuff
> generated that doesn't exist when the feature is excluded from the
> build. For example, when disabling Shenandoah, we still need to compile
> empty methods in jfrPeriodic.cpp to satisfy the generated code. 
> 
> The fix is to extend the code-generator to accept multiple metadata-
> *.xml files and concatenate the parsing. The version in JDK16 accepts a
> --xml $FILENAME argument, and I'm extending this to --xml
> $FILENAME1:$FILENAME2:.. etc, i.e. multiple filenames separated by
> colon. It allows empty filenames, e.g. metadata.xml::: would be parsed
> as a single file metadata.xml files. That makes the build machinery
> much simpler.
> 
> I also did the relevant metadata-separation for Shenandoah because that
> is what I care about myself. If you'd like other parts treated the
> same, just let me know.
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8250218
> Webrev:
> http://cr.openjdk.java.net/~rkennke/JDK-8250218/webrev.00/
> 
> Testing: build with and without Shenandoah, run some tests, I'd await
> submit-repo results before pushing.
> 
> Can I please get a review?
> 
> Thanks!
> Roman
>