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 <[email protected]> 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 >
