From forax at univ-mlv.fr Sat Sep 1 11:48:10 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 1 Sep 2018 13:48:10 +0200 (CEST) Subject: Provide api for accessing bytecode from java.lang.reflect.Method. In-Reply-To: <1535735813.95987216@f416.i.mail.ru> References: <1535735813.95987216@f416.i.mail.ru> Message-ID: <1262014749.1279938.1535802490483.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "?????? ??????" > ?: "jdk-dev" > Envoy?: Vendredi 31 Ao?t 2018 19:16:53 > Objet: Provide api for accessing bytecode from java.lang.reflect.Method. > Hi, Hi ! > > In .NET we can retrieve bytecode array from reflected class, e.g.: > > MethodInfo mi = typeof (Example).GetMethod( "MethodBodyExample" ); > MethodBody mb = mi.GetMethodBody(); > var bytes= mb.GetILAsByteArray(); > > How about having something like this in java ? Leveraging this, it would be > possible to get bytecode of currently loaded classes (including lambdas), > killing the need to load class as a resource. I may be wrong but the main difference is that in .Net the bytecode array of a method contains references (metadata tokens) to one global datastructure (metadata tables) for whole the program while in Java, the bytecode array contains references to one data structure per class so in Java returning a byte array without the class is useless because you do not know how to interpret it. > > > > > ? ?????????, > ?????? ?????? regards, R?mi From aleksej.efimov at oracle.com Wed Sep 5 14:14:45 2018 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Wed, 5 Sep 2018 15:14:45 +0100 Subject: CFV: New JDK Committer: Leo Jiang In-Reply-To: <3b449fd5-bbdb-c67a-a68f-bcabd8cfa105@oracle.com> References: <3b449fd5-bbdb-c67a-a68f-bcabd8cfa105@oracle.com> Message-ID: <15a60bc9-3613-fd1f-68ed-b5bb7055e931@oracle.com> Vote: yes With Best Regards, Aleksei On 08/29/2018 02:37 AM, naoto.sato at oracle.com wrote: > I hereby nominate Leo Jiang (ljiang) to JDK Committer. > > Leo works for the Oracle localization team and has contributed more > than 30 changes. His contributions can be found here [3]. > > Votes are due by 19:00 pm PT, September 11, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Naoto Sato > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=(keyword(%22li.jiang%40oracle.com%22)+or+author(ljiang)) From roger.riggs at oracle.com Wed Sep 5 14:33:17 2018 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 5 Sep 2018 10:33:17 -0400 Subject: CFV: New JDK Committer: Leo Jiang In-Reply-To: <3b449fd5-bbdb-c67a-a68f-bcabd8cfa105@oracle.com> References: <3b449fd5-bbdb-c67a-a68f-bcabd8cfa105@oracle.com> Message-ID: Vote: Yes On 8/28/18 9:37 PM, naoto.sato at oracle.com wrote: > I hereby nominate Leo Jiang (ljiang) to JDK Committer. From claes.redestad at oracle.com Thu Sep 6 15:16:08 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 6 Sep 2018 17:16:08 +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, and I'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. This situation 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 netbeans at post.cz Thu Sep 6 06:24:08 2018 From: netbeans at post.cz (netbeans at post.cz) Date: Thu, 06 Sep 2018 08:24:08 +0200 (CEST) Subject: Reaction to JEP 326/JDK-8196004 Message-ID: Dear JDK dev. Let me react to JEP 326: Raw String Literals and related https://bugs. openjdk.java.net/browse/JDK-8196004 (https://bugs.openjdk.java.net/browse/JDK-8196004). 1) in case of path This should not be hard code in source code, but it should be part of configuration 2) example of html This should be part of templates and including translations 3) script function This should be part of external file to be e.g. validated by editor regarding to used languages so not part of Java source code. 4) regexp I think that better to provide exact operator to write regexp directly /.*/ 5) query I think that this is not really good design as building query should be part of query builder to ensure security. 6) "`" I am affraid that all keyboards have this. Best regards. From shade at redhat.com Thu Sep 6 16:28:42 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 6 Sep 2018 18:28:42 +0200 Subject: Reviving JEP 230: Microbenchmark Suite In-Reply-To: References: Message-ID: <8bbe2cf1-47ba-76a2-40d0-74569f81e060@redhat.com> Hi, I think this proposal tries hard to push for co-location without properly considering the drawbacks of it. The major drawback is: pushing corpus to JDK tree means we effectively tie the corpus versioning to JDK versioning. Instead of golden corpus that could be used for cross-JDK tests (which is _much more_ important with faster release cadence), we now would have the similar benchmarks carried over in jdk12, in jdk13, in jdk14, etc. And this gives us the cluster of problems: 1. What happens when JMH updates are needed (e.g. infra bugs fixed, more features in APIs, or profilers)? Are we pushing the JMH version update to all jdk repositories at once? How does that work with the notion that some repositories get abandoned within months after inception? 2. What happens when JMH API changes? The golden corpus is good for coordinated change like that: we update the JMH APIs, and we fix all benchmarks at once. Co-located repository means you would need to do this work N times, for each supported tree. 3. What happens when benchmark is added *after* feature development? For example, when we add benchmarks for jdk11 features when jdk12 is in development? How do these benchmarks get from jdk/jdk to jdk-updates/jdkXu? Are we now looking into backporting the benchmarks too? 4. What happens when benchmark has a testbug? Do we sift the changes to that benchmark down to every jdk-updates/jdkXu? Notice "when", not "if". Benchmarks are much more fluid than jtreg regression tests, and require much more care during their lifetime. The separate jcstress repository was very handy when solving all these problems wholesale. While we can argue that some repositories would be abandoned for a reason (e.g. "we" do not care about jdk10 once jdk11 is released), it is a kick in the gut for community maintainers that pick up what Oracle abandoned. In other words, this argument is a moral hazard. I guess we can make the argument that the "golden" corpus is the one in jdk/jdk, and that corpus should be used for all benchmarks. But it also comes with a bunch of questions: a. Philosophical. This is jmh-jdk-microbenchmarks in disguise, which we already have, why bother? b. Educational. What exactly prevents the user who runs 8-feature-specific benchmark, from taking jdk-updates/jdk11 corpus while running 11 binaries, and taking jdk/jdk while running 12 binaries? I would guess build system changes for benchmark co-location would make that a natural thing to do. How would users know that any of (1)...(4) pitfalls might be in effect? If we argue that internal Oracle test systems are aware of this possibility, and act correctly to resolve it -- not only this is a moral hazard, it is also a bad design, when a natural way is the faulty one. c. Technical. When users want to run benchmarks against already existing binary, for example, 8u181, 10.0.2, 11, and current dev, what do users do? Okay, checking out the entire jdk/jdk is a bearable hassle. What then? Does OpenJDK build system produce a JAR somewhere in build/ that we need to pick up from, and it runs normal JMH from there? This piles on "why bother" question above. Or does OpenJDK build system know enough to accept outside JDK with its build target option that it could be executed from "make ..."? This piles on "natural way' question above. On 09/06/2018 05:16 PM, Claes Redestad wrote: > 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. So, why take the entire corpus hostage for a handful of benchmarks against APIs that are not yet stable? Can we put the {valhalla, amber, whatever} benchmarks in their specific JDK trees, and only them? Once the feature graduates into the released JDK, its benchmarks get contributed to the benchmark corpus, wherever it is. > 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. Saying as the guy who supported j.u.c/VarHandles tests in jcstress, it did not feel costly. Take a step back. Once benchmarks are done against the published APIs, they are just like any other 3rd party test suite that is run against JDK, be that jcstress, Lucene tests, bigapps, etc. Painting the infrastructure need as additional hassle misses that this part has to be done efficiently for 3rd party suites anyway. > 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. It sounds that this co-location proposal tries to simplify operational issues for Oracle testing systems, right? I remember solving the matching problem in current corpus by splitting the corpus by minimal JDK version required to run the benchmark, and building the parts separately with different source/target, then trivially matching "ha, this is JDK 9, better run benchmarks-9.jar". This mechanism seems very local, and does not give versioning headaches outlined above. I cannot remember at which point all that was lumped together into the single module in jmh-jdk-microbenchmarks project, which gives us the matching problem we are now trying to resolve. > 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. I prefer to keep separate jmh-jdk-microbenchmarks project, and do whatever JDK compatibility work there. Putting the in-flight unstable benchmarks into the relevant non-mainline feature trees seems to be the good compromise to shield the jmh-jdk-microbenchmarks from the need to address feature-specific troubles with benchmarks under heavy development. -Aleksey From claes.redestad at oracle.com Thu Sep 6 17:30:27 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 6 Sep 2018 19:30:27 +0200 Subject: Reviving JEP 230: Microbenchmark Suite In-Reply-To: <8bbe2cf1-47ba-76a2-40d0-74569f81e060@redhat.com> References: <8bbe2cf1-47ba-76a2-40d0-74569f81e060@redhat.com> Message-ID: Hi, On 2018-09-06 18:28, Aleksey Shipilev wrote: > Hi, > > I think this proposal tries hard to push for co-location without properly considering the drawbacks > of it. I've considered many more pros and cons than has been outlined in this introductory "Hey, I intend to work on this thing again" proposal. But I digress... :-) > > The major drawback is: pushing corpus to JDK tree means we effectively tie the corpus versioning to > JDK versioning. Instead of golden corpus that could be used for cross-JDK tests (which is _much > more_ important with faster release cadence), we now would have the similar benchmarks carried over > in jdk12, in jdk13, in jdk14, etc. Microbenchmark bundles would effectively be released and versioned with their respective JDK. If I want to compare back to jdk12, I'd use the "golden" bundle released with that build (or some earlier). The number of times we've decided to upgrade to a new version of the microbenchmarks corpus for an older release to date is zero, while the number of times we've added in new configurations for benchmarks in development is significant. Optimizing the process for ongoing development seems sensible, but of course we should try to make backporting etc as manageable as possible. I think the drawbacks you're hypothesizing about below will turn out to be more manageable in reality than you make them out to be. > > And this gives us the cluster of problems: > > 1. What happens when JMH updates are needed (e.g. infra bugs fixed, more features in APIs, or > profilers)? Are we pushing the JMH version update to all jdk repositories at once? How does that > work with the notion that some repositories get abandoned within months after inception? On a case by case basis. The main purpose of "golden" bundles is to not have to make any changes and preserve predictable results over a longer time trend, so I see backports as something to be avoided. This is in line with the new release model: we backport stability and critical bug fixes, not features. When they are needed, they should follow the typical path of being pushed to jdk/jdk first, then backport back as far as necessary. > > 2. What happens when JMH API changes? The golden corpus is good for coordinated change like that: > we update the JMH APIs, and we fix all benchmarks at once. Co-located repository means you would > need to do this work N times, for each supported tree. I think this would continue to be a rare occurrence, but if a coordinated change has to be done I'm sure it can be done. > 3. What happens when benchmark is added *after* feature development? For example, when we add > benchmarks for jdk11 features when jdk12 is in development? How do these benchmarks get from jdk/jdk > to jdk-updates/jdkXu? Are we now looking into backporting the benchmarks too? I'd avoid it, but it seems reasonable to allow backporting benchmarks, or otherwise ensure we can build bundles that are runnable on update releases. > 4. What happens when benchmark has a testbug? Do we sift the changes to that benchmark down to > every jdk-updates/jdkXu? > > Notice "when", not "if". Benchmarks are much more fluid than jtreg regression tests, and require > much more care during their lifetime. The separate jcstress repository was very handy when solving > all these problems wholesale. Arguably, it also goes the other way: certain benchmarks need to be different to capture the underlying behavior of the JDK under test, especially if what you're testing is provoking some indirect behavior (GC, reference processing). I don't think there's a one-size-fits-all solution here, and the "golden" standard that is jmh-jdk-microbenchmarks might not always be doing the "right thing" on older and newer JDKs alike. > > While we can argue that some repositories would be abandoned for a reason (e.g. "we" do not care > about jdk10 once jdk11 is released), it is a kick in the gut for community maintainers that pick up > what Oracle abandoned. In other words, this argument is a moral hazard. > > I guess we can make the argument that the "golden" corpus is the one in jdk/jdk, and that corpus > should be used for all benchmarks. But it also comes with a bunch of questions: > > a. Philosophical. This is jmh-jdk-microbenchmarks in disguise, which we already have, why bother? I think there are several benefits outside of those outlined here. > > b. Educational. What exactly prevents the user who runs 8-feature-specific benchmark, from taking > jdk-updates/jdk11 corpus while running 11 binaries, and taking jdk/jdk while running 12 binaries? I > would guess build system changes for benchmark co-location would make that a natural thing to do. > How would users know that any of (1)...(4) pitfalls might be in effect? If we argue that internal > Oracle test systems are aware of this possibility, and act correctly to resolve it -- not only this > is a moral hazard, it is also a bad design, when a natural way is the faulty one. Documenting best practices and why doing comparisons using benchmarks picked from different places are hazardous is part of the plan for this JEP. I think a much more common use-case is that you have a change against the repo you're working on and you want to test it locally. Having a "natural way" to build and run said changes using the benchmarks available and under development in the same repo would be great for many. > > c. Technical. When users want to run benchmarks against already existing binary, for example, > 8u181, 10.0.2, 11, and current dev, what do users do? Okay, checking out the entire jdk/jdk is a > bearable hassle. What then? Does OpenJDK build system produce a JAR somewhere in build/ that we need > to pick up from, and it runs normal JMH from there? This piles on "why bother" question above. Or > does OpenJDK build system know enough to accept outside JDK with its build target option that it > could be executed from "make ..."? This piles on "natural way' question above. A build target to produce a JAR somewhere is planned, yes. I think tools to help pick up the right JDKs and benchmark JARs is out of scope for this JEP, but definitely something that could be worked on and contributed separately. > > On 09/06/2018 05:16 PM, Claes Redestad wrote: >> 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. > So, why take the entire corpus hostage for a handful of benchmarks against APIs that are not yet > stable? Can we put the {valhalla, amber, whatever} benchmarks in their specific JDK trees, and only > them? Once the feature graduates into the released JDK, its benchmarks get contributed to the > benchmark corpus, wherever it is. I have outlined this as an alternative, which you replied to below. > >> 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. > Saying as the guy who supported j.u.c/VarHandles tests in jcstress, it did not feel costly. > > Take a step back. Once benchmarks are done against the published APIs, they are just like any other > 3rd party test suite that is run against JDK, be that jcstress, Lucene tests, bigapps, etc. Painting > the infrastructure need as additional hassle misses that this part has to be done efficiently for > 3rd party suites anyway. The general experience around here is that co-locating test suites has greatly increased productivity in several ways. There are naturally valid reasons not to in specific cases, be they practical or legal. > > >> 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. > It sounds that this co-location proposal tries to simplify operational issues for Oracle testing > systems, right? It's a motivating factor, yes, but not the sole or even main motivator for this. Things like simplifying for *any* dev to contribute microbenchmarks for the feature they are working on is higher up on my list. > > I remember solving the matching problem in current corpus by splitting the corpus by minimal JDK > version required to run the benchmark, and building the parts separately with different > source/target, then trivially matching "ha, this is JDK 9, better run benchmarks-9.jar". This > mechanism seems very local, and does not give versioning headaches outlined above. I cannot remember > at which point all that was lumped together into the single module in jmh-jdk-microbenchmarks > project, which gives us the matching problem we are now trying to resolve. I think the corpus was cleaned up to be a single module before it was open sourced, but I wasn't part of the decision process for that so I can't tell what the reasoning at the time was. > >> 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. > I prefer to keep separate jmh-jdk-microbenchmarks project, and do whatever JDK compatibility work > there. Putting the in-flight unstable benchmarks into the relevant non-mainline feature trees seems > to be the good compromise to shield the jmh-jdk-microbenchmarks from the need to address > feature-specific troubles with benchmarks under heavy development. Something along these lines could be a reasonable compromise, yes. It does carry with it some questions, such as do we keep the benchmarks we've developed in the jdk repo forever, or remove them as we migrate them to jmh-jdk-microbenchmarks? /Claes From jiangli.zhou at oracle.com Thu Sep 6 19:45:59 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 6 Sep 2018 12:45:59 -0700 Subject: RFR: JDK-8202951: Implementation of JEPJDK-8204247: Include default CDS (Class Data Sharing) archive in JDK binary In-Reply-To: References: <8e17729f-9f5b-4d7c-a8cf-e0d3ffeeb694@oracle.com> Message-ID: <0f79551e-5f0a-b7f4-cc72-eb84ed8baa14@oracle.com> Hi, The JEP (http://openjdk.java.net/jeps/341) for the default CDS archives is now a candidate. Please see Mark's email, 'New candidate JEP: 341: Default CDS Archives'. Please help test Erik's makefile patch for your platform if it is not built/tested in openjdk mainline to prevent any possible breakage on your side. Any comments/feedbacks on the default CDS archive are highly appreciated! ? http://cr.openjdk.java.net/~jiangli/8202951/webrev.02/ The above webrev is sync'ed with the lasted jdk/jdk repository today. Thanks! Jiangli On 8/30/18 11:26 AM, Jiangli Zhou wrote: > Hi Magnus, > > Sounds good. Will update the message. > > Thanks! > > Jiangli > > > On 8/30/18 3:56 AM, Magnus Ihse Bursie wrote: >> On 2018-08-29 17:45, Erik Joelsson wrote: >>> >>> Hello Magnus, >>> >>> As the author of the build changes I will answer this. >>> >>> On 2018-08-29 04:53, Magnus Ihse Bursie wrote: >>>> On 2018-08-28 18:25, Erik Joelsson wrote: >>>>> Build changes look good to me (but should probably get review from >>>>> someone else). >>>> >>>> I'm (as usually) not as happy as Erik. ;-) >>>> >>>> In Images.gmk, you have added this rule: >>>> ????????? $@ -Xshare:dump -Xmx128M -Xms128M $(LOG_INFO) >>>> >>>> It took me a while to grasp. You are relying on >>>> $(JIMAGE_TARGET_FILE) to evaluate to bin/java. But that is only >>>> incidentally so. This file is just picked arbitrarily to represent >>>> when the entire image is done, for make. Please use >>>> $(JRE_IMAGE_DIR)/bin/java instead. >>>> >>> I can agree with this part. That was a bit of a hack done in a hurry. >>>> The logic in jdk-options.m4 is broken. If indeed it is not possible >>>> to use cds archive with zero, then things will break since it will >>>> still be built if using --enable-cds-archive! >>>> >>>> What you should do is to set default to true unless using cross >>>> compilation or zero. If the user explicitly sets >>>> --enable-cds-archive, and it's not possible, a fatal error should >>>> be generated. >>>> >>> Here I'm not as sure. I deliberately let it be possible to override >>> the default behavior for zero as someone might want to fix that at >>> some point, you never know. For cross compilation it's just not >>> possible ever so that's different. Maybe my reasoning is invalid. >> >> I see. I still think it would have made more sense, in that case, to >> set the default to false if using zero, but allow override. But I'm >> not going to insist on that. >> >> However, if the problem with zero is not that it's technically >> impossible, just that it's not tested, I think the message should be >> changed from "[no, not possible with JVM variant zero]" to just >> "[no]" with a comment in the configure script that it's off by >> default since it's not tested. >> >> Apart from that, Jiangli's latest webrev looks good. >> >> Jiangli: If you fix it like I suggested, you do not need to respin >> the webrev. >> >> /Magnus >> >>> >>> /Erik >>>> Apart from this, I'm more on Erik's line. :-) >>>> >>>> /Magnus >>>> >>>> >>>> >>>>> >>>>> /Erik >>>>> >>>>> >>>>> On 2018-08-27 13:33, Jiangli Zhou wrote: >>>>>> Please review the implementation for JEP JDK-8204247 >>>>>> (https://bugs.openjdk.java.net/browse/JDK-8204247). The goal of >>>>>> the JEP is to include a default CDS archive in JDK 12 binary >>>>>> distribution (downloadable from http://jdk.java.net/12/). The >>>>>> default CDS archive is generated using the default classlist >>>>>> (resides in the lib/ directory) at JDK build time. Any >>>>>> comments/suggestions are highly appreciated. >>>>>> >>>>>> All makefile changes in the webrev are contributed by Erik >>>>>> Joelsson (many thanks!!). >>>>>> >>>>>> This is a combination of efforts from different teams and >>>>>> individuals. Thanks to everyone who has been involved in the JEP >>>>>> & implementation discussions, testing and bug fixing! >>>>>> >>>>>> ? JEP: https://bugs.openjdk.java.net/browse/JDK-8204247 >>>>>> ? RFE: https://bugs.openjdk.java.net/browse/JDK-8202951 >>>>>> ? webrev: http://cr.openjdk.java.net/~jiangli/8202951/webrev.00/ >>>>>> >>>>>> Two sanity test cases for the default CDS archive are included >>>>>> test/hotspot/jtreg/runtime/SharedArchiveFile. They are not >>>>>> intended for in-depth CDS functional testing, which is already >>>>>> covered by the existing cds/appcds tests and all tiered tests >>>>>> executing with the default CDS archive enabled. >>>>>> >>>>>> As part of the webrev, >>>>>> test/jdk/javax/imageio/plugins/png/ItxtUtf8Test.java is also >>>>>> fixed to use larger java heap (JDK-8209739 >>>>>> , https://bugs.openjdk.java.net/browse/JDK-8209739). >>>>>> >>>>>> Tests executed: >>>>>> ?- several rounds of tier1 - tier8 via mach5 >>>>>> ?- JCK lang, api and vm tests via mach5 >>>>>> >>>>>> >>>>>> Thanks! >>>>>> Calvin, Ioi, Jiangli >>>>>> >>>>>> >>>>> >>>> >>> >> > From Ed.Munoz at microfocus.com Thu Sep 6 22:54:05 2018 From: Ed.Munoz at microfocus.com (Ed Munoz) Date: Thu, 6 Sep 2018 22:54:05 +0000 Subject: What does LTS mean for OpenJDK? Message-ID: The responses on this thread have helped to clarify the situation regarding OpenJDK 11 and later. (Thank you!) I have similar questions regarding OpenJDK 8. Dalibor Topic's post below says: > A similar transition [of maintainers] would also happen for OpenJDK 8 Updates after January 2019, assuming that a suitable Project Lead steps forward to carry on the maintenance work led by Oracle developers since 2014. Questions: 1) Are there one or more parties willing to step forward to assume the role of maintainer for JDK 8 after Oracle steps down as maintainer? For example, Red Hat has said it may step forward to be the maintainer for JDK 11 - might it also step forward to be the maintainer for JDK 8? 2) Will Oracle's expected announcement on "End of maintenance & invitation for new maintainers" for JDK 8 be posted on this (jdk-dev) mailing list? Or on jdk8u-dev? It would be helpful to know where and when to watch for it. 3) What platforms will be maintained for JDK 8 after the new maintainer steps in? If this is not yet known, when can we expect to get clarification on this? Will it be the same platforms as are currently supported? Or are some platform changes expected? Will Win32 still be supported? 4) How long will JDK 8 be maintained? A Red Hat site lists June 2023, referring to JDK support in RHEL. https://access.redhat.com/articles/1299013 The AdoptOpenJDK site lists September 2022. https://adoptopenjdk.net/support.html When do we expect to have a more definite sense of how long OpenJDK 8 security updates will be available for the various platforms that OpenJDK supports? 5) Let's expand Jack Shirazi's post about JDK 11 support to include JDK 8. Is this a reasonable statement of what is expected to happen with security updates? Assume it is less than 6 months since the release of JDK 12 (say, July 2019), and Oracle announces a security update to Java. - Oracle would apply that to their paid-for Oracle Java 12 build (and possibly to some paid-for Oracle Java back versions). - Oracle would also apply it to the OpenJDK Java 12 build. - Oracle would NOT apply it the latest OpenJDK Java 11 build. - The jdk11u project WILL backport that to the OpenJDK Java 11 build. - AdoptOpenJDK will provide builds of that Java 11 upgraded version, so that upgraded OpenJDK Java 11 build will be available for public consumption. - The jdk8u project WILL backport that to the OpenJDK Java 8 build. - AdoptOpenJDK will provide builds of that Java 8 upgraded version, so that upgraded OpenJDK Java 8 build will be available for public consumption. Thanks, -Ed Munoz ed.munoz at microfocus.com -------------------------------------------------------- Date: Mon, 20 Aug 2018 15:23:42 +0200 From: dalibor topic > To: jdk-dev at openjdk.java.net Subject: Re: What does LTS mean for OpenJDK? Message-ID: <4350b6f9-d169-359e-d278-b31220a3d03b at oracle.com> Content-Type: text/plain; charset=utf-8; format=flowed On 17.08.2018 18:36, Stephen Colebourne wrote: > The LTS (long term support) release Java 11 is nearly upon us. But > what does LTS mean in the context of OpenJDK? Please see http://openjdk.java.net/jeps/322 "If a release is part of a series of releases for which an implementor offers long-term support then the value of $OPT should start with "LTS", e.g., 11.0.2+13-LTS. This will cause "LTS" to be displayed prominently in the output of java --version, etc." Whether an implementor decides to offer long term support for a given OpenJDK release, for how long they do it, which platforms they chose to support in this way, is ultimately up to them. So far Oracle, for example, has cumulatively contributed almost 15 years of maintenance to OpenJDK between OpenJDK 6, JDK 7 Updates, JDK 8 Updates, JDK 9 updates and JDK 10 updates across a lot of different OS/CPU platforms. Over the last couple of years, we have developed a model to transition between different teams of maintainers across OpenJDK update releases. For example, Oracle developers maintained OpenJDK 6 for 5 years. After they stepped down, they enabled other developers to take over OpenJDK 6 maintenance. Those developers, focusing on a different set of operating systems from Oracle developers, continued to work on the OpenJDK 6 source code until, eventually, they stopped. Then another set of developers continued where they left, with yet again a different set of operating systems that they cared about. A similar transition has happened with OpenJDK 7 Updates, after almost 4 years of maintenance by Oracle developers. A similar transition would also happen for OpenJDK 8 Updates after January 2019, assuming that a suitable Project Lead steps forward to carry on the maintenance work led by Oracle developers since 2014. Since such transitions are bound to happen more often under the new release cycle, there is a process for them in the JDK Updates Project as described in http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-February/000064.html . You can observe that process in the works via the jdk-updates-dev mailing list, specifically with respect to JDK 10 maintenance via http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-July/000143.html . > What will Java 11 get from Oracle? Well, long term support, for one, as discussed on http://www.oracle.com/technetwork/java/eol-135779.html . But beside that, it will get a reference implementation in OpenJDK. Followed by, assuming that the transition from JDK 10 to JDK 11 proves to be as smooth as the transition from JDK 9 to JDK 10 was, at least six months of JDK 11 updates maintained by Oracle developers and contributed to the corresponding OpenJDK JDK Updates Project jdk11u repository along with binaries being published at http://jdk.java.net. Finally, JDK 11 would get an orderly maintainer transition process. Specifically, at some point after a jdk11u repo is established in the JDK Updates Project, an e-mail to jdk-updates-dev would announce when Oracle would stop contributing to that particular repository. For JDK 10, it looked like this: http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-May/000128.html . After the last OpenJDK JDK 11u release led by Oracle, a call for future 11u maintainers such as http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-July/000143.html would go out on the jdk-updates-dev list, and, if someone qualified stepped up on the list, there would be some work to do on an orderly transition of maintainer duties for that repo within the JDK Update Project - rather unexciting things like dealing with updates to hgcheck and jcheck configurations for the repo, for example. You can read the jdk7u-dev mailing list archives from the time of transition, if you want to know the details. Some details will of course end up being slightly different for JDK 11 Updates, since we will use the existing JDK Updates Project for jdk11u, we'll have a single repo instead of a forest, and so on. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Fri Sep 7 08:29:03 2018 From: dalibor.topic at oracle.com (dalibor topic) Date: Fri, 7 Sep 2018 10:29:03 +0200 Subject: What does LTS mean for OpenJDK? In-Reply-To: References: Message-ID: <1f6cd7a9-7a5c-f4a6-0035-9d9995c9b78d@oracle.com> On 07.09.2018 00:54, Ed Munoz wrote: > The responses on this thread have helped to clarify the situation > regarding OpenJDK 11 and later. (Thank you!) > > I have similar questions regarding OpenJDK 8. > > Dalibor Topic?s post below says: > > > A similar transition [of maintainers] would also happen for OpenJDK 8 > Updates after January 2019, assuming that a suitable Project Lead steps > forward to carry on the maintenance work led by Oracle developers since > 2014. > > Questions: > > > 2) Will Oracle?s expected announcement on "End of maintenance & > invitation for new maintainers" for JDK 8 be posted on this (jdk-dev) > mailing list? No. > Or on jdk8u-dev? Yes. > 5) Let?s expand Jack Shirazi?s post about JDK 11 support to include JDK > 8. Is this a reasonable statement of what is expected to happen with > security updates? > > Assume it is less than 6 months since the release of JDK 12 (say, July > 2019), and Oracle announces a security update to Java. > > - Oracle would apply that to their paid-for Oracle Java 12 build (and > possibly to some paid-for Oracle Java back versions). As before, Oracle's CPU schedule is available here: https://www.oracle.com/technetwork/topics/security/alerts-086861.html and the support roadmap is available here: http://www.oracle.com/technetwork/java/eol-135779.html . Based on these documents, you can determine which Oracle Java SE releases receive a Critical Patch Update on July 16th, 2019. > - Oracle would also apply it to the OpenJDK Java 12 build. As with OpenJDK 6, OpenJDK 7 Updates, OpenJDK 8 Updates, OpenJDK 9 and OpenJDK 10, the applicable changes in the corresponding Oracle CPU release are applied to all Oracle-led OpenJDK update releases as well. > - Oracle would NOT apply it the latest OpenJDK Java 11 build. At this point in time, that's not possible to say with confidence for a given date six months after JDK 11 GA. I think the phrase 'at least six months of updates' has come up in this thread a couple of times already. We are currently winding down JDK 10 Updates maintenance in the JDK Updates Project, per http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-July/000143.html . At some point in time after JDK 11 is released, a mail like http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-May/000128.html will be sent out to the jdk-updates-dev mailing list, outlining Oracle's plans for further contributions regarding that particular release. So in short, if you want to know when Oracle will stop contributing changes to JDK 11 updates in OpenJDK, please subscribe to the jdk-updates-dev mailing list, and monitor it for updates. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From aph at redhat.com Fri Sep 7 08:55:20 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 7 Sep 2018 09:55:20 +0100 Subject: What does LTS mean for OpenJDK? In-Reply-To: References: Message-ID: <613240e9-40da-68df-8405-887f0fc559cf@redhat.com> On 09/06/2018 11:54 PM, Ed Munoz wrote: > The responses on this thread have helped to clarify the situation regarding OpenJDK 11 and later. (Thank you!) > I have similar questions regarding OpenJDK 8. >> A similar transition [of maintainers] would also happen for OpenJDK >> 8 Updates after January 2019, assuming that a suitable Project Lead >> steps forward to carry on the maintenance work led by Oracle >> developers since 2014. > Questions: > 1) Are there one or more parties willing to step forward to assume > the role of maintainer for JDK 8 after Oracle steps down as > maintainer? For example, Red Hat has said it may step forward to be > the maintainer for JDK 11 - might it also step forward to be the > maintainer for JDK 8? Yes. > 2) Will Oracle's expected announcement on "End of maintenance & > invitation for new maintainers" for JDK 8 be posted on this > (jdk-dev) mailing list? Or on jdk8u-dev? It would be helpful to know > where and when to watch for it. > 3) What platforms will be maintained for JDK 8 after the new > maintainer steps in? If this is not yet known, when can we expect to > get clarification on this? Will it be the same platforms as are > currently supported? Or are some platform changes expected? Will > Win32 still be supported? I expect most platforms will continue to be the same, but I don't know about Windows 32. I'd personally like to see Windows 32 support end, but there may still be some interest. Mainstream support for Windows 7 ended a long time ago; extended support for Windows 7 ends at the beginning of 2020. Microsoft just announced an extension for bulk customers with deep pockets, so who knows. Are many of them likely to be 32 bit? > 4) How long will JDK 8 be maintained? A Red Hat site lists June > 2023, referring to JDK support in > RHEL. https://access.redhat.com/articles/1299013 The AdoptOpenJDK > site lists September 2022. https://adoptopenjdk.net/support.html > When do we expect to have a more definite sense of how long OpenJDK > 8 security updates will be available for the various platforms that > OpenJDK supports? AdoptOpenJDK can provide binaries for as long as they want to: it doesn't affect the jdk8u project. June 2023 is right for JDK 8, but I wouldn't be surprised if it goes on beyond that. > 5) Let's expand Jack Shirazi's post about JDK 11 support to include > JDK 8. Is this a reasonable statement of what is expected to happen > with security updates? > Assume it is less than 6 months since the release of JDK 12 (say, > July 2019), and Oracle announces a security update to Java. > > - Oracle would apply that to their paid-for Oracle Java 12 build > (and possibly to some paid-for Oracle Java back versions). > > - Oracle would also apply it to the OpenJDK Java 12 build. > > - Oracle would NOT apply it the latest OpenJDK Java 11 build. That sounds about right. > - The jdk11u project WILL backport that to the OpenJDK Java 11 build. Yes, > - AdoptOpenJDK will provide builds of that Java 11 upgraded version, > so that upgraded OpenJDK Java 11 build will be available for public > consumption. I don't know what AdoptOpenJDK would do with their builds, but I presume so. > - The jdk8u project WILL backport that to the OpenJDK Java 8 build. If applicable, yes. > - AdoptOpenJDK will provide builds of that Java 8 upgraded version, > so that upgraded OpenJDK Java 8 build will be available for public > consumption. Let's talk about binaries. If you're using any kind of a Linux/GNU system you'll want to use your distro's packages and update manager, so we don't need to talk about Linux. Binary downloads, are, therefore only really relevant to Windows and (perhaps) Macintosh. I want the future updates project(s) to produce official Windows binaries (perhaps built and tested jointly with AdoptOpenJDK, but we haven't decided) and I'd like to see Macintosh binaries too. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From martijnverburg at gmail.com Fri Sep 7 12:58:34 2018 From: martijnverburg at gmail.com (Martijn Verburg) Date: Fri, 7 Sep 2018 13:58:34 +0100 Subject: What does LTS mean for OpenJDK? In-Reply-To: <613240e9-40da-68df-8405-887f0fc559cf@redhat.com> References: <613240e9-40da-68df-8405-887f0fc559cf@redhat.com> Message-ID: Hi all, I'll add a few bits inline from Adopt (and snip the rest). On Fri, 7 Sep 2018 at 09:55, Andrew Haley wrote: > On 09/06/2018 11:54 PM, Ed Munoz wrote: > > > 3) What platforms will be maintained for JDK 8 after the new > > maintainer steps in? If this is not yet known, when can we expect to > > get clarification on this? Will it be the same platforms as are > > currently supported? Or are some platform changes expected? Will > > Win32 still be supported? > > I expect most platforms will continue to be the same, but I don't know > about Windows 32. I'd personally like to see Windows 32 support end, > but there may still be some interest. Mainstream support for Windows 7 > ended a long time ago; extended support for Windows 7 ends at the > beginning of 2020. Microsoft just announced an extension for bulk > customers with deep pockets, so who knows. Are many of them likely to > be 32 bit? > AdoptOpenJDK has a couple of contributors who are working on maintaining Win32. They'll follow the usual process of signing the OCA, submitting patches to OpenJDK (build-dev mainly) etc. > > 4) How long will JDK 8 be maintained? A Red Hat site lists June > > 2023, referring to JDK support in > > RHEL. https://access.redhat.com/articles/1299013 The AdoptOpenJDK > > site lists September 2022. https://adoptopenjdk.net/support.html > > When do we expect to have a more definite sense of how long OpenJDK > > 8 security updates will be available for the various platforms that > > OpenJDK supports? > > AdoptOpenJDK can provide binaries for as long as they want to: it > doesn't affect the jdk8u project. June 2023 is right for JDK 8, but I > wouldn't be surprised if it goes on beyond that. > To add to Andrew's statement. Adopt *only* produces binaries and will keep building 8u and 11u as long as it's being maintained (I need to update our official support page on this). > - AdoptOpenJDK will provide builds of that Java 11 upgraded version, > > so that upgraded OpenJDK Java 11 build will be available for public > > consumption. > > I don't know what AdoptOpenJDK would do with their builds, but I > presume so. > Yes we will. > > - The jdk8u project WILL backport that to the OpenJDK Java 8 build. > > If applicable, yes. > > > - AdoptOpenJDK will provide builds of that Java 8 upgraded version, > > so that upgraded OpenJDK Java 8 build will be available for public > > consumption. > Let's talk about binaries. If you're using any kind of a Linux/GNU > system you'll want to use your distro's packages and update manager, > so we don't need to talk about Linux. > > Binary downloads, are, therefore only really relevant to Windows and > (perhaps) Macintosh. I want the future updates project(s) to produce > official Windows binaries (perhaps built and tested jointly with > AdoptOpenJDK, but we haven't decided) and I'd like to see Macintosh > binaries too. > Adopt will build them yes (and as Andrew says, hopefully in close collaboration with the updates project(s) maintainers). We also build for a host of other platforms (AIX, zLinux, s390 Linux, PPC, PPCLE, aarch32 and aarch64, win32 and zos). Cheers, Martijn From mark.reinhold at oracle.com Fri Sep 7 17:35:22 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 07 Sep 2018 10:35:22 -0700 Subject: JEP proposed to target JDK 12: 326: Raw String Literals (Preview) In-Reply-To: <20180830154917.372576318@eggemoggin.niobe.net> References: <20180830154917.372576318@eggemoggin.niobe.net> Message-ID: <20180907103522.224925366@eggemoggin.niobe.net> 2018/8/30 15:49:17 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 12: > > 326: Raw String Literals (Preview) > http://openjdk.java.net/jeps/326 > > Feedback on this proposal is more than welcome, as are reasoned > objections. If no such objections are raised by 23:00 UTC on Thursday, > 6 September, or if they?re raised and then satisfactorily answered, > then per the JEP 2.0 process proposal [1] I?ll target this JEP to > JDK 12. There was one message in reaction to this proposal, but it was merely an expression of preferences without justification rather than a reasoned objection to the proposal as it stands. As such, I don?t think that it requires a response. Hearing no actual reasoned objections from Committers or Reviewers, I?ve targeted this JEP to JDK 12. - Mark From mark.reinhold at oracle.com Fri Sep 7 17:52:45 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 7 Sep 2018 10:52:45 -0700 (PDT) Subject: New candidate JEP: 342: Limit Speculative Execution Message-ID: <20180907175245.38546208F78@eggemoggin.niobe.net> http://openjdk.java.net/jeps/342 - Mark From martinrb at google.com Mon Sep 10 04:47:07 2018 From: martinrb at google.com (Martin Buchholz) Date: Sun, 9 Sep 2018 21:47:07 -0700 Subject: Reviving JEP 230: Microbenchmark Suite In-Reply-To: References: <8bbe2cf1-47ba-76a2-40d0-74569f81e060@redhat.com> Message-ID: I am in agreement with most of what Claes says. My personal experience is maintaining the benchmarks in test/jdk/java/util/Collection. They are hacky home-brew microbenchmarks, but they get the job done. They double as actual correctness tests, which have found at least one bug not found by any other test. I have never joined the jmh world, waiting for jmh to become available for the jdk repo. Colocation is a huge social advantage - I'd like the work to be done by the developer to be the same as when writing a test - simply creating the file in the right directory as part of the same changeset is enough. I'd like benchmarking to be as similar as possible to testing - so much so that benchmarking should perhaps be a special mode supported by jtreg, as e.g. junit is today. The existence of jmh-jdk-microbenchmarks as a separate repo is a barrier. I would hope that jmh's API should be stable by now, so that tests should rarely need porting to new versions of jmh. Version skew between jdks and microbenchmarks is a problem, but no different from jtreg tests. In both cases you are likely to be using some new API just added to the jdk (in the same changeset!). Designing a good benchmark framework is very hard, especially when the target is adoption by ordinary programmers. From mikael.vidstedt at oracle.com Mon Sep 10 17:11:09 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 10 Sep 2018 10:11:09 -0700 Subject: Reviving JEP 230: Microbenchmark Suite In-Reply-To: References: Message-ID: <0BED273C-06DD-425A-BD3D-B819E4EEF622@oracle.com> I would very much like to see this move forward. With more of the development happening in project sandboxes the challenge mentioned of keeping benchmarks for new or changed APIs in sync with the sandboxes will only get worse. Co-locating the benchmarks does have some cons as Aleksey mentions, though other co-location exercise not entirely unlike the proposed one have in my experience always turned out positive. I do think we?ll find that the fact that the benchmarks are trivially *there* (no extra cloning etc. needed) will mean that more people actually run them, and more people will develop new ones. Cheers, Mikael > On Sep 6, 2018, at 8:16 AM, Claes Redestad wrote: > > 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, and I'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. This situation 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 martinrb at google.com Mon Sep 10 19:08:35 2018 From: martinrb at google.com (Martin Buchholz) Date: Mon, 10 Sep 2018 12:08:35 -0700 Subject: Reviving JEP 230: Microbenchmark Suite In-Reply-To: <0BED273C-06DD-425A-BD3D-B819E4EEF622@oracle.com> References: <0BED273C-06DD-425A-BD3D-B819E4EEF622@oracle.com> Message-ID: Yes. The "social" aspects - easy to use, easy to share - of a benchmarking suite are the most important. From naoto.sato at oracle.com Wed Sep 12 16:23:20 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 12 Sep 2018 09:23:20 -0700 Subject: Result: New JDK Committer: Leo Jiang Message-ID: <8c936850-3cd7-8854-4a33-bc4984bcbe34@oracle.com> Voting for Leo Jiang [1] is now closed. Yes: 11 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Naoto Sato [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-August/001883.html From yumin.qi at gmail.com Thu Sep 13 15:47:55 2018 From: yumin.qi at gmail.com (yumin qi) Date: Thu, 13 Sep 2018 08:47:55 -0700 Subject: cr.openjdk.java.net is down? Message-ID: Anybody notice that the server cannot be accessed from outside? Thanks Yumin From mark.reinhold at oracle.com Thu Sep 13 15:49:41 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 13 Sep 2018 08:49:41 -0700 Subject: cr.openjdk.java.net is down? In-Reply-To: References: Message-ID: <20180913084941.705449070@eggemoggin.niobe.net> 2018/9/13 8:47:55 -0700, yumin.qi at gmail.com: > Anybody notice that the server cannot be accessed from outside? Yes. This outage affects openjdk.java.net, {cr,hg,mail}.openjdk.java.net, and jdk.java.net We?re working to fix the problem as quickly as possible. - Mark From mark.reinhold at oracle.com Thu Sep 13 22:41:02 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 13 Sep 2018 15:41:02 -0700 (PDT) Subject: Proposed schedule for JDK 12 Message-ID: <20180913224102.673F82097A3@eggemoggin.niobe.net> With JDK 11 nearly out the door, here's a proposed schedule for JDK 12: 2018/12/13 Rampdown Phase One 2019/01/17 Rampdown Phase Two 2019/01/31 Release-Candidate Phase 2019/03/19 General Availability The phases are defined in JEP 3 [1]. Comments on this proposal from JDK Committers and Reviewers [2] are welcome, as are reasoned objections. If no such objections are raised by 23:00 UTC next Thursday, 20 September, or if they're raised and then satisfactorily answered, then per the JEP 2.0 process proposal [3] this will be the schedule for JDK 12. - Mark [1] http://openjdk.java.net/jeps/3 [2] http://openjdk.java.net/census#jdk [3] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From philip.race at oracle.com Thu Sep 13 23:01:19 2018 From: philip.race at oracle.com (Philip Race) Date: Thu, 13 Sep 2018 16:01:19 -0700 Subject: Proposed schedule for JDK 12 In-Reply-To: <20180913224102.673F82097A3@eggemoggin.niobe.net> References: <20180913224102.673F82097A3@eggemoggin.niobe.net> Message-ID: <5B9AEC3F.3080701@oracle.com> On 9/13/18, 3:41 PM, mark.reinhold at oracle.com wrote: > With JDK 11 nearly out the door, here's a proposed schedule for JDK 12: > > 2018/12/13 Rampdown Phase One I don't know the day counting algorithm, but why not 12/20 or thereabouts ? .. 12/13 seems to reducing the amount of time to get features in by a week relative to RDP 2 + GA -phil. > 2019/01/17 Rampdown Phase Two > 2019/01/31 Release-Candidate Phase > 2019/03/19 General Availability > > The phases are defined in JEP 3 [1]. > > Comments on this proposal from JDK Committers and Reviewers [2] are > welcome, as are reasoned objections. If no such objections are raised > by 23:00 UTC next Thursday, 20 September, or if they're raised and then > satisfactorily answered, then per the JEP 2.0 process proposal [3] this > will be the schedule for JDK 12. > > - Mark > > > [1] http://openjdk.java.net/jeps/3 > [2] http://openjdk.java.net/census#jdk > [3] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From joe.darcy at oracle.com Sat Sep 15 14:48:13 2018 From: joe.darcy at oracle.com (joe darcy) Date: Sat, 15 Sep 2018 07:48:13 -0700 Subject: FYI, skara-dev list now available Message-ID: <90b74db5-b710-b60c-b3e8-cf7d6684e7d6@oracle.com> Hello, Those interested in participating in discussions around SCM alternatives for the JDK can now subscribe to the skara-dev list: ??? http://mail.openjdk.java.net/mailman/listinfo/skara-dev Cheers, -Joe From zhaixiang at loongson.cn Mon Sep 17 07:52:18 2018 From: zhaixiang at loongson.cn (Leslie Zhai) Date: Mon, 17 Sep 2018 15:52:18 +0800 Subject: OpenJDK 12-dev fastdebug for X86: Native memory allocation (malloc) failed to allocate 3276800 bytes for CodeCache: no room for Interpreter Message-ID: <73bee3be-b4d4-0ba4-f202-0a182dda4a90@loongson.cn> Hi Erik, I want to verify JDK-8199417 with OpenJDK 12-dev fastdebug for X86: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-September/007839.html $ hg log | head changeset:?? 51761:5f868838bc5f tag:???????? tip user:??????? weijun date:??????? Mon Sep 17 14:52:44 2018 +0800 summary:???? 8210736: jdk/javax/xml/crypto/dsig/GenerationTests.java slow on linux $ ./configure --with-debug-level=fastdebug --with-boot-jdk=/home/xiangzhai/jdk-10.0.2 --disable-warnings-as-errors Then *deliberately* changed `InterpreterCodeSize` too big, for example 800K: diff -r 5f868838bc5f src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp --- a/src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp Mon Sep 17 14:52:44 2018 +0800 +++ b/src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp Mon Sep 17 15:43:09 2018 +0800 @@ -57,8 +57,12 @@ ?// Run with +PrintInterpreter to get the VM to print out the size. ?// Max size with JVMTI ?#ifdef AMD64 +#ifdef PRODUCT ?int TemplateInterpreter::InterpreterCodeSize = JVMCI_ONLY(268) NOT_JVMCI(256) * 1024; ?#else +int TemplateInterpreter::InterpreterCodeSize = 800 * 1024; +#endif +#else ?int TemplateInterpreter::InterpreterCodeSize = 224 * 1024; ?#endif // AMD64 $ make CONF=fastdebug images $ jtreg -vmoptions:"-XX:+UnlockDiagnosticVMOptions -XX:+PrintInterpreter" -dir:/home/xiangzhai/jdk/test/hotspot/jtreg -verbose:all -a -ignore:quiet -timeoutFactor:5 -agentvm -testjdk:/home/xiangzhai/jdk/build/linux-x86_64-normal-server-fastdebug/jdk compiler/startup/SmallCodeCacheStartup.java STDOUT: Command line: [/home/xiangzhai/jdk/build/linux-x86_64-normal-server-fastdebug/jdk/bin/java -cp /home/xiangzhai/JTwork/classes/compiler/startup/SmallCodeCacheStartup.d:/home/xiangzhai/jdk/test/hotspot/jtreg/compiler/startup:/home/xiangzhai/JTwork/classes/test/lib:/home/xiangzhai/jtreg/lib/javatest.jar:/home/xiangzhai/jtreg/lib/jtreg.jar -XX:ReservedCodeCacheSize=3m -XX:CICompilerCount=64 -Xcomp -version ] STDERR: ?stdout: [[0.014s][warning][codecache] CodeCache is full. Compiler has been disabled. [0.015s][warning][codecache] Try increasing the code cache size using -XX:ReservedCodeCacheSize= CodeCache: size=3072Kb used=32Kb max_used=33Kb free=3039Kb ?bounds [0x00007f99c2e6f000, 0x00007f99c316f000, 0x00007f99c316f000] ?total_blobs=7 nmethods=0 adapters=0 ?compilation: disabled (not enough contiguous free space left) ????????????? stopped_count=1, restarted_count=0 ?full_count=0 # # There is insufficient memory for the Java Runtime Environment to continue. # Native memory allocation (malloc) failed to allocate 3276800 bytes for CodeCache: no room for Interpreter ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --- So there is the upper limit value for `InterpreterCodeSize`?? Is it able to workaround MIN(quadrupled, MAX_VALUE) for debug builds in order to accommodate for the additional debugging code? Please give me some suggestions, thanks a lot! Thanks, Leslie Zhai From erik.osterlund at oracle.com Mon Sep 17 09:19:03 2018 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 17 Sep 2018 11:19:03 +0200 Subject: OpenJDK 12-dev fastdebug for X86: Native memory allocation (malloc) failed to allocate 3276800 bytes for CodeCache: no room for Interpreter In-Reply-To: <73bee3be-b4d4-0ba4-f202-0a182dda4a90@loongson.cn> References: <73bee3be-b4d4-0ba4-f202-0a182dda4a90@loongson.cn> Message-ID: <5B9F7187.5000200@oracle.com> Hi Leslie, InterpreterCodeSize is a VM-private variable. I recommend not changing it unless you added lots of interpreter code that causes you to run into the assert suggesting you need more memory, in at least one configuration. This value needs to be at least large enough to fit the interpreter in all supported configurations, and then yet a bit longer for headroom so we don't have to update it every time somebody makes a change to the interpreter interpreter code. Obviously, if you set the value too high, you will exhaust your code cache, unless you add memory to the -XX:ReservedCodeCacheSize to accommodate for that. The particular test you are running is running with a very small code cache size, so it does not come as a surprise that you exhaust it by making the interpreter code reservation very large. I would suggest sending follow-up questions regarding the interpreter to hotspot-runtime-dev, and not jdk-dev to reduce noise on this list. Hope this explanation helps. /Erik On 2018-09-17 09:52, Leslie Zhai wrote: > Hi Erik, > > I want to verify JDK-8199417 with OpenJDK 12-dev fastdebug for X86: > > http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-September/007839.html > > > $ hg log | head > > changeset: 51761:5f868838bc5f > tag: tip > user: weijun > date: Mon Sep 17 14:52:44 2018 +0800 > summary: 8210736: jdk/javax/xml/crypto/dsig/GenerationTests.java > slow on linux > > $ ./configure --with-debug-level=fastdebug > --with-boot-jdk=/home/xiangzhai/jdk-10.0.2 --disable-warnings-as-errors > > Then *deliberately* changed `InterpreterCodeSize` too big, for example > 800K: > > diff -r 5f868838bc5f > src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp > --- a/src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp Mon Sep > 17 14:52:44 2018 +0800 > +++ b/src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp Mon Sep > 17 15:43:09 2018 +0800 > @@ -57,8 +57,12 @@ > // Run with +PrintInterpreter to get the VM to print out the size. > // Max size with JVMTI > #ifdef AMD64 > +#ifdef PRODUCT > int TemplateInterpreter::InterpreterCodeSize = JVMCI_ONLY(268) > NOT_JVMCI(256) * 1024; > #else > +int TemplateInterpreter::InterpreterCodeSize = 800 * 1024; > +#endif > +#else > int TemplateInterpreter::InterpreterCodeSize = 224 * 1024; > #endif // AMD64 > > > $ make CONF=fastdebug images > > $ jtreg -vmoptions:"-XX:+UnlockDiagnosticVMOptions > -XX:+PrintInterpreter" -dir:/home/xiangzhai/jdk/test/hotspot/jtreg > -verbose:all -a -ignore:quiet -timeoutFactor:5 -agentvm > -testjdk:/home/xiangzhai/jdk/build/linux-x86_64-normal-server-fastdebug/jdk > compiler/startup/SmallCodeCacheStartup.java > > STDOUT: > Command line: > [/home/xiangzhai/jdk/build/linux-x86_64-normal-server-fastdebug/jdk/bin/java > -cp > /home/xiangzhai/JTwork/classes/compiler/startup/SmallCodeCacheStartup.d:/home/xiangzhai/jdk/test/hotspot/jtreg/compiler/startup:/home/xiangzhai/JTwork/classes/test/lib:/home/xiangzhai/jtreg/lib/javatest.jar:/home/xiangzhai/jtreg/lib/jtreg.jar > -XX:ReservedCodeCacheSize=3m -XX:CICompilerCount=64 -Xcomp -version ] > STDERR: > stdout: [[0.014s][warning][codecache] CodeCache is full. Compiler has > been disabled. > [0.015s][warning][codecache] Try increasing the code cache size using > -XX:ReservedCodeCacheSize= > CodeCache: size=3072Kb used=32Kb max_used=33Kb free=3039Kb > bounds [0x00007f99c2e6f000, 0x00007f99c316f000, 0x00007f99c316f000] > total_blobs=7 nmethods=0 adapters=0 > compilation: disabled (not enough contiguous free space left) > stopped_count=1, restarted_count=0 > full_count=0 > # > # There is insufficient memory for the Java Runtime Environment to > continue. > # Native memory allocation (malloc) failed to allocate 3276800 bytes > for CodeCache: no room for Interpreter > > ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --- > > So there is the upper limit value for `InterpreterCodeSize`? Is it > able to workaround MIN(quadrupled, MAX_VALUE) for debug builds in > order to accommodate for the additional debugging code? > > Please give me some suggestions, thanks a lot! > > Thanks, > > Leslie Zhai > > From vladimir.kozlov at oracle.com Tue Sep 18 15:53:34 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 18 Sep 2018 08:53:34 -0700 Subject: Result: New JDK Committer: Gilles Duboscq Message-ID: <5af67146-91d7-5b5d-bad5-4fc42561b7c9@oracle.com> Voting for Gilles Duboscq [1] is now closed. Yes: 14 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Thanks, Vladimir Kozlov [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-August/001848.html From jesper.wilhelmsson at oracle.com Thu Sep 20 00:04:11 2018 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Thu, 20 Sep 2018 02:04:11 +0200 Subject: Introducing time wasters Message-ID: Hi, As an experiment we are introducing a new label in JBS, timewaster. The label is used to tag bugs that for some reason is wasting engineering time. This could for instance be a bug that occurs frequently in our testing and causes many engineers to investigate the failure in different test runs just to realize it's the same issue as have been seen before, or worse, don't realize it is a known issue and files a duplicate bug in JBS. Bugs that cause tests to fail without a proper explanation may also be considered time wasters since several engineers risk to investigate the failures just to realize there is no information to be found. There are other cases as well and there is some flexibility in the definition. If you see an issue that have been wasting your time, feel free to add an explanation to why you think it's a time waster and add the label. The fact that a bug is wasting engineering time should be taken into account when a bug is triaged. A time waster has higher urgency than other bugs. This is not really reflected in the priority of a bug so the priority is not necessarily changed due to the higher urgency. When triaging a time waster, or when adding the label after a bug already has been triaged, it's recommended to notify the developers that work on the affected component, e.g. by sending an email to the proper mailing list and make sure the bug is assigned to someone. If you have a time waster assigned to you, please consider fixing it asap. If you chose to not work on the issue, you should at least be aware that you are choosing to waste more engineering time and others will be affected by this choice. To see currently open time wasters use the JBS filter Time wasters: https://bugs.openjdk.java.net/issues/?filter=35335 Thanks, /Jesper From philip.race at oracle.com Thu Sep 20 04:39:41 2018 From: philip.race at oracle.com (Philip Race) Date: Wed, 19 Sep 2018 21:39:41 -0700 Subject: Introducing time wasters In-Reply-To: References: Message-ID: <5BA3248D.6000107@oracle.com> Who is 'we' ? Where was this discussed, proposed, and adopted ? -phil. On 9/19/18, 5:04 PM, jesper.wilhelmsson at oracle.com wrote: > Hi, > > As an experiment we are introducing a new label in JBS, timewaster. The label is used to tag bugs that for some reason is wasting engineering time. This could for instance be a bug that occurs frequently in our testing and causes many engineers to investigate the failure in different test runs just to realize it's the same issue as have been seen before, or worse, don't realize it is a known issue and files a duplicate bug in JBS. Bugs that cause tests to fail without a proper explanation may also be considered time wasters since several engineers risk to investigate the failures just to realize there is no information to be found. There are other cases as well and there is some flexibility in the definition. If you see an issue that have been wasting your time, feel free to add an explanation to why you think it's a time waster and add the label. > > The fact that a bug is wasting engineering time should be taken into account when a bug is triaged. A time waster has higher urgency than other bugs. This is not really reflected in the priority of a bug so the priority is not necessarily changed due to the higher urgency. When triaging a time waster, or when adding the label after a bug already has been triaged, it's recommended to notify the developers that work on the affected component, e.g. by sending an email to the proper mailing list and make sure the bug is assigned to someone. > > If you have a time waster assigned to you, please consider fixing it asap. If you chose to not work on the issue, you should at least be aware that you are choosing to waste more engineering time and others will be affected by this choice. > > To see currently open time wasters use the JBS filter Time wasters: https://bugs.openjdk.java.net/issues/?filter=35335 > > Thanks, > /Jesper > From sean.mullan at oracle.com Thu Sep 20 12:09:39 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 20 Sep 2018 08:09:39 -0400 Subject: Introducing time wasters In-Reply-To: <5BA3248D.6000107@oracle.com> References: <5BA3248D.6000107@oracle.com> Message-ID: I read it as a joke. I did double-check the calendar and it's not April 1 yet. --Sean On 9/20/18 12:39 AM, Philip Race wrote: > Who is 'we' ? > > Where was this discussed, proposed, and adopted ? > > -phil. > > On 9/19/18, 5:04 PM, jesper.wilhelmsson at oracle.com wrote: >> Hi, >> >> As an experiment we are introducing a new label in JBS, timewaster. >> The label is used to tag bugs that for some reason is wasting >> engineering time. This could for instance be a bug that occurs >> frequently in our testing and causes many engineers to investigate the >> failure in different test runs just to realize it's the same issue as >> have been seen before, or worse, don't realize it is a known issue and >> files a duplicate bug in JBS. Bugs that cause tests to fail without a >> proper explanation may also be considered time wasters since several >> engineers risk to investigate the failures just to realize there is no >> information to be found. There are other cases as well and there is >> some flexibility in the definition. If you see an issue that have been >> wasting your time, feel free to add an explanation to why you think >> it's a time waster and add the label. >> >> The fact that a bug is wasting engineering time should be taken into >> account when a bug is triaged. A time waster has higher urgency than >> other bugs. This is not really reflected in the priority of a bug so >> the priority is not necessarily changed due to the higher urgency. >> When triaging a time waster, or when adding the label after a bug >> already has been triaged, it's recommended to notify the developers >> that work on the affected component, e.g. by sending an email to the >> proper mailing list and make sure the bug is assigned to someone. >> >> If you have a time waster assigned to you, please consider fixing it >> asap. If you chose to not work on the issue, you should at least be >> aware that you are choosing to waste more engineering time and others >> will be affected by this choice. >> >> To see currently open time wasters use the JBS filter Time wasters: >> https://bugs.openjdk.java.net/issues/?filter=35335 >> >> Thanks, >> /Jesper >> From fweimer at redhat.com Thu Sep 20 12:15:02 2018 From: fweimer at redhat.com (Florian Weimer) Date: Thu, 20 Sep 2018 14:15:02 +0200 Subject: Introducing time wasters In-Reply-To: (Sean Mullan's message of "Thu, 20 Sep 2018 08:09:39 -0400") References: <5BA3248D.6000107@oracle.com> Message-ID: <87fty4fjqx.fsf@oldenburg.str.redhat.com> * Sean Mullan: > I read it as a joke. I did double-check the calendar and it's not > April 1 yet. Is it a joke? Avoiding wasting developer and QE time for manually checking logs is the main reason why we fix and backport obscure test suite failures. We are usually constrained by QE resources for backports, but I think we now have a mindset that the QE cost for such fixes is actually negative: Sure, there is another bug to validate, but it will pay off pretty quickly because you don't have to worry about the failing test ever again. Thanks, Florian From sean.mullan at oracle.com Thu Sep 20 12:18:28 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 20 Sep 2018 08:18:28 -0400 Subject: Introducing time wasters In-Reply-To: <87fty4fjqx.fsf@oldenburg.str.redhat.com> References: <5BA3248D.6000107@oracle.com> <87fty4fjqx.fsf@oldenburg.str.redhat.com> Message-ID: <0f050bb8-3675-bab7-6290-528640440382@oracle.com> On 9/20/18 8:15 AM, Florian Weimer wrote: > * Sean Mullan: > >> I read it as a joke. I did double-check the calendar and it's not >> April 1 yet. > > Is it a joke? I have no idea but it was specifically this part that led me to believe it may be a joke: > If you have a time waster assigned to you, please consider fixing it asap. If you chose to not work on the issue, you should at least be aware that you are choosing to waste more engineering time and others will be affected by this choice. --Sean > > Avoiding wasting developer and QE time for manually checking logs is the > main reason why we fix and backport obscure test suite failures. We are > usually constrained by QE resources for backports, but I think we now > have a mindset that the QE cost for such fixes is actually negative: > Sure, there is another bug to validate, but it will pay off pretty > quickly because you don't have to worry about the failing test ever > again. > > Thanks, > Florian > From neugens.limasoftware at gmail.com Thu Sep 20 12:22:58 2018 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Thu, 20 Sep 2018 14:22:58 +0200 Subject: Introducing time wasters In-Reply-To: <0f050bb8-3675-bab7-6290-528640440382@oracle.com> References: <5BA3248D.6000107@oracle.com> <87fty4fjqx.fsf@oldenburg.str.redhat.com> <0f050bb8-3675-bab7-6290-528640440382@oracle.com> Message-ID: Doesn't seem a joke, since the label is there. I can understand the frustration of having such bugs, but I wonder if it shouldn't be just the priority of the bug raised rather than a new label? Additionally, I take it the only benefit is to indicate that a bug sucks engineering time of engineers not working on the bug but affected by it. I wonder if the problem then is that engineers that find the bug don't fix it ;) at least, that's what I would do. Cheers, Mario Il giorno gio 20 set 2018 alle ore 14:18 Sean Mullan ha scritto: > > On 9/20/18 8:15 AM, Florian Weimer wrote: > > * Sean Mullan: > > > >> I read it as a joke. I did double-check the calendar and it's not > >> April 1 yet. > > > > Is it a joke? > > I have no idea but it was specifically this part that led me to believe > it may be a joke: > > > If you have a time waster assigned to you, please consider fixing it > asap. If you chose to not work on the issue, you should at least be > aware that you are choosing to waste more engineering time and others > will be affected by this choice. > > --Sean > > > > > Avoiding wasting developer and QE time for manually checking logs is the > > main reason why we fix and backport obscure test suite failures. We are > > usually constrained by QE resources for backports, but I think we now > > have a mindset that the QE cost for such fixes is actually negative: > > Sure, there is another bug to validate, but it will pay off pretty > > quickly because you don't have to worry about the failing test ever > > again. > > > > Thanks, > > Florian > > -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From roman at kennke.org Thu Sep 20 12:25:51 2018 From: roman at kennke.org (Roman Kennke) Date: Thu, 20 Sep 2018 14:25:51 +0200 Subject: Introducing time wasters In-Reply-To: References: <5BA3248D.6000107@oracle.com> Message-ID: > I read it as a joke. I did double-check the calendar and it's not April > 1 yet. +1 This, or I'm a bit irritated. I'd rather use tags and information based on technical merits, and not on subjective experience of somebody. It's a matter of attitude whether you view a bug as 'waste of time' or as something that you work your way through it. It's a matter of communication. What sends a better message? - Tagging a bug with 'timewaster' - Asking politely for more information? To me, 'timewaster' tag sends a message 'my time is somehow more valueable than yours'. It would really piss me off if I'd file a bug, and then, for some reason, somebody would tag it 'timewaster'. Yeah, not everybody is perfect, not everybody does file bugs as we want them (check for dupes, attach all possible logs, etc etc), but that is part of life, isn't it? If somebody files a bug, there's probably a good reason for it, and our task is to take it seriously. At least, that's how I see it. I don't think we should do that in an open source project. It's just not how I want to work. There's got to be more sensible ways to communicate. Roman > --Sean > > On 9/20/18 12:39 AM, Philip Race wrote: >> Who is 'we' ? >> >> Where was this discussed, proposed, and adopted ? >> >> -phil. >> >> On 9/19/18, 5:04 PM, jesper.wilhelmsson at oracle.com wrote: >>> Hi, >>> >>> As an experiment we are introducing a new label in JBS, timewaster. >>> The label is used to tag bugs that for some reason is wasting >>> engineering time. This could for instance be a bug that occurs >>> frequently in our testing and causes many engineers to investigate >>> the failure in different test runs just to realize it's the same >>> issue as have been seen before, or worse, don't realize it is a known >>> issue and files a duplicate bug in JBS. Bugs that cause tests to fail >>> without a proper explanation may also be considered time wasters >>> since several engineers risk to investigate the failures just to >>> realize there is no information to be found. There are other cases as >>> well and there is some flexibility in the definition. If you see an >>> issue that have been wasting your time, feel free to add an >>> explanation to why you think it's a time waster and add the label. >>> >>> The fact that a bug is wasting engineering time should be taken into >>> account when a bug is triaged. A time waster has higher urgency than >>> other bugs. This is not really reflected in the priority of a bug so >>> the priority is not necessarily changed due to the higher urgency. >>> When triaging a time waster, or when adding the label after a bug >>> already has been triaged, it's recommended to notify the developers >>> that work on the affected component, e.g. by sending an email to the >>> proper mailing list and make sure the bug is assigned to someone. >>> >>> If you have a time waster assigned to you, please consider fixing it >>> asap. If you chose to not work on the issue, you should at least be >>> aware that you are choosing to waste more engineering time and others >>> will be affected by this choice. >>> >>> To see currently open time wasters use the JBS filter Time wasters: >>> https://bugs.openjdk.java.net/issues/?filter=35335 >>> >>> Thanks, >>> /Jesper >>> > From neugens.limasoftware at gmail.com Thu Sep 20 12:33:17 2018 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Thu, 20 Sep 2018 14:33:17 +0200 Subject: Introducing time wasters In-Reply-To: References: <5BA3248D.6000107@oracle.com> Message-ID: Il giorno gio 20 set 2018 alle ore 14:26 Roman Kennke ha scritto: > > > > I read it as a joke. I did double-check the calendar and it's not April > > 1 yet. > > > +1 > > This, or I'm a bit irritated. > > I'd rather use tags and information based on technical merits, and not > on subjective experience of somebody. It's a matter of attitude whether > you view a bug as 'waste of time' or as something that you work your way > through it. It's a matter of communication. What sends a better message? > > - Tagging a bug with 'timewaster' > - Asking politely for more information? > > To me, 'timewaster' tag sends a message 'my time is somehow more > valueable than yours'. It would really piss me off if I'd file a bug, > and then, for some reason, somebody would tag it 'timewaster'. Yeah, not > everybody is perfect, not everybody does file bugs as we want them > (check for dupes, attach all possible logs, etc etc), but that is part > of life, isn't it? If somebody files a bug, there's probably a good > reason for it, and our task is to take it seriously. At least, that's > how I see it. > > I don't think we should do that in an open source project. It's just not > how I want to work. There's got to be more sensible ways to communicate. > > Roman Totally agree, Beside, isn't every bug a time waster anyway by definition? I mean, it definitely wastes somebody's time, the reporter couldn't do some work because of it and the engineer working on it can't do other more interesting things. Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From volker.simonis at gmail.com Thu Sep 20 14:17:00 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 20 Sep 2018 16:17:00 +0200 Subject: Introducing time wasters In-Reply-To: References: <5BA3248D.6000107@oracle.com> Message-ID: Hi Roman, maybe there's a little misunderstanding here? As I understand it, If you open a bug and I flag it as "timewaster", that doesn't mean that I think fixing that bug would be a waste of time nor does it mean that I pretend my time is more valuable than yours. It only means that I lost a lot of time searching for a similar problem and in the end I detected that you already found it and there's already a bug for it. In some sense the flag can be seen as a frequency counter for how often a problem occurs. Let's face it - there are still plenty of bugs in the OpenJDK. And I think it is reasonable to open a JBS issue every time we detect a bug (e.g. every time the HotSpot crashes with an hs_err file) even if we can't fix it right away. If such bugs only occur once in a decade, it may be reasonable to not fix them with a high priority. But if several developers have invested some efforts in diagnosing them, it may be useful to somehow flag that. Also, some issues may only occur in the debug version (e.g. assertions) and of course such issues will have lower priority than issues in the product version. But still they can lead to failed test runs which require manual and time consuming analysis. Both these examples are candidates for the 'timewaster' tag, because they have the potential to consume a lot of developer time without really impacting customers. So for me this tag can be useful if used in a responsible way. Regards, Volker On Thu, Sep 20, 2018 at 2:26 PM Roman Kennke wrote: > > > > I read it as a joke. I did double-check the calendar and it's not April > > 1 yet. > > > +1 > > This, or I'm a bit irritated. > > I'd rather use tags and information based on technical merits, and not > on subjective experience of somebody. It's a matter of attitude whether > you view a bug as 'waste of time' or as something that you work your way > through it. It's a matter of communication. What sends a better message? > > - Tagging a bug with 'timewaster' > - Asking politely for more information? > > To me, 'timewaster' tag sends a message 'my time is somehow more > valueable than yours'. It would really piss me off if I'd file a bug, > and then, for some reason, somebody would tag it 'timewaster'. Yeah, not > everybody is perfect, not everybody does file bugs as we want them > (check for dupes, attach all possible logs, etc etc), but that is part > of life, isn't it? If somebody files a bug, there's probably a good > reason for it, and our task is to take it seriously. At least, that's > how I see it. > > I don't think we should do that in an open source project. It's just not > how I want to work. There's got to be more sensible ways to communicate. > > Roman > > > --Sean > > > > On 9/20/18 12:39 AM, Philip Race wrote: > >> Who is 'we' ? > >> > >> Where was this discussed, proposed, and adopted ? > >> > >> -phil. > >> > >> On 9/19/18, 5:04 PM, jesper.wilhelmsson at oracle.com wrote: > >>> Hi, > >>> > >>> As an experiment we are introducing a new label in JBS, timewaster. > >>> The label is used to tag bugs that for some reason is wasting > >>> engineering time. This could for instance be a bug that occurs > >>> frequently in our testing and causes many engineers to investigate > >>> the failure in different test runs just to realize it's the same > >>> issue as have been seen before, or worse, don't realize it is a known > >>> issue and files a duplicate bug in JBS. Bugs that cause tests to fail > >>> without a proper explanation may also be considered time wasters > >>> since several engineers risk to investigate the failures just to > >>> realize there is no information to be found. There are other cases as > >>> well and there is some flexibility in the definition. If you see an > >>> issue that have been wasting your time, feel free to add an > >>> explanation to why you think it's a time waster and add the label. > >>> > >>> The fact that a bug is wasting engineering time should be taken into > >>> account when a bug is triaged. A time waster has higher urgency than > >>> other bugs. This is not really reflected in the priority of a bug so > >>> the priority is not necessarily changed due to the higher urgency. > >>> When triaging a time waster, or when adding the label after a bug > >>> already has been triaged, it's recommended to notify the developers > >>> that work on the affected component, e.g. by sending an email to the > >>> proper mailing list and make sure the bug is assigned to someone. > >>> > >>> If you have a time waster assigned to you, please consider fixing it > >>> asap. If you chose to not work on the issue, you should at least be > >>> aware that you are choosing to waste more engineering time and others > >>> will be affected by this choice. > >>> > >>> To see currently open time wasters use the JBS filter Time wasters: > >>> https://bugs.openjdk.java.net/issues/?filter=35335 > >>> > >>> Thanks, > >>> /Jesper > >>> > > > > From adinn at redhat.com Thu Sep 20 14:34:06 2018 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 20 Sep 2018 15:34:06 +0100 Subject: Introducing time wasters In-Reply-To: References: <5BA3248D.6000107@oracle.com> Message-ID: <74f63b69-3dac-453a-2c80-b297d678a25d@redhat.com> Hi Volker/Roman, On 20/09/18 15:17, Volker Simonis wrote: > maybe there's a little misunderstanding here? As I understand it, If > you open a bug and I flag it as "timewaster", that doesn't mean that I > think fixing that bug would be a waste of time nor does it mean that I > pretend my time is more valuable than yours. It only means that I lost > a lot of time searching for a similar problem and in the end I > detected that you already found it and there's already a bug for it. > In some sense the flag can be seen as a frequency counter for how > often a problem occurs. Well, I almost posted this this morning ... so here goes. I think there is a not-so-little misunderstanding here that we need to avoid. The point of this tag is to emphasise that the bug is costly in developer time while it remains present i.e. that it is a priority to fix this. That's precisely the opposite of what the tag will suggest to many native English speakers (and some non-native ones, too,it seems) who will read it as saying "this bug is not worth fixing and ought to be ignored -- probably because it was raised by someone who has nary a clue as to what is involved" I'm quite sure this is going to be a regular stumbling block if we don't change the name. So, perhaps we could use a tag which says more explicitly what was intended e.g. "development-slowdown", "dev-brake" or something along those lines? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From aleksei.voitylov at bell-sw.com Thu Sep 20 14:37:36 2018 From: aleksei.voitylov at bell-sw.com (aleksei.voitylov at bell-sw.com) Date: Thu, 20 Sep 2018 17:37:36 +0300 Subject: Introducing time wasters In-Reply-To: <74f63b69-3dac-453a-2c80-b297d678a25d@redhat.com> References: <5BA3248D.6000107@oracle.com> <74f63b69-3dac-453a-2c80-b297d678a25d@redhat.com> Message-ID: <165f76a2f80.2786.de43121e48c2b7fef2896cfce71f7232@bell-sw.com> +1. How about dev-hard? Andrew Dinn 20 ???????? 2018 ?. 17:34:46 ???????: > Hi Volker/Roman, > > On 20/09/18 15:17, Volker Simonis wrote: >> maybe there's a little misunderstanding here? As I understand it, If >> you open a bug and I flag it as "timewaster", that doesn't mean that I >> think fixing that bug would be a waste of time nor does it mean that I >> pretend my time is more valuable than yours. It only means that I lost >> a lot of time searching for a similar problem and in the end I >> detected that you already found it and there's already a bug for it. >> In some sense the flag can be seen as a frequency counter for how >> often a problem occurs. > > Well, I almost posted this this morning ... so here goes. I think there > is a not-so-little misunderstanding here that we need to avoid. > > The point of this tag is to emphasise that the bug is costly in > developer time while it remains present i.e. that it is a priority to > fix this. > > That's precisely the opposite of what the tag will suggest to many > native English speakers (and some non-native ones, too,it seems) who > will read it as saying > > "this bug is not worth fixing and ought to be ignored -- probably > because it was raised by someone who has nary a clue as to what is involved" > > I'm quite sure this is going to be a regular stumbling block if we don't > change the name. > > So, perhaps we could use a tag which says more explicitly what was > intended e.g. "development-slowdown", "dev-brake" or something along > those lines? > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From shade at redhat.com Thu Sep 20 14:42:04 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 20 Sep 2018 16:42:04 +0200 Subject: Introducing time wasters In-Reply-To: <165f76a2f80.2786.de43121e48c2b7fef2896cfce71f7232@bell-sw.com> References: <5BA3248D.6000107@oracle.com> <74f63b69-3dac-453a-2c80-b297d678a25d@redhat.com> <165f76a2f80.2786.de43121e48c2b7fef2896cfce71f7232@bell-sw.com> Message-ID: <0745e52e-5a1f-70d2-3100-87ba48614c76@redhat.com> dev-hard implies "this requires hard development"? Probably, the variant of "critical-for-dev-experience" to turn the whole thing positive. -Aleksey On 09/20/2018 04:37 PM, aleksei.voitylov at bell-sw.com wrote: > +1. How about dev-hard? > > Andrew Dinn 20 ???????? 2018 ?. 17:34:46 ???????: >> >> So, perhaps we could use a tag which says more explicitly what was >> intended e.g. "development-slowdown", "dev-brake" or something along >> those lines? From aleksei.voitylov at bell-sw.com Thu Sep 20 14:54:17 2018 From: aleksei.voitylov at bell-sw.com (aleksei.voitylov at bell-sw.com) Date: Thu, 20 Sep 2018 17:54:17 +0300 Subject: Introducing time wasters In-Reply-To: <0745e52e-5a1f-70d2-3100-87ba48614c76@redhat.com> References: <5BA3248D.6000107@oracle.com> <74f63b69-3dac-453a-2c80-b297d678a25d@redhat.com> <165f76a2f80.2786.de43121e48c2b7fef2896cfce71f7232@bell-sw.com> <0745e52e-5a1f-70d2-3100-87ba48614c76@redhat.com> Message-ID: <165f77971c0.2786.de43121e48c2b7fef2896cfce71f7232@bell-sw.com> >From my exp long labels tend not to be used and no, JIRA suggestions do not help. I'll be happy to see a positive short label. Aleksey Shipilev 20 ???????? 2018 ?. 17:42:12 ???????: > dev-hard implies "this requires hard development"? > > Probably, the variant of "critical-for-dev-experience" to turn the whole > thing positive. > > -Aleksey > > On 09/20/2018 04:37 PM, aleksei.voitylov at bell-sw.com wrote: >> +1. How about dev-hard? >> >> Andrew Dinn 20 ???????? 2018 ?. 17:34:46 ???????: >>> >>> So, perhaps we could use a tag which says more explicitly what was >>> intended e.g. "development-slowdown", "dev-brake" or something along >>> those lines? From jesper.wilhelmsson at oracle.com Thu Sep 20 16:04:12 2018 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Thu, 20 Sep 2018 18:04:12 +0200 Subject: Introducing time wasters In-Reply-To: References: Message-ID: <4FCFBCDB-0773-4493-9FF4-266A51A49563@oracle.com> OK, I see that this didn't come out as I intended it. The name "timewaster" is clearly not the best since it can be interpreted as "this bug is a waste of time - it shouldn't have been filed" - That was NOT what I meant. My intention was to have a label to indicate that a bug is urgent to fix because a lot of developers is currently spending time chasing down the same issue over and over. It has been suggested to increase the priority instead of using a label. One of the reasons that it ended up as a label is that JBS don't have a way to express urgency. Priority and urgency are two different things and should not be mixed, so raising the priority would send the wrong signal. One example is a broken test in tier 1 that is failing at every run. This bug would cause work for every engineer who is running through our tests, be it through the submit forest or in internal test frameworks in our different organisations. Fixing it is clearly urgent. However, raising the priority would mean that it becomes a blocker for the release. A broken test should not block the release. So, back to the name. Since urgency is what we're after, can we call it "urgent"? As for the "discussed, proposed, and adopted" part - This is where it is proposed and discussed. (Thanks to everyone who engage in the discussion!) It hasn't been adopted yet, it is, as I wrote, an experiment. Thanks, /Jesper > On 20 Sep 2018, at 02:04, jesper.wilhelmsson at oracle.com wrote: > > Hi, > > As an experiment we are introducing a new label in JBS, timewaster. The label is used to tag bugs that for some reason is wasting engineering time. This could for instance be a bug that occurs frequently in our testing and causes many engineers to investigate the failure in different test runs just to realize it's the same issue as have been seen before, or worse, don't realize it is a known issue and files a duplicate bug in JBS. Bugs that cause tests to fail without a proper explanation may also be considered time wasters since several engineers risk to investigate the failures just to realize there is no information to be found. There are other cases as well and there is some flexibility in the definition. If you see an issue that have been wasting your time, feel free to add an explanation to why you think it's a time waster and add the label. > > The fact that a bug is wasting engineering time should be taken into account when a bug is triaged. A time waster has higher urgency than other bugs. This is not really reflected in the priority of a bug so the priority is not necessarily changed due to the higher urgency. When triaging a time waster, or when adding the label after a bug already has been triaged, it's recommended to notify the developers that work on the affected component, e.g. by sending an email to the proper mailing list and make sure the bug is assigned to someone. > > If you have a time waster assigned to you, please consider fixing it asap. If you chose to not work on the issue, you should at least be aware that you are choosing to waste more engineering time and others will be affected by this choice. > > To see currently open time wasters use the JBS filter Time wasters: https://bugs.openjdk.java.net/issues/?filter=35335 > > Thanks, > /Jesper > From gromero at linux.vnet.ibm.com Thu Sep 20 16:13:37 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Thu, 20 Sep 2018 13:13:37 -0300 Subject: Introducing time wasters In-Reply-To: <74f63b69-3dac-453a-2c80-b297d678a25d@redhat.com> References: <5BA3248D.6000107@oracle.com> <74f63b69-3dac-453a-2c80-b297d678a25d@redhat.com> Message-ID: Hi, On 09/20/2018 11:34 AM, Andrew Dinn wrote: > Hi Volker/Roman, > > On 20/09/18 15:17, Volker Simonis wrote: >> maybe there's a little misunderstanding here? As I understand it, If >> you open a bug and I flag it as "timewaster", that doesn't mean that I >> think fixing that bug would be a waste of time nor does it mean that I >> pretend my time is more valuable than yours. It only means that I lost >> a lot of time searching for a similar problem and in the end I >> detected that you already found it and there's already a bug for it. >> In some sense the flag can be seen as a frequency counter for how >> often a problem occurs. > > Well, I almost posted this this morning ... so here goes. I think there > is a not-so-little misunderstanding here that we need to avoid. > > The point of this tag is to emphasise that the bug is costly in > developer time while it remains present i.e. that it is a priority to > fix this. > > That's precisely the opposite of what the tag will suggest to many > native English speakers (and some non-native ones, too,it seems) who > will read it as saying > > "this bug is not worth fixing and ought to be ignored -- probably > because it was raised by someone who has nary a clue as to what is involved" > > I'm quite sure this is going to be a regular stumbling block if we don't > change the name. As a non-native English speaker I concur with Andrew's comment, i.e. the first time I read Jesper's description I've got a bit confused because in the end I was unsure if "timewaster" was meant for bugs important or no important in general. So by just looking at the name "timewaster" I tented to conclude that the bugs with that tag were not that important, because who would like to take something that wastes such a precious resource like time? :) Launchpad (from Canonical) has measure for bugs called "Bug heat" and in my understanding incorporates a measure as Volker said: a sort of frequency counter based on the number of affected users: " Bug heat Launchpad helps you to appraise a bug by giving you a calculated measure ? called bug heat ? of its likely significance. You can see bug heat in bug listings, and also on individual bug pages, as a number next to a flame icon. Here's how Launchpad calculates the bug heat score: Attribute Calculation Private Adds 150 points Security issues Adds 250 points Duplicates Adds 6 points per duplicate bug Affected users Adds 4 points per affected user <======= Subscribers (incl. subscribers to duplicates) Adds 2 points per subscriber " So I'm wondering if it would be better to implement it no like a discrete tag but instead as counter in fact, calling it something like "affected-devs", "affected-devs", or "dev-impact". I understand the urgency is already tracked by the priority numbers? Best regards, Gustavo > So, perhaps we could use a tag which says more explicitly what was > intended e.g. "development-slowdown", "dev-brake" or something along > those lines? > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From jonathan.gibbons at oracle.com Thu Sep 20 16:23:05 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 20 Sep 2018 09:23:05 -0700 Subject: Introducing time wasters In-Reply-To: <4FCFBCDB-0773-4493-9FF4-266A51A49563@oracle.com> References: <4FCFBCDB-0773-4493-9FF4-266A51A49563@oracle.com> Message-ID: <1ca63185-cb6a-bf8d-719b-16ebd234acd7@oracle.com> +1 for "urgent" or some similar short meaningful name, along with a guideline that there should be comments justifying the use of the label. Another reason for a label instead of priority is that it can be more focussed, and can be used in filters/gadgets/dashboards in JBS. -- Jon On 9/20/18 9:04 AM, jesper.wilhelmsson at oracle.com wrote: > OK, I see that this didn't come out as I intended it. The name "timewaster" is clearly not the best since it can be interpreted as "this bug is a waste of time - it shouldn't have been filed" - That was NOT what I meant. > > My intention was to have a label to indicate that a bug is urgent to fix because a lot of developers is currently spending time chasing down the same issue over and over. > > It has been suggested to increase the priority instead of using a label. One of the reasons that it ended up as a label is that JBS don't have a way to express urgency. Priority and urgency are two different things and should not be mixed, so raising the priority would send the wrong signal. One example is a broken test in tier 1 that is failing at every run. This bug would cause work for every engineer who is running through our tests, be it through the submit forest or in internal test frameworks in our different organisations. Fixing it is clearly urgent. However, raising the priority would mean that it becomes a blocker for the release. A broken test should not block the release. > > So, back to the name. Since urgency is what we're after, can we call it "urgent"? > > As for the "discussed, proposed, and adopted" part - This is where it is proposed and discussed. (Thanks to everyone who engage in the discussion!) > It hasn't been adopted yet, it is, as I wrote, an experiment. > > Thanks, > /Jesper > > >> On 20 Sep 2018, at 02:04, jesper.wilhelmsson at oracle.com wrote: >> >> Hi, >> >> As an experiment we are introducing a new label in JBS, timewaster. The label is used to tag bugs that for some reason is wasting engineering time. This could for instance be a bug that occurs frequently in our testing and causes many engineers to investigate the failure in different test runs just to realize it's the same issue as have been seen before, or worse, don't realize it is a known issue and files a duplicate bug in JBS. Bugs that cause tests to fail without a proper explanation may also be considered time wasters since several engineers risk to investigate the failures just to realize there is no information to be found. There are other cases as well and there is some flexibility in the definition. If you see an issue that have been wasting your time, feel free to add an explanation to why you think it's a time waster and add the label. >> >> The fact that a bug is wasting engineering time should be taken into account when a bug is triaged. A time waster has higher urgency than other bugs. This is not really reflected in the priority of a bug so the priority is not necessarily changed due to the higher urgency. When triaging a time waster, or when adding the label after a bug already has been triaged, it's recommended to notify the developers that work on the affected component, e.g. by sending an email to the proper mailing list and make sure the bug is assigned to someone. >> >> If you have a time waster assigned to you, please consider fixing it asap. If you chose to not work on the issue, you should at least be aware that you are choosing to waste more engineering time and others will be affected by this choice. >> >> To see currently open time wasters use the JBS filter Time wasters: https://bugs.openjdk.java.net/issues/?filter=35335 >> >> Thanks, >> /Jesper >> From mikhailo.seledtsov at oracle.com Thu Sep 20 17:57:10 2018 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Thu, 20 Sep 2018 10:57:10 -0700 Subject: Introducing time wasters In-Reply-To: <1ca63185-cb6a-bf8d-719b-16ebd234acd7@oracle.com> References: <4FCFBCDB-0773-4493-9FF4-266A51A49563@oracle.com> <1ca63185-cb6a-bf8d-719b-16ebd234acd7@oracle.com> Message-ID: <5BA3DF76.6030800@oracle.com> On 9/20/18, 9:23 AM, Jonathan Gibbons wrote: > +1 for "urgent" or some similar short meaningful name, along with a > guideline that there should be comments justifying the use of the label. > > Another reason for a label instead of priority is that it can be more > focussed, and can be used in filters/gadgets/dashboards in JBS. > > -- Jon > +1 > > On 9/20/18 9:04 AM, jesper.wilhelmsson at oracle.com wrote: >> OK, I see that this didn't come out as I intended it. The name >> "timewaster" is clearly not the best since it can be interpreted as >> "this bug is a waste of time - it shouldn't have been filed" - That >> was NOT what I meant. >> >> My intention was to have a label to indicate that a bug is urgent to >> fix because a lot of developers is currently spending time chasing >> down the same issue over and over. >> >> It has been suggested to increase the priority instead of using a >> label. One of the reasons that it ended up as a label is that JBS >> don't have a way to express urgency. Priority and urgency are two >> different things and should not be mixed, so raising the priority >> would send the wrong signal. One example is a broken test in tier 1 >> that is failing at every run. This bug would cause work for every >> engineer who is running through our tests, be it through the submit >> forest or in internal test frameworks in our different organisations. >> Fixing it is clearly urgent. However, raising the priority would mean >> that it becomes a blocker for the release. A broken test should not >> block the release. >> >> So, back to the name. Since urgency is what we're after, can we call >> it "urgent"? >> >> As for the "discussed, proposed, and adopted" part - This is where it >> is proposed and discussed. (Thanks to everyone who engage in the >> discussion!) >> It hasn't been adopted yet, it is, as I wrote, an experiment. >> >> Thanks, >> /Jesper >> >> >>> On 20 Sep 2018, at 02:04, jesper.wilhelmsson at oracle.com wrote: >>> >>> Hi, >>> >>> As an experiment we are introducing a new label in JBS, timewaster. >>> The label is used to tag bugs that for some reason is wasting >>> engineering time. This could for instance be a bug that occurs >>> frequently in our testing and causes many engineers to investigate >>> the failure in different test runs just to realize it's the same >>> issue as have been seen before, or worse, don't realize it is a >>> known issue and files a duplicate bug in JBS. Bugs that cause tests >>> to fail without a proper explanation may also be considered time >>> wasters since several engineers risk to investigate the failures >>> just to realize there is no information to be found. There are other >>> cases as well and there is some flexibility in the definition. If >>> you see an issue that have been wasting your time, feel free to add >>> an explanation to why you think it's a time waster and add the label. >>> >>> The fact that a bug is wasting engineering time should be taken into >>> account when a bug is triaged. A time waster has higher urgency than >>> other bugs. This is not really reflected in the priority of a bug so >>> the priority is not necessarily changed due to the higher urgency. >>> When triaging a time waster, or when adding the label after a bug >>> already has been triaged, it's recommended to notify the developers >>> that work on the affected component, e.g. by sending an email to the >>> proper mailing list and make sure the bug is assigned to someone. >>> >>> If you have a time waster assigned to you, please consider fixing it >>> asap. If you chose to not work on the issue, you should at least be >>> aware that you are choosing to waste more engineering time and >>> others will be affected by this choice. >>> >>> To see currently open time wasters use the JBS filter Time wasters: >>> https://bugs.openjdk.java.net/issues/?filter=35335 >>> >>> Thanks, >>> /Jesper >>> > From fweimer at redhat.com Thu Sep 20 18:14:55 2018 From: fweimer at redhat.com (Florian Weimer) Date: Thu, 20 Sep 2018 20:14:55 +0200 Subject: Introducing time wasters In-Reply-To: <0745e52e-5a1f-70d2-3100-87ba48614c76@redhat.com> (Aleksey Shipilev's message of "Thu, 20 Sep 2018 16:42:04 +0200") References: <5BA3248D.6000107@oracle.com> <74f63b69-3dac-453a-2c80-b297d678a25d@redhat.com> <165f76a2f80.2786.de43121e48c2b7fef2896cfce71f7232@bell-sw.com> <0745e52e-5a1f-70d2-3100-87ba48614c76@redhat.com> Message-ID: <87h8ikqbmo.fsf@oldenburg.str.redhat.com> * Aleksey Shipilev: > dev-hard implies "this requires hard development"? > > Probably, the variant of "critical-for-dev-experience" to turn the > whole thing positive. I think the point is the internal impact. Presumably it's like a test blocker, except that it's possible to work around once understood (but then the time waste has already occurred). I'm not sure if such bugs are automatically urgent. It's true that the fix will quickly pay for itself, but that doesn't really tell us much about priority and severity of the issue (and the difficulty of the fix 8-). Thanks, Florian From apr at jpos.org Thu Sep 20 18:31:18 2018 From: apr at jpos.org (Alejandro Revilla) Date: Thu, 20 Sep 2018 15:31:18 -0300 Subject: Introducing time wasters In-Reply-To: <87h8ikqbmo.fsf@oldenburg.str.redhat.com> References: <5BA3248D.6000107@oracle.com> <74f63b69-3dac-453a-2c80-b297d678a25d@redhat.com> <165f76a2f80.2786.de43121e48c2b7fef2896cfce71f7232@bell-sw.com> <0745e52e-5a1f-70d2-3100-87ba48614c76@redhat.com> <87h8ikqbmo.fsf@oldenburg.str.redhat.com> Message-ID: Why not 'nasty'? It's a nasty bug, after all. My 2c. -- @apr On Thu, Sep 20, 2018 at 3:14 PM, Florian Weimer wrote: > * Aleksey Shipilev: > > > dev-hard implies "this requires hard development"? > > > > Probably, the variant of "critical-for-dev-experience" to turn the > > whole thing positive. > > I think the point is the internal impact. Presumably it's like a test > blocker, except that it's possible to work around once understood (but > then the time waste has already occurred). > > I'm not sure if such bugs are automatically urgent. It's true that the > fix will quickly pay for itself, but that doesn't really tell us much > about priority and severity of the issue (and the difficulty of the fix > 8-). > > Thanks, > Florian > From neugens.limasoftware at gmail.com Thu Sep 20 19:29:57 2018 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Thu, 20 Sep 2018 21:29:57 +0200 Subject: Introducing time wasters In-Reply-To: References: <5BA3248D.6000107@oracle.com> <74f63b69-3dac-453a-2c80-b297d678a25d@redhat.com> <165f76a2f80.2786.de43121e48c2b7fef2896cfce71f7232@bell-sw.com> <0745e52e-5a1f-70d2-3100-87ba48614c76@redhat.com> <87h8ikqbmo.fsf@oldenburg.str.redhat.com> Message-ID: A "mosquito" bug. Very irritating indeed :) Cheers, Mario Il giorno gio 20 set 2018 alle ore 20:32 Alejandro Revilla ha scritto: > > Why not 'nasty'? It's a nasty bug, after all. > > My 2c. > > -- > @apr > > On Thu, Sep 20, 2018 at 3:14 PM, Florian Weimer wrote: > > > * Aleksey Shipilev: > > > > > dev-hard implies "this requires hard development"? > > > > > > Probably, the variant of "critical-for-dev-experience" to turn the > > > whole thing positive. > > > > I think the point is the internal impact. Presumably it's like a test > > blocker, except that it's possible to work around once understood (but > > then the time waste has already occurred). > > > > I'm not sure if such bugs are automatically urgent. It's true that the > > fix will quickly pay for itself, but that doesn't really tell us much > > about priority and severity of the issue (and the difficulty of the fix > > 8-). > > > > Thanks, > > Florian > > -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From talden at gmail.com Fri Sep 21 02:14:16 2018 From: talden at gmail.com (Aaron Scott-Boddendijk) Date: Fri, 21 Sep 2018 14:14:16 +1200 Subject: Introducing time wasters In-Reply-To: References: <5BA3248D.6000107@oracle.com> <74f63b69-3dac-453a-2c80-b297d678a25d@redhat.com> <165f76a2f80.2786.de43121e48c2b7fef2896cfce71f7232@bell-sw.com> <0745e52e-5a1f-70d2-3100-87ba48614c76@redhat.com> <87h8ikqbmo.fsf@oldenburg.str.redhat.com> Message-ID: I like the 'affects-dev' idea but maybe it should say how it affects them - productivity... "dev-productivity" maybe? The productivity losses taking the form of of one or more of the following (and almost certainly not exhaustive): * Redundantly repeated investigation (because the cause and symptoms make it non-obvious to find in the bug log). * Interrupting developer workflow or requiring a low-productivity workaround. * Impacting workflow efficiency, such as slow builds, tests, requiring repeated test-infrastructure tear-up/set-up cycles etc. This tag could mark issues that are bad things or good things for dev-productivity, anything that improves productivity by better tooling or removing pain. It should be noted that such bugs do impact customers - it's just that the impact is indirect, they get features and other fixes more slowly because the team is repeatedly impacted by this bug. -- Aaron Scott-Boddendijk On Fri, Sep 21, 2018 at 7:30 AM Mario Torre wrote: > A "mosquito" bug. Very irritating indeed :) > > Cheers, > Mario > Il giorno gio 20 set 2018 alle ore 20:32 Alejandro Revilla > ha scritto: > > > > Why not 'nasty'? It's a nasty bug, after all. > > > > My 2c. > > > > -- > > @apr > > > > On Thu, Sep 20, 2018 at 3:14 PM, Florian Weimer > wrote: > > > > > * Aleksey Shipilev: > > > > > > > dev-hard implies "this requires hard development"? > > > > > > > > Probably, the variant of "critical-for-dev-experience" to turn the > > > > whole thing positive. > > > > > > I think the point is the internal impact. Presumably it's like a test > > > blocker, except that it's possible to work around once understood (but > > > then the time waste has already occurred). > > > > > > I'm not sure if such bugs are automatically urgent. It's true that the > > > fix will quickly pay for itself, but that doesn't really tell us much > > > about priority and severity of the issue (and the difficulty of the fix > > > 8-). > > > > > > Thanks, > > > Florian > > > > > > > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens > Proud GNU Classpath developer: http://www.classpath.org/ > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ > From magnus.ihse.bursie at oracle.com Fri Sep 21 11:45:28 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 21 Sep 2018 13:45:28 +0200 Subject: Introducing time wasters In-Reply-To: References: <5BA3248D.6000107@oracle.com> <74f63b69-3dac-453a-2c80-b297d678a25d@redhat.com> <165f76a2f80.2786.de43121e48c2b7fef2896cfce71f7232@bell-sw.com> <0745e52e-5a1f-70d2-3100-87ba48614c76@redhat.com> <87h8ikqbmo.fsf@oldenburg.str.redhat.com> Message-ID: <2319b493-69b1-88de-adaf-7af98a80b73b@oracle.com> On 2018-09-21 04:14, Aaron Scott-Boddendijk wrote: > I like the 'affects-dev' idea but maybe it should say how it affects them - > productivity... "dev-productivity" maybe? Of all the suggestions given on this list, I like "dev-productivity" by far best! It's to the point, but still generic enough to be applied to anything (not just product bugs, but also slow builds or improper inclusion of slow tests) what is believed to improve developer productivity. As you say, developer productivity affects the customers in the end, but since it does so indirectly, it's not always so clear. /Magnus > > The productivity losses taking the form of of one or more of the following > (and almost certainly not exhaustive): > > * Redundantly repeated investigation (because the cause and symptoms make > it non-obvious to find in the bug log). > * Interrupting developer workflow or requiring a low-productivity > workaround. > * Impacting workflow efficiency, such as slow builds, tests, requiring > repeated test-infrastructure tear-up/set-up cycles etc. > > This tag could mark issues that are bad things or good things for > dev-productivity, anything that improves productivity by better tooling or > removing pain. > > It should be noted that such bugs do impact customers - it's just that the > impact is indirect, they get features and other fixes more slowly because > the team is repeatedly impacted by this bug. > > -- > Aaron Scott-Boddendijk > > > On Fri, Sep 21, 2018 at 7:30 AM Mario Torre > wrote: > >> A "mosquito" bug. Very irritating indeed :) >> >> Cheers, >> Mario >> Il giorno gio 20 set 2018 alle ore 20:32 Alejandro Revilla >> ha scritto: >>> Why not 'nasty'? It's a nasty bug, after all. >>> >>> My 2c. >>> >>> -- >>> @apr >>> >>> On Thu, Sep 20, 2018 at 3:14 PM, Florian Weimer >> wrote: >>>> * Aleksey Shipilev: >>>> >>>>> dev-hard implies "this requires hard development"? >>>>> >>>>> Probably, the variant of "critical-for-dev-experience" to turn the >>>>> whole thing positive. >>>> I think the point is the internal impact. Presumably it's like a test >>>> blocker, except that it's possible to work around once understood (but >>>> then the time waste has already occurred). >>>> >>>> I'm not sure if such bugs are automatically urgent. It's true that the >>>> fix will quickly pay for itself, but that doesn't really tell us much >>>> about priority and severity of the issue (and the difficulty of the fix >>>> 8-). >>>> >>>> Thanks, >>>> Florian >>>> >> >> >> -- >> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF >> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF >> >> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens >> Proud GNU Classpath developer: http://www.classpath.org/ >> OpenJDK: http://openjdk.java.net/projects/caciocavallo/ >> >> Please, support open standards: >> http://endsoftpatents.org/ >> From tim.bell at oracle.com Fri Sep 21 15:39:33 2018 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 21 Sep 2018 15:39:33 +0000 Subject: RFR: 8190985: .jcheck/conf files contain 'project=jdk10' In-Reply-To: <5BA50D7C.9070502@oracle.com> References: <5BA50D7C.9070502@oracle.com> Message-ID: <5BA510B5.2030804@oracle.com> (Originally sent to build-dev at openjdk.java.net - widening the audience here) This is a minor fix that will correct an oversight in .jcheck/conf: http://cr.openjdk.java.net/~tbell/8190985/webrev/ This affects where jcheck looks in the census when checking committers. Here is the diff: % hg diff diff --git a/.jcheck/conf b/.jcheck/conf --- a/.jcheck/conf +++ b/.jcheck/conf @@ -1,2 +1,2 @@ -project=jdk10 +project=jdk bugids=dup Testing: We ran "hg jcheck -vv -r 0..tip" which iterates over all changesets in the history for jdk/jdk. All good. Tim From mark.reinhold at oracle.com Fri Sep 21 15:48:38 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 21 Sep 2018 08:48:38 -0700 Subject: RFR: 8190985: .jcheck/conf files contain 'project=jdk10' In-Reply-To: <5BA510B5.2030804@oracle.com> References: <5BA50D7C.9070502@oracle.com> <5BA510B5.2030804@oracle.com> Message-ID: <20180921084838.568127885@eggemoggin.niobe.net> 2018/9/21 8:39:33 -0700, tim.bell at oracle.com: > % hg diff > diff --git a/.jcheck/conf b/.jcheck/conf > --- a/.jcheck/conf > +++ b/.jcheck/conf > @@ -1,2 +1,2 @@ > -project=jdk10 > +project=jdk > bugids=dup Looks good! - Mark From iris.clark at oracle.com Fri Sep 21 16:09:19 2018 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 21 Sep 2018 09:09:19 -0700 (PDT) Subject: RFR: 8190985: .jcheck/conf files contain 'project=jdk10' In-Reply-To: <5BA510B5.2030804@oracle.com> References: <5BA50D7C.9070502@oracle.com> <5BA510B5.2030804@oracle.com> Message-ID: Hi, Tim. > http://cr.openjdk.java.net/~tbell/8190985/webrev/ Looks good! iris From openjdk at haupz.de Fri Sep 21 17:47:31 2018 From: openjdk at haupz.de (Michael Haupt) Date: Fri, 21 Sep 2018 19:47:31 +0200 Subject: Introducing time wasters In-Reply-To: References: <5BA3248D.6000107@oracle.com> <74f63b69-3dac-453a-2c80-b297d678a25d@redhat.com> <165f76a2f80.2786.de43121e48c2b7fef2896cfce71f7232@bell-sw.com> <0745e52e-5a1f-70d2-3100-87ba48614c76@redhat.com> <87h8ikqbmo.fsf@oldenburg.str.redhat.com> Message-ID: <3127A6BF-9DB9-48A7-A3DC-5081EEC93215@haupz.de> Hi, "nuisance", "embuggerance", "kerfuffle"? Not entirely nonserious, Michael > Am 20.09.2018 um 20:31 schrieb Alejandro Revilla : > > Why not 'nasty'? It's a nasty bug, after all. > > My 2c. > > -- > @apr > >> On Thu, Sep 20, 2018 at 3:14 PM, Florian Weimer wrote: >> >> * Aleksey Shipilev: >> >>> dev-hard implies "this requires hard development"? >>> >>> Probably, the variant of "critical-for-dev-experience" to turn the >>> whole thing positive. >> >> I think the point is the internal impact. Presumably it's like a test >> blocker, except that it's possible to work around once understood (but >> then the time waste has already occurred). >> >> I'm not sure if such bugs are automatically urgent. It's true that the >> fix will quickly pay for itself, but that doesn't really tell us much >> about priority and severity of the issue (and the difficulty of the fix >> 8-). >> >> Thanks, >> Florian >> From mikael.vidstedt at oracle.com Fri Sep 21 18:26:11 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 21 Sep 2018 11:26:11 -0700 Subject: Introducing time wasters In-Reply-To: <2319b493-69b1-88de-adaf-7af98a80b73b@oracle.com> References: <5BA3248D.6000107@oracle.com> <74f63b69-3dac-453a-2c80-b297d678a25d@redhat.com> <165f76a2f80.2786.de43121e48c2b7fef2896cfce71f7232@bell-sw.com> <0745e52e-5a1f-70d2-3100-87ba48614c76@redhat.com> <87h8ikqbmo.fsf@oldenburg.str.redhat.com> <2319b493-69b1-88de-adaf-7af98a80b73b@oracle.com> Message-ID: <71023447-BA7B-4197-BBD9-9FA93774965F@oracle.com> I also like dev-productivity for many the same reasons! Cheers, Mikael > On Sep 21, 2018, at 4:45 AM, Magnus Ihse Bursie wrote: > > On 2018-09-21 04:14, Aaron Scott-Boddendijk wrote: >> I like the 'affects-dev' idea but maybe it should say how it affects them - >> productivity... "dev-productivity" maybe? > Of all the suggestions given on this list, I like "dev-productivity" by far best! > > It's to the point, but still generic enough to be applied to anything (not just product bugs, but also slow builds or improper inclusion of slow tests) what is believed to improve developer productivity. > > As you say, developer productivity affects the customers in the end, but since it does so indirectly, it's not always so clear. > > /Magnus >> >> The productivity losses taking the form of of one or more of the following >> (and almost certainly not exhaustive): >> >> * Redundantly repeated investigation (because the cause and symptoms make >> it non-obvious to find in the bug log). >> * Interrupting developer workflow or requiring a low-productivity >> workaround. >> * Impacting workflow efficiency, such as slow builds, tests, requiring >> repeated test-infrastructure tear-up/set-up cycles etc. >> >> This tag could mark issues that are bad things or good things for >> dev-productivity, anything that improves productivity by better tooling or >> removing pain. >> >> It should be noted that such bugs do impact customers - it's just that the >> impact is indirect, they get features and other fixes more slowly because >> the team is repeatedly impacted by this bug. >> >> -- >> Aaron Scott-Boddendijk >> >> >> On Fri, Sep 21, 2018 at 7:30 AM Mario Torre >> wrote: >> >>> A "mosquito" bug. Very irritating indeed :) >>> >>> Cheers, >>> Mario >>> Il giorno gio 20 set 2018 alle ore 20:32 Alejandro Revilla >>> ha scritto: >>>> Why not 'nasty'? It's a nasty bug, after all. >>>> >>>> My 2c. >>>> >>>> -- >>>> @apr >>>> >>>> On Thu, Sep 20, 2018 at 3:14 PM, Florian Weimer >>> wrote: >>>>> * Aleksey Shipilev: >>>>> >>>>>> dev-hard implies "this requires hard development"? >>>>>> >>>>>> Probably, the variant of "critical-for-dev-experience" to turn the >>>>>> whole thing positive. >>>>> I think the point is the internal impact. Presumably it's like a test >>>>> blocker, except that it's possible to work around once understood (but >>>>> then the time waste has already occurred). >>>>> >>>>> I'm not sure if such bugs are automatically urgent. It's true that the >>>>> fix will quickly pay for itself, but that doesn't really tell us much >>>>> about priority and severity of the issue (and the difficulty of the fix >>>>> 8-). >>>>> >>>>> Thanks, >>>>> Florian >>>>> >>> >>> >>> -- >>> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF >>> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF >>> >>> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens >>> Proud GNU Classpath developer: http://www.classpath.org/ >>> OpenJDK: http://openjdk.java.net/projects/caciocavallo/ >>> >>> Please, support open standards: >>> http://endsoftpatents.org/ >>> > From daniel.daugherty at oracle.com Fri Sep 21 19:03:03 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 21 Sep 2018 15:03:03 -0400 Subject: Introducing time wasters In-Reply-To: <71023447-BA7B-4197-BBD9-9FA93774965F@oracle.com> References: <5BA3248D.6000107@oracle.com> <74f63b69-3dac-453a-2c80-b297d678a25d@redhat.com> <165f76a2f80.2786.de43121e48c2b7fef2896cfce71f7232@bell-sw.com> <0745e52e-5a1f-70d2-3100-87ba48614c76@redhat.com> <87h8ikqbmo.fsf@oldenburg.str.redhat.com> <2319b493-69b1-88de-adaf-7af98a80b73b@oracle.com> <71023447-BA7B-4197-BBD9-9FA93774965F@oracle.com> Message-ID: <2dfef88f-4a5d-6340-d4cf-76b2ce07fbc0@oracle.com> Rather than make it specific to 'dev' or 'developers', perhaps ??? productivity-sink Dan On 9/21/18 2:26 PM, Mikael Vidstedt wrote: > I also like dev-productivity for many the same reasons! > > Cheers, > Mikael > >> On Sep 21, 2018, at 4:45 AM, Magnus Ihse Bursie wrote: >> >> On 2018-09-21 04:14, Aaron Scott-Boddendijk wrote: >>> I like the 'affects-dev' idea but maybe it should say how it affects them - >>> productivity... "dev-productivity" maybe? >> Of all the suggestions given on this list, I like "dev-productivity" by far best! >> >> It's to the point, but still generic enough to be applied to anything (not just product bugs, but also slow builds or improper inclusion of slow tests) what is believed to improve developer productivity. >> >> As you say, developer productivity affects the customers in the end, but since it does so indirectly, it's not always so clear. >> >> /Magnus >>> The productivity losses taking the form of of one or more of the following >>> (and almost certainly not exhaustive): >>> >>> * Redundantly repeated investigation (because the cause and symptoms make >>> it non-obvious to find in the bug log). >>> * Interrupting developer workflow or requiring a low-productivity >>> workaround. >>> * Impacting workflow efficiency, such as slow builds, tests, requiring >>> repeated test-infrastructure tear-up/set-up cycles etc. >>> >>> This tag could mark issues that are bad things or good things for >>> dev-productivity, anything that improves productivity by better tooling or >>> removing pain. >>> >>> It should be noted that such bugs do impact customers - it's just that the >>> impact is indirect, they get features and other fixes more slowly because >>> the team is repeatedly impacted by this bug. >>> >>> -- >>> Aaron Scott-Boddendijk >>> >>> >>> On Fri, Sep 21, 2018 at 7:30 AM Mario Torre >>> wrote: >>> >>>> A "mosquito" bug. Very irritating indeed :) >>>> >>>> Cheers, >>>> Mario >>>> Il giorno gio 20 set 2018 alle ore 20:32 Alejandro Revilla >>>> ha scritto: >>>>> Why not 'nasty'? It's a nasty bug, after all. >>>>> >>>>> My 2c. >>>>> >>>>> -- >>>>> @apr >>>>> >>>>> On Thu, Sep 20, 2018 at 3:14 PM, Florian Weimer >>>> wrote: >>>>>> * Aleksey Shipilev: >>>>>> >>>>>>> dev-hard implies "this requires hard development"? >>>>>>> >>>>>>> Probably, the variant of "critical-for-dev-experience" to turn the >>>>>>> whole thing positive. >>>>>> I think the point is the internal impact. Presumably it's like a test >>>>>> blocker, except that it's possible to work around once understood (but >>>>>> then the time waste has already occurred). >>>>>> >>>>>> I'm not sure if such bugs are automatically urgent. It's true that the >>>>>> fix will quickly pay for itself, but that doesn't really tell us much >>>>>> about priority and severity of the issue (and the difficulty of the fix >>>>>> 8-). >>>>>> >>>>>> Thanks, >>>>>> Florian >>>>>> >>>> >>>> -- >>>> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF >>>> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF >>>> >>>> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens >>>> Proud GNU Classpath developer: http://www.classpath.org/ >>>> OpenJDK: http://openjdk.java.net/projects/caciocavallo/ >>>> >>>> Please, support open standards: >>>> http://endsoftpatents.org/ >>>> > From roman at kennke.org Fri Sep 21 19:33:44 2018 From: roman at kennke.org (Roman Kennke) Date: Fri, 21 Sep 2018 21:33:44 +0200 Subject: Introducing time wasters In-Reply-To: <2dfef88f-4a5d-6340-d4cf-76b2ce07fbc0@oracle.com> References: <5BA3248D.6000107@oracle.com> <74f63b69-3dac-453a-2c80-b297d678a25d@redhat.com> <165f76a2f80.2786.de43121e48c2b7fef2896cfce71f7232@bell-sw.com> <0745e52e-5a1f-70d2-3100-87ba48614c76@redhat.com> <87h8ikqbmo.fsf@oldenburg.str.redhat.com> <2319b493-69b1-88de-adaf-7af98a80b73b@oracle.com> <71023447-BA7B-4197-BBD9-9FA93774965F@oracle.com> <2dfef88f-4a5d-6340-d4cf-76b2ce07fbc0@oracle.com> Message-ID: <11722009-c147-38d0-5820-2abd2f395e97@kennke.org> +1 My favorite so far. Next to dev-productivity. > Rather than make it specific to 'dev' or 'developers', perhaps > > ??? productivity-sink > > Dan > > > On 9/21/18 2:26 PM, Mikael Vidstedt wrote: >> I also like dev-productivity for many the same reasons! >> >> Cheers, >> Mikael >> >>> On Sep 21, 2018, at 4:45 AM, Magnus Ihse Bursie >>> wrote: >>> >>> On 2018-09-21 04:14, Aaron Scott-Boddendijk wrote: >>>> I like the 'affects-dev' idea but maybe it should say how it affects >>>> them - >>>> productivity... "dev-productivity" maybe? >>> Of all the suggestions given on this list, I like "dev-productivity" >>> by far best! >>> >>> It's to the point, but still generic enough to be applied to anything >>> (not just product bugs, but also slow builds or improper inclusion of >>> slow tests) what is believed to improve developer productivity. >>> >>> As you say, developer productivity affects the customers in the end, >>> but since it does so indirectly, it's not always so clear. >>> >>> /Magnus >>>> The productivity losses taking the form of of one or more of the >>>> following >>>> (and almost certainly not exhaustive): >>>> >>>> * Redundantly repeated investigation (because the cause and symptoms >>>> make >>>> it non-obvious to find in the bug log). >>>> * Interrupting developer workflow or requiring a low-productivity >>>> workaround. >>>> * Impacting workflow efficiency, such as slow builds, tests, requiring >>>> repeated test-infrastructure tear-up/set-up cycles etc. >>>> >>>> This tag could mark issues that are bad things or good things for >>>> dev-productivity, anything that improves productivity by better >>>> tooling or >>>> removing pain. >>>> >>>> It should be noted that such bugs do impact customers - it's just >>>> that the >>>> impact is indirect, they get features and other fixes more slowly >>>> because >>>> the team is repeatedly impacted by this bug. >>>> >>>> -- >>>> Aaron Scott-Boddendijk >>>> >>>> >>>> On Fri, Sep 21, 2018 at 7:30 AM Mario Torre >>>> >>>> wrote: >>>> >>>>> A "mosquito" bug. Very irritating indeed :) >>>>> >>>>> Cheers, >>>>> Mario >>>>> Il giorno gio 20 set 2018 alle ore 20:32 Alejandro Revilla >>>>> ha scritto: >>>>>> Why not 'nasty'? It's a nasty bug, after all. >>>>>> >>>>>> My 2c. >>>>>> >>>>>> -- >>>>>> @apr >>>>>> >>>>>> On Thu, Sep 20, 2018 at 3:14 PM, Florian Weimer >>>>> wrote: >>>>>>> * Aleksey Shipilev: >>>>>>> >>>>>>>> dev-hard implies "this requires hard development"? >>>>>>>> >>>>>>>> Probably, the variant of "critical-for-dev-experience" to turn the >>>>>>>> whole thing positive. >>>>>>> I think the point is the internal impact.? Presumably it's like a >>>>>>> test >>>>>>> blocker, except that it's possible to work around once understood >>>>>>> (but >>>>>>> then the time waste has already occurred). >>>>>>> >>>>>>> I'm not sure if such bugs are automatically urgent.? It's true >>>>>>> that the >>>>>>> fix will quickly pay for itself, but that doesn't really tell us >>>>>>> much >>>>>>> about priority and severity of the issue (and the difficulty of >>>>>>> the fix >>>>>>> 8-). >>>>>>> >>>>>>> Thanks, >>>>>>> Florian >>>>>>> >>>>> >>>>> -- >>>>> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF >>>>> Fingerprint: BA39 9666 94EC 8B73 27FA? FC7C 4086 63E3 80F2 40CF >>>>> >>>>> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens >>>>> Proud GNU Classpath developer: http://www.classpath.org/ >>>>> OpenJDK: http://openjdk.java.net/projects/caciocavallo/ >>>>> >>>>> Please, support open standards: >>>>> http://endsoftpatents.org/ >>>>> >> > > From mikhailo.seledtsov at oracle.com Fri Sep 21 20:11:24 2018 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Fri, 21 Sep 2018 13:11:24 -0700 Subject: Introducing time wasters In-Reply-To: <2dfef88f-4a5d-6340-d4cf-76b2ce07fbc0@oracle.com> References: <5BA3248D.6000107@oracle.com> <74f63b69-3dac-453a-2c80-b297d678a25d@redhat.com> <165f76a2f80.2786.de43121e48c2b7fef2896cfce71f7232@bell-sw.com> <0745e52e-5a1f-70d2-3100-87ba48614c76@redhat.com> <87h8ikqbmo.fsf@oldenburg.str.redhat.com> <2319b493-69b1-88de-adaf-7af98a80b73b@oracle.com> <71023447-BA7B-4197-BBD9-9FA93774965F@oracle.com> <2dfef88f-4a5d-6340-d4cf-76b2ce07fbc0@oracle.com> Message-ID: <5BA5506C.8070006@oracle.com> +1 On 9/21/18, 12:03 PM, Daniel D. Daugherty wrote: > Rather than make it specific to 'dev' or 'developers', perhaps > > productivity-sink > > Dan > > > On 9/21/18 2:26 PM, Mikael Vidstedt wrote: >> I also like dev-productivity for many the same reasons! >> >> Cheers, >> Mikael >> >>> On Sep 21, 2018, at 4:45 AM, Magnus Ihse Bursie >>> wrote: >>> >>> On 2018-09-21 04:14, Aaron Scott-Boddendijk wrote: >>>> I like the 'affects-dev' idea but maybe it should say how it >>>> affects them - >>>> productivity... "dev-productivity" maybe? >>> Of all the suggestions given on this list, I like "dev-productivity" >>> by far best! >>> >>> It's to the point, but still generic enough to be applied to >>> anything (not just product bugs, but also slow builds or improper >>> inclusion of slow tests) what is believed to improve developer >>> productivity. >>> >>> As you say, developer productivity affects the customers in the end, >>> but since it does so indirectly, it's not always so clear. >>> >>> /Magnus >>>> The productivity losses taking the form of of one or more of the >>>> following >>>> (and almost certainly not exhaustive): >>>> >>>> * Redundantly repeated investigation (because the cause and >>>> symptoms make >>>> it non-obvious to find in the bug log). >>>> * Interrupting developer workflow or requiring a low-productivity >>>> workaround. >>>> * Impacting workflow efficiency, such as slow builds, tests, requiring >>>> repeated test-infrastructure tear-up/set-up cycles etc. >>>> >>>> This tag could mark issues that are bad things or good things for >>>> dev-productivity, anything that improves productivity by better >>>> tooling or >>>> removing pain. >>>> >>>> It should be noted that such bugs do impact customers - it's just >>>> that the >>>> impact is indirect, they get features and other fixes more slowly >>>> because >>>> the team is repeatedly impacted by this bug. >>>> >>>> -- >>>> Aaron Scott-Boddendijk >>>> >>>> >>>> On Fri, Sep 21, 2018 at 7:30 AM Mario Torre >>>> >>>> wrote: >>>> >>>>> A "mosquito" bug. Very irritating indeed :) >>>>> >>>>> Cheers, >>>>> Mario >>>>> Il giorno gio 20 set 2018 alle ore 20:32 Alejandro Revilla >>>>> ha scritto: >>>>>> Why not 'nasty'? It's a nasty bug, after all. >>>>>> >>>>>> My 2c. >>>>>> >>>>>> -- >>>>>> @apr >>>>>> >>>>>> On Thu, Sep 20, 2018 at 3:14 PM, Florian Weimer >>>>> wrote: >>>>>>> * Aleksey Shipilev: >>>>>>> >>>>>>>> dev-hard implies "this requires hard development"? >>>>>>>> >>>>>>>> Probably, the variant of "critical-for-dev-experience" to turn the >>>>>>>> whole thing positive. >>>>>>> I think the point is the internal impact. Presumably it's like >>>>>>> a test >>>>>>> blocker, except that it's possible to work around once >>>>>>> understood (but >>>>>>> then the time waste has already occurred). >>>>>>> >>>>>>> I'm not sure if such bugs are automatically urgent. It's true >>>>>>> that the >>>>>>> fix will quickly pay for itself, but that doesn't really tell us >>>>>>> much >>>>>>> about priority and severity of the issue (and the difficulty of >>>>>>> the fix >>>>>>> 8-). >>>>>>> >>>>>>> Thanks, >>>>>>> Florian >>>>>>> >>>>> >>>>> -- >>>>> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF >>>>> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF >>>>> >>>>> Java Champion - Blog: http://neugens.wordpress.com - Twitter: >>>>> @neugens >>>>> Proud GNU Classpath developer: http://www.classpath.org/ >>>>> OpenJDK: http://openjdk.java.net/projects/caciocavallo/ >>>>> >>>>> Please, support open standards: >>>>> http://endsoftpatents.org/ >>>>> >> > From mark.reinhold at oracle.com Sat Sep 22 00:22:30 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 21 Sep 2018 17:22:30 -0700 Subject: Introducing time wasters In-Reply-To: <2dfef88f-4a5d-6340-d4cf-76b2ce07fbc0@oracle.com> References: <5BA3248D.6000107@oracle.com> <74f63b69-3dac-453a-2c80-b297d678a25d@redhat.com> <165f76a2f80.2786.de43121e48c2b7fef2896cfce71f7232@bell-sw.com> <0745e52e-5a1f-70d2-3100-87ba48614c76@redhat.com> <87h8ikqbmo.fsf@oldenburg.str.redhat.com> <2319b493-69b1-88de-adaf-7af98a80b73b@oracle.com> <71023447-BA7B-4197-BBD9-9FA93774965F@oracle.com> <2dfef88f-4a5d-6340-d4cf-76b2ce07fbc0@oracle.com> Message-ID: <20180921172230.503154009@eggemoggin.niobe.net> 2018/9/21 12:03:03 -0700, daniel.daugherty at oracle.com: > Rather than make it specific to 'dev' or 'developers', perhaps > > productivity-sink Productivity sink for whom? Someone using the JDK, or someone working on it? Arguably the lack of (to pick a random example) extension methods in the language is a productivity sink for some developers in the latter category. This suggests labels that include the token ?maintainer.? Maybe one of: affects-maintainers maintainer-burden maintainer-nuisance maintainer-overhead maintainer-sink maintainer-slog maintainer-slowdown maintainer-tax ... or something like that. - Mark From talden at gmail.com Sat Sep 22 01:53:58 2018 From: talden at gmail.com (Aaron Scott-Boddendijk) Date: Sat, 22 Sep 2018 13:53:58 +1200 Subject: Introducing time wasters In-Reply-To: <20180921172230.503154009@eggemoggin.niobe.net> References: <5BA3248D.6000107@oracle.com> <74f63b69-3dac-453a-2c80-b297d678a25d@redhat.com> <165f76a2f80.2786.de43121e48c2b7fef2896cfce71f7232@bell-sw.com> <0745e52e-5a1f-70d2-3100-87ba48614c76@redhat.com> <87h8ikqbmo.fsf@oldenburg.str.redhat.com> <2319b493-69b1-88de-adaf-7af98a80b73b@oracle.com> <71023447-BA7B-4197-BBD9-9FA93774965F@oracle.com> <2dfef88f-4a5d-6340-d4cf-76b2ce07fbc0@oracle.com> <20180921172230.503154009@eggemoggin.niobe.net> Message-ID: I like the 'maintainer' suggestion - dev is a little 'down in the code', whereas maintainer recognises all of the contributors of assets to the product. I wouldn't use 'sink' myself because this reads negatively and feels odd when placed on tooling enhancements. To me 'maintainer-productivity' would read more neutrally (though long) and simply states the benefit of resolving the issue - though I'm aware that this thread started with a desire to draw attention to pain (rather than opportunity). -- Aaron Scott-Boddendijk On Sat, Sep 22, 2018 at 12:23 PM wrote: > 2018/9/21 12:03:03 -0700, daniel.daugherty at oracle.com: > > Rather than make it specific to 'dev' or 'developers', perhaps > > > > productivity-sink > > Productivity sink for whom? Someone using the JDK, or someone working > on it? Arguably the lack of (to pick a random example) extension > methods in the language is a productivity sink for some developers in > the latter category. > > This suggests labels that include the token ?maintainer.? Maybe one of: > > affects-maintainers > maintainer-burden > maintainer-nuisance > maintainer-overhead > maintainer-sink > maintainer-slog > maintainer-slowdown > maintainer-tax > > ... or something like that. > > - Mark > From erik.helin at oracle.com Sat Sep 22 08:49:54 2018 From: erik.helin at oracle.com (Erik Helin) Date: Sat, 22 Sep 2018 10:49:54 +0200 Subject: RFR: 8190985: .jcheck/conf files contain 'project=jdk10' In-Reply-To: <5BA510B5.2030804@oracle.com> References: <5BA50D7C.9070502@oracle.com> <5BA510B5.2030804@oracle.com> Message-ID: On 09/21/2018 05:39 PM, Tim Bell wrote: > % hg diff > diff --git a/.jcheck/conf b/.jcheck/conf > --- a/.jcheck/conf > +++ b/.jcheck/conf > @@ -1,2 +1,2 @@ > -project=jdk10 > +project=jdk > ?bugids=dup Looks good to me, Reviewed. Thanks for fixing this Tim! Erik From ivan.gerasimov at oracle.com Sat Sep 22 11:57:58 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sat, 22 Sep 2018 04:57:58 -0700 Subject: Introducing time wasters In-Reply-To: <4FCFBCDB-0773-4493-9FF4-266A51A49563@oracle.com> References: <4FCFBCDB-0773-4493-9FF4-266A51A49563@oracle.com> Message-ID: I think that number of votes for the bug can indicate urgency. However this functionality do not seem to used too often (for example a query 'component = core-libs and votes > 1' returned only 8 issues for me). Maybe we should use (and pay attention to) the votes more actively? Just an opinion. With kind regards, Ivan On 9/20/18 9:04 AM, jesper.wilhelmsson at oracle.com wrote: > OK, I see that this didn't come out as I intended it. The name "timewaster" is clearly not the best since it can be interpreted as "this bug is a waste of time - it shouldn't have been filed" - That was NOT what I meant. > > My intention was to have a label to indicate that a bug is urgent to fix because a lot of developers is currently spending time chasing down the same issue over and over. > > It has been suggested to increase the priority instead of using a label. One of the reasons that it ended up as a label is that JBS don't have a way to express urgency. Priority and urgency are two different things and should not be mixed, so raising the priority would send the wrong signal. One example is a broken test in tier 1 that is failing at every run. This bug would cause work for every engineer who is running through our tests, be it through the submit forest or in internal test frameworks in our different organisations. Fixing it is clearly urgent. However, raising the priority would mean that it becomes a blocker for the release. A broken test should not block the release. > > So, back to the name. Since urgency is what we're after, can we call it "urgent"? > > As for the "discussed, proposed, and adopted" part - This is where it is proposed and discussed. (Thanks to everyone who engage in the discussion!) > It hasn't been adopted yet, it is, as I wrote, an experiment. > > Thanks, > /Jesper > > >> On 20 Sep 2018, at 02:04, jesper.wilhelmsson at oracle.com wrote: >> >> Hi, >> >> As an experiment we are introducing a new label in JBS, timewaster. The label is used to tag bugs that for some reason is wasting engineering time. This could for instance be a bug that occurs frequently in our testing and causes many engineers to investigate the failure in different test runs just to realize it's the same issue as have been seen before, or worse, don't realize it is a known issue and files a duplicate bug in JBS. Bugs that cause tests to fail without a proper explanation may also be considered time wasters since several engineers risk to investigate the failures just to realize there is no information to be found. There are other cases as well and there is some flexibility in the definition. If you see an issue that have been wasting your time, feel free to add an explanation to why you think it's a time waster and add the label. >> >> The fact that a bug is wasting engineering time should be taken into account when a bug is triaged. A time waster has higher urgency than other bugs. This is not really reflected in the priority of a bug so the priority is not necessarily changed due to the higher urgency. When triaging a time waster, or when adding the label after a bug already has been triaged, it's recommended to notify the developers that work on the affected component, e.g. by sending an email to the proper mailing list and make sure the bug is assigned to someone. >> >> If you have a time waster assigned to you, please consider fixing it asap. If you chose to not work on the issue, you should at least be aware that you are choosing to waste more engineering time and others will be affected by this choice. >> >> To see currently open time wasters use the JBS filter Time wasters: https://bugs.openjdk.java.net/issues/?filter=35335 >> >> Thanks, >> /Jesper >> > -- With kind regards, Ivan Gerasimov From gromero at linux.vnet.ibm.com Sat Sep 22 13:11:59 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Sat, 22 Sep 2018 10:11:59 -0300 Subject: Introducing time wasters In-Reply-To: References: <4FCFBCDB-0773-4493-9FF4-266A51A49563@oracle.com> Message-ID: <6a280ddd-7a87-f8d9-8464-6b801d56279c@linux.vnet.ibm.com> On 09/22/2018 08:57 AM, Ivan Gerasimov wrote: > I think that number of votes for the bug can indicate urgency. > > However this functionality do not seem to used too often (for example a query 'component = core-libs? and votes > 1' returned only 8 issues for me). oh we do have a counter already... I totally missed that. > Maybe we should use (and pay attention to) the votes more actively? I really think that having a counter instead of a static label is the best way to convey the idea we are discussing here, so +1. ...maybe modify "Votes:" counter name or add another named like Mark and others suggested for the label name, as "affects-maintainers" (+1 for that BTW). But use a counter and not a static label either way. Regards, Gustavo > Just an opinion. > > With kind regards, > Ivan > > On 9/20/18 9:04 AM, jesper.wilhelmsson at oracle.com wrote: >> OK, I see that this didn't come out as I intended it. The name "timewaster" is clearly not the best since it can be interpreted as "this bug is a waste of time - it shouldn't have been filed" - That was NOT what I meant. >> >> My intention was to have a label to indicate that a bug is urgent to fix because a lot of developers is currently spending time chasing down the same issue over and over. >> >> It has been suggested to increase the priority instead of using a label. One of the reasons that it ended up as a label is that JBS don't have a way to express urgency. Priority and urgency are two different things and should not be mixed, so raising the priority would send the wrong signal. One example is a broken test in tier 1 that is failing at every run. This bug would cause work for every engineer who is running through our tests, be it through the submit forest or in internal test frameworks in our different organisations. Fixing it is clearly urgent. However, raising the priority would mean that it becomes a blocker for the release. A broken test should not block the release. >> >> So, back to the name. Since urgency is what we're after, can we call it "urgent"? >> >> As for the "discussed, proposed, and adopted" part - This is where it is proposed and discussed. (Thanks to everyone who engage in the discussion!) >> It hasn't been adopted yet, it is, as I wrote, an experiment. >> >> Thanks, >> /Jesper >> >> >>> On 20 Sep 2018, at 02:04, jesper.wilhelmsson at oracle.com wrote: >>> >>> Hi, >>> >>> As an experiment we are introducing a new label in JBS, timewaster. The label is used to tag bugs that for some reason is wasting engineering time. This could for instance be a bug that occurs frequently in our testing and causes many engineers to investigate the failure in different test runs just to realize it's the same issue as have been seen before, or worse, don't realize it is a known issue and files a duplicate bug in JBS. Bugs that cause tests to fail without a proper explanation may also be considered time wasters since several engineers risk to investigate the failures just to realize there is no information to be found. There are other cases as well and there is some flexibility in the definition. If you see an issue that have been wasting your time, feel free to add an explanation to why you think it's a time waster and add the label. >>> >>> The fact that a bug is wasting engineering time should be taken into account when a bug is triaged. A time waster has higher urgency than other bugs. This is not really reflected in the priority of a bug so the priority is not necessarily changed due to the higher urgency. When triaging a time waster, or when adding the label after a bug already has been triaged, it's recommended to notify the developers that work on the affected component, e.g. by sending an email to the proper mailing list and make sure the bug is assigned to someone. >>> >>> If you have a time waster assigned to you, please consider fixing it asap. If you chose to not work on the issue, you should at least be aware that you are choosing to waste more engineering time and others will be affected by this choice. >>> >>> To see currently open time wasters use the JBS filter Time wasters: https://bugs.openjdk.java.net/issues/?filter=35335 >>> >>> Thanks, >>> /Jesper >>> >> > From mark.reinhold at oracle.com Sat Sep 22 17:41:39 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Sat, 22 Sep 2018 10:41:39 -0700 Subject: Introducing time wasters In-Reply-To: <20180921172230.503154009@eggemoggin.niobe.net> References: <5BA3248D.6000107@oracle.com> <74f63b69-3dac-453a-2c80-b297d678a25d@redhat.com> <165f76a2f80.2786.de43121e48c2b7fef2896cfce71f7232@bell-sw.com> <0745e52e-5a1f-70d2-3100-87ba48614c76@redhat.com> <87h8ikqbmo.fsf@oldenburg.str.redhat.com> <2319b493-69b1-88de-adaf-7af98a80b73b@oracle.com> <71023447-BA7B-4197-BBD9-9FA93774965F@oracle.com> <2dfef88f-4a5d-6340-d4cf-76b2ce07fbc0@oracle.com> <20180921172230.503154009@eggemoggin.niobe.net> Message-ID: <20180922104139.971975988@eggemoggin.niobe.net> 2018/9/21 17:22:30 -0700, mark.reinhold at oracle.com: > ... > > This suggests labels that include the token ?maintainer.? Maybe one of: > > affects-maintainers > maintainer-burden > maintainer-nuisance > maintainer-overhead > maintainer-sink > maintainer-slog > maintainer-slowdown > maintainer-tax > > ... or something like that. ... or a simple rhyme: maintainer-pain - Mark From roman at kennke.org Sat Sep 22 19:25:44 2018 From: roman at kennke.org (Roman Kennke) Date: Sat, 22 Sep 2018 21:25:44 +0200 Subject: Introducing time wasters In-Reply-To: <20180922104139.971975988@eggemoggin.niobe.net> References: <5BA3248D.6000107@oracle.com> <74f63b69-3dac-453a-2c80-b297d678a25d@redhat.com> <165f76a2f80.2786.de43121e48c2b7fef2896cfce71f7232@bell-sw.com> <0745e52e-5a1f-70d2-3100-87ba48614c76@redhat.com> <87h8ikqbmo.fsf@oldenburg.str.redhat.com> <2319b493-69b1-88de-adaf-7af98a80b73b@oracle.com> <71023447-BA7B-4197-BBD9-9FA93774965F@oracle.com> <2dfef88f-4a5d-6340-d4cf-76b2ce07fbc0@oracle.com> <20180921172230.503154009@eggemoggin.niobe.net> <20180922104139.971975988@eggemoggin.niobe.net> Message-ID: <36521e63-8ece-16c6-2a2e-7b0b8992e205@kennke.org> >> This suggests labels that include the token ?maintainer.? Maybe one of: >> >> affects-maintainers >> maintainer-burden >> maintainer-nuisance >> maintainer-overhead >> maintainer-sink >> maintainer-slog >> maintainer-slowdown >> maintainer-tax >> >> ... or something like that. > > ... or a simple rhyme: > > maintainer-pain > I like that too :-) Also, couldn't resist: https://bugs.openjdk.java.net/browse/JDK-8211042 I like how that thread turned into self-documenting the kind of issue that it is all about ;-) Roman From adinn at redhat.com Mon Sep 24 10:51:44 2018 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 24 Sep 2018 11:51:44 +0100 Subject: Introducing time wasters In-Reply-To: <6a280ddd-7a87-f8d9-8464-6b801d56279c@linux.vnet.ibm.com> References: <4FCFBCDB-0773-4493-9FF4-266A51A49563@oracle.com> <6a280ddd-7a87-f8d9-8464-6b801d56279c@linux.vnet.ibm.com> Message-ID: <23d44c4d-be14-0f92-eef3-da1a6fc3857f@redhat.com> On 22/09/18 14:11, Gustavo Romero wrote: > On 09/22/2018 08:57 AM, Ivan Gerasimov wrote: >> Maybe we should use (and pay attention to) the votes more actively? > > I really think that having a counter instead of a static label is the best > way to convey the idea we are discussing here, so +1. > > ...maybe modify "Votes:" counter name or add another named like Mark and > others suggested for the label name, as "affects-maintainers" > (+1 for that BTW). But use a counter and not a static label either way. Oh, boy, I knew this would turn into a bikeshed discussion :-) Unfortunately, by relocating this tag into the realm of the beauty contest, I think this idea misses the point. In two ways: In almost all cases canvassing of opinions will not not needed to determine that a defect is going to cause developers pain. Furthermore, shifting the burden of arriving at such judgement to developers and, in particular, making it's validity dependent on how many developers actually 1) come across and 2) report the pain they are exposed to is likely to make this remedy a very unreliable cure for the original problem -- the desired cure being simply to flag urgency for whoever needs to ensure a problem gets fixed rather than create work for everyone else. I suggest someone very quickly makes an /executive decision/ to: pick an ok name from the many extant suggestions and mandate its use, irrespective of any subsequently expressed preferences. Honestly, silver was a a bad idea but grey will be fine. Jesper? I think the ball is in your court! regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From jesper.wilhelmsson at oracle.com Mon Sep 24 17:38:23 2018 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Mon, 24 Sep 2018 19:38:23 +0200 Subject: Introducing time wasters In-Reply-To: <23d44c4d-be14-0f92-eef3-da1a6fc3857f@redhat.com> References: <4FCFBCDB-0773-4493-9FF4-266A51A49563@oracle.com> <6a280ddd-7a87-f8d9-8464-6b801d56279c@linux.vnet.ibm.com> <23d44c4d-be14-0f92-eef3-da1a6fc3857f@redhat.com> Message-ID: <3A86D3F6-49AF-4A13-B475-1E7E6BE4ED45@oracle.com> > I suggest someone very quickly makes an /executive decision/ to: pick an > ok name from the many extant suggestions and mandate its use, > irrespective of any subsequently expressed preferences. Honestly, silver > was a a bad idea but grey will be fine. > > Jesper? I think the ball is in your court! Thank you all for your contributions to this discussion! I have read through all suggestions and there are several examples to suggest that a label is the right way to go, so I'll stick to that. As for naming, these are a few of the arguments that both support my initial idea, and seem to have support in the discussion: "The point of this tag is to emphasise that the bug is costly in developer time while it remains present i.e. that it is a priority to fix this." "From my exp long labels tend not to be used and no, JIRA suggestions do not help. I'll be happy to see a positive short label." A label like "urgent" or "fix-urgent" would satisfy these aspects, but after some mulling over this I concluded that these are too generic and could be placed on any P1 bug. I wanted to capture the developer/maintainer aspect as well, not just that a bug is critical to fix. So comments like: "Rather than make it specific to 'dev' or 'developers', perhaps..." ... "This suggests labels that include the token ?maintainer.?" "...this thread started with a desire to draw attention to pain (rather than opportunity)" make me think that the best suggestion so far is maintainer-pain. I have updated the filter and the bugs that were already labeled: https://bugs.openjdk.java.net/issues/?filter=35335 If this is acceptable I'll update and close JDK-8211042. Thanks, /Jesper From mikael.vidstedt at oracle.com Mon Sep 24 17:43:37 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 24 Sep 2018 10:43:37 -0700 Subject: Introducing time wasters In-Reply-To: <3A86D3F6-49AF-4A13-B475-1E7E6BE4ED45@oracle.com> References: <4FCFBCDB-0773-4493-9FF4-266A51A49563@oracle.com> <6a280ddd-7a87-f8d9-8464-6b801d56279c@linux.vnet.ibm.com> <23d44c4d-be14-0f92-eef3-da1a6fc3857f@redhat.com> <3A86D3F6-49AF-4A13-B475-1E7E6BE4ED45@oracle.com> Message-ID: <1C815791-D5F8-4881-846C-6F2E25480B94@oracle.com> > On Sep 24, 2018, at 10:38 AM, jesper.wilhelmsson at oracle.com wrote: > > >> I suggest someone very quickly makes an /executive decision/ to: pick an >> ok name from the many extant suggestions and mandate its use, >> irrespective of any subsequently expressed preferences. Honestly, silver >> was a a bad idea but grey will be fine. >> >> Jesper? I think the ball is in your court! > > Thank you all for your contributions to this discussion! > > I have read through all suggestions and there are several examples to suggest that a label is the right way to go, so I'll stick to that. As for naming, these are a few of the arguments that both support my initial idea, and seem to have support in the discussion: > > "The point of this tag is to emphasise that the bug is costly in developer time while it remains present i.e. that it is a priority to fix this." > "From my exp long labels tend not to be used and no, JIRA suggestions do not help. I'll be happy to see a positive short label." > > A label like "urgent" or "fix-urgent" would satisfy these aspects, but after some mulling over this I concluded that these are too generic and could be placed on any P1 bug. I wanted to capture the developer/maintainer aspect as well, not just that a bug is critical to fix. So comments like: > > "Rather than make it specific to 'dev' or 'developers', perhaps..." > ... "This suggests labels that include the token ?maintainer.?" > "...this thread started with a desire to draw attention to pain (rather than opportunity)" > > make me think that the best suggestion so far is maintainer-pain. Works for me! Cheers, Mikael From daniel.daugherty at oracle.com Mon Sep 24 18:41:21 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 24 Sep 2018 14:41:21 -0400 Subject: Introducing time wasters In-Reply-To: <1C815791-D5F8-4881-846C-6F2E25480B94@oracle.com> References: <4FCFBCDB-0773-4493-9FF4-266A51A49563@oracle.com> <6a280ddd-7a87-f8d9-8464-6b801d56279c@linux.vnet.ibm.com> <23d44c4d-be14-0f92-eef3-da1a6fc3857f@redhat.com> <3A86D3F6-49AF-4A13-B475-1E7E6BE4ED45@oracle.com> <1C815791-D5F8-4881-846C-6F2E25480B94@oracle.com> Message-ID: On 9/24/18 1:43 PM, Mikael Vidstedt wrote: >> On Sep 24, 2018, at 10:38 AM, jesper.wilhelmsson at oracle.com wrote: >> >> >>> I suggest someone very quickly makes an /executive decision/ to: pick an >>> ok name from the many extant suggestions and mandate its use, >>> irrespective of any subsequently expressed preferences. Honestly, silver >>> was a a bad idea but grey will be fine. >>> >>> Jesper? I think the ball is in your court! >> Thank you all for your contributions to this discussion! >> >> I have read through all suggestions and there are several examples to suggest that a label is the right way to go, so I'll stick to that. As for naming, these are a few of the arguments that both support my initial idea, and seem to have support in the discussion: >> >> "The point of this tag is to emphasise that the bug is costly in developer time while it remains present i.e. that it is a priority to fix this." >> "From my exp long labels tend not to be used and no, JIRA suggestions do not help. I'll be happy to see a positive short label." >> >> A label like "urgent" or "fix-urgent" would satisfy these aspects, but after some mulling over this I concluded that these are too generic and could be placed on any P1 bug. I wanted to capture the developer/maintainer aspect as well, not just that a bug is critical to fix. So comments like: >> >> "Rather than make it specific to 'dev' or 'developers', perhaps..." >> ... "This suggests labels that include the token ?maintainer.?" >> "...this thread started with a desire to draw attention to pain (rather than opportunity)" >> >> make me think that the best suggestion so far is maintainer-pain. > Works for me! > > Cheers, > Mikael > Also works for me. Dan From zhangbodut at gmail.com Tue Sep 25 01:01:06 2018 From: zhangbodut at gmail.com (Bo Zhang) Date: Tue, 25 Sep 2018 09:01:06 +0800 Subject: [PATCH] 8210810: Incorrect argument file parser behavior in certain cases Message-ID: <248AD6DC-E6B2-41C5-8E15-578D361796D3@gmail.com> Hi all, This is my first time to try to submit a patch. Please forgive me if I did anything inappropriate. I?ve signed OCA. Bug description: 8210810 : Incorrect argument file parser behavior in certain cases Previously, if a quoted backslash character appears at argument file parser buffer boundary (i.e. 4096th/8192nd/... character of an argument file is backslash '\'), the segment before the backslash character will be added into argument twice due to a missing anchor position reset operation. For example, you have an argument file: -cp "...a\\b" and the 4096th and 4097th characters happen to be both '\', the result generated by the argument file parser would be: -cp "...aa\\b? This patch fixes the issue by resetting anchor position correctly in this case. I?m a little surprised that this issue has existed for several years unnoticed. Patch: # HG changeset patch # User Bo Zhang # Date 1537835887 -28800 # Tue Sep 25 08:38:07 2018 +0800 # Node ID 34f2803ad62cde8c82e3dfcf0b66e80276bd7352 # Parent 16f0deae8fa6ef85f7230308e1fe7556bd007c39 8210810: Incorrect argument file parser behavior in certain cases Previously, if a quoted backslash character appears at argument file parser buffer boundary (i.e. 4096th/8192nd/... character of an argument file is backslash '\'), the segment before the backslash character will be added into argument twice due to a missing anchor position reset operation. For example, you have an argument file: -cp "...a\\b" and the 4096th and 4097th characters happen to be both '\', the result generated by the argument file parser would be: -cp "...aa\\b" This patch fixes the issue by resetting anchor position correctly in this case. diff --git a/src/java.base/share/native/libjli/args.c b/src/java.base/share/native/libjli/args.c --- a/src/java.base/share/native/libjli/args.c +++ b/src/java.base/share/native/libjli/args.c @@ -262,6 +262,8 @@ continue; } JLI_List_addSubstring(pctx->parts, anchor, nextc - anchor); + // anchor after backslash character + anchor = nextc + 1; pctx->state = IN_ESCAPE; break; case '\'': diff --git a/test/jdk/tools/launcher/Test8210810.java b/test/jdk/tools/launcher/Test8210810.java new file mode 100644 --- /dev/null +++ b/test/jdk/tools/launcher/Test8210810.java @@ -0,0 +1,107 @@ +/* + * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * @test + * @bug 8210810 + * @summary Incorrect argument file parser behavior when backslash appears at buffer boundary + * @modules java.base + * @author Bo Zhang + * @build TestHelper + * @run main Test8210810 + */ + +/* + * 8210810: Previously, if a quoted backslash character appears at argument file + * parser buffer boundary (i.e. 4096th/8192nd/... character of an argument + * file is backslash '\'), the segment before the backslash character will + * be added into argument twice due to a missing anchor position reset + * operation. This test creates a special argument file which can reproduce this issue. + */ +import java.io.File; +import java.nio.file.Files; +import java.io.IOException; +import java.util.Arrays; + +public class Test8210810 extends TestHelper { + // Buffer size in args.c readArgFile() method + private static final int ARG_FILE_PARSER_BUF_SIZE = 4096; + public static void main(String... args) throws Exception { + new Test8210810().canParseArgFileCorrectly(); + } + + private void canParseArgFileCorrectly() throws IOException { + File testJar = createTestClassWhichPrintsClasspath(); + File argFile = createArgFileWithSpecificClasspath(); + TestResult result = doExec(javaCmd, "@argFile", "Foo"); + + long zCountInArgFile = countZ(new String(Files.readAllBytes(argFile.toPath()))); + long zCountReadByParser = countZ(result.testOutput.get(0)); + if(zCountInArgFile != zCountReadByParser) { + throw new RuntimeException("Classpath parsed by parser is different from argument file!"); + } + + testJar.delete(); + argFile.delete(); + } + + private long countZ(String str) { + return str.chars().filter(ch -> ch == 'z').count(); + } + + private File createTestClassWhichPrintsClasspath() throws IOException { + File testJar = new File("test.jar"); + testJar.delete(); + + StringBuilder tsrc = new StringBuilder(); + tsrc.append("public static void main(String... args) {\n"); + tsrc.append(" System.out.println(\"Classpath:\" + System.getProperty(\"java.class.path\"));\n"); + tsrc.append("}\n"); + createJar(testJar, new File("Foo"), tsrc.toString()); + return testJar; + } + + // Create a file whose 4096th and 4097th characters are both '\' (backslash) + // File content: + // |-cp "test.jar:zzzzz...zzz\\"| + private File createArgFileWithSpecificClasspath() throws IOException { + File argFile = new File("argFile"); + argFile.delete(); + + StringBuilder arg = new StringBuilder("-cp \"test.jar"); + arg.append(File.pathSeparator); + + int fillingCharactersCount = ARG_FILE_PARSER_BUF_SIZE - 1 - arg.length(); + + for(int i = 0; i < fillingCharactersCount; ++i) { + arg.append('z'); + } + + arg.append('\\'); // 4096th character in the arg file + arg.append('\\'); // 4097th character in the arg file + arg.append('"'); + + createAFile(argFile, Arrays.asList(arg.toString())); + return argFile; + } +} Unit test: Included in the patch. It creates a special argument file whose 4096th and 4097th characters are both ?\?. Then it compares the classpath read in the VM and the classpath in the argument file to verify they?re identical. From Alan.Bateman at oracle.com Tue Sep 25 06:19:12 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 25 Sep 2018 07:19:12 +0100 Subject: [PATCH] 8210810: Incorrect argument file parser behavior in certain cases In-Reply-To: <248AD6DC-E6B2-41C5-8E15-578D361796D3@gmail.com> References: <248AD6DC-E6B2-41C5-8E15-578D361796D3@gmail.com> Message-ID: On 25/09/2018 02:01, Bo Zhang wrote: > Hi all, > > This is my first time to try to submit a patch. Please forgive me if I did anything inappropriate. I?ve signed OCA. > > Bug description: > > 8210810 : Incorrect argument file parser behavior in certain cases > > Previously, if a quoted backslash character appears at argument file > parser buffer boundary (i.e. 4096th/8192nd/... character of an argument > file is backslash '\'), the segment before the backslash character will > be added into argument twice due to a missing anchor position reset > operation. > > For example, you have an argument file: > > -cp "...a\\b" > > and the 4096th and 4097th characters happen to be both '\', the result > generated by the argument file parser would be: > > -cp "...aa\\b? > > This patch fixes the issue by resetting anchor position correctly > in this case. > > I?m a little surprised that this issue has existed for several years unnoticed. The java launcher support for @argument files is new since JDK 9 so it's possible this case with quoting wasn't noticed before. It would be good to get that fixed. Can you bring this to core-libs-dev for discussion as that is where issues with the java launcher are discussed? Also can you include the name that you used when signing the OCA in case it is different to the name in your mail address. -Alan From zhangbodut at gmail.com Tue Sep 25 06:21:44 2018 From: zhangbodut at gmail.com (Bo Zhang) Date: Tue, 25 Sep 2018 14:21:44 +0800 Subject: [PATCH] 8210810: Incorrect argument file parser behavior in certain cases In-Reply-To: References: <248AD6DC-E6B2-41C5-8E15-578D361796D3@gmail.com> Message-ID: Thank you very much for the guidance, will do. > On 25 Sep 2018, at 14:19, Alan Bateman wrote: > > On 25/09/2018 02:01, Bo Zhang wrote: >> Hi all, >> >> This is my first time to try to submit a patch. Please forgive me if I did anything inappropriate. I?ve signed OCA. >> >> Bug description: >> >> 8210810 : Incorrect argument file parser behavior in certain cases >> >> Previously, if a quoted backslash character appears at argument file >> parser buffer boundary (i.e. 4096th/8192nd/... character of an argument >> file is backslash '\'), the segment before the backslash character will >> be added into argument twice due to a missing anchor position reset >> operation. >> >> For example, you have an argument file: >> >> -cp "...a\\b" >> >> and the 4096th and 4097th characters happen to be both '\', the result >> generated by the argument file parser would be: >> >> -cp "...aa\\b? >> >> This patch fixes the issue by resetting anchor position correctly >> in this case. >> >> I?m a little surprised that this issue has existed for several years unnoticed. > The java launcher support for @argument files is new since JDK 9 so it's possible this case with quoting wasn't noticed before. It would be good to get that fixed. > > Can you bring this to core-libs-dev for discussion as that is where issues with the java launcher are discussed? Also can you include the name that you used when signing the OCA in case it is different to the name in your mail address. > > -Alan From mark.reinhold at oracle.com Tue Sep 25 17:23:51 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 25 Sep 2018 10:23:51 -0700 (PDT) Subject: Java 11 / JDK 11: General Availability Message-ID: <20180925172351.3D45420AB8B@eggemoggin.niobe.net> JDK 11, the reference implementation of Java 11 and the first long-term support release produced under the six-month rapid-cadence release model [1][2], is now Generally Available. We've identified no P1 bugs since we promoted build 28 over four weeks ago so that?s the official GA release, ready for production use. GPL-licensed OpenJDK builds from Oracle are available here: https://jdk.java.net/11 Builds from other implementors will no doubt be available soon. This release includes seventeen features [3]: 181: Nest-Based Access Control 309: Dynamic Class-File Constants 315: Improve Aarch64 Intrinsics 318: Epsilon: A No-Op Garbage Collector (Experimental) 320: Remove the Java EE and CORBA Modules 321: HTTP Client (Standard) 323: Local-Variable Syntax for Lambda Parameters 324: Key Agreement with Curve25519 and Curve448 327: Unicode 10 328: Flight Recorder 329: ChaCha20 & Poly1305 Cryptographic Algorithms 330: Launch Single-File Source-Code Programs 331: Low-Overhead Heap Profiling 332: Transport Layer Security (TLS) 1.3 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental) 335: Deprecate the Nashorn JavaScript Engine 336: Deprecate the Pack200 Tools and API along with, of course, hundreds of smaller enhancements and countless bug fixes. Thanks to everyone who contributed JDK 11, whether by creating features or enhancements, removing old features, fixing bugs, or downloading and testing the early-access builds. Onward, to JDK 12! - Mark [1] https://mreinhold.org/blog/forward-faster [2] https://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html [3] https://openjdk.java.net/projects/jdk/11 From aph at redhat.com Wed Sep 26 15:51:43 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 26 Sep 2018 16:51:43 +0100 Subject: RFR: 8211163: UNIX version of Java_java_io_Console_echo does not return a clean boolean Message-ID: Java_java_io_Console_echo looks like this: JNIEXPORT jboolean JNICALL Java_java_io_Console_echo(JNIEnv *env, jclass cls, jboolean on) { DWORD fdwMode; jboolean old; ... old = (fdwMode & ENABLE_ECHO_INPUT); ... return old; } It only works by accident. jboolean is an unsigned byte. ENABLE_ECHO_INPUT on the systems I know of is 0000010, so fdwMode & ENABLE_ECHO_INPUT fits into the result, but only by accident. We should do things properly and return a clean boolean. Note that the Windows version of the code is correct: I assume the UNIX version is an oversight. https://bugs.openjdk.java.net/browse/JDK-8211163 http://cr.openjdk.java.net/~aph/8211163/ OK? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Alan.Bateman at oracle.com Wed Sep 26 15:58:21 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 26 Sep 2018 16:58:21 +0100 Subject: RFR: 8211163: UNIX version of Java_java_io_Console_echo does not return a clean boolean In-Reply-To: References: Message-ID: <222e6c1c-b946-7bf7-8eab-08a89622a4f1@oracle.com> On 26/09/2018 16:51, Andrew Haley wrote: > Java_java_io_Console_echo looks like this: > > JNIEXPORT jboolean JNICALL > Java_java_io_Console_echo(JNIEnv *env, jclass cls, jboolean on) > { > DWORD fdwMode; > jboolean old; > ... > old = (fdwMode & ENABLE_ECHO_INPUT); > ... > return old; > } > > It only works by accident. jboolean is an unsigned byte. > ENABLE_ECHO_INPUT on the systems I know of is 0000010, so fdwMode & > ENABLE_ECHO_INPUT fits into the result, but only by accident. We > should do things properly and return a clean boolean. > > Note that the Windows version of the code is correct: I assume the > UNIX version is an oversight. > > https://bugs.openjdk.java.net/browse/JDK-8211163 > http://cr.openjdk.java.net/~aph/8211163/ > > OK? Probably better to bring this to core-libs-dev as I think it's the same issue as this thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-July/054479.html I can't see a conclusion (as in change-set) but Ichiroh's second mail has the same patch as you. -Alan From ashipile at redhat.com Wed Sep 26 15:58:47 2018 From: ashipile at redhat.com (Aleksey Shipilev) Date: Wed, 26 Sep 2018 17:58:47 +0200 Subject: RFR: 8211163: UNIX version of Java_java_io_Console_echo does not return a clean boolean In-Reply-To: References: Message-ID: <3a5b6f71-34d6-2242-3070-05c0ce9215f0@redhat.com> On 09/26/2018 05:51 PM, Andrew Haley wrote: > https://bugs.openjdk.java.net/browse/JDK-8211163 > http://cr.openjdk.java.net/~aph/8211163/ Patch looks good, I suggested the same fix earlier, and thought Sherman would handle it: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054910.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054911.html I think this RFR should be reviewed on core-libs-dev@ though. -Aleksey From aph at redhat.com Wed Sep 26 16:37:24 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 26 Sep 2018 17:37:24 +0100 Subject: RFR: 8211163: UNIX version of Java_java_io_Console_echo does not return a clean boolean In-Reply-To: <3a5b6f71-34d6-2242-3070-05c0ce9215f0@redhat.com> References: <3a5b6f71-34d6-2242-3070-05c0ce9215f0@redhat.com> Message-ID: <64531bbf-ba9d-c7b2-a136-5b9c97b22a4f@redhat.com> On 09/26/2018 04:58 PM, Aleksey Shipilev wrote: > Patch looks good, I suggested the same fix earlier, and thought Sherman would handle it: Right, but nobody seems to have noticed that it only works by accident. Whether it's legal to return a value outside the set of {0, 1} doesn't much matter IMO, it's *still* *wrong*. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From jesper.wilhelmsson at oracle.com Thu Sep 27 16:05:54 2018 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Thu, 27 Sep 2018 18:05:54 +0200 Subject: CFV: New JDK Reviewer: Jini George Message-ID: <3C834F7A-6B22-41F5-B78A-B673FE917F71@oracle.com> I hearby nominate Jini George (jgeorge) to JDK Project Reviewer. Jini has made 37 contributions in the JDK [3], many in the Serviceability Agent which is an area that for a long time was lacking active contributors. Jini's work in the SA is highly appreciated. Votes are due by 18:00 CET October 11, 2018. Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [2]. Thanks, /Jesper [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#reviewer-vote [3] List of contributions: (1) 8210836: Build fails with warn_unused_result in openjdk/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c http://hg.openjdk.java.net/jdk/jdk/rev/c0f9161f591e (2) 8204308: SA: serviceability/sa/TestInstanceKlassSize*.java fails when running in CDS mode http://hg.openjdk.java.net/jdk/jdk/rev/948c62200f8c (3) 8189429: SA: MacOSX: Replace the deprecated PT_ATTACH with PT_ATTACHEXC http://hg.openjdk.java.net/jdk/jdk/rev/e46b9e514479 (4) 8195613: [SA] HotSpotTypeDataBase.readVMLongConstants truncates values to int http://hg.openjdk.java.net/jdk/jdk/rev/300e4a88c400 (5) 8174995: SA: clhsdb 'where -a' throws Assertion Failure with illegal code 236 when CDS is used http://hg.openjdk.java.net/jdk/jdk/rev/55153a374d18 (6) 8174994: SA: clhsdb printmdo throws WrongTypeException when attached to a process with CDS http://hg.openjdk.java.net/jdk/jdk/rev/ec2dd30adbc1 (7) 8175312: SA: clhsdb: Provide an improved heap summary for 'universe' for G1GC http://hg.openjdk.java.net/jdk/jdk/rev/ccb003941743 (8) 8175384: SA: clhsdb 'printall' throws ClassCastException while printing out the bytecodes http://hg.openjdk.java.net/jdk/jdk/rev/d2a860bc50a3 (9) 8193352: SA: Test for the clhsdb 'thread' and 'threads' commands http://hg.openjdk.java.net/jdk/jdk/rev/fdef4da95080 (10) 8192985: SA: Test cases for the clhsdb 'inspect', 'scanoops' and 'printas' commands http://hg.openjdk.java.net/jdk/jdk/rev/be065f758154 (11) 8191538: SA: tests for clhsdb commands: vmstructsdump, field, symboltable and symbol http://hg.openjdk.java.net/jdk/jdk/rev/61a14b5cb1c6 (12) 8191914: New SA test timeout on windows http://hg.openjdk.java.net/jdk/jdk/rev/88ec5fca7726 (13) 8191324: SA cleanup -- part 2 http://hg.openjdk.java.net/jdk/jdk/rev/2659c4fe8ea7 (14) 8191961: SA: Remove left over quarantined SA tests due to 8184042 from ProblemList.txt http://hg.openjdk.java.net/jdk/jdk/rev/111834dd10dd (15) 8191919: Include TestJhsdbJstackLock.java in ProblemList.txt http://hg.openjdk.java.net/jdk/jdk/rev/d851eb254409 (16) 8190307: SA tests for the clhsdb commands: universe, intconstant, type http://hg.openjdk.java.net/jdk/jdk/rev/75d365bfc2e6 (17) 8189798: SA cleanup - part 1 http://hg.openjdk.java.net/jdk/jdk/rev/ac0af7750da9 (18) 8184042: several serviceability/sa tests timed out on MacOS X http://hg.openjdk.java.net/jdk/jdk/rev/dfb375d231fb (19) 8175512: new TestPrintMdo.java fails with -XX:TieredStopAtLevel=1 http://hg.openjdk.java.net/jdk/jdk/rev/deab1e2f0ebf (20) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client http://hg.openjdk.java.net/jdk/jdk/rev/2eab88a780e3 (21) 8162504: TestInstanceKlassSize.java and TestInstanceKlassSizeForInterface.java fail on Mac OS http://hg.openjdk.java.net/jdk/jdk/rev/4597fa06b227 (22) 8175054: Move new TestPrintMdo.java to hotspot/test directory http://hg.openjdk.java.net/jdk/jdk/rev/d9ba85f5cb9d (23) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client http://hg.openjdk.java.net/jdk/jdk/rev/c809fcb66c81 (24) 8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow http://hg.openjdk.java.net/jdk/jdk/rev/a152f2d3320e (25) 8159127: hprof heap dumps broken for lambda classdata http://hg.openjdk.java.net/jdk/jdk/rev/0b0ae99d8639 http://hg.openjdk.java.net/jdk/jdk/rev/297ba2772122 (26) 8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1 http://hg.openjdk.java.net/jdk/jdk/rev/48d874bf85fb (27) 8169638: serviceability/sa/TestInstanceKlassSize.java and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation http://hg.openjdk.java.net/jdk/jdk/rev/a20695c30be5 (28) 8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c http://hg.openjdk.java.net/jdk/jdk/rev/154099b110df (29) 7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test http://hg.openjdk.java.net/jdk/jdk/rev/815cfbe4878b (30) 8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure http://hg.openjdk.java.net/jdk/jdk/rev/afd6ae4fec81 (31) 8164383: jhsdb dumps core on Solaris 12 when loading dumped core http://hg.openjdk.java.net/jdk/jdk/rev/10e6e31dc1aa (32) 8166552: SA: Missed testcase for add default methods to InstanceKlass http://hg.openjdk.java.net/jdk/jdk/rev/815650daefb4 (33) 8027920: SA: Add default methods to InstanceKlass http://hg.openjdk.java.net/jdk/jdk/rev/aed0f6434aea (34) 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" http://hg.openjdk.java.net/jdk/jdk/rev/c0e02245ff93 http://hg.openjdk.java.net/jdk/jdk/rev/12787d18650e (35) 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE http://hg.openjdk.java.net/jdk/jdk/rev/adf083cbc37f (36) 8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames http://hg.openjdk.java.net/jdk/jdk/rev/8a2083c5e2b1 http://hg.openjdk.java.net/jdk/jdk/rev/d46cac7959c4 (37) 8145627: sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test http://hg.openjdk.java.net/jdk/jdk/rev/82ece130a37b From thomas.stuefe at gmail.com Thu Sep 27 19:07:19 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 27 Sep 2018 21:07:19 +0200 Subject: CFV: New JDK Reviewer: Jini George In-Reply-To: <3C834F7A-6B22-41F5-B78A-B673FE917F71@oracle.com> References: <3C834F7A-6B22-41F5-B78A-B673FE917F71@oracle.com> Message-ID: Vote: yes. On Thu, Sep 27, 2018 at 6:05 PM, wrote: > I hearby nominate Jini George (jgeorge) to JDK Project Reviewer. > > Jini has made 37 contributions in the JDK [3], many in the Serviceability Agent which is an area that for a long time was lacking active contributors. Jini's work in the SA is highly appreciated. > > Votes are due by 18:00 CET October 11, 2018. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] List of contributions: > > (1) 8210836: Build fails with warn_unused_result in openjdk/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c > http://hg.openjdk.java.net/jdk/jdk/rev/c0f9161f591e > > (2) 8204308: SA: serviceability/sa/TestInstanceKlassSize*.java fails when running in CDS mode > http://hg.openjdk.java.net/jdk/jdk/rev/948c62200f8c > > (3) 8189429: SA: MacOSX: Replace the deprecated PT_ATTACH with PT_ATTACHEXC > http://hg.openjdk.java.net/jdk/jdk/rev/e46b9e514479 > > (4) 8195613: [SA] HotSpotTypeDataBase.readVMLongConstants truncates values to int > http://hg.openjdk.java.net/jdk/jdk/rev/300e4a88c400 > > (5) 8174995: SA: clhsdb 'where -a' throws Assertion Failure with illegal code 236 when CDS is used > http://hg.openjdk.java.net/jdk/jdk/rev/55153a374d18 > > (6) 8174994: SA: clhsdb printmdo throws WrongTypeException when attached to a process with CDS > http://hg.openjdk.java.net/jdk/jdk/rev/ec2dd30adbc1 > > (7) 8175312: SA: clhsdb: Provide an improved heap summary for 'universe' for G1GC > http://hg.openjdk.java.net/jdk/jdk/rev/ccb003941743 > > (8) 8175384: SA: clhsdb 'printall' throws ClassCastException while printing out the bytecodes > http://hg.openjdk.java.net/jdk/jdk/rev/d2a860bc50a3 > > (9) 8193352: SA: Test for the clhsdb 'thread' and 'threads' commands > http://hg.openjdk.java.net/jdk/jdk/rev/fdef4da95080 > > (10) 8192985: SA: Test cases for the clhsdb 'inspect', 'scanoops' and 'printas' commands > http://hg.openjdk.java.net/jdk/jdk/rev/be065f758154 > > (11) 8191538: SA: tests for clhsdb commands: vmstructsdump, field, symboltable and symbol > http://hg.openjdk.java.net/jdk/jdk/rev/61a14b5cb1c6 > > (12) 8191914: New SA test timeout on windows > http://hg.openjdk.java.net/jdk/jdk/rev/88ec5fca7726 > > (13) 8191324: SA cleanup -- part 2 > http://hg.openjdk.java.net/jdk/jdk/rev/2659c4fe8ea7 > > (14) 8191961: SA: Remove left over quarantined SA tests due to 8184042 from ProblemList.txt > http://hg.openjdk.java.net/jdk/jdk/rev/111834dd10dd > > (15) 8191919: Include TestJhsdbJstackLock.java in ProblemList.txt > http://hg.openjdk.java.net/jdk/jdk/rev/d851eb254409 > > (16) 8190307: SA tests for the clhsdb commands: universe, intconstant, type > http://hg.openjdk.java.net/jdk/jdk/rev/75d365bfc2e6 > > (17) 8189798: SA cleanup - part 1 > http://hg.openjdk.java.net/jdk/jdk/rev/ac0af7750da9 > > (18) 8184042: several serviceability/sa tests timed out on MacOS X > http://hg.openjdk.java.net/jdk/jdk/rev/dfb375d231fb > > (19) 8175512: new TestPrintMdo.java fails with -XX:TieredStopAtLevel=1 > http://hg.openjdk.java.net/jdk/jdk/rev/deab1e2f0ebf > > (20) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client > http://hg.openjdk.java.net/jdk/jdk/rev/2eab88a780e3 > > (21) 8162504: TestInstanceKlassSize.java and TestInstanceKlassSizeForInterface.java fail on Mac OS > http://hg.openjdk.java.net/jdk/jdk/rev/4597fa06b227 > > (22) 8175054: Move new TestPrintMdo.java to hotspot/test directory > http://hg.openjdk.java.net/jdk/jdk/rev/d9ba85f5cb9d > > (23) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client > http://hg.openjdk.java.net/jdk/jdk/rev/c809fcb66c81 > > (24) 8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow > http://hg.openjdk.java.net/jdk/jdk/rev/a152f2d3320e > > (25) 8159127: hprof heap dumps broken for lambda classdata > http://hg.openjdk.java.net/jdk/jdk/rev/0b0ae99d8639 > http://hg.openjdk.java.net/jdk/jdk/rev/297ba2772122 > > (26) 8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1 > http://hg.openjdk.java.net/jdk/jdk/rev/48d874bf85fb > > (27) 8169638: serviceability/sa/TestInstanceKlassSize.java and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation > http://hg.openjdk.java.net/jdk/jdk/rev/a20695c30be5 > > (28) 8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c > http://hg.openjdk.java.net/jdk/jdk/rev/154099b110df > > (29) 7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test > http://hg.openjdk.java.net/jdk/jdk/rev/815cfbe4878b > > (30) 8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure > http://hg.openjdk.java.net/jdk/jdk/rev/afd6ae4fec81 > > (31) 8164383: jhsdb dumps core on Solaris 12 when loading dumped core > http://hg.openjdk.java.net/jdk/jdk/rev/10e6e31dc1aa > > (32) 8166552: SA: Missed testcase for add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk/jdk/rev/815650daefb4 > > (33) 8027920: SA: Add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk/jdk/rev/aed0f6434aea > > (34) 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" > http://hg.openjdk.java.net/jdk/jdk/rev/c0e02245ff93 > http://hg.openjdk.java.net/jdk/jdk/rev/12787d18650e > > (35) 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE > http://hg.openjdk.java.net/jdk/jdk/rev/adf083cbc37f > > (36) 8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames > http://hg.openjdk.java.net/jdk/jdk/rev/8a2083c5e2b1 > http://hg.openjdk.java.net/jdk/jdk/rev/d46cac7959c4 > > (37) 8145627: sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test > http://hg.openjdk.java.net/jdk/jdk/rev/82ece130a37b > From chris.plummer at oracle.com Thu Sep 27 19:46:02 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 27 Sep 2018 12:46:02 -0700 Subject: CFV: New JDK Reviewer: Jini George In-Reply-To: <3C834F7A-6B22-41F5-B78A-B673FE917F71@oracle.com> References: <3C834F7A-6B22-41F5-B78A-B673FE917F71@oracle.com> Message-ID: Vote: yes On 9/27/18 9:05 AM, jesper.wilhelmsson at oracle.com wrote: > I hearby nominate Jini George (jgeorge) to JDK Project Reviewer. > > Jini has made 37 contributions in the JDK [3], many in the Serviceability Agent which is an area that for a long time was lacking active contributors. Jini's work in the SA is highly appreciated. > > Votes are due by 18:00 CET October 11, 2018. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] List of contributions: > > (1) 8210836: Build fails with warn_unused_result in openjdk/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c > http://hg.openjdk.java.net/jdk/jdk/rev/c0f9161f591e > > (2) 8204308: SA: serviceability/sa/TestInstanceKlassSize*.java fails when running in CDS mode > http://hg.openjdk.java.net/jdk/jdk/rev/948c62200f8c > > (3) 8189429: SA: MacOSX: Replace the deprecated PT_ATTACH with PT_ATTACHEXC > http://hg.openjdk.java.net/jdk/jdk/rev/e46b9e514479 > > (4) 8195613: [SA] HotSpotTypeDataBase.readVMLongConstants truncates values to int > http://hg.openjdk.java.net/jdk/jdk/rev/300e4a88c400 > > (5) 8174995: SA: clhsdb 'where -a' throws Assertion Failure with illegal code 236 when CDS is used > http://hg.openjdk.java.net/jdk/jdk/rev/55153a374d18 > > (6) 8174994: SA: clhsdb printmdo throws WrongTypeException when attached to a process with CDS > http://hg.openjdk.java.net/jdk/jdk/rev/ec2dd30adbc1 > > (7) 8175312: SA: clhsdb: Provide an improved heap summary for 'universe' for G1GC > http://hg.openjdk.java.net/jdk/jdk/rev/ccb003941743 > > (8) 8175384: SA: clhsdb 'printall' throws ClassCastException while printing out the bytecodes > http://hg.openjdk.java.net/jdk/jdk/rev/d2a860bc50a3 > > (9) 8193352: SA: Test for the clhsdb 'thread' and 'threads' commands > http://hg.openjdk.java.net/jdk/jdk/rev/fdef4da95080 > > (10) 8192985: SA: Test cases for the clhsdb 'inspect', 'scanoops' and 'printas' commands > http://hg.openjdk.java.net/jdk/jdk/rev/be065f758154 > > (11) 8191538: SA: tests for clhsdb commands: vmstructsdump, field, symboltable and symbol > http://hg.openjdk.java.net/jdk/jdk/rev/61a14b5cb1c6 > > (12) 8191914: New SA test timeout on windows > http://hg.openjdk.java.net/jdk/jdk/rev/88ec5fca7726 > > (13) 8191324: SA cleanup -- part 2 > http://hg.openjdk.java.net/jdk/jdk/rev/2659c4fe8ea7 > > (14) 8191961: SA: Remove left over quarantined SA tests due to 8184042 from ProblemList.txt > http://hg.openjdk.java.net/jdk/jdk/rev/111834dd10dd > > (15) 8191919: Include TestJhsdbJstackLock.java in ProblemList.txt > http://hg.openjdk.java.net/jdk/jdk/rev/d851eb254409 > > (16) 8190307: SA tests for the clhsdb commands: universe, intconstant, type > http://hg.openjdk.java.net/jdk/jdk/rev/75d365bfc2e6 > > (17) 8189798: SA cleanup - part 1 > http://hg.openjdk.java.net/jdk/jdk/rev/ac0af7750da9 > > (18) 8184042: several serviceability/sa tests timed out on MacOS X > http://hg.openjdk.java.net/jdk/jdk/rev/dfb375d231fb > > (19) 8175512: new TestPrintMdo.java fails with -XX:TieredStopAtLevel=1 > http://hg.openjdk.java.net/jdk/jdk/rev/deab1e2f0ebf > > (20) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client > http://hg.openjdk.java.net/jdk/jdk/rev/2eab88a780e3 > > (21) 8162504: TestInstanceKlassSize.java and TestInstanceKlassSizeForInterface.java fail on Mac OS > http://hg.openjdk.java.net/jdk/jdk/rev/4597fa06b227 > > (22) 8175054: Move new TestPrintMdo.java to hotspot/test directory > http://hg.openjdk.java.net/jdk/jdk/rev/d9ba85f5cb9d > > (23) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client > http://hg.openjdk.java.net/jdk/jdk/rev/c809fcb66c81 > > (24) 8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow > http://hg.openjdk.java.net/jdk/jdk/rev/a152f2d3320e > > (25) 8159127: hprof heap dumps broken for lambda classdata > http://hg.openjdk.java.net/jdk/jdk/rev/0b0ae99d8639 > http://hg.openjdk.java.net/jdk/jdk/rev/297ba2772122 > > (26) 8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1 > http://hg.openjdk.java.net/jdk/jdk/rev/48d874bf85fb > > (27) 8169638: serviceability/sa/TestInstanceKlassSize.java and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation > http://hg.openjdk.java.net/jdk/jdk/rev/a20695c30be5 > > (28) 8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c > http://hg.openjdk.java.net/jdk/jdk/rev/154099b110df > > (29) 7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test > http://hg.openjdk.java.net/jdk/jdk/rev/815cfbe4878b > > (30) 8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure > http://hg.openjdk.java.net/jdk/jdk/rev/afd6ae4fec81 > > (31) 8164383: jhsdb dumps core on Solaris 12 when loading dumped core > http://hg.openjdk.java.net/jdk/jdk/rev/10e6e31dc1aa > > (32) 8166552: SA: Missed testcase for add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk/jdk/rev/815650daefb4 > > (33) 8027920: SA: Add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk/jdk/rev/aed0f6434aea > > (34) 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" > http://hg.openjdk.java.net/jdk/jdk/rev/c0e02245ff93 > http://hg.openjdk.java.net/jdk/jdk/rev/12787d18650e > > (35) 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE > http://hg.openjdk.java.net/jdk/jdk/rev/adf083cbc37f > > (36) 8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames > http://hg.openjdk.java.net/jdk/jdk/rev/8a2083c5e2b1 > http://hg.openjdk.java.net/jdk/jdk/rev/d46cac7959c4 > > (37) 8145627: sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test > http://hg.openjdk.java.net/jdk/jdk/rev/82ece130a37b > From yasuenag at gmail.com Thu Sep 27 22:23:29 2018 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 28 Sep 2018 07:23:29 +0900 Subject: CFV: New JDK Reviewer: Jini George In-Reply-To: <3C834F7A-6B22-41F5-B78A-B673FE917F71@oracle.com> References: <3C834F7A-6B22-41F5-B78A-B673FE917F71@oracle.com> Message-ID: Vote: yes On 2018/09/28 1:05, jesper.wilhelmsson at oracle.com wrote: > I hearby nominate Jini George (jgeorge) to JDK Project Reviewer. > > Jini has made 37 contributions in the JDK [3], many in the Serviceability Agent which is an area that for a long time was lacking active contributors. Jini's work in the SA is highly appreciated. > > Votes are due by 18:00 CET October 11, 2018. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] List of contributions: > > (1) 8210836: Build fails with warn_unused_result in openjdk/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c > http://hg.openjdk.java.net/jdk/jdk/rev/c0f9161f591e > > (2) 8204308: SA: serviceability/sa/TestInstanceKlassSize*.java fails when running in CDS mode > http://hg.openjdk.java.net/jdk/jdk/rev/948c62200f8c > > (3) 8189429: SA: MacOSX: Replace the deprecated PT_ATTACH with PT_ATTACHEXC > http://hg.openjdk.java.net/jdk/jdk/rev/e46b9e514479 > > (4) 8195613: [SA] HotSpotTypeDataBase.readVMLongConstants truncates values to int > http://hg.openjdk.java.net/jdk/jdk/rev/300e4a88c400 > > (5) 8174995: SA: clhsdb 'where -a' throws Assertion Failure with illegal code 236 when CDS is used > http://hg.openjdk.java.net/jdk/jdk/rev/55153a374d18 > > (6) 8174994: SA: clhsdb printmdo throws WrongTypeException when attached to a process with CDS > http://hg.openjdk.java.net/jdk/jdk/rev/ec2dd30adbc1 > > (7) 8175312: SA: clhsdb: Provide an improved heap summary for 'universe' for G1GC > http://hg.openjdk.java.net/jdk/jdk/rev/ccb003941743 > > (8) 8175384: SA: clhsdb 'printall' throws ClassCastException while printing out the bytecodes > http://hg.openjdk.java.net/jdk/jdk/rev/d2a860bc50a3 > > (9) 8193352: SA: Test for the clhsdb 'thread' and 'threads' commands > http://hg.openjdk.java.net/jdk/jdk/rev/fdef4da95080 > > (10) 8192985: SA: Test cases for the clhsdb 'inspect', 'scanoops' and 'printas' commands > http://hg.openjdk.java.net/jdk/jdk/rev/be065f758154 > > (11) 8191538: SA: tests for clhsdb commands: vmstructsdump, field, symboltable and symbol > http://hg.openjdk.java.net/jdk/jdk/rev/61a14b5cb1c6 > > (12) 8191914: New SA test timeout on windows > http://hg.openjdk.java.net/jdk/jdk/rev/88ec5fca7726 > > (13) 8191324: SA cleanup -- part 2 > http://hg.openjdk.java.net/jdk/jdk/rev/2659c4fe8ea7 > > (14) 8191961: SA: Remove left over quarantined SA tests due to 8184042 from ProblemList.txt > http://hg.openjdk.java.net/jdk/jdk/rev/111834dd10dd > > (15) 8191919: Include TestJhsdbJstackLock.java in ProblemList.txt > http://hg.openjdk.java.net/jdk/jdk/rev/d851eb254409 > > (16) 8190307: SA tests for the clhsdb commands: universe, intconstant, type > http://hg.openjdk.java.net/jdk/jdk/rev/75d365bfc2e6 > > (17) 8189798: SA cleanup - part 1 > http://hg.openjdk.java.net/jdk/jdk/rev/ac0af7750da9 > > (18) 8184042: several serviceability/sa tests timed out on MacOS X > http://hg.openjdk.java.net/jdk/jdk/rev/dfb375d231fb > > (19) 8175512: new TestPrintMdo.java fails with -XX:TieredStopAtLevel=1 > http://hg.openjdk.java.net/jdk/jdk/rev/deab1e2f0ebf > > (20) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client > http://hg.openjdk.java.net/jdk/jdk/rev/2eab88a780e3 > > (21) 8162504: TestInstanceKlassSize.java and TestInstanceKlassSizeForInterface.java fail on Mac OS > http://hg.openjdk.java.net/jdk/jdk/rev/4597fa06b227 > > (22) 8175054: Move new TestPrintMdo.java to hotspot/test directory > http://hg.openjdk.java.net/jdk/jdk/rev/d9ba85f5cb9d > > (23) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client > http://hg.openjdk.java.net/jdk/jdk/rev/c809fcb66c81 > > (24) 8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow > http://hg.openjdk.java.net/jdk/jdk/rev/a152f2d3320e > > (25) 8159127: hprof heap dumps broken for lambda classdata > http://hg.openjdk.java.net/jdk/jdk/rev/0b0ae99d8639 > http://hg.openjdk.java.net/jdk/jdk/rev/297ba2772122 > > (26) 8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1 > http://hg.openjdk.java.net/jdk/jdk/rev/48d874bf85fb > > (27) 8169638: serviceability/sa/TestInstanceKlassSize.java and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation > http://hg.openjdk.java.net/jdk/jdk/rev/a20695c30be5 > > (28) 8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c > http://hg.openjdk.java.net/jdk/jdk/rev/154099b110df > > (29) 7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test > http://hg.openjdk.java.net/jdk/jdk/rev/815cfbe4878b > > (30) 8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure > http://hg.openjdk.java.net/jdk/jdk/rev/afd6ae4fec81 > > (31) 8164383: jhsdb dumps core on Solaris 12 when loading dumped core > http://hg.openjdk.java.net/jdk/jdk/rev/10e6e31dc1aa > > (32) 8166552: SA: Missed testcase for add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk/jdk/rev/815650daefb4 > > (33) 8027920: SA: Add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk/jdk/rev/aed0f6434aea > > (34) 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" > http://hg.openjdk.java.net/jdk/jdk/rev/c0e02245ff93 > http://hg.openjdk.java.net/jdk/jdk/rev/12787d18650e > > (35) 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE > http://hg.openjdk.java.net/jdk/jdk/rev/adf083cbc37f > > (36) 8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames > http://hg.openjdk.java.net/jdk/jdk/rev/8a2083c5e2b1 > http://hg.openjdk.java.net/jdk/jdk/rev/d46cac7959c4 > > (37) 8145627: sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test > http://hg.openjdk.java.net/jdk/jdk/rev/82ece130a37b > From mark.reinhold at oracle.com Thu Sep 27 22:37:41 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 27 Sep 2018 15:37:41 -0700 (PDT) Subject: JEP proposed to target JDK 12: 340: One AArch64 Port, Not Two Message-ID: <20180927223741.D01B720B000@eggemoggin.niobe.net> The following JEP is proposed to target JDK 12: 340: One AArch64 Port, Not Two http://openjdk.java.net/jeps/340 Feedback on this proposal from JDK Project Committers and Reviewers [1] is more than welcome, as are reasoned objections. If no such objections are raised by 23:00 UTC on Thursday, 4 October, or if they?re raised and then satisfactorily answered, then per the JEP 2.0 process proposal [2] I?ll target this JEP to JDK 12. - Mark [1] http://openjdk.java.net/census#jdk [2] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From mark.reinhold at oracle.com Thu Sep 27 22:37:43 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 27 Sep 2018 15:37:43 -0700 (PDT) Subject: JEP proposed to target JDK 12: 341: Default CDS Archives Message-ID: <20180927223743.13E8820B002@eggemoggin.niobe.net> The following JEP is proposed to target JDK 12: 341: Default CDS Archives http://openjdk.java.net/jeps/341 Feedback on this proposal from JDK Project Committers and Reviewers [1] is more than welcome, as are reasoned objections. If no such objections are raised by 23:00 UTC on Thursday, 4 October, or if they?re raised and then satisfactorily answered, then per the JEP 2.0 process proposal [2] I?ll target this JEP to JDK 12. - Mark [1] http://openjdk.java.net/census#jdk [2] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From mark.reinhold at oracle.com Thu Sep 27 23:16:53 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 27 Sep 2018 16:16:53 -0700 Subject: Proposed schedule for JDK 12 In-Reply-To: <5B9AEC3F.3080701@oracle.com> References: <20180913224102.673F82097A3@eggemoggin.niobe.net> <5B9AEC3F.3080701@oracle.com> Message-ID: <20180927161653.618998912@eggemoggin.niobe.net> 2018/9/13 16:01:19 -0700, philip.race at oracle.com: > On 9/13/18, 3:41 PM, mark.reinhold at oracle.com wrote: >> With JDK 11 nearly out the door, here's a proposed schedule for JDK 12: >> >> 2018/12/13 Rampdown Phase One > > I don't know the day counting algorithm, but why not 12/20 or thereabouts ? 12/20 is very close to a major holiday for many contributors, including those who will do the fork from the main-line repository when RDP 1 begins. Starting RDP 1 on 12/13 rather than 12/20 allows people to make personal travel plans and, more generally, not be overly stressed about work right before the holiday. The JDK 10 schedule started RDP 1 at a similar date (12/14), for the same reason. > .. 12/13 seems to reducing the amount of time to get features in by a > week relative to RDP 2 + GA If a feature doesn?t make it into JDK 12 then ... there?s always JDK 13. I did notice a mistake in the schedule, though: RDP 2 was three weeks long in JDK 10 and JDK 11, but it?s only two weeks long in JDK 12, and the RC phase was five weeks (and five days) long in JDK 10 and JDK 11 but it?s six weeks (and five days) long in JDK 12. This is easy to fix -- we just move the start of the RC phase out by one week: 2018/12/13 Rampdown Phase One 2019/01/17 Rampdown Phase Two 2019/02/07 Release-Candidate Phase (changed; was 1/31) 2019/03/19 General Availability I?ll hold this thread open until 23:30 UTC next Thursday in case there are further comments or objections. - Mark From jiangli.zhou at oracle.com Fri Sep 28 02:49:24 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 27 Sep 2018 22:49:24 -0400 Subject: CFV: New JDK Reviewer: Jini George In-Reply-To: <3C834F7A-6B22-41F5-B78A-B673FE917F71@oracle.com> References: <3C834F7A-6B22-41F5-B78A-B673FE917F71@oracle.com> Message-ID: <02cbf342-31fe-e40a-340a-8ec6f9ef7172@oracle.com> Vote: yes Thanks, Jiangli On 9/27/18 12:05 PM, jesper.wilhelmsson at oracle.com wrote: > I hearby nominate Jini George (jgeorge) to JDK Project Reviewer. > > Jini has made 37 contributions in the JDK [3], many in the Serviceability Agent which is an area that for a long time was lacking active contributors. Jini's work in the SA is highly appreciated. > > Votes are due by 18:00 CET October 11, 2018. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] List of contributions: > > (1) 8210836: Build fails with warn_unused_result in openjdk/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c > http://hg.openjdk.java.net/jdk/jdk/rev/c0f9161f591e > > (2) 8204308: SA: serviceability/sa/TestInstanceKlassSize*.java fails when running in CDS mode > http://hg.openjdk.java.net/jdk/jdk/rev/948c62200f8c > > (3) 8189429: SA: MacOSX: Replace the deprecated PT_ATTACH with PT_ATTACHEXC > http://hg.openjdk.java.net/jdk/jdk/rev/e46b9e514479 > > (4) 8195613: [SA] HotSpotTypeDataBase.readVMLongConstants truncates values to int > http://hg.openjdk.java.net/jdk/jdk/rev/300e4a88c400 > > (5) 8174995: SA: clhsdb 'where -a' throws Assertion Failure with illegal code 236 when CDS is used > http://hg.openjdk.java.net/jdk/jdk/rev/55153a374d18 > > (6) 8174994: SA: clhsdb printmdo throws WrongTypeException when attached to a process with CDS > http://hg.openjdk.java.net/jdk/jdk/rev/ec2dd30adbc1 > > (7) 8175312: SA: clhsdb: Provide an improved heap summary for 'universe' for G1GC > http://hg.openjdk.java.net/jdk/jdk/rev/ccb003941743 > > (8) 8175384: SA: clhsdb 'printall' throws ClassCastException while printing out the bytecodes > http://hg.openjdk.java.net/jdk/jdk/rev/d2a860bc50a3 > > (9) 8193352: SA: Test for the clhsdb 'thread' and 'threads' commands > http://hg.openjdk.java.net/jdk/jdk/rev/fdef4da95080 > > (10) 8192985: SA: Test cases for the clhsdb 'inspect', 'scanoops' and 'printas' commands > http://hg.openjdk.java.net/jdk/jdk/rev/be065f758154 > > (11) 8191538: SA: tests for clhsdb commands: vmstructsdump, field, symboltable and symbol > http://hg.openjdk.java.net/jdk/jdk/rev/61a14b5cb1c6 > > (12) 8191914: New SA test timeout on windows > http://hg.openjdk.java.net/jdk/jdk/rev/88ec5fca7726 > > (13) 8191324: SA cleanup -- part 2 > http://hg.openjdk.java.net/jdk/jdk/rev/2659c4fe8ea7 > > (14) 8191961: SA: Remove left over quarantined SA tests due to 8184042 from ProblemList.txt > http://hg.openjdk.java.net/jdk/jdk/rev/111834dd10dd > > (15) 8191919: Include TestJhsdbJstackLock.java in ProblemList.txt > http://hg.openjdk.java.net/jdk/jdk/rev/d851eb254409 > > (16) 8190307: SA tests for the clhsdb commands: universe, intconstant, type > http://hg.openjdk.java.net/jdk/jdk/rev/75d365bfc2e6 > > (17) 8189798: SA cleanup - part 1 > http://hg.openjdk.java.net/jdk/jdk/rev/ac0af7750da9 > > (18) 8184042: several serviceability/sa tests timed out on MacOS X > http://hg.openjdk.java.net/jdk/jdk/rev/dfb375d231fb > > (19) 8175512: new TestPrintMdo.java fails with -XX:TieredStopAtLevel=1 > http://hg.openjdk.java.net/jdk/jdk/rev/deab1e2f0ebf > > (20) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client > http://hg.openjdk.java.net/jdk/jdk/rev/2eab88a780e3 > > (21) 8162504: TestInstanceKlassSize.java and TestInstanceKlassSizeForInterface.java fail on Mac OS > http://hg.openjdk.java.net/jdk/jdk/rev/4597fa06b227 > > (22) 8175054: Move new TestPrintMdo.java to hotspot/test directory > http://hg.openjdk.java.net/jdk/jdk/rev/d9ba85f5cb9d > > (23) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client > http://hg.openjdk.java.net/jdk/jdk/rev/c809fcb66c81 > > (24) 8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow > http://hg.openjdk.java.net/jdk/jdk/rev/a152f2d3320e > > (25) 8159127: hprof heap dumps broken for lambda classdata > http://hg.openjdk.java.net/jdk/jdk/rev/0b0ae99d8639 > http://hg.openjdk.java.net/jdk/jdk/rev/297ba2772122 > > (26) 8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1 > http://hg.openjdk.java.net/jdk/jdk/rev/48d874bf85fb > > (27) 8169638: serviceability/sa/TestInstanceKlassSize.java and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation > http://hg.openjdk.java.net/jdk/jdk/rev/a20695c30be5 > > (28) 8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c > http://hg.openjdk.java.net/jdk/jdk/rev/154099b110df > > (29) 7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test > http://hg.openjdk.java.net/jdk/jdk/rev/815cfbe4878b > > (30) 8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure > http://hg.openjdk.java.net/jdk/jdk/rev/afd6ae4fec81 > > (31) 8164383: jhsdb dumps core on Solaris 12 when loading dumped core > http://hg.openjdk.java.net/jdk/jdk/rev/10e6e31dc1aa > > (32) 8166552: SA: Missed testcase for add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk/jdk/rev/815650daefb4 > > (33) 8027920: SA: Add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk/jdk/rev/aed0f6434aea > > (34) 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" > http://hg.openjdk.java.net/jdk/jdk/rev/c0e02245ff93 > http://hg.openjdk.java.net/jdk/jdk/rev/12787d18650e > > (35) 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE > http://hg.openjdk.java.net/jdk/jdk/rev/adf083cbc37f > > (36) 8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames > http://hg.openjdk.java.net/jdk/jdk/rev/8a2083c5e2b1 > http://hg.openjdk.java.net/jdk/jdk/rev/d46cac7959c4 > > (37) 8145627: sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test > http://hg.openjdk.java.net/jdk/jdk/rev/82ece130a37b > From matthias.baesken at sap.com Fri Sep 28 12:32:49 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 28 Sep 2018 12:32:49 +0000 Subject: jboolean handling in native JDK code - was : RE: 8211163: UNIX version of Java_java_io_Console_echo does not return a clean boolean Message-ID: Hi Andrew, maybe this is another "bad" jboolean handling : src/java.desktop/windows/native/libawt/windows/awt_List.cpp 1004JNIEXPORT jboolean JNICALL 1005Java_sun_awt_windows_WListPeer_isSelected(JNIEnv *env, jobject self, 1006 jint index) 1007{ 1008 TRY; 1009 1010 SelectElementStruct *ses = new SelectElementStruct; 1011 ses->list = env->NewGlobalRef(self); 1012 ses->index = index; 1013 1014 return (jboolean)((intptr_t)AwtToolkit::GetInstance().SyncCall( 1015 (void *(*)(void *))AwtList::_IsSelected, ses)); Shouldn't we better compare the pointer to NULL instead of just casting ? Best regards, Matthias > -----Original Message----- > From: jdk-dev On Behalf Of Andrew > Haley > Sent: Mittwoch, 26. September 2018 17:52 > To: jdk-dev at openjdk.java.net > Subject: RFR: 8211163: UNIX version of Java_java_io_Console_echo does not > return a clean boolean > > Java_java_io_Console_echo looks like this: > > JNIEXPORT jboolean JNICALL > Java_java_io_Console_echo(JNIEnv *env, jclass cls, jboolean on) > { > DWORD fdwMode; > jboolean old; > ... > old = (fdwMode & ENABLE_ECHO_INPUT); > ... > return old; > } > > It only works by accident. jboolean is an unsigned byte. > ENABLE_ECHO_INPUT on the systems I know of is 0000010, so fdwMode & > ENABLE_ECHO_INPUT fits into the result, but only by accident. We > should do things properly and return a clean boolean. > > Note that the Windows version of the code is correct: I assume the > UNIX version is an oversight. > > https://bugs.openjdk.java.net/browse/JDK-8211163 > http://cr.openjdk.java.net/~aph/8211163/ > > OK? > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From matthias.baesken at sap.com Fri Sep 28 13:44:51 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 28 Sep 2018 13:44:51 +0000 Subject: jboolean handling in native JDK code - was : RE: 8211163: UNIX version of Java_java_io_Console_echo does not return a clean boolean In-Reply-To: References: Message-ID: I found a few other places in jdk code where the jboolean handling looks problematic to me . Should we change them ? Best regards, Matthias other strange pointer/jboolean casts + assignments : --------------------------------------------------------------------------------- jdk/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp 7123JNIEXPORT jboolean JNICALL 7124Java_sun_awt_windows_WComponentPeer_nativeHandlesWheelScrolling (JNIEnv* env, 7125 jobject self) 7126{ 7129 return (jboolean)((intptr_t)AwtToolkit::GetInstance().SyncCall( 7130 (void *(*)(void *))AwtComponent::_NativeHandlesWheelScrolling, 7131 env->NewGlobalRef(self))); 7142JNIEXPORT jboolean JNICALL 7143Java_sun_awt_windows_WComponentPeer_isObscured(JNIEnv* env, 7144 jobject self) 7145{ 7150 return (jboolean)((intptr_t)AwtToolkit::GetInstance().SyncCall( 7151 (void*(*)(void*))AwtComponent::_IsObscured, 7152 (void *)selfGlobalRef)); jdk/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp 3907JNIEXPORT jboolean JNICALL Java_sun_awt_windows_WWindowPeer_requestWindowFocus 3908 (JNIEnv *env, jobject self, jboolean isMouseEventCause) 3909{ 3917 3918 return (jboolean)((intptr_t)AwtToolkit::GetInstance().SyncCall( 3919 (void*(*)(void*))AwtWindow::_RequestWindowFocus, rfs)); another different one : we might assign "result = context->err_code;" and err_code gets potentially values 0 - 3 -------------------------------------------- jdk/src/java.base/share/native/libverify/check_code.c 763#define CC_OK 1 764#define CC_VerifyError 0 765#define CC_OutOfMemory 2 766#define CC_ClassFormatError 3 767 768JNIEXPORT jboolean 769VerifyClassForMajorVersion(JNIEnv *env, jclass cb, char *buffer, jint len, 770 jint major_version) 771{ ................. 774 jboolean result = CC_OK; 775 int i; 776 int num_methods; 777 int* code_lengths; 778 unsigned char** code; 779 878 result = CC_OK; 879 } else { 880 result = context->err_code; 881 } 908 return result; 909} > -----Original Message----- > From: Baesken, Matthias > Sent: Freitag, 28. September 2018 14:33 > To: 'Andrew Haley' ; jdk-dev at openjdk.java.net > Cc: Simonis, Volker > Subject: jboolean handling in native JDK code - was : RE: 8211163: UNIX > version of Java_java_io_Console_echo does not return a clean boolean > > Hi Andrew, maybe this is another "bad" jboolean handling : > > > src/java.desktop/windows/native/libawt/windows/awt_List.cpp > > 1004JNIEXPORT jboolean JNICALL > 1005Java_sun_awt_windows_WListPeer_isSelected(JNIEnv *env, jobject > self, > 1006 jint index) > 1007{ > 1008 TRY; > 1009 > 1010 SelectElementStruct *ses = new SelectElementStruct; > 1011 ses->list = env->NewGlobalRef(self); > 1012 ses->index = index; > 1013 > 1014 return (jboolean)((intptr_t)AwtToolkit::GetInstance().SyncCall( > 1015 (void *(*)(void *))AwtList::_IsSelected, ses)); > > > Shouldn't we better compare the pointer to NULL instead of just casting ? > > Best regards, Matthias > > > > -----Original Message----- > > From: jdk-dev On Behalf Of > Andrew > > Haley > > Sent: Mittwoch, 26. September 2018 17:52 > > To: jdk-dev at openjdk.java.net > > Subject: RFR: 8211163: UNIX version of Java_java_io_Console_echo does > not > > return a clean boolean > > > > Java_java_io_Console_echo looks like this: > > > > JNIEXPORT jboolean JNICALL > > Java_java_io_Console_echo(JNIEnv *env, jclass cls, jboolean on) > > { > > DWORD fdwMode; > > jboolean old; > > ... > > old = (fdwMode & ENABLE_ECHO_INPUT); > > ... > > return old; > > } > > > > It only works by accident. jboolean is an unsigned byte. > > ENABLE_ECHO_INPUT on the systems I know of is 0000010, so fdwMode & > > ENABLE_ECHO_INPUT fits into the result, but only by accident. We > > should do things properly and return a clean boolean. > > > > Note that the Windows version of the code is correct: I assume the > > UNIX version is an oversight. > > > > https://bugs.openjdk.java.net/browse/JDK-8211163 > > http://cr.openjdk.java.net/~aph/8211163/ > > > > OK? > > > > -- > > Andrew Haley > > Java Platform Lead Engineer > > Red Hat UK Ltd. > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Fri Sep 28 14:04:24 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 28 Sep 2018 15:04:24 +0100 Subject: jboolean handling in native JDK code - was : RE: 8211163: UNIX version of Java_java_io_Console_echo does not return a clean boolean In-Reply-To: References: Message-ID: On 09/28/2018 01:32 PM, Baesken, Matthias wrote: > Shouldn't we better compare the pointer to NULL instead of just casting ? Heavens, yes! You have found a nasty bug. Note that the cast to intptr_t used here suppresses the compiler warning which should have been a big clue that something was wrong. Good catch. 8198895: Compilation errors in java.desktop with VS 2017 +++ b/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp Mon Mar 19 14:16:23 2018 -0700 @@ -3915,8 +3915,8 @@ rfs->component = selfGlobalRef; rfs->isMouseEventCause = isMouseEventCause; - return (jboolean)AwtToolkit::GetInstance().SyncCall( - (void*(*)(void*))AwtWindow::_RequestWindowFocus, rfs); + return (jboolean)((intptr_t)AwtToolkit::GetInstance().SyncCall( + (void*(*)(void*))AwtWindow::_RequestWindowFocus, rfs)); // global refs and rfs are deleted in _RequestWindowFocus CATCH_BAD_ALLOC_RET(JNI_FALSE); -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Fri Sep 28 14:06:18 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 28 Sep 2018 15:06:18 +0100 Subject: jboolean handling in native JDK code - was : RE: 8211163: UNIX version of Java_java_io_Console_echo does not return a clean boolean In-Reply-To: References: Message-ID: <5d2695f1-55f4-095d-8eef-97e79d5f8f05@redhat.com> On 09/28/2018 02:44 PM, Baesken, Matthias wrote: > I found a few other places in jdk code where the jboolean handling looks problematic to me . > Should we change them ? I would. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From philip.race at oracle.com Fri Sep 28 16:32:30 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 28 Sep 2018 09:32:30 -0700 Subject: jboolean handling in native JDK code - was : RE: 8211163: UNIX version of Java_java_io_Console_echo does not return a clean boolean In-Reply-To: References: Message-ID: <594d2fde-3b63-a67b-dea7-21ae6acbb41c@oracle.com> _RequestWindowFocus is declared to return jboolean. So I don't think there's a nasty bug, just a whole lot of casting which might be better avoided by some additional overload of SyncCall() which accepts the function's real signature. -phil. On 09/28/2018 07:04 AM, Andrew Haley wrote: > On 09/28/2018 01:32 PM, Baesken, Matthias wrote: >> Shouldn't we better compare the pointer to NULL instead of just casting ? > Heavens, yes! You have found a nasty bug. > > Note that the cast to intptr_t used here suppresses the compiler > warning which should have been a big clue that something was > wrong. Good catch. > > 8198895: Compilation errors in java.desktop with VS 2017 > > +++ b/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp Mon Mar 19 14:16:23 2018 -0700 > @@ -3915,8 +3915,8 @@ > rfs->component = selfGlobalRef; > rfs->isMouseEventCause = isMouseEventCause; > > - return (jboolean)AwtToolkit::GetInstance().SyncCall( > - (void*(*)(void*))AwtWindow::_RequestWindowFocus, rfs); > + return (jboolean)((intptr_t)AwtToolkit::GetInstance().SyncCall( > + (void*(*)(void*))AwtWindow::_RequestWindowFocus, rfs)); > // global refs and rfs are deleted in _RequestWindowFocus > > CATCH_BAD_ALLOC_RET(JNI_FALSE); From aph at redhat.com Fri Sep 28 17:27:22 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 28 Sep 2018 18:27:22 +0100 Subject: jboolean handling in native JDK code - was : RE: 8211163: UNIX version of Java_java_io_Console_echo does not return a clean boolean In-Reply-To: <594d2fde-3b63-a67b-dea7-21ae6acbb41c@oracle.com> References: <594d2fde-3b63-a67b-dea7-21ae6acbb41c@oracle.com> Message-ID: <41f420b4-aa10-c345-e576-94dec251c755@redhat.com> On 09/28/2018 05:32 PM, Phil Race wrote: > _RequestWindowFocus is declared to return jboolean. > > So I don't think there's a nasty bug, just a whole lot of casting which might > be better avoided by some additional overload of SyncCall() which accepts > the function's real signature. Yes, you're right. Thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671