From claes.redestad at oracle.com Thu Sep 6 14:57:46 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 6 Sep 2018 16:57:46 +0200 Subject: Reviving JEP 230: Microbenchmark Suite Message-ID: Hi, JEP 230: Microbenchmark Suite[1] was proposed during JDK 9 development, but was put on hold for various mundane reasons. I think time has come to revive this effort, andI've volunteered to take over ownership of this JEP. Some time after JEP 230 was temporarily abandoned, the jmh-jdk-microbenchmarks project[2] was conceived to ensure some of the work done to prepare didn't go to waste. A set of previously closed source microbenchmarks was open sourced and contributed there, and artifacts from this project are actively being used to track performance. Thissituation is not ideal, however. A side-effect of the more rapid release cadence is that the bulk of new feature development is being done in project repositories. This creates some very specific challenges when developing benchmarks out-of-tree, especially those that that aim to track new and emerging APIs. For starters we're pushed toward setting up branches that mirror the project layout of the various OpenJDK projects (valhalla, amber, ...), then we need to set up automated builds from each such branch, then have some automated means to match these artifacts with appropriate builds of the project-under-test etc. And how do we even deal with the case when the changes we really want to test are in javac? Nothing is impossible, of course, but the workarounds and added work is turning out to be costly. By co-locating microbenchmarks, matching the JDK-under-test with an appropriate microbenchmark bundle would be trivial and automatic in most cases, and while one always need to be wary of subtle changes creeping into benchmark bundles and the JDK between builds, this is something we already test for automatically as regressions are detected. Also, we wouldn't really lose the ability to pick up an existing microbenchmark artifact as appropriate (a "golden" bundle; appropriate when comparing library and VM changes over a longer time). A standalone project can be considered a good enough fit for that case, so one alternative to moving all of jmh-jdk-microbenchmarks into the JDK would be keep maintaining the standalone project for benchmarks that are considered mature and stable. My preference is to make jmh-jdk-microbenchmarks redundant and then shut it down, though. I think most would typically build and keep a "golden" bundle of a specific version around for longer-term regression tests, so a separate standalone project of JDK micros doesn't make much sense. Also of note is that one of the more controversial aspects of JEP 230 was the question of where to put them. We've since consolidated the OpenJDK source repositories into a single one, so much of what was discussed back then no longer applies. Mainly this simplifies the steps needed to integrate a microbenchmark suite into the JDK, and I've updated the JEP text accordingly. Thanks! /Claes [1] http://openjdk.java.net/jeps/230 [2] http://openjdk.java.net/projects/code-tools/jmh-jdk-microbenchmarks/ From adam.farley at uk.ibm.com Thu Sep 13 13:10:26 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Thu, 13 Sep 2018 14:10:26 +0100 Subject: [General JEP Question] - JEPs and Associated Change Sets: Is there a pattern? Message-ID: Hi All, First, this is a general question about JEPs and their associated change sets. If this is not the correct forum for such questions, I would appreciate being pointed in the right direction. On with the question. Is there a logic to the positioning of change set links in connection to a given JEP? Specifically I'm trying to find out if there's an easy way to figure out what change sets are associated with which JEPs, with an eye to knowing that I have found all of the change sets associated with a given JEP. Right now the layout looks like issue spaghetti. You access the JEP's issue, open every sub-task (most of which won't have change sets in them), and every associated work item, or work item associated with the associated work items, etc etc, until you run out of work items or leave the "theme" of the JEP. You then screen all of those for change set links, and compile a list, Seems crazy, so I'm hoping there's some logic written down somewhere...? Or maybe a web page where you enter a JEP number and get all of the change sets connected to that JEP? That would be good too. :) Best Regards Adam Farley Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From joe.darcy at oracle.com Wed Sep 26 00:15:04 2018 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 25 Sep 2018 17:15:04 -0700 Subject: [General JEP Question] - JEPs and Associated Change Sets: Is there a pattern? In-Reply-To: References: Message-ID: <5BAACF88.4080209@oracle.com> Hello, There is no automated facility to collate links to the changesets comprising a JEP. Cheers, -Joe On 9/13/2018 6:10 AM, Adam Farley8 wrote: > Hi All, > > First, this is a general question about JEPs and their associated change > sets. If this is not the correct forum for such questions, I would > appreciate being pointed in the right direction. > > On with the question. > > Is there a logic to the positioning of change set links in connection to a > given JEP? > > Specifically I'm trying to find out if there's an easy way to figure out > what change sets are associated with which JEPs, with an eye to knowing > that I have found all of the change sets associated with a given JEP. > > Right now the layout looks like issue spaghetti. You access the JEP's > issue, open every sub-task (most of which won't have change sets in them), > and every associated work item, or work item associated with the > associated work items, etc etc, until you run out of work items or leave > the "theme" of the JEP. You then screen all of those for change set links, > and compile a list, > > Seems crazy, so I'm hoping there's some logic written down somewhere...? > > Or maybe a web page where you enter a JEP number and get all of the change > sets connected to that JEP? That would be good too. :) > > Best Regards > > Adam Farley > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU