Hi Erik,
> Hi Roman, > > What is the problem you are trying to solve? > It is mostly an exercise in cleanliness. In the effort to upstream Shenandoah GC to jdk11u (which is still ongoing), it has been asked to make sure that build with Shenandoah excluded (--with-jvm-features=- shenandoahgc) is identical to current build without Shenandoah patch. The symbols and empty method(s) compiled in by JFR have been one of a few places that needed some work. With this patch and a few more, I was able to *prove mechanically* that the objects compiled by unpatched JDK11u are byte-identical to patched JDK11u with Shenandoah disabled. I thought I'd offer this here, maybe it's equally interesting going forward. If it's agreed that it is not very interesting then be it - I don't have a strong opinion about it. Thanks & cheers, Roman > 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 > >
