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

[Erik Gahlin]

Thanks for the explanation.

I think it would better to keep things as is going forward.

Erik

> On 23 Jul 2020, at 22:29, Roman Kennke <rkennke at redhat.com> wrote:
> 
> 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
>>> 
>