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

[Erik Joelsson]

Build changes look ok to me. I would prefer if the long "COMMAND" line 
was broken up though as the side by side diff is already forcing a side 
scroll on my smaller monitor.

/Erik

On 2020-07-23 10:48, Roman Kennke 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
>