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

[Roman Kennke]

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 <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
> >