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