From gnu.andrew at redhat.com Wed May 1 05:44:59 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 1 May 2019 06:44:59 +0100 Subject: [RFR] [8u] 8222965: Build Breakage from JDK-8129988 In-Reply-To: <9AD53AF4-8431-40F1-9DBE-F82EF589DBCD@amazon.com> References: <6d56c8eb-5eee-22fc-a728-9bbd6d7009a6@redhat.com> <8d6a3bdb-7bf2-b678-013b-4d7b6b61b2ce@redhat.com> <9a96362a-5cc1-347c-9cb8-c9768474a4ba@redhat.com> <28fd2e8c-0160-dbe5-a063-165ee1cc5986@redhat.com> <9AD53AF4-8431-40F1-9DBE-F82EF589DBCD@amazon.com> Message-ID: <7c4db68a-0cca-44ae-403c-2f9fe817b788@redhat.com> On 30/04/2019 22:53, Hohensee, Paul wrote: > My apologies for messing this up, and thanks for fixing it. > > Paul > No problem. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Wed May 1 05:47:14 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 1 May 2019 06:47:14 +0100 Subject: jdk8u222-b01 tagged Message-ID: I've tagged jdk8u222-b01 locally and will push once tested. Any changes pushed from this point forward will form part of b02. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Wed May 1 06:02:44 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 1 May 2019 07:02:44 +0100 Subject: [8u] RFR: 8210416: [linux] Poor StrictMath performance due to non-optimized compilation In-Reply-To: <2dce878b0d25f63974f2988f58d022d810af81bd.camel@redhat.com> References: <2dce878b0d25f63974f2988f58d022d810af81bd.camel@redhat.com> Message-ID: <5d46c995-833f-7e95-b1f1-96d35ac8dc15@redhat.com> On 30/04/2019 12:37, Severin Gehwolf wrote: > Hi, > > Could I please get a review for this 8u backport related to fdlibm > optimization on Linux? The JDK 12 patch doesn't apply as-is as the JDK > 8 build system is drastically different from JDK 11+. > It's not "drastically different" as regards the top-level and jdk areas. HotSpot is another matter. The main difference in this change is we're supporting gcc < 4.6, which is sensible. > Bug: https://bugs.openjdk.java.net/browse/JDK-8210416 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/jdk8/02/ > > The main differences to the original fix are: a) optimization level and > b) additional hook for older GCC. This backport keeps the optimization > level at -O3 (HIGH) over -O2 (LOW) for JDK 8u as this would otherwise > regress Linux ppc64{,le} which currently use -O3. As the current code > has the implicit assumption of ppc64 being compiled on older GCCs too > (JDK-8172053), this backport maintains compatibility in this regard. If > -ffp-contract=off is not available, a machine specific set of flags is > being used if the compiler supports them (-mno-fused-madd -fno-strict- > aliasing). > > For older GCCs (< 4.6) specific machine flags are being used. That is, > for ppc64{,le} and x86{,_64}. ppc64{,le} machine specific flags have > already been determined (See JDK-8172053). x86_64 and x86 have the same > machine specific flags available, so I've used them there too[1]. > > Testing: build/test on gcc 8.x Linux x86_64. build/test on gcc 4.4.7 > x86_64/ppc64. Manual inspection of build logs for fdlibm files (e.g. > w_asin.c). > > Thoughts? > > Thanks, > Severin > > [1] https://gcc.gnu.org/onlinedocs/gcc-4.4.7/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options > > > > > Looks good to me. This is how JDK-8172053 should have been handled to begin with, rather than making assumptions (and indeed, that's how I fixed it [0] [1]) [0] http://icedtea.classpath.org/hg/icedtea8-forest/rev/d5760f7cce54 [1] http://icedtea.classpath.org/hg/icedtea8-forest/jdk/rev/3642a826880b -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Wed May 1 06:06:57 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 1 May 2019 07:06:57 +0100 Subject: [8u] RFR (S) 8151539: Remove duplicate AlwaysTrueClosures In-Reply-To: <59f3ef8f-42b4-13f6-8e91-3b76014b9d13@redhat.com> References: <59f3ef8f-42b4-13f6-8e91-3b76014b9d13@redhat.com> Message-ID: <61b25369-59e3-caef-7867-d6ba0dfe09bd@redhat.com> On 30/04/2019 17:21, Aleksey Shipilev wrote: > Original RFE: > https://bugs.openjdk.java.net/browse/JDK-8151539 > > Original fix: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/be3ffb6d8eb0 > > I would like to backport this cleanup to 8u, because it unblocks the Shenandoah backport in > downstream repository. Patch does not apply cleanly, because reshuffles are needed, and then some > near code is not matching the version from 9 (mostly due to Unified Logging). > > 8u webrev: > http://cr.openjdk.java.net/~shade/8151539/webrev.8u.01/ > > Testing: Linux x86_64 {fastdebug,release} builds; all hotspot jtregs > Looks good to me. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Wed May 1 06:50:05 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 1 May 2019 07:50:05 +0100 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> <833668ba-d134-fdd0-2363-f682b19eced7@redhat.com> Message-ID: On 30/04/2019 13:40, Lindenmaier, Goetz wrote: > Hi Andrew, > >>> To put this into concrete steps, is it ok if I do the following?: >>> >>> In jdk11u: >>> Tuesday between 12:00 and 18:00 CE(S)T >>> hg pull >>> hg tag; >>> run tests and build >>> Wednesday between 12:00 and 18:00 (after tests completed): >>> hg pull/hg merge if necessary. >>> hg push --> publishes the tag to 11u >> As it stands, this is going to mean testing and tagging nothing, because >> jdk11u is at 11.0.3-ga. > > Well, obviously this is only the initial case. I could have pulled from jdk11u-dev > last week if I had known. Exceptionally, I could pull right now. > I tried to run this discussion 4 weeks ago, but did not get much > feedback. Many of us were very busy with the last release. > The hg-updater issue is blocking us, anyways. > If we now pull to jdk11u, it will all be tagged as going to 11.0.3. Indeed. This seems like a reason to do it in jdk11u-dev. > >>> hg pull jdk11u-dev --> this is skipped after 2019-05-28 >>> hg merge >>> hg push --> brings the latest changes from 11u-dev to 11u >>> They can be tested 6 days in 11u. >>> >> Whereas the jdk11u-dev changes are not being tested. > They would be tested from there on in jdk11u. > Who keeps us from doing fixes in jdk11u in those 6 days? What do you mean by "doing fixes"? Work should go on in jdk11u-dev, not jdk11. > >>> In jdk11u-dev: >>> Wednesday before 18:00 CE(S)T >>> hg pull >>> hg pull jdk11u >>> hg merge >>> run tests and build >>> Thursday after tests completed: >>> hg pull/hg merge if necessary. >>> hg push --> brings the latest changes and the tag from 11u to 11u-dev >>> >> >> This was my thinking (and thus my plan for 8u): >> >> Development stage (2019-05-01 to 2019-05-29): >> >> jdk11u-dev: >> >> $ hg pull >> >> If all good: >> >> $ hg tag jdk-11.0.4+x >> $ hg push >> >> jdk11u: >> >> $ hg pull >> $ hg pull jdk11u-dev >> $ hg merge (if necessary) >> >> I don't think a merge should be necessary as jdk11u-dev is a superset of >> jdk11u and that merge has already been performed in pulling >> jdk-11.0.3-ga into jdk11u-dev. >> >> At rampdown: jdk11u-dev is tagged jdk-11.0.5+0 >> >> Rampdown stage (2019-06-05 to 2019-06-26): >> >> jdk11u: >> >> $ hg pull >> >> If all good: >> >> $ hg tag jdk-11.0.4+y >> $ hg push >> >> jdk11u-dev: >> >> $ hg pull >> $ hg pull jdk11u >> $ hg merge >> >> Merging will be necessary as jdk11u will contain 11.0.5 changes by this >> point. >> >> In other words, the same process takes place in both stages, but the >> repositories switch roles; in the development stage, jdk11u-dev is the >> master receiving changes and is merged into jdk11u, while in the >> rampdown stage, jdk11u is now receiving changes for that release and is >> merged into jdk11u-dev. > > I think we should not concentrate on reducing the hg commands on > our side. That's not my aim. > We should try to build a process that is easy to communicate We should. I'm sorry, but I don't find yours to be so. and > understand for those that are not as involved as we are. > If we always tag in jdk11u, we can say: > "jdk11u is the consolidation repository for the next release" > Now the message is: up to this day we do work in jdk11u-dev, > from that on in jdk11u. No, it isn't. I'm not sure who the 'we' is here, but maybe this is the confusion here. The message is work is always done in the development tree, jdk11u-dev. Work in the jdk11u-dev tree is always work on the development stage of a release. Explicitly moving the focus for release x from the development tree to the master tree at rampdown is designed to shift development focus to the next release, x+1. If an issue is found in working on x+1, or in testing x, that is a showstopper for release x, then that may be flagged as jdk8u-critical-request to get it into the upcoming release. But otherwise, the intent here is for people to start aiming their work at the next release at rampdown. Patches being pushed to jdk11u should be rare. > And it raises the question: why is it merged to jdk11u? It's the > same anyways! > Thus, following your approach, I would propose to skip merging > to jdk11u until start of the rampdown. Because jdk11u and jdk11u-dev are aimed at different audiences. The master tree (jdk11u) is snapshots for people to test and integrate downstream, leading up to the final release. The development tree (jdk11u-dev) is for developers to work on the release. I don't see how that's any different to your scenario which, I believe, also updates both. I don't expect developers working on jdk8u development to have to care much about the master tree, unless they is a critical issue with the upcoming release. I don't expect consumers to care about the development tree at all; they should consume solely from jdk11. As I said before, merging to jdk11u earlier is intended to provide for earlier testing of a smaller number of changes. It's an attempt to meet your call for earlier testing without locking everything down before many people have even had time to work on the release. > >> What testing do you do? > > We build and test jdk11u-dev and jdk11u as Christoph pointed out announced here > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000648.html > on a daily basis. This is all automated and backed by a database where we > can see test failures about half a year back. > We still add new tests, recently we > added jtreg tests nashorn, jaxp and langtools. > (Adding test always means to fix a lot of test bugs and setup issues.) > The builds of jdk11u-dev include a mercurial patch queue with the > changes we are working on. Therefore the test results are not > that reliable ... well, it is a dev code line :) > Further tests are done in our SapMachine infrastructure. > The SapMachine build is only triggered if a tag arrives in the > jdk11u code line. > Finally we distribute prerelease builds to departments in > our company that use it for testing. As there only is a window > of four weeks from RDP2 to the code freeze, feedback from > these will probably go directly to SapMachine and then to the > next OpenJDK 11u release. But we will share issues and try to get > fixes into the current OpenJDK release. Which is why I suggest starting such builds over the next week or so. My plan for 8u is to integrate the build downstream and do our usual builds and testing as much as possible for each tag. > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Wed May 1 09:35:21 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 1 May 2019 11:35:21 +0200 Subject: [8u] RFR (S) 8151539: Remove duplicate AlwaysTrueClosures In-Reply-To: <61b25369-59e3-caef-7867-d6ba0dfe09bd@redhat.com> References: <59f3ef8f-42b4-13f6-8e91-3b76014b9d13@redhat.com> <61b25369-59e3-caef-7867-d6ba0dfe09bd@redhat.com> Message-ID: <16db4f9d-96eb-6f66-6a4e-c075af2472f8@redhat.com> On 5/1/19 8:06 AM, Andrew John Hughes wrote: > On 30/04/2019 17:21, Aleksey Shipilev wrote: >> Original RFE: >> https://bugs.openjdk.java.net/browse/JDK-8151539 >> >> Original fix: >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/be3ffb6d8eb0 >> >> I would like to backport this cleanup to 8u, because it unblocks the Shenandoah backport in >> downstream repository. Patch does not apply cleanly, because reshuffles are needed, and then some >> near code is not matching the version from 9 (mostly due to Unified Logging). >> >> 8u webrev: >> http://cr.openjdk.java.net/~shade/8151539/webrev.8u.01/ >> >> Testing: Linux x86_64 {fastdebug,release} builds; all hotspot jtregs >> > > Looks good to me. Thanks guys, pushed. -Aleksey From goetz.lindenmaier at sap.com Wed May 1 13:33:55 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 1 May 2019 13:33:55 +0000 Subject: Tagged 11.0.4+1 in jdk11u-dev. Sharing test failures. Message-ID: Hi, I tagged jdk11.0.4+1 in jdk11u-dev. below I list the jtreg tests we see failing as of jdk11.0.4+1. This includes all tests I see failing, without ruling out setup issues and the like. These tests were not failing in our 11.0.3 builds, nor in 12 or 13 except if explicitly stated. The fact they are failing on a certain platform does not mean the bug is platform dependent. Sometimes it's just the dependency to the OS variant. We test on a wide variety of different machines, OSes etc. In the next days I will have a closer look at the failures and open JBS issues if adequate. If someone jumps in and adresses one of these issues he is more than welcome. If so, I'm happy to share more details about the failures. Best regards, Goetz. all java/util/Calendar/NarrowNamesTest.sh java.lang.RuntimeException: test failed at NarrowNamesTest.main(NarrowNamesTest.java:134) I see this on various VMs today, also 11.0.3 and 8. But not consistently over all builds. For 11.0.4 only solaris sparc failed. Some kind of Japanese Era problem? all ppc platforms vmTestbase/vm/mlvm/meth/stress/gc/createLotsOfMHConsts/Test.java sporadic timeouts ### TRACE 1: RNG seed = -7264363496160763377 (0x9b2fcbe37405e20f) Timeout refired 720 times aix ppc64 java/nio/file/Files/DeleteOnClose.java JavaTest Message: Test threw exception: java.lang.RuntimeException: IOException expected java/nio/file/Files/SBC.java java.lang.RuntimeException at SBC.noFollowLinksTests(SBC.java:238) linux ppc64le runtime/ErrorHandling/ErrorHandler.java Gustavo java/awt/FontMetrics/MaxAdvanceIsMax.java FAILED: getMaxAdvance is not max for font: java.awt.Font linux s390x java/lang/management/MemoryMXBean/LowMemoryTest2.sh Exception in thread "Thread-0" java.lang.OutOfMemoryError: Compressed class space linux x86_64 and mac security/infra/java/security/cert/CertPathValidator/certification/GlobalSignR6CA.java java.lang.RuntimeException: TEST FAILED: couldn't determine EE certificate status Maybe an infrastructure problem. mac x86_64 java/net/MulticastSocket/Promiscuous.java java.lang.RuntimeException: Expected message not received, Receive timed out java/net/MulticastSocket/SetOutgoingIf.java java.net.SocketTimeoutException: Receive timed out solaris sparc Tier 1!! compiler/codecache/cli/codeheapsize/TestCodeHeapSizeOptions.java compiler/codecache/cli/printcodecache/TestPrintCodeCacheOption.java Not enough space in non-nmethod code heap to run VM: 20480K < 21475K windows x86_64 vmTestbase/nsk/jvmti/AddToBootstrapClassLoaderSearch/bootclssearch002/TestDescription.java vmTestbase/nsk/jvmti/AddToBootstrapClassLoaderSearch/bootclssearch004/TestDescription.java vmTestbase/nsk/jvmti/AddToBootstrapClassLoaderSearch/bootclssearch010/TestDescription.java Error: Could not find or load main class nsk.jvmti.AddToBootstrapClassLoaderSearch.bootclssearch002 Caused by: java.lang.NoClassDefFoundError: nsk/jvmti/AddToBootstrapClassLoaderSearch/bootclssearch002p java/net/httpclient/SmokeTest.java timeout > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Tuesday, April 30, 2019 2:48 PM > To: Andrew John Hughes ; Langer, Christoph > > Cc: Severin Gehwolf ; 'jdk8u- > dev at openjdk.java.net' ; Andrew Haley > ; Aleksey Shipilev ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u]: 8u222 & 11.0.4 release schedule > > Hi everybody, > > According to below schedule, I will tag SAPs nightbuild of jdk11u-dev > of Tuesday evening on Wednesday after testing and push the tag to > jdk11u-dev. > > Best regards, > Goetz. > > > March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) > > =============== 11.0.3 Released ============================ > > = jdk11u tree gets changes by merge from jdk11u-dev = > > > ========================================================== > == > > Wednesday, May 01 2019: First build (tag: jdk-11.0.4+1) > > Wednesday, May 08 2019: Second build (tag: jdk-11.0.4+2) > > Wednesday, May 15 2019: Third build (tag: jdk-11.0.4+3) > > Wednesday, May 21 2019: Fourth build (tag: jdk-11.0.4+4) > > Wednesday, May 29 2019: Fifth and final dev build (tag: jdk-11.0.4+5) > > ================= Rampdown > ================================= > > = jdk11u tree gets changes only by jdk11u-critical-request = > > > ========================================================== > == > > Wednesday, June 5, 2019: First rampdown build (tag: jdk-11.0.4+6) > > Wednesday, June 12, 2019: Second rampdown build (tag: jdk-11.0.4+7) > > Wednesday, June 19, 2019: Third rampdown build (tag: jdk-11.0.4+8) > > Wednesday June 26 2019: Last tag before code freeze (tag: jdk-11.0.4+9) > > ================= FREEZE > =================================== > > = jdk11u sees no public changes = > > > ========================================================== > == > > Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga, likely to be jdk-11.0.4+10) > > > > So, we could probably start the post-release stage a week earlier in > > future i.e. the Wednesday of the week after the CPU, if we're happy with > > the same stable process. > > > > Best regards, > > -- > > Andrew :) > > > > Senior Free Java Software Engineer > > Red Hat, Inc. (http://www.redhat.com) > > > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > > https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Wed May 1 15:58:14 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 1 May 2019 16:58:14 +0100 Subject: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath In-Reply-To: References: Message-ID: [CCing jdk8u-dev for 8u review] On 01/05/2019 08:04, Steve Groeger wrote: > Hi all, > > The following issue [1] has been raised and the associated webrev [2] has > been approved and the code merged into jdk/jdk [3] > I am now requesting this fix to be back-ported to jdk8u, jdk11u and > jdk12u. > The patch imports and works correctly on jdk8u and jdk12u but not quite on > jdk8u due to difference in the test framework. > I have created a separate webrev for the jdk8u changes [4]. > I am therefore requesting someone to review these changes and to sponsor > these updates to jdk8u, jdk11u and jdk12u. > > [1] https://bugs.openjdk.java.net/browse/JDK-8218152 > [2] http://cr.openjdk.java.net/~sgroeger/8218152/jdk/webrev.04/ > [3] http://hg.openjdk.java.net/jdk/jdk/rev/d9208a660094 > [4] http://cr.openjdk.java.net/~sgroeger/8218152/jdk8u/webrev.04/ > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Regarding the 8u webrev, the two additions for hasNext() and next() in JavacProcessingEnvironment.java seem to have been flipped. Was this intentional? Comparing patched jdk8u with the jdk/jdk version: --- src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java 2019-05-01 16:50:40.409545256 +0100 +++ ../../jdk/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java 2019-05-01 03:00 public boolean hasNext() { try { - return iterator.hasNext(); + return internalHasNext(); } catch(ServiceConfigurationError sce) { - log.error("proc.bad.config.file", sce.getLocalizedMessage()); + log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage())); throw new Abort(sce); + } catch (UnsupportedClassVersionError ucve) { + log.error(Errors.ProcCantLoadClass(ucve.getLocalizedMessage())); + throw new Abort(ucve); + } catch (ClassFormatError cfe) { + log.error(Errors.ProcCantLoadClass(cfe.getLocalizedMessage())); + throw new Abort(cfe); } catch (Throwable t) { - log.error("proc.bad.config.file", t.getLocalizedMessage()); + log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage())); throw new Abort(t); } } ... public Processor next() { try { - return iterator.next(); + return internalNext(); } catch (ServiceConfigurationError sce) { - log.error("proc.bad.config.file", sce.getLocalizedMessage()); + log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage())); throw new Abort(sce); - } catch (UnsupportedClassVersionError ucve) { - log.error("proc.cant.load.class", ucve.getLocalizedMessage()); - throw new Abort(ucve); - } catch (ClassFormatError cfe) { - log.error("proc.cant.load.class", cfe.getLocalizedMessage()); - throw new Abort(cfe); } catch (Throwable t) { - log.error("proc.bad.config.file", t.getLocalizedMessage()); + log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage())); throw new Abort(t); } } The test changes look ok and I assume they pass. Long term, we may want to look at backporting https://bugs.openjdk.java.net/browse/JDK-8050429 to avoid this work for every test. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Wed May 1 16:52:44 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 1 May 2019 18:52:44 +0200 Subject: jdk8u-jfr-incubator workspace, builds, webrevs Message-ID: Hi, These are the things that might make your development life a bit easier with JFR backport. Mercurial snapshot: https://builds.shipilev.net/workspaces/jdk8u-jdk8u-jfr-incubator.tar.xz Source snapshot: https://builds.shipilev.net/source-snapshots/jdk8u-jdk8u-jfr-incubator.tar.xz Webrev with difference against jdk8u/jdk8u: https://builds.shipilev.net/patch-openjdk-jdk8-jfr/ Builds (plus build logs in case of errors): https://builds.shipilev.net/openjdk-jdk8-jfr/ Webrevs are currently empty, because there are no changes against upstream? Builds are in progress and would show up in their full glory in a few hours. -- Thanks, -Aleksey From dalibor.topic at oracle.com Thu May 2 10:41:46 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 2 May 2019 12:41:46 +0200 Subject: Tagged 11.0.4+1 in jdk11u-dev. Sharing test failures. In-Reply-To: References: Message-ID: <87045a08-7f0d-b110-5297-8ef74e082e10@oracle.com> On 01.05.2019 15:33, Lindenmaier, Goetz wrote: > Hi, > > I tagged jdk11.0.4+1 in jdk11u-dev. > > below I list the jtreg tests we see failing as of jdk11.0.4+1. Thank you for running tests, Goetz. I'd suggest cross-posting your results to quality-discuss if you plan to run and post them regularly, where the results for JDK 13 (and prior releases') EA builds have been posted as well, such as https://mail.openjdk.java.net/pipermail/quality-discuss/2019-April/000866.html for the past several years. cheers, dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | D-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-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From christoph.langer at sap.com Thu May 2 12:55:25 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 2 May 2019 12:55:25 +0000 Subject: [8u] RFR: 8189131: Open-source the Oracle JDK Root Certificates (Integration for JEP 319: Root Certificates) Message-ID: Hi, as was already discussed and requested on the mailing lists ([0], [1]), I hereby propose a change to add the root certificates of upstream OpenJDK to OpenJDK 8 updates. The main bug that (initially) brought the Oracle certificates to OpenJDK is 8189131: Open-source the Oracle JDK Root Certificates [2]. My proposed change will also backport all updates to the contents of cacerts since then: 8191844: Remove SECOM root (secomevrootca1) 8189949: Remove Baltimore Cybertrust Code Signing CA 8191031: Remove several Symantec Root CAs 8196141: Add GoDaddy root certificates 8204923: Restore Symantec root verisignclass2g2ca 8195774: Add Entrust root certificates 8199779: Add T-Systems, GlobalSign and Starfield services root certificates 8209506: Add Google Trust Services GlobalSign root certificates 8210432: Add additional TeliaSonera root certificate 8195793: Remove GTE CyberTrust Global Root 8216577: Add GlobalSign's R6 Root certificate 8222137: Remove T-Systems root CA certificate Please find the webrev here: http://cr.openjdk.java.net/~clanger/webrevs/8189131.8u/ I took the current state of cacerts from the jdk/jdk repo along with the provided testcases and brought them down to the jdk8 repository layout. To make the test run in JDK8, I had to a) modify test/sun/security/lib/cacerts/VerifyCACerts.java: 240 private static final HashSet EXPIRY_EXC_ENTRIES = new HashSet() { I needed to add the String type to the constructor of the HashSet, since the JDK8 java compiler will not accept <> in that place. b) modify test/security/infra/java/security/cert/CertPathValidator/certification/ValidatePathWithParams.java 60 private static final String CACERTS_STORE = System.getProperty("test.jdk") 61 + FS + "jre" + FS + "lib" + FS + "security" + FS + "cacerts"; I needed to adapt the path to cacerts in a JDK8 JDK/JRE as it is located in subdirectory jre there. Out of the tests in test/security/infra/java/security/cert/CertPathValidator/certification, there are 2 failing: FAILED: security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java FAILED: security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java However, for jdk/jdk it is the same. JBS Issues for these tests exist and are yet unresolved: JDK-8202651 and JDK-8215546. Since the tests don't seem to be part of any tier, I propose to include them in this backport and later on also backport possible fixes to them. Thanks Christoph [0] https://mail.openjdk.java.net/pipermail/security-dev/2019-March/019557.html [1] https://mail.openjdk.java.net/pipermail/security-dev/2019-April/019733.html [2] https://bugs.openjdk.java.net/browse/JDK-8189131 From shade at redhat.com Thu May 2 17:45:25 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 2 May 2019 19:45:25 +0200 Subject: [8u] RFR (S) 8190974: Parallel stream execution within a custom ForkJoinPool should obey the parallelism Message-ID: <94d05544-08af-0969-1d28-484b79c597fe@redhat.com> Original fix: https://bugs.openjdk.java.net/browse/JDK-8190974 http://hg.openjdk.java.net/jdk/jdk/rev/e0041b182e31 This is one of the things that was mentioned multiple times as the pitfall in 8u. The patch itself is simple enough to consider backporting and fixing that pothole. Once related JDK-8154387 [1] backport is in, this patch applies with reshuffling to 8u, except for the test, which requires fitting to the old shape of Stream tests. 8u webrev: http://cr.openjdk.java.net/~shade/8190974/webrev.8u.01/ Testing: jdk_core tests, including the new test Thanks, -Aleksey [1] https://bugs.openjdk.java.net/browse/JDK-8154387 From goetz.lindenmaier at sap.com Fri May 3 13:15:43 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 3 May 2019 13:15:43 +0000 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> <833668ba-d134-fdd0-2363-f682b19eced7@redhat.com> Message-ID: Hi, > > The hg-updater issue is blocking us, anyways. > > If we now pull to jdk11u, it will all be tagged as going to 11.0.3. > Indeed. This seems like a reason to do it in jdk11u-dev. Please distinguish one-time contraints from general process setup. > What do you mean by "doing fixes"? Work should go on in jdk11u-dev, not > jdk11. Who keeps us from pushing to jdk11u? We could do so. > Explicitly moving the focus for release x from the development tree to > the master tree at rampdown is designed to shift development focus to > the next release, x+1. Yes. > If an issue is found in working on x+1, or in testing x, that is a > showstopper for release x, then that may be flagged as > jdk8u-critical-request to get it into the upcoming release. I think the name 'critical' is bad, it is misleading. The second tag is needed because we have two codelines, and want to distinguish for which the downport request is made. > But otherwise, the intent here is for people to start aiming their work > at the next release at rampdown. Patches being pushed to jdk11u should > be rare. I think we should use jdk11u only for rampdown. So patches pushed to jdk11u should be limited and well restricted, but not necessarily rare. But yes, definitely less than pushed to jdk11u-dev. > > And it raises the question: why is it merged to jdk11u? It's the > > same anyways! > > Thus, following your approach, I would propose to skip merging > > to jdk11u until start of the rampdown. > Because jdk11u and jdk11u-dev are aimed at different audiences. If they are interested in a decent stable version, they should only get the repo at rampdown. I think it's rather because people have certain processes set up, and jdk11u-dev is new. That again is a bad trigger for basic process decisions. > The master tree (jdk11u) is snapshots for people to test and integrate > downstream, leading up to the final release. No. The jdk11u is a repository used for rampdown so that development can be continued in another repository, here jdk11u-dev. It is not a convenience for testers, it is to allow parallel work with two different intentions: development <--> stabilization. > The development tree (jdk11u-dev) is for developers to work on the release. > > I don't see how that's any different to your scenario which, I believe, > also updates both. Yes it updates both because others want it that way, but I tried to assure at least some stabilization before tagging. > I don't expect developers working on jdk8u development to have to care > much about the master tree, unless they is a critical issue with the > upcoming release. I don't expect consumers to care about the development > tree at all; they should consume solely from jdk11. Yes, the audience pushing to jdk11u should be smaller than that pushing to jdk11u-dev. > As I said before, merging to jdk11u earlier is intended to provide for > earlier testing of a smaller number of changes. It's an attempt to meet > your call for earlier testing without locking everything down before > many people have even had time to work on the release. People should test jdk11u-dev if they want to test more early. Then they know they are testing an arbitrary development state and nothing in consolidation. > Which is why I suggest starting such builds over the next week or so. > > My plan for 8u is to integrate the build downstream and do our usual > builds and testing as much as possible for each tag. By the way, what is your "downstream"? Is it a repo that differs from OpenJDK (kind of as our SapMachine)? Or is it just a repo that feeds your build/test infrastructure? Best regards, Goetz. > > > > > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew From shade at redhat.com Fri May 3 14:14:21 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 3 May 2019 16:14:21 +0200 Subject: [8u] RFR (S) 8217315: Proper units should print more significant digits Message-ID: Original RFE: https://bugs.openjdk.java.net/browse/JDK-8217315 http://hg.openjdk.java.net/jdk/jdk/rev/d5f6540c6bb1 Unfortunately, 8u does not have support for gtest, which means the new regression test is not usable there. I worked that around by putting the test into ExecuteInternalVMTests block. 8u webrev: http://cr.openjdk.java.net/~shade/8217315/webrev.8u.02/ Testing: hotspot_all, jdk_core; ad-hoc -XX:+ExecuteInternalVMTests run -- Thanks, -Aleksey From sgehwolf at redhat.com Fri May 3 16:35:42 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 03 May 2019 18:35:42 +0200 Subject: [8u] RFR: 8210425: [x86] sharedRuntimeTrig/sharedRuntimeTrans compiled without optimization Message-ID: Hi, Could I please get reviews for this 8u backport of an optimization fix pertaining to the hotspot copy of fdlibm? Historically, sharedRuntimeTrans.cpp and sharedRuntimeTrig.cpp have been compiled with optimization turned off on x86/x86_64. As JDK-8210416 will be backported to JDK 8u fixing optimization for fdlibm itself, so should be the hotspot copy in OpenJDK 8u. The build system for hotspot in JDK 8u is very different, so the original fix for JDK 12 doesn't apply. It's a complete rewrite. Please see this webrev which shows the prerequisite patch. It adds the FDLIBM_CFLAGS logic: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/jdk8/02/ It also fixes a bug on ppc64{,le} where optimization is being turned on in hotspot (-O3), but not providing the -ffp-contract=off flag (or older equivalent). Before (on ppc64le): /bin/g++ -DLINUX -D_GNU_SOURCE -DPPC64 -DPRODUCT -I. -I/home/openjdk/jdk8u/hotspot/src/share/vm/prims -I/home/openjdk/jdk8u/hotspot/src/share/vm -I/home/openjdk/jdk8u/hotspot/src/share/vm/precompiled -I/home/openjdk/jdk8u/hotspot/src/cpu/ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os_cpu/linux_ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os/linux/vm -I/home/openjdk/jdk8u/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.212-b04\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"openjdk\"" -DHOTSPOT_LIB_ARCH=\"ppc64le\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_linux_ppc -DTARGET_OS_ARCH_MODEL_linux_ppc_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -fno-strict-aliasing -fno-omit-frame-pointer -O3 -g -D_LP64=1 -DVM_LITTLE_ENDIAN -DABI_ELFv2 -mcpu=power7 -mtune=power8 -minsert-sched-nops=regroup_exact -mno-multiple -mno-string -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -std=gnu++98 -c -MMD -MP -MF ../generated/dependencies/sharedRuntimeTrig.o.d -fpch-deps -o sharedRuntimeTrig.o /home/openjdk/jdk8u/hotspot/src/share/vm/runtime/sharedRuntimeTrig.cpp After (on ppc64le; Note -ffp-contract=off flag): /bin/g++ -DLINUX -D_GNU_SOURCE -DPPC64 -DPRODUCT -I. -I/home/openjdk/jdk8u/hotspot/src/share/vm/prims -I/home/openjdk/jdk8u/hotspot/src/share/vm -I/home/openjdk/jdk8u/hotspot/src/share/vm/precompiled -I/home/openjdk/jdk8u/hotspot/src/cpu/ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os_cpu/linux_ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os/linux/vm -I/home/openjdk/jdk8u/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.212-b04\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"openjdk\"" -DHOTSPOT_LIB_ARCH=\"ppc64le\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_linux_ppc -DTARGET_OS_ARCH_MODEL_linux_ppc_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -fno-strict-aliasing -fno-omit-frame-pointer -O3 -ffp-contract=off -D_LP64=1 -DVM_LITTLE_ENDIAN -DABI_ELFv2 -mcpu=power7 -mtune=power8 -minsert-sched-nops=regroup_exact -mno-multiple -mno-string -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -std=gnu++98 -c -MMD -MP -MF ../generated/dependencies/sharedRuntimeTrig.o.d -fpch-deps -o sharedRuntimeTrig.o /home/openjdk/jdk8u/hotspot/src/share/vm/runtime/sharedRuntimeTrig.cpp Bug: https://bugs.openjdk.java.net/browse/JDK-8210425 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210425/jdk8/02/webrev Testing: Builds on x86_64 (server/Zero). Manual inspection of compile log of sharedRuntimeTrans.cpp/sharedRuntimeTrig.cpp. Same for ppc64le. Note that we've been using this patch downstream for a while now. We haven't seen any issues so far. Thanks, Severin From gnu.andrew at redhat.com Fri May 3 17:57:47 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 3 May 2019 18:57:47 +0100 Subject: OpenJDK 8u222-b01 EA Released Message-ID: I've made available an early access source bundle for 8u222, based on the tag jdk8u222-b01: https://openjdk-sources.osci.io/openjdk8/openjdk8u222-b01.tar.xz The tarball is accompanied by a digital signature available at: https://openjdk-sources.osci.io/openjdk8/openjdk8u222-b01.tar.xz.sig This is signed by our new Red Hat OpenJDK key (openjdk at redhat.com): PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) Fingerprint = CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F SHA256 checksums: 5319ca54aa176df306c30e03cfc008bc4831797c2f3fe22d2314f80f21fc7e4d openjdk8u222-b01.tar.xz 46664701ea0d6cf588ff379ee7134d83517d16fb3c2ad9036577f7a90dc5209f openjdk8u222-b01.tar.xz.sig They are listed at https://openjdk-sources.osci.io/openjdk8/openjdk8u222-b01.sha256 -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From dalibor.topic at oracle.com Mon May 6 08:36:12 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Mon, 6 May 2019 10:36:12 +0200 Subject: OpenJDK 8u222-b01 EA Released In-Reply-To: References: Message-ID: On 03.05.2019 19:57, Andrew John Hughes wrote: > I've made available an early access source bundle for 8u222, based on > the tag jdk8u222-b01: > > https://openjdk-sources.osci.io/openjdk8/openjdk8u222-b01.tar.xz Hi, Please use an EA denotation as part of the file name in order to avoid confusing users about the GA status of the download. Please see earlier discussions on this list for rationale. cheers, dalibor topic > > The tarball is accompanied by a digital signature available at: > > https://openjdk-sources.osci.io/openjdk8/openjdk8u222-b01.tar.xz.sig > > This is signed by our new Red Hat OpenJDK key (openjdk at redhat.com): > > PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) > Fingerprint = CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F > > SHA256 checksums: > > 5319ca54aa176df306c30e03cfc008bc4831797c2f3fe22d2314f80f21fc7e4d > openjdk8u222-b01.tar.xz > 46664701ea0d6cf588ff379ee7134d83517d16fb3c2ad9036577f7a90dc5209f > openjdk8u222-b01.tar.xz.sig > > They are listed at > https://openjdk-sources.osci.io/openjdk8/openjdk8u222-b01.sha256 > -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | D-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-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From sgehwolf at redhat.com Mon May 6 09:36:54 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 06 May 2019 11:36:54 +0200 Subject: [8u] RFR: 8210416: [linux] Poor StrictMath performance due to non-optimized compilation In-Reply-To: <5d46c995-833f-7e95-b1f1-96d35ac8dc15@redhat.com> References: <2dce878b0d25f63974f2988f58d022d810af81bd.camel@redhat.com> <5d46c995-833f-7e95-b1f1-96d35ac8dc15@redhat.com> Message-ID: <4170180280af205679061e7d220b46b8769822ea.camel@redhat.com> Hi Andrew, Thanks for the review. Once I have jdk8u-fix-yes I'll push the patch. Cheers, Severin On Wed, 2019-05-01 at 07:02 +0100, Andrew John Hughes wrote: > On 30/04/2019 12:37, Severin Gehwolf wrote: > > Hi, > > > > Could I please get a review for this 8u backport related to fdlibm > > optimization on Linux? The JDK 12 patch doesn't apply as-is as the JDK > > 8 build system is drastically different from JDK 11+. > > > > It's not "drastically different" as regards the top-level and jdk areas. > HotSpot is another matter. > > The main difference in this change is we're supporting gcc < 4.6, which > is sensible. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210416 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/jdk8/02/ > > > > The main differences to the original fix are: a) optimization level and > > b) additional hook for older GCC. This backport keeps the optimization > > level at -O3 (HIGH) over -O2 (LOW) for JDK 8u as this would otherwise > > regress Linux ppc64{,le} which currently use -O3. As the current code > > has the implicit assumption of ppc64 being compiled on older GCCs too > > (JDK-8172053), this backport maintains compatibility in this regard. If > > -ffp-contract=off is not available, a machine specific set of flags is > > being used if the compiler supports them (-mno-fused-madd -fno-strict- > > aliasing). > > > > For older GCCs (< 4.6) specific machine flags are being used. That is, > > for ppc64{,le} and x86{,_64}. ppc64{,le} machine specific flags have > > already been determined (See JDK-8172053). x86_64 and x86 have the same > > machine specific flags available, so I've used them there too[1]. > > > > Testing: build/test on gcc 8.x Linux x86_64. build/test on gcc 4.4.7 > > x86_64/ppc64. Manual inspection of build logs for fdlibm files (e.g. > > w_asin.c). > > > > Thoughts? > > > > Thanks, > > Severin > > > > [1] https://gcc.gnu.org/onlinedocs/gcc-4.4.7/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options > > > > > > > > > > > > Looks good to me. This is how JDK-8172053 should have been handled to > begin with, rather than making assumptions (and indeed, that's how I > fixed it [0] [1]) > > [0] http://icedtea.classpath.org/hg/icedtea8-forest/rev/d5760f7cce54 > [1] http://icedtea.classpath.org/hg/icedtea8-forest/jdk/rev/3642a826880b From shade at redhat.com Mon May 6 10:21:56 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 6 May 2019 12:21:56 +0200 Subject: [8u] RFR (XS) 8134030: test/serviceability/dcmd/gc/HeapDumpTest fails to verify the dump Message-ID: <2a6ac1bb-47af-b39b-3c4f-5d3e2dddb021@redhat.com> Original fix: https://bugs.openjdk.java.net/browse/JDK-8134030 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2a591a32d924 There is nowhere to put the test in 8u, and the shape of affected code is a bit different. However, the patch itself is simple. It can also subsume one of the previous asserts by doing InstanceKlass::cast. 8u webrev: http://cr.openjdk.java.net/~shade/8134030/webrev.8u.01/ Testing: Linux x86_64 fastdebug; all hotspot jtregs -- Thanks, -Aleksey From thomas.schatzl at oracle.com Mon May 6 10:52:13 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 06 May 2019 12:52:13 +0200 Subject: [8u] RFR (S) 8217315: Proper units should print more significant digits In-Reply-To: References: Message-ID: Hi, On Fri, 2019-05-03 at 16:14 +0200, Aleksey Shipilev wrote: > Original RFE: > https://bugs.openjdk.java.net/browse/JDK-8217315 > http://hg.openjdk.java.net/jdk/jdk/rev/d5f6540c6bb1 > > Unfortunately, 8u does not have support for gtest, which means the > new regression test is not usable > there. I worked that around by putting the test into > ExecuteInternalVMTests block. > > 8u webrev: > http://cr.openjdk.java.net/~shade/8217315/webrev.8u.02/ > > Testing: hotspot_all, jdk_core; ad-hoc -XX:+ExecuteInternalVMTests > run > looks good. Thomas From andrey at azul.com Mon May 6 13:30:05 2019 From: andrey at azul.com (Andrey Petushkov) Date: Mon, 6 May 2019 13:30:05 +0000 Subject: jdk8u-jfr-incubator workspace, builds, webrevs In-Reply-To: References: Message-ID: <69D055DB-F302-4CFC-83AA-5CBD64334486@azul.com> Hi Alexey, That's great, thanks! And yes, no changes yet, due to long holiday week. Will publish first set hopefully today/tomorrow Regards, Andrey > On 1 May 2019, at 19:52, Aleksey Shipilev wrote: > > Hi, > > These are the things that might make your development life a bit easier with JFR backport. > > Mercurial snapshot: > https://builds.shipilev.net/workspaces/jdk8u-jdk8u-jfr-incubator.tar.xz > > Source snapshot: > https://builds.shipilev.net/source-snapshots/jdk8u-jdk8u-jfr-incubator.tar.xz > > Webrev with difference against jdk8u/jdk8u: > https://builds.shipilev.net/patch-openjdk-jdk8-jfr/ > > Builds (plus build logs in case of errors): > https://builds.shipilev.net/openjdk-jdk8-jfr/ > > Webrevs are currently empty, because there are no changes against upstream? > Builds are in progress and would show up in their full glory in a few hours. > > -- > Thanks, > -Aleksey > From serguei.spitsyn at oracle.com Tue May 7 02:14:32 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 6 May 2019 19:14:32 -0700 Subject: [8u] RFR (XS) 8134030: test/serviceability/dcmd/gc/HeapDumpTest fails to verify the dump In-Reply-To: <2a6ac1bb-47af-b39b-3c4f-5d3e2dddb021@redhat.com> References: <2a6ac1bb-47af-b39b-3c4f-5d3e2dddb021@redhat.com> Message-ID: <279e82bb-d068-78e0-736d-3d8907a54a5f@oracle.com> Hi Aleksey, The backport looks good to me. Thanks, Serguei On 5/6/19 03:21, Aleksey Shipilev wrote: > Original fix: > https://bugs.openjdk.java.net/browse/JDK-8134030 > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2a591a32d924 > > There is nowhere to put the test in 8u, and the shape of affected code is a bit different. However, > the patch itself is simple. It can also subsume one of the previous asserts by doing > InstanceKlass::cast. > > 8u webrev: > http://cr.openjdk.java.net/~shade/8134030/webrev.8u.01/ > > Testing: Linux x86_64 fastdebug; all hotspot jtregs > From felix.yang at huawei.com Tue May 7 02:57:48 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 7 May 2019 02:57:48 +0000 Subject: Request for Approval: Backport of 7100957: SOCKS proxying does not work with IPv6 connections Message-ID: Hi, Please approve the backport of 7100957 to 8u-dev. This bug is biting our software developers. Bug: https://bugs.openjdk.java.net/browse/JDK-7100957 JDK9 Changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/07aee60ef0a6 JDK9 Review Thread: http://mail.openjdk.java.net/pipermail/net-dev/2014-January/008100.html Changes apply cleanly to jdk8u-dev. Thanks, Felix From aph at redhat.com Tue May 7 10:17:02 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 7 May 2019 11:17:02 +0100 Subject: Request for Approval: Backport of 7100957: SOCKS proxying does not work with IPv6 connections In-Reply-To: References: Message-ID: On 5/7/19 3:57 AM, Yangfei (Felix) wrote: > Please approve the backport of 7100957 to 8u-dev. This bug is biting our software developers. > > Bug: https://bugs.openjdk.java.net/browse/JDK-7100957 > JDK9 Changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/07aee60ef0a6 > JDK9 Review Thread: http://mail.openjdk.java.net/pipermail/net-dev/2014-January/008100.html > > Changes apply cleanly to jdk8u-dev. OK. Please mark the bug with the label "jdk8u-fix-request" or it won't go in. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Tue May 7 10:46:29 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 7 May 2019 10:46:29 +0000 Subject: [8u, 11u]: Fix approvals, hgupdater status Message-ID: Hi Andrew, It seems like quite some fix requests have piled up in both, jdk8 and jdk11 updates. Is there any particular reason why the approvals are currently stalling (other than holidays)? ?? Furthermore, are there any updates from hgupdater for jdk11u and jdk8u repos? Thank you, Christoph From andrey at azul.com Tue May 7 11:20:15 2019 From: andrey at azul.com (Andrey Petushkov) Date: Tue, 7 May 2019 11:20:15 +0000 Subject: RFR: 8223147: JFR Backport (to jdk8u) In-Reply-To: References: Message-ID: <3E224264-DA96-48B8-8270-2B77B09E190F@azul.com> Hi All, RFR for initial JFR backport to current state of jdk8u-jfr-incubator is here http://cr.openjdk.java.net/~apetushkov/8223147/ Please could you review and hopefully approve The changes are the same as in initial review request [1] except two fixes were added for the bugs found after integration of Alibaba's implementation of thread sampling (note that according to the plan Alibaba's patches are not included into this RFR) The webrev includes bug ids for all changes backported under it, however these are not separated on per-file basis One process question (thus Andrew in To), the new webrev currently only includes the code which applies to jdk8u-jfr-incubator repo, but what about aarch64 and aarch32 ports which are not available there? I don't see a reason to prevent them from having JFR and there is code ready for that ([1]). How could we proceed with integration of it? Thanks, Andrey [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-February/008576.html > On 30 Apr 2019, at 18:49, Mario Torre wrote: > > On Tue, Apr 30, 2019 at 5:27 PM Andrew John Hughes > wrote: >> >> >> >> On 30/04/2019 16:19, Mario Torre wrote: >>> On Tue, Apr 30, 2019 at 5:15 PM Andrew John Hughes >>> wrote: >>>> >>>> >>>> >>>> On 30/04/2019 11:29, Mario Torre wrote: >>>>> Hi all, >>>>> >>>>> I have sync'ed up jdku-dev post security with our staging repository: >>>>> >>>>> https://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/ >>>>> >>>>> After discussing with Andrew we decided to be best to create a new bug >>>>> rather than reusing the existing JFR and mark them as backports, so I >>>>> went ahead and created it: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8223147 >>>>> >>>> >>>> Doesn't this mean that an issue won't show up as having been backported >>>> to 8u when it has? >>> >>> Yes, this is why the initial thought was to have the backports bug, >>> however this feature doesn't have one specific bug for the backport, >>> it's more like a multitude of the bugs and doesn't apply cleanly >>> either, so we decided to just have a separate bug to encompass >>> everything else. I'm not sure what else we can do, what do you think? >>> >>> Cheers, >>> Mario >>> >> >> Note that you can mention multiple bug IDs in a commit: >> >> https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/bc0a3a91a074 >> >> From my experience with a similar situation with getting the PPC port >> into OpenJDK 7, I'd say a hybrid solution is the best option; use a >> unique bug for the initial backport of the feature, but import later bug >> fixes using the same changeset+bug ID relationship. >> >> e.g. >> >> there is: >> >> https://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/de5e8c8a9b87 >> >> and then a run of other bugs: >> >> https://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/ccb68f77d07a >> https://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/ccb68f77d07a >> https://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/f2f5a053bd0d >> etc. >> >> >> Where possible, it's best to avoid the problem where someone does 'log >> -k ', can't find it in the repo, starts to backport it and then >> realises it's there in disguise :) > > That makes sense, and I'm all for going towards what makes the > maintainers life easier. > > We can use the bug ID I created and then reference individual fixes > one by one or go back to the first plan and use multiple bug ids (or > just the core jfr even if the patch is reworked). > > Andrew Haley, what do you think? Given that this will be merged into > 8u-dev at some point I think this should be really your decision on > what bug to use. > > Cheers, > Mario > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From felix.yang at huawei.com Tue May 7 11:30:51 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 7 May 2019 11:30:51 +0000 Subject: Request for Approval: Backport of 7100957: SOCKS proxying does not work with IPv6 connections In-Reply-To: References: Message-ID: Done. Now it has the "jdk8u-fix-request" label. Thanks for approving this. Felix > > On 5/7/19 3:57 AM, Yangfei (Felix) wrote: > > Please approve the backport of 7100957 to 8u-dev. This bug is biting our > software developers. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-7100957 > > JDK9 Changeset: > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/07aee60ef0a6 > > JDK9 Review Thread: > http://mail.openjdk.java.net/pipermail/net-dev/2014-January/008100.html > > > > Changes apply cleanly to jdk8u-dev. > > OK. Please mark the bug with the label "jdk8u-fix-request" or it won't go in. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From andrey at azul.com Tue May 7 11:42:20 2019 From: andrey at azul.com (Andrey Petushkov) Date: Tue, 7 May 2019 11:42:20 +0000 Subject: RFR: 8223147: JFR Backport (to jdk8u) In-Reply-To: <3E224264-DA96-48B8-8270-2B77B09E190F@azul.com> References: <3E224264-DA96-48B8-8270-2B77B09E190F@azul.com> Message-ID: <351D8DC2-D5FB-48F3-A60A-A10F97F7B640@azul.com> In addition, Ekaterina Vergizova from Azul Systems (katya at azul.com) has backported bunch of JFR fixes atop of initial integration. The fixes are: 8041626: Shutdown tracing event 8165675: Trace event for thread park has incorrect unit for timeout 8202578: Revisit location for class unload events 8205516: JFR tool 8207829: FlightRecorderMXBeanImpl is leaking the first classloader which calls it 8210024: JFR calls virtual is_Java_thread from ~Thread() 8211239: Build fails without JFR: empty JFR events signatures mismatch 8212232: Wrong metadata for the configuration of the cutoff for old object sample events 8213015: Inconsistent settings between JFR.configure and -XX:FlightRecorderOptions 8213421: Line number information for execution samples always 0 8213617: JFR should record the PID of the recorded process 8213914: [TESTBUG] Several JFR VM events are not covered by tests 8213917: [TESTBUG] Shutdown JFR event is not covered by test 8213966: The ZGC JFR events should be marked as experimental 8214750: Unnecessary

tags in jfr classes 8214896: JFR Tool left files behind 8214906: [TESTBUG] jfr/event/sampling/TestNative.java fails with UnsatisfiedLinkError 8214925: JFR tool fails to execute 8215175: Inconsistencies in JFR event metadata 8215237: jdk.jfr.Recording javadoc does not compile 8215284: Reduce noise induced by periodic task getFileSize() 8215362: JFR GTest JfrTestNetworkUtilization fails 8215771: The jfr tool should pretty print reference chains 8216486: Possibility of integer overflow in JfrThreadSampler::run() 8216559: [JFR] Native libraries not correctly parsed from /proc/self/maps 8216578: Remove unused/obsolete method in JFR code 8216995: Clean up JFR command line processing 8217744: [TESTBUG] JFR TestShutdownEvent fails on some systems due to process surviving SIGINT 8217748: [TESTBUG] Exclude TestSig test case from JFR TestShutdownEvent 8218935: Make jfr strncpy uses GCC 8.x friendly Please could you also review these backports here http://cr.openjdk.java.net/~apetushkov/jfr_backports_katya/ That is single webrev but created from set of individual commits. If one would like to see individual webrevs please let us know Relevant JFR jtreg tests have passed on all supported platforms Thanks, Andrey > On 7 May 2019, at 14:20, Andrey Petushkov wrote: > > Hi All, > > RFR for initial JFR backport to current state of jdk8u-jfr-incubator is here http://cr.openjdk.java.net/~apetushkov/8223147/ > Please could you review and hopefully approve > > The changes are the same as in initial review request [1] except two fixes were added for the bugs found after integration > of Alibaba's implementation of thread sampling (note that according to the plan Alibaba's patches are not included into this RFR) > The webrev includes bug ids for all changes backported under it, however these are not separated on per-file basis > > One process question (thus Andrew in To), the new webrev currently only includes the code which applies to jdk8u-jfr-incubator > repo, but what about aarch64 and aarch32 ports which are not available there? I don't see a reason to prevent them from > having JFR and there is code ready for that ([1]). How could we proceed with integration of it? > > Thanks, > Andrey > > [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-February/008576.html > >> On 30 Apr 2019, at 18:49, Mario Torre wrote: >> >> On Tue, Apr 30, 2019 at 5:27 PM Andrew John Hughes >> wrote: >>> >>> >>> >>> On 30/04/2019 16:19, Mario Torre wrote: >>>> On Tue, Apr 30, 2019 at 5:15 PM Andrew John Hughes >>>> wrote: >>>>> >>>>> >>>>> >>>>> On 30/04/2019 11:29, Mario Torre wrote: >>>>>> Hi all, >>>>>> >>>>>> I have sync'ed up jdku-dev post security with our staging repository: >>>>>> >>>>>> https://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/ >>>>>> >>>>>> After discussing with Andrew we decided to be best to create a new bug >>>>>> rather than reusing the existing JFR and mark them as backports, so I >>>>>> went ahead and created it: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8223147 >>>>>> >>>>> >>>>> Doesn't this mean that an issue won't show up as having been backported >>>>> to 8u when it has? >>>> >>>> Yes, this is why the initial thought was to have the backports bug, >>>> however this feature doesn't have one specific bug for the backport, >>>> it's more like a multitude of the bugs and doesn't apply cleanly >>>> either, so we decided to just have a separate bug to encompass >>>> everything else. I'm not sure what else we can do, what do you think? >>>> >>>> Cheers, >>>> Mario >>>> >>> >>> Note that you can mention multiple bug IDs in a commit: >>> >>> https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/bc0a3a91a074 >>> >>> From my experience with a similar situation with getting the PPC port >>> into OpenJDK 7, I'd say a hybrid solution is the best option; use a >>> unique bug for the initial backport of the feature, but import later bug >>> fixes using the same changeset+bug ID relationship. >>> >>> e.g. >>> >>> there is: >>> >>> https://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/de5e8c8a9b87 >>> >>> and then a run of other bugs: >>> >>> https://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/ccb68f77d07a >>> https://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/ccb68f77d07a >>> https://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/f2f5a053bd0d >>> etc. >>> >>> >>> Where possible, it's best to avoid the problem where someone does 'log >>> -k ', can't find it in the repo, starts to backport it and then >>> realises it's there in disguise :) >> >> That makes sense, and I'm all for going towards what makes the >> maintainers life easier. >> >> We can use the bug ID I created and then reference individual fixes >> one by one or go back to the first plan and use multiple bug ids (or >> just the core jfr even if the patch is reworked). >> >> Andrew Haley, what do you think? Given that this will be merged into >> 8u-dev at some point I think this should be really your decision on >> what bug to use. >> >> Cheers, >> Mario >> >> -- >> Mario Torre >> Associate Manager, Software Engineering >> Red Hat GmbH >> 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > From aph at redhat.com Tue May 7 13:33:37 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 7 May 2019 14:33:37 +0100 Subject: [8u, 11u]: Fix approvals, hgupdater status In-Reply-To: References: Message-ID: <3e709bdb-bdd9-e999-2727-034d6515f1d2@redhat.com> On 5/7/19 11:46 AM, Langer, Christoph wrote: > It seems like quite some fix requests have piled up in both, jdk8 and jdk11 updates. Is there any particular reason why the approvals are currently stalling (other than holidays)? ?? Probably. > Furthermore, are there any updates from hgupdater for jdk11u and jdk8u repos? All done. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From neugens at redhat.com Tue May 7 13:52:19 2019 From: neugens at redhat.com (Mario Torre) Date: Tue, 7 May 2019 15:52:19 +0200 Subject: RFR: 8223147: JFR Backport (to jdk8u) In-Reply-To: <3E224264-DA96-48B8-8270-2B77B09E190F@azul.com> References: <3E224264-DA96-48B8-8270-2B77B09E190F@azul.com> Message-ID: On Tue, May 7, 2019 at 1:20 PM Andrey Petushkov wrote: > > Hi All, Hi Andrey, thanks for the patch! > RFR for initial JFR backport to current state of jdk8u-jfr-incubator is here http://cr.openjdk.java.net/~apetushkov/8223147/ > Please could you review and hopefully approve I'm going through it now, I'll get back to you as soon as possible! > The changes are the same as in initial review request [1] except two fixes were added for the bugs found after integration > of Alibaba's implementation of thread sampling (note that according to the plan Alibaba's patches are not included into this RFR) > The webrev includes bug ids for all changes backported under it, however these are not separated on per-file basis This is perfect, so we have proper tracking of the patches. > One process question (thus Andrew in To), the new webrev currently only includes the code which applies to jdk8u-jfr-incubator > repo, but what about aarch64 and aarch32 ports which are not available there? I don't see a reason to prevent them from > having JFR and there is code ready for that ([1]). How could we proceed with integration of it? You are right, it didn't occur to me that this code was not part of the repository, but this is because the staging repo is forked from jdk8u-dev which doesn't contain those ports. I think we should indeed backport the other changes, perhaps once everything is in mainline we can push into the shenandoah/arm/etc... repositories individual patches? Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From andrey.petushkov at gmail.com Tue May 7 13:53:33 2019 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Tue, 7 May 2019 16:53:33 +0300 Subject: [8u-dev] RFR+RFA (M): JDK-8176100: [REDO][REDO] G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: <20665D4C-C717-4FE3-93B3-149378615B26@amazon.com> References: <8A7A3619-56E2-4E19-A1E0-BA47CBB5BAE4@amazon.com> <25EF3922-AC36-4D6F-B5D6-49B202A44986@amazon.com> <84e8f725-ae22-a6ce-355c-713141b9bcdd@redhat.com> <9EEBDA2A-196F-40AC-AE42-8C0D69E94025@azul.com> <20665D4C-C717-4FE3-93B3-149378615B26@amazon.com> Message-ID: Hi Paul, All, hotspot/test/runtime tests for the build with the patch have passed on e6500-based machine Regards, Andrey On Wed, May 1, 2019 at 12:36 AM Hohensee, Paul wrote: > Thank you, Dmitry. Now we just need ppc results. > > Paul > > ?On 4/29/19, 11:59 PM, "jdk8u-dev on behalf of Dmitry Cherepanov" < > jdk8u-dev-bounces at openjdk.java.net on behalf of dcherepanov at azul.com> > wrote: > > Hi Paul, Andrew, > > I tested this with Solaris builds (x86_64 and sparc) and the results > look good. The build passed and running jtreg?s tests > (hotspot/test/runtime) didn?t reveal any regression. > > Thanks, > > Dmitry > > > On Apr 24, 2019, at 7:38 AM, Andrew John Hughes < > gnu.andrew at redhat.com> wrote: > > > > On 23/04/2019 19:15, Hohensee, Paul wrote: > >> Ping. And, may I have a jdk8u-fix-yes tag? > >> > >> On 4/11/19, 2:38 PM, "jdk8u-dev on behalf of Hohensee, Paul" < > jdk8u-dev-bounces at openjdk.java.net on behalf of hohensee at amazon.com> > wrote: > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8176100 > >> Webrev: http://cr.openjdk.java.net/~phh/8176100/webrev.8u.01/ > >> > >> Original patch: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/b163435e40b3 > >> > >> Patch applies cleanly net of file names and line numbers, except > that shell scripts are necessary for jdk8 to run the two new tests. Also, I > don?t have facilities to test x86 32-bit, sparc or ppc, so I?d greatly > appreciate someone trying it on those platforms. > >> > >> Thanks, > >> > >> Paul > >> > >> > >> > > > > I saw the original post, but I'm waiting on the review outcome before > > approving a patch of this size with arch-specific changes. > > > > I'd also like to see some response with regards x86 & ppc. I think > sparc > > may lack support, going forward, and I don't think Oracle were even > > particularly maintaining Linux+SPARC. Last time I asked around, I > > couldn't find anyone with a machine to test it on. It looks like > there > > may be some in the GCC compile farm now [0], so I'll try and take a > > look, unless anyone has any better offers. > > > > [0] https://cfarm.tetaneutral.net/machines/list/ > > -- > > Andrew :) > > > > Senior Free Java Software Engineer > > Red Hat, Inc. (http://www.redhat.com) > > > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > > https://keybase.io/gnu_andrew > > > > From neugens at redhat.com Tue May 7 13:55:09 2019 From: neugens at redhat.com (Mario Torre) Date: Tue, 7 May 2019 15:55:09 +0200 Subject: RFR: 8223147: JFR Backport (to jdk8u) In-Reply-To: <351D8DC2-D5FB-48F3-A60A-A10F97F7B640@azul.com> References: <3E224264-DA96-48B8-8270-2B77B09E190F@azul.com> <351D8DC2-D5FB-48F3-A60A-A10F97F7B640@azul.com> Message-ID: Thanks for the work once again, I'll look at these after the main patch is reviewed Cheers, Mario On Tue, May 7, 2019 at 1:42 PM Andrey Petushkov wrote: > > In addition, Ekaterina Vergizova from Azul Systems (katya at azul.com) has backported bunch of JFR fixes atop of initial > integration. The fixes are: > > 8041626: Shutdown tracing event > 8165675: Trace event for thread park has incorrect unit for timeout > 8202578: Revisit location for class unload events > 8205516: JFR tool > 8207829: FlightRecorderMXBeanImpl is leaking the first classloader which calls it > 8210024: JFR calls virtual is_Java_thread from ~Thread() > 8211239: Build fails without JFR: empty JFR events signatures mismatch > 8212232: Wrong metadata for the configuration of the cutoff for old object sample events > 8213015: Inconsistent settings between JFR.configure and -XX:FlightRecorderOptions > 8213421: Line number information for execution samples always 0 > 8213617: JFR should record the PID of the recorded process > 8213914: [TESTBUG] Several JFR VM events are not covered by tests > 8213917: [TESTBUG] Shutdown JFR event is not covered by test > 8213966: The ZGC JFR events should be marked as experimental > 8214750: Unnecessary

tags in jfr classes > 8214896: JFR Tool left files behind > 8214906: [TESTBUG] jfr/event/sampling/TestNative.java fails with UnsatisfiedLinkError > 8214925: JFR tool fails to execute > 8215175: Inconsistencies in JFR event metadata > 8215237: jdk.jfr.Recording javadoc does not compile > 8215284: Reduce noise induced by periodic task getFileSize() > 8215362: JFR GTest JfrTestNetworkUtilization fails > 8215771: The jfr tool should pretty print reference chains > 8216486: Possibility of integer overflow in JfrThreadSampler::run() > 8216559: [JFR] Native libraries not correctly parsed from /proc/self/maps > 8216578: Remove unused/obsolete method in JFR code > 8216995: Clean up JFR command line processing > 8217744: [TESTBUG] JFR TestShutdownEvent fails on some systems due to process surviving SIGINT > 8217748: [TESTBUG] Exclude TestSig test case from JFR TestShutdownEvent > 8218935: Make jfr strncpy uses GCC 8.x friendly > > Please could you also review these backports here http://cr.openjdk.java.net/~apetushkov/jfr_backports_katya/ > That is single webrev but created from set of individual commits. If one would like to see individual webrevs please let us know > Relevant JFR jtreg tests have passed on all supported platforms > > Thanks, > Andrey > > > On 7 May 2019, at 14:20, Andrey Petushkov wrote: > > > > Hi All, > > > > RFR for initial JFR backport to current state of jdk8u-jfr-incubator is here http://cr.openjdk.java.net/~apetushkov/8223147/ > > Please could you review and hopefully approve > > > > The changes are the same as in initial review request [1] except two fixes were added for the bugs found after integration > > of Alibaba's implementation of thread sampling (note that according to the plan Alibaba's patches are not included into this RFR) > > The webrev includes bug ids for all changes backported under it, however these are not separated on per-file basis > > > > One process question (thus Andrew in To), the new webrev currently only includes the code which applies to jdk8u-jfr-incubator > > repo, but what about aarch64 and aarch32 ports which are not available there? I don't see a reason to prevent them from > > having JFR and there is code ready for that ([1]). How could we proceed with integration of it? > > > > Thanks, > > Andrey > > > > [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-February/008576.html > > > >> On 30 Apr 2019, at 18:49, Mario Torre wrote: > >> > >> On Tue, Apr 30, 2019 at 5:27 PM Andrew John Hughes > >> wrote: > >>> > >>> > >>> > >>> On 30/04/2019 16:19, Mario Torre wrote: > >>>> On Tue, Apr 30, 2019 at 5:15 PM Andrew John Hughes > >>>> wrote: > >>>>> > >>>>> > >>>>> > >>>>> On 30/04/2019 11:29, Mario Torre wrote: > >>>>>> Hi all, > >>>>>> > >>>>>> I have sync'ed up jdku-dev post security with our staging repository: > >>>>>> > >>>>>> https://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/ > >>>>>> > >>>>>> After discussing with Andrew we decided to be best to create a new bug > >>>>>> rather than reusing the existing JFR and mark them as backports, so I > >>>>>> went ahead and created it: > >>>>>> > >>>>>> https://bugs.openjdk.java.net/browse/JDK-8223147 > >>>>>> > >>>>> > >>>>> Doesn't this mean that an issue won't show up as having been backported > >>>>> to 8u when it has? > >>>> > >>>> Yes, this is why the initial thought was to have the backports bug, > >>>> however this feature doesn't have one specific bug for the backport, > >>>> it's more like a multitude of the bugs and doesn't apply cleanly > >>>> either, so we decided to just have a separate bug to encompass > >>>> everything else. I'm not sure what else we can do, what do you think? > >>>> > >>>> Cheers, > >>>> Mario > >>>> > >>> > >>> Note that you can mention multiple bug IDs in a commit: > >>> > >>> https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/bc0a3a91a074 > >>> > >>> From my experience with a similar situation with getting the PPC port > >>> into OpenJDK 7, I'd say a hybrid solution is the best option; use a > >>> unique bug for the initial backport of the feature, but import later bug > >>> fixes using the same changeset+bug ID relationship. > >>> > >>> e.g. > >>> > >>> there is: > >>> > >>> https://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/de5e8c8a9b87 > >>> > >>> and then a run of other bugs: > >>> > >>> https://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/ccb68f77d07a > >>> https://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/ccb68f77d07a > >>> https://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/f2f5a053bd0d > >>> etc. > >>> > >>> > >>> Where possible, it's best to avoid the problem where someone does 'log > >>> -k ', can't find it in the repo, starts to backport it and then > >>> realises it's there in disguise :) > >> > >> That makes sense, and I'm all for going towards what makes the > >> maintainers life easier. > >> > >> We can use the bug ID I created and then reference individual fixes > >> one by one or go back to the first plan and use multiple bug ids (or > >> just the core jfr even if the patch is reworked). > >> > >> Andrew Haley, what do you think? Given that this will be merged into > >> 8u-dev at some point I think this should be really your decision on > >> what bug to use. > >> > >> Cheers, > >> Mario > >> > >> -- > >> Mario Torre > >> Associate Manager, Software Engineering > >> Red Hat GmbH > >> 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From goetz.lindenmaier at sap.com Tue May 7 13:58:15 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 7 May 2019 13:58:15 +0000 Subject: [8u, 11u]: Fix approvals, hgupdater status In-Reply-To: <3e709bdb-bdd9-e999-2727-034d6515f1d2@redhat.com> References: <3e709bdb-bdd9-e999-2727-034d6515f1d2@redhat.com> Message-ID: Hi Andrew, thanks for driving the hgupdater issue. I will carefully pull jdk11u-dev to jdk11u tomorrow after tagging. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Andrew Haley > Sent: Dienstag, 7. Mai 2019 15:34 > To: Langer, Christoph > Cc: 'jdk8u-dev at openjdk.java.net' ; jdk-updates- > dev at openjdk.java.net > Subject: Re: [8u, 11u]: Fix approvals, hgupdater status > > On 5/7/19 11:46 AM, Langer, Christoph wrote: > > It seems like quite some fix requests have piled up in both, jdk8 and jdk11 > updates. Is there any particular reason why the approvals are currently stalling > (other than holidays)? ?? > > Probably. > > > Furthermore, are there any updates from hgupdater for jdk11u and jdk8u > repos? > > All done. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Tue May 7 14:13:46 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 7 May 2019 14:13:46 +0000 Subject: [8u, 11u]: Fix approvals, hgupdater status In-Reply-To: References: <3e709bdb-bdd9-e999-2727-034d6515f1d2@redhat.com> Message-ID: Thanks, Andrew. Let's keep fingers crossed that all works when pulling over. Otherwise we'll have to go through several dozens of false 11.0.3 backport items and fix them manually. /Christoph > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Dienstag, 7. Mai 2019 15:58 > To: Andrew Haley ; Langer, Christoph > > Cc: 'jdk8u-dev at openjdk.java.net' ; jdk- > updates-dev at openjdk.java.net > Subject: RE: [8u, 11u]: Fix approvals, hgupdater status > > Hi Andrew, > > thanks for driving the hgupdater issue. > I will carefully pull jdk11u-dev to jdk11u tomorrow after tagging. > > Best regards, > Goetz. > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Andrew Haley > > Sent: Dienstag, 7. Mai 2019 15:34 > > To: Langer, Christoph > > Cc: 'jdk8u-dev at openjdk.java.net' ; jdk- > updates- > > dev at openjdk.java.net > > Subject: Re: [8u, 11u]: Fix approvals, hgupdater status > > > > On 5/7/19 11:46 AM, Langer, Christoph wrote: > > > It seems like quite some fix requests have piled up in both, jdk8 and > jdk11 > > updates. Is there any particular reason why the approvals are currently > stalling > > (other than holidays)? ?? > > > > Probably. > > > > > Furthermore, are there any updates from hgupdater for jdk11u and > jdk8u > > repos? > > > > All done. > > > > -- > > Andrew Haley > > Java Platform Lead Engineer > > Red Hat UK Ltd. > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Tue May 7 14:15:15 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 7 May 2019 14:15:15 +0000 Subject: [8u] RFR: 8189131: Open-source the Oracle JDK Root Certificates (Integration for JEP 319: Root Certificates) In-Reply-To: References: Message-ID: Ping: can I please have a review for this? From: Langer, Christoph Sent: Donnerstag, 2. Mai 2019 14:55 To: 'jdk8u-dev at openjdk.java.net' ; security-dev Subject: [8u] RFR: 8189131: Open-source the Oracle JDK Root Certificates (Integration for JEP 319: Root Certificates) Hi, as was already discussed and requested on the mailing lists ([0], [1]), I hereby propose a change to add the root certificates of upstream OpenJDK to OpenJDK 8 updates. The main bug that (initially) brought the Oracle certificates to OpenJDK is 8189131: Open-source the Oracle JDK Root Certificates [2]. My proposed change will also backport all updates to the contents of cacerts since then: 8191844: Remove SECOM root (secomevrootca1) 8189949: Remove Baltimore Cybertrust Code Signing CA 8191031: Remove several Symantec Root CAs 8196141: Add GoDaddy root certificates 8204923: Restore Symantec root verisignclass2g2ca 8195774: Add Entrust root certificates 8199779: Add T-Systems, GlobalSign and Starfield services root certificates 8209506: Add Google Trust Services GlobalSign root certificates 8210432: Add additional TeliaSonera root certificate 8195793: Remove GTE CyberTrust Global Root 8216577: Add GlobalSign's R6 Root certificate 8222137: Remove T-Systems root CA certificate Please find the webrev here: http://cr.openjdk.java.net/~clanger/webrevs/8189131.8u/ I took the current state of cacerts from the jdk/jdk repo along with the provided testcases and brought them down to the jdk8 repository layout. To make the test run in JDK8, I had to a) modify test/sun/security/lib/cacerts/VerifyCACerts.java: 240 private static final HashSet EXPIRY_EXC_ENTRIES = new HashSet() { I needed to add the String type to the constructor of the HashSet, since the JDK8 java compiler will not accept <> in that place. b) modify test/security/infra/java/security/cert/CertPathValidator/certification/ValidatePathWithParams.java 60 private static final String CACERTS_STORE = System.getProperty("test.jdk") 61 + FS + "jre" + FS + "lib" + FS + "security" + FS + "cacerts"; I needed to adapt the path to cacerts in a JDK8 JDK/JRE as it is located in subdirectory jre there. Out of the tests in test/security/infra/java/security/cert/CertPathValidator/certification, there are 2 failing: FAILED: security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java FAILED: security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java However, for jdk/jdk it is the same. JBS Issues for these tests exist and are yet unresolved: JDK-8202651 and JDK-8215546. Since the tests don't seem to be part of any tier, I propose to include them in this backport and later on also backport possible fixes to them. Thanks Christoph [0] https://mail.openjdk.java.net/pipermail/security-dev/2019-March/019557.html [1] https://mail.openjdk.java.net/pipermail/security-dev/2019-April/019733.html [2] https://bugs.openjdk.java.net/browse/JDK-8189131 From shade at redhat.com Tue May 7 19:00:15 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 7 May 2019 21:00:15 +0200 Subject: [8u] RFR (S) 8217315: Proper units should print more significant digits In-Reply-To: References: Message-ID: <3028bad2-a685-fb60-f9bc-5b5e43423835@redhat.com> On 5/6/19 12:52 PM, Thomas Schatzl wrote: > On Fri, 2019-05-03 at 16:14 +0200, Aleksey Shipilev wrote: >> Original RFE: >> https://bugs.openjdk.java.net/browse/JDK-8217315 >> http://hg.openjdk.java.net/jdk/jdk/rev/d5f6540c6bb1 >> >> Unfortunately, 8u does not have support for gtest, which means the >> new regression test is not usable >> there. I worked that around by putting the test into >> ExecuteInternalVMTests block. >> >> 8u webrev: >> http://cr.openjdk.java.net/~shade/8217315/webrev.8u.02/ >> >> Testing: hotspot_all, jdk_core; ad-hoc -XX:+ExecuteInternalVMTests >> run >> > > looks good. Thanks! -Aleksey From shade at redhat.com Tue May 7 19:00:36 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 7 May 2019 21:00:36 +0200 Subject: [8u] RFR (XS) 8134030: test/serviceability/dcmd/gc/HeapDumpTest fails to verify the dump In-Reply-To: <279e82bb-d068-78e0-736d-3d8907a54a5f@oracle.com> References: <2a6ac1bb-47af-b39b-3c4f-5d3e2dddb021@redhat.com> <279e82bb-d068-78e0-736d-3d8907a54a5f@oracle.com> Message-ID: <27190153-c2da-9a2c-1354-b7725fb7de74@redhat.com> Thanks! -Aleksey On 5/7/19 4:14 AM, serguei.spitsyn at oracle.com wrote: > Hi Aleksey, > > The backport looks good to me. > > Thanks, > Serguei > > > On 5/6/19 03:21, Aleksey Shipilev wrote: >> Original fix: >> ?? https://bugs.openjdk.java.net/browse/JDK-8134030 >> ?? http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2a591a32d924 >> >> There is nowhere to put the test in 8u, and the shape of affected code is a bit different. However, >> the patch itself is simple. It can also subsume one of the previous asserts by doing >> InstanceKlass::cast. >> >> 8u webrev: >> ?? http://cr.openjdk.java.net/~shade/8134030/webrev.8u.01/ >> >> Testing: Linux x86_64 fastdebug; all hotspot jtregs >> > From hohensee at amazon.com Tue May 7 20:45:28 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 7 May 2019 20:45:28 +0000 Subject: [8u-dev] RFR+RFA (M): JDK-8176100: [REDO][REDO] G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: References: <8A7A3619-56E2-4E19-A1E0-BA47CBB5BAE4@amazon.com> <25EF3922-AC36-4D6F-B5D6-49B202A44986@amazon.com> <84e8f725-ae22-a6ce-355c-713141b9bcdd@redhat.com> <9EEBDA2A-196F-40AC-AE42-8C0D69E94025@azul.com> <20665D4C-C717-4FE3-93B3-149378615B26@amazon.com> Message-ID: <59753B34-E56C-46B5-9AF6-4B1F8001CE00@amazon.com> Thank you, Andrey. Pushed in my name since the author, Mikael Gerdin, is inactive. From: Andrey Petushkov Date: Tuesday, May 7, 2019 at 6:54 AM To: "Hohensee, Paul" Cc: Dmitry Cherepanov , Andrew Hughes , "jdk8u-dev at openjdk.java.net" Subject: Re: [8u-dev] RFR+RFA (M): JDK-8176100: [REDO][REDO] G1 Needs pre barrier on dereference of weak JNI handles Hi Paul, All, hotspot/test/runtime tests for the build with the patch have passed on e6500-based machine Regards, Andrey On Wed, May 1, 2019 at 12:36 AM Hohensee, Paul > wrote: Thank you, Dmitry. Now we just need ppc results. Paul On 4/29/19, 11:59 PM, "jdk8u-dev on behalf of Dmitry Cherepanov" on behalf of dcherepanov at azul.com> wrote: Hi Paul, Andrew, I tested this with Solaris builds (x86_64 and sparc) and the results look good. The build passed and running jtreg?s tests (hotspot/test/runtime) didn?t reveal any regression. Thanks, Dmitry > On Apr 24, 2019, at 7:38 AM, Andrew John Hughes > wrote: > > On 23/04/2019 19:15, Hohensee, Paul wrote: >> Ping. And, may I have a jdk8u-fix-yes tag? >> >> On 4/11/19, 2:38 PM, "jdk8u-dev on behalf of Hohensee, Paul" on behalf of hohensee at amazon.com> wrote: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8176100 >> Webrev: http://cr.openjdk.java.net/~phh/8176100/webrev.8u.01/ >> >> Original patch: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/b163435e40b3 >> >> Patch applies cleanly net of file names and line numbers, except that shell scripts are necessary for jdk8 to run the two new tests. Also, I don?t have facilities to test x86 32-bit, sparc or ppc, so I?d greatly appreciate someone trying it on those platforms. >> >> Thanks, >> >> Paul >> >> >> > > I saw the original post, but I'm waiting on the review outcome before > approving a patch of this size with arch-specific changes. > > I'd also like to see some response with regards x86 & ppc. I think sparc > may lack support, going forward, and I don't think Oracle were even > particularly maintaining Linux+SPARC. Last time I asked around, I > couldn't find anyone with a machine to test it on. It looks like there > may be some in the GCC compile farm now [0], so I'll try and take a > look, unless anyone has any better offers. > > [0] https://cfarm.tetaneutral.net/machines/list/ > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew From aph at redhat.com Wed May 8 08:15:37 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 8 May 2019 09:15:37 +0100 Subject: JFR backport status In-Reply-To: References: Message-ID: <0ccc9609-4fef-c84c-0731-ce4384873a2f@redhat.com> On 4/30/19 4:49 PM, Mario Torre wrote: > That makes sense, and I'm all for going towards what makes the > maintainers life easier. > > We can use the bug ID I created and then reference individual fixes > one by one or go back to the first plan and use multiple bug ids (or > just the core jfr even if the patch is reworked). > > Andrew Haley, what do you think? Given that this will be merged into > 8u-dev at some point I think this should be really your decision on > what bug to use. As long as all of the bug IDs are marked as having been merged into JDK 8u I'm happy. Having a master bug ID for the port makes sense too, so there's nothing that's ideal. You're the hard-working miners at the coal face, so in the end it has to be whatever you're comfortable with. I'll note that, again, our development process seems to be determined by the need to keep the tooling happy... -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From neugens at redhat.com Wed May 8 12:24:05 2019 From: neugens at redhat.com (Mario Torre) Date: Wed, 8 May 2019 14:24:05 +0200 Subject: RFR: 8223147: JFR Backport (to jdk8u) In-Reply-To: References: <3E224264-DA96-48B8-8270-2B77B09E190F@azul.com> Message-ID: Hi Andrey, There are a few things I wanted to point out about this patch. Overall, it seems good to me, of course not being different than what we already pre-reviewed. There are a couple of points however that we need to address, I think they should be addressed before the patch is in, but I'm open for discussions. By default, when I compile without jfr (without --enable-jfr) there should be no reference to JFR in the resulting image, but this is not the case. For example, in the resulting images/j2sdk-image/jre/lib library I can still see jfr.jar and a jfr directory with the jfr templates next to the rest of the libraries. I think this should be removed (a step at the end of the compilation process will do I think, if it's too cumbersome to not generate those in the first place). What's more is that the presence of JFR sneaks into the JDK at runtime. For example, the attached applications when run on a default build of OpenJDK 8 produces the following exception: Exception in thread "main" javax.management.RuntimeMBeanException: java.lang.IllegalArgumentException: VM option "FlightRecorder" does not exist at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrow(DefaultMBeanServerInterceptor.java:839) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrowMaybeMBeanException(DefaultMBeanServerInterceptor.java:852) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:821) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) at CheckJFR.main(CheckJFR.java:15) Caused by: java.lang.IllegalArgumentException: VM option "FlightRecorder" does not exist at sun.management.HotSpotDiagnostic.getVMOption(HotSpotDiagnostic.java:83) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275) at com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:193) at com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:175) at com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:117) at com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:54) at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237) at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252) at javax.management.StandardMBean.invoke(StandardMBean.java:405) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) ... 2 more When running against the jdk8u-jfr-incubator build instead produces "false". If I run with the -XX:+FlightRecorder I even get a "true" although I then can't request a flight recorder via JMC or the mbean interface, while a standard build would give me "Unrecognized VM option 'FlightRecorder'" in this case. I think we should fix this before merging (and please, do feel free to add this small snippet of code as a test case in the patch). I'll try to give more useful feedback as I keep on testing. Cheers, Mario On Tue, May 7, 2019 at 3:52 PM Mario Torre wrote: > > On Tue, May 7, 2019 at 1:20 PM Andrey Petushkov wrote: > > > > Hi All, > > Hi Andrey, thanks for the patch! > > > RFR for initial JFR backport to current state of jdk8u-jfr-incubator is here http://cr.openjdk.java.net/~apetushkov/8223147/ > > Please could you review and hopefully approve > > I'm going through it now, I'll get back to you as soon as possible! > > > The changes are the same as in initial review request [1] except two fixes were added for the bugs found after integration > > of Alibaba's implementation of thread sampling (note that according to the plan Alibaba's patches are not included into this RFR) > > The webrev includes bug ids for all changes backported under it, however these are not separated on per-file basis > > This is perfect, so we have proper tracking of the patches. > > > One process question (thus Andrew in To), the new webrev currently only includes the code which applies to jdk8u-jfr-incubator > > repo, but what about aarch64 and aarch32 ports which are not available there? I don't see a reason to prevent them from > > having JFR and there is code ready for that ([1]). How could we proceed with integration of it? > > You are right, it didn't occur to me that this code was not part of > the repository, but this is because the staging repo is forked from > jdk8u-dev which doesn't contain those ports. > > I think we should indeed backport the other changes, perhaps once > everything is in mainline we can push into the shenandoah/arm/etc... > repositories individual patches? > > Cheers, > Mario > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From GROEGES at uk.ibm.com Wed May 8 12:26:51 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Wed, 8 May 2019 13:26:51 +0100 Subject: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath In-Reply-To: References: Message-ID: Hi Andrew, Thanks for taking a look at this. > Regarding the 8u webrev, the two additions for hasNext() and next() in > JavacProcessingEnvironment.java seem to have been flipped. Was this > intentional? Comparing patched jdk8u with the jdk/jdk version: Yes, this was intentional. When I investigated this issue I did initially add the changes to hasNext() in the jdk8u code but that didn't resolve the issue. Having then looked at a generated stack trace it showed that the code was going thru the next() method and failing there rather than in hasNext(). Hence the reason the changes were put in the next() method for jdk8u and in the hasNext() for jdk11 and above. Seems the JavacProcessingEnvoronment.java class has changed since jdk8. > The test changes look ok and I assume they pass. Yes, the tests do pass when run on my local environment for all releases jdk8u, jdk11u and jdk12u. > Long term, we may want to look at backporting > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8050429&d=DwIBAg&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=LkzUD_N0v0KwSG0YynY27x94cP7H0yoJ6U7weXpeyPQ&s=3Yl646g64OzPtT77EUuXwAhXV6ZVMzF7ykQyPLV3KX4&e= > to avoid this work for every test. I agree that we need to back-port this at some point. It gets quite time consuming having to change tests that are created on jdk11u+ and need to be back-ported to jdk8u. Is there anything else I need to do in order to get these back-ports merged. If so, please let me know. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: Andrew John Hughes To: jdk-updates-dev at openjdk.java.net, "'jdk8u-dev at openjdk.java.net'" Date: 01/05/2019 17:00 Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath Sent by: "jdk-updates-dev" [CCing jdk8u-dev for 8u review] On 01/05/2019 08:04, Steve Groeger wrote: > Hi all, > > The following issue [1] has been raised and the associated webrev [2] has > been approved and the code merged into jdk/jdk [3] > I am now requesting this fix to be back-ported to jdk8u, jdk11u and > jdk12u. > The patch imports and works correctly on jdk8u and jdk12u but not quite on > jdk8u due to difference in the test framework. > I have created a separate webrev for the jdk8u changes [4]. > I am therefore requesting someone to review these changes and to sponsor > these updates to jdk8u, jdk11u and jdk12u. > > [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8218152&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjApBdRxGug&s=qupvoIE2b9o6H2gvzu3EdQUSjE0HvDBZeDXycoIlg4w&e= > [2] https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk_webrev.04_&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjApBdRxGug&s=Lx2f4bK7_yW6MWLgQYj-Y8GzL5NbAH95L7X_ptB9SBk&e= > [3] https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_jdk_rev_d9208a660094&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjApBdRxGug&s=4I9emNaREfISeASbo-TDQVJ3x6_pTiKFtlFPK8K2hTk&e= > [4] https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk8u_webrev.04_&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjApBdRxGug&s=ByHXRWAiDbkm9dsfgHchCQR4FMQiZc_ge0LYlRQkYD8&e= > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Regarding the 8u webrev, the two additions for hasNext() and next() in JavacProcessingEnvironment.java seem to have been flipped. Was this intentional? Comparing patched jdk8u with the jdk/jdk version: --- src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java 2019-05-01 16:50:40.409545256 +0100 +++ ../../jdk/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java 2019-05-01 03:00 public boolean hasNext() { try { - return iterator.hasNext(); + return internalHasNext(); } catch(ServiceConfigurationError sce) { - log.error("proc.bad.config.file", sce.getLocalizedMessage()); + log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage())); throw new Abort(sce); + } catch (UnsupportedClassVersionError ucve) { + log.error(Errors.ProcCantLoadClass(ucve.getLocalizedMessage())); + throw new Abort(ucve); + } catch (ClassFormatError cfe) { + log.error(Errors.ProcCantLoadClass(cfe.getLocalizedMessage())); + throw new Abort(cfe); } catch (Throwable t) { - log.error("proc.bad.config.file", t.getLocalizedMessage()); + log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage())); throw new Abort(t); } } ... public Processor next() { try { - return iterator.next(); + return internalNext(); } catch (ServiceConfigurationError sce) { - log.error("proc.bad.config.file", sce.getLocalizedMessage()); + log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage())); throw new Abort(sce); - } catch (UnsupportedClassVersionError ucve) { - log.error("proc.cant.load.class", ucve.getLocalizedMessage()); - throw new Abort(ucve); - } catch (ClassFormatError cfe) { - log.error("proc.cant.load.class", cfe.getLocalizedMessage()); - throw new Abort(cfe); } catch (Throwable t) { - log.error("proc.bad.config.file", t.getLocalizedMessage()); + log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage())); throw new Abort(t); } } The test changes look ok and I assume they pass. Long term, we may want to look at backporting https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8050429&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjApBdRxGug&s=q-BAu0YUQlwQmBEoesgfjRpVLy_wpTd8b1UZ7CZ_Akk&e= to avoid this work for every test. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. ( https://urldefense.proofpoint.com/v2/url?u=http-3A__www.redhat.com&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjApBdRxGug&s=IXk7fITakTIJN8xZ0a-S80B5oFOvfv5yzV1wdICi7hA&e= ) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://urldefense.proofpoint.com/v2/url?u=https-3A__keybase.io_gnu-5Fandrew&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjApBdRxGug&s=iHeIglNN6XbY2FUKnkzs8A3gd7i9W_jO428tjpYD-Q0&e= Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From andrey at azul.com Wed May 8 13:27:59 2019 From: andrey at azul.com (Andrey Petushkov) Date: Wed, 8 May 2019 13:27:59 +0000 Subject: RFR: 8223147: JFR Backport (to jdk8u) In-Reply-To: References: <3E224264-DA96-48B8-8270-2B77B09E190F@azul.com> Message-ID: <5C55C088-6098-4B04-AF04-DBD317C36C59@azul.com> Hi Mario, Right, this makes sense. I'll do a cleanup for non-jfr enabled builds Thank you, Andrey > On 8 May 2019, at 15:24, Mario Torre wrote: > > Hi Andrey, > > There are a few things I wanted to point out about this patch. > > Overall, it seems good to me, of course not being different than what > we already pre-reviewed. There are a couple of points however that we > need to address, I think they should be addressed before the patch is > in, but I'm open for discussions. > > By default, when I compile without jfr (without --enable-jfr) there > should be no reference to JFR in the resulting image, but this is not > the case. > > For example, in the resulting images/j2sdk-image/jre/lib library I can > still see jfr.jar and a jfr directory with the jfr templates next to > the rest of the libraries. I think this should be removed (a step at > the end of the compilation process will do I think, if it's too > cumbersome to not generate those in the first place). > > What's more is that the presence of JFR sneaks into the JDK at > runtime. For example, the attached applications when run on a default > build of OpenJDK 8 produces the following exception: > > Exception in thread "main" javax.management.RuntimeMBeanException: > java.lang.IllegalArgumentException: VM option "FlightRecorder" does > not exist > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrow(DefaultMBeanServerInterceptor.java:839) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrowMaybeMBeanException(DefaultMBeanServerInterceptor.java:852) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:821) > at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) > at CheckJFR.main(CheckJFR.java:15) > Caused by: java.lang.IllegalArgumentException: VM option > "FlightRecorder" does not exist > at sun.management.HotSpotDiagnostic.getVMOption(HotSpotDiagnostic.java:83) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275) > at com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:193) > at com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:175) > at com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:117) > at com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:54) > at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237) > at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) > at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252) > at javax.management.StandardMBean.invoke(StandardMBean.java:405) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) > ... 2 more > > When running against the jdk8u-jfr-incubator build instead produces > "false". If I run with the -XX:+FlightRecorder I even get a "true" > although I then can't request a flight recorder via JMC or the mbean > interface, while a standard build would give me "Unrecognized VM > option 'FlightRecorder'" in this case. > > I think we should fix this before merging (and please, do feel free to > add this small snippet of code as a test case in the patch). > > I'll try to give more useful feedback as I keep on testing. > > Cheers, > Mario > > > > On Tue, May 7, 2019 at 3:52 PM Mario Torre wrote: >> >> On Tue, May 7, 2019 at 1:20 PM Andrey Petushkov wrote: >>> >>> Hi All, >> >> Hi Andrey, thanks for the patch! >> >>> RFR for initial JFR backport to current state of jdk8u-jfr-incubator is here http://cr.openjdk.java.net/~apetushkov/8223147/ >>> Please could you review and hopefully approve >> >> I'm going through it now, I'll get back to you as soon as possible! >> >>> The changes are the same as in initial review request [1] except two fixes were added for the bugs found after integration >>> of Alibaba's implementation of thread sampling (note that according to the plan Alibaba's patches are not included into this RFR) >>> The webrev includes bug ids for all changes backported under it, however these are not separated on per-file basis >> >> This is perfect, so we have proper tracking of the patches. >> >>> One process question (thus Andrew in To), the new webrev currently only includes the code which applies to jdk8u-jfr-incubator >>> repo, but what about aarch64 and aarch32 ports which are not available there? I don't see a reason to prevent them from >>> having JFR and there is code ready for that ([1]). How could we proceed with integration of it? >> >> You are right, it didn't occur to me that this code was not part of >> the repository, but this is because the staging repo is forked from >> jdk8u-dev which doesn't contain those ports. >> >> I think we should indeed backport the other changes, perhaps once >> everything is in mainline we can push into the shenandoah/arm/etc... >> repositories individual patches? >> >> Cheers, >> Mario >> >> -- >> Mario Torre >> Associate Manager, Software Engineering >> Red Hat GmbH >> 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > From sgehwolf at redhat.com Thu May 9 12:39:18 2019 From: sgehwolf at redhat.com (sgehwolf at redhat.com) Date: Thu, 09 May 2019 14:39:18 +0200 Subject: [PING] [8u] RFR: 8210425: [x86] sharedRuntimeTrig/sharedRuntimeTrans compiled without optimization In-Reply-To: References: Message-ID: <34336f93b6c53942ccf522de449c550bae30d546.camel@redhat.com> Ping? On Fri, 2019-05-03 at 18:35 +0200, Severin Gehwolf wrote: > Hi, > > Could I please get reviews for this 8u backport of an optimization fix > pertaining to the hotspot copy of fdlibm? Historically, > sharedRuntimeTrans.cpp and sharedRuntimeTrig.cpp have been compiled > with optimization turned off on x86/x86_64. As JDK-8210416 will be > backported to JDK 8u fixing optimization for fdlibm itself, so should > be the hotspot copy in OpenJDK 8u. The build system for hotspot in JDK > 8u is very different, so the original fix for JDK 12 doesn't apply. > It's a complete rewrite. Please see this webrev which shows the > prerequisite patch. It adds the FDLIBM_CFLAGS logic: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/jdk8/02/ > > It also fixes a bug on ppc64{,le} where optimization is being turned on > in hotspot (-O3), but not providing the -ffp-contract=off flag (or > older equivalent). > > Before (on ppc64le): > /bin/g++ -DLINUX -D_GNU_SOURCE -DPPC64 -DPRODUCT -I. -I/home/openjdk/jdk8u/hotspot/src/share/vm/prims -I/home/openjdk/jdk8u/hotspot/src/share/vm -I/home/openjdk/jdk8u/hotspot/src/share/vm/precompiled -I/home/openjdk/jdk8u/hotspot/src/cpu/ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os_cpu/linux_ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os/linux/vm -I/home/openjdk/jdk8u/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.212-b04\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"openjdk\"" -DHOTSPOT_LIB_ARCH=\"ppc64le\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_linux_ppc -DTARGET_OS_ARCH_MODEL_linux_ppc_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -fno-strict-aliasing -fno-omit-frame-pointer -O3 -g -D_LP64=1 -DVM_LITTLE_ENDIAN -DABI_ELFv2 -mcpu=power7 -mtune=power8 -minsert-sched-nops=regroup_exact -mno-multiple -mno-string -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -std=gnu++98 -c -MMD -MP -MF ../generated/dependencies/sharedRuntimeTrig.o.d -fpch-deps -o sharedRuntimeTrig.o /home/openjdk/jdk8u/hotspot/src/share/vm/runtime/sharedRuntimeTrig.cpp > After (on ppc64le; Note -ffp-contract=off flag): > /bin/g++ -DLINUX -D_GNU_SOURCE -DPPC64 -DPRODUCT -I. -I/home/openjdk/jdk8u/hotspot/src/share/vm/prims -I/home/openjdk/jdk8u/hotspot/src/share/vm -I/home/openjdk/jdk8u/hotspot/src/share/vm/precompiled -I/home/openjdk/jdk8u/hotspot/src/cpu/ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os_cpu/linux_ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os/linux/vm -I/home/openjdk/jdk8u/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.212-b04\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"openjdk\"" -DHOTSPOT_LIB_ARCH=\"ppc64le\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_linux_ppc -DTARGET_OS_ARCH_MODEL_linux_ppc_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -fno-strict-aliasing -fno-omit-frame-pointer -O3 -ffp-contract=off -D_LP64=1 -DVM_LITTLE_ENDIAN -DABI_ELFv2 -mcpu=power7 -mtune=power8 -minsert-sched-nops=regroup_exact -mno-multiple -mno-string -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -std=gnu++98 -c -MMD -MP -MF ../generated/dependencies/sharedRuntimeTrig.o.d -fpch-deps -o sharedRuntimeTrig.o /home/openjdk/jdk8u/hotspot/src/share/vm/runtime/sharedRuntimeTrig.cpp > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210425 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210425/jdk8/02/webrev > > Testing: Builds on x86_64 (server/Zero). Manual inspection of compile > log of sharedRuntimeTrans.cpp/sharedRuntimeTrig.cpp. Same for ppc64le. > Note that we've been using this patch downstream for a while now. We > haven't seen any issues so far. > > Thanks, > Severin From OGATAK at jp.ibm.com Fri May 10 06:30:05 2019 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Fri, 10 May 2019 15:30:05 +0900 Subject: [8u-dev, ppc] RFR for (almost clean) backport of 8158232 Message-ID: Hi, May I get review for backport of 8158232: PPC64: improve byte, int and long array copy stubs by using VSX instructions? This changeset looks no conflict with the latest jdk8u-dev code, but the patch command failed to apply it. It seems the patch command lost the code regions to apply patches because stubGenerator_ppc.cpp has sets of similar (but slightly different) functions. I created new webrev mainly to update line numbers in the patch file. I verified I can build fastdebug and release builds and there was no degradation in "make test" results. http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8158232/webrev.02/ Regards, Ogata From OGATAK at jp.ibm.com Fri May 10 06:55:51 2019 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Fri, 10 May 2019 15:55:51 +0900 Subject: [8u-dev, ppc] RFR for (almost clean) backport of 8158232 In-Reply-To: References: Message-ID: Sorry, I forgot to put the links to the bug report and the original changeset Also forgot to mention that this changeset is needed to backport AES intrinsics support [1] on ppc64 big-endian. Bug report: https://bugs.openjdk.java.net/browse/JDK-8158232 Original change set http://hg.openjdk.java.net/jdk/jdk/rev/987528901b83 Webrev: http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8158232/webrev.02/ Refs: [1] https://bugs.openjdk.java.net/browse/JDK-8188868 Regards, Ogata "hotspot-compiler-dev" wrote on 2019/05/10 15:30:05: > From: "Kazunori Ogata" > To: hotspot-compiler-dev at openjdk.java.net, jdk8u-dev at openjdk.java.net > Date: 2019/05/10 15:31 > Subject: [8u-dev, ppc] RFR for (almost clean) backport of 8158232 > Sent by: "hotspot-compiler-dev" > > Hi, > > May I get review for backport of 8158232: PPC64: improve byte, int and > long array copy stubs by using VSX instructions? > > This changeset looks no conflict with the latest jdk8u-dev code, but the > patch command failed to apply it. It seems the patch command lost the > code regions to apply patches because stubGenerator_ppc.cpp has sets of > similar (but slightly different) functions. > > I created new webrev mainly to update line numbers in the patch file. I > verified I can build fastdebug and release builds and there was no > degradation in "make test" results. > > http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8158232/webrev.02/ > > Regards, > Ogata > > From neugens at redhat.com Fri May 10 09:00:51 2019 From: neugens at redhat.com (Mario Torre) Date: Fri, 10 May 2019 11:00:51 +0200 Subject: RFR: 8223147: JFR Backport (to jdk8u) In-Reply-To: References: <3E224264-DA96-48B8-8270-2B77B09E190F@azul.com> Message-ID: Hi Denghui, Sure, those patches are surely of interest. I would like if you could prepare the patches referencing each bug they backport like Azul did in their series, then we can proceed as soon as the main patch has been merged. Thanks for doing this! Cheers, Mario On Fri, May 10, 2019 at 10:57 AM ???(??) wrote: > > Hi Mario?Andrey and all, > > We(Alibaba) provided below JFR patches some time ago(check previous Guangyu' discussion in this thread), which are incremental changes based on Azul' patchset. > > 1. Add thread sampling support: > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_thread_samp_20190326/ > > 2. Add biasedLocking event support: > http://cr.openjdk.java.net/~luchsh/hs_biasedlock/ > http://cr.openjdk.java.net/~luchsh/jdk_biasedlock/ > > 3. Add G1 region type change event: > http://cr.openjdk.java.net/~luchsh/g1region_type_change_event > > 4. Add G1 heap summay event: > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_g1heapsum_hs_20190326/ > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_g1heapsum_jdk_20190326/ > > In addition to events support, they also include fixes for some failed testcases, > As repository has been created now(Thanks for Alexey' work), we are planning to proceed the integraion for these patches. > What's your comments? > > > Thanks, > Denghui > > ------------------------------------------------------------------ > ????Mario Torre > ?????2019?5?7?(???) 21:53 > ????Andrey Petushkov > ????jdk8u-dev > ????Re: RFR: 8223147: JFR Backport (to jdk8u) > > On Tue, May 7, 2019 at 1:20 PM Andrey Petushkov wrote: > > > > Hi All, > > Hi Andrey, thanks for the patch! > > > RFR for initial JFR backport to current state of jdk8u-jfr-incubator is here http://cr.openjdk.java.net/~apetushkov/8223147/ > > Please could you review and hopefully approve > > I'm going through it now, I'll get back to you as soon as possible! > > > The changes are the same as in initial review request [1] except two fixes were added for the bugs found after integration > > of Alibaba's implementation of thread sampling (note that according to the plan Alibaba's patches are not included into this RFR) > > The webrev includes bug ids for all changes backported under it, however these are not separated on per-file basis > > This is perfect, so we have proper tracking of the patches. > > > One process question (thus Andrew in To), the new webrev currently only includes the code which applies to jdk8u-jfr-incubator > > repo, but what about aarch64 and aarch32 ports which are not available there? I don't see a reason to prevent them from > > having JFR and there is code ready for that ([1]). How could we proceed with integration of it? > > You are right, it didn't occur to me that this code was not part of > the repository, but this is because the staging repo is forked from > jdk8u-dev which doesn't contain those ports. > > I think we should indeed backport the other changes, perhaps once > everything is in mainline we can push into the shenandoah/arm/etc... > repositories individual patches? > > Cheers, > Mario > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From GROEGES at uk.ibm.com Thu May 2 08:41:57 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Thu, 2 May 2019 09:41:57 +0100 Subject: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath In-Reply-To: References: Message-ID: Hi Andrew, Thanks for taking a look at this. > Regarding the 8u webrev, the two additions for hasNext() and next() in > JavacProcessingEnvironment.java seem to have been flipped. Was this > intentional? Comparing patched jdk8u with the jdk/jdk version: Yes, this was intentional. When I investigated this issue I did initially add the changes to hasNext() in the jdk8u code but that didn't resolve the issue. Having then looked at a generated stack trace it showed that the code was going thru the next() method and failing there rather than in hasNext(). Hence the reason the changes were put in the next() method for jdk8u and in the hasNext() for jdk11 and above. Seems the JavacProcessingEnvoronment.java class has changed since jdk8. > The test changes look ok and I assume they pass. Yes, the tests do pass when run on my local environment for all releases jdk8u, jdk11u and jdk12u. > Long term, we may want to look at backporting > https://bugs.openjdk.java.net/browse/JDK-8050429 > to avoid this work for every test. I agree that we need to back-port this at some point. It gets quite time consuming having to change tests that are created on jdk11u+ and need to be back-ported to jdk8u. Is there anything else I need to do in order to get these back-ports merged. If so, please let me know. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: Andrew John Hughes To: jdk-updates-dev at openjdk.java.net, "'jdk8u-dev at openjdk.java.net'" Date: 01/05/2019 17:00 Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath Sent by: "jdk-updates-dev" [CCing jdk8u-dev for 8u review] On 01/05/2019 08:04, Steve Groeger wrote: > Hi all, > > The following issue [1] has been raised and the associated webrev [2] has > been approved and the code merged into jdk/jdk [3] > I am now requesting this fix to be back-ported to jdk8u, jdk11u and > jdk12u. > The patch imports and works correctly on jdk8u and jdk12u but not quite on > jdk8u due to difference in the test framework. > I have created a separate webrev for the jdk8u changes [4]. > I am therefore requesting someone to review these changes and to sponsor > these updates to jdk8u, jdk11u and jdk12u. > > [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8218152&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjApBdRxGug&s=qupvoIE2b9o6H2gvzu3EdQUSjE0HvDBZeDXycoIlg4w&e= > [2] https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk_webrev.04_&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjApBdRxGug&s=Lx2f4bK7_yW6MWLgQYj-Y8GzL5NbAH95L7X_ptB9SBk&e= > [3] https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_jdk_rev_d9208a660094&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjApBdRxGug&s=4I9emNaREfISeASbo-TDQVJ3x6_pTiKFtlFPK8K2hTk&e= > [4] https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk8u_webrev.04_&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjApBdRxGug&s=ByHXRWAiDbkm9dsfgHchCQR4FMQiZc_ge0LYlRQkYD8&e= > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Regarding the 8u webrev, the two additions for hasNext() and next() in JavacProcessingEnvironment.java seem to have been flipped. Was this intentional? Comparing patched jdk8u with the jdk/jdk version: --- src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java 2019-05-01 16:50:40.409545256 +0100 +++ ../../jdk/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java 2019-05-01 03:00 public boolean hasNext() { try { - return iterator.hasNext(); + return internalHasNext(); } catch(ServiceConfigurationError sce) { - log.error("proc.bad.config.file", sce.getLocalizedMessage()); + log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage())); throw new Abort(sce); + } catch (UnsupportedClassVersionError ucve) { + log.error(Errors.ProcCantLoadClass(ucve.getLocalizedMessage())); + throw new Abort(ucve); + } catch (ClassFormatError cfe) { + log.error(Errors.ProcCantLoadClass(cfe.getLocalizedMessage())); + throw new Abort(cfe); } catch (Throwable t) { - log.error("proc.bad.config.file", t.getLocalizedMessage()); + log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage())); throw new Abort(t); } } ... public Processor next() { try { - return iterator.next(); + return internalNext(); } catch (ServiceConfigurationError sce) { - log.error("proc.bad.config.file", sce.getLocalizedMessage()); + log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage())); throw new Abort(sce); - } catch (UnsupportedClassVersionError ucve) { - log.error("proc.cant.load.class", ucve.getLocalizedMessage()); - throw new Abort(ucve); - } catch (ClassFormatError cfe) { - log.error("proc.cant.load.class", cfe.getLocalizedMessage()); - throw new Abort(cfe); } catch (Throwable t) { - log.error("proc.bad.config.file", t.getLocalizedMessage()); + log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage())); throw new Abort(t); } } The test changes look ok and I assume they pass. Long term, we may want to look at backporting https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8050429&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjApBdRxGug&s=q-BAu0YUQlwQmBEoesgfjRpVLy_wpTd8b1UZ7CZ_Akk&e= to avoid this work for every test. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. ( https://urldefense.proofpoint.com/v2/url?u=http-3A__www.redhat.com&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjApBdRxGug&s=IXk7fITakTIJN8xZ0a-S80B5oFOvfv5yzV1wdICi7hA&e= ) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://urldefense.proofpoint.com/v2/url?u=https-3A__keybase.io_gnu-5Fandrew&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=ATbJ1iXicP6W17wnytspWscrkGhzqhW7xjApBdRxGug&s=iHeIglNN6XbY2FUKnkzs8A3gd7i9W_jO428tjpYD-Q0&e= Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From denghui.ddh at alipay.com Fri May 10 08:57:20 2019 From: denghui.ddh at alipay.com (=?UTF-8?B?6JGj55m76L6JKOWNk+aYgik=?=) Date: Fri, 10 May 2019 16:57:20 +0800 Subject: =?UTF-8?B?5Zue5aSN77yaUkZSOiA4MjIzMTQ3OiBKRlIgQmFja3BvcnQgKHRvIGpkazh1KQ==?= In-Reply-To: References: <3E224264-DA96-48B8-8270-2B77B09E190F@azul.com>, Message-ID: Hi Mario?Andrey and all, We(Alibaba) provided below JFR patches some time ago(check previous Guangyu' discussion in this thread), which are incremental changes based on Azul' patchset. 1. Add thread sampling support: http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_thread_samp_20190326/ 2. Add biasedLocking event support: http://cr.openjdk.java.net/~luchsh/hs_biasedlock/ http://cr.openjdk.java.net/~luchsh/jdk_biasedlock/ 3. Add G1 region type change event: http://cr.openjdk.java.net/~luchsh/g1region_type_change_event 4. Add G1 heap summay event: http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_g1heapsum_hs_20190326/ http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_g1heapsum_jdk_20190326/ In addition to events support, they also include fixes for some failed testcases, As repository has been created now(Thanks for Alexey' work), we are planning to proceed the integraion for these patches. What's your comments? Thanks, Denghui ------------------------------------------------------------------ ????Mario Torre ?????2019?5?7?(???) 21:53 ????Andrey Petushkov ????jdk8u-dev ????Re: RFR: 8223147: JFR Backport (to jdk8u) On Tue, May 7, 2019 at 1:20 PM Andrey Petushkov wrote: > > Hi All, Hi Andrey, thanks for the patch! > RFR for initial JFR backport to current state of jdk8u-jfr-incubator is here http://cr.openjdk.java.net/~apetushkov/8223147/ > Please could you review and hopefully approve I'm going through it now, I'll get back to you as soon as possible! > The changes are the same as in initial review request [1] except two fixes were added for the bugs found after integration > of Alibaba's implementation of thread sampling (note that according to the plan Alibaba's patches are not included into this RFR) > The webrev includes bug ids for all changes backported under it, however these are not separated on per-file basis This is perfect, so we have proper tracking of the patches. > One process question (thus Andrew in To), the new webrev currently only includes the code which applies to jdk8u-jfr-incubator > repo, but what about aarch64 and aarch32 ports which are not available there? I don't see a reason to prevent them from > having JFR and there is code ready for that ([1]). How could we proceed with integration of it? You are right, it didn't occur to me that this code was not part of the repository, but this is because the staging repo is forked from jdk8u-dev which doesn't contain those ports. I think we should indeed backport the other changes, perhaps once everything is in mainline we can push into the shenandoah/arm/etc... repositories individual patches? Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From christoph.langer at sap.com Fri May 10 09:36:07 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 10 May 2019 09:36:07 +0000 Subject: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath In-Reply-To: References: Message-ID: Hi Steve > Is there anything else I need to do in order to get these back-ports > merged. If so, please let me know. In case you haven't seen yet: I have already pushed the backports for 11 and 12 yesterday. jdk8 I would leave for Andrew. Best regards Christoph From gnu.andrew at redhat.com Fri May 10 17:55:52 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 10 May 2019 18:55:52 +0100 Subject: RFR: 8223147: JFR Backport (to jdk8u) In-Reply-To: References: <3E224264-DA96-48B8-8270-2B77B09E190F@azul.com> Message-ID: snip... > >> One process question (thus Andrew in To), the new webrev currently only includes the code which applies to jdk8u-jfr-incubator >> repo, but what about aarch64 and aarch32 ports which are not available there? I don't see a reason to prevent them from >> having JFR and there is code ready for that ([1]). How could we proceed with integration of it? > > You are right, it didn't occur to me that this code was not part of > the repository, but this is because the staging repo is forked from > jdk8u-dev which doesn't contain those ports. > > I think we should indeed backport the other changes, perhaps once > everything is in mainline we can push into the shenandoah/arm/etc... > repositories individual patches? > > Cheers, > Mario > Once JFR is integrated into the jdk8u repository, it will get merged into the aarch64/shenandoah-jdk8u [0] and aarch32 [1] trees. I don't see any problem in adding AArch{32,64} code blocks in the shared code during the incubation period, but any changes to arch-specific files will be against files that simply don't exist in the jdk8u trees. When that occurs, it's worth taking a note of what changes have to be left out so they can be added to the respective ports once JFR is integrated. [0] https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/ [1] https://hg.openjdk.java.net/aarch32-port/jdk8u/ Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Fri May 10 18:26:10 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 10 May 2019 19:26:10 +0100 Subject: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath In-Reply-To: References: Message-ID: <6829d771-49fc-8be2-3daa-b68b6e4c4c4e@redhat.com> On 08/05/2019 13:26, Steve Groeger wrote: > Hi Andrew, > > Thanks for taking a look at this. > >> Regarding the 8u webrev, the two additions for hasNext() and next() in >> JavacProcessingEnvironment.java seem to have been flipped. Was this >> intentional? Comparing patched jdk8u with the jdk/jdk version: > > Yes, this was intentional. When I investigated this issue I did initially > add the changes to hasNext() in the jdk8u code but that didn't resolve the > issue. Having then looked at a generated stack trace it showed that the > code was going thru the next() method and failing there rather than in > hasNext(). Hence the reason the changes were put in the next() method for > jdk8u and in the hasNext() for jdk11 and above. Seems the > JavacProcessingEnvoronment.java class has changed since jdk8. > Ah ok. >> The test changes look ok and I assume they pass. > > Yes, the tests do pass when run on my local environment for all releases > jdk8u, jdk11u and jdk12u. > >> Long term, we may want to look at backporting >> https://bugs.openjdk.java.net/browse/JDK-8050429 >> to avoid this work for every test. > > I agree that we need to back-port this at some point. It gets quite time > consuming having to change tests that are created on jdk11u+ and need to > be back-ported to jdk8u. > > Is there anything else I need to do in order to get these back-ports > merged. If so, please let me know. > I see you added jdk8u-fix-request, and it has a jdk8u-fix-yes in response, so now it has been reviewed, all that's needed now is to push the change. Do you have push access or shall I do it on your behalf? > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Fri May 10 18:40:29 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 10 May 2019 19:40:29 +0100 Subject: jdk8u222-b02 tagged Message-ID: <5fc076bd-1cf6-009e-9970-53ca3c4319d1@redhat.com> I've tagged jdk8u222-b02 locally and will push once tested. Any changes pushed from this point forward will form part of b03. Changes in jdk8u222-b02: - S8134030: test/serviceability/dcmd/gc/HeapDumpTest fails to verify the dump - S8151539: Remove duplicate AlwaysTrueClosures - S8176100: [REDO][REDO] G1 Needs pre barrier on dereference of weak JNI handles - S8210416: [linux] Poor StrictMath performance due to non-optimized compilation - S8217315: Proper units should print more significant digits - S8218674: HTML Tooltip with "img=src" on component doesn't show Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From hong_hao.sun at nokia-sbell.com Mon May 13 07:14:04 2019 From: hong_hao.sun at nokia-sbell.com (Sun, Hong Hao (NSB - CN/Qingdao)) Date: Mon, 13 May 2019 07:14:04 +0000 Subject: Question about Oracle JDK update and OpenJDK update Message-ID: <9ae732014d52499cbed3c02fa378cc58@nokia-sbell.com> Hi Folks, One question about the relationship between Oracle JDK update an OpenJDK update. In Oracle JDK 8 release note webpage, https://www.oracle.com/technetwork/java/javase/8u-relnotes-2225394.html, it shows the updates for JDK 8. And from webpage https://wiki.openjdk.java.net/display/jdk8u, I can see the status for 8u222 and 232 only, Filters for release 8u222 [Open Downports Oracle -> OpenJDK] [Additional commits in OpenJDK vs Oracle] Filters for release 8u232 [Open Downports Oracle -> OpenJDK] [Additional commits in OpenJDK vs Oracle] Question is, is OpenJDK 8u201 contains all the feature/bug fixes in Oracle JDK 8u201? How can I find this kind of information? Thanks a lot! Regards, Joey From aph at redhat.com Mon May 13 08:33:27 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 13 May 2019 09:33:27 +0100 Subject: Question about Oracle JDK update and OpenJDK update In-Reply-To: <9ae732014d52499cbed3c02fa378cc58@nokia-sbell.com> References: <9ae732014d52499cbed3c02fa378cc58@nokia-sbell.com> Message-ID: <355e6634-df96-696d-afe8-756b5a575652@redhat.com> On 5/13/19 8:14 AM, Sun, Hong Hao (NSB - CN/Qingdao) wrote: > Question is, is OpenJDK 8u201 contains all the feature/bug fixes in Oracle JDK 8u201? How can I find this kind of information? That's very hard because Oracle proprietary Java is closed. We can tell you about OpenJDK, because it is open. We don't have any private channels into Oracle: we have to read the public information. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From hong_hao.sun at nokia-sbell.com Mon May 13 08:40:08 2019 From: hong_hao.sun at nokia-sbell.com (Sun, Hong Hao (NSB - CN/Qingdao)) Date: Mon, 13 May 2019 08:40:08 +0000 Subject: Question about Oracle JDK update and OpenJDK update In-Reply-To: <355e6634-df96-696d-afe8-756b5a575652@redhat.com> References: <9ae732014d52499cbed3c02fa378cc58@nokia-sbell.com> <355e6634-df96-696d-afe8-756b5a575652@redhat.com> Message-ID: Hi Haley, Thanks for your information! One more question, where I can find all the feature list/bug list in one specific OpenJDK update, for example, the OpenJDK 8u201 one? Thanks! Regards, Joey -----Original Message----- From: Andrew Haley Sent: Monday, May 13, 2019 4:33 PM To: Sun, Hong Hao (NSB - CN/Qingdao) ; jdk8u-dev at openjdk.java.net Subject: Re: Question about Oracle JDK update and OpenJDK update On 5/13/19 8:14 AM, Sun, Hong Hao (NSB - CN/Qingdao) wrote: > Question is, is OpenJDK 8u201 contains all the feature/bug fixes in Oracle JDK 8u201? How can I find this kind of information? That's very hard because Oracle proprietary Java is closed. We can tell you about OpenJDK, because it is open. We don't have any private channels into Oracle: we have to read the public information. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From andrey at azul.com Mon May 13 17:04:11 2019 From: andrey at azul.com (Andrey Petushkov) Date: Mon, 13 May 2019 17:04:11 +0000 Subject: RFR: 8223147: JFR Backport (to jdk8u) In-Reply-To: References: <3E224264-DA96-48B8-8270-2B77B09E190F@azul.com> Message-ID: <771B3281-FB26-4673-B19C-6282BE1D9D86@azul.com> Hi Mario, Apparently the situation is not that bad, just a few things went wrong on our sides. My fault I did not switch --enable-jfr to false. Fixed now And you seem did not make clean after changing configure options :) With proper clean build the only wrong behavior I get from your list is the presence of jfc/template files in the distribution. I've fixed that as well. I don't see any other JFR artefacts in the images directory when building with JFR disabled (there are few intermediate files generated but these do not get into final image) Your test passes The webrevs are updated, please could you check again Sorry, I did not adopt your test as a jtreg yet Thanks a lot, Andrey > On 8 May 2019, at 15:24, Mario Torre wrote: > > Hi Andrey, > > There are a few things I wanted to point out about this patch. > > Overall, it seems good to me, of course not being different than what > we already pre-reviewed. There are a couple of points however that we > need to address, I think they should be addressed before the patch is > in, but I'm open for discussions. > > By default, when I compile without jfr (without --enable-jfr) there > should be no reference to JFR in the resulting image, but this is not > the case. > > For example, in the resulting images/j2sdk-image/jre/lib library I can > still see jfr.jar and a jfr directory with the jfr templates next to > the rest of the libraries. I think this should be removed (a step at > the end of the compilation process will do I think, if it's too > cumbersome to not generate those in the first place). > > What's more is that the presence of JFR sneaks into the JDK at > runtime. For example, the attached applications when run on a default > build of OpenJDK 8 produces the following exception: > > Exception in thread "main" javax.management.RuntimeMBeanException: > java.lang.IllegalArgumentException: VM option "FlightRecorder" does > not exist > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrow(DefaultMBeanServerInterceptor.java:839) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrowMaybeMBeanException(DefaultMBeanServerInterceptor.java:852) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:821) > at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) > at CheckJFR.main(CheckJFR.java:15) > Caused by: java.lang.IllegalArgumentException: VM option > "FlightRecorder" does not exist > at sun.management.HotSpotDiagnostic.getVMOption(HotSpotDiagnostic.java:83) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275) > at com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:193) > at com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:175) > at com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:117) > at com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:54) > at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237) > at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) > at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252) > at javax.management.StandardMBean.invoke(StandardMBean.java:405) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) > ... 2 more > > When running against the jdk8u-jfr-incubator build instead produces > "false". If I run with the -XX:+FlightRecorder I even get a "true" > although I then can't request a flight recorder via JMC or the mbean > interface, while a standard build would give me "Unrecognized VM > option 'FlightRecorder'" in this case. > > I think we should fix this before merging (and please, do feel free to > add this small snippet of code as a test case in the patch). > > I'll try to give more useful feedback as I keep on testing. > > Cheers, > Mario > > > > On Tue, May 7, 2019 at 3:52 PM Mario Torre wrote: >> >> On Tue, May 7, 2019 at 1:20 PM Andrey Petushkov wrote: >>> >>> Hi All, >> >> Hi Andrey, thanks for the patch! >> >>> RFR for initial JFR backport to current state of jdk8u-jfr-incubator is here http://cr.openjdk.java.net/~apetushkov/8223147/ >>> Please could you review and hopefully approve >> >> I'm going through it now, I'll get back to you as soon as possible! >> >>> The changes are the same as in initial review request [1] except two fixes were added for the bugs found after integration >>> of Alibaba's implementation of thread sampling (note that according to the plan Alibaba's patches are not included into this RFR) >>> The webrev includes bug ids for all changes backported under it, however these are not separated on per-file basis >> >> This is perfect, so we have proper tracking of the patches. >> >>> One process question (thus Andrew in To), the new webrev currently only includes the code which applies to jdk8u-jfr-incubator >>> repo, but what about aarch64 and aarch32 ports which are not available there? I don't see a reason to prevent them from >>> having JFR and there is code ready for that ([1]). How could we proceed with integration of it? >> >> You are right, it didn't occur to me that this code was not part of >> the repository, but this is because the staging repo is forked from >> jdk8u-dev which doesn't contain those ports. >> >> I think we should indeed backport the other changes, perhaps once >> everything is in mainline we can push into the shenandoah/arm/etc... >> repositories individual patches? >> >> Cheers, >> Mario >> >> -- >> Mario Torre >> Associate Manager, Software Engineering >> Red Hat GmbH >> 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > From gromero at linux.vnet.ibm.com Mon May 13 19:59:43 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 13 May 2019 16:59:43 -0300 Subject: [8u-dev, ppc] RFR for (almost clean) backport of 8158232 In-Reply-To: References: Message-ID: Hi Ogata, Thanks for the backport and for the webrev. I understand that offset adjustments in general, and particularly for this backport, are not considered a change that needs to be reviewed again. That said, and although I'm not a Reviewer, I tested it against SPECjvm and microbenchmarks for byte, int, and long and reviewed the change for jdk8u-dev. It looks good. Please, provide a "Fix Request" comment to the original bug explaining that the backport is low risk and affects PPC64-only, accordingly to [1] and [2]. Then please add the label "jdk8u-fix-request" to it. Once the approval to push is granted I'll sponsor the change. Thank you. Best regards, Gustavo [1] https://wiki.openjdk.java.net/display/jdk8u/Main [2] http://openjdk.java.net/projects/jdk-updates/approval.html On 05/10/2019 03:55 AM, Kazunori Ogata wrote: > Sorry, I forgot to put the links to the bug report and the original > changeset Also forgot to mention that this changeset is needed to > backport AES intrinsics support [1] on ppc64 big-endian. > > Bug report: > https://bugs.openjdk.java.net/browse/JDK-8158232 > > Original change set > http://hg.openjdk.java.net/jdk/jdk/rev/987528901b83 > > > Webrev: > http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8158232/webrev.02/ > > > Refs: > [1] https://bugs.openjdk.java.net/browse/JDK-8188868 > > > Regards, > Ogata > > "hotspot-compiler-dev" > wrote on 2019/05/10 15:30:05: > >> From: "Kazunori Ogata" >> To: hotspot-compiler-dev at openjdk.java.net, jdk8u-dev at openjdk.java.net >> Date: 2019/05/10 15:31 >> Subject: [8u-dev, ppc] RFR for (almost clean) backport of 8158232 >> Sent by: "hotspot-compiler-dev" > >> >> Hi, >> >> May I get review for backport of 8158232: PPC64: improve byte, int and >> long array copy stubs by using VSX instructions? >> >> This changeset looks no conflict with the latest jdk8u-dev code, but the > >> patch command failed to apply it. It seems the patch command lost the >> code regions to apply patches because stubGenerator_ppc.cpp has sets of >> similar (but slightly different) functions. >> >> I created new webrev mainly to update line numbers in the patch file. I > >> verified I can build fastdebug and release builds and there was no >> degradation in "make test" results. >> >> http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8158232/webrev.02/ >> >> Regards, >> Ogata >> >> > > From m.yamamoto at change-vision.com Tue May 14 04:56:58 2019 From: m.yamamoto at change-vision.com (Mitsuhiro Yamamoto) Date: Tue, 14 May 2019 13:56:58 +0900 Subject: Fonts with embedded bitmaps are not always rotated Message-ID: Hi there, I would like to fix a issue below, so I created a patch file for it. https://github.com/AdoptOpenJDK/openjdk-build/issues/945 Can you help me with this? diff --git a/jdk/src/share/native/sun/font/freetypeScaler.c b/jdk/src/share/native/sun/font/freetypeScaler.c index 8c9207d9b2..59747cc860 100644 --- a/jdk/src/share/native/sun/font/freetypeScaler.c +++ b/jdk/src/share/native/sun/font/freetypeScaler.c @@ -364,6 +364,19 @@ Java_sun_font_FreetypeFontScaler_createScalerContextNative( context->doBold = (boldness != 1.0); context->doItalize = (italic != 0); + /* freetype is very keen to use embedded bitmaps, even if it knows + * there is a rotation or you asked for antialiasing. + * In the rendering path we will check useSBits and disable + * bitmaps unless it is set. And here we set it only if none + * of the conditions invalidate using it. + * Note that we allow embedded bitmaps for the LCD case. + */ + if ((aa != TEXT_AA_ON) && (fm != TEXT_FM_ON) && + !context->doBold && !context->doItalize && + (context->transform.yx == 0) && (context->transform.xy == 0)) + { + context->useSbits = 1; + } return ptr_to_jlong(context); } @@ -685,9 +698,8 @@ Java_sun_font_FreetypeFontScaler_getGlyphImageNative( return ptr_to_jlong(getNullGlyphImage()); } - /* if algorithmic styling is required then we do not request bitmap */ - if (context->doBold || context->doItalize) { - renderFlags = FT_LOAD_DEFAULT; + if (!context->useSbits) { + renderFlags |= FT_LOAD_NO_BITMAP; } /* NB: in case of non identity transform Mit From OGATAK at jp.ibm.com Tue May 14 06:02:49 2019 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Tue, 14 May 2019 15:02:49 +0900 Subject: [8u-dev, ppc] RFR for (almost clean) backport of 8158232 In-Reply-To: References: Message-ID: Hi Gustavo, Thank you for the suggestion. I'll proceed to put the fix request comment and tag in the original bug report. Thank you too for offering to sponsor this change. I'll let you know when it's approved. Regards, Ogata "Gustavo Romero" wrote on 2019/05/14 04:59:43: > From: "Gustavo Romero" > To: Kazunori Ogata/Japan/IBM at IBMJP, hotspot-compiler-dev at openjdk.java.net, > jdk8u-dev at openjdk.java.net > Date: 2019/05/14 04:59 > Subject: Re: [8u-dev, ppc] RFR for (almost clean) backport of 8158232 > > Hi Ogata, > > Thanks for the backport and for the webrev. > > I understand that offset adjustments in general, and particularly for this > backport, are not considered a change that needs to be reviewed again. > > That said, and although I'm not a Reviewer, I tested it against SPECjvm and > microbenchmarks for byte, int, and long and reviewed the change for jdk8u-dev. > > It looks good. > > Please, provide a "Fix Request" comment to the original bug explaining that > the backport is low risk and affects PPC64-only, accordingly to [1] and [2]. > Then please add the label "jdk8u-fix-request" to it. > > Once the approval to push is granted I'll sponsor the change. > > Thank you. > > Best regards, > Gustavo > > [1] https://wiki.openjdk.java.net/display/jdk8u/Main > [2] http://openjdk.java.net/projects/jdk-updates/approval.html > > On 05/10/2019 03:55 AM, Kazunori Ogata wrote: > > Sorry, I forgot to put the links to the bug report and the original > > changeset Also forgot to mention that this changeset is needed to > > backport AES intrinsics support [1] on ppc64 big-endian. > > > > Bug report: > > https://bugs.openjdk.java.net/browse/JDK-8158232 > > > > Original change set > > http://hg.openjdk.java.net/jdk/jdk/rev/987528901b83 > > > > > > Webrev: > > http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8158232/webrev.02/ > > > > > > Refs: > > [1] https://bugs.openjdk.java.net/browse/JDK-8188868 > > > > > > Regards, > > Ogata > > > > "hotspot-compiler-dev" > > wrote on 2019/05/10 15:30:05: > > > >> From: "Kazunori Ogata" > >> To: hotspot-compiler-dev at openjdk.java.net, jdk8u-dev at openjdk.java.net > >> Date: 2019/05/10 15:31 > >> Subject: [8u-dev, ppc] RFR for (almost clean) backport of 8158232 > >> Sent by: "hotspot-compiler-dev" > > > >> > >> Hi, > >> > >> May I get review for backport of 8158232: PPC64: improve byte, int and > >> long array copy stubs by using VSX instructions? > >> > >> This changeset looks no conflict with the latest jdk8u-dev code, but the > > > >> patch command failed to apply it. It seems the patch command lost the > >> code regions to apply patches because stubGenerator_ppc.cpp has sets of > >> similar (but slightly different) functions. > >> > >> I created new webrev mainly to update line numbers in the patch file. I > > > >> verified I can build fastdebug and release builds and there was no > >> degradation in "make test" results. > >> > >> http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8158232/webrev.02/ > >> > >> Regards, > >> Ogata > >> > >> > > > > From martin.doerr at sap.com Tue May 14 08:22:26 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 14 May 2019 08:22:26 +0000 Subject: [8u] RFR: 8189131: Open-source the Oracle JDK Root Certificates (Integration for JEP 319: Root Certificates) In-Reply-To: References: Message-ID: Hi Christoph, this looks good to me. I don't know if anybody has issues with the failing tests. Should they get added to a problem list? Best regards, Martin -----Original Message----- From: jdk8u-dev On Behalf Of Langer, Christoph Sent: Dienstag, 7. Mai 2019 16:15 To: 'jdk8u-dev at openjdk.java.net' ; security-dev Subject: [CAUTION] RE: [8u] RFR: 8189131: Open-source the Oracle JDK Root Certificates (Integration for JEP 319: Root Certificates) Ping: can I please have a review for this? From: Langer, Christoph Sent: Donnerstag, 2. Mai 2019 14:55 To: 'jdk8u-dev at openjdk.java.net' ; security-dev Subject: [8u] RFR: 8189131: Open-source the Oracle JDK Root Certificates (Integration for JEP 319: Root Certificates) Hi, as was already discussed and requested on the mailing lists ([0], [1]), I hereby propose a change to add the root certificates of upstream OpenJDK to OpenJDK 8 updates. The main bug that (initially) brought the Oracle certificates to OpenJDK is 8189131: Open-source the Oracle JDK Root Certificates [2]. My proposed change will also backport all updates to the contents of cacerts since then: 8191844: Remove SECOM root (secomevrootca1) 8189949: Remove Baltimore Cybertrust Code Signing CA 8191031: Remove several Symantec Root CAs 8196141: Add GoDaddy root certificates 8204923: Restore Symantec root verisignclass2g2ca 8195774: Add Entrust root certificates 8199779: Add T-Systems, GlobalSign and Starfield services root certificates 8209506: Add Google Trust Services GlobalSign root certificates 8210432: Add additional TeliaSonera root certificate 8195793: Remove GTE CyberTrust Global Root 8216577: Add GlobalSign's R6 Root certificate 8222137: Remove T-Systems root CA certificate Please find the webrev here: http://cr.openjdk.java.net/~clanger/webrevs/8189131.8u/ I took the current state of cacerts from the jdk/jdk repo along with the provided testcases and brought them down to the jdk8 repository layout. To make the test run in JDK8, I had to a) modify test/sun/security/lib/cacerts/VerifyCACerts.java: 240 private static final HashSet EXPIRY_EXC_ENTRIES = new HashSet() { I needed to add the String type to the constructor of the HashSet, since the JDK8 java compiler will not accept <> in that place. b) modify test/security/infra/java/security/cert/CertPathValidator/certification/ValidatePathWithParams.java 60 private static final String CACERTS_STORE = System.getProperty("test.jdk") 61 + FS + "jre" + FS + "lib" + FS + "security" + FS + "cacerts"; I needed to adapt the path to cacerts in a JDK8 JDK/JRE as it is located in subdirectory jre there. Out of the tests in test/security/infra/java/security/cert/CertPathValidator/certification, there are 2 failing: FAILED: security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java FAILED: security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java However, for jdk/jdk it is the same. JBS Issues for these tests exist and are yet unresolved: JDK-8202651 and JDK-8215546. Since the tests don't seem to be part of any tier, I propose to include them in this backport and later on also backport possible fixes to them. Thanks Christoph [0] https://mail.openjdk.java.net/pipermail/security-dev/2019-March/019557.html [1] https://mail.openjdk.java.net/pipermail/security-dev/2019-April/019733.html [2] https://bugs.openjdk.java.net/browse/JDK-8189131 From christoph.langer at sap.com Tue May 14 09:29:14 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 14 May 2019 09:29:14 +0000 Subject: [8u] RFR: 8189131: Open-source the Oracle JDK Root Certificates (Integration for JEP 319: Root Certificates) In-Reply-To: References: Message-ID: Hi Martin, thanks for your review. Regarding the failing tests: They are not executed in any tier. You'd either have to execute all tests below jdk/test or the test group "jdk_security_infra". But anyway, I'll follow up on these tests as we see the issues in our test system and have to exclude them locally. /Christoph > -----Original Message----- > From: Doerr, Martin > Sent: Dienstag, 14. Mai 2019 10:22 > To: Langer, Christoph ; 'jdk8u- > dev at openjdk.java.net' ; security-dev > > Subject: RE: [8u] RFR: 8189131: Open-source the Oracle JDK Root Certificates > (Integration for JEP 319: Root Certificates) > > Hi Christoph, > > this looks good to me. > I don't know if anybody has issues with the failing tests. Should they get > added to a problem list? > > Best regards, > Martin > > > -----Original Message----- > From: jdk8u-dev On Behalf Of > Langer, Christoph > Sent: Dienstag, 7. Mai 2019 16:15 > To: 'jdk8u-dev at openjdk.java.net' ; security- > dev > Subject: [CAUTION] RE: [8u] RFR: 8189131: Open-source the Oracle JDK Root > Certificates (Integration for JEP 319: Root Certificates) > > Ping: can I please have a review for this? > > From: Langer, Christoph > Sent: Donnerstag, 2. Mai 2019 14:55 > To: 'jdk8u-dev at openjdk.java.net' ; security- > dev > Subject: [8u] RFR: 8189131: Open-source the Oracle JDK Root Certificates > (Integration for JEP 319: Root Certificates) > > Hi, > > as was already discussed and requested on the mailing lists ([0], [1]), I hereby > propose a change to add the root certificates of upstream OpenJDK to > OpenJDK 8 updates. > > The main bug that (initially) brought the Oracle certificates to OpenJDK is > 8189131: Open-source the Oracle JDK Root Certificates [2]. My proposed > change will also backport all updates to the contents of cacerts since then: > > 8191844: Remove SECOM root (secomevrootca1) > 8189949: Remove Baltimore Cybertrust Code Signing CA > 8191031: Remove several Symantec Root CAs > 8196141: Add GoDaddy root certificates > 8204923: Restore Symantec root verisignclass2g2ca > 8195774: Add Entrust root certificates > 8199779: Add T-Systems, GlobalSign and Starfield services root certificates > 8209506: Add Google Trust Services GlobalSign root certificates > 8210432: Add additional TeliaSonera root certificate > 8195793: Remove GTE CyberTrust Global Root > 8216577: Add GlobalSign's R6 Root certificate > 8222137: Remove T-Systems root CA certificate > > Please find the webrev here: > http://cr.openjdk.java.net/~clanger/webrevs/8189131.8u/ > > I took the current state of cacerts from the jdk/jdk repo along with the > provided testcases and brought them down to the jdk8 repository layout. > > To make the test run in JDK8, I had to > a) modify test/sun/security/lib/cacerts/VerifyCACerts.java: > 240 private static final HashSet EXPIRY_EXC_ENTRIES = new > HashSet() { > I needed to add the String type to the constructor of the HashSet, since the > JDK8 java compiler will not accept <> in that place. > > b) modify > test/security/infra/java/security/cert/CertPathValidator/certification/Validat > ePathWithParams.java > > 60 private static final String CACERTS_STORE = > System.getProperty("test.jdk") > > 61 + FS + "jre" + FS + "lib" + FS + "security" + FS + "cacerts"; > I needed to adapt the path to cacerts in a JDK8 JDK/JRE as it is located in > subdirectory jre there. > > Out of the tests in > test/security/infra/java/security/cert/CertPathValidator/certification, there > are 2 failing: > FAILED: > security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.ja > va > FAILED: > security/infra/java/security/cert/CertPathValidator/certification/ComodoCA. > java > However, for jdk/jdk it is the same. JBS Issues for these tests exist and are > yet unresolved: JDK-8202651 and JDK-8215546. > > Since the tests don't seem to be part of any tier, I propose to include them in > this backport and later on also backport possible fixes to them. > > Thanks > Christoph > > [0] https://mail.openjdk.java.net/pipermail/security-dev/2019- > March/019557.html > [1] https://mail.openjdk.java.net/pipermail/security-dev/2019- > April/019733.html > [2] https://bugs.openjdk.java.net/browse/JDK-8189131 From gnu.andrew at redhat.com Tue May 14 13:26:42 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 14 May 2019 14:26:42 +0100 Subject: [8u] RFR: 8189131: Open-source the Oracle JDK Root Certificates (Integration for JEP 319: Root Certificates) In-Reply-To: References: Message-ID: <2f1c2b92-1957-3126-889d-d1070a605f3a@redhat.com> On 07/05/2019 15:15, Langer, Christoph wrote: > Ping: can I please have a review for this? > > From: Langer, Christoph > Sent: Donnerstag, 2. Mai 2019 14:55 > To: 'jdk8u-dev at openjdk.java.net' ; security-dev > Subject: [8u] RFR: 8189131: Open-source the Oracle JDK Root Certificates (Integration for JEP 319: Root Certificates) > > Hi, > > as was already discussed and requested on the mailing lists ([0], [1]), I hereby propose a change to add the root certificates of upstream OpenJDK to OpenJDK 8 updates. > > The main bug that (initially) brought the Oracle certificates to OpenJDK is 8189131: Open-source the Oracle JDK Root Certificates [2]. My proposed change will also backport all updates to the contents of cacerts since then: > > 8191844: Remove SECOM root (secomevrootca1) > 8189949: Remove Baltimore Cybertrust Code Signing CA > 8191031: Remove several Symantec Root CAs > 8196141: Add GoDaddy root certificates > 8204923: Restore Symantec root verisignclass2g2ca > 8195774: Add Entrust root certificates > 8199779: Add T-Systems, GlobalSign and Starfield services root certificates > 8209506: Add Google Trust Services GlobalSign root certificates > 8210432: Add additional TeliaSonera root certificate > 8195793: Remove GTE CyberTrust Global Root > 8216577: Add GlobalSign's R6 Root certificate > 8222137: Remove T-Systems root CA certificate > > Please find the webrev here: http://cr.openjdk.java.net/~clanger/webrevs/8189131.8u/ > > I took the current state of cacerts from the jdk/jdk repo along with the provided testcases and brought them down to the jdk8 repository layout. > > To make the test run in JDK8, I had to > a) modify test/sun/security/lib/cacerts/VerifyCACerts.java: > 240 private static final HashSet EXPIRY_EXC_ENTRIES = new HashSet() { > I needed to add the String type to the constructor of the HashSet, since the JDK8 java compiler will not accept <> in that place. > > b) modify test/security/infra/java/security/cert/CertPathValidator/certification/ValidatePathWithParams.java > > 60 private static final String CACERTS_STORE = System.getProperty("test.jdk") > > 61 + FS + "jre" + FS + "lib" + FS + "security" + FS + "cacerts"; > I needed to adapt the path to cacerts in a JDK8 JDK/JRE as it is located in subdirectory jre there. > > Out of the tests in test/security/infra/java/security/cert/CertPathValidator/certification, there are 2 failing: > FAILED: security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java > FAILED: security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java > However, for jdk/jdk it is the same. JBS Issues for these tests exist and are yet unresolved: JDK-8202651 and JDK-8215546. > > Since the tests don't seem to be part of any tier, I propose to include them in this backport and later on also backport possible fixes to them. > > Thanks > Christoph > > [0] https://mail.openjdk.java.net/pipermail/security-dev/2019-March/019557.html > [1] https://mail.openjdk.java.net/pipermail/security-dev/2019-April/019733.html > [2] https://bugs.openjdk.java.net/browse/JDK-8189131 > Sorry for the slow response. I've built up a bit of a backlog with the recent public holidays here in the UK. It doesn't look like there's much to review here, given the main content of the patch is binary. Thanks for referencing all the imported bugs. Let's get it in and then we can work out any remaining issues once it's in the repos for people to play around with. As to testing, you should be able to direct jtreg to the jdk/test/security/infra subdirectory to run just these tests. That's how I ran the calendar ones. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue May 14 13:33:33 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 14 May 2019 14:33:33 +0100 Subject: [8u-dev] RFR+RFA (M): JDK-8176100: [REDO][REDO] G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: <59753B34-E56C-46B5-9AF6-4B1F8001CE00@amazon.com> References: <8A7A3619-56E2-4E19-A1E0-BA47CBB5BAE4@amazon.com> <25EF3922-AC36-4D6F-B5D6-49B202A44986@amazon.com> <84e8f725-ae22-a6ce-355c-713141b9bcdd@redhat.com> <9EEBDA2A-196F-40AC-AE42-8C0D69E94025@azul.com> <20665D4C-C717-4FE3-93B3-149378615B26@amazon.com> <59753B34-E56C-46B5-9AF6-4B1F8001CE00@amazon.com> Message-ID: <34e2b8c1-3371-0288-21c2-e0d42997f3e1@redhat.com> On 07/05/2019 21:45, Hohensee, Paul wrote: > Thank you, Andrey. Pushed in my name since the author, Mikael Gerdin, is > inactive. > I noticed when integrating this downstream that JDK-8064786 [0] was also silently included in this change. Was this intentional? 8062808, which prompts this change, is on my list to backport and we have the fix locally in RPMs. But there should be no need for 8064786 if the -Wreturn-type warning is not turned on by 8062808. Were you seeing such build failures with jdk8u-dev? Incidentally, there also seemed to be one line which rolled back a copyright line. If the copyright line is already later than the proposed change, it should be left as is. [0] https://bugs.openjdk.java.net/browse/JDK-8064786 Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue May 14 13:36:14 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 14 May 2019 14:36:14 +0100 Subject: [PING] [8u] RFR: 8210425: [x86] sharedRuntimeTrig/sharedRuntimeTrans compiled without optimization In-Reply-To: <34336f93b6c53942ccf522de449c550bae30d546.camel@redhat.com> References: <34336f93b6c53942ccf522de449c550bae30d546.camel@redhat.com> Message-ID: On 09/05/2019 13:39, sgehwolf at redhat.com wrote: > Ping? > > On Fri, 2019-05-03 at 18:35 +0200, Severin Gehwolf wrote: >> Hi, >> >> Could I please get reviews for this 8u backport of an optimization fix >> pertaining to the hotspot copy of fdlibm? Historically, >> sharedRuntimeTrans.cpp and sharedRuntimeTrig.cpp have been compiled >> with optimization turned off on x86/x86_64. As JDK-8210416 will be >> backported to JDK 8u fixing optimization for fdlibm itself, so should >> be the hotspot copy in OpenJDK 8u. The build system for hotspot in JDK >> 8u is very different, so the original fix for JDK 12 doesn't apply. >> It's a complete rewrite. Please see this webrev which shows the >> prerequisite patch. It adds the FDLIBM_CFLAGS logic: >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/jdk8/02/ >> >> It also fixes a bug on ppc64{,le} where optimization is being turned on >> in hotspot (-O3), but not providing the -ffp-contract=off flag (or >> older equivalent). >> >> Before (on ppc64le): >> /bin/g++ -DLINUX -D_GNU_SOURCE -DPPC64 -DPRODUCT -I. -I/home/openjdk/jdk8u/hotspot/src/share/vm/prims -I/home/openjdk/jdk8u/hotspot/src/share/vm -I/home/openjdk/jdk8u/hotspot/src/share/vm/precompiled -I/home/openjdk/jdk8u/hotspot/src/cpu/ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os_cpu/linux_ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os/linux/vm -I/home/openjdk/jdk8u/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.212-b04\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"openjdk\"" -DHOTSPOT_LIB_ARCH=\"ppc64le\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_linux_ppc -DTARGET_OS_ARCH_MODEL_linux_ppc_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -fno-strict-aliasing -fno-omit-frame-pointer -O3 -g -D_LP64=1 -DVM_LITTLE_ENDIAN -DABI_ELFv2 -mcpu=power7 -mtune=power8 -minsert-sched-nops=regroup_exact -mno-multiple -mno-string -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -std=gnu++98 -c -MMD -MP -MF ../generated/dependencies/sharedRuntimeTrig.o.d -fpch-deps -o sharedRuntimeTrig.o /home/openjdk/jdk8u/hotspot/src/share/vm/runtime/sharedRuntimeTrig.cpp >> After (on ppc64le; Note -ffp-contract=off flag): >> /bin/g++ -DLINUX -D_GNU_SOURCE -DPPC64 -DPRODUCT -I. -I/home/openjdk/jdk8u/hotspot/src/share/vm/prims -I/home/openjdk/jdk8u/hotspot/src/share/vm -I/home/openjdk/jdk8u/hotspot/src/share/vm/precompiled -I/home/openjdk/jdk8u/hotspot/src/cpu/ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os_cpu/linux_ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os/linux/vm -I/home/openjdk/jdk8u/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.212-b04\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"openjdk\"" -DHOTSPOT_LIB_ARCH=\"ppc64le\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_linux_ppc -DTARGET_OS_ARCH_MODEL_linux_ppc_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -fno-strict-aliasing -fno-omit-frame-pointer -O3 -ffp-contract=off -D_LP64=1 -DVM_LITTLE_ENDIAN -DABI_ELFv2 -mcpu=power7 -mtune=power8 -minsert-sched-nops=regroup_exact -mno-multiple -mno-string -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -std=gnu++98 -c -MMD -MP -MF ../generated/dependencies/sharedRuntimeTrig.o.d -fpch-deps -o sharedRuntimeTrig.o /home/openjdk/jdk8u/hotspot/src/share/vm/runtime/sharedRuntimeTrig.cpp >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210425 >> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210425/jdk8/02/webrev >> >> Testing: Builds on x86_64 (server/Zero). Manual inspection of compile >> log of sharedRuntimeTrans.cpp/sharedRuntimeTrig.cpp. Same for ppc64le. >> Note that we've been using this patch downstream for a while now. We >> haven't seen any issues so far. >> >> Thanks, >> Severin > Looks good to me. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue May 14 14:12:26 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 14 May 2019 15:12:26 +0100 Subject: OpenJDK 8u222-b02 EA Released Message-ID: <6ef000eb-555d-33c0-7379-6a5b606e0246@redhat.com> I've made available an early access source bundle for 8u222, based on the tag jdk8u222-b02: https://openjdk-sources.osci.io/openjdk8/openjdk8u222-b02-ea.tar.xz The tarball is accompanied by a digital signature available at: https://openjdk-sources.osci.io/openjdk8/openjdk8u222-b02-ea.tar.xz.sig This is signed by our new Red Hat OpenJDK key (openjdk at redhat.com): PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) Fingerprint = CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F SHA256 checksums: 2a397018f9746e9c752f7d39f4170a9491fe3a518ffb22b2228ab203ad10e328 openjdk8u222-b02-ea.tar.xz b052d6d04931d9514d39afa6aa9849bcd47dabddb635c3b2ec8cc9a18d49ee70 openjdk8u222-b02-ea.tar.xz.sig They are listed at https://openjdk-sources.osci.io/openjdk8/openjdk8u222-b02-ea.sha256 -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue May 14 14:19:22 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 14 May 2019 15:19:22 +0100 Subject: OpenJDK 8u222-b01 EA Released In-Reply-To: References: Message-ID: <37ffcae8-b6d6-d153-011a-090604f1a5ba@redhat.com> On 06/05/2019 09:36, Dalibor Topic wrote: > On 03.05.2019 19:57, Andrew John Hughes wrote: >> I've made available an early access source bundle for 8u222, based on >> the? tag jdk8u222-b01: >> >> https://openjdk-sources.osci.io/openjdk8/openjdk8u222-b01.tar.xz > > Hi, > > Please use an EA denotation as part of the file name in order to avoid > confusing users about the GA status of the download. Please see earlier > discussions on this list for rationale. > > cheers, > dalibor topic > >> >> The tarball is accompanied by a digital signature available at: >> >> https://openjdk-sources.osci.io/openjdk8/openjdk8u222-b01.tar.xz.sig >> >> This is signed by our new Red Hat OpenJDK key (openjdk at redhat.com): >> >> PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) >> Fingerprint = CA5F 11C6 CE22 644D 42C6? AC44 92EF 8D39 DC13 168F >> >> SHA256 checksums: >> >> 5319ca54aa176df306c30e03cfc008bc4831797c2f3fe22d2314f80f21fc7e4d >> openjdk8u222-b01.tar.xz >> 46664701ea0d6cf588ff379ee7134d83517d16fb3c2ad9036577f7a90dc5209f >> openjdk8u222-b01.tar.xz.sig >> >> They are listed at >> https://openjdk-sources.osci.io/openjdk8/openjdk8u222-b01.sha256 >> > I've done that with the latest one (b02), though I think EA is generally a little sketchy a designation here in general. How can there be "early access" when everyone has constant access to the source of a FOSS project? -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From hohensee at amazon.com Tue May 14 15:22:33 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 14 May 2019 15:22:33 +0000 Subject: [8u-dev] RFR+RFA (M): JDK-8176100: [REDO][REDO] G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: <34e2b8c1-3371-0288-21c2-e0d42997f3e1@redhat.com> References: <8A7A3619-56E2-4E19-A1E0-BA47CBB5BAE4@amazon.com> <25EF3922-AC36-4D6F-B5D6-49B202A44986@amazon.com> <84e8f725-ae22-a6ce-355c-713141b9bcdd@redhat.com> <9EEBDA2A-196F-40AC-AE42-8C0D69E94025@azul.com> <20665D4C-C717-4FE3-93B3-149378615B26@amazon.com> <59753B34-E56C-46B5-9AF6-4B1F8001CE00@amazon.com> <34e2b8c1-3371-0288-21c2-e0d42997f3e1@redhat.com> Message-ID: <3B733DCF-015B-419E-855D-DBE13B609308@amazon.com> Hi Andrew, The commit is http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/32bc598624bd. Both problems are in jni.cpp. It wasn't intentional: I overlooked it moving our internal patch to jdk8u-dev. It's there because a compiler for another internally-supported platform complained. We weren't aware of 8062808. If you like, I'll create a backport issue for 8062808 and point it to the 8176100 backport patch, or I could revert the 8062808-specific code and and do 8062808 separately. I'll file an issue to fix the copyright date. Thanks, Paul ?On 5/14/19, 6:34 AM, "Andrew John Hughes" wrote: On 07/05/2019 21:45, Hohensee, Paul wrote: > Thank you, Andrey. Pushed in my name since the author, Mikael Gerdin, is > inactive. > I noticed when integrating this downstream that JDK-8064786 [0] was also silently included in this change. Was this intentional? 8062808, which prompts this change, is on my list to backport and we have the fix locally in RPMs. But there should be no need for 8064786 if the -Wreturn-type warning is not turned on by 8062808. Were you seeing such build failures with jdk8u-dev? Incidentally, there also seemed to be one line which rolled back a copyright line. If the copyright line is already later than the proposed change, it should be left as is. [0] https://bugs.openjdk.java.net/browse/JDK-8064786 Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From christoph.langer at sap.com Tue May 14 20:50:31 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 14 May 2019 20:50:31 +0000 Subject: Fonts with embedded bitmaps are not always rotated In-Reply-To: References: Message-ID: Hi Mit, first of all: Is this an issue with JDK8 only which requires a new patch or is it something that is fixed in a higher OpenJDK release and needs to be backported? If the latter is the case, please send us the bug URL in JBS = OpenJDK Bug system [0]. If not, can you please send a problem description by which one can open a bug. Secondly, if you want to contribute your patch, the OpenJDK project requires you to sign a committers agreement (OCA). Do you have that? Further information can be found at [1], [2]. Thanks Christoph [0] https://bugs.openjdk.java.net/ [1] https://openjdk.java.net/contribute/ [2] http://www.oracle.com/technetwork/oca-405177.pdf > -----Original Message----- > From: jdk8u-dev On Behalf Of > Mitsuhiro Yamamoto > Sent: Dienstag, 14. Mai 2019 06:57 > To: jdk8u-dev at openjdk.java.net > Subject: Fonts with embedded bitmaps are not always rotated > > Hi there, > > I would like to fix a issue below, so I created a patch file for it. > https://github.com/AdoptOpenJDK/openjdk-build/issues/945 > > Can you help me with this? > > diff --git a/jdk/src/share/native/sun/font/freetypeScaler.c > b/jdk/src/share/native/sun/font/freetypeScaler.c > index 8c9207d9b2..59747cc860 100644 > --- a/jdk/src/share/native/sun/font/freetypeScaler.c > +++ b/jdk/src/share/native/sun/font/freetypeScaler.c > @@ -364,6 +364,19 @@ > Java_sun_font_FreetypeFontScaler_createScalerContextNative( > context->doBold = (boldness != 1.0); > context->doItalize = (italic != 0); > > + /* freetype is very keen to use embedded bitmaps, even if it knows > + * there is a rotation or you asked for antialiasing. > + * In the rendering path we will check useSBits and disable > + * bitmaps unless it is set. And here we set it only if none > + * of the conditions invalidate using it. > + * Note that we allow embedded bitmaps for the LCD case. > + */ > + if ((aa != TEXT_AA_ON) && (fm != TEXT_FM_ON) && > + !context->doBold && !context->doItalize && > + (context->transform.yx == 0) && (context->transform.xy == 0)) > + { > + context->useSbits = 1; > + } > return ptr_to_jlong(context); > } > > @@ -685,9 +698,8 @@ > Java_sun_font_FreetypeFontScaler_getGlyphImageNative( > return ptr_to_jlong(getNullGlyphImage()); > } > > - /* if algorithmic styling is required then we do not request bitmap */ > - if (context->doBold || context->doItalize) { > - renderFlags = FT_LOAD_DEFAULT; > + if (!context->useSbits) { > + renderFlags |= FT_LOAD_NO_BITMAP; > } > > /* NB: in case of non identity transform > > Mit From christoph.langer at sap.com Tue May 14 20:55:12 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 14 May 2019 20:55:12 +0000 Subject: [8u] RFR: 8189131: Open-source the Oracle JDK Root Certificates (Integration for JEP 319: Root Certificates) In-Reply-To: <2f1c2b92-1957-3126-889d-d1070a605f3a@redhat.com> References: <2f1c2b92-1957-3126-889d-d1070a605f3a@redhat.com> Message-ID: > Sorry for the slow response. I've built up a bit of a backlog with the > recent public holidays here in the UK. > > It doesn't look like there's much to review here, given the main content > of the patch is binary. Thanks for referencing all the imported bugs. > Let's get it in and then we can work out any remaining issues once it's > in the repos for people to play around with. Thanks for the review, Andrew. I've pushed it today. From now on I'll also bring the updates for cacerts down to 8. > As to testing, you should be able to direct jtreg to the > jdk/test/security/infra subdirectory to run just these tests. That's how > I ran the calendar ones. Yep, sure. It's just that the tests aren't in any tier. I'll follow up on these as well. Best regards Christoph From m.yamamoto at change-vision.com Tue May 14 23:34:19 2019 From: m.yamamoto at change-vision.com (Mitsuhiro Yamamoto) Date: Wed, 15 May 2019 08:34:19 +0900 Subject: Fonts with embedded bitmaps are not always rotated In-Reply-To: References: Message-ID: Hi Christoph, This is an issue for JDK8. Actually there was a problem with a higher OpenJDK, but it has already been fixed in JDK11.. https://bugs.openjdk.java.net/browse/JDK-8204929 I just want to get the same fix into JDK8. Mit 2019?5?15?(?) 5:51 Langer, Christoph : > Hi Mit, > > first of all: Is this an issue with JDK8 only which requires a new patch > or is it something that is fixed in a higher OpenJDK release and needs to > be backported? If the latter is the case, please send us the bug URL in JBS > = OpenJDK Bug system [0]. If not, can you please send a problem description > by which one can open a bug. > > Secondly, if you want to contribute your patch, the OpenJDK project > requires you to sign a committers agreement (OCA). Do you have that? > Further information can be found at [1], [2]. > > Thanks > Christoph > > [0] https://bugs.openjdk.java.net/ > [1] https://openjdk.java.net/contribute/ > [2] http://www.oracle.com/technetwork/oca-405177.pdf > > > > -----Original Message----- > > From: jdk8u-dev On Behalf Of > > Mitsuhiro Yamamoto > > Sent: Dienstag, 14. Mai 2019 06:57 > > To: jdk8u-dev at openjdk.java.net > > Subject: Fonts with embedded bitmaps are not always rotated > > > > Hi there, > > > > I would like to fix a issue below, so I created a patch file for it. > > https://github.com/AdoptOpenJDK/openjdk-build/issues/945 > > > > Can you help me with this? > > > > diff --git a/jdk/src/share/native/sun/font/freetypeScaler.c > > b/jdk/src/share/native/sun/font/freetypeScaler.c > > index 8c9207d9b2..59747cc860 100644 > > --- a/jdk/src/share/native/sun/font/freetypeScaler.c > > +++ b/jdk/src/share/native/sun/font/freetypeScaler.c > > @@ -364,6 +364,19 @@ > > Java_sun_font_FreetypeFontScaler_createScalerContextNative( > > context->doBold = (boldness != 1.0); > > context->doItalize = (italic != 0); > > > > + /* freetype is very keen to use embedded bitmaps, even if it knows > > + * there is a rotation or you asked for antialiasing. > > + * In the rendering path we will check useSBits and disable > > + * bitmaps unless it is set. And here we set it only if none > > + * of the conditions invalidate using it. > > + * Note that we allow embedded bitmaps for the LCD case. > > + */ > > + if ((aa != TEXT_AA_ON) && (fm != TEXT_FM_ON) && > > + !context->doBold && !context->doItalize && > > + (context->transform.yx == 0) && (context->transform.xy == 0)) > > + { > > + context->useSbits = 1; > > + } > > return ptr_to_jlong(context); > > } > > > > @@ -685,9 +698,8 @@ > > Java_sun_font_FreetypeFontScaler_getGlyphImageNative( > > return ptr_to_jlong(getNullGlyphImage()); > > } > > > > - /* if algorithmic styling is required then we do not request bitmap > */ > > - if (context->doBold || context->doItalize) { > > - renderFlags = FT_LOAD_DEFAULT; > > + if (!context->useSbits) { > > + renderFlags |= FT_LOAD_NO_BITMAP; > > } > > > > /* NB: in case of non identity transform > > > > Mit > From christoph.langer at sap.com Wed May 15 07:05:58 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 15 May 2019 07:05:58 +0000 Subject: RFR(S) Backport: 8213213: Remove src/java.desktop/unix/classes/sun/awt/X11/keysym2ucs.h Message-ID: Hi, please review this simple backport of a cleanup change for awt/X11. The patch failed on this hunk: --- XKeysym.java +++ XKeysym.java @@ -33,15 +44,6 @@ public class XKeysym { - public static void main( String[] args ) { - System.out.println( "Cyrillc zhe:"+convertKeysym(0x06d6, 0)); - System.out.println( "Arabic sheen:"+convertKeysym(0x05d4, 0)); - System.out.println( "Latin a breve:"+convertKeysym(0x01e3, 0)); - System.out.println( "Latin f:"+convertKeysym(0x066, 0)); - System.out.println( "Backspace:"+Integer.toHexString(convertKeysym(0xff08, 0))); - System.out.println( "Ctrl+f:"+Integer.toHexString(convertKeysym(0x066, XConstants.ControlMask))); - } - private XKeysym() {} static class Keysym2JavaKeycode { The signature of main had been changed by JDK-8211300 which isn?t downported. So I deleted the main method manually to resolve ?? It also failed to delete src/solaris/classes/sun/awt/X11/keysym2ucs.h.rej because the existing file of jdk8 obviously had diffs to the upstream version. I deleted it nevertheless. The change of src/java.desktop/unix/legal/xwindows.md moved to THIRD_PARTY_README. This part of the change I?ll have to push to all sub-repos of the 8u forest. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213213.8u.jdk/ Original Bug: https://bugs.openjdk.java.net/browse/JDK-8213213 Thanks Christoph From hohensee at amazon.com Wed May 15 15:48:15 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 15 May 2019 15:48:15 +0000 Subject: RFR(S) Backport: 8213213: Remove src/java.desktop/unix/classes/sun/awt/X11/keysym2ucs.h In-Reply-To: References: Message-ID: Looks good. Paul ?On 5/15/19, 12:07 AM, "jdk8u-dev on behalf of Langer, Christoph" wrote: Hi, please review this simple backport of a cleanup change for awt/X11. The patch failed on this hunk: --- XKeysym.java +++ XKeysym.java @@ -33,15 +44,6 @@ public class XKeysym { - public static void main( String[] args ) { - System.out.println( "Cyrillc zhe:"+convertKeysym(0x06d6, 0)); - System.out.println( "Arabic sheen:"+convertKeysym(0x05d4, 0)); - System.out.println( "Latin a breve:"+convertKeysym(0x01e3, 0)); - System.out.println( "Latin f:"+convertKeysym(0x066, 0)); - System.out.println( "Backspace:"+Integer.toHexString(convertKeysym(0xff08, 0))); - System.out.println( "Ctrl+f:"+Integer.toHexString(convertKeysym(0x066, XConstants.ControlMask))); - } - private XKeysym() {} static class Keysym2JavaKeycode { The signature of main had been changed by JDK-8211300 which isn?t downported. So I deleted the main method manually to resolve ?? It also failed to delete src/solaris/classes/sun/awt/X11/keysym2ucs.h.rej because the existing file of jdk8 obviously had diffs to the upstream version. I deleted it nevertheless. The change of src/java.desktop/unix/legal/xwindows.md moved to THIRD_PARTY_README. This part of the change I?ll have to push to all sub-repos of the 8u forest. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213213.8u.jdk/ Original Bug: https://bugs.openjdk.java.net/browse/JDK-8213213 Thanks Christoph From gil at azul.com Wed May 15 18:49:55 2019 From: gil at azul.com (Gil Tene) Date: Wed, 15 May 2019 18:49:55 +0000 Subject: Mystery meat OpenJDK builds strike again Message-ID: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> Umm? Lumpy.local-43% docker run -it --rm openjdk:8 java -version openjdk version "1.8.0_212" OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1~deb9u1-b01) OpenJDK 64-Bit Server VM (build 25.212-b01, mixed mode) Lumpy.local-44% date Wed May 15 11:41:12 PDT 2019 Look at the build number carefully? This was populated no later than March 27, 2019. 3 weeks before the actual 8u212 was released on April 16, 2019. Similarly: Lumpy.local-46% docker run -it --rm openjdk:11 java -version openjdk version "11.0.3" 2019-04-16 OpenJDK Runtime Environment (build 11.0.3+1-Debian-1bpo91) OpenJDK 64-Bit Server VM (build 11.0.3+1-Debian-1bpo91, mixed mode, sharing) Lumpy.local-47% date Wed May 15 11:43:12 PDT 2019 This one was populate dno later than April 3, 2 weeks before the actual 11.0.3 was released on April 16, 2019 If anyone was wondering about the importance of having version strings say "EA" (or some other "THIS IS NOT a RELEASED VERSION" warning) on any and all OpenJDK builds that are not an actual release build, the above shows you how bad things get when that practice is not followed. Right now, anyone using the *Official* Docker images for OpenJDK 8 and 11 (https://hub.docker.com/_/openjdk) is probably thinking that they are running 8u212 or 11.0.3, when what they are actually running is an interim "work in progress build", with several bugs unaddressed, several updates missing, and (critically) CVE vulnerabilities that were fixed in the actual 8u212 and 11.0.3 un-addressed. The mechanics of how this situation came about seem to be: The docker file for openjdk:8 (https://github.com/docker-library/openjdk/blob/b8ce9eff38451de3282b2eb2bcd8b520fb95e1ce/8/jdk/Dockerfile ) was updated on March 27, 2019, 3 weeks before the actual release of OpenJDK 8u212 (see changes in https://github.com/docker-library/openjdk/commit/b8ce9eff38451de3282b2eb2bcd8b520fb95e1ce#diff-fef076ee1e5f270f2c5a93d075150919), and is set to use a specific Debian stretch build version (8u212-b01-1~deb9u1) that was available at that time, pulled via apt-get from debian stretch repos. Similarly, the docker file for openjdk:11 (https://github.com/docker-library/openjdk/blob/178c542fbb93a8f8a42e331b73a1214c9d8ba81d/11/jdk/Dockerfile) was updated on April 3, 2019, two weeks before the actual release of OpenJDK 11.0.3 (see changes in https://github.com/docker-library/openjdk/commit/178c542fbb93a8f8a42e331b73a1214c9d8ba81d#diff-c338262eaf0fd203322a06702be174e0), and set to use a specific Debian stretch build version (11.0.3+1-1~bpo9+1) also pulled via apt-get from debian stretch repos. Why Debian populated their repos with these builds is their business, and why docker chose to use those specific debian builds can be speculated about all we want. the details don't matter. The end result of these cumulative "reasonable" (according to some people) choices is that the default openjdk runs done by millions of people on docker right now are using "mystery meat", incomplete, and exposed builds while seeming to report (to the lay person) a Java version that would suggest a real 8u212 or 11.0.3 (which one would expect has the security vulnerabilities in the April update addressed, the bug fixes included, etc.). Making sure OpenJDK version string only show non-EA contents in actual release builds (which is the practice we had recently moved to for both 8u and 11u) will not necessarily prevent such unfortunate decision chains from getting interim builds to unsuspecting end users, but will at least (assuming no malice is involved and no manual removal of EA labels happens) make it clear to the end user that what they got is not an actual released version. ? Gil. From hohensee at amazon.com Wed May 15 20:42:51 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 15 May 2019 20:42:51 +0000 Subject: [PING] [8u] RFR: 8210425: [x86] sharedRuntimeTrig/sharedRuntimeTrans compiled without optimization In-Reply-To: <34336f93b6c53942ccf522de449c550bae30d546.camel@redhat.com> References: <34336f93b6c53942ccf522de449c550bae30d546.camel@redhat.com> Message-ID: <2474115F-1A08-4C22-A267-0FA93FA29A09@amazon.com> Looks good. Paul ?On 5/9/19, 5:39 AM, "hotspot-dev on behalf of sgehwolf at redhat.com" wrote: Ping? On Fri, 2019-05-03 at 18:35 +0200, Severin Gehwolf wrote: > Hi, > > Could I please get reviews for this 8u backport of an optimization fix > pertaining to the hotspot copy of fdlibm? Historically, > sharedRuntimeTrans.cpp and sharedRuntimeTrig.cpp have been compiled > with optimization turned off on x86/x86_64. As JDK-8210416 will be > backported to JDK 8u fixing optimization for fdlibm itself, so should > be the hotspot copy in OpenJDK 8u. The build system for hotspot in JDK > 8u is very different, so the original fix for JDK 12 doesn't apply. > It's a complete rewrite. Please see this webrev which shows the > prerequisite patch. It adds the FDLIBM_CFLAGS logic: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/jdk8/02/ > > It also fixes a bug on ppc64{,le} where optimization is being turned on > in hotspot (-O3), but not providing the -ffp-contract=off flag (or > older equivalent). > > Before (on ppc64le): > /bin/g++ -DLINUX -D_GNU_SOURCE -DPPC64 -DPRODUCT -I. -I/home/openjdk/jdk8u/hotspot/src/share/vm/prims -I/home/openjdk/jdk8u/hotspot/src/share/vm -I/home/openjdk/jdk8u/hotspot/src/share/vm/precompiled -I/home/openjdk/jdk8u/hotspot/src/cpu/ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os_cpu/linux_ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os/linux/vm -I/home/openjdk/jdk8u/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.212-b04\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"openjdk\"" -DHOTSPOT_LIB_ARCH=\"ppc64le\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_linux_ppc -DTARGET_OS_ARCH_MODEL_linux_ppc_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -fno-strict-aliasing -fno-omit-frame-pointer -O3 -g -D_LP64=1 -DVM_LITTLE_ENDIAN -DABI_ELFv2 -mcpu=power7 -mtune=power8 -minsert-sched-nops=regroup_exact -mno-multiple -mno-string -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -std=gnu++98 -c -MMD -MP -MF ../generated/dependencies/sharedRuntimeTrig.o.d -fpch-deps -o sharedRuntimeTrig.o /home/openjdk/jdk8u/hotspot/src/share/vm/runtime/sharedRuntimeTrig.cpp > After (on ppc64le; Note -ffp-contract=off flag): > /bin/g++ -DLINUX -D_GNU_SOURCE -DPPC64 -DPRODUCT -I. -I/home/openjdk/jdk8u/hotspot/src/share/vm/prims -I/home/openjdk/jdk8u/hotspot/src/share/vm -I/home/openjdk/jdk8u/hotspot/src/share/vm/precompiled -I/home/openjdk/jdk8u/hotspot/src/cpu/ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os_cpu/linux_ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os/linux/vm -I/home/openjdk/jdk8u/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.212-b04\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"openjdk\"" -DHOTSPOT_LIB_ARCH=\"ppc64le\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_linux_ppc -DTARGET_OS_ARCH_MODEL_linux_ppc_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -fno-strict-aliasing -fno-omit-frame-pointer -O3 -ffp-contract=off -D_LP64=1 -DVM_LITTLE_ENDIAN -DABI_ELFv2 -mcpu=power7 -mtune=power8 -minsert-sched-nops=regroup_exact -mno-multiple -mno-string -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -std=gnu++98 -c -MMD -MP -MF ../generated/dependencies/sharedRuntimeTrig.o.d -fpch-deps -o sharedRuntimeTrig.o /home/openjdk/jdk8u/hotspot/src/share/vm/runtime/sharedRuntimeTrig.cpp > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210425 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210425/jdk8/02/webrev > > Testing: Builds on x86_64 (server/Zero). Manual inspection of compile > log of sharedRuntimeTrans.cpp/sharedRuntimeTrig.cpp. Same for ppc64le. > Note that we've been using this patch downstream for a while now. We > haven't seen any issues so far. > > Thanks, > Severin From gnu.andrew at redhat.com Wed May 15 21:05:54 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 15 May 2019 22:05:54 +0100 Subject: [8u-dev] RFR+RFA (M): JDK-8176100: [REDO][REDO] G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: <3B733DCF-015B-419E-855D-DBE13B609308@amazon.com> References: <8A7A3619-56E2-4E19-A1E0-BA47CBB5BAE4@amazon.com> <25EF3922-AC36-4D6F-B5D6-49B202A44986@amazon.com> <84e8f725-ae22-a6ce-355c-713141b9bcdd@redhat.com> <9EEBDA2A-196F-40AC-AE42-8C0D69E94025@azul.com> <20665D4C-C717-4FE3-93B3-149378615B26@amazon.com> <59753B34-E56C-46B5-9AF6-4B1F8001CE00@amazon.com> <34e2b8c1-3371-0288-21c2-e0d42997f3e1@redhat.com> <3B733DCF-015B-419E-855D-DBE13B609308@amazon.com> Message-ID: On 14/05/2019 16:22, Hohensee, Paul wrote: > Hi Andrew, > > The commit is http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/32bc598624bd. Both problems are in jni.cpp. > > It wasn't intentional: I overlooked it moving our internal patch to jdk8u-dev. It's there because a compiler for another internally-supported platform complained. We weren't aware of 8062808. If you like, I'll create a backport issue for 8062808 and point it to the 8176100 backport patch, or I could revert the 8062808-specific code and and do 8062808 separately. > It's ok. I asked about it more because I was curious why the change was needed than any intention to require further changes. I have backports of 8062808 and related issues already downstream that I intend to include, so I'll just list 8064786 in the commit for 8062808, so it appears as resolved in OpenJDK 8u, even though the actual fix is in the earlier commit. > I'll file an issue to fix the copyright date. > Thanks. > Thanks, > > Paul > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Wed May 15 21:28:06 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 15 May 2019 22:28:06 +0100 Subject: Fonts with embedded bitmaps are not always rotated In-Reply-To: References: Message-ID: On 15/05/2019 00:34, Mitsuhiro Yamamoto wrote: > Hi Christoph, > > This is an issue for JDK8. > Actually there was a problem with a higher OpenJDK, but it has already been > fixed in JDK11.. > https://bugs.openjdk.java.net/browse/JDK-8204929 > I just want to get the same fix into JDK8. > > Mit > Ah ok, so this isn't a new change but just needs: https://hg.openjdk.java.net/jdk/jdk/rev/db4f24a6cf34 to be backported. We can do that :-) The patch applies cleanly, so I'll flag the bug with jdk8u-fix-request and then this can be pushed as soon as that's approved. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Wed May 15 21:39:46 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 15 May 2019 22:39:46 +0100 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> Message-ID: On 15/05/2019 19:49, Gil Tene wrote: > Umm? > > Lumpy.local-43% docker run -it --rm openjdk:8 java -version > openjdk version "1.8.0_212" > OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1~deb9u1-b01) > OpenJDK 64-Bit Server VM (build 25.212-b01, mixed mode) > Lumpy.local-44% date > Wed May 15 11:41:12 PDT 2019 > > Look at the build number carefully? This was populated no later > than March 27, 2019. 3 weeks before the actual 8u212 was released > on April 16, 2019. > > Similarly: > > Lumpy.local-46% docker run -it --rm openjdk:11 java -version > openjdk version "11.0.3" 2019-04-16 > OpenJDK Runtime Environment (build 11.0.3+1-Debian-1bpo91) > OpenJDK 64-Bit Server VM (build 11.0.3+1-Debian-1bpo91, mixed mode, sharing) > Lumpy.local-47% date > Wed May 15 11:43:12 PDT 2019 > > This one was populate dno later than April 3, 2 weeks before > the actual 11.0.3 was released on April 16, 2019 > > If anyone was wondering about the importance of having version strings say > "EA" (or some other "THIS IS NOT a RELEASED VERSION" warning) on any > and all OpenJDK builds that are not an actual release build, the above shows > you how bad things get when that practice is not followed. > > Right now, anyone using the *Official* Docker images for OpenJDK 8 and 11 > (https://hub.docker.com/_/openjdk) is probably thinking that they are running > 8u212 or 11.0.3, when what they are actually running is an interim "work in > progress build", with several bugs unaddressed, several updates missing, > and (critically) CVE vulnerabilities that were fixed in the actual > 8u212 and 11.0.3 un-addressed. > > The mechanics of how this situation came about seem to be: > > The docker file for openjdk:8 (https://github.com/docker-library/openjdk/blob/b8ce9eff38451de3282b2eb2bcd8b520fb95e1ce/8/jdk/Dockerfile ) was updated on March 27, 2019, 3 weeks before the actual release of > OpenJDK 8u212 (see changes in https://github.com/docker-library/openjdk/commit/b8ce9eff38451de3282b2eb2bcd8b520fb95e1ce#diff-fef076ee1e5f270f2c5a93d075150919), and is set to use a specific > Debian stretch build version (8u212-b01-1~deb9u1) that was available > at that time, pulled via apt-get from debian stretch repos. > > Similarly, the docker file for openjdk:11 (https://github.com/docker-library/openjdk/blob/178c542fbb93a8f8a42e331b73a1214c9d8ba81d/11/jdk/Dockerfile) > was updated on April 3, 2019, two weeks before the actual release > of OpenJDK 11.0.3 (see changes in https://github.com/docker-library/openjdk/commit/178c542fbb93a8f8a42e331b73a1214c9d8ba81d#diff-c338262eaf0fd203322a06702be174e0), and set to use a specific > Debian stretch build version (11.0.3+1-1~bpo9+1) also pulled via apt-get > from debian stretch repos. > > Why Debian populated their repos with these builds is their business, and > why docker chose to use those specific debian builds can be speculated > about all we want. the details don't matter. The end result of these > cumulative "reasonable" (according to some people) choices is that the > default openjdk runs done by millions of people on docker right now are > using "mystery meat", incomplete, and exposed builds while seeming to > report (to the lay person) a Java version that would suggest a real 8u212 > or 11.0.3 (which one would expect has the security vulnerabilities in the > April update addressed, the bug fixes included, etc.). > > Making sure OpenJDK version string only show non-EA contents in actual > release builds (which is the practice we had recently moved to for both 8u > and 11u) will not necessarily prevent such unfortunate decision chains from > getting interim builds to unsuspecting end users, but will at least (assuming > no malice is involved and no manual removal of EA labels happens) make > it clear to the end user that what they got is not an actual released version. > > ? Gil. > > > > > Wouldn't this be better raised on the Debian mailing lists than here? The above is not the default output, so they are already overriding any defaults we might set. At least it does say it is 11.0.3+1, which can be compared to the official released version [0] [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000951.html -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Wed May 15 21:44:48 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 15 May 2019 23:44:48 +0200 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> Message-ID: <6701b582-174f-a28a-fd65-4db7742f5ee5@redhat.com> On 5/15/19 11:39 PM, Andrew John Hughes wrote: > Wouldn't this be better raised on the Debian mailing lists than here? +1 Plus, who actually maintains the "official" Docker images for 8u and 11u? Github history for Dockerfiles points to no one I recognize from around OpenJDK. That seems to be part of the problem here: responsible people are not in the loop to get all the important memos. -Aleksey From gnu.andrew at redhat.com Wed May 15 21:45:23 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 15 May 2019 22:45:23 +0100 Subject: When to do a review for a downported change? In-Reply-To: References: <1f642250-2a46-4b02-ebc5-fcdc9b3870c8@redhat.com> <28cd659b-b6a1-d557-12e0-b004239d2d38@redhat.com> Message-ID: <24376b51-8149-e5da-7222-9e1e56474226@redhat.com> On 14/05/2019 17:22, Aleksey Shipilev wrote: > On 5/14/19 5:52 PM, Andrew Haley wrote: >> On 5/14/19 4:02 PM, Aleksey Shipilev wrote: >>> Aside, I think it is a good style (though optional) to post the diff >>> between the upstream patch and the backport -- it seems low-overhead >>> when there is the mq patch on top. This would also make reviews much >>> easier, and probably fits the backporting workflow too. That is what >>> I do anyway. >> >> Post in what format, though? A diff of a diff? > > Depends. Whatever fits the workflow, and maybe with workflow adjustments: > a) Sometimes just copy-paste *.rej and explain why those are not applicable. > b) Sometimes just inline the "addon" patches that fix the original change: in my workflow with mq > there are two patches: the original "backport" change with rejects, and the follow up patch that > resolves those rejects, hg qdiff the second one and paste it. > c) Sometimes just the copy-pasted affected block "before" / "after", showing the adjustment made; > d) Sometimes just the diff of a diff is enough to highlight the changes. If that is not available, > I would do that during review for a non-trivial backport _anyway_. > e) Sometimes just pointing out which files and methods have differences vs upstream version, so we > can eyeball them. > > I mean, anything that _you_ as reviewer, who sees the backport for the first time, would like to see > in order to understand what was done, quickly and exactly. If backport differences are indeed > trivial, then any of the ways above would amount to a copy-pasted paragraph in RFR, and it would > breeze through the review, making the whole thing low-overhead. > > (This is not to say people here are not doing that. Just describing "the common sense" out loud.) > > -Aleksey > Indeed. When reviewing backports (which I do for jdk8u-fix-request as well), I diff the original changeset against the webrev patch. Having that in a review e-mail would help. As to trivial changes, I'd lump copyright headers in with the filename shuffling as trivial stuff that doesn't warrant a review. It is worth noting though that copyright changes should only ever be applied when they move to a later year (e.g. patch says 2019, code is 2018, so changed to 2019). We shouldn't roll backwards (e.g. patch says 2018, code is 2019, so changed to 2018). -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From martijnverburg at gmail.com Thu May 16 02:31:28 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 16 May 2019 11:31:28 +0900 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: <6701b582-174f-a28a-fd65-4db7742f5ee5@redhat.com> References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> <6701b582-174f-a28a-fd65-4db7742f5ee5@redhat.com> Message-ID: AdoptOpenJDK is working with the Docker folks to find out who is providing the 'official' openjdk builds there (we're also not sure who's currently providing that openjdk). We're also in some longer-term discussions with Debian folks about how they can better manage their builds (since they have a build from source policy). But yeah - it's really a concern for those two communities. Cheers, Martijn On Thu, 16 May 2019 at 06:45, Aleksey Shipilev wrote: > On 5/15/19 11:39 PM, Andrew John Hughes wrote: > > Wouldn't this be better raised on the Debian mailing lists than here? > > +1 > > Plus, who actually maintains the "official" Docker images for 8u and 11u? > Github history for > Dockerfiles points to no one I recognize from around OpenJDK. That seems > to be part of the problem > here: responsible people are not in the loop to get all the important > memos. > > -Aleksey > > From denghui.ddh at alipay.com Fri May 10 10:17:42 2019 From: denghui.ddh at alipay.com (=?UTF-8?B?6JGj55m76L6JKOWNk+aYgik=?=) Date: Fri, 10 May 2019 18:17:42 +0800 Subject: =?UTF-8?B?5Zue5aSN77yaUkZSOiA4MjIzMTQ3OiBKRlIgQmFja3BvcnQgKHRvIGpkazh1KQ==?= In-Reply-To: References: <3E224264-DA96-48B8-8270-2B77B09E190F@azul.com> , Message-ID: Hi Mario, Good suggestion! Related bugs are as follows: 8223689: Add JFR Thread Sampling Support http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_thread_samp_20190326/ 8223690: Add JFR BiasedLock Event Support http://cr.openjdk.java.net/~luchsh/hs_biasedlock/ http://cr.openjdk.java.net/~luchsh/jdk_biasedlock/ 8223691: Add JFR G1 Region Type Change Event Support http://cr.openjdk.java.net/~luchsh/g1region_type_change_event 8223692: Add JFR G1 Heap Summary Event Support http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_g1heapsum_hs_20190326/ http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_g1heapsum_jdk_20190326/ Thanks, Denghui ------------------------------------------------------------------ ????Mario Torre ?????2019?5?10?(???) 17:01 ???????(??) ????jdk8u-dev ????Re: RFR: 8223147: JFR Backport (to jdk8u) Hi Denghui, Sure, those patches are surely of interest. I would like if you could prepare the patches referencing each bug they backport like Azul did in their series, then we can proceed as soon as the main patch has been merged. Thanks for doing this! Cheers, Mario On Fri, May 10, 2019 at 10:57 AM ???(??) wrote: > > Hi Mario?Andrey and all, > > We(Alibaba) provided below JFR patches some time ago(check previous Guangyu' discussion in this thread), which are incremental changes based on Azul' patchset. > > 1. Add thread sampling support: > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_thread_samp_20190326/ > > 2. Add biasedLocking event support: > http://cr.openjdk.java.net/~luchsh/hs_biasedlock/ > http://cr.openjdk.java.net/~luchsh/jdk_biasedlock/ > > 3. Add G1 region type change event: > http://cr.openjdk.java.net/~luchsh/g1region_type_change_event > > 4. Add G1 heap summay event: > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_g1heapsum_hs_20190326/ > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_g1heapsum_jdk_20190326/ > > In addition to events support, they also include fixes for some failed testcases, > As repository has been created now(Thanks for Alexey' work), we are planning to proceed the integraion for these patches. > What's your comments? > > > Thanks, > Denghui > > ------------------------------------------------------------------ > ????Mario Torre > ?????2019?5?7?(???) 21:53 > ????Andrey Petushkov > ? ??jdk8u-dev > ? ??Re: RFR: 8223147: JFR Backport (to jdk8u) > > On Tue, May 7, 2019 at 1:20 PM Andrey Petushkov wrote: > > > > Hi All, > > Hi Andrey, thanks for the patch! > > > RFR for initial JFR backport to current state of jdk8u-jfr-incubator is here http://cr.openjdk.java.net/~apetushkov/8223147/ > > Please could you review and hopefully approve > > I'm going through it now, I'll get back to you as soon as possible! > > > The changes are the same as in initial review request [1] except two fixes were added for the bugs found after integration > > of Alibaba's implementation of thread sampling (note that according to the plan Alibaba's patches are not included into this RFR) > > The webrev includes bug ids for all changes backported under it, however these are not separated on per-file basis > > This is perfect, so we have proper tracking of the patches. > > > One process question (thus Andrew in To), the new webrev currently only includes the code which applies to jdk8u-jfr-incubator > > repo, but what about aarch64 and aarch32 ports which are not available there? I don't see a reason to prevent them from > > having JFR and there is code ready for that ([1]). How could we proceed with integration of it? > > You are right, it didn't occur to me that this code was not part of > the repository, but this is because the staging repo is forked from > jdk8u-dev which doesn't contain those ports. > > I think we should indeed backport the other changes, perhaps once > everything is in mainline we can push into the shenandoah/arm/etc... > repositories individual patches? > > Cheers, > Mario > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From christoph.langer at sap.com Thu May 16 06:02:00 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 16 May 2019 06:02:00 +0000 Subject: RFR(S) Backport: 8213213: Remove src/java.desktop/unix/classes/sun/awt/X11/keysym2ucs.h In-Reply-To: References: Message-ID: Thanks, Paul. > -----Original Message----- > From: Hohensee, Paul > Sent: Mittwoch, 15. Mai 2019 17:48 > To: Langer, Christoph ; jdk8u- > dev at openjdk.java.net > Subject: Re: RFR(S) Backport: 8213213: Remove > src/java.desktop/unix/classes/sun/awt/X11/keysym2ucs.h > > Looks good. > > Paul > > ?On 5/15/19, 12:07 AM, "jdk8u-dev on behalf of Langer, Christoph" dev-bounces at openjdk.java.net on behalf of christoph.langer at sap.com> > wrote: > > Hi, > > please review this simple backport of a cleanup change for awt/X11. > > The patch failed on this hunk: > > --- XKeysym.java > +++ XKeysym.java > @@ -33,15 +44,6 @@ > public class XKeysym { > - public static void main( String[] args ) { > - System.out.println( "Cyrillc zhe:"+convertKeysym(0x06d6, 0)); > - System.out.println( "Arabic sheen:"+convertKeysym(0x05d4, 0)); > - System.out.println( "Latin a breve:"+convertKeysym(0x01e3, 0)); > - System.out.println( "Latin f:"+convertKeysym(0x066, 0)); > - System.out.println( > "Backspace:"+Integer.toHexString(convertKeysym(0xff08, 0))); > - System.out.println( > "Ctrl+f:"+Integer.toHexString(convertKeysym(0x066, > XConstants.ControlMask))); > - } > - > private XKeysym() {} > static class Keysym2JavaKeycode { > > The signature of main had been changed by JDK-8211300 which isn?t > downported. So I deleted the main method manually to resolve ?? > > It also failed to delete src/solaris/classes/sun/awt/X11/keysym2ucs.h.rej > because the existing file of jdk8 obviously had diffs to the upstream version. I > deleted it nevertheless. > > The change of src/java.desktop/unix/legal/xwindows.md moved to > THIRD_PARTY_README. This part of the change I?ll have to push to all sub- > repos of the 8u forest. > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213213.8u.jdk/ > Original Bug: https://bugs.openjdk.java.net/browse/JDK-8213213 > > Thanks > Christoph > > From GROEGES at uk.ibm.com Thu May 16 08:42:21 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Thu, 16 May 2019 09:42:21 +0100 Subject: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath In-Reply-To: <6829d771-49fc-8be2-3daa-b68b6e4c4c4e@redhat.com> References: <6829d771-49fc-8be2-3daa-b68b6e4c4c4e@redhat.com> Message-ID: Hi Andrew, > I see you added jdk8u-fix-request, and it has a jdk8u-fix-yes in > response, so now it has been reviewed, all that's needed now is to push > the change. > > Do you have push access or shall I do it on your behalf? Unfortunately, I do not have push access so would be very grateful if you could push this on my behalf. > In case you haven't seen yet: I have already pushed the backports for 11 and 12 yesterday. Christoph, thanks for pushing the backport for jdk11 and jdk12. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: Andrew John Hughes To: Steve Groeger Cc: "'jdk8u-dev at openjdk.java.net'" Date: 10/05/2019 19:26 Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath On 08/05/2019 13:26, Steve Groeger wrote: > Hi Andrew, > > Thanks for taking a look at this. > >> Regarding the 8u webrev, the two additions for hasNext() and next() in >> JavacProcessingEnvironment.java seem to have been flipped. Was this >> intentional? Comparing patched jdk8u with the jdk/jdk version: > > Yes, this was intentional. When I investigated this issue I did initially > add the changes to hasNext() in the jdk8u code but that didn't resolve the > issue. Having then looked at a generated stack trace it showed that the > code was going thru the next() method and failing there rather than in > hasNext(). Hence the reason the changes were put in the next() method for > jdk8u and in the hasNext() for jdk11 and above. Seems the > JavacProcessingEnvoronment.java class has changed since jdk8. > Ah ok. >> The test changes look ok and I assume they pass. > > Yes, the tests do pass when run on my local environment for all releases > jdk8u, jdk11u and jdk12u. > >> Long term, we may want to look at backporting >> https://bugs.openjdk.java.net/browse/JDK-8050429 >> to avoid this work for every test. > > I agree that we need to back-port this at some point. It gets quite time > consuming having to change tests that are created on jdk11u+ and need to > be back-ported to jdk8u. > > Is there anything else I need to do in order to get these back-ports > merged. If so, please let me know. > I see you added jdk8u-fix-request, and it has a jdk8u-fix-yes in response, so now it has been reviewed, all that's needed now is to push the change. Do you have push access or shall I do it on your behalf? > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew [attachment "signature.asc" deleted by Steve Groeger/UK/IBM] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From christoph.langer at sap.com Thu May 16 09:57:49 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 16 May 2019 09:57:49 +0000 Subject: JDK11/8 Updates: process, schedules and tagging Message-ID: Hi, after we had the discussion about the OpenJDK 8/11 release process and schedule [0], I?d like to explicitly spell out the current status and update the Wiki pages. It seems like we have agreed to a 3 phase model 1. Development 2. Rampdown (RDP2) 3. Freeze I?ve updated the timelines on the Wiki pages [1], [2] now accordingly. Please check/review. I would short-summarize our process like this: During development phase, changes go into the development repositories (jdk8u-dev/jdk11u-dev) and weekly tagging will be done in there. When the release repositories (jdk8u/jdk11u) aren?t blocked by rampdown/freeze of the previous release, the tags will be synced on a weekly basis to the release repositories. When rampdown of a release starts, merges from dev to release repositories are suspended and RDP2 approved changes have to be pushed to the release repositories. From that time merges happen from release->dev. After the freeze tag, no changes must go into the release repository while the CPU is assembled non publicly. After release, the CPU is merged back to the open repositories. Is that our common understanding? If I get no objections, I?ll update the process description pages [3] and [4] accordingly. I furthermore have 2 questions / things to clarify. a) Will we tag in the dev-repositories right from the start? E.g. will we start tagging 11.0.5 right after the 11.0.4 RDP2 integration from 11u-dev to 11u in the week after May 28? - I would suggest to do so. b) Will we also do a weekly tag when no changes happened after the previous tag? This should probably be a rare case given the current activities but we should have a guideline for that. - My feeling would be to skip the tag then. I can?t see any value in this. May I please have your feedback on that (especially from the Andrews ??) Thanks Christoph [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000996.html [1] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u [2] https://wiki.openjdk.java.net/display/jdk8u/Main [3] https://wiki.openjdk.java.net/display/JDKUpdates/Detailed+Process+Description [4] https://wiki.openjdk.java.net/display/jdk8u/Detailed+Process+Description From aph at redhat.com Thu May 16 13:25:39 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 16 May 2019 14:25:39 +0100 Subject: JDK11/8 Updates: process, schedules and tagging In-Reply-To: References: Message-ID: On 5/16/19 10:57 AM, Langer, Christoph wrote: > > after we had the discussion about the OpenJDK 8/11 release process > and schedule [0], I?d like to explicitly spell out the current > status and update the Wiki pages. > > It seems like we have agreed to a 3 phase model > > 1. Development > > 2. Rampdown (RDP2) > > 3. Freeze Yes. > I?ve updated the timelines on the Wiki pages [1], [2] now > accordingly. Please check/review. > > > > I would short-summarize our process like this: > > During development phase, changes go into the development > repositories (jdk8u-dev/jdk11u-dev) and weekly tagging will be done > in there. When the release repositories (jdk8u/jdk11u) aren?t > blocked by rampdown/freeze of the previous release, the tags will be > synced on a weekly basis to the release repositories. When rampdown > of a release starts, merges from dev to release repositories are > suspended and RDP2 approved changes have to be pushed to the release > repositories. From that time merges happen from release->dev. After > the freeze tag, no changes must go into the release repository while > the CPU is assembled non publicly. After release, the CPU is merged > back to the open repositories. That sounds right, modulo last-minute critical patches. > Is that our common understanding? If I get no objections, I?ll > update the process description pages [3] and [4] accordingly. > > I furthermore have 2 questions / things to clarify. > > a) Will we tag in the dev-repositories right from the start? > E.g. will we start tagging 11.0.5 right after the 11.0.4 RDP2 > integration from 11u-dev to 11u in the week after May 28? > > - I would suggest to do so. We might as well: it simplifies the process. > b) Will we also do a weekly tag when no changes happened after the > previous tag? This should probably be a rare case given the current > activities but we should have a guideline for that. > > - My feeling would be to skip the tag then. I can?t see any > value in this. It doesn't matter. If the tag is done and there are no chages, there is no harm because that tag won't be used for any merges. If the tag is not done, there is no harm because that tag won't be used for any merges. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From goetz.lindenmaier at sap.com Thu May 16 13:48:42 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 16 May 2019 13:48:42 +0000 Subject: JDK11/8 Updates: process, schedules and tagging In-Reply-To: References: Message-ID: Hi, I appreciate what was proposed here. > > b) Will we also do a weekly tag when no changes happened after the > > previous tag? This should probably be a rare case given the current > > activities but we should have a guideline for that. > > > > - My feeling would be to skip the tag then. I can?t see any > > value in this. > > It doesn't matter. If the tag is done and there are no chages, there > is no harm because that tag won't be used for any merges. If the tag > is not done, there is no harm because that tag won't be used for any > merges. I see two problems with skipping tags: - You cannot predict when a tag will applied. You can not talk about the future mentioning tags if you skip them. - If you look at a repo, you can not easily tell at which sequence tags were applied. You need to look at the dates of changes. With regular weekly tags, going back 4 tags means going back 4 weeks. I.e., I think it's not essential, but makes life more easy if it's predictable. Also, Oracle does not skip them. See 11.0.2+2 and 11.0.2+3. http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/fa6e8935bbf2 http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/8a8606a3bdf2 I think we should be similar here. Best regards, Goetz. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From xxinliu at amazon.com Thu May 16 17:23:19 2019 From: xxinliu at amazon.com (Liu, Xin) Date: Thu, 16 May 2019 17:23:19 +0000 Subject: [8u] RFR: Backport of JDK-8222670: pathological case of JIT recompilation and code cache bloat In-Reply-To: <29367C39-36D1-4D17-BEB0-7B7C9D590435@amazon.com> References: <29367C39-36D1-4D17-BEB0-7B7C9D590435@amazon.com> Message-ID: <7DE1A3A6-4BCA-4C35-B992-08281C7A6C8B@amazon.com> Hi, Reviewers, Could you review this backport patch? BUG: https://bugs.openjdk.java.net/browse/JDK-8222670 Webrev: https://cr.openjdk.java.net/~xliu/8222670/webrev.8u-dev/ I can?t cleanly apply the original patch to jdk8u. I made the following changes. 1. Include JDK-8223537. It solved suspend problem in blocking mode. One line change. 2. Shorter wait period. Otherwise, it?s easy to timeout for the test. It?s part of a JDK-8066770. https://cr.openjdk.java.net/~xliu/8222670/webrev.8u-dev/test/compiler/whitebox/CompilerWhiteBoxTest.java.udiff.html 1. +1 for Tier4MinInvocationThreshold and Tier4CompileThreshold. Otherwise, we have to backport JDK-8059604, which looks like complicated. https://cr.openjdk.java.net/~xliu/8222670/webrev.8u-dev/src/share/vm/prims/whitebox.cpp.udiff.html Thanks, --lx From sgehwolf at redhat.com Thu May 16 17:51:25 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 16 May 2019 19:51:25 +0200 Subject: [8u] RFR: 8203190: SessionId.hashCode generates too many collisions Message-ID: <386bd6930219b727bba30bf0daf76202bb5c7157.camel@redhat.com> Hi, Could I please get a review of this OpenJDK 8u only fix? JDKs 11+ don't seems to have this issue as with the TLS 1.3 feature (JDK-8196584) SessionId.hashCode() got changed to use Arrays.hashCode() already. webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203190/01/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8203190 The rationale for the fix are these assumptions: a) elements in trees on hash collision of LinkedHashMap used internally by the MemoryCache class become prohibitively large for many SessionId entries in the cache, b) moderate speed of the new hashCode() impl will not have a detrimental effect on performance overall. Comparison of performance of hashCode impls[1]: Benchmark Mode Cnt Score Error Units SessionIDBench.newHashCode thrpt 100 43649538.284 ? 678702.696 ops/s SessionIDBench.oldHashCode thrpt 100 94068843.923 ? 1379930.266 ops/s Collision testing[2] showed that indeed, the current hashCode() implementation of SessionId produces more collissions and, thus, produce more elements in trees for collision resolution in the underlying LinkedHashMap. The default cache expiry is 24 hours per entry and this can result in millions of entries in the cache in some circumstances[3]. Before: ################################################## Collision test for 100 sessions: ------------------------------------------------ Total number of collisions: 4 Max length of collision list over all buckets: 2 Collision test for 20480 sessions: ------------------------------------------------ Total number of collisions: 18311 Max length of collision list over all buckets: 30 Collision test for 10000000 sessions: ------------------------------------------------ Total number of collisions: 9996395 Max length of collision list over all buckets: 9709 ################################################## After: ################################################## Collision test for 100 sessions: ------------------------------------------------ Total number of collisions: 0 Collision test for 20480 sessions: ------------------------------------------------ Total number of collisions: 0 Collision test for 10000000 sessions: ------------------------------------------------ Total number of collisions: 11530 Max length of collision list over all buckets: 2 ################################################## Testing: Above testing, and make test. No new failures. Thoughts? Thanks, Severin [1] http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203190/SessionIDBench.java [2] http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203190/SessionIdCollissionTest.java [3] https://bugs.openjdk.java.net/browse/JDK-8210985 From gnu.andrew at redhat.com Thu May 16 18:10:23 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 16 May 2019 19:10:23 +0100 Subject: [8u] RFR: 8203190: SessionId.hashCode generates too many collisions In-Reply-To: <386bd6930219b727bba30bf0daf76202bb5c7157.camel@redhat.com> References: <386bd6930219b727bba30bf0daf76202bb5c7157.camel@redhat.com> Message-ID: <8f8432c6-9e17-78b4-a87a-6592183169cf@redhat.com> On 16/05/2019 18:51, Severin Gehwolf wrote: > Hi, > > Could I please get a review of this OpenJDK 8u only fix? JDKs 11+ don't > seems to have this issue as with the TLS 1.3 feature (JDK-8196584) > SessionId.hashCode() got changed to use Arrays.hashCode() already. > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203190/01/webrev/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8203190 > > The rationale for the fix are these assumptions: > > a) elements in trees on hash collision of LinkedHashMap used internally > by the MemoryCache class become prohibitively large for many SessionId > entries in the cache, b) moderate speed of the new hashCode() impl will > not have a detrimental effect on performance overall. > > Comparison of performance of hashCode impls[1]: > > Benchmark Mode Cnt Score Error Units > SessionIDBench.newHashCode thrpt 100 43649538.284 ? 678702.696 ops/s > SessionIDBench.oldHashCode thrpt 100 94068843.923 ? 1379930.266 ops/s > > Collision testing[2] showed that indeed, the current hashCode() > implementation of SessionId produces more collissions and, thus, > produce more elements in trees for collision resolution in the > underlying LinkedHashMap. The default cache expiry is 24 hours per > entry and this can result in millions of entries in the cache in some > circumstances[3]. > > Before: > ################################################## > Collision test for 100 sessions: > ------------------------------------------------ > Total number of collisions: 4 > Max length of collision list over all buckets: 2 > > Collision test for 20480 sessions: > ------------------------------------------------ > Total number of collisions: 18311 > Max length of collision list over all buckets: 30 > > Collision test for 10000000 sessions: > ------------------------------------------------ > Total number of collisions: 9996395 > Max length of collision list over all buckets: 9709 > ################################################## > > After: > ################################################## > Collision test for 100 sessions: > ------------------------------------------------ > Total number of collisions: 0 > > Collision test for 20480 sessions: > ------------------------------------------------ > Total number of collisions: 0 > > Collision test for 10000000 sessions: > ------------------------------------------------ > Total number of collisions: 11530 > Max length of collision list over all buckets: 2 > ################################################## > > > Testing: Above testing, and make test. No new failures. > > Thoughts? > > Thanks, > Severin > > [1] http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203190/SessionIDBench.java > [2] http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203190/SessionIdCollissionTest.java > [3] https://bugs.openjdk.java.net/browse/JDK-8210985 > Change looks good. Is there a reason the tests aren't included in the webrev? I think it would be better to have them checked in, even if they can't be run automatically. They will need copyright headers and I'd correct the spelling of 'collision' too :-) -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Thu May 16 18:45:48 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 16 May 2019 19:45:48 +0100 Subject: [8u] RFR: Backport of JDK-8222670: pathological case of JIT recompilation and code cache bloat In-Reply-To: <7DE1A3A6-4BCA-4C35-B992-08281C7A6C8B@amazon.com> References: <29367C39-36D1-4D17-BEB0-7B7C9D590435@amazon.com> <7DE1A3A6-4BCA-4C35-B992-08281C7A6C8B@amazon.com> Message-ID: <50f562af-6061-73f9-e974-bb3820022c9b@redhat.com> On 16/05/2019 18:23, Liu, Xin wrote: > Hi, Reviewers, > > Could you review this backport patch? > > BUG: https://bugs.openjdk.java.net/browse/JDK-8222670 > Webrev: https://cr.openjdk.java.net/~xliu/8222670/webrev.8u-dev/ > > I can?t cleanly apply the original patch to jdk8u. I made the following changes. > > 1. Include JDK-8223537. It solved suspend problem in blocking mode. One line change. I think this should be applied as a pre-requisite clean backport. Just flag the bug with jdk8u-fix-request, no need for a separate review. > 2. Shorter wait period. Otherwise, it?s easy to timeout for the test. It?s part of a JDK-8066770. > https://cr.openjdk.java.net/~xliu/8222670/webrev.8u-dev/test/compiler/whitebox/CompilerWhiteBoxTest.java.udiff.html > 8066770 relies on a lot of WhiteBox API that is not present in 8u so I'm ok with including just this segment. > 1. +1 for Tier4MinInvocationThreshold and Tier4CompileThreshold. Otherwise, we have to backport JDK-8059604, which looks like complicated. > > https://cr.openjdk.java.net/~xliu/8222670/webrev.8u-dev/src/share/vm/prims/whitebox.cpp.udiff.html JDK-8059604 looks backportable, but I'm ok with including this commented workaround for now. There seem to be two other changes being included here: 1. compileBroker.cpp changes These aren't in the original JDK-8222670. In 9, the != NULL test is added by "8144964: JVMCI compilations need to be disabled until the module system is initialized". 8 has neither JVMCI or a module system, so not sure why this test is being added here. Why is this included? 2. skiponTieredCompilation in CompilerWhiteBoxTest.java This is part of "8059575: JEP-JDK-8043304: Test task: Tiered Compilation level transition tests" which should also be backported as a pre-requisite. > Thanks, > --lx > Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Thu May 16 19:43:50 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 16 May 2019 20:43:50 +0100 Subject: JDK11/8 Updates: process, schedules and tagging In-Reply-To: References: Message-ID: <6ce70f91-d409-0a78-8100-0a8b81de5d5f@redhat.com> On 16/05/2019 10:57, Langer, Christoph wrote: > Hi, > > ? > > after we had the discussion about the OpenJDK 8/11 release process and > schedule [0], I?d like to explicitly spell out the current status and > update the Wiki pages. > > ? > > It seems like we have agreed to a 3 phase model > > ? > > 1. Development > > 2. Rampdown (RDP2) > > 3. Freeze > > ? > > I?ve updated the timelines on the Wiki pages [1], [2] now accordingly. > Please check/review. > Thanks. I'll review the 8u page and check it matches the process I'm following. I do think "RDP2" should be avoided as there is no "RDP1". > ? > > I would short-summarize our process like this: > > During development phase, changes go into the development repositories > (jdk8u-dev/jdk11u-dev) and weekly tagging will be done in there. When > the release repositories (jdk8u/jdk11u) aren?t blocked by > rampdown/freeze of the previous release, the tags will be synced on a > weekly basis to the release repositories. When rampdown of a release > starts, merges from dev to release repositories are suspended and RDP2 > approved changes have to be pushed to the release repositories. From > that time merges happen from release->dev. After the freeze tag, no > changes must go into the release repository while the CPU is assembled > non publicly. After release, the CPU is merged back to the open > repositories. Yes: Dev phase: dev tagged, dev->master Rampdown phase: master tagged, master->dev Freeze phase: no changes to master Release: CPU changes pushed to master, master->dev > > ? > > Is that our common understanding? If I get no objections, I?ll update > the process description pages [3] and [4] accordingly. > > ? > > I furthermore have 2 questions / things to clarify. > > ? > > a) Will we tag in the dev-repositories right from the start? E.g. will > we start tagging 11.0.5 right after the 11.0.4 RDP2 integration from > 11u-dev to 11u in the week after May 28? > > ??? - I would suggest to do so. We do tag that point as -b00, I believe. If you mean do we start weekly tags of release x+1 in dev once release x is in rampdown, then no, I don't plan to for 8u. If you have the cycles to do so for 11, you can, but I need that time - particularly the freeze period - to prepare, build and test the imminent releases. Also, I don't really see the point when there is nowhere to promote the build to, as master is still on release x. That does mean that b01 will run over a longer period than other tags, but I don't see that as a particular problem. > > b) Will we also do a weekly tag when no changes happened after the > previous tag? This should probably be a rare case given the current > activities but we should have a guideline for that. > > ??? - My feeling would be to skip the tag then. I can?t see any value in > this. > I agree with skipping such empty tags, with an appropriate list announcement. I think the predictability argument is already lost in the final stages where we may have to add multiple tags in secret during the addition of the security patches. On the other hand, tagging periods with no changes introduces the possibility of a lot of needless work testing unchanged sources. I think it's easier to convey the message that a tag is being skipped - which someone who notices the lack of a new tag may look for - than it is to tag and have unknown users downstream building and testing something with no changes. The problem with comparing with Oracle processes is that their process is largely internal and so there are not the same potential communication issues. I think this is unlikely during the development stage, but more likely during the rampdown if nothing is critical enough to be included in the imminent release. My answer to both questions is concerned more with the reality of the workload involved than pointlessly sticking to an agreed protocol, when our limited resources could be better utilised. > ? > > May I please have your feedback on that (especially from the Andrews ??) > > ? > > Thanks > > Christoph > > ? > > [0] > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000996.html > > [1] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u > > [2] https://wiki.openjdk.java.net/display/jdk8u/Main > > [3] > https://wiki.openjdk.java.net/display/JDKUpdates/Detailed+Process+Description > > > [4] https://wiki.openjdk.java.net/display/jdk8u/Detailed+Process+Description > > ? > Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From alvdavi at amazon.com Thu May 16 20:26:43 2019 From: alvdavi at amazon.com (Alvarez, David) Date: Thu, 16 May 2019 20:26:43 +0000 Subject: JDK-8048782, which is designated for u222, fixes a bug, but it also introduces a new one. Message-ID: <5D3CFC22-12D6-452E-A99E-C51B2D3C3FA3@amazon.com> Hi, It has come to our attention that JDK-8048782 [1] can cause Pisces to perform wrong renderings. This patch was originally developed for OpenJDK9, but has now been backported to openjdk8u222, so it has become relevant again. After diving into the issue, it is my understanding that fix was created to solve potential RasterFormatException. That exception occurred by the fact that internally, PiscesCache always works with a bound box one pixel larger than specified, as it can see on its constructor [2]. That slightly larger bbox was exposed outside by the PiscesTileGenerator::getBbox method, and could lead to the RasterFormatException in some scenarios. JDK-8048782 addressed this by ensuring the bbox exposed outside did not contain the additional pixel. Calls to retrieve the bbox will now go to a PiscesCache::getBBox [3] method that removed the extra pixel. However, one thing that was not changed is the PiscesTileGenerator::nextTile method [4]. This method is still accessing the internal value. The new problem happens because now the AAShapePipe::renderTiles works with a different bbox that the PiscesTileGenerator::nextTile. This means that for certain sizes of the bbox (those multiple of 32, the tile size), AAShapePipe may start working with the next row while PiscesTileGenerator still considers we are on the current row. This issue generates patterns like the ones on the attached tile_misalignment.png image. This could be fixed by aligning the PiscesTileGenerator::nextTile method to use the same value for bboxX1 as the one that was exposed outside (removing the extra pixel). Something functionally equivalent to: public void nextTile() { if ((x += TILE_SIZE) >= cache.bboxX1 -1) { x = cache.bboxX0; y += TILE_SIZE; } } However, the part that I haven?t been able to understand is why PiscesCache works with that extra pixel. As far as I can tell, it has always been there, but I've never seen it documented. I assume there was a legitimate reason for that extra pixel to be there, but I don't know why or if it is still relevant. I would love if someone with more knowledge in this area were able to explain it. There seems to be three options here: - Revert JDK-804782, leaving the original RasterFormatException bug. - Address the misalignment by changing the PiscesTileGenerator::nextTile. - If no longer needed, remove the additional pixel in PiscesCache bbox (and reverting JDK-804782, that would no longer be needed) Thanks, David --- [1] https://bugs.openjdk.java.net/browse/JDK-8048782 [2] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/cecd70d27b27/src/share/classes/sun/java2d/pisces/PiscesCache.java#l62 [3] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/d9da27985291/src/share/classes/sun/java2d/pisces/PiscesCache.java#l170 [4] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/d9da27985291/src/share/classes/sun/java2d/pisces/PiscesTileGenerator.java#l135 [5] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/d9da27985291/src/share/classes/sun/java2d/pipe/AAShapePipe.java#l162 From goetz.lindenmaier at sap.com Fri May 17 08:04:42 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 17 May 2019 08:04:42 +0000 Subject: JDK11/8 Updates: process, schedules and tagging In-Reply-To: <6ce70f91-d409-0a78-8100-0a8b81de5d5f@redhat.com> References: <6ce70f91-d409-0a78-8100-0a8b81de5d5f@redhat.com> Message-ID: Hi, > I do think "RDP2" should be avoided as there is no "RDP1". I understand you don't want the OpenJDK RDP terms. So let's use the term Rampdown. Could you please propose some wording to describe which changes are acceptable during rampdown? I will do the weekly tags on 11. Best regards, Goetz. > > I would short-summarize our process like this: > > > > During development phase, changes go into the development repositories > > (jdk8u-dev/jdk11u-dev) and weekly tagging will be done in there. When > > the release repositories (jdk8u/jdk11u) aren?t blocked by > > rampdown/freeze of the previous release, the tags will be synced on a > > weekly basis to the release repositories. When rampdown of a release > > starts, merges from dev to release repositories are suspended and RDP2 > > approved changes have to be pushed to the release repositories. From > > that time merges happen from release->dev. After the freeze tag, no > > changes must go into the release repository while the CPU is assembled > > non publicly. After release, the CPU is merged back to the open > > repositories. > > Yes: > > Dev phase: dev tagged, dev->master > Rampdown phase: master tagged, master->dev > Freeze phase: no changes to master > Release: CPU changes pushed to master, master->dev > > > > > > > > > Is that our common understanding? If I get no objections, I?ll update > > the process description pages [3] and [4] accordingly. > > > > > > > > I furthermore have 2 questions / things to clarify. > > > > > > > > a) Will we tag in the dev-repositories right from the start? E.g. will > > we start tagging 11.0.5 right after the 11.0.4 RDP2 integration from > > 11u-dev to 11u in the week after May 28? > > > > ??? - I would suggest to do so. > > We do tag that point as -b00, I believe. > > If you mean do we start weekly tags of release x+1 in dev once release x > is in rampdown, then no, I don't plan to for 8u. If you have the cycles > to do so for 11, you can, but I need that time - particularly the freeze > period - to prepare, build and test the imminent releases. > > Also, I don't really see the point when there is nowhere to promote the > build to, as master is still on release x. > > That does mean that b01 will run over a longer period than other tags, > but I don't see that as a particular problem. > > > > > b) Will we also do a weekly tag when no changes happened after the > > previous tag? This should probably be a rare case given the current > > activities but we should have a guideline for that. > > > > ??? - My feeling would be to skip the tag then. I can?t see any value in > > this. > > > > I agree with skipping such empty tags, with an appropriate list > announcement. > > I think the predictability argument is already lost in the final stages > where we may have to add multiple tags in secret during the addition of > the security patches. On the other hand, tagging periods with no changes > introduces the possibility of a lot of needless work testing unchanged > sources. > > I think it's easier to convey the message that a tag is being skipped - > which someone who notices the lack of a new tag may look for - than it > is to tag and have unknown users downstream building and testing > something with no changes. > > The problem with comparing with Oracle processes is that their process > is largely internal and so there are not the same potential > communication issues. > > I think this is unlikely during the development stage, but more likely > during the rampdown if nothing is critical enough to be included in the > imminent release. > > My answer to both questions is concerned more with the reality of the > workload involved than pointlessly sticking to an agreed protocol, when > our limited resources could be better utilised. > > > > > > > May I please have your feedback on that (especially from the Andrews ??) > > > > > > > > Thanks > > > > Christoph > > > > > > > > [0] > > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019- > April/000996.html > > > > [1] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u > > > > [2] https://wiki.openjdk.java.net/display/jdk8u/Main > > > > [3] > > > https://wiki.openjdk.java.net/display/JDKUpdates/Detailed+Process+Descripti > on > > > > > > [4] > https://wiki.openjdk.java.net/display/jdk8u/Detailed+Process+Description > > > > > > > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew From aph at redhat.com Fri May 17 08:15:54 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 17 May 2019 09:15:54 +0100 Subject: JDK11/8 Updates: process, schedules and tagging In-Reply-To: References: <6ce70f91-d409-0a78-8100-0a8b81de5d5f@redhat.com> Message-ID: On 5/17/19 9:04 AM, Lindenmaier, Goetz wrote: > Could you please propose some wording to describe which > changes are acceptable during rampdown? Hmm. OK, so we need some rough guidelines, but it'll be a judgment call. There was more traffic than I liked last time around, but on the other hand things seemed to work out pretty well. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Fri May 17 10:07:57 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 17 May 2019 12:07:57 +0200 Subject: [8u] RFR: 8203190: SessionId.hashCode generates too many collisions In-Reply-To: <386bd6930219b727bba30bf0daf76202bb5c7157.camel@redhat.com> References: <386bd6930219b727bba30bf0daf76202bb5c7157.camel@redhat.com> Message-ID: On 5/16/19 7:51 PM, Severin Gehwolf wrote: > Could I please get a review of this OpenJDK 8u only fix? JDKs 11+ don't > seems to have this issue as with the TLS 1.3 feature (JDK-8196584) > SessionId.hashCode() got changed to use Arrays.hashCode() already. > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203190/01/webrev/ This looks good to me. -Aleksey From sgehwolf at redhat.com Fri May 17 11:37:21 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 17 May 2019 13:37:21 +0200 Subject: [8u] RFR: 8203190: SessionId.hashCode generates too many collisions In-Reply-To: <8f8432c6-9e17-78b4-a87a-6592183169cf@redhat.com> References: <386bd6930219b727bba30bf0daf76202bb5c7157.camel@redhat.com> <8f8432c6-9e17-78b4-a87a-6592183169cf@redhat.com> Message-ID: <7748a702f75c0456764b62d14201e5e5e3e47c19.camel@redhat.com> On Thu, 2019-05-16 at 19:10 +0100, Andrew John Hughes wrote: > > Change looks good. Thanks for the review. > Is there a reason the tests aren't included in the webrev? I think it > would be better to have them checked in, even if they can't be run > automatically. The reason was that it's not a good test to be run automatically. It would have to have some heuristic which it uses as "passed" and "fail". Checking in the code anyway has a tendency for it to bitrot. If you really feel strongly about it, I can add it. FWIW, the reference to the test isn't going away so it'll be available either way. > They will need copyright headers and I'd correct the spelling of > 'collision' too :-) :) Af for the typo: Well spotted. Thanks, Severin From sgehwolf at redhat.com Fri May 17 11:37:59 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 17 May 2019 13:37:59 +0200 Subject: [8u] RFR: 8203190: SessionId.hashCode generates too many collisions In-Reply-To: References: <386bd6930219b727bba30bf0daf76202bb5c7157.camel@redhat.com> Message-ID: <819a6c3f9fc84d347aa7102ef440efecc5b266ec.camel@redhat.com> On Fri, 2019-05-17 at 12:07 +0200, Aleksey Shipilev wrote: > On 5/16/19 7:51 PM, Severin Gehwolf wrote: > > Could I please get a review of this OpenJDK 8u only fix? JDKs 11+ don't > > seems to have this issue as with the TLS 1.3 feature (JDK-8196584) > > SessionId.hashCode() got changed to use Arrays.hashCode() already. > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203190/01/webrev/ > > This looks good to me. Thanks for the review, Aleksey! Cheers, Severin From gnu.andrew at redhat.com Fri May 17 15:28:12 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 17 May 2019 16:28:12 +0100 Subject: [8u] RFR: 8203190: SessionId.hashCode generates too many collisions In-Reply-To: <7748a702f75c0456764b62d14201e5e5e3e47c19.camel@redhat.com> References: <386bd6930219b727bba30bf0daf76202bb5c7157.camel@redhat.com> <8f8432c6-9e17-78b4-a87a-6592183169cf@redhat.com> <7748a702f75c0456764b62d14201e5e5e3e47c19.camel@redhat.com> Message-ID: On 17/05/2019 12:37, Severin Gehwolf wrote: snip... > > The reason was that it's not a good test to be run automatically. It > would have to have some heuristic which it uses as "passed" and "fail". > Checking in the code anyway has a tendency for it to bitrot. If you > really feel strongly about it, I can add it. FWIW, the reference to the > test isn't going away so it'll be available either way. > I get that, but there are other manual tests in the repositories. I saw one yesterday that required downloading a font before running it. I think it better to have everything in one place rather than relying on someone to find this e-mail thread. The bitrot argument seems a little odd, given it would be more open to updates in the repositories rather than on a web server where only you can update it :/ -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From sgehwolf at redhat.com Fri May 17 16:00:59 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 17 May 2019 18:00:59 +0200 Subject: [8u] RFR: 8203190: SessionId.hashCode generates too many collisions In-Reply-To: References: <386bd6930219b727bba30bf0daf76202bb5c7157.camel@redhat.com> <8f8432c6-9e17-78b4-a87a-6592183169cf@redhat.com> <7748a702f75c0456764b62d14201e5e5e3e47c19.camel@redhat.com> Message-ID: <5e042b97694c2652b628badfc728bb497895880e.camel@redhat.com> On Fri, 2019-05-17 at 16:28 +0100, Andrew John Hughes wrote: > > On 17/05/2019 12:37, Severin Gehwolf wrote: > > snip... > > > The reason was that it's not a good test to be run automatically. It > > would have to have some heuristic which it uses as "passed" and "fail". > > Checking in the code anyway has a tendency for it to bitrot. If you > > really feel strongly about it, I can add it. FWIW, the reference to the > > test isn't going away so it'll be available either way. > > > > I get that, but there are other manual tests in the repositories. I saw > one yesterday that required downloading a font before running it. I > think it better to have everything in one place rather than relying on > someone to find this e-mail thread. > > The bitrot argument seems a little odd, given it would be more open to > updates in the repositories rather than on a web server where only you > can update it :/ Sure. Here the webrev with the test: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203190/02/webrev/ OK to push? Thanks, Severin From gnu.andrew at redhat.com Fri May 17 16:13:42 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 17 May 2019 17:13:42 +0100 Subject: [8u] RFR: 8203190: SessionId.hashCode generates too many collisions In-Reply-To: <5e042b97694c2652b628badfc728bb497895880e.camel@redhat.com> References: <386bd6930219b727bba30bf0daf76202bb5c7157.camel@redhat.com> <8f8432c6-9e17-78b4-a87a-6592183169cf@redhat.com> <7748a702f75c0456764b62d14201e5e5e3e47c19.camel@redhat.com> <5e042b97694c2652b628badfc728bb497895880e.camel@redhat.com> Message-ID: On 17/05/2019 17:00, Severin Gehwolf wrote: > On Fri, 2019-05-17 at 16:28 +0100, Andrew John Hughes wrote: >> >> On 17/05/2019 12:37, Severin Gehwolf wrote: >> >> snip... >> >>> The reason was that it's not a good test to be run automatically. It >>> would have to have some heuristic which it uses as "passed" and "fail". >>> Checking in the code anyway has a tendency for it to bitrot. If you >>> really feel strongly about it, I can add it. FWIW, the reference to the >>> test isn't going away so it'll be available either way. >>> >> >> I get that, but there are other manual tests in the repositories. I saw >> one yesterday that required downloading a font before running it. I >> think it better to have everything in one place rather than relying on >> someone to find this e-mail thread. >> >> The bitrot argument seems a little odd, given it would be more open to >> updates in the repositories rather than on a web server where only you >> can update it :/ > > Sure. Here the webrev with the test: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203190/02/webrev/ > > OK to push? > > Thanks, > Severin > Looks good to me. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From daniel.fuchs at oracle.com Fri May 17 16:15:39 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 17 May 2019 17:15:39 +0100 Subject: [8u] RFR: 8203190: SessionId.hashCode generates too many collisions In-Reply-To: <5e042b97694c2652b628badfc728bb497895880e.camel@redhat.com> References: <386bd6930219b727bba30bf0daf76202bb5c7157.camel@redhat.com> <8f8432c6-9e17-78b4-a87a-6592183169cf@redhat.com> <7748a702f75c0456764b62d14201e5e5e3e47c19.camel@redhat.com> <5e042b97694c2652b628badfc728bb497895880e.camel@redhat.com> Message-ID: <3a53f7fb-7bcc-74de-5478-d7f958d0b183@oracle.com> Hi Severin, Here is an example of a manual test checked in in the jdk repo: http://hg.openjdk.java.net/jdk/jdk/file/tip/test/jdk/sun/security/provider/PolicyParser/ExtDirs.java - it has an @test annotation - it has an @bug annotation - it has an @run main/manual line - it has a comment explaining how to run the test (if necessary) and should have also explain in which case it should be declared successful or failed... best regards, -- daniel On 17/05/2019 17:00, Severin Gehwolf wrote: > On Fri, 2019-05-17 at 16:28 +0100, Andrew John Hughes wrote: >> >> On 17/05/2019 12:37, Severin Gehwolf wrote: >> >> snip... >> >>> The reason was that it's not a good test to be run automatically. It >>> would have to have some heuristic which it uses as "passed" and "fail". >>> Checking in the code anyway has a tendency for it to bitrot. If you >>> really feel strongly about it, I can add it. FWIW, the reference to the >>> test isn't going away so it'll be available either way. >>> >> >> I get that, but there are other manual tests in the repositories. I saw >> one yesterday that required downloading a font before running it. I >> think it better to have everything in one place rather than relying on >> someone to find this e-mail thread. >> >> The bitrot argument seems a little odd, given it would be more open to >> updates in the repositories rather than on a web server where only you >> can update it :/ > > Sure. Here the webrev with the test: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203190/02/webrev/ > > OK to push? > > Thanks, > Severin > From sgehwolf at redhat.com Fri May 17 16:58:51 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 17 May 2019 18:58:51 +0200 Subject: [8u] RFR: 8203190: SessionId.hashCode generates too many collisions In-Reply-To: <3a53f7fb-7bcc-74de-5478-d7f958d0b183@oracle.com> References: <386bd6930219b727bba30bf0daf76202bb5c7157.camel@redhat.com> <8f8432c6-9e17-78b4-a87a-6592183169cf@redhat.com> <7748a702f75c0456764b62d14201e5e5e3e47c19.camel@redhat.com> <5e042b97694c2652b628badfc728bb497895880e.camel@redhat.com> <3a53f7fb-7bcc-74de-5478-d7f958d0b183@oracle.com> Message-ID: <676689a0368a7469f72f5ba6ab09d2636e5e0583.camel@redhat.com> Hi Daniel, On Fri, 2019-05-17 at 17:15 +0100, Daniel Fuchs wrote: > Hi Severin, > > Here is an example of a manual test checked in in the jdk repo: > > http://hg.openjdk.java.net/jdk/jdk/file/tip/test/jdk/sun/security/provider/PolicyParser/ExtDirs.java > > - it has an @test annotation > - it has an @bug annotation > - it has an @run main/manual line > - it has a comment explaining how to run the test > (if necessary) and should have also explain > in which case it should be declared successful > or failed... Thanks! How about this? http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203190/03/webrev/ Cheers, Severin > best regards, > > -- daniel > > On 17/05/2019 17:00, Severin Gehwolf wrote: > > On Fri, 2019-05-17 at 16:28 +0100, Andrew John Hughes wrote: > > > On 17/05/2019 12:37, Severin Gehwolf wrote: > > > > > > snip... > > > > > > > The reason was that it's not a good test to be run > > > > automatically. It > > > > would have to have some heuristic which it uses as "passed" and > > > > "fail". > > > > Checking in the code anyway has a tendency for it to bitrot. If > > > > you > > > > really feel strongly about it, I can add it. FWIW, the > > > > reference to the > > > > test isn't going away so it'll be available either way. > > > > > > > > > > I get that, but there are other manual tests in the repositories. > > > I saw > > > one yesterday that required downloading a font before running it. > > > I > > > think it better to have everything in one place rather than > > > relying on > > > someone to find this e-mail thread. > > > > > > The bitrot argument seems a little odd, given it would be more > > > open to > > > updates in the repositories rather than on a web server where > > > only you > > > can update it :/ > > > > Sure. Here the webrev with the test: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203190/02/webrev/ > > > > OK to push? > > > > Thanks, > > Severin > > From gnu.andrew at redhat.com Fri May 17 17:56:38 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 17 May 2019 18:56:38 +0100 Subject: jdk8u222-b03 tagged Message-ID: <56f26eec-797c-7122-0a6c-586d01d79381@redhat.com> I've tagged jdk8u222-b03 locally and will push once tested. I pushed a number of pending changes which were clean backports and had approval before tagging: * 7102541: RFE: os::set_native_thread_name() cleanups * 8151322: Implement os::set_native_thread_name() on Solaris * 8214770: java/time/test/java/time/format/TestNonIsoFormatter.java failed in non-english locales. * 8154387: Parallel unordered Stream.limit() tries to collect 128 elements even if limit is less * 7100957: SOCKS proxying does not work with IPv6 connections Any changes pushed from this point forward will form part of b04. Changes in jdk8u222-b03: - S7100957: SOCKS proxying does not work with IPv6 connections - S7102541: RFE: os::set_native_thread_name() cleanups - S8144332: HSDB could not terminate when close button is pushed. - S8151322: Implement os::set_native_thread_name() on Solaris - S8154387: Parallel unordered Stream.limit() tries to collect 128 elements even if limit is less - S8189131: Open-source the Oracle JDK Root Certificates - S8189949: Remove Baltimore Cybertrust Code Signing CA - S8191031: Remove several Symantec Root CAs - S8191844: Remove SECOM root (secomevrootca1) - S8195774: Add Entrust root certificates - S8195793: Remove GTE CyberTrust Global Root - S8196141: Add GoDaddy root certificates - S8199779: Add T-Systems, GlobalSign and Starfield services root certificates - S8204923: Restore Symantec root verisignclass2g2ca - S8209506: Add Google Trust Services GlobalSign root certificates - S8210425: [x86] sharedRuntimeTrig/sharedRuntimeTrans compiled without optimization - S8210432: Add additional TeliaSonera root certificate - S8213213: Remove src/java.desktop/unix/classes/sun/awt/X11/keysym2ucs.h - S8214770: java/time/test/java/time/format/TestNonIsoFormatter.java failed in non-english locales. - S8216577: Add GlobalSign's R6 Root certificate - S8218152: [javac] fails and exits with no error if a bad annotation processor provided - S8222136: Remove two Comodo root CA certificates that are expiring - S8222137: Remove T-Systems root CA certificate - S8223555: Cleanups in cacerts tests - S8223664: Add jtreg tests for 8223528, backport to jdk8u of 8176100 -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Fri May 17 17:57:30 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 17 May 2019 18:57:30 +0100 Subject: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath In-Reply-To: References: <6829d771-49fc-8be2-3daa-b68b6e4c4c4e@redhat.com> Message-ID: <163178d1-4c41-7ba2-756c-399cd751cee3@redhat.com> On 16/05/2019 09:42, Steve Groeger wrote: > Hi Andrew, > >> I see you added jdk8u-fix-request, and it has a jdk8u-fix-yes in >> response, so now it has been reviewed, all that's needed now is to push >> the change. >> >> Do you have push access or shall I do it on your behalf? > > Unfortunately, I do not have push access so would be very grateful if > you could push this on my behalf. > Done: https://hg.openjdk.java.net/jdk8u/jdk8u-dev/langtools/rev/12045c5cae33 -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From daniel.fuchs at oracle.com Fri May 17 19:12:49 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 17 May 2019 20:12:49 +0100 Subject: [8u] RFR: 8203190: SessionId.hashCode generates too many collisions In-Reply-To: <676689a0368a7469f72f5ba6ab09d2636e5e0583.camel@redhat.com> References: <386bd6930219b727bba30bf0daf76202bb5c7157.camel@redhat.com> <8f8432c6-9e17-78b4-a87a-6592183169cf@redhat.com> <7748a702f75c0456764b62d14201e5e5e3e47c19.camel@redhat.com> <5e042b97694c2652b628badfc728bb497895880e.camel@redhat.com> <3a53f7fb-7bcc-74de-5478-d7f958d0b183@oracle.com> <676689a0368a7469f72f5ba6ab09d2636e5e0583.camel@redhat.com> Message-ID: <1c808da6-034a-e366-1010-0bba07a47c0b@oracle.com> On 17/05/19 17:58, Severin Gehwolf wrote: > Thanks! How about this? > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203190/03/webrev/ Yes, the test looks good to me! Thanks Severin, best regards, -- daniel From xxinliu at amazon.com Sat May 18 17:20:37 2019 From: xxinliu at amazon.com (Liu, Xin) Date: Sat, 18 May 2019 17:20:37 +0000 Subject: [8u] RFR: Backport of JDK-8222670: pathological case of JIT recompilation and code cache bloat In-Reply-To: <50f562af-6061-73f9-e974-bb3820022c9b@redhat.com> References: <29367C39-36D1-4D17-BEB0-7B7C9D590435@amazon.com> <7DE1A3A6-4BCA-4C35-B992-08281C7A6C8B@amazon.com> <50f562af-6061-73f9-e974-bb3820022c9b@redhat.com> Message-ID: Hi, Andrew, Thanks for review it. Even though it's a backport patch, but the review workload as high as original one. Thanks. My comments are inline. ?On 5/16/19, 11:47 AM, "jdk8u-dev on behalf of Andrew John Hughes" wrote: On 16/05/2019 18:23, Liu, Xin wrote: > Hi, Reviewers, > > Could you review this backport patch? > > BUG: https://bugs.openjdk.java.net/browse/JDK-8222670 > Webrev: https://cr.openjdk.java.net/~xliu/8222670/webrev.8u-dev/ > > I can?t cleanly apply the original patch to jdk8u. I made the following changes. > > 1. Include JDK-8223537. It solved suspend problem in blocking mode. One line change. I think this should be applied as a pre-requisite clean backport. Just flag the bug with jdk8u-fix-request, no need for a separate review. I added jdk8u-fix-request for JDK-8223537 The change can trivially apply on jdk8u-dev. Here is webrev. The order does matter, so let's call it 3/3 patch, or last one. https://cr.openjdk.java.net/~xliu/8223537/webrev.8u-dev/ > 2. Shorter wait period. Otherwise, it?s easy to timeout for the test. It?s part of a JDK-8066770. > https://cr.openjdk.java.net/~xliu/8222670/webrev.8u-dev/test/compiler/whitebox/CompilerWhiteBoxTest.java.udiff.html > 8066770 relies on a lot of WhiteBox API that is not present in 8u so I'm ok with including just this segment. > 1. +1 for Tier4MinInvocationThreshold and Tier4CompileThreshold. Otherwise, we have to backport JDK-8059604, which looks like complicated. > > https://cr.openjdk.java.net/~xliu/8222670/webrev.8u-dev/src/share/vm/prims/whitebox.cpp.udiff.html JDK-8059604 looks backportable, but I'm ok with including this commented workaround for now. >> It is backportable. Actually, Paul suggested me do it. I think it's complicated because JDK-8059604 is only part of campaign(JDK-8050853). Taking 8059604 alone to jdk8u seems not be very useful. Further, I can't evaluate how much impact of changing thresholds from > to >= here. https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ffe9c8c82350#l5.9 I'd like to +1 in whitebox.cpp because it's just a fixture of testing. It won't have runtime risk. There seem to be two other changes being included here: 1. compileBroker.cpp changes These aren't in the original JDK-8222670. In 9, the != NULL test is added by "8144964: JVMCI compilations need to be disabled until the module system is initialized". 8 has neither JVMCI or a module system, so not sure why this test is being added here. Why is this included? >> I do need the "task != NULL" protection here. Otherwise, remove(NULL/*task*/); will cash JVM. If duplication happens , this patch will ditch the task from select_task and return NULL. For JDK-8144964, it?s all about JVMCI. That's why I don't want to backport it. 2. skiponTieredCompilation in CompilerWhiteBoxTest.java This is part of "8059575: JEP-JDK-8043304: Test task: Tiered Compilation level transition tests" which should also be backported as a pre-requisite. >> I backported 8059575 to jdk8u-dev. It's the 1/3 patch, or the first one to apply. Here is webrev: https://cr.openjdk.java.net/~xliu/8059575/webrev.01/ I was wrong at JDK-8059575. It need to polish a little bit to pass all tests. Here is my change: 1) add compile_id in NMethod.java. I got lost from here. https://hg.openjdk.java.net/jdk9/jdk9/rev/c82ea5393dda 2) modify @library for LevelTransitionTest.java and ConstantGettersTransitionsTest.java. It's because auxiliary library locates differently. > Thanks, > --lx > Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From aph at redhat.com Sun May 19 16:44:45 2019 From: aph at redhat.com (Andrew Haley) Date: Sun, 19 May 2019 17:44:45 +0100 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> <833668ba-d134-fdd0-2363-f682b19eced7@redhat.com> Message-ID: <30cdeab6-98d8-ae27-22ec-d1df51e13959@redhat.com> On 5/3/19 2:15 PM, Lindenmaier, Goetz wrote: >> But otherwise, the intent here is for people to start aiming their >> work at the next release at rampdown. Patches being pushed to >> jdk11u should be rare. > I think we should use jdk11u only for rampdown. So patches pushed to > jdk11u should be limited and well restricted, but not necessarily > rare. But yes, definitely less than pushed to jdk11u-dev. I have to agree with Andrew here. We should minimize churn at rampdown: every patch and combination of patches risks undermining stability, and that's true even with apparently low-risk patches. There were a lot of patches pushed to jdk11 during rampdown last time around, and that isn't necessarily good. >> The master tree (jdk11u) is snapshots for people to test and integrate >> downstream, leading up to the final release. >No. The jdk11u is a repository used for rampdown so that development >can be continued in another repository, here jdk11u-dev. >It is not a convenience for testers, it is to allow parallel work with >two different intentions: development <--> stabilization. Both of these can be true: Andrew is talking about what 11u is, you are talking about what it is for. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From goetz.lindenmaier at sap.com Mon May 20 07:22:02 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 20 May 2019 07:22:02 +0000 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: <30cdeab6-98d8-ae27-22ec-d1df51e13959@redhat.com> References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> <833668ba-d134-fdd0-2363-f682b19eced7@redhat.com> <30cdeab6-98d8-ae27-22ec-d1df51e13959@redhat.com> Message-ID: > -----Original Message----- > From: Andrew Haley > Sent: Sonntag, 19. Mai 2019 18:45 > To: Lindenmaier, Goetz ; Andrew John Hughes > ; Langer, Christoph > Cc: Severin Gehwolf ; 'jdk8u-dev at openjdk.java.net' > ; Aleksey Shipilev ; jdk- > updates-dev at openjdk.java.net > Subject: Re: [11u]: 8u222 & 11.0.4 release schedule > > On 5/3/19 2:15 PM, Lindenmaier, Goetz wrote: > > >> But otherwise, the intent here is for people to start aiming their > >> work at the next release at rampdown. Patches being pushed to > >> jdk11u should be rare. > > I think we should use jdk11u only for rampdown. So patches pushed to > > jdk11u should be limited and well restricted, but not necessarily > > rare. But yes, definitely less than pushed to jdk11u-dev. > > I have to agree with Andrew here. We should minimize churn at > rampdown: every patch and combination of patches risks undermining > stability, and that's true even with apparently low-risk > patches. There were a lot of patches pushed to jdk11 during rampdown > last time around, and that isn't necessarily good. Well, yes. Now as we do only 4 weeks of rampdown, we need to be much more careful about the changes than if we do 4 weeks RDP1 and 4 weeks RDP2. Best regards, Goetz. > >> The master tree (jdk11u) is snapshots for people to test and integrate > >> downstream, leading up to the final release. > >No. The jdk11u is a repository used for rampdown so that development > >can be continued in another repository, here jdk11u-dev. > >It is not a convenience for testers, it is to allow parallel work with > >two different intentions: development <--> stabilization. > > Both of these can be true: Andrew is talking about what 11u is, you > are talking about what it is for. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From xiaoming.gu at gmail.com Mon May 20 07:38:51 2019 From: xiaoming.gu at gmail.com (xiaoming gu) Date: Mon, 20 May 2019 00:38:51 -0700 Subject: which version of GCC is recommended to build 8u212 Message-ID: Hi folks, I hit a g++ error during building 8u212 with GCC 4..4.7. I'm wondering which version of GCC is recommended to build 8u212. Thanks, Xiaoming From shade at redhat.com Mon May 20 07:48:56 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 20 May 2019 09:48:56 +0200 Subject: which version of GCC is recommended to build 8u212 In-Reply-To: References: Message-ID: <12ab6fc7-eb60-a7a8-4b76-219c82d2eeb0@redhat.com> On 5/20/19 9:38 AM, xiaoming gu wrote: > I hit a g++ error during building 8u212 with GCC 4..4.7. I'm wondering > which version of GCC is recommended to build 8u212. You have to be more specific: what error have you hit? There are plenty of warnings-as-errors that could fail the build. Passing --with-extra-cflags=-Wno-error would resolve that. -Aleksey From fujie at loongson.cn Mon May 20 07:50:42 2019 From: fujie at loongson.cn (Jie Fu) Date: Mon, 20 May 2019 15:50:42 +0800 Subject: which version of GCC is recommended to build 8u212 In-Reply-To: References: Message-ID: <1c060bda-4fa8-6799-7ab0-2a81ca13451a@loongson.cn> What's the error, deprecated-declarations warning errors? On 2019/5/20 ??3:38, xiaoming gu wrote: > Hi folks, > > I hit a g++ error during building 8u212 with GCC 4..4.7. I'm wondering > which version of GCC is recommended to build 8u212. > > Thanks, > Xiaoming From aph at redhat.com Mon May 20 08:52:06 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 20 May 2019 09:52:06 +0100 Subject: OpenJDK Updates Project Builds In-Reply-To: <19529ef56caca7311d40fdb51bee0e27a3cefb86.camel@redhat.com> References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> <9e3b46db-c190-5a8a-3d26-050aab48d8ac@oracle.com> <70ef08c2-d452-bac8-53d9-914b95fdaccf@oracle.com> <9ca2b175cb0add0b6ff3da32d2b705af210c592b.camel@redhat.com> <515BB18C-F37C-44F6-81ED-E71F4DEF5FDF@azul.com> <19529ef56caca7311d40fdb51bee0e27a3cefb86.camel@redhat.com> Message-ID: <7b71194d-4a18-49e6-7caa-f4e4da180931@redhat.com> On 4/29/19 9:40 AM, Severin Gehwolf wrote: > On Fri, 2019-04-26 at 18:18 +0100, Andrew John Hughes wrote: >> I agree with making it clear that these builds are early access builds >> in the version output. A brief look suggests that --with-milestone=ea >> would be the way to do that, but I'm open to better suggestions from >> those who are more familiar with that part of the 8u build. > > --with-milestone=ea gives me this in version output for a hypothetical > 8u222-b00: > > $ ./bin/java -version > openjdk version "1.8.0_8u222-ea" > OpenJDK Runtime Environment (build 1.8.0_8u222-ea-b00) > OpenJDK 64-Bit Server VM (build 25.8u222-b00, mixed mode) > > If that seems OK to people, then I'll incorporate that for future EA > builds. That sounds right. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sgehwolf at redhat.com Mon May 20 08:59:13 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 20 May 2019 10:59:13 +0200 Subject: OpenJDK Updates Project Builds In-Reply-To: <7b71194d-4a18-49e6-7caa-f4e4da180931@redhat.com> References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> <9e3b46db-c190-5a8a-3d26-050aab48d8ac@oracle.com> <70ef08c2-d452-bac8-53d9-914b95fdaccf@oracle.com> <9ca2b175cb0add0b6ff3da32d2b705af210c592b.camel@redhat.com> <515BB18C-F37C-44F6-81ED-E71F4DEF5FDF@azul.com> <19529ef56caca7311d40fdb51bee0e27a3cefb86.camel@redhat.com> <7b71194d-4a18-49e6-7caa-f4e4da180931@redhat.com> Message-ID: <33768f33b0cae49fd6116788e06b54bc583450c7.camel@redhat.com> On Mon, 2019-05-20 at 09:52 +0100, Andrew Haley wrote: > > --with-milestone=ea gives me this in version output for a hypothetical > > 8u222-b00: > > > > $ ./bin/java -version > > openjdk version "1.8.0_8u222-ea" > > OpenJDK Runtime Environment (build 1.8.0_8u222-ea-b00) > > OpenJDK 64-Bit Server VM (build 25.8u222-b00, mixed mode) > > > > If that seems OK to people, then I'll incorporate that for future EA > > builds. > > That sounds right. Great! JDK 8u builds[1] do that since 8u222-b01: $ ./openjdk-8u222-b02/bin/java -version openjdk version "1.8.0_222-ea" OpenJDK Runtime Environment (build 1.8.0_222-ea-b02) OpenJDK 64-Bit Server VM (build 25.222-b02, mixed mode) Thanks, Severin [1] https://adoptopenjdk.net/upstream.html From shade at redhat.com Mon May 20 09:02:56 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 20 May 2019 11:02:56 +0200 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: <6701b582-174f-a28a-fd65-4db7742f5ee5@redhat.com> References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> <6701b582-174f-a28a-fd65-4db7742f5ee5@redhat.com> Message-ID: <27387e08-a6d5-d419-c7ca-ea37b9cd7c21@redhat.com> On 5/15/19 11:44 PM, Aleksey Shipilev wrote: > On 5/15/19 11:39 PM, Andrew John Hughes wrote: >> Wouldn't this be better raised on the Debian mailing lists than here? > > +1 I take it that no one did? Looking around archives yield no relevant hits. Maybe it is stashed in Debian bugtracker somewhere I cannot find. So, I just did this: https://lists.debian.org/debian-java/2019/05/msg00007.html -- Thanks, -Aleksey From sgehwolf at redhat.com Mon May 20 09:08:10 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 20 May 2019 11:08:10 +0200 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: <27387e08-a6d5-d419-c7ca-ea37b9cd7c21@redhat.com> References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> <6701b582-174f-a28a-fd65-4db7742f5ee5@redhat.com> <27387e08-a6d5-d419-c7ca-ea37b9cd7c21@redhat.com> Message-ID: <71bda8763fa18c64f933af129226a99bae0067bb.camel@redhat.com> On Mon, 2019-05-20 at 11:02 +0200, Aleksey Shipilev wrote: > On 5/15/19 11:44 PM, Aleksey Shipilev wrote: > > On 5/15/19 11:39 PM, Andrew John Hughes wrote: > > > Wouldn't this be better raised on the Debian mailing lists than here? > > > > +1 > > I take it that no one did? Looking around archives yield no relevant hits. Maybe it is stashed in > Debian bugtracker somewhere I cannot find. > > So, I just did this: > https://lists.debian.org/debian-java/2019/05/msg00007.html See also: https://github.com/docker-library/openjdk/issues/320 Thanks, Severin From dalibor.topic at oracle.com Mon May 20 11:35:52 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Mon, 20 May 2019 13:35:52 +0200 Subject: OpenJDK 8u222-b01 EA Released In-Reply-To: <37ffcae8-b6d6-d153-011a-090604f1a5ba@redhat.com> References: <37ffcae8-b6d6-d153-011a-090604f1a5ba@redhat.com> Message-ID: On 14.05.2019 16:19, Andrew John Hughes wrote: > > I've done that with the latest one (b02), Thank you very much, Andrew! cheers, dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | D-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-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From anssi at aketzu.net Mon May 20 16:47:15 2019 From: anssi at aketzu.net (Anssi Kolehmainen) Date: Mon, 20 May 2019 19:47:15 +0300 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> Message-ID: <20190520164715.b63rhopjn2f7czfy@kelvin.aketzu.net> On Wed, 15 May 2019 18:49:55 +0000, Gil Tene wrote: > If anyone was wondering about the importance of having version strings say > "EA" (or some other "THIS IS NOT a RELEASED VERSION" warning) on any > and all OpenJDK builds that are not an actual release build, the above shows > you how bad things get when that practice is not followed. Here's an outsider UI testing report for Java versioning: Task: How can I find out which is the correct build for this version Google openjdk, go to openjdk.java.net, on frontpage click install. Instructions say "sudo apt-get install openjdk-8-jre" which then installs 8u212-b01. Success! Go back to frontpage, click on "here" (as in Oracle builds), see only "8u212", don't want to do read through EULA so go back to openjdk frontpage. Go through the tiny left navbar, click on "JDK 8"... This talks about 2014 so bummer. Go to "JDK 8 Updates"... Pretty much empty page so "Consult Wiki for details". Font gets even tinier but I keep glancing. Releases list "Latest: 8u212" but only "GA" as build number. Click on "tag" which goes to hg[1] "Added tag jdk8u212-b02"... Success! [1]: http://hg.openjdk.java.net/jdk8u/jdk8u/rev/5218ef8ea6c3 Click on "Released", get to Github AdoptOpenJDK releases. Title says "8u212 GA" but thankfully tag shows "8u212-b03". Go to Azul web to look for releases and notice that there is grey overcast on whole page which prevents clicking on any links. Top bar says something about cookies but I close the page since it seems broken. (Thanks EU) Go back to OpenJDK frontpage and click on Mercurial. Click on jdk8, jdk and notice that everything is again 2014. Go back to jdk8u, go to jdk8u, go to jdk. Click on tags and be amazed of the UI. A bit hard to demonstrate in email but something like jdk8u212-b04 01535393e060 jdk8u212-ga ac2ef877d3e8 jdk8u212-b03 ac2ef877d3e8 jdk8u212-b02 acab6dbdd0b5 jdk8u222-b00 fcf246aa327f jdk8u212-b01 fcf246aa327f So b04 is the newest (and thus best?) but after decreasing resolution from 2K and applying ruler to display ga happens to have same node as b03. Finally dig out mailing list archives, find the release announcement and look up in the URLs that say b03. Final tally is something like b01 1 hit b02 1 hit b03 3 hits b04 1 hit So with some confidence it would be possible to say that b03 is the correct version :) It would be really much better if version number would include beta/pre/EA in the prereleases or then GA in the final version. -- Anssi Kolehmainen From xiaoming.gu at gmail.com Mon May 20 18:53:28 2019 From: xiaoming.gu at gmail.com (xiaoming gu) Date: Mon, 20 May 2019 11:53:28 -0700 Subject: which version of GCC is recommended to build 8u212 In-Reply-To: <1c060bda-4fa8-6799-7ab0-2a81ca13451a@loongson.cn> References: <1c060bda-4fa8-6799-7ab0-2a81ca13451a@loongson.cn> Message-ID: It is not a warning but a crash inside g++. Please see details as follows: ..../jdk8u212-b03/hotspot/src/share/vm/opto/mulnode.cpp: In member function ?virtual Node* MulLNode::Ideal(PhaseGVN*, bool)?: ..../jdk8u212-b03/hotspot/src/share/vm/opto/mulnode.cpp:324: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. gmake[6]: *** [mulnode.o] Error 1 I did the build simply with "bash ./configure" and "make all". The used toolchain was GCC 4.4.7. Which version of GCC do you use? Thanks, Xiaoming On Mon, May 20, 2019 at 12:51 AM Jie Fu wrote: > What's the error, deprecated-declarations warning errors? > > On 2019/5/20 ??3:38, xiaoming gu wrote: > > Hi folks, > > > > I hit a g++ error during building 8u212 with GCC 4..4.7. I'm wondering > > which version of GCC is recommended to build 8u212. > > > > Thanks, > > Xiaoming > > From gromero at linux.vnet.ibm.com Mon May 20 20:46:58 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 20 May 2019 17:46:58 -0300 Subject: [8u-dev, ppc] RFR for (almost clean) backport of 8158232 In-Reply-To: References: Message-ID: <81c12391-1406-948d-e8c5-9f66437a1b92@linux.vnet.ibm.com> Hi, Pushed to jdk8u-dev: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/39678a65a0e8 Thank you. Best regards, Gustavo On 05/14/2019 03:02 AM, Kazunori Ogata wrote: > Hi Gustavo, > > Thank you for the suggestion. I'll proceed to put the fix request comment > and tag in the original bug report. > > Thank you too for offering to sponsor this change. I'll let you know when > it's approved. > > > Regards, > Ogata > > > "Gustavo Romero" wrote on 2019/05/14 > 04:59:43: > >> From: "Gustavo Romero" >> To: Kazunori Ogata/Japan/IBM at IBMJP, > hotspot-compiler-dev at openjdk.java.net, >> jdk8u-dev at openjdk.java.net >> Date: 2019/05/14 04:59 >> Subject: Re: [8u-dev, ppc] RFR for (almost clean) backport of 8158232 >> >> Hi Ogata, >> >> Thanks for the backport and for the webrev. >> >> I understand that offset adjustments in general, and particularly for > this >> backport, are not considered a change that needs to be reviewed again. >> >> That said, and although I'm not a Reviewer, I tested it against SPECjvm > and >> microbenchmarks for byte, int, and long and reviewed the change for > jdk8u-dev. >> >> It looks good. >> >> Please, provide a "Fix Request" comment to the original bug explaining > that >> the backport is low risk and affects PPC64-only, accordingly to [1] and > [2]. >> Then please add the label "jdk8u-fix-request" to it. >> >> Once the approval to push is granted I'll sponsor the change. >> >> Thank you. >> >> Best regards, >> Gustavo >> >> [1] https://wiki.openjdk.java.net/display/jdk8u/Main >> [2] http://openjdk.java.net/projects/jdk-updates/approval.html >> >> On 05/10/2019 03:55 AM, Kazunori Ogata wrote: >>> Sorry, I forgot to put the links to the bug report and the original >>> changeset Also forgot to mention that this changeset is needed to >>> backport AES intrinsics support [1] on ppc64 big-endian. >>> >>> Bug report: >>> https://bugs.openjdk.java.net/browse/JDK-8158232 >>> >>> Original change set >>> http://hg.openjdk.java.net/jdk/jdk/rev/987528901b83 >>> >>> >>> Webrev: >>> http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8158232/webrev.02/ >>> >>> >>> Refs: >>> [1] https://bugs.openjdk.java.net/browse/JDK-8188868 >>> >>> >>> Regards, >>> Ogata >>> >>> "hotspot-compiler-dev" >>> wrote on 2019/05/10 15:30:05: >>> >>>> From: "Kazunori Ogata" >>>> To: hotspot-compiler-dev at openjdk.java.net, jdk8u-dev at openjdk.java.net >>>> Date: 2019/05/10 15:31 >>>> Subject: [8u-dev, ppc] RFR for (almost clean) backport of 8158232 >>>> Sent by: "hotspot-compiler-dev" >>> >>>> >>>> Hi, >>>> >>>> May I get review for backport of 8158232: PPC64: improve byte, int > and >>>> long array copy stubs by using VSX instructions? >>>> >>>> This changeset looks no conflict with the latest jdk8u-dev code, but > the >>> >>>> patch command failed to apply it. It seems the patch command lost > the >>>> code regions to apply patches because stubGenerator_ppc.cpp has sets > of >>>> similar (but slightly different) functions. >>>> >>>> I created new webrev mainly to update line numbers in the patch file. > I >>> >>>> verified I can build fastdebug and release builds and there was no >>>> degradation in "make test" results. >>>> >>>> http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8158232/webrev.02/ >>>> >>>> Regards, >>>> Ogata >>>> >>>> >>> >>> > > From fujie at loongson.cn Mon May 20 20:57:39 2019 From: fujie at loongson.cn (Jie Fu) Date: Tue, 21 May 2019 04:57:39 +0800 Subject: which version of GCC is recommended to build 8u212 In-Reply-To: References: <1c060bda-4fa8-6799-7ab0-2a81ca13451a@loongson.cn> Message-ID: <9607bd6f-6fb9-7111-ad12-82c847c9e3ba@loongson.cn> In case of SIGSEGV, just rm build and retry it. I also came across such errors while building jdk/jdk. On 2019?05?21? 02:53, xiaoming gu wrote: > It is not a warning but a crash inside g++. Please see details as > follows: > > ..../jdk8u212-b03/hotspot/src/share/vm/opto/mulnode.cpp: In member > function ?virtual Node* MulLNode::Ideal(PhaseGVN*, bool)?: > ..../jdk8u212-b03/hotspot/src/share/vm/opto/mulnode.cpp:324: internal > compiler error: Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > gmake[6]: *** [mulnode.o] Error 1 > > I did the build simply with "bash ./configure" and "make all". The > used toolchain was GCC 4.4.7. Which version of GCC do you use? > > Thanks, > Xiaoming > > > > On Mon, May 20, 2019 at 12:51 AM Jie Fu > wrote: > > What's the error, deprecated-declarations warning errors? > > On 2019/5/20 ??3:38, xiaoming gu wrote: > > Hi folks, > > > > I hit a g++ error during building 8u212 with GCC 4..4.7. I'm > wondering > > which version of GCC is recommended to build 8u212. > > > > Thanks, > > Xiaoming > From gnu.andrew at redhat.com Tue May 21 01:51:12 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 21 May 2019 02:51:12 +0100 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: <20190520164715.b63rhopjn2f7czfy@kelvin.aketzu.net> References: <20190520164715.b63rhopjn2f7czfy@kelvin.aketzu.net> Message-ID: On 20/05/2019 17:47, Anssi Kolehmainen wrote: > On Wed, 15 May 2019 18:49:55 +0000, Gil Tene wrote: >> If anyone was wondering about the importance of having version strings >> say >> "EA" (or some other "THIS IS NOT a RELEASED VERSION" warning) on any >> and all OpenJDK builds that are not an actual release build, the above >> shows >> you how bad things get when that practice is not followed. > > Here's an outsider UI testing report for Java versioning: > > Task: How can I find out which is the correct build for this version > > > Google openjdk, go to openjdk.java.net, on frontpage click install. > Instructions say "sudo apt-get install openjdk-8-jre" which then > installs 8u212-b01. Success! > > Go back to frontpage, click on "here" (as in Oracle builds), see only > "8u212", > don't want to do read through EULA so go back to openjdk frontpage. > > Go through the tiny left navbar, click on "JDK 8"... This talks about > 2014 so bummer. This content is controlled by Oracle, so sadly we can't change any of it. I certainly don't think non-OpenJDK builds should be listed on the front page. However, you do omit the link between those two which directs to jdk.java.net/12 and OpenJDK builds of the latest OpenJDK release. I guess that's not much use if you're specifically looking for 8 and it would be irresponsible to link to https://jdk.java.net/java-se-ri/8 as the builds it links to are woefully outdated. Go to "JDK 8 Updates"... Pretty much empty page so > "Consult Wiki for details". > Font gets even tinier but I keep glancing. Releases list "Latest: 8u212" > but only "GA" as build number. Click on "tag" which goes to hg[1] "Added > tag jdk8u212-b02"... Success! > [1]: http://hg.openjdk.java.net/jdk8u/jdk8u/rev/5218ef8ea6c3 > > Click on "Released", get to Github AdoptOpenJDK releases. Title says > "8u212 GA" but thankfully tag shows "8u212-b03". We can revise these, so suggestions welcome. I'm not sure about changing the text size on the wiki, but I agree I also find it rather on the small side. > > Go to Azul web to look for releases and notice that there is grey > overcast on whole page which prevents clicking on any links. Top bar > says something about cookies but I close the page since it seems broken. > (Thanks EU) I'll leave Azul to comment on this. > > Go back to OpenJDK frontpage and click on Mercurial. Click on jdk8, jdk > and notice that everything is again 2014. Go back to jdk8u, go to jdk8u, > go to jdk. > Click on tags and be amazed of the UI. A bit hard to demonstrate in > email but something like > > jdk8u212-b04???????????????????????????????????????????????????? > 01535393e060 > jdk8u212-ga????????????????????????????????????????????????????? > ac2ef877d3e8 > jdk8u212-b03???????????????????????????????????????????????????? > ac2ef877d3e8 > jdk8u212-b02???????????????????????????????????????????????????? > acab6dbdd0b5 > jdk8u222-b00???????????????????????????????????????????????????? > fcf246aa327f > jdk8u212-b01???????????????????????????????????????????????????? > fcf246aa327f > Yes, this is not really much use from an end-user perspective. > So b04 is the newest (and thus best?) but after decreasing resolution > from 2K and applying ruler to display ga happens to have same node as b03. > > Finally dig out mailing list archives, find the release announcement and > look up in the URLs that say b03. > > > Final tally is something like > b01? 1 hit > b02? 1 hit > b03? 3 hits > b04? 1 hit > > So with some confidence it would be possible to say that b03 is the correct > version :) The release announcement (http://bitly.com/oj8u212) should be linked from the wiki page. I'll fix that. > > > It would be really much better if version number would include > beta/pre/EA in the prereleases or then GA in the final version. > Where do you mean? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From anssi at aketzu.net Tue May 21 07:13:43 2019 From: anssi at aketzu.net (Anssi Kolehmainen) Date: Tue, 21 May 2019 10:13:43 +0300 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: References: <20190520164715.b63rhopjn2f7czfy@kelvin.aketzu.net> Message-ID: <20190521071343.6ziavswihvxjtcuf@kelvin.aketzu.net> On Tue, May 21, 2019 at 02:51:12AM +0100, Andrew John Hughes wrote: >On 20/05/2019 17:47, Anssi Kolehmainen wrote: >> Google openjdk, go to openjdk.java.net, on frontpage click install. >> Instructions say "sudo apt-get install openjdk-8-jre" which then >> installs 8u212-b01. Success! >> >> Go back to frontpage, click on "here" (as in Oracle builds), see only >> "8u212", >> don't want to do read through EULA so go back to openjdk frontpage. >> >> Go through the tiny left navbar, click on "JDK 8"... This talks about >> 2014 so bummer. > >This content is controlled by Oracle, so sadly we can't change any of >it. I certainly don't think non-OpenJDK builds should be listed on the >front page. However, you do omit the link between those two which >directs to jdk.java.net/12 and OpenJDK builds of the latest OpenJDK release. Yeah... What I want to do is to get Java on the machine, be it Debian, RHEL, Windows or whatever. Currently OpenJDK web looks like everything is just JDK 12 and others are "too old". Sadly the other products (e.g. Payara) have not caught up with the new Java release speed so JDK 8 it must be. I basically must figure out somewhere else that what I really want is AdoptOpenJDK or Azul and not "OpenJDK" itself. (Oracle JDK is basically out of question after latest license change.) >> "Consult Wiki for details". >> Font gets even tinier but I keep glancing. Releases list "Latest: 8u212" >> but only "GA" as build number. Click on "tag" which goes to hg[1] "Added >> tag jdk8u212-b02"... Success! >> [1]: http://hg.openjdk.java.net/jdk8u/jdk8u/rev/5218ef8ea6c3 >> >> Click on "Released", get to Github AdoptOpenJDK releases. Title says >> "8u212 GA" but thankfully tag shows "8u212-b03". > >We can revise these, so suggestions welcome. I'm not sure about changing >the text size on the wiki, but I agree I also find it rather on the >small side. On a general level what I usually look is the current version, when it was released and what was changed (major points, incompatibilities). Also sometimes version history that when some old version was released. On release notes level GitLab does pretty good job https://about.gitlab.com/2019/04/22/gitlab-11-10-released/ Something like Payara might be better fit for JDK releases https://www.payara.fish/software/release-notes/ .. which is pretty much what the release announcement mailing list post looks like. But it's "hidden" behind so many clicks. It would be really nice to be able edit also the openjdk.java.net frontpage so there would be more direct links to relevant parts. For version history something like: https://en.wikipedia.org/wiki/.NET_Framework#Release_history https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Version_history_and_timeline So there would be list of all releases and links to their release postings. For example if I want to check 8u202 release details I go to archive page which has basically nothing. Was there a release posting about it? AdoptOpenJDK GitHub page lists 8u202-b08 as release version. Debian has packaged 8u202-b26. Oracle just makes my head hurt every time :) >> It would be really much better if version number would include >> beta/pre/EA in the prereleases or then GA in the final version. > >Where do you mean? In the version number itself... So instead of OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1~deb9u1-b01) it would be OpenJDK Runtime Environment (build 1.8.0_212-8u212-pre01-1~deb9u1-pre01) Then it would hopefully be more clear that "this version is not suitable for general use". -- Anssi Kolehmainen anssi.kolehmainen at iki.fi 040-5085390 From shade at redhat.com Wed May 22 08:28:13 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 22 May 2019 10:28:13 +0200 Subject: [8u] RFR (S) 8190974: Parallel stream execution within a custom ForkJoinPool should obey the parallelism In-Reply-To: <94d05544-08af-0969-1d28-484b79c597fe@redhat.com> References: <94d05544-08af-0969-1d28-484b79c597fe@redhat.com> Message-ID: Ping, still needs review. On 5/2/19 7:45 PM, Aleksey Shipilev wrote: > Original fix: > https://bugs.openjdk.java.net/browse/JDK-8190974 > http://hg.openjdk.java.net/jdk/jdk/rev/e0041b182e31 > > This is one of the things that was mentioned multiple times as the pitfall in 8u. The patch itself > is simple enough to consider backporting and fixing that pothole. Once related JDK-8154387 [1] > backport is in, this patch applies with reshuffling to 8u, except for the test, which requires > fitting to the old shape of Stream tests. > > 8u webrev: > http://cr.openjdk.java.net/~shade/8190974/webrev.8u.01/ > > Testing: jdk_core tests, including the new test > > Thanks, > -Aleksey > > [1] https://bugs.openjdk.java.net/browse/JDK-8154387 -- Thanks, -Aleksey From martinrb at google.com Wed May 22 15:47:41 2019 From: martinrb at google.com (Martin Buchholz) Date: Wed, 22 May 2019 08:47:41 -0700 Subject: [8u] RFR (S) 8190974: Parallel stream execution within a custom ForkJoinPool should obey the parallelism In-Reply-To: <94d05544-08af-0969-1d28-484b79c597fe@redhat.com> References: <94d05544-08af-0969-1d28-484b79c597fe@redhat.com> Message-ID: Too bad Paul Sandoz is no longer working on openjdk. Maybe Doug can review - he was involved with design of stream parallelism IIRC. I took a quick look - it Looks Good To Me. (But I have misgivings about any sort of auto-parallelization, including via parallel streams, which will become increasingly important as cpu counts increase) On Thu, May 2, 2019 at 10:45 AM Aleksey Shipilev wrote: > Original fix: > https://bugs.openjdk.java.net/browse/JDK-8190974 > http://hg.openjdk.java.net/jdk/jdk/rev/e0041b182e31 > > This is one of the things that was mentioned multiple times as the pitfall > in 8u. The patch itself > is simple enough to consider backporting and fixing that pothole. Once > related JDK-8154387 [1] > backport is in, this patch applies with reshuffling to 8u, except for the > test, which requires > fitting to the old shape of Stream tests. > > 8u webrev: > http://cr.openjdk.java.net/~shade/8190974/webrev.8u.01/ > > Testing: jdk_core tests, including the new test > > Thanks, > -Aleksey > > [1] https://bugs.openjdk.java.net/browse/JDK-8154387 > > From vkempik at azul.com Wed May 22 16:04:37 2019 From: vkempik at azul.com (Vladimir Kempik) Date: Wed, 22 May 2019 16:04:37 +0000 Subject: RFR: 8223147: JFR Backport (to jdk8u) Message-ID: <0960517C-26F0-4344-92CA-08A547323FE9@azul.com> Hello. Please take a look at these patches to fix solaris10 support for jfr on openjdk8. Since solaris10 was never in mind when this series of patches were produced, we at azul had issues with jfr tests on solaris10. Please take a look at series of patches which supposed to add solaris 10 support to these jfr patches discussed in this thread. First one http://cr.openjdk.java.net/~vkempik/solaris1/webrev.00/ it?s related to VM InterruptableIO on solaris and similar to https://bugs.openjdk.java.net/browse/JDK-8153641 fixes most of the issues we had when jvm is writing jfr dumps second one http://cr.openjdk.java.net/~vkempik/solaris2/webrev.00/ it?s about enumerating network interfaces on solaris10, it?s pretty different from solaris 11 on solaris11 it?s enough to just do kstat -c net -m link , but on solaris10 one need to do first kstat -c net -n mac and remember the list of modules which provide mac functionality, for example: module: nxge instance: 0 name: mac class: net then if you do kstat -c net -m ngxe and check only elements where name starts with module name then it?s actual list of network interfaces, for example: module: nxge instance: 0 name: nxge0 class: net and the last one http://cr.openjdk.java.net/~vkempik/solaris3/webrev.00/ is just to fix solaris build again( which was broken by http://cr.openjdk.java.net/~luchsh/g1region_type_change_event/ ) which is failing due to missing types definitions which are in file gc_implementation/g1/g1HeapRegionTraceType.hpp All jfr tests pass on solaris10 now Thanks, Vladimir From sgehwolf at redhat.com Wed May 22 16:34:04 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 22 May 2019 18:34:04 +0200 Subject: [8u] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u Message-ID: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com> Hi, Could I please get reviews for this minimal implementation of a tier1- like test set for JDK 8u? The implementation is rather barebones as I don't think it's worth rewriting the build system just for a command that runs a certain set of tests across a select set of repositories. I've re-used existing work in Makefiles as much as possible. After this patch one can do: $ make test TEST="tier1" Inspiration came from JDK 11u's tier1. As for prior art to this, I've only found "make test" to be working for JDK 8u from the top level. Yet, it doesn't run any hotspot tests, exits with a zero code on test failures and doesn't present a summary at the end. Overall not a nice developer experience. This patch makes it easier for a developers tests. It presents a summary at the end, returns non-zero on test failures so this can get used in CI and runs hotspot tests. As a follow-on we can work on fixing/excluding tests so that we always have a passing set of tests for developers to run before a checkin. Bug: https://bugs.openjdk.java.net/browse/JDK-8222737 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/ (includes changes to top/hotspot/jdk/langtools repos) Example excerpt from a run: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/example_output.txt Thoughts? Thanks, Severin From dl at cs.oswego.edu Wed May 22 17:46:47 2019 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 22 May 2019 13:46:47 -0400 Subject: [8u] RFR (S) 8190974: Parallel stream execution within a custom ForkJoinPool should obey the parallelism In-Reply-To: References: <94d05544-08af-0969-1d28-484b79c597fe@redhat.com> Message-ID: Yes, this looks OK to me. -Doug On 5/22/19 11:47 AM, Martin Buchholz wrote: > Too bad Paul Sandoz is no longer working on openjdk. > Maybe Doug can review - he was involved with design of stream > parallelism IIRC. > I took a quick look - it Looks Good To Me. > > (But I have misgivings about any sort of auto-parallelization, including > via parallel streams, which will become increasingly important as cpu > counts increase) > > On Thu, May 2, 2019 at 10:45 AM Aleksey Shipilev > wrote: > > Original fix: > ? https://bugs.openjdk.java.net/browse/JDK-8190974 > ? http://hg.openjdk.java.net/jdk/jdk/rev/e0041b182e31 > > This is one of the things that was mentioned multiple times as the > pitfall in 8u. The patch itself > is simple enough to consider backporting and fixing that pothole. > Once related JDK-8154387 [1] > backport is in, this patch applies with reshuffling to 8u, except > for the test, which requires > fitting to the old shape of Stream tests. > > 8u webrev: > ? http://cr.openjdk.java.net/~shade/8190974/webrev.8u.01/ > > Testing: jdk_core tests, including the new test > > Thanks, > -Aleksey > > [1] https://bugs.openjdk.java.net/browse/JDK-8154387 > From OGATAK at jp.ibm.com Wed May 22 18:43:50 2019 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Thu, 23 May 2019 03:43:50 +0900 Subject: [8u-dev, ppc] RFR for (almost clean) backport of 8158232 In-Reply-To: <81c12391-1406-948d-e8c5-9f66437a1b92@linux.vnet.ibm.com> References: <81c12391-1406-948d-e8c5-9f66437a1b92@linux.vnet.ibm.com> Message-ID: Hi Gustavo, Thank you for sponsoring the patch. Regards, Ogata "Gustavo Romero" wrote on 2019/05/21 05:46:58: > From: "Gustavo Romero" > To: Kazunori Ogata/Japan/IBM at IBMJP > Cc: hotspot-compiler-dev at openjdk.java.net, jdk8u-dev at openjdk.java.net > Date: 2019/05/21 05:47 > Subject: Re: [8u-dev, ppc] RFR for (almost clean) backport of 8158232 > > Hi, > > Pushed to jdk8u-dev: > > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/39678a65a0e8 > > Thank you. > > Best regards, > Gustavo > > On 05/14/2019 03:02 AM, Kazunori Ogata wrote: > > Hi Gustavo, > > > > Thank you for the suggestion. I'll proceed to put the fix request comment > > and tag in the original bug report. > > > > Thank you too for offering to sponsor this change. I'll let you know when > > it's approved. > > > > > > Regards, > > Ogata > > > > > > "Gustavo Romero" wrote on 2019/05/14 > > 04:59:43: > > > >> From: "Gustavo Romero" > >> To: Kazunori Ogata/Japan/IBM at IBMJP, > > hotspot-compiler-dev at openjdk.java.net, > >> jdk8u-dev at openjdk.java.net > >> Date: 2019/05/14 04:59 > >> Subject: Re: [8u-dev, ppc] RFR for (almost clean) backport of 8158232 > >> > >> Hi Ogata, > >> > >> Thanks for the backport and for the webrev. > >> > >> I understand that offset adjustments in general, and particularly for > > this > >> backport, are not considered a change that needs to be reviewed again. > >> > >> That said, and although I'm not a Reviewer, I tested it against SPECjvm > > and > >> microbenchmarks for byte, int, and long and reviewed the change for > > jdk8u-dev. > >> > >> It looks good. > >> > >> Please, provide a "Fix Request" comment to the original bug explaining > > that > >> the backport is low risk and affects PPC64-only, accordingly to [1] and > > [2]. > >> Then please add the label "jdk8u-fix-request" to it. > >> > >> Once the approval to push is granted I'll sponsor the change. > >> > >> Thank you. > >> > >> Best regards, > >> Gustavo > >> > >> [1] https://wiki.openjdk.java.net/display/jdk8u/Main > >> [2] http://openjdk.java.net/projects/jdk-updates/approval.html > >> > >> On 05/10/2019 03:55 AM, Kazunori Ogata wrote: > >>> Sorry, I forgot to put the links to the bug report and the original > >>> changeset Also forgot to mention that this changeset is needed to > >>> backport AES intrinsics support [1] on ppc64 big-endian. > >>> > >>> Bug report: > >>> https://bugs.openjdk.java.net/browse/JDK-8158232 > >>> > >>> Original change set > >>> http://hg.openjdk.java.net/jdk/jdk/rev/987528901b83 > >>> > >>> > >>> Webrev: > >>> http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8158232/webrev.02/ > >>> > >>> > >>> Refs: > >>> [1] https://bugs.openjdk.java.net/browse/JDK-8188868 > >>> > >>> > >>> Regards, > >>> Ogata > >>> > >>> "hotspot-compiler-dev" > >>> wrote on 2019/05/10 15:30:05: > >>> > >>>> From: "Kazunori Ogata" > >>>> To: hotspot-compiler-dev at openjdk.java.net, jdk8u-dev at openjdk.java.net > >>>> Date: 2019/05/10 15:31 > >>>> Subject: [8u-dev, ppc] RFR for (almost clean) backport of 8158232 > >>>> Sent by: "hotspot-compiler-dev" > >>> > >>>> > >>>> Hi, > >>>> > >>>> May I get review for backport of 8158232: PPC64: improve byte, int > > and > >>>> long array copy stubs by using VSX instructions? > >>>> > >>>> This changeset looks no conflict with the latest jdk8u-dev code, but > > the > >>> > >>>> patch command failed to apply it. It seems the patch command lost > > the > >>>> code regions to apply patches because stubGenerator_ppc.cpp has sets > > of > >>>> similar (but slightly different) functions. > >>>> > >>>> I created new webrev mainly to update line numbers in the patch file. > > I > >>> > >>>> verified I can build fastdebug and release builds and there was no > >>>> degradation in "make test" results. > >>>> > >>>> http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8158232/webrev.02/ > >>>> > >>>> Regards, > >>>> Ogata > >>>> > >>>> > >>> > >>> > > > > From shade at redhat.com Wed May 22 19:29:21 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 22 May 2019 21:29:21 +0200 Subject: [8u] RFR (S) 8190974: Parallel stream execution within a custom ForkJoinPool should obey the parallelism In-Reply-To: References: <94d05544-08af-0969-1d28-484b79c597fe@redhat.com> Message-ID: <722a9ee1-676d-292c-60eb-0e75df6ddfa8@redhat.com> Thank you all, we have all reviews and approvals. Pushed to 8u-dev. -Aleksey On 5/22/19 7:46 PM, Doug Lea wrote: > Yes, this looks OK to me. > > -Doug > > > On 5/22/19 11:47 AM, Martin Buchholz wrote: >> Too bad Paul Sandoz is no longer working on openjdk. >> Maybe Doug can review - he was involved with design of stream >> parallelism IIRC. >> I took a quick look - it Looks Good To Me. >> >> (But I have misgivings about any sort of auto-parallelization, including >> via parallel streams, which will become increasingly important as cpu >> counts increase) >> >> On Thu, May 2, 2019 at 10:45 AM Aleksey Shipilev > > wrote: >> >> Original fix: >> ? https://bugs.openjdk.java.net/browse/JDK-8190974 >> ? http://hg.openjdk.java.net/jdk/jdk/rev/e0041b182e31 >> >> This is one of the things that was mentioned multiple times as the >> pitfall in 8u. The patch itself >> is simple enough to consider backporting and fixing that pothole. >> Once related JDK-8154387 [1] >> backport is in, this patch applies with reshuffling to 8u, except >> for the test, which requires >> fitting to the old shape of Stream tests. >> >> 8u webrev: >> ? http://cr.openjdk.java.net/~shade/8190974/webrev.8u.01/ >> >> Testing: jdk_core tests, including the new test >> >> Thanks, >> -Aleksey >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8154387 >> > > -- Thanks, -Aleksey From gnu.andrew at redhat.com Thu May 23 03:34:17 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 23 May 2019 04:34:17 +0100 Subject: OpenJDK 8u222-b03 EA Released Message-ID: <62bd8a4d-a6ec-b440-9bbd-562aab78c844@redhat.com> I've made available an early access source bundle for 8u222, based on the tag jdk8u222-b03: https://openjdk-sources.osci.io/openjdk8/openjdk8u222-b03-ea.tar.xz The tarball is accompanied by a digital signature available at: https://openjdk-sources.osci.io/openjdk8/openjdk8u222-b03-ea.tar.xz.sig This is signed by our new Red Hat OpenJDK key (openjdk at redhat.com): PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) Fingerprint = CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F SHA256 checksums: 60d603331e5d17029f75f6a3cf921f3a1a2a09bfb8f6d820f8e9025f96508866 openjdk8u222-b03-ea.tar.xz 4a38811a5338083bf85fe7034434b6fe1eee7b23b64a914697ba1250e736cd07 openjdk8u222-b03-ea.tar.xz.sig They are listed at https://openjdk-sources.osci.io/openjdk8/openjdk8u222-b03-ea.sha256 Changes in jdk8u222-b03: - S7100957: SOCKS proxying does not work with IPv6 connections - S7102541: RFE: os::set_native_thread_name() cleanups - S8144332: HSDB could not terminate when close button is pushed. - S8151322: Implement os::set_native_thread_name() on Solaris - S8154387: Parallel unordered Stream.limit() tries to collect 128 elements even if limit is less - S8189131: Open-source the Oracle JDK Root Certificates - S8189949: Remove Baltimore Cybertrust Code Signing CA - S8191031: Remove several Symantec Root CAs - S8191844: Remove SECOM root (secomevrootca1) - S8195774: Add Entrust root certificates - S8195793: Remove GTE CyberTrust Global Root - S8196141: Add GoDaddy root certificates - S8199779: Add T-Systems, GlobalSign and Starfield services root certificates - S8204923: Restore Symantec root verisignclass2g2ca - S8209506: Add Google Trust Services GlobalSign root certificates - S8210425: [x86] sharedRuntimeTrig/sharedRuntimeTrans compiled without optimization - S8210432: Add additional TeliaSonera root certificate - S8213213: Remove src/java.desktop/unix/classes/sun/awt/X11/keysym2ucs.h - S8214770: java/time/test/java/time/format/TestNonIsoFormatter.java failed in non-english locales. - S8216577: Add GlobalSign's R6 Root certificate - S8218152: [javac] fails and exits with no error if a bad annotation processor provided - S8222136: Remove two Comodo root CA certificates that are expiring - S8222137: Remove T-Systems root CA certificate - S8223555: Cleanups in cacerts tests - S8223664: Add jtreg tests for 8223528, backport to jdk8u of 8176100 -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Thu May 23 03:36:25 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 23 May 2019 04:36:25 +0100 Subject: jdk8u222-b04 tagged Message-ID: I've tagged jdk8u222-b04 locally and will push once tested. Any changes pushed from this point forward will form part of b04. Changes in jdk8u222-b04: - S8158232: PPC64: improve byte, int and long array copy stubs by using VSX instructions - S8190974: Parallel stream execution within a custom ForkJoinPool should obey the parallelism - S8203190: SessionId.hashCode generates too many collisions - S8223499: Remove two DocuSign root certificates that are expiring - S8223883: Fix jni.cpp copyright date after 8223528 -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From adinn at redhat.com Thu May 23 08:34:19 2019 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 23 May 2019 09:34:19 +0100 Subject: [8u] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u In-Reply-To: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com> References: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com> Message-ID: Hi Severin, On 22/05/2019 17:34, Severin Gehwolf wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8222737 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/ > (includes changes to top/hotspot/jdk/langtools repos) > > Example excerpt from a run: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/example_output.txt > > Thoughts? Unfortunately, my makefile fu is too limited to provide a reliable review of the patch (I'm mostly just surprised it took so few changes to achieve). However, I can still wholeheartedly applaud this endeavour and its present outcome. As you say tuning the test group can be done over time as a follow-up. The important thing is to quickly place devs in a position to easily check that fixes have no unintended side-effects. Very nice! 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 sgehwolf at redhat.com Thu May 23 09:53:29 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 23 May 2019 11:53:29 +0200 Subject: [8u] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u In-Reply-To: References: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com> Message-ID: <38f5d5d356e7dba6162ff1cee7752ccebf0aff65.camel@redhat.com> Hi Andrew, On Thu, 2019-05-23 at 09:34 +0100, Andrew Dinn wrote: > Hi Severin, > > On 22/05/2019 17:34, Severin Gehwolf wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222737 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/ > > (includes changes to top/hotspot/jdk/langtools repos) > > > > Example excerpt from a run: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/example_output.txt > > > > Thoughts? > Unfortunately, my makefile fu is too limited to provide a reliable > review of the patch (I'm mostly just surprised it took so few changes to > achieve). However, I can still wholeheartedly applaud this endeavour and > its present outcome. :) Great. > As you say tuning the test group can be done over time as a follow-up. > The important thing is to quickly place devs in a position to easily > check that fixes have no unintended side-effects. Very nice! Thanks for looking this over! Cheers, Severin From hohensee at amazon.com Thu May 23 17:27:24 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 23 May 2019 17:27:24 +0000 Subject: JDK-8048782, which is designated for u222, fixes a bug, but it also introduces a new one. In-Reply-To: <5D3CFC22-12D6-452E-A99E-C51B2D3C3FA3@amazon.com> References: <5D3CFC22-12D6-452E-A99E-C51B2D3C3FA3@amazon.com> Message-ID: <38E6ACB8-B011-4381-ADBB-6F953346AF81@amazon.com> Ping on behalf of David. Our current 8u222 solution would be to revert the patch for https://bugs.openjdk.java.net/browse/JDK-8221166 (which is the 8u222 backport issue for https://bugs.openjdk.java.net/browse/JDK-8048782). Thanks, Paul ?On 5/16/19, 1:28 PM, "jdk8u-dev on behalf of Alvarez, David" wrote: Hi, It has come to our attention that JDK-8048782 [1] can cause Pisces to perform wrong renderings. This patch was originally developed for OpenJDK9, but has now been backported to openjdk8u222, so it has become relevant again. After diving into the issue, it is my understanding that fix was created to solve potential RasterFormatException. That exception occurred by the fact that internally, PiscesCache always works with a bound box one pixel larger than specified, as it can see on its constructor [2]. That slightly larger bbox was exposed outside by the PiscesTileGenerator::getBbox method, and could lead to the RasterFormatException in some scenarios. JDK-8048782 addressed this by ensuring the bbox exposed outside did not contain the additional pixel. Calls to retrieve the bbox will now go to a PiscesCache::getBBox [3] method that removed the extra pixel. However, one thing that was not changed is the PiscesTileGenerator::nextTile method [4]. This method is still accessing the internal value. The new problem happens because now the AAShapePipe::renderTiles works with a different bbox that the PiscesTileGenerator::nextTile. This means that for certain sizes of the bbox (those multiple of 32, the tile size), AAShapePipe may start working with the next row while PiscesTileGenerator still considers we are on the current row. This issue generates patterns like the ones on the attached tile_misalignment.png image. This could be fixed by aligning the PiscesTileGenerator::nextTile method to use the same value for bboxX1 as the one that was exposed outside (removing the extra pixel). Something functionally equivalent to: public void nextTile() { if ((x += TILE_SIZE) >= cache.bboxX1 -1) { x = cache.bboxX0; y += TILE_SIZE; } } However, the part that I haven?t been able to understand is why PiscesCache works with that extra pixel. As far as I can tell, it has always been there, but I've never seen it documented. I assume there was a legitimate reason for that extra pixel to be there, but I don't know why or if it is still relevant. I would love if someone with more knowledge in this area were able to explain it. There seems to be three options here: - Revert JDK-804782, leaving the original RasterFormatException bug. - Address the misalignment by changing the PiscesTileGenerator::nextTile. - If no longer needed, remove the additional pixel in PiscesCache bbox (and reverting JDK-804782, that would no longer be needed) Thanks, David --- [1] https://bugs.openjdk.java.net/browse/JDK-8048782 [2] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/cecd70d27b27/src/share/classes/sun/java2d/pisces/PiscesCache.java#l62 [3] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/d9da27985291/src/share/classes/sun/java2d/pisces/PiscesCache.java#l170 [4] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/d9da27985291/src/share/classes/sun/java2d/pisces/PiscesTileGenerator.java#l135 [5] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/d9da27985291/src/share/classes/sun/java2d/pipe/AAShapePipe.java#l162 From denghui.ddh at alibaba-inc.com Fri May 24 03:36:09 2019 From: denghui.ddh at alibaba-inc.com (DDH) Date: Fri, 24 May 2019 11:36:09 +0800 Subject: =?UTF-8?B?UmU6IFJGUjogODIyMzE0NzogSkZSIEJhY2twb3J0ICh0byBqZGs4dSk=?= Message-ID: Hi Mario?Andrey and all, For current main JFR patch in review, we found here are some unsupported event definitions: ... These events should be removed completly in JDK8u JFR backport. How do you think? Thanks denghui From hohensee at amazon.com Fri May 24 17:09:00 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 24 May 2019 17:09:00 +0000 Subject: [8u-dev] RFA (S): JDK-8210985: Update the default SSL session cache size to 20480 Message-ID: Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8224769 Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8224770 Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8210985 Original CSR: https://bugs.openjdk.java.net/browse/JDK-8213577 Original email thread: http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018168.html Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/8a85d21d9616 Requesting approval for the backport CSR as well as the backport itself. Since this is a backport, I?ve gone with the one-phase CSR approval process and finalized the CSR. Original patch applies cleanly to 8u net of line numbers and file locations. Thanks, Paul From gnu.andrew at redhat.com Fri May 24 18:04:26 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 24 May 2019 19:04:26 +0100 Subject: [8u] RFR: Backport of JDK-8222670: pathological case of JIT recompilation and code cache bloat In-Reply-To: References: <29367C39-36D1-4D17-BEB0-7B7C9D590435@amazon.com> <7DE1A3A6-4BCA-4C35-B992-08281C7A6C8B@amazon.com> <50f562af-6061-73f9-e974-bb3820022c9b@redhat.com> Message-ID: <8167d8dc-3a13-98ad-079f-a859dbb958d2@redhat.com> On 18/05/2019 18:20, Liu, Xin wrote: > Hi, Andrew, > Thanks for review it. Even though it's a backport patch, but the review workload as high as original one. Thanks. > My comments are inline. > > ?On 5/16/19, 11:47 AM, "jdk8u-dev on behalf of Andrew John Hughes" wrote: > > On 16/05/2019 18:23, Liu, Xin wrote: > > Hi, Reviewers, > > > > Could you review this backport patch? > > > > BUG: https://bugs.openjdk.java.net/browse/JDK-8222670 > > Webrev: https://cr.openjdk.java.net/~xliu/8222670/webrev.8u-dev/ > > > > I can?t cleanly apply the original patch to jdk8u. I made the following changes. > > > > 1. Include JDK-8223537. It solved suspend problem in blocking mode. One line change. > > I think this should be applied as a pre-requisite clean backport. Just > flag the bug with jdk8u-fix-request, no need for a separate review. > > I added jdk8u-fix-request for JDK-8223537 > The change can trivially apply on jdk8u-dev. Here is webrev. The order does matter, so let's call it 3/3 patch, or last one. > https://cr.openjdk.java.net/~xliu/8223537/webrev.8u-dev/ Ok, this has jdk8u-fix-yes now. Not sure why the webrev still lists 8222670. > > > 2. Shorter wait period. Otherwise, it?s easy to timeout for the test. It?s part of a JDK-8066770. > > https://cr.openjdk.java.net/~xliu/8222670/webrev.8u-dev/test/compiler/whitebox/CompilerWhiteBoxTest.java.udiff.html > > > > 8066770 relies on a lot of WhiteBox API that is not present in 8u so I'm > ok with including just this segment. > > > 1. +1 for Tier4MinInvocationThreshold and Tier4CompileThreshold. Otherwise, we have to backport JDK-8059604, which looks like complicated. > > > > https://cr.openjdk.java.net/~xliu/8222670/webrev.8u-dev/src/share/vm/prims/whitebox.cpp.udiff.html > > JDK-8059604 looks backportable, but I'm ok with including this commented > workaround for now. >>> > It is backportable. Actually, Paul suggested me do it. > I think it's complicated because JDK-8059604 is only part of campaign(JDK-8050853). Taking 8059604 alone to jdk8u seems not be very useful. > Further, I can't evaluate how much impact of changing thresholds from > to >= here. > https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ffe9c8c82350#l5.9 > > I'd like to +1 in whitebox.cpp because it's just a fixture of testing. It won't have runtime risk. Yes, I agree; do this for now and maybe look at that later. > > There seem to be two other changes being included here: > > 1. compileBroker.cpp changes > > These aren't in the original JDK-8222670. In 9, the != NULL test is > added by "8144964: JVMCI compilations need to be disabled until the > module system is initialized". 8 has neither JVMCI or a module system, > so not sure why this test is being added here. Why is this included? >>> > I do need the "task != NULL" protection here. Otherwise, remove(NULL/*task*/); will cash JVM. > If duplication happens , this patch will ditch the task from select_task and return NULL. > > For JDK-8144964, it?s all about JVMCI. That's why I don't want to backport it. Yes, I wasn't suggesting to do so, I just wondered why it was needed. Thanks for clarifying. > > > 2. skiponTieredCompilation in CompilerWhiteBoxTest.java > > This is part of "8059575: JEP-JDK-8043304: Test task: Tiered Compilation > level transition tests" which should also be backported as a pre-requisite. >>> > I backported 8059575 to jdk8u-dev. It's the 1/3 patch, or the first one to apply. > Here is webrev: https://cr.openjdk.java.net/~xliu/8059575/webrev.01/ > > I was wrong at JDK-8059575. It need to polish a little bit to pass all tests. > Here is my change: > 1) add compile_id in NMethod.java. > I got lost from here. > https://hg.openjdk.java.net/jdk9/jdk9/rev/c82ea5393dda That file move obscures things and I think it silently does include the addition of 'final'. The additions to whitebox.cpp & NMethod.java to add compile_id come from JDK-8054492. In both cases though, it's needed for the test, not the actual fix. So whether you want to backport this as well is up to you. It adds a Class.cast intrinsic. > 2) modify @library for LevelTransitionTest.java and ConstantGettersTransitionsTest.java. > It's because auxiliary library locates differently. That's follows from not having the file movement that takes place in 8066433, 8067223 & 8067337 which look odd now they are in the single jdk repository, but previously involved two repositories. The problems you see with tracking the history are because the files were added again in one changeset (to the root repository) and then the other copies removed in another changeset. I don't think we need to do that move as the only JDK test that currently uses whitebox is test/jdk/java/lang/ref/CleanerTest.java and java.lang.ref.Cleaner is part of the Java 9 API. So I'm fine with just changing @library. > > > > Thanks, > > --lx > > > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew > > > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Fri May 24 18:16:41 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 24 May 2019 19:16:41 +0100 Subject: [8u-dev] RFA (S): JDK-8210985: Update the default SSL session cache size to 20480 In-Reply-To: References: Message-ID: On 24/05/2019 18:09, Hohensee, Paul wrote: > Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8224769 > Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8224770 > > Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8210985 > Original CSR: https://bugs.openjdk.java.net/browse/JDK-8213577 > Original email thread: http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018168.html > Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/8a85d21d9616 > > Requesting approval for the backport CSR as well as the backport itself. Since this is a backport, I?ve gone with the one-phase CSR approval process and finalized the CSR. > > Original patch applies cleanly to 8u net of line numbers and file locations. > > Thanks, > > Paul > There's no jdk8u-fix-request on the bug. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From martijnverburg at gmail.com Fri May 24 18:32:22 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Fri, 24 May 2019 20:32:22 +0200 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: <20190521071343.6ziavswihvxjtcuf@kelvin.aketzu.net> References: <20190520164715.b63rhopjn2f7czfy@kelvin.aketzu.net> <20190521071343.6ziavswihvxjtcuf@kelvin.aketzu.net> Message-ID: Hi all, Discussions are now happening over on the debian-java mailing list, they're going to make this 'right' and we're exploring ways to make sure it doesn't regress, thanks folks for bringing this up and Aleksey for kicking off the thread over there. Cheers, Martijn On Tue, 21 May 2019 at 09:14, Anssi Kolehmainen wrote: > On Tue, May 21, 2019 at 02:51:12AM +0100, Andrew John Hughes wrote: > >On 20/05/2019 17:47, Anssi Kolehmainen wrote: > >> Google openjdk, go to openjdk.java.net, on frontpage click install. > >> Instructions say "sudo apt-get install openjdk-8-jre" which then > >> installs 8u212-b01. Success! > >> > >> Go back to frontpage, click on "here" (as in Oracle builds), see only > >> "8u212", > >> don't want to do read through EULA so go back to openjdk frontpage. > >> > >> Go through the tiny left navbar, click on "JDK 8"... This talks about > >> 2014 so bummer. > > > >This content is controlled by Oracle, so sadly we can't change any of > >it. I certainly don't think non-OpenJDK builds should be listed on the > >front page. However, you do omit the link between those two which > >directs to jdk.java.net/12 and OpenJDK builds of the latest OpenJDK > release. > > Yeah... What I want to do is to get Java on the machine, be it Debian, > RHEL, > Windows or whatever. Currently OpenJDK web looks like everything is just > JDK 12 > and others are "too old". Sadly the other products (e.g. Payara) have not > caught up with the new Java release speed so JDK 8 it must be. > > I basically must figure out somewhere else that what I really want is > AdoptOpenJDK or Azul and not "OpenJDK" itself. > > (Oracle JDK is basically out of question after latest license change.) > > >> "Consult Wiki for details". > >> Font gets even tinier but I keep glancing. Releases list "Latest: 8u212" > >> but only "GA" as build number. Click on "tag" which goes to hg[1] "Added > >> tag jdk8u212-b02"... Success! > >> [1]: http://hg.openjdk.java.net/jdk8u/jdk8u/rev/5218ef8ea6c3 > >> > >> Click on "Released", get to Github AdoptOpenJDK releases. Title says > >> "8u212 GA" but thankfully tag shows "8u212-b03". > > > >We can revise these, so suggestions welcome. I'm not sure about changing > >the text size on the wiki, but I agree I also find it rather on the > >small side. > > On a general level what I usually look is the current version, when it was > released and what was changed (major points, incompatibilities). Also > sometimes > version history that when some old version was released. > > On release notes level GitLab does pretty good job > https://about.gitlab.com/2019/04/22/gitlab-11-10-released/ > > Something like Payara might be better fit for JDK releases > https://www.payara.fish/software/release-notes/ > .. which is pretty much what the release announcement mailing list post > looks > like. But it's "hidden" behind so many clicks. > > It would be really nice to be able edit also the openjdk.java.net > frontpage so > there would be more direct links to relevant parts. > > For version history something like: > https://en.wikipedia.org/wiki/.NET_Framework#Release_history > > https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Version_history_and_timeline > > So there would be list of all releases and links to their release postings. > For example if I want to check 8u202 release details I go to archive page > which > has basically nothing. Was there a release posting about it? > > AdoptOpenJDK GitHub page lists 8u202-b08 as release version. Debian has > packaged 8u202-b26. > > Oracle just makes my head hurt every time :) > > >> It would be really much better if version number would include > >> beta/pre/EA in the prereleases or then GA in the final version. > > > >Where do you mean? > > In the version number itself... > > So instead of > OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1~deb9u1-b01) > it would be > OpenJDK Runtime Environment (build 1.8.0_212-8u212-pre01-1~deb9u1-pre01) > > Then it would hopefully be more clear that "this version is not suitable > for > general use". > > -- > Anssi Kolehmainen > anssi.kolehmainen at iki.fi > 040-5085390 > From hohensee at amazon.com Fri May 24 20:26:38 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 24 May 2019 20:26:38 +0000 Subject: [8u-dev] RFA (S): JDK-8210985: Update the default SSL session cache size to 20480 In-Reply-To: References: Message-ID: Added. I was waiting on CSR approval, but Joe Darcy noted that we're not using CSRs for 8u, which I hadn't known (or had forgot!). Thanks, Paul ?On 5/24/19, 11:18 AM, "jdk8u-dev on behalf of Andrew John Hughes" wrote: On 24/05/2019 18:09, Hohensee, Paul wrote: > Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8224769 > Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8224770 > > Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8210985 > Original CSR: https://bugs.openjdk.java.net/browse/JDK-8213577 > Original email thread: http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018168.html > Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/8a85d21d9616 > > Requesting approval for the backport CSR as well as the backport itself. Since this is a backport, I?ve gone with the one-phase CSR approval process and finalized the CSR. > > Original patch applies cleanly to 8u net of line numbers and file locations. > > Thanks, > > Paul > There's no jdk8u-fix-request on the bug. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Fri May 24 21:21:24 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 24 May 2019 22:21:24 +0100 Subject: [8u-dev] RFA (S): JDK-8210985: Update the default SSL session cache size to 20480 In-Reply-To: References: Message-ID: On 24/05/2019 21:26, Hohensee, Paul wrote: > Added. I was waiting on CSR approval, but Joe Darcy noted that we're not using CSRs for 8u, which I hadn't known (or had forgot!). > > Thanks, > > Paul > I didn't know either, and was actually wondering what I was meant to approve here. As far as I could gather from the CSR page, it had already been approved by being in the "Finalized" state. Are CSRs an Oracle thing? I'm not sure how they even fit in with the non-Oracle run projects. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From hohensee at amazon.com Fri May 24 21:55:00 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 24 May 2019 21:55:00 +0000 Subject: [8u-dev] RFA (S): JDK-8210985: Update the default SSL session cache size to 20480 In-Reply-To: References: Message-ID: <06A96C44-3C2F-4135-B2BE-F8C1A14C6A93@amazon.com> CSRs are definitely an Oracle thing. See https://wiki.openjdk.java.net/display/csr/Main. At Oracle, if you want to change an interface or behavior, you file a JBS issue to do the work, then file a CSR to get approval for the interface change. Closing a CSR == approving it. Finalized state means it's ready for review. One is supposed to get consensus before finalizing a CSR. If a backport involved a CSR, Oracle used to want a backport CSR, so the process was and maybe is: create a backport JBS issue, then a CSR for the backport issue, get the CSR approved, then get the backport approved. I don't know what Oracle's CSR backport process is now, but somehow I was under the impression that I should follow it. :) We could use Oracle's process for 8u and 11u, though it's a bit heavy-weight. It does have the advantage of thoroughly documenting interface/behavior changes in backports. I'm not sure who would do the backport CSR approvals: probably the Maintainers. I was incorrect/hasty about 8u clean patch application. 8u doesn't have SSLLogger, so that code gets dropped from SSLSessionContextImpl.getDefaultCacheLimit(). 8u webrev: http://cr.openjdk.java.net/~phh/8210985/webrev.8u.00/ The included test passes. Thanks, Paul ?On 5/24/19, 2:22 PM, "Andrew John Hughes" wrote: On 24/05/2019 21:26, Hohensee, Paul wrote: > Added. I was waiting on CSR approval, but Joe Darcy noted that we're not using CSRs for 8u, which I hadn't known (or had forgot!). > > Thanks, > > Paul > I didn't know either, and was actually wondering what I was meant to approve here. As far as I could gather from the CSR page, it had already been approved by being in the "Finalized" state. Are CSRs an Oracle thing? I'm not sure how they even fit in with the non-Oracle run projects. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From aph at redhat.com Sat May 25 13:10:02 2019 From: aph at redhat.com (Andrew Haley) Date: Sat, 25 May 2019 14:10:02 +0100 Subject: Delay 8u Rampdown Message-ID: We have a few (about 20) bugs still open for jdk8u. Rampdown is scheduled to begin on Wednesday, May 29th. All of the bugs are assigned to people, and I don't expect them to take long. Monday is Memorial Day in the USA and may Bank Holiday in the UK. Rather than put everything through the critical-bug-triage process I think we should delay the onset of 8u rampdown by a couple of days. If there are any bugs still outstanding by Friday they'll have to go through triage. Comments? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Sat May 25 13:40:08 2019 From: aph at redhat.com (Andrew Haley) Date: Sat, 25 May 2019 14:40:08 +0100 Subject: [8u-dev] RFA (S): JDK-8210985: Update the default SSL session cache size to 20480 In-Reply-To: References: Message-ID: On 5/24/19 9:26 PM, Hohensee, Paul wrote: > Added. I was waiting on CSR approval, but Joe Darcy noted that we're > not using CSRs for 8u, which I hadn't known (or had forgot!). I thought I'd asked Joe Darcy (in Brussels) whether we could use CSRs for 8u, and he'd said yes. Now I am very confused. Surely we need the CSR process. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From doko at ubuntu.com Sun May 26 22:25:05 2019 From: doko at ubuntu.com (Matthias Klose) Date: Mon, 27 May 2019 00:25:05 +0200 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> Message-ID: I am disappointed to see such trolling, bashing and telling fake news on a technical mailing list. Is this Azul's business model to promote their own binary builds? Such behavior propagates e.g. via twitter https://twitter.com/jroper/status/1130678379403857920 I'm starting the discussion about version numbers and release information in a new thread. I am neither involved with any Docker image nor with any Debian backport. Debian provides security support for its stable release (stretch, 9.x). openjdk-11 isn't part of any released Debian version. Ubuntu ships openjdk-8 as a supported package in Ubuntu 16.04 LTS and is committed to provide security support for openjdk-8 in Ubuntu 18.04 LTS until the EOL of Ubuntu 16.04 LTS (around April 2021). Ubuntu 18.04 LTS initially shipped with OpenJDK 10 with the commitment to update to OpenJDK 11 which now is available in the Ubuntu 18.04 LTS release (in the security pocket). There is no mystery meat, just security supported uploads for both Debian and Ubuntu. On 15.05.19 20:49, Gil Tene wrote: > Umm? > > Lumpy.local-43% docker run -it --rm openjdk:8 java -version > openjdk version "1.8.0_212" > OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1~deb9u1-b01) > OpenJDK 64-Bit Server VM (build 25.212-b01, mixed mode) > Lumpy.local-44% date > Wed May 15 11:41:12 PDT 2019 > > Look at the build number carefully? This was populated no later > than March 27, 2019. 3 weeks before the actual 8u212 was released > on April 16, 2019. The Debian openjdk-8 source package is put together from the jdk8u, aarch64-port/jdk8u-shenandoah and aarch32-port/jdk8u projects. Certainly not ideal, however these packages can only be made if all the sources are available, or tagged. I am happy to see that the aarch64-port tries to keep up with the jdk8u project however this is a different story with the aarch32-port project: The project doesn't have *any* prerelease tags, plus the project updates it's release tags only months after the jdk8u releases. So blaming Debian for shipping what they are able to ship and Azul holding back source releases yourself? Ein Schelm wer B?ses dabei denkt ... > Similarly: > > Lumpy.local-46% docker run -it --rm openjdk:11 java -version > openjdk version "11.0.3" 2019-04-16 > OpenJDK Runtime Environment (build 11.0.3+1-Debian-1bpo91) > OpenJDK 64-Bit Server VM (build 11.0.3+1-Debian-1bpo91, mixed mode, sharing) > Lumpy.local-47% date > Wed May 15 11:43:12 PDT 2019 > > This one was populate dno later than April 3, 2 weeks before > the actual 11.0.3 was released on April 16, 2019 > > If anyone was wondering about the importance of having version strings say > "EA" (or some other "THIS IS NOT a RELEASED VERSION" warning) on any > and all OpenJDK builds that are not an actual release build, the above shows > you how bad things get when that practice is not followed. Don't trust the label, just the content. I agree that the java community is much more label/version driven, however this is not a reason to discredit other sane builds. > Why Debian populated their repos with these builds is their business, and > why docker chose to use those specific debian builds can be speculated > about all we want. the details don't matter. The end result of these > cumulative "reasonable" (according to some people) choices is that the > default openjdk runs done by millions of people on docker right now are > using "mystery meat", incomplete, and exposed builds while seeming to > report (to the lay person) a Java version that would suggest a real 8u212 > or 11.0.3 (which one would expect has the security vulnerabilities in the > April update addressed, the bug fixes included, etc.). Again, I see this as an advertising or promotion email for the Azul binary builds. Fine, do so. Both please use marketing lists and not the OpenJDK technical lists. Matthias From gil at azul.com Sun May 26 23:41:07 2019 From: gil at azul.com (Gil Tene) Date: Sun, 26 May 2019 23:41:07 +0000 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com>, Message-ID: <8FB70808-E4E0-451C-AC86-C9EA1EA2FA30@azul.com> Seriously? You see factual reporting (directly documented and dated in the original posting) of the actual version numbers being used by official docker images, along with irrefutable proof that the packages used in those were built weeks before the respective OpenJDK 8u and 11u releases were complete, as ?fake news?? You think that alerting millions of unsuspecting people using exposed, insecure builds that falsely report their OpenJDK version (as one that includes e.g. critical security fixes) to the fact as ?marketing?? And you consider pleas to use responsibly built and tested OpenJDK builds, with no mention of any vendor name at all, ?trolling?? This (the specific things documented at the start of this thread) was absolutely Mystery Meat masquerading as an actual release OpenJDK. Facts are facts. Blaming the messager and trying to attribute commercial motives to the calling out of inconvenient truths is a way of dealing with reality. Sent from Gil's iPhone > On May 26, 2019, at 3:25 PM, Matthias Klose wrote: > > I am disappointed to see such trolling, bashing and telling fake news on a > technical mailing list. Is this Azul's business model to promote their own > binary builds? > > Such behavior propagates e.g. via twitter > https://twitter.com/jroper/status/1130678379403857920 > > I'm starting the discussion about version numbers and release information in a > new thread. > > I am neither involved with any Docker image nor with any Debian backport. > > Debian provides security support for its stable release (stretch, 9.x). > openjdk-11 isn't part of any released Debian version. > > Ubuntu ships openjdk-8 as a supported package in Ubuntu 16.04 LTS and is > committed to provide security support for openjdk-8 in Ubuntu 18.04 LTS until > the EOL of Ubuntu 16.04 LTS (around April 2021). > > Ubuntu 18.04 LTS initially shipped with OpenJDK 10 with the commitment to update > to OpenJDK 11 which now is available in the Ubuntu 18.04 LTS release (in the > security pocket). > > There is no mystery meat, just security supported uploads for both Debian and > Ubuntu. > >> On 15.05.19 20:49, Gil Tene wrote: >> Umm? >> >> Lumpy.local-43% docker run -it --rm openjdk:8 java -version >> openjdk version "1.8.0_212" >> OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1~deb9u1-b01) >> OpenJDK 64-Bit Server VM (build 25.212-b01, mixed mode) >> Lumpy.local-44% date >> Wed May 15 11:41:12 PDT 2019 >> >> Look at the build number carefully? This was populated no later >> than March 27, 2019. 3 weeks before the actual 8u212 was released >> on April 16, 2019. > > The Debian openjdk-8 source package is put together from the jdk8u, > aarch64-port/jdk8u-shenandoah and aarch32-port/jdk8u projects. Certainly not > ideal, however these packages can only be made if all the sources are available, > or tagged. > > I am happy to see that the aarch64-port tries to keep up with the jdk8u project > however this is a different story with the aarch32-port project: The project > doesn't have *any* prerelease tags, plus the project updates it's release tags > only months after the jdk8u releases. So blaming Debian for shipping what they > are able to ship and Azul holding back source releases yourself? Ein Schelm > wer B?ses dabei denkt ... > >> Similarly: >> >> Lumpy.local-46% docker run -it --rm openjdk:11 java -version >> openjdk version "11.0.3" 2019-04-16 >> OpenJDK Runtime Environment (build 11.0.3+1-Debian-1bpo91) >> OpenJDK 64-Bit Server VM (build 11.0.3+1-Debian-1bpo91, mixed mode, sharing) >> Lumpy.local-47% date >> Wed May 15 11:43:12 PDT 2019 >> >> This one was populate dno later than April 3, 2 weeks before >> the actual 11.0.3 was released on April 16, 2019 >> >> If anyone was wondering about the importance of having version strings say >> "EA" (or some other "THIS IS NOT a RELEASED VERSION" warning) on any >> and all OpenJDK builds that are not an actual release build, the above shows >> you how bad things get when that practice is not followed. > > Don't trust the label, just the content. I agree that the java community is > much more label/version driven, however this is not a reason to discredit other > sane builds. > >> Why Debian populated their repos with these builds is their business, and >> why docker chose to use those specific debian builds can be speculated >> about all we want. the details don't matter. The end result of these >> cumulative "reasonable" (according to some people) choices is that the >> default openjdk runs done by millions of people on docker right now are >> using "mystery meat", incomplete, and exposed builds while seeming to >> report (to the lay person) a Java version that would suggest a real 8u212 >> or 11.0.3 (which one would expect has the security vulnerabilities in the >> April update addressed, the bug fixes included, etc.). > > Again, I see this as an advertising or promotion email for the Azul binary > builds. Fine, do so. Both please use marketing lists and not the OpenJDK > technical lists. > > Matthias From gil at azul.com Mon May 27 01:24:58 2019 From: gil at azul.com (Gil Tene) Date: Mon, 27 May 2019 01:24:58 +0000 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> Message-ID: <5491A2A5-32D1-42D9-99E4-2ACE2927C9FD@azul.com> > On May 26, 2019, at 3:25 PM, Matthias Klose wrote: > > I am disappointed to see such trolling, bashing and telling fake news on a > technical mailing list. Is this Azul's business model to promote their own > binary builds? > > Such behavior propagates e.g. via twitter > https://twitter.com/jroper/status/1130678379403857920 > > I'm starting the discussion about version numbers and release information in a > new thread. > > I am neither involved with any Docker image nor with any Debian backport. > > Debian provides security support for its stable release (stretch, 9.x). > openjdk-11 isn't part of any released Debian version. > > Ubuntu ships openjdk-8 as a supported package in Ubuntu 16.04 LTS and is > committed to provide security support for openjdk-8 in Ubuntu 18.04 LTS until > the EOL of Ubuntu 16.04 LTS (around April 2021). > > Ubuntu 18.04 LTS initially shipped with OpenJDK 10 with the commitment to update > to OpenJDK 11 which now is available in the Ubuntu 18.04 LTS release (in the > security pocket). > > There is no mystery meat, just security supported uploads for both Debian and > Ubuntu. With such an emphatic attack on the motives associated with the original posting on this thread, I tried to figure out what might lead someone to take that path. I can attribute one of few possible logic paths that may lead you to making the above argument: a) You never bothered to check any of the actual facts posted, and just assumed the original posting was fake news. b) You did check the facts, but read the output wrong (like most people in the world would have, since the scary details behind the specific 8u212 and 11.0.3 builds involved need some digging to figure out), and somehow assumed that the thing reporting e.g. 'openjdk version "1.8.0_212"' was a good (non-Mystery-Meat) build of the released version being reported. c) You know the facts, but want others to think someone else is wrong for pointing them out, and go about doing that by trying to associate as many negative motives as you can muster ("trolling", "bashing", "fake news", "marketing", "business model", "advertising", "promotion", all of which you had literally used in this one e-mail) to the factual posting at the top of this tread. d) You think the facts posted, even when true, do not amount to the associated builds deserving to be called Mystery Meat. So let's quickly dispense the first two possibilities: If the benefit of the doubt for not actually realizing the truth of the situation, and the accuracy of the contents of the original e-mail is deserved, and you wrongly called this stuff "fake news", go ahead and check on the facts and come back to us with a correction. But somehow (see below), I doubt that (a) or (b) explain your misrepresentation of facts in this e-mail. I doubt that the original e-mail in this thread could have been much more clear or specific in documenting the actual Mystery Meat situation in the wild on the date it was posted. Thankfully, the Official Docker openjdk images has since fixed their official builds to no longer present docker users with images containing faulty, Mystery Meat 8u212 and 11.0.3 OpenJDK versions. However, there seem to be plenty of people (you included, clearly, per this very e-mail) who are trying to argue that the builds themselves are not a problem, that it is the lack of education or understanding of the end-user that is responsible, etc. Many of these arguments have taken a deflection approach of e.g. focusing on OpenJDK 11, combined with something like "the good, stable, meant-for-actual-use, security-supported version of Debian (debian stretrch, 9.x per the above) does not provide openjdk-11, and some irresponsible middle-person act of taking mislabeled builds from other repos (e.g. backports, unstable, etc.) is to blame. Fine, let's go with that for just a minute. Ignore the fact that the original posting was about the end-result (and specifically stated "Why Debian populated their repos with these builds is their business") and ignore the impact on OpenJDK 11. Just for a minute. Let's focus on the OpenJDK 8 part, and let's test the facts, *today*, and limit our testing to the stable, "security supported uploads" in Debian stretch: We still end up staring at this very inconvenient truth: OpenJDK 8, Debian (stable, stretch, 9), and the current situation (two weeks into being alerted to it) show the following right now: root at 020dc36b9046:/# root at 020dc36b9046:/# date Sun May 26 23:55:45 UTC 2019 root at 020dc36b9046:/# root at 020dc36b9046:/# cat /etc/os-release PRETTY_NAME="Debian GNU/Linux 9 (stretch)" NAME="Debian GNU/Linux" VERSION_ID="9" VERSION="9 (stretch)" ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/" root at 020dc36b9046:/# root at 020dc36b9046:/# apt-get update Ign:2 http://cdn-fastly.deb.debian.org/debian stable InRelease Hit:1 http://security-cdn.debian.org/debian-security stable/updates InRelease Hit:3 http://cdn-fastly.deb.debian.org/debian stable-updates InRelease Hit:4 http://cdn-fastly.deb.debian.org/debian stable Release Reading package lists... Done root at 020dc36b9046:/# root at 020dc36b9046:/# apt-get install openjdk-8-jdk ... root at 020dc36b9046:/# root at 020dc36b9046:/# java -version openjdk version "1.8.0_212" OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1~deb9u1-b01) OpenJDK 64-Bit Server VM (build 25.212-b01, mixed mode) root at 020dc36b9046:/# To be clear on what ?build 1.8.0_212-8u212-b01-1~deb9u1-b01" in the above tracks to, we can track it in https://tracker.debian.org/pkg/openjdk-8 , which has this convenient log for when the build was created (March 29, 2019, 3 weeks prior to the actual release of 8u212 by the OpenJDK 8u project): ? [2019-04-06] openjdk-8 REMOVED from testing (Debian testing watch) ? [2019-03-30] Removed 8u212-b01-1 from unstable (Debian FTP Masters) ? [2019-03-30] Removed 8u144-b01-2 from unstable (Debian FTP Masters) ? [2019-03-30] Removed 8u141-b15-3 from unstable (Debian FTP Masters) ? [2019-03-29] openjdk-8 8u212-b01-1 MIGRATED to testing (Debian testing watch) ? [2019-03-29] Accepted openjdk-8 8u212-b01-1~deb9u1 (source amd64 all) into proposed-updates->stable-new, proposed-updates (Moritz Muehlenhoff) (signed by: Moritz M?hlenhoff) ? [2019-03-20] Accepted openjdk-8 8u212-b01-1~deb9u1 (source amd64 all) into stable->embargoed, stable(Moritz Muehlenhoff) (signed by: Moritz M?hlenhoff) ? [2019-03-19] Accepted openjdk-8 8u212-b01-1 (source) into unstable (Matthias Klose) [The fact that your name is on the actual log items above makes it unlikely that options (a) or (b) above apply. It's pretty clearly (c) and/or (d).] So what do we have here? A mislabeled (' openjdk version "1.8.0_212" ', no disqualifiers, early access, or "danger, this is not really 8u212" labeled anywhere), fell off the truck (actually built from sources picked up at a random weekly tag point, 3 weeks prior to the actual 8u212 release was complete, and missing a multitude of bug fixes and security fixes that are in the actual 8u212 release), build of OpenJDK "8u212" is being delivered in the current, stable, debian release from default repositories. Not the unstable repos, not the backports repos, not by some other version's repos, not by some middle-men. You may not think that "Mystery Meat" is a good label for this very situation. But I suspect that would put you in the tiny minority of people who believe or argue that all meat, from all sources, is equally untrustworthy. And that labels, cleanliness, use-by-dates, and (most importantly) reputation for label accuracy and trustworthiness should not affect people's consumption choices. That's what is going on right now. Arguing that someone else is to blame doesn't change it. Arguing that "the media" is against you and has nefarious motives doesn't either. And arguing that "this is fine, and it is what users of "stable" Debian should expect", well, that just tells them what to expect, I guess. > > On 15.05.19 20:49, Gil Tene wrote: >> Umm? >> >> Lumpy.local-43% docker run -it --rm openjdk:8 java -version >> openjdk version "1.8.0_212" >> OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1~deb9u1-b01) >> OpenJDK 64-Bit Server VM (build 25.212-b01, mixed mode) >> Lumpy.local-44% date >> Wed May 15 11:41:12 PDT 2019 >> >> Look at the build number carefully? This was populated no later >> than March 27, 2019. 3 weeks before the actual 8u212 was released >> on April 16, 2019. > > The Debian openjdk-8 source package is put together from the jdk8u, > aarch64-port/jdk8u-shenandoah and aarch32-port/jdk8u projects. Certainly not > ideal, however these packages can only be made if all the sources are available, > or tagged. > > I am happy to see that the aarch64-port tries to keep up with the jdk8u project > however this is a different story with the aarch32-port project: The project > doesn't have *any* prerelease tags, plus the project updates it's release tags > only months after the jdk8u releases. So blaming Debian for shipping what they > are able to ship and Azul holding back source releases yourself? Ein Schelm > wer B?ses dabei denkt ... > >> Similarly: >> >> Lumpy.local-46% docker run -it --rm openjdk:11 java -version >> openjdk version "11.0.3" 2019-04-16 >> OpenJDK Runtime Environment (build 11.0.3+1-Debian-1bpo91) >> OpenJDK 64-Bit Server VM (build 11.0.3+1-Debian-1bpo91, mixed mode, sharing) >> Lumpy.local-47% date >> Wed May 15 11:43:12 PDT 2019 >> >> This one was populate dno later than April 3, 2 weeks before >> the actual 11.0.3 was released on April 16, 2019 >> >> If anyone was wondering about the importance of having version strings say >> "EA" (or some other "THIS IS NOT a RELEASED VERSION" warning) on any >> and all OpenJDK builds that are not an actual release build, the above shows >> you how bad things get when that practice is not followed. > > Don't trust the label, just the content. I agree that the java community is > much more label/version driven, however this is not a reason to discredit other > sane builds. > >> Why Debian populated their repos with these builds is their business, and >> why docker chose to use those specific debian builds can be speculated >> about all we want. the details don't matter. The end result of these >> cumulative "reasonable" (according to some people) choices is that the >> default openjdk runs done by millions of people on docker right now are >> using "mystery meat", incomplete, and exposed builds while seeming to >> report (to the lay person) a Java version that would suggest a real 8u212 >> or 11.0.3 (which one would expect has the security vulnerabilities in the >> April update addressed, the bug fixes included, etc.). > > Again, I see this as an advertising or promotion email for the Azul binary > builds. Fine, do so. Both please use marketing lists and not the OpenJDK > technical lists. > > Matthias From christoph.langer at sap.com Mon May 27 06:38:10 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 27 May 2019 06:38:10 +0000 Subject: Delay 8u Rampdown In-Reply-To: References: Message-ID: Sounds reasonable. I guess for the next release we should aim to have these backport items finished earlier though. Best regards Christoph > -----Original Message----- > From: jdk8u-dev On Behalf Of > Andrew Haley > Sent: Samstag, 25. Mai 2019 15:10 > To: jdk8u-dev at openjdk.java.net > Subject: Delay 8u Rampdown > > We have a few (about 20) bugs still open for jdk8u. Rampdown is > scheduled to begin on Wednesday, May 29th. All of the bugs are > assigned to people, and I don't expect them to take long. > > Monday is Memorial Day in the USA and may Bank Holiday in the UK. > Rather than put everything through the critical-bug-triage process I > think we should delay the onset of 8u rampdown by a couple of days. > If there are any bugs still outstanding by Friday they'll have to go > through triage. > > Comments? > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Mon May 27 06:56:30 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 27 May 2019 06:56:30 +0000 Subject: [8u-dev] RFA (S): JDK-8210985: Update the default SSL session cache size to 20480 In-Reply-To: References: Message-ID: Hi, I did also wonder. We have definitely used the CSR process for JDK11u already, see this item: https://bugs.openjdk.java.net/browse/JDK-8220362 Process wise I was told by Joe to use 11-pool as version number and largely copy&paste the upstream CSR as it applies. Then it would undergo the usual review procedure. That way we'd probably share the CSRs with Oracle for 11 updates. @aph, can you clearify this for both, 11u and 8u with Joe Darcy? Thanks Christoph > -----Original Message----- > From: jdk8u-dev On Behalf Of > Andrew Haley > Sent: Samstag, 25. Mai 2019 15:40 > To: Hohensee, Paul ; Andrew John Hughes > ; jdk8u-dev at openjdk.java.net > Subject: Re: [8u-dev] RFA (S): JDK-8210985: Update the default SSL session > cache size to 20480 > > On 5/24/19 9:26 PM, Hohensee, Paul wrote: > > > Added. I was waiting on CSR approval, but Joe Darcy noted that we're > > not using CSRs for 8u, which I hadn't known (or had forgot!). > > I thought I'd asked Joe Darcy (in Brussels) whether we could use CSRs > for 8u, and he'd said yes. Now I am very confused. Surely we need the > CSR process. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From OGATAK at jp.ibm.com Mon May 27 09:06:04 2019 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Mon, 27 May 2019 18:06:04 +0900 Subject: [8u-dev, ppc] RFR for (almost clean) backport of 8185696: PPC64: Improve VSR support to use up to 64 registers Message-ID: Hi, I'm requesting backport of 8185696: PPC64: Improve VSR support to use up to 64 registers to jdk8u-dev. This patch can be applied almost cleanly, but one chunk failed (other than a copyright year conflict) because the definition of MTVSRWA_OPCODE is missing in src/cpu/ppc/vm/assembler_ppc.hpp. MTVSRWA_OPCODE was added in 8144019: PPC64 C1: Introduce Client Compiler [1], which added tiered compilation feature in JDK9. Since JDK8 does not support tiered compilation, we cannot apply this change set. So I manually applied the failed chunk by skipping the MTVSRWA_OPCODE definition because no code in this changeset and other changesets I'm going to backport uses this opcode. I'll leave it to the future backport that really needs this opcode. Is this fix acceptable for backport request? If there is no objection in a few days, I'll go forward to add jdk8u-fix-request tag in the original bug report. I verified I can build both fastdebug and release version, and no degradation in jtreg. Original bug report: https://bugs.openjdk.java.net/browse/JDK-8185969 Webrev: http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8185969/webrev.02/ Refs: [1] https://bugs.openjdk.java.net/browse/JDK-8144019 From fweimer at redhat.com Mon May 27 10:13:12 2019 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 27 May 2019 12:13:12 +0200 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: <5491A2A5-32D1-42D9-99E4-2ACE2927C9FD@azul.com> (Gil Tene's message of "Mon, 27 May 2019 01:24:58 +0000") References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> <5491A2A5-32D1-42D9-99E4-2ACE2927C9FD@azul.com> Message-ID: <875zpwkxxj.fsf@oldenburg2.str.redhat.com> * Gil Tene: > root at 020dc36b9046:/# java -version > openjdk version "1.8.0_212" > OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1~deb9u1-b01) > OpenJDK 64-Bit Server VM (build 25.212-b01, mixed mode) > root at 020dc36b9046:/# I wonder if the core technical issue is this: Debian stretch currently packages OpenJDK 8 8u212-b01, when it should be packaging 8u212-b03 or 8u212-b04 (which one isn't clear, the release announcement was for 8u212-b03, not for 8u212-b04 or 8u212-ga). My understanding is that 8u212-b01 is a version identifier created by the jdk8u project, and based on a quick check, it matches what Debian identifies as its upstream sources (except for some stripping of system library components). But it's not the most current release. Thanks, Florian From martijnverburg at gmail.com Mon May 27 10:19:13 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 27 May 2019 11:19:13 +0100 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: <875zpwkxxj.fsf@oldenburg2.str.redhat.com> References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> <5491A2A5-32D1-42D9-99E4-2ACE2927C9FD@azul.com> <875zpwkxxj.fsf@oldenburg2.str.redhat.com> Message-ID: On Mon, 27 May 2019 at 11:13, Florian Weimer wrote: > * Gil Tene: > > > root at 020dc36b9046:/# java -version > > openjdk version "1.8.0_212" > > OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1~deb9u1-b01) > > OpenJDK 64-Bit Server VM (build 25.212-b01, mixed mode) > > root at 020dc36b9046:/# > > I wonder if the core technical issue is this: Debian stretch currently > packages OpenJDK 8 8u212-b01, when it should be packaging 8u212-b03 or > 8u212-b04 (which one isn't clear, the release announcement > > was for 8u212-b03, not for 8u212-b04 or 8u212-ga). > > My understanding is that 8u212-b01 is a version identifier created by > the jdk8u project, and based on a quick check, it matches what Debian > identifies as its upstream sources (except for some stripping of system > library components). But it's not the most current release. > It's one of the challenges, the rest of the world doesn't necessarily know about the new `-ga` tag that we use to designate releases, so we need to go and help them. I've also replied separately to this thread (with a meeting request) but cut out the OpenJDK mailing lists as it's really the Debian distro list that we should be discussing this on. If folks feel otherwise, let me know and I'll CC these lists back in. Cheers, Martijn > > Thanks, > Florian > From fweimer at redhat.com Mon May 27 10:39:12 2019 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 27 May 2019 12:39:12 +0200 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: (Martijn Verburg's message of "Mon, 27 May 2019 11:19:13 +0100") References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> <5491A2A5-32D1-42D9-99E4-2ACE2927C9FD@azul.com> <875zpwkxxj.fsf@oldenburg2.str.redhat.com> Message-ID: <871s0kkwq7.fsf@oldenburg2.str.redhat.com> * Martijn Verburg: > On Mon, 27 May 2019 at 11:13, Florian Weimer wrote: > > * Gil Tene: > > > root at 020dc36b9046:/# java -version > > openjdk version "1.8.0_212" > > OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1~deb9u1-b01) > > OpenJDK 64-Bit Server VM (build 25.212-b01, mixed mode) > > root at 020dc36b9046:/# > > I wonder if the core technical issue is this: Debian stretch currently > packages OpenJDK 8 8u212-b01, when it should be packaging 8u212-b03 or > 8u212-b04 (which one isn't clear, the release announcement > > was for 8u212-b03, not for 8u212-b04 or 8u212-ga). > > My understanding is that 8u212-b01 is a version identifier created by > the jdk8u project, and based on a quick check, it matches what Debian > identifies as its upstream sources (except for some stripping of system > library components). But it's not the most current release. > > It's one of the challenges, the rest of the world doesn't necessarily > know about the new `-ga ` tag that we use to designate releases, so we > need to go and help them. Right. could mention these tags and link to official tarball(s). I suspect this page is the permanent, quasi-official release announcement due to the openjdk.java.net limitations. It would also help to have a permanent location *anywhere* which is compatible with distribution upstream watch files. Thanks, Florian From gnu.andrew at redhat.com Mon May 27 13:32:57 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 27 May 2019 14:32:57 +0100 Subject: Delay 8u Rampdown In-Reply-To: References: Message-ID: <51ee7ea8-2452-0e0e-46e1-373078658c9c@redhat.com> On 25/05/2019 14:10, Andrew Haley wrote: > We have a few (about 20) bugs still open for jdk8u. Rampdown is > scheduled to begin on Wednesday, May 29th. All of the bugs are > assigned to people, and I don't expect them to take long. > > Monday is Memorial Day in the USA and may Bank Holiday in the UK. > Rather than put everything through the critical-bug-triage process I > think we should delay the onset of 8u rampdown by a couple of days. > If there are any bugs still outstanding by Friday they'll have to go > through triage. > > Comments? > I suggest adding one more cycle, so rampdown is moved from this Wednesday to the following one. That's the cleanest solution without disrupting our process. Unless there are any objections, I'll update the wiki with that information tomorrow. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From doko at ubuntu.com Mon May 27 13:34:04 2019 From: doko at ubuntu.com (Matthias Klose) Date: Mon, 27 May 2019 15:34:04 +0200 Subject: OpenJDK 8u/11u release information Message-ID: <0884e5fb-1e37-3ac7-7fd4-da8796faf9b3@ubuntu.com> Hi guys, until recently we didn't have any source code releases for OpenJDK at all. I appreciate the effort to have source releases, however the gap to produce binaries based on the source release is way to high. Instead of having a dozen of configuration options to build a binary, please can we have a default option which builds consumable packages by default? OpenJDK doesn't have source releases until recently. Now we have, and from my point of view, such a source release should only have a minimal set of configuration options to build a usable image. Things I would like to see - I see it's important to display the version string as the first line of java -version. The source release should set that correctly. - The OpenJDK source release ships with the vendor set to Oracle. Distributors set that to Azul, AdoptJDK, Debian, and probably other values. The binaries built by the OpenJDK itself set that to some sort of version string. An "unknown" vendor causes issue, because some software (LibreOffice, Gradle) uses or at least used that to check for a valid java installation. - The version number should be used for both the source release and the binary package. E.g. the 11.0.3 source release is missing the -ga modifier. - To include a package in a Linux distro, you have to use a monotonically increasing version number, and you have to follow the versioning constraints for the distro. So sometimes you have to juggle with the version numbers. E.g. for Debian/Ubuntu a second dash is problematic for version comparisons. I consider uploads to a development distro as essential, so I have to plan for these version numbers as well. Last time when I asked on the mailing lists, people seemed to be fine with the versioning, however if needed, we could document such versioning on the OpenJDK wiki? - It would be very helpful to see directly in the binary how the build was configured. GCC is showing this information with gcc -v Python is showing that with python -c 'import sysconfig; print(sysconfig.get_config_var("CONFIG_ARGS"))' Or maybe this already exists? Usually binaries in a distro come with a changelog, however sometimes even that is stripped away by re-distributors of binaries. - The configure system has some issues with invalid configure arguments, e.g. configuring --with-version-build='' leads to a failing build. Matthias From gnu.andrew at redhat.com Mon May 27 14:08:46 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 27 May 2019 15:08:46 +0100 Subject: [8u-dev] RFA (S): JDK-8210985: Update the default SSL session cache size to 20480 In-Reply-To: <06A96C44-3C2F-4135-B2BE-F8C1A14C6A93@amazon.com> References: <06A96C44-3C2F-4135-B2BE-F8C1A14C6A93@amazon.com> Message-ID: On 24/05/2019 22:55, Hohensee, Paul wrote: > CSRs are definitely an Oracle thing. See https://wiki.openjdk.java.net/display/csr/Main. > > At Oracle, if you want to change an interface or behavior, you file a JBS issue to do the work, then file a CSR to get approval for the interface change. Closing a CSR == approving it. Finalized state means it's ready for review. One is supposed to get consensus before finalizing a CSR. > > If a backport involved a CSR, Oracle used to want a backport CSR, so the process was and maybe is: create a backport JBS issue, then a CSR for the backport issue, get the CSR approved, then get the backport approved. I don't know what Oracle's CSR backport process is now, but somehow I was under the impression that I should follow it. :) We could use Oracle's process for 8u and 11u, though it's a bit heavy-weight. It does have the advantage of thoroughly documenting interface/behavior changes in backports. I'm not sure who would do the backport CSR approvals: probably the Maintainers. I don't have a strong opinion either way, as long as I know what boxes I need to tick :-) > > I was incorrect/hasty about 8u clean patch application. 8u doesn't have SSLLogger, so that code gets dropped from SSLSessionContextImpl.getDefaultCacheLimit(). > > 8u webrev: http://cr.openjdk.java.net/~phh/8210985/webrev.8u.00/ There's an issue here with the changes to SSLSessionContextImpl.java where the doPrivileged is being lost. In the original version [0], it is changed to GetIntegerAction.privilegedGetProperty which is introduced by JDK-8154231 [1] & JDK-8155775 [2], which I think may be worth backporting themselves: public static Integer privilegedGetProperty(String theProp, int defaultVal) { Integer value; if (System.getSecurityManager() == null) { value = Integer.getInteger(theProp); } else { value = AccessController.doPrivileged( new GetIntegerAction(theProp)); } return (value != null) ? value : defaultVal; } In the 8u backport, the GetIntegerAction is created locally and not run inside a doPrivileged call: + int defaultCacheLimit = + new GetIntegerAction("javax.net.ssl.sessionCacheSize", + DEFAULT_MAX_CACHE_SIZE).run().intValue(); which is incorrect. I suggest something along the lines of: int defaultCacheLimit = java.security.AccessController.doPrivileged(new GetIntegerAction("javax.net.ssl.sessionCacheSize", DEFAULT_MAX_CACHE_SIZE)).intValue(); [0] https://hg.openjdk.java.net/jdk/jdk/rev/8a85d21d9616 [1] https://bugs.openjdk.java.net/browse/JDK-8154231 [2] https://bugs.openjdk.java.net/browse/JDK-8155775 -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From stooke at redhat.com Mon May 27 14:35:18 2019 From: stooke at redhat.com (Simon Tooke) Date: Mon, 27 May 2019 10:35:18 -0400 Subject: [8u] RFR: backport of JDK-8210886: Remove references in xwindows.md to non-existent files. Message-ID: <7fb414e9-e47d-b859-1359-77ded1616bf3@redhat.com> I would like to request a backport of? JDK-8210886: Remove references in xwindows.md to non-existent files. In JDK8, all the copyright notices are in THIRD_PARTY_README, which is identical in all copies in the subrepos. My patch only includes the base repo, but if it makes more sense, I can create (identical) patches for all the subrepos. Bug: https://bugs.openjdk.java.net/browse/JDK-8210886 Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8210886/ Thank you for your time, -Simon From gnu.andrew at redhat.com Mon May 27 15:22:55 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 27 May 2019 16:22:55 +0100 Subject: [8u] RFR: backport of JDK-8210886: Remove references in xwindows.md to non-existent files. In-Reply-To: <7fb414e9-e47d-b859-1359-77ded1616bf3@redhat.com> References: <7fb414e9-e47d-b859-1359-77ded1616bf3@redhat.com> Message-ID: <7d04035b-8a93-62ea-65cc-ae94c6ec8d40@redhat.com> On 27/05/2019 15:35, Simon Tooke wrote: > I would like to request a backport of? JDK-8210886: Remove references in > xwindows.md to non-existent files. > > In JDK8, all the copyright notices are in THIRD_PARTY_README, which is > identical in all copies in the subrepos. > > My patch only includes the base repo, but if it makes more sense, I can > create (identical) patches for all the subrepos. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210886 > > Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8210886/ > > Thank you for your time, > > -Simon > > > Yes, this will need to be applied to all subrepos as well. See Christoph's work on the similar https://bugs.openjdk.java.net/browse/JDK-8213213 as an example. Please add a jdk8u-fix-request label to JDK-8210886 so I can approve this. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From zgu at redhat.com Mon May 27 15:56:52 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 27 May 2019 11:56:52 -0400 Subject: [8u] RFR 8153732: Windows remote printer changes do not reflect in lookupPrintServices() Message-ID: <5779fda6-fc2f-40c3-f81a-f5f48803fc46@redhat.com> Hi, Please review this backport to 8u. The original patch can not apply to 8u without first renaming Win32PrintServiceLookup.java to PrintServiceLookupProvider.java, and fixing class names, references and native jni method signature. After that, the patch is clean. Bug: https://bugs.openjdk.java.net/browse/JDK-8153732 Original changeset: http://hg.openjdk.java.net/jdk/client/rev/732a3b600098 8u Backport Webrev: http://cr.openjdk.java.net/~zgu/JDK-8153732_8u/webrev.00/ Test: manual testing: RemotePrinterStatusRefresh Thanks, -Zhengyu From gnu.andrew at redhat.com Mon May 27 16:10:09 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 27 May 2019 17:10:09 +0100 Subject: OpenJDK 8u222-b04 EA Released Message-ID: I've made available an early access source bundle for 8u222, based on the tag jdk8u222-b04: https://openjdk-sources.osci.io/openjdk8/openjdk8u222-b04-ea.tar.xz The tarball is accompanied by a digital signature available at: https://openjdk-sources.osci.io/openjdk8/openjdk8u222-b04-ea.tar.xz.sig This is signed by our new Red Hat OpenJDK key (openjdk at redhat.com): PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) Fingerprint = CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F SHA256 checksums: 80bc2ea3eba52268aa0c49de22d99b5bf87cadec4f6a1f72afa7cce2d03965a2 openjdk8u222-b04-ea.tar.xz c8c413e9dc7d73316a510ef4f08d3c0935f36ee4d641035a08e4e3673de034a3 openjdk8u222-b04-ea.tar.xz.sig They are listed at https://openjdk-sources.osci.io/openjdk8/openjdk8u222-b04-ea.sha256 Changes in jdk8u222-b04: - S8158232: PPC64: improve byte, int and long array copy stubs by using VSX instructions - S8190974: Parallel stream execution within a custom ForkJoinPool should obey the parallelism - S8203190: SessionId.hashCode generates too many collisions - S8223499: Remove two DocuSign root certificates that are expiring - S8223883: Fix jni.cpp copyright date after 8223528 Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Mon May 27 16:21:01 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 27 May 2019 17:21:01 +0100 Subject: [8u] RFR 8153732: Windows remote printer changes do not reflect in lookupPrintServices() In-Reply-To: <5779fda6-fc2f-40c3-f81a-f5f48803fc46@redhat.com> References: <5779fda6-fc2f-40c3-f81a-f5f48803fc46@redhat.com> Message-ID: On 27/05/2019 16:56, Zhengyu Gu wrote: > Hi, > > Please review this backport to 8u. > > The original patch can not apply to 8u without first renaming > Win32PrintServiceLookup.java to PrintServiceLookupProvider.java, and > fixing class names, references and native jni method signature. After > that, the patch is clean. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153732 > > Original changeset: http://hg.openjdk.java.net/jdk/client/rev/732a3b600098 > > 8u Backport Webrev: > http://cr.openjdk.java.net/~zgu/JDK-8153732_8u/webrev.00/ > > Test: > ? manual testing: RemotePrinterStatusRefresh > > Thanks, > > -Zhengyu > If you're going to perform the renaming, then JDK-8055705 should be backported separately as a pre-requisite. Bundling just the Windows half of this into this changeset is going to cause confusion further down the line. Alternatively, the changes in 8153732 could just be applied directly to WPrinterJob.cpp and Win32PrintServiceLookup.java in 8u, AFAICS. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gil at azul.com Mon May 27 16:23:00 2019 From: gil at azul.com (Gil Tene) Date: Mon, 27 May 2019 16:23:00 +0000 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> <8FB70808-E4E0-451C-AC86-C9EA1EA2FA30@azul.com>, Message-ID: <9CD92EA4-EAAE-44ED-9901-C269628035C7@azul.com> Sent from my iPad On May 27, 2019, at 7:59 AM, Thomas St?fe > wrote: Hi Gil, On Mon, May 27, 2019 at 1:41 AM Gil Tene > wrote: Seriously? You see factual reporting (directly documented and dated in the original posting) of the actual version numbers being used by official docker images, along with irrefutable proof that the packages used in those were built weeks before the respective OpenJDK 8u and 11u releases were complete, as ?fake news?? You think that alerting millions of unsuspecting people using exposed, insecure builds that falsely report their OpenJDK version (as one that includes e.g. critical security fixes) to the fact as ?marketing?? Did you try to contact Debian folks to give them opportunity to fix those security concerns before going public with them? Or did they not react in time? Multiple times over ~4.5 years, and through multiple channels. The ?we don?t care?, ?go away, vendor?, and ?java and openjdk do versioning wrong? reactions are the most common. Many were less polite than that. The defensive tone of the email you see on this thread is about average. The denial and deflection attempts you see there are also common. Some people just don?t want help, at least not from some. And that?s fine. There is an established way to coordinate activity around security issues in the java community, with plenty of time to deal with them before publication, and a coordinated embargo date before which they do not get discussed publicly. Each java distribution is then free to include fixes to those issues after that date. And since the binaries for fixed versions become widely available, CVE information published, and source code for the fixes show up in at least some cases (e.g. OpenJDK), the cats are out of theirs bags at that point. As has happened many many times in the past, OpenJDK 8u chose the 8u212 release, and OpenJDK 11u the 11.0.3 release, as the ones that would include the 8u and 11u updates for issues revealed on April 16, 2019 (the coordinated quarterly update date). All tagged builds with 8u212 mentioned prior to that date were not releases, but things preparing to eventually become the 8u212 release. By necessity, none of the non-release builds included any security fixes, as those were all developed and integrated ?in the dark?. Same goes for 11.0.3. OpenJDK code is open source, and the process of developing an upcoming quarterly update release is done mostly in the open (with exceptions, like the security part, which is done in the dark but still with community coordination). These are good things. But these good things also mean that anyone, anywhere, can pick up source code at any point, and are perfectly within their rights to build that code, call it whatever version they want, give it to people, and even advertise and market it as ?stable? and attack anyone who dares to suggest anything is wrong with their choices. Does that mean that making a JDK from unreleased code and calling it 8u212 (with no ?not really? disqualifier) a good idea? Probably not according to most people. Certainly not IMO. But as noted before, I?ve given up on holding my breath a long time ago. Cheers, Thomas From gnu.andrew at redhat.com Mon May 27 16:31:35 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 27 May 2019 17:31:35 +0100 Subject: [8u-dev, ppc] RFR for (almost clean) backport of 8185696: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: References: Message-ID: <1bd63cd1-efbb-e70d-62e5-510d364f712b@redhat.com> On 27/05/2019 10:06, Kazunori Ogata wrote: > Hi, > > I'm requesting backport of 8185696: PPC64: Improve VSR support to use up > to 64 registers to jdk8u-dev. This patch can be applied almost cleanly, > but one chunk failed (other than a copyright year conflict) because the > definition of MTVSRWA_OPCODE is missing in > src/cpu/ppc/vm/assembler_ppc.hpp. > > MTVSRWA_OPCODE was added in 8144019: PPC64 C1: Introduce Client Compiler > [1], which added tiered compilation feature in JDK9. Since JDK8 does not > support tiered compilation, we cannot apply this change set. > > So I manually applied the failed chunk by skipping the MTVSRWA_OPCODE > definition because no code in this changeset and other changesets I'm > going to backport uses this opcode. I'll leave it to the future backport > that really needs this opcode. > > Is this fix acceptable for backport request? If there is no objection in > a few days, I'll go forward to add jdk8u-fix-request tag in the original > bug report. I verified I can build both fastdebug and release version, > and no degradation in jtreg. > > > Original bug report: > https://bugs.openjdk.java.net/browse/JDK-8185969 > > Webrev: > http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8185969/webrev.02/ > > Refs: > [1] https://bugs.openjdk.java.net/browse/JDK-8144019 > > This mostly looks ok, but why is the copyright header updated to 2019 for assembler_ppc.hpp, but not register_ppc.hpp and register_ppc.cpp? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From martin.doerr at sap.com Mon May 27 16:41:37 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 27 May 2019 16:41:37 +0000 Subject: [8u-dev, ppc] RFR for (almost clean) backport of 8185696: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: <1bd63cd1-efbb-e70d-62e5-510d364f712b@redhat.com> References: <1bd63cd1-efbb-e70d-62e5-510d364f712b@redhat.com> Message-ID: Hi, I think it's fine. I guess the copyright updates in the other files were part of other changes which have not been backported. I don't think we have to update copyrights in backport changes other than what comes naturally with the change. Best regards, Martin > -----Original Message----- > From: hotspot-compiler-dev bounces at openjdk.java.net> On Behalf Of Andrew John Hughes > Sent: Montag, 27. Mai 2019 18:32 > To: Kazunori Ogata ; hotspot-compiler- > dev at openjdk.java.net; jdk8u-dev at openjdk.java.net > Subject: Re: [8u-dev, ppc] RFR for (almost clean) backport of 8185696: PPC64: > Improve VSR support to use up to 64 registers > > > > On 27/05/2019 10:06, Kazunori Ogata wrote: > > Hi, > > > > I'm requesting backport of 8185696: PPC64: Improve VSR support to use up > > to 64 registers to jdk8u-dev. This patch can be applied almost cleanly, > > but one chunk failed (other than a copyright year conflict) because the > > definition of MTVSRWA_OPCODE is missing in > > src/cpu/ppc/vm/assembler_ppc.hpp. > > > > MTVSRWA_OPCODE was added in 8144019: PPC64 C1: Introduce Client > Compiler > > [1], which added tiered compilation feature in JDK9. Since JDK8 does not > > support tiered compilation, we cannot apply this change set. > > > > So I manually applied the failed chunk by skipping the MTVSRWA_OPCODE > > definition because no code in this changeset and other changesets I'm > > going to backport uses this opcode. I'll leave it to the future backport > > that really needs this opcode. > > > > Is this fix acceptable for backport request? If there is no objection in > > a few days, I'll go forward to add jdk8u-fix-request tag in the original > > bug report. I verified I can build both fastdebug and release version, > > and no degradation in jtreg. > > > > > > Original bug report: > > https://bugs.openjdk.java.net/browse/JDK-8185969 > > > > Webrev: > > http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8185969/webrev.02/ > > > > Refs: > > [1] https://bugs.openjdk.java.net/browse/JDK-8144019 > > > > > > This mostly looks ok, but why is the copyright header updated to 2019 > for assembler_ppc.hpp, but not register_ppc.hpp and register_ppc.cpp? > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew From doko at ubuntu.com Mon May 27 16:53:58 2019 From: doko at ubuntu.com (Matthias Klose) Date: Mon, 27 May 2019 18:53:58 +0200 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: <9CD92EA4-EAAE-44ED-9901-C269628035C7@azul.com> References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> <8FB70808-E4E0-451C-AC86-C9EA1EA2FA30@azul.com> <9CD92EA4-EAAE-44ED-9901-C269628035C7@azul.com> Message-ID: On 27.05.19 18:23, Gil Tene wrote: >> Did you try to contact Debian folks to give them opportunity to fix those security concerns before going public with them? Or did they not react in time? > > Multiple times over ~4.5 years, and through multiple channels. The > ?we don?t care?, ?go away, vendor?, and ?java and openjdk do versioning > wrong? reactions are the most common. Many were less polite than that. > The defensive tone of the email you see on this thread is about average. > The denial and deflection attempts you see there are also common. I can't follow that. There is not a single bug report about that in the Debian tracker. Looking at the Debian Java mailing list, there is not a single posting from your side. And I can't remember that being discussed on the ML either. Also not on the distro-pkg-dev ML. Same thing for the Ubuntu bug tracker. So which channels are you using? > Some people just don?t want help, at least not from some. And that?s fine. I raised questions about the versioning on the jdk ML's multiple times. Most of those were ignored, or saw the versioning as being correct. I brought up the configuration issues at this year OpenJDK committers workshop, but it was voted down because other topics seemed more pressing to discuss. Matthias From gnu.andrew at redhat.com Mon May 27 17:28:28 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 27 May 2019 18:28:28 +0100 Subject: [8u-dev, ppc] RFR for (almost clean) backport of 8185696: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: References: <1bd63cd1-efbb-e70d-62e5-510d364f712b@redhat.com> Message-ID: <6459888e-be23-e362-3b09-c5cd4afa701f@redhat.com> On 27/05/2019 17:41, Doerr, Martin wrote: > Hi, > > I think it's fine. > > I guess the copyright updates in the other files were part of other changes which have not been backported. > I don't think we have to update copyrights in backport changes other than what comes naturally with the change. > > Best regards, > Martin > > The change to the copyright header in assembler_ppc.hpp is an addition in this backport. So either that should be dropped or the same should be applied to register_ppc.{c,h}pp (the remaining file is already 2019). I tend towards dropping it, but we should at least be consistent within the same patch. Best regards, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From dcherepanov at azul.com Mon May 27 17:47:49 2019 From: dcherepanov at azul.com (Dmitry Cherepanov) Date: Mon, 27 May 2019 17:47:49 +0000 Subject: [8u] RFR 8220495: Update GIFlib library to the 5.1.8 Message-ID: <977AA493-E714-43B6-9B2E-A51938E268F1@azul.com> Hello, Please review the backport of 8220495 to 8u-dev. JBS: https://bugs.openjdk.java.net/browse/JDK-8220495 Webrevs: http://cr.openjdk.java.net/~dcherepanov/8220495/v0/ The patch applies cleanly after unshuffling except the change in giflib.md. It?s incorporated into THIRD_PARTY_README for all repos. Testing: build passed on Mac/Win/Linux/Solaris and relevant tests (java/awt/SplashScreen/sun/java2d) didn't reveal any issues. Thanks, Dmitry From rkennke at redhat.com Mon May 27 19:26:34 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 27 May 2019 21:26:34 +0200 Subject: RFR: 8218020: Fix version number in mesa.md 3rd party legal file Message-ID: <4c08f94d-0e31-a567-2a75-9195c8ebc6e5@redhat.com> Sort-of trivial version number update backport. In contrast to >8 versions where the mesa version info is in a single mesa3d.md file, the information is spread over several THIRD_PARTY_READY in 8. See changesets here: http://cr.openjdk.java.net/~rkennke/backport-jdk-JDK-8218020/ Original jdk12 bugfix: http://hg.openjdk.java.net/jdk/jdk12/rev/cda5d1ed2c85 Issue: https://bugs.openjdk.java.net/browse/JDK-8218020 Ok? Roman From stooke at redhat.com Mon May 27 19:59:31 2019 From: stooke at redhat.com (Simon Tooke) Date: Mon, 27 May 2019 15:59:31 -0400 Subject: [8u] RFR: backport of JDK-8210886: Remove references in xwindows.md to non-existent files. In-Reply-To: <7d04035b-8a93-62ea-65cc-ae94c6ec8d40@redhat.com> References: <7fb414e9-e47d-b859-1359-77ded1616bf3@redhat.com> <7d04035b-8a93-62ea-65cc-ae94c6ec8d40@redhat.com> Message-ID: On 5/27/2019 11:22 AM, Andrew John Hughes wrote: > > On 27/05/2019 15:35, Simon Tooke wrote: >> I would like to request a backport of? JDK-8210886: Remove references in >> xwindows.md to non-existent files. >> >> In JDK8, all the copyright notices are in THIRD_PARTY_README, which is >> identical in all copies in the subrepos. >> >> My patch only includes the base repo, but if it makes more sense, I can >> create (identical) patches for all the subrepos. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210886 >> >> Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8210886/ >> >> Thank you for your time, >> >> -Simon >> >> >> > Yes, this will need to be applied to all subrepos as well. See > Christoph's work on the similar > https://bugs.openjdk.java.net/browse/JDK-8213213 as an example. > > Please add a jdk8u-fix-request label to JDK-8210886 so I can approve this. I've revised the webrev to include all directories, and added the tag. Thanks, -Simon > > Thanks, From zgu at redhat.com Mon May 27 20:00:51 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 27 May 2019 16:00:51 -0400 Subject: [8u] RFR 8153732: Windows remote printer changes do not reflect in lookupPrintServices() In-Reply-To: References: <5779fda6-fc2f-40c3-f81a-f5f48803fc46@redhat.com> Message-ID: <05c526b3-6ee8-d1d5-a13a-264248701713@redhat.com> Hi Andrew >> > > If you're going to perform the renaming, then JDK-8055705 should be > backported separately as a pre-requisite. Bundling just the Windows > half of this into this changeset is going to cause confusion further > down the line. > > Alternatively, the changes in 8153732 could just be applied directly to > WPrinterJob.cpp and Win32PrintServiceLookup.java in 8u, AFAICS. > I were not able to find this renaming RFE. Therefore, I would like to withdraw this review, and backport JDK-JDK-8055705. Thanks, -Zhengyu > Thanks, > From stooke at redhat.com Mon May 27 20:04:58 2019 From: stooke at redhat.com (Simon Tooke) Date: Mon, 27 May 2019 16:04:58 -0400 Subject: [8u] RFR: backport of JDK-8214765, All TrayIcon MessageType icons does not show up with gtk3 option set Message-ID: <68d2fb9f-f0e6-3790-615f-733dc2447f7e@redhat.com> This is a straightforward backport to use new filenames for icons if the version of gtk is >= 3.10. Issue: https://bugs.openjdk.java.net/browse/JDK-8214765 Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8214765/ Is it okay? -Simon From rkennke at redhat.com Mon May 27 20:43:00 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 27 May 2019 22:43:00 +0200 Subject: RFR: 8019816: [TEST_BUG][macosx] closed/java/awt/BasicStroke/DashZeroWidth.java not on EDT Message-ID: <14fb8769-4d6f-5e63-1250-574c7cd73c65@redhat.com> This is a straightforward backport from the original jdk10 fix to jdk8u, only adjusted new files locations. Bug: https://bugs.openjdk.java.net/browse/JDK-8019816 Original fix: http://hg.openjdk.java.net/jdk/jdk/rev/080c3ab73c8d JDK8u-backport: http://cr.openjdk.java.net/~rkennke/backport-jdk8-JDK-8019816/webrev.00/ Good? Thanks, Roman From gil at azul.com Tue May 28 00:51:53 2019 From: gil at azul.com (Gil Tene) Date: Tue, 28 May 2019 00:51:53 +0000 Subject: OpenJDK 8u/11u release information In-Reply-To: <0884e5fb-1e37-3ac7-7fd4-da8796faf9b3@ubuntu.com> References: <0884e5fb-1e37-3ac7-7fd4-da8796faf9b3@ubuntu.com> Message-ID: <9ED31317-5AF2-4DA5-A96B-744E7CE6F1B6@azul.com> > On May 27, 2019, at 6:34 AM, Matthias Klose wrote: > > Hi guys, The following is meant to be constructive and informational, so please don't read it as anything other than that. With that said, any and all "you are plain wrong, and here is why" followups to what I say below are welcome. > > until recently we didn't have any source code releases for OpenJDK at all. Not sure what you mean by this. Can you clarify what you mean when you use the term "source code releases"? And how the thing you mean differs from historical practice in OpenJDK? By my understanding OpenJDK, as a source code project, has been producing source code releases pretty much since OpenJDK 6 was first released, and has never stopped doing so, with continuing update releases happening within major version project on a pretty regular basis. Version formats have changed across major java versions, tagging and development processes going into a release also evolved and changed over time. But at all points in the past several years, it's been pretty clear when a release happened, and what the source code for that release actually was. Binary builds of those released sources have been around for quite a while as well. But in the past, these may not have been created consistently by the project lead for every update. What is "new" (AFAIK), specifically in 8u and 11u (and not in other projects thus far), is the posting of project-lead blessed, TCK-tested builds of "vanilla" released (as well as EA) sources of 8u and 11u (see e.g. https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009105.html and subsequent discussions) at some external location. That's a very positive development, which I certainly hope will last and continue. But as noted in that e-mail thread, those binaries are simply good, fully-TCK-tested builds of the released sources, posted to a known location. They did not change the release process in any way. > I appreciate the effort to have source releases, however the gap to produce > binaries based on the source release is way to high. Instead of having a dozen > of configuration options to build a binary, please can we have a default option > which builds consumable packages by default? As things stand, across the various java version projects, the default build modes for all sources (including releases) produce consumable-by-the-builder things, intentionally labeled in ways that would scare people away from using the bits as a release. This is intentional, and is aimed to make sure that things that look like an actual release will only happen through intent, assertive actions and real choices about reported versions. E.g., when I build things using the defaults, I'd get stuff like: # bash ./configure # make all # build/linux-x86_64-normal-server-release/jdk/bin/java -version openjdk version "1.8.0-internal" OpenJDK Runtime Environment (build 1.8.0-internal-gil_2019_05_27_10_48-b00) OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode) And that's a good thing. It prevents the accidental leakage of unfinished bits to others. To produce things you would give other people ("consumable" by others), you need to intentionally make assertive (non-default) choices about configuration. Normally, stating your update version, build version, and milestone (or "pre" version) at the very least, and likely things like vendor version, etc. Non of those have good "defaults", as you don't want any of those to appear "by accident" in a build. The same is true for the sources of the actual quarterly releases, which are no more than a snapshot of the sources at the release point. To create a binary build that does not carry the "-internal" identification, and that has specific update and build numbers, you have to assertively declare those in the build configuration. But that's not very complicated. E.g. # bash ./configure --with-update-version=972 --with-build-number=b41 --with-milestone="snapshot" # make clean; make all # build/linux-x86_64-normal-server-release/jdk/bin/java -version openjdk version "1.8.0_972-snapshot" OpenJDK Runtime Environment (build 1.8.0_972-snapshot-b41) OpenJDK 64-Bit Server VM (build 25.972-b41, mixed mode) And with the special milestone called "fcs": # bash ./configure --with-update-version=982 --with-build-number=b42 --with-milestone="fcs" # make clean; make all # build/linux-x86_64-normal-server-release/jdk/bin/java -version openjdk version "1.8.0_982" OpenJDK Runtime Environment (build 1.8.0_982-b42) OpenJDK 64-Bit Server VM (build 25.982-b42, mixed mode) Note: For OpenJDK 8u "fcs" is a special milestone. It is the specific thing you need to do to get rid of the milestone part of the versions string. Any other value (including "", which will revert to "internal") will show up in the version, because of this in common/autoconf/spec.gmk.in : # These variables need to be generated here so that MILESTONE and # JDK_BUILD_NUMBER can be overridden on the make command line. ifeq ($(MILESTONE), fcs) RELEASE=$(JDK_VERSION)$(BUILD_VARIANT_RELEASE) else RELEASE=$(JDK_VERSION)-$(MILESTONE)$(BUILD_VARIANT_RELEASE) endif 11u is a little different. The release versioning is more specifically defined (JEP322), and the term for that "disqualifier" part for the version that tells you it is not an actual release (what 8u sets using --with-milestone) is the "pre-release identifier" ($PRE) part of the version string (set --with-version-pre). The default behaves the same with regards to "-internal" in the sense that $PRE defaults to "internal", a =nd must be assertively set to "" to get rid of it. But in 11u a default for the UPDATE portion of the JEP322 version string is typically baked into make/autoconf/version-numbers (as opposed to having to be set via --with-update-version in 8u) so e.g.: # bash ./configure # make all # ./build/linux-x86_64-normal-server-release/jdk/bin/java -version openjdk version "11.0.3-internal" 2019-04-16 OpenJDK Runtime Environment (build 11.0.3-internal+0-adhoc.gil.11u1103rel) OpenJDK 64-Bit Server VM (build 11.0.3-internal+0-adhoc.gil.11u1103rel, mixed mode) But when you build something that is fit for others to consume, you will still want to provide a build number with --with-build-number, use -with-version-pre="" if you want to say it is an actual release (use e.g. "ea", or just leave blank to make it "internal" otherwise), and in addition set --with-version-opt to control that thing that defaults to "adhoc.$USERNAME.$basedirname". Finally, --with-vendor-version-string="18.9" is considered "vanilla" (the year.month for Java SE 11), and that's where non-vanilla distros tend put their name in. So e.g.: # bash ./configure --with-version-build=42 --with-version-opt="" --with-version-pre="" --with-vendor-version-string="18.9" # make all # ./build/linux-x86_64-normal-server-release/jdk/bin/java -version openjdk version "11.0.3" 2019-04-16 OpenJDK Runtime Environment 18.9 (build 11.0.3+42) OpenJDK 64-Bit Server VM 18.9 (build 11.0.3+42, mixed mode) > > OpenJDK doesn't have source releases until recently. Now we have, and from my > point of view, such a source release should only have a minimal set of > configuration options to build a usable image. Things I would like to see > > - I see it's important to display the version string as the first line > of java -version. The source release should set that correctly. See above discussion about why (by long standing OpenJDK historical practice) version strings are controlled by the build configuration, and not by the source code of a release. > > - The OpenJDK source release ships with the vendor set to Oracle. > Distributors set that to Azul, AdoptJDK, Debian, and probably other > values. The binaries built by the OpenJDK itself set that to some > sort of version string. An "unknown" vendor causes issue, because some > software (LibreOffice, Gradle) uses or at least used that to check > for a valid java installation. I'll assume you are referring to the "18.9" part in the version string reported by the "blessed by project lead" builds of the OpenJDK 11u 11.0.3 release: # ./openjdk-11.0.3+7/bin/java -version openjdk version "11.0.3" 2019-04-16 OpenJDK Runtime Environment 18.9 (build 11.0.3+7) OpenJDK 64-Bit Server VM 18.9 (build 11.0.3+7, mixed mode) That 18.9 part is the "vendor version string" as defined by JEP322 (a new property that did not exist in 8u). The choice of "18.9" (the year.month that Java SE 11 was released) is both the actual example vendor version string shown in the JEP, and follows the precedent already set for "vanilla" OpenJDK builds of 11, 11.0.1, and 11.0.2 produced by the previous project lead during the first 6 months of 11u. (note that those were the OpenJDK build posted by Oracle, not the Oracle JDK builds). Since "18.9" was there as a vendor version string form the very start of OpenJDK 11, we can assume that anything that knows how to parse JEP322 versions will not have a problem with it. > > - The version number should be used for both the source release and the > binary package. E.g. the 11.0.3 source release is missing the -ga > modifier. I'll assume that you are referring to version string reported by the binary, e.g. in response to -version, and not to package names, file names, or tags in source control. The version string conventions for each existing Java SE version are already established, and they (unfortunately) differ by major version. Thus far, for all Java SE versions I know of which had an OpenJDK project (6, 7, 8, 9, 10, 11, 12), neither Oracle nor OpenJDK builds have included a positive (e.g. "-ga") indicator in the version strings of actually-released versions. Instead, the long standing convention has been to include a disqualifier ("-ea", "-internal", "-rc1") in non-released builds. The build system defaults to using the -internal qualifier in all versions to date. Thus the current output from the project-lead blessed builds of 8u212 is: # java -version openjdk version "1.8.0_212" OpenJDK Runtime Environment (build 1.8.0_212-b04) OpenJDK 64-Bit Server VM (build 25.212-b04, mixed mode) (which, since there is no "disqualifier" in the version, means that it reports as a build of an actual release). The technical term for this "disqualifier" has varied over the years. As shown above, 8u calls it "milestone", 11u calls it a "pre-release identifier". But in all versions so far, *not* having it there means that it is a release. Changing version string formats and conventions for indicating things within a major java version is a generally bad idea. Adding "-ga" to actual update releases of existing Java SE major versions is likely to blow up a whole bunch of things. For one: a common ways to determine that a version of OpenJDK or Oracle JDK is an actual released version (as opposed to some ea/beta/rc1/internal/experimental thing) is to verify that there is no "-XYZ" part (the milestone or $PRE) in the version string. Making changes to conventions across versions is quite possible, and has been done multiple times (e.g. JEP 322, JEP 223). JEP 322 is what we currently follow for 11u and above. If it insufficient for some reason, and we want to change it yet again for e.g. OpenJDK 14, that's something to discuss, I guess., But such changes should not affect existing Java SE versions (12 and below). > > - To include a package in a Linux distro, you have to use a monotonically > increasing version number, and you have to follow the versioning > constraints for the distro. So sometimes you have to juggle with the > version numbers. E.g. for Debian/Ubuntu a second dash is problematic > for version comparisons. I consider uploads to a development distro > as essential, so I have to plan for these version numbers as well. > Last time when I asked on the mailing lists, people seemed to be fine > with the versioning, however if needed, we could document such > versioning on the OpenJDK wiki? This is a good point (make sure your *package* names retain monotonically growing version numbers), but since these rules apply to the package names as seen by the distro (and not to the version strings) simple distro-specific file name conversion conventions seem to suffice. This is often necessary simply because conventions and file name requirements can vary widely between OSs (some don't like dots, some don't like dashes, some deal with capitalization in interesting ways). E.g. you can convert every dash in the version string to to an underscore in the .deb or .rpm package names. An interesting problem shows up if the parsing of the version string related fields appears to "go backwards" in your monotonic comparisons (e.g. if the sorting is text based rather than numeric, and 11.0.10 would be considered earlier than 11.0.9, or 8u92 was considered to come after 8u102). I can think of a few ways to resolve that with package name conventions, but I don't really know if this is a problem. Does debian compare numeric sequence substrings in package name numerically, or lexicographically? > > - It would be very helpful to see directly in the binary how the build > was configured. GCC is showing this information with > gcc -v > Python is showing that with > python -c 'import sysconfig; print(sysconfig.get_config_var("CONFIG_ARGS"))' > Or maybe this already exists? > > Usually binaries in a distro come with a changelog, however sometimes > even that is stripped away by re-distributors of binaries. > > - The configure system has some issues with invalid configure arguments, e.g. > configuring --with-version-build='' leads to a failing build. Setting --with-version-build="" works on 8u (it is a string). In 11u, you'd use --with-version-build=0 (it is an integer). > > Matthias From OGATAK at jp.ibm.com Tue May 28 05:22:20 2019 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Tue, 28 May 2019 14:22:20 +0900 Subject: [8u-dev, ppc] RFR for (almost clean) backport of 8185696: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: <6459888e-be23-e362-3b09-c5cd4afa701f@redhat.com> References: <1bd63cd1-efbb-e70d-62e5-510d364f712b@redhat.com> <6459888e-be23-e362-3b09-c5cd4afa701f@redhat.com> Message-ID: Hi Andrew and Martin, Thank you for your comments. My original intention to change the copyright year was that I did some work to apply the original patch to this file. I now realized I made no change in the code that was modified in the original patch. So I agree not updating the copyright year is more natural. I updated webrev: http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8185969/webrev.03/ Regards, Ogata Andrew John Hughes wrote on 2019/05/28 02:28:28: > From: Andrew John Hughes > To: "Doerr, Martin" , Kazunori Ogata > , "hotspot-compiler-dev at openjdk.java.net" compiler-dev at openjdk.java.net>, "jdk8u-dev at openjdk.java.net" dev at openjdk.java.net> > Date: 2019/05/28 02:28 > Subject: [EXTERNAL] Re: [8u-dev, ppc] RFR for (almost clean) backport of > 8185696: PPC64: Improve VSR support to use up to 64 registers > > > > On 27/05/2019 17:41, Doerr, Martin wrote: > > Hi, > > > > I think it's fine. > > > > I guess the copyright updates in the other files were part of other > changes which have not been backported. > > I don't think we have to update copyrights in backport changes other > than what comes naturally with the change. > > > > Best regards, > > Martin > > > > > > The change to the copyright header in assembler_ppc.hpp is an addition > in this backport. So either that should be dropped or the same should be > applied to register_ppc.{c,h}pp (the remaining file is already 2019). > > I tend towards dropping it, but we should at least be consistent within > the same patch. > > Best regards, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew > > [attachment "signature.asc" deleted by Kazunori Ogata/Japan/IBM] From aph at redhat.com Tue May 28 08:31:06 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 28 May 2019 09:31:06 +0100 Subject: [8u-dev] Delay 8u Rampdown In-Reply-To: References: Message-ID: On 5/25/19 2:10 PM, Andrew Haley wrote: > We have a few (about 20) bugs still open for jdk8u. Rampdown is > scheduled to begin on Wednesday, May 29th. All of the bugs are > assigned to people, and I don't expect them to take long. > > Monday is Memorial Day in the USA and may Bank Holiday in the UK. > Rather than put everything through the critical-bug-triage process I > think we should delay the onset of 8u rampdown by a couple of days. > If there are any bugs still outstanding by Friday they'll have to go > through triage. > > Comments? None? :-) -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue May 28 08:38:19 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 28 May 2019 09:38:19 +0100 Subject: Delay 8u Rampdown In-Reply-To: <51ee7ea8-2452-0e0e-46e1-373078658c9c@redhat.com> References: <51ee7ea8-2452-0e0e-46e1-373078658c9c@redhat.com> Message-ID: On 5/27/19 2:32 PM, Andrew John Hughes wrote: > > On 25/05/2019 14:10, Andrew Haley wrote: >> We have a few (about 20) bugs still open for jdk8u. Rampdown is >> scheduled to begin on Wednesday, May 29th. All of the bugs are >> assigned to people, and I don't expect them to take long. >> >> Monday is Memorial Day in the USA and may Bank Holiday in the UK. >> Rather than put everything through the critical-bug-triage process I >> think we should delay the onset of 8u rampdown by a couple of days. >> If there are any bugs still outstanding by Friday they'll have to go >> through triage. >> >> Comments? > > I suggest adding one more cycle, so rampdown is moved from this > Wednesday to the following one. That's the cleanest solution without > disrupting our process. > > Unless there are any objections, I'll update the wiki with that > information tomorrow. Sounds good. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue May 28 08:40:27 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 28 May 2019 09:40:27 +0100 Subject: Delay 8u Rampdown In-Reply-To: References: Message-ID: On 5/27/19 7:38 AM, Langer, Christoph wrote: > Sounds reasonable. I guess for the next release we should aim to have these backport items finished earlier though. Sure. Co-ordination between independent people and organizations, each with its own plans and goals, has always been a challenge in free software projects, but we work ever closer to perfection. :-) -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From martijnverburg at gmail.com Tue May 28 08:51:49 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Tue, 28 May 2019 09:51:49 +0100 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: <871s0kkwq7.fsf@oldenburg2.str.redhat.com> References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> <5491A2A5-32D1-42D9-99E4-2ACE2927C9FD@azul.com> <875zpwkxxj.fsf@oldenburg2.str.redhat.com> <871s0kkwq7.fsf@oldenburg2.str.redhat.com> Message-ID: Hi Florian, > My understanding is that 8u212-b01 is a version identifier created by > > the jdk8u project, and based on a quick check, it matches what Debian > > identifies as its upstream sources (except for some stripping of system > > library components). But it's not the most current release. > > > > It's one of the challenges, the rest of the world doesn't necessarily > > know about the new `-ga ` tag that we use to designate releases, so we > > need to go and help them. > > Right. could > mention these tags and link to official tarball(s). I suspect this page > is the permanent, quasi-official release announcement due to the > openjdk.java.net limitations. > > It would also help to have a permanent location *anywhere* which is > compatible with distribution upstream watch files. > Right, you are - https://github.com/AdoptOpenJDK/openjdk-website/pull/501 raised to resolve this, thanks! Cheers, Martijn > > Thanks, > Florian > From martijnverburg at gmail.com Tue May 28 08:54:42 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Tue, 28 May 2019 09:54:42 +0100 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> <5491A2A5-32D1-42D9-99E4-2ACE2927C9FD@azul.com> <875zpwkxxj.fsf@oldenburg2.str.redhat.com> Message-ID: Hi all, It's one of the challenges, the rest of the world doesn't necessarily know >> about the new `-ga` tag that we use to designate releases, so we need to go >> and help them. >> > > I've also replied separately to this thread (with a meeting request) but > cut out the OpenJDK mailing lists as it's really the Debian distro list > that we should be discussing this on. > If folks feel otherwise, let me know and I'll CC these lists back in. > FYI - I have a call (high bandwidth is required here) with Matthias next Monday (1100UK time) so I can learn more about the Debian process and what we can do to align going forward. I'll report back here or via a Debian ticket so the conversation and outcomes can be tracked. if anyone else wants to join on the call then please let me know! Cheers, Martijn From aph at redhat.com Tue May 28 09:05:00 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 28 May 2019 10:05:00 +0100 Subject: [8u-dev] Delay 8u Rampdown In-Reply-To: References: Message-ID: On 5/28/19 9:31 AM, Andrew Haley wrote: >> Comments? > None? :-) Sorry, my email feed wasn't working. Got it now. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From zgu at redhat.com Tue May 28 12:30:22 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 28 May 2019 08:30:22 -0400 Subject: [8u] RFR 8055705: Rename UnixPrintServiceLookup and Win32PrintServiceLookup as a platform neutral class name Message-ID: Hi, Please review this backport to 8u. The patch applied largely clean after file path changes. But instead of using platform-dependent META-INFO service configuration file, I kept old mechanism to avoid pulling in more changesets, and updated service configuration in following files: src/solaris/classes/sun/print/services/javax.print.PrintServiceLookup src/windows/classes/sun/print/services/javax.print.PrintServiceLookup JDK9 bug: https://bugs.openjdk.java.net/browse/JDK-8055705 Original patch: http://hg.openjdk.java.net/jdk9/client/jdk/rev/8278952344bc JDK8u backport: http://cr.openjdk.java.net/~zgu/JDK-8055705-8u/webrev.00/ Thanks, -Zhengyu From christoph.langer at sap.com Tue May 28 12:51:46 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 28 May 2019 12:51:46 +0000 Subject: RFR: 8218020: Fix version number in mesa.md 3rd party legal file In-Reply-To: <4c08f94d-0e31-a567-2a75-9195c8ebc6e5@redhat.com> References: <4c08f94d-0e31-a567-2a75-9195c8ebc6e5@redhat.com> Message-ID: Hi Roman, looks good. The distributed THIRD_PARTY_README is a bit annoying but it is as it is... ?? Best regards Christoph > -----Original Message----- > From: jdk8u-dev On Behalf Of > Roman Kennke > Sent: Montag, 27. Mai 2019 21:27 > To: jdk8u-dev at openjdk.java.net > Subject: RFR: 8218020: Fix version number in mesa.md 3rd party legal file > > Sort-of trivial version number update backport. > > In contrast to >8 versions where the mesa version info is in a single > mesa3d.md file, the information is spread over several THIRD_PARTY_READY > in 8. See changesets here: > > http://cr.openjdk.java.net/~rkennke/backport-jdk-JDK-8218020/ > > Original jdk12 bugfix: > http://hg.openjdk.java.net/jdk/jdk12/rev/cda5d1ed2c85 > Issue: > https://bugs.openjdk.java.net/browse/JDK-8218020 > > Ok? > > Roman From christoph.langer at sap.com Tue May 28 12:54:01 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 28 May 2019 12:54:01 +0000 Subject: [8u] RFR: backport of JDK-8214765, All TrayIcon MessageType icons does not show up with gtk3 option set In-Reply-To: <68d2fb9f-f0e6-3790-615f-733dc2447f7e@redhat.com> References: <68d2fb9f-f0e6-3790-615f-733dc2447f7e@redhat.com> Message-ID: Hi Simon, looks good to me. Best regards Christoph > -----Original Message----- > From: jdk8u-dev On Behalf Of > Simon Tooke > Sent: Montag, 27. Mai 2019 22:05 > To: jdk8u-dev at openjdk.java.net > Subject: [8u] RFR: backport of JDK-8214765, All TrayIcon MessageType icons > does not show up with gtk3 option set > > This is a straightforward backport to use new filenames for icons if the > version of gtk is >= 3.10. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8214765 > > Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8214765/ > > Is it okay? > > -Simon From zgu at redhat.com Tue May 28 13:03:57 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 28 May 2019 09:03:57 -0400 Subject: [8u] RFR 8153732: Windows remote printer changes do not reflect in lookupPrintServices() In-Reply-To: <05c526b3-6ee8-d1d5-a13a-264248701713@redhat.com> References: <5779fda6-fc2f-40c3-f81a-f5f48803fc46@redhat.com> <05c526b3-6ee8-d1d5-a13a-264248701713@redhat.com> Message-ID: Hi, Could you please review this 8u backport? After JDK-8055705 backport, the original patch still does not apply cleanly, due to missing following Thread API in JDK8u. public Thread?(ThreadGroup group, Runnable target, String name, long stackSize, boolean inheritThreadLocals) The original patch has inheritThreadLocals = false, but replacement API public Thread?(ThreadGroup group, Runnable target, String name, long stackSize) has it default to true. Could AWT folks take a look? JDK9 bug: https://bugs.openjdk.java.net/browse/JDK-8153732 Original patch: http://hg.openjdk.java.net/jdk/client/rev/732a3b600098 8u Backport: http://cr.openjdk.java.net/~zgu/JDK-8153732_8u/webrev.01/ Test: manual test: RemotePrinterStatusRefresh Thanks, -Zhengyu Thanks, -Zhengyu From zgu at redhat.com Tue May 28 14:31:39 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 28 May 2019 10:31:39 -0400 Subject: RFR: 8019816: [TEST_BUG][macosx] closed/java/awt/BasicStroke/DashZeroWidth.java not on EDT In-Reply-To: <14fb8769-4d6f-5e63-1250-574c7cd73c65@redhat.com> References: <14fb8769-4d6f-5e63-1250-574c7cd73c65@redhat.com> Message-ID: I don't think you need RFR if patch applies cleanly. -Zhengyu On 5/27/19 4:43 PM, Roman Kennke wrote: > This is a straightforward backport from the original jdk10 fix to jdk8u, > only adjusted new files locations. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8019816 > Original fix: > http://hg.openjdk.java.net/jdk/jdk/rev/080c3ab73c8d > > JDK8u-backport: > http://cr.openjdk.java.net/~rkennke/backport-jdk8-JDK-8019816/webrev.00/ > > Good? > > Thanks, > Roman > From christoph.langer at sap.com Tue May 28 15:04:58 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 28 May 2019 15:04:58 +0000 Subject: JDK11/8 Updates: process, schedules and tagging In-Reply-To: <6ce70f91-d409-0a78-8100-0a8b81de5d5f@redhat.com> References: <6ce70f91-d409-0a78-8100-0a8b81de5d5f@redhat.com> Message-ID: Hi Andrew, I just took over your changes from the OpenJDK 8 Updates Wiki to the OpenJDK11 pages. Thanks for the nice update. Now the pages reflect the current process and their readability has significantly increased ?? As for the tagging then I think we have agreed to start with tagging in the dev branches the week after GA of the previous release. And when no changes occurred then we'd skip a tag and announce that on the mailing lists. This is what's written down in the Wiki. I fully share your arguments below. Best regards Christoph > -----Original Message----- > From: Andrew John Hughes > Sent: Donnerstag, 16. Mai 2019 21:44 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net; jdk8u-dev at openjdk.java.net; Lindenmaier, Goetz > ; Andrew Haley > Subject: Re: JDK11/8 Updates: process, schedules and tagging > > On 16/05/2019 10:57, Langer, Christoph wrote: > > Hi, > > > > > > > > after we had the discussion about the OpenJDK 8/11 release process and > > schedule [0], I?d like to explicitly spell out the current status and > > update the Wiki pages. > > > > > > > > It seems like we have agreed to a 3 phase model > > > > > > > > 1. Development > > > > 2. Rampdown (RDP2) > > > > 3. Freeze > > > > > > > > I?ve updated the timelines on the Wiki pages [1], [2] now accordingly. > > Please check/review. > > > > Thanks. I'll review the 8u page and check it matches the process I'm > following. > > I do think "RDP2" should be avoided as there is no "RDP1". > > > > > > > I would short-summarize our process like this: > > > > During development phase, changes go into the development repositories > > (jdk8u-dev/jdk11u-dev) and weekly tagging will be done in there. When > > the release repositories (jdk8u/jdk11u) aren?t blocked by > > rampdown/freeze of the previous release, the tags will be synced on a > > weekly basis to the release repositories. When rampdown of a release > > starts, merges from dev to release repositories are suspended and RDP2 > > approved changes have to be pushed to the release repositories. From > > that time merges happen from release->dev. After the freeze tag, no > > changes must go into the release repository while the CPU is assembled > > non publicly. After release, the CPU is merged back to the open > > repositories. > > Yes: > > Dev phase: dev tagged, dev->master > Rampdown phase: master tagged, master->dev > Freeze phase: no changes to master > Release: CPU changes pushed to master, master->dev > > > > > > > > > Is that our common understanding? If I get no objections, I?ll update > > the process description pages [3] and [4] accordingly. > > > > > > > > I furthermore have 2 questions / things to clarify. > > > > > > > > a) Will we tag in the dev-repositories right from the start? E.g. will > > we start tagging 11.0.5 right after the 11.0.4 RDP2 integration from > > 11u-dev to 11u in the week after May 28? > > > > ??? - I would suggest to do so. > > We do tag that point as -b00, I believe. > > If you mean do we start weekly tags of release x+1 in dev once release x > is in rampdown, then no, I don't plan to for 8u. If you have the cycles > to do so for 11, you can, but I need that time - particularly the freeze > period - to prepare, build and test the imminent releases. > > Also, I don't really see the point when there is nowhere to promote the > build to, as master is still on release x. > > That does mean that b01 will run over a longer period than other tags, > but I don't see that as a particular problem. > > > > > b) Will we also do a weekly tag when no changes happened after the > > previous tag? This should probably be a rare case given the current > > activities but we should have a guideline for that. > > > > ??? - My feeling would be to skip the tag then. I can?t see any value in > > this. > > > > I agree with skipping such empty tags, with an appropriate list > announcement. > > I think the predictability argument is already lost in the final stages > where we may have to add multiple tags in secret during the addition of > the security patches. On the other hand, tagging periods with no changes > introduces the possibility of a lot of needless work testing unchanged > sources. > > I think it's easier to convey the message that a tag is being skipped - > which someone who notices the lack of a new tag may look for - than it > is to tag and have unknown users downstream building and testing > something with no changes. > > The problem with comparing with Oracle processes is that their process > is largely internal and so there are not the same potential > communication issues. > > I think this is unlikely during the development stage, but more likely > during the rampdown if nothing is critical enough to be included in the > imminent release. > > My answer to both questions is concerned more with the reality of the > workload involved than pointlessly sticking to an agreed protocol, when > our limited resources could be better utilised. > > > > > > > May I please have your feedback on that (especially from the Andrews ??) > > > > > > > > Thanks > > > > Christoph > > > > > > > > [0] > > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019- > April/000996.html > > > > [1] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u > > > > [2] https://wiki.openjdk.java.net/display/jdk8u/Main > > > > [3] > > > https://wiki.openjdk.java.net/display/JDKUpdates/Detailed+Process+Descri > ption > > > > > > [4] > https://wiki.openjdk.java.net/display/jdk8u/Detailed+Process+Description > > > > > > > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew From adinn at redhat.com Tue May 28 15:21:10 2019 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 28 May 2019 16:21:10 +0100 Subject: RFR: 8202884 [backport]: SA: Attach/detach might fail on Linux if debugee application create/destroy threads during attaching Message-ID: I'd like to request a review for a backport of JDK-8202884 to jdk8u. The original patch does not apply cleanly. A modified patch is provided here: changeset: http://cr.openjdk.java.net/~adinn/8202884/ 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 adinn at redhat.com Tue May 28 15:21:14 2019 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 28 May 2019 16:21:14 +0100 Subject: RFR: 8176237 [backport]: (fs) java/nio/file/FileStore/Basic.java should conditionally check FileStores Message-ID: I'd like to request a review for a backport of JDK-8176237 to jdk8u. The original patch does not apply cleanly. A modified patch is provided here: changeset: http://cr.openjdk.java.net/~adinn/8176237/ 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 adinn at redhat.com Tue May 28 15:21:23 2019 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 28 May 2019 16:21:23 +0100 Subject: RFR: 8173910 [backport]: (fs) java/nio/file/FileSystem/Basic.java should conditionally check FileStores Message-ID: I'd like to request a review for a backport of JDK-8173910 to jdk8u. The original patch does not apply cleanly. A modified patch is provided here: changeset: http://cr.openjdk.java.net/~adinn/8173910/ Note that this patch assumes prior backport of the patch for JDK-8176237 which I have just sent out an RFR for. 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 aph at redhat.com Tue May 28 15:21:55 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 28 May 2019 16:21:55 +0100 Subject: OpenJDK 8u/11u release information In-Reply-To: <9ED31317-5AF2-4DA5-A96B-744E7CE6F1B6@azul.com> References: <0884e5fb-1e37-3ac7-7fd4-da8796faf9b3@ubuntu.com> <9ED31317-5AF2-4DA5-A96B-744E7CE6F1B6@azul.com> Message-ID: <0020169d-e939-343c-ab9d-654bd55094ae@redhat.com> On 5/28/19 1:51 AM, Gil Tene wrote: > What is "new" (AFAIK), specifically in 8u and 11u (and not in other > projects thus far), is the posting of project-lead blessed, > TCK-tested builds of "vanilla" released (as well as EA) sources of > 8u and 11u (see > e.g. https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009105.html > and subsequent discussions) at some external location. This practice is not new, it's a continuation of what Oracle used to do with their OpenJDK build releases, and still do with OpenJDK 12: https://jdk.java.net/12/ -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gil at azul.com Tue May 28 15:58:47 2019 From: gil at azul.com (Gil Tene) Date: Tue, 28 May 2019 15:58:47 +0000 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: <875zpwkxxj.fsf@oldenburg2.str.redhat.com> References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> <5491A2A5-32D1-42D9-99E4-2ACE2927C9FD@azul.com> <875zpwkxxj.fsf@oldenburg2.str.redhat.com> Message-ID: <7A083937-34F3-4C55-85B6-D848DD0EC4AA@azul.com> > On May 27, 2019, at 3:13 AM, Florian Weimer wrote: > > * Gil Tene: > >> root at 020dc36b9046:/# java -version >> openjdk version "1.8.0_212" >> OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1~deb9u1-b01) >> OpenJDK 64-Bit Server VM (build 25.212-b01, mixed mode) >> root at 020dc36b9046:/# > > I wonder if the core technical issue is this: Debian stretch currently > packages OpenJDK 8 8u212-b01, when it should be packaging 8u212-b03 or > 8u212-b04 (which one isn't clear, the release announcement > > was for 8u212-b03, not for 8u212-b04 or 8u212-ga). > > My understanding is that 8u212-b01 is a version identifier created by > the jdk8u project, and based on a quick check, it matches what Debian > identifies as its upstream sources (except for some stripping of system > library components). But it's not the most current release. 8u212-b01 is NOT an OpenJDK 8u release. Not in any form, current or otherwise. Let's be very clear here since this is at the heart of these (misunderstandings?): Releases are identified with tags. Tags are not releases. "8u212-b01" was a tag (in mercurial) used during the active development of 8u212, well before it was released. It in no way identifies an OpenJDK 8u release, and has no "release with this tag exists" implications. An entire month of additional code development and integration followed this tag point, before an actual release was arrived at, declared, and tagged. The 8u project tags source code at various points in time on the way to eventual release, and has done so for many years. Tags are often chosen at arbitrary points in time (e.g. they might appear weekly during a rampdown period). See example of when tags are used in a weekly progression: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/009309.html https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/009360.html https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/009388.html 8u212-b01 was used in e.g. https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-March/008939.html and nothing in the 8u-dev list attempted to indicate any sort of release (not even an "EA" thing) at the time. > > Thanks, > Florian From gil at azul.com Tue May 28 16:09:26 2019 From: gil at azul.com (Gil Tene) Date: Tue, 28 May 2019 16:09:26 +0000 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> <5491A2A5-32D1-42D9-99E4-2ACE2927C9FD@azul.com> <875zpwkxxj.fsf@oldenburg2.str.redhat.com> Message-ID: <0EDB372B-2A7E-49EA-9E45-0CD183BD3A99@azul.com> > On May 27, 2019, at 3:19 AM, Martijn Verburg wrote: > > On Mon, 27 May 2019 at 11:13, Florian Weimer > wrote: > * Gil Tene: > > > root at 020dc36b9046:/# java -version > > openjdk version "1.8.0_212" > > OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1~deb9u1-b01) > > OpenJDK 64-Bit Server VM (build 25.212-b01, mixed mode) > > root at 020dc36b9046:/# > > I wonder if the core technical issue is this: Debian stretch currently > packages OpenJDK 8 8u212-b01, when it should be packaging 8u212-b03 or > 8u212-b04 (which one isn't clear, the release announcement > > > was for 8u212-b03, not for 8u212-b04 or 8u212-ga). > > My understanding is that 8u212-b01 is a version identifier created by > the jdk8u project, and based on a quick check, it matches what Debian > identifies as its upstream sources (except for some stripping of system > library components). But it's not the most current release. > > It's one of the challenges, the rest of the world doesn't necessarily know about the new `-ga` tag that we use to designate releases, so we need to go and help them. Let's be clear about what the new (as in "additional") -ga tag is, in order to avoid the misunderstanding (that you can see in other threads) that somehow OpenJDK has just now started declaring releases: The notion of a "-ga" tag was added recently as a convenience mechanism to help people "identify snapshots of GA releases in Mercurial history without having to know the build number of the GA release". (see https://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-October/007940.html for initial discussion). To quote from there: "For example, to obtain JDK 10.0.2 GA sources today, one issues the `hg update -r jdk-10.0.2+13` command. With the proposed enhancement, `hg update -r jdk-10.0.2-ga` could have been used." [GA and other] Releases existed long before this tag was added, and every [GA and other] Release has a known tag number. The "-ga" tag is a welcome addition, and makes it much easier (fewer steps) to find the sources for a release, as well as programmatically watch for ones to appear. > > I've also replied separately to this thread (with a meeting request) but cut out the OpenJDK mailing lists as it's really the Debian distro list that we should be discussing this on. > If folks feel otherwise, let me know and I'll CC these lists back in. > > Cheers, > Martijn > > > Thanks, > Florian From gnu.andrew at redhat.com Tue May 28 16:50:35 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 28 May 2019 17:50:35 +0100 Subject: [8u] RFR 8055705: Rename UnixPrintServiceLookup and Win32PrintServiceLookup as a platform neutral class name In-Reply-To: References: Message-ID: <9059c2e9-e472-5536-9f0e-c027808762a0@redhat.com> On 28/05/2019 13:30, Zhengyu Gu wrote: > Hi, > > Please review this backport to 8u. The patch applied largely clean after > file path changes. But instead of using platform-dependent META-INFO > service configuration file, I kept old mechanism to avoid pulling in > more changesets, and updated service configuration in following files: > > src/solaris/classes/sun/print/services/javax.print.PrintServiceLookup > src/windows/classes/sun/print/services/javax.print.PrintServiceLookup > > JDK9 bug: https://bugs.openjdk.java.net/browse/JDK-8055705 > Original patch: http://hg.openjdk.java.net/jdk9/client/jdk/rev/8278952344bc > > JDK8u backport: http://cr.openjdk.java.net/~zgu/JDK-8055705-8u/webrev.00/ > > Thanks, > > -Zhengyu The webrev is not showing the file moves as renames, but as new files, making it hard to compare to 11u. Your previous webrev for 8153732 had it right. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From zgu at redhat.com Tue May 28 16:59:20 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 28 May 2019 12:59:20 -0400 Subject: [8u] RFR 8055705: Rename UnixPrintServiceLookup and Win32PrintServiceLookup as a platform neutral class name In-Reply-To: <9059c2e9-e472-5536-9f0e-c027808762a0@redhat.com> References: <9059c2e9-e472-5536-9f0e-c027808762a0@redhat.com> Message-ID: <36008042-1063-1366-af20-4a311329fd7b@redhat.com> On 5/28/19 12:50 PM, Andrew John Hughes wrote: > > > On 28/05/2019 13:30, Zhengyu Gu wrote: >> Hi, >> >> Please review this backport to 8u. The patch applied largely clean after >> file path changes. But instead of using platform-dependent META-INFO >> service configuration file, I kept old mechanism to avoid pulling in >> more changesets, and updated service configuration in following files: >> >> src/solaris/classes/sun/print/services/javax.print.PrintServiceLookup >> src/windows/classes/sun/print/services/javax.print.PrintServiceLookup >> >> JDK9 bug: https://bugs.openjdk.java.net/browse/JDK-8055705 >> Original patch: http://hg.openjdk.java.net/jdk9/client/jdk/rev/8278952344bc >> >> JDK8u backport: http://cr.openjdk.java.net/~zgu/JDK-8055705-8u/webrev.00/ >> >> Thanks, >> >> -Zhengyu > > The webrev is not showing the file moves as renames, but as new files, > making it hard to compare to 11u. Your previous webrev for 8153732 had > it right. Because original patch is not showing moves, but deletes and addes. e.g. --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java Fri Oct 10 09:03:28 2014 -0700 --- a/src/java.desktop/unix/classes/sun/print/UnixPrintServiceLookup.java Fri Oct 10 16:07:18 2014 +0400 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 -Zhengyu > > Thanks, > From gnu.andrew at redhat.com Tue May 28 17:01:50 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 28 May 2019 18:01:50 +0100 Subject: RFR: 8019816: [TEST_BUG][macosx] closed/java/awt/BasicStroke/DashZeroWidth.java not on EDT In-Reply-To: References: <14fb8769-4d6f-5e63-1250-574c7cd73c65@redhat.com> Message-ID: <7e98a3a4-e066-f3b8-c056-0b888e6decc3@redhat.com> On 28/05/2019 15:31, Zhengyu Gu wrote: > I don't think you need RFR if patch applies cleanly. > > -Zhengyu > > On 5/27/19 4:43 PM, Roman Kennke wrote: >> This is a straightforward backport from the original jdk10 fix to jdk8u, >> only adjusted new files locations. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8019816 >> Original fix: >> http://hg.openjdk.java.net/jdk/jdk/rev/080c3ab73c8d >> >> JDK8u-backport: >> http://cr.openjdk.java.net/~rkennke/backport-jdk8-JDK-8019816/webrev.00/ >> >> Good? >> >> Thanks, >> Roman >> Yeah, if it applies fine - with appropriate file renames - there's no need for a review. As this just adds two files, there's nothing actually being patched :) Do the tests work on 8u? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue May 28 17:02:57 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 28 May 2019 18:02:57 +0100 Subject: JDK11/8 Updates: process, schedules and tagging In-Reply-To: References: <6ce70f91-d409-0a78-8100-0a8b81de5d5f@redhat.com> Message-ID: On 28/05/2019 16:04, Langer, Christoph wrote: > Hi Andrew, > > I just took over your changes from the OpenJDK 8 Updates Wiki to the OpenJDK11 pages. Thanks for the nice update. Now the pages reflect the current process and their readability has significantly increased ?? > > As for the tagging then I think we have agreed to start with tagging in the dev branches the week after GA of the previous release. And when no changes occurred then we'd skip a tag and announce that on the mailing lists. This is what's written down in the Wiki. I fully share your arguments below. > > Best regards > Christoph > Thanks! :) I didn't want to make changes to the 11u version, as I think it's better that it reflects the mind of the person doing the work, but I'm glad you found my changes helpful in updating 11u. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From aph at redhat.com Tue May 28 17:10:51 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 28 May 2019 18:10:51 +0100 Subject: [8u] RFR: 8224671: AArch64: mauve System.arraycopy test failure Message-ID: Patch applies cleanly. https://bugs.openjdk.java.net/browse/JDK-8224671 http://cr.openjdk.java.net/~aph/8224671/jdk-test.changeset -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue May 28 17:15:49 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 28 May 2019 18:15:49 +0100 Subject: [8u] RFR: Backport 8224671: AArch64: mauve System.arraycopy test failure Message-ID: <6bf3c6d3-6d6c-9529-0a2d-aeeacc2785f4@redhat.com> Patch applies cleanly. https://bugs.openjdk.java.net/browse/JDK-8224671 http://cr.openjdk.java.net/~aph/8224671/jdk-test.changeset -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Tue May 28 17:17:48 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 28 May 2019 18:17:48 +0100 Subject: [8u] RFR: 8224671: AArch64: mauve System.arraycopy test failure In-Reply-To: References: Message-ID: <53c752b5-2479-e1fe-7190-e08c0a96ba58@redhat.com> On 28/05/2019 18:10, Andrew Haley wrote: > Patch applies cleanly. > > https://bugs.openjdk.java.net/browse/JDK-8224671 > > http://cr.openjdk.java.net/~aph/8224671/jdk-test.changeset > There is no assembler_aarch64.{c,h}pp in jdk8u. I think this may need to go to the aarch64-port-dev mailing list? (CCed) Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From rkennke at redhat.com Tue May 28 17:18:13 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 28 May 2019 19:18:13 +0200 Subject: RFR: 8019816: [TEST_BUG][macosx] closed/java/awt/BasicStroke/DashZeroWidth.java not on EDT In-Reply-To: <7e98a3a4-e066-f3b8-c056-0b888e6decc3@redhat.com> References: <14fb8769-4d6f-5e63-1250-574c7cd73c65@redhat.com> <7e98a3a4-e066-f3b8-c056-0b888e6decc3@redhat.com> Message-ID: <78bffbf6-84d4-b4d8-70be-d4ce36ed1f35@redhat.com> > On 28/05/2019 15:31, Zhengyu Gu wrote: >> I don't think you need RFR if patch applies cleanly. >> >> -Zhengyu >> >> On 5/27/19 4:43 PM, Roman Kennke wrote: >>> This is a straightforward backport from the original jdk10 fix to jdk8u, >>> only adjusted new files locations. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8019816 >>> Original fix: >>> http://hg.openjdk.java.net/jdk/jdk/rev/080c3ab73c8d >>> >>> JDK8u-backport: >>> http://cr.openjdk.java.net/~rkennke/backport-jdk8-JDK-8019816/webrev.00/ >>> >>> Good? >>> >>> Thanks, >>> Roman >>> > > Yeah, if it applies fine - with appropriate file renames - there's no > need for a review. As this just adds two files, there's nothing actually > being patched :) > > Do the tests work on 8u? yes, I verified this. Roman From aph at redhat.com Tue May 28 17:19:01 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 28 May 2019 18:19:01 +0100 Subject: [8u] RFR: 8224671: AArch64: mauve System.arraycopy test failure In-Reply-To: <53c752b5-2479-e1fe-7190-e08c0a96ba58@redhat.com> References: <53c752b5-2479-e1fe-7190-e08c0a96ba58@redhat.com> Message-ID: <070da8e5-75d4-40cf-916b-ef254744a23e@redhat.com> On 5/28/19 6:17 PM, Andrew John Hughes wrote: > > > On 28/05/2019 18:10, Andrew Haley wrote: >> Patch applies cleanly. >> >> https://bugs.openjdk.java.net/browse/JDK-8224671 >> >> http://cr.openjdk.java.net/~aph/8224671/jdk-test.changeset >> > > There is no assembler_aarch64.{c,h}pp in jdk8u. > > I think this may need to go to the aarch64-port-dev mailing list? (CCed) Sorry, wrong list. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Tue May 28 17:24:00 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 28 May 2019 18:24:00 +0100 Subject: [8u] RFR 8055705: Rename UnixPrintServiceLookup and Win32PrintServiceLookup as a platform neutral class name In-Reply-To: <36008042-1063-1366-af20-4a311329fd7b@redhat.com> References: <9059c2e9-e472-5536-9f0e-c027808762a0@redhat.com> <36008042-1063-1366-af20-4a311329fd7b@redhat.com> Message-ID: <2136fa67-9103-125b-7e18-102c6e56b91a@redhat.com> On 28/05/2019 17:59, Zhengyu Gu wrote: > > > On 5/28/19 12:50 PM, Andrew John Hughes wrote: >> >> >> On 28/05/2019 13:30, Zhengyu Gu wrote: >>> Hi, >>> >>> Please review this backport to 8u. The patch applied largely clean after >>> file path changes. But instead of using platform-dependent META-INFO >>> service configuration file, I kept old mechanism to avoid pulling in >>> more changesets, and updated service configuration in following files: >>> >>> src/solaris/classes/sun/print/services/javax.print.PrintServiceLookup >>> src/windows/classes/sun/print/services/javax.print.PrintServiceLookup >>> >>> JDK9 bug: https://bugs.openjdk.java.net/browse/JDK-8055705 >>> Original patch: >>> http://hg.openjdk.java.net/jdk9/client/jdk/rev/8278952344bc >>> >>> JDK8u backport: >>> http://cr.openjdk.java.net/~zgu/JDK-8055705-8u/webrev.00/ >>> >>> Thanks, >>> >>> -Zhengyu >> >> The webrev is not showing the file moves as renames, but as new files, >> making it hard to compare to 11u. Your previous webrev for 8153732 had >> it right. > > Because original patch is not showing moves, but deletes and addes. e.g. > > --- /dev/null??? Thu Jan 01 00:00:00 1970 +0000 > +++ > b/src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java Fri > Oct 10 09:03:28 2014 -0700 > > --- > a/src/java.desktop/unix/classes/sun/print/UnixPrintServiceLookup.java > Fri Oct 10 16:07:18 2014 +0400 > +++ /dev/null??? Thu Jan 01 00:00:00 1970 +0000 > > > -Zhengyu > >> >> Thanks, >> The original patch I'm looking at in 11u does: $ hg export -R ../jdk11 -r 1ef2879dc7ad|grep ^rename rename from jdk/src/java.desktop/unix/classes/META-INF/services/javax.print.PrintServiceLookup rename to jdk/src/java.desktop/share/classes/META-INF/services/javax.print.PrintServiceLookup rename from jdk/src/java.desktop/unix/classes/META-INF/services/javax.print.StreamPrintServiceFactory rename to jdk/src/java.desktop/share/classes/META-INF/services/javax.print.StreamPrintServiceFactory rename from jdk/src/java.desktop/unix/classes/sun/print/UnixPrintServiceLookup.java rename to jdk/src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java rename from jdk/src/java.desktop/windows/classes/sun/print/Win32PrintServiceLookup.java rename to jdk/src/java.desktop/windows/classes/sun/print/PrintServiceLookupProvider.java Regardless, can we make sure they are renames in 8u? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue May 28 17:39:23 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 28 May 2019 18:39:23 +0100 Subject: RFR: 8202884 [backport]: SA: Attach/detach might fail on Linux if debugee application create/destroy threads during attaching In-Reply-To: References: Message-ID: On 28/05/2019 16:21, Andrew Dinn wrote: > I'd like to request a review for a backport of JDK-8202884 to jdk8u. The > original patch does not apply cleanly. A modified patch is provided here: > > changeset: http://cr.openjdk.java.net/~adinn/8202884/ > > 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 > This looks mostly like a clean backport apart from: 11u: if (!ptrace_continue(pid, WSTOPSIG(status))) { print_error("Failed to correctly attach to VM. VM might HANG! [PTRACE_CONT failed, stopped by %d]\n", WSTOPSIG(statu\ s)); - return false; + return ATTACH_FAIL; } } else { - print_debug("waitpid(): Child process exited/terminated (status = 0x%x)\n", status); - return false; + print_debug("waitpid(): Child process %d exited/terminated (status = 0x%x)\n", pid, status); + return ATTACH_THREAD_DEAD; } 8u: if (!ptrace_continue(pid, WSTOPSIG(status))) { - print_error("Failed to correctly attach to VM. VM might HANG! [PTRACE_CONT failed, stopped by %d]\n", WSTOPSIG(statu\ s)); - return false; + print_debug("waitpid(): Child process %d exited/terminated (status = 0x%x)\n", pid, status); + return ATTACH_THREAD_DEAD; } } else { print_debug("waitpid(): Child process exited/terminated (status = 0x%x)\n", status); It looks like the ATTACH_FAIL change has been lost and the ATTACH_THREAD_DEAD change moved to the block above. Was this deliberate? Rest looks ok. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From rkennke at redhat.com Tue May 28 17:48:50 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 28 May 2019 19:48:50 +0200 Subject: RFR: 8019816: [TEST_BUG][macosx] closed/java/awt/BasicStroke/DashZeroWidth.java not on EDT In-Reply-To: <7e98a3a4-e066-f3b8-c056-0b888e6decc3@redhat.com> References: <14fb8769-4d6f-5e63-1250-574c7cd73c65@redhat.com> <7e98a3a4-e066-f3b8-c056-0b888e6decc3@redhat.com> Message-ID: <87ec6a6f-213a-ce04-f50d-bc8b201a072e@redhat.com> I accidentally pushed this together with: 8218020: Fix version number in mesa.md 3rd party legal file Shall back out the new files under '8218020' and re-add them under correct commit? Roman > On 28/05/2019 15:31, Zhengyu Gu wrote: >> I don't think you need RFR if patch applies cleanly. >> >> -Zhengyu >> >> On 5/27/19 4:43 PM, Roman Kennke wrote: >>> This is a straightforward backport from the original jdk10 fix to jdk8u, >>> only adjusted new files locations. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8019816 >>> Original fix: >>> http://hg.openjdk.java.net/jdk/jdk/rev/080c3ab73c8d >>> >>> JDK8u-backport: >>> http://cr.openjdk.java.net/~rkennke/backport-jdk8-JDK-8019816/webrev.00/ >>> >>> Good? >>> >>> Thanks, >>> Roman >>> > > Yeah, if it applies fine - with appropriate file renames - there's no > need for a review. As this just adds two files, there's nothing actually > being patched :) > > Do the tests work on 8u? > > Thanks, > From gnu.andrew at redhat.com Tue May 28 17:51:57 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 28 May 2019 18:51:57 +0100 Subject: RFR: 8019816: [TEST_BUG][macosx] closed/java/awt/BasicStroke/DashZeroWidth.java not on EDT In-Reply-To: <87ec6a6f-213a-ce04-f50d-bc8b201a072e@redhat.com> References: <14fb8769-4d6f-5e63-1250-574c7cd73c65@redhat.com> <7e98a3a4-e066-f3b8-c056-0b888e6decc3@redhat.com> <87ec6a6f-213a-ce04-f50d-bc8b201a072e@redhat.com> Message-ID: On 28/05/2019 18:48, Roman Kennke wrote: > I accidentally pushed this together with: > > 8218020: Fix version number in mesa.md 3rd party legal file > > Shall back out the new files under '8218020' and re-add them under > correct commit? > > Roman > > Yes, please do a 'hg rm' commit under 8218020 and then the correct push under 8019816 so it's recorded as fixed. 8u should allow duplicate bug IDs (has to due to all the merges), but if not, we'll have to file a bug ID. I'm hoping it does, because I intend to use it to do version updates under the one bug. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From hohensee at amazon.com Tue May 28 17:52:37 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 28 May 2019 17:52:37 +0000 Subject: [8u-dev] RFA (S): JDK-8210985: Update the default SSL session cache size to 20480 In-Reply-To: References: <06A96C44-3C2F-4135-B2BE-F8C1A14C6A93@amazon.com> Message-ID: <233BF768-28CC-48DE-B85C-F2E922D44B43@amazon.com> Thanks for the review, Andrew. New webrev: http://cr.openjdk.java.net/~phh/8210985/webrev.8u.01/ I commented on the 8u CSR https://bugs.openjdk.java.net/browse/JDK-8224770, asking who the 8u CSR approver(s) would be if the 8u maintainer(s) wanted to use the CSR process. For the time being, there's no 8u CSR process, so imo you can just approve the backport. :) I took a look at JDK-8154231. It doesn't apply cleanly, and looks like it needs a previous backport to do so. I didn't investigate further, but imo if we want to do so it should wait for 8u232. ?On 5/27/19, 7:09 AM, "Andrew John Hughes" wrote: On 24/05/2019 22:55, Hohensee, Paul wrote: > CSRs are definitely an Oracle thing. See https://wiki.openjdk.java.net/display/csr/Main. > > At Oracle, if you want to change an interface or behavior, you file a JBS issue to do the work, then file a CSR to get approval for the interface change. Closing a CSR == approving it. Finalized state means it's ready for review. One is supposed to get consensus before finalizing a CSR. > > If a backport involved a CSR, Oracle used to want a backport CSR, so the process was and maybe is: create a backport JBS issue, then a CSR for the backport issue, get the CSR approved, then get the backport approved. I don't know what Oracle's CSR backport process is now, but somehow I was under the impression that I should follow it. :) We could use Oracle's process for 8u and 11u, though it's a bit heavy-weight. It does have the advantage of thoroughly documenting interface/behavior changes in backports. I'm not sure who would do the backport CSR approvals: probably the Maintainers. I don't have a strong opinion either way, as long as I know what boxes I need to tick :-) > > I was incorrect/hasty about 8u clean patch application. 8u doesn't have SSLLogger, so that code gets dropped from SSLSessionContextImpl.getDefaultCacheLimit(). > > 8u webrev: http://cr.openjdk.java.net/~phh/8210985/webrev.8u.00/ There's an issue here with the changes to SSLSessionContextImpl.java where the doPrivileged is being lost. In the original version [0], it is changed to GetIntegerAction.privilegedGetProperty which is introduced by JDK-8154231 [1] & JDK-8155775 [2], which I think may be worth backporting themselves: public static Integer privilegedGetProperty(String theProp, int defaultVal) { Integer value; if (System.getSecurityManager() == null) { value = Integer.getInteger(theProp); } else { value = AccessController.doPrivileged( new GetIntegerAction(theProp)); } return (value != null) ? value : defaultVal; } In the 8u backport, the GetIntegerAction is created locally and not run inside a doPrivileged call: + int defaultCacheLimit = + new GetIntegerAction("javax.net.ssl.sessionCacheSize", + DEFAULT_MAX_CACHE_SIZE).run().intValue(); which is incorrect. I suggest something along the lines of: int defaultCacheLimit = java.security.AccessController.doPrivileged(new GetIntegerAction("javax.net.ssl.sessionCacheSize", DEFAULT_MAX_CACHE_SIZE)).intValue(); [0] https://hg.openjdk.java.net/jdk/jdk/rev/8a85d21d9616 [1] https://bugs.openjdk.java.net/browse/JDK-8154231 [2] https://bugs.openjdk.java.net/browse/JDK-8155775 -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From zgu at redhat.com Tue May 28 18:46:35 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 28 May 2019 14:46:35 -0400 Subject: [8u] RFR 8055705: Rename UnixPrintServiceLookup and Win32PrintServiceLookup as a platform neutral class name In-Reply-To: <2136fa67-9103-125b-7e18-102c6e56b91a@redhat.com> References: <9059c2e9-e472-5536-9f0e-c027808762a0@redhat.com> <36008042-1063-1366-af20-4a311329fd7b@redhat.com> <2136fa67-9103-125b-7e18-102c6e56b91a@redhat.com> Message-ID: <9c1f0ea0-39e5-ec21-ec6d-b59f0d09c2c3@redhat.com> On 5/28/19 1:24 PM, Andrew John Hughes wrote: > > > On 28/05/2019 17:59, Zhengyu Gu wrote: >> >> >> On 5/28/19 12:50 PM, Andrew John Hughes wrote: >>> >>> >>> On 28/05/2019 13:30, Zhengyu Gu wrote: >>>> Hi, >>>> >>>> Please review this backport to 8u. The patch applied largely clean after >>>> file path changes. But instead of using platform-dependent META-INFO >>>> service configuration file, I kept old mechanism to avoid pulling in >>>> more changesets, and updated service configuration in following files: >>>> >>>> src/solaris/classes/sun/print/services/javax.print.PrintServiceLookup >>>> src/windows/classes/sun/print/services/javax.print.PrintServiceLookup >>>> >>>> JDK9 bug: https://bugs.openjdk.java.net/browse/JDK-8055705 >>>> Original patch: >>>> http://hg.openjdk.java.net/jdk9/client/jdk/rev/8278952344bc >>>> >>>> JDK8u backport: >>>> http://cr.openjdk.java.net/~zgu/JDK-8055705-8u/webrev.00/ >>>> >>>> Thanks, >>>> >>>> -Zhengyu >>> >>> The webrev is not showing the file moves as renames, but as new files, >>> making it hard to compare to 11u. Your previous webrev for 8153732 had >>> it right. Updated: http://cr.openjdk.java.net/~zgu/JDK-8055705-8u/webrev.01/ Now, it shows moves. Thanks, -Zhengyu >> >> Because original patch is not showing moves, but deletes and addes. e.g. >> >> --- /dev/null??? Thu Jan 01 00:00:00 1970 +0000 >> +++ >> b/src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java Fri >> Oct 10 09:03:28 2014 -0700 >> >> --- >> a/src/java.desktop/unix/classes/sun/print/UnixPrintServiceLookup.java >> Fri Oct 10 16:07:18 2014 +0400 >> +++ /dev/null??? Thu Jan 01 00:00:00 1970 +0000 >> >> >> -Zhengyu >> >>> >>> Thanks, >>> > > > The original patch I'm looking at in 11u does: > > $ hg export -R ../jdk11 -r 1ef2879dc7ad|grep ^rename > rename from > jdk/src/java.desktop/unix/classes/META-INF/services/javax.print.PrintServiceLookup > rename to > jdk/src/java.desktop/share/classes/META-INF/services/javax.print.PrintServiceLookup > rename from > jdk/src/java.desktop/unix/classes/META-INF/services/javax.print.StreamPrintServiceFactory > rename to > jdk/src/java.desktop/share/classes/META-INF/services/javax.print.StreamPrintServiceFactory > rename from > jdk/src/java.desktop/unix/classes/sun/print/UnixPrintServiceLookup.java > rename to > jdk/src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java > rename from > jdk/src/java.desktop/windows/classes/sun/print/Win32PrintServiceLookup.java > rename to > jdk/src/java.desktop/windows/classes/sun/print/PrintServiceLookupProvider.java > > Regardless, can we make sure they are renames in 8u? > > Thanks, > From gnu.andrew at redhat.com Tue May 28 20:50:55 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 28 May 2019 21:50:55 +0100 Subject: RFR: 8176237 [backport]: (fs) java/nio/file/FileStore/Basic.java should conditionally check FileStores In-Reply-To: References: Message-ID: <79167957-ccf9-611f-352d-ea3d04807f05@redhat.com> On 28/05/2019 16:21, Andrew Dinn wrote: > I'd like to request a review for a backport of JDK-8176237 to jdk8u. The > original patch does not apply cleanly. A modified patch is provided here: > > changeset: http://cr.openjdk.java.net/~adinn/8176237/ > > > 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 > The patch looks ok. Do the patched tests pass? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue May 28 22:15:15 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 28 May 2019 23:15:15 +0100 Subject: Delay 8u Rampdown In-Reply-To: References: <51ee7ea8-2452-0e0e-46e1-373078658c9c@redhat.com> Message-ID: <4f1b3acf-0cfa-37ad-d51d-83fb59f4bf64@redhat.com> On 28/05/2019 09:38, Andrew Haley wrote: > On 5/27/19 2:32 PM, Andrew John Hughes wrote: >> >> On 25/05/2019 14:10, Andrew Haley wrote: >>> We have a few (about 20) bugs still open for jdk8u. Rampdown is >>> scheduled to begin on Wednesday, May 29th. All of the bugs are >>> assigned to people, and I don't expect them to take long. >>> >>> Monday is Memorial Day in the USA and may Bank Holiday in the UK. >>> Rather than put everything through the critical-bug-triage process I >>> think we should delay the onset of 8u rampdown by a couple of days. >>> If there are any bugs still outstanding by Friday they'll have to go >>> through triage. >>> >>> Comments? >> >> I suggest adding one more cycle, so rampdown is moved from this >> Wednesday to the following one. That's the cleanest solution without >> disrupting our process. >> >> Unless there are any objections, I'll update the wiki with that >> information tomorrow. > > Sounds good. > Thanks for updating the wiki :-) -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue May 28 22:23:10 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 28 May 2019 23:23:10 +0100 Subject: REMINDER: OpenJDK 8u222 rampdown starts Wednesday, June 5th Message-ID: <99ec4483-8918-897d-aeb3-2206fa50f4ce@redhat.com> Hi, I would like to remind everybody who is working on OpenJDK 8 updates that rampdown of 8u222 starts next Wednesday, June 5th (a week later than originally advertised). At that point in time, the jdk8u-dev will be declared frozen. Please push all changes you want to get to 8u222 before that date. The jdk8u-dev will be opened for commits shortly after this, once the bug system is updated to use 8u232 for commits and the jdk8u232-b00 tag is added. Please keep an eye on this mailing list for announcements regarding the status of jdk8u-dev. During the rampdown phase, critical changes for OpenJDK 8 updates may be requested with the label jdk8u-critical-request. Such requests should be limited to regressions and other blocking issues. Other fixes should be committed to jdk8u-dev to form part of 8u232. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue May 28 22:37:30 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 28 May 2019 23:37:30 +0100 Subject: [8u-dev] RFA (S): JDK-8210985: Update the default SSL session cache size to 20480 In-Reply-To: <233BF768-28CC-48DE-B85C-F2E922D44B43@amazon.com> References: <06A96C44-3C2F-4135-B2BE-F8C1A14C6A93@amazon.com> <233BF768-28CC-48DE-B85C-F2E922D44B43@amazon.com> Message-ID: <44fbcc78-c0ef-55c5-8512-bdf335b38694@redhat.com> On 28/05/2019 18:52, Hohensee, Paul wrote: > Thanks for the review, Andrew. > > New webrev: http://cr.openjdk.java.net/~phh/8210985/webrev.8u.01/ > > I commented on the 8u CSR https://bugs.openjdk.java.net/browse/JDK-8224770, > asking who the 8u CSR approver(s) would be if the 8u maintainer(s) wanted to use the CSR process. > > For the time being, there's no 8u CSR process, so imo you can just approve the backport. :) > > I took a look at JDK-8154231. It doesn't apply cleanly, and looks like it needs a previous backport to do so. I didn't investigate further, but imo if we want to do so it should wait for 8u232. > I'm happy for JDK-8154231 to wait, given the updated webrev has restored the use of doPrivileged. Good to go. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue May 28 22:40:05 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 28 May 2019 23:40:05 +0100 Subject: [8u] RFR: backport of JDK-8210886: Remove references in xwindows.md to non-existent files. In-Reply-To: References: <7fb414e9-e47d-b859-1359-77ded1616bf3@redhat.com> <7d04035b-8a93-62ea-65cc-ae94c6ec8d40@redhat.com> Message-ID: On 27/05/2019 20:59, Simon Tooke wrote: > > On 5/27/2019 11:22 AM, Andrew John Hughes wrote: >> >> On 27/05/2019 15:35, Simon Tooke wrote: >>> I would like to request a backport of? JDK-8210886: Remove references in >>> xwindows.md to non-existent files. >>> >>> In JDK8, all the copyright notices are in THIRD_PARTY_README, which is >>> identical in all copies in the subrepos. >>> >>> My patch only includes the base repo, but if it makes more sense, I can >>> create (identical) patches for all the subrepos. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210886 >>> >>> Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8210886/ >>> >>> Thank you for your time, >>> >>> -Simon >>> >>> >>> >> Yes, this will need to be applied to all subrepos as well. See >> Christoph's work on the similar >> https://bugs.openjdk.java.net/browse/JDK-8213213 as an example. >> >> Please add a jdk8u-fix-request label to JDK-8210886 so I can approve this. > > I've revised the webrev to include all directories, and added the tag. > > Thanks, > > -Simon > >> >> Thanks, Approved. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From zgu at redhat.com Wed May 29 00:03:00 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 28 May 2019 20:03:00 -0400 Subject: [8u] RFR 8212202: [Windows] Exception if no printers are installed Message-ID: Please review this 8u backport. The original patch applied cleanly. Bug: https://bugs.openjdk.java.net/browse/JDK-8212202 Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/03163eb3b2d4 8u backport patch: http://cr.openjdk.java.net/~zgu/JDK-8212202-8u/webrev.00/ Thanks, -Zhengyu From zgu at redhat.com Wed May 29 00:10:35 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 28 May 2019 20:10:35 -0400 Subject: [8u] RFR 8221412: lookupPrintServices() does not always update the list of Windows remote printers Message-ID: Please review this 8u backport. The original patch did not apply cleanly, there were minor conflicts, such as copyright years and indents, etc. Bug: https://bugs.openjdk.java.net/browse/JDK-8221412 Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/31c35004f300 8u backport: http://cr.openjdk.java.net/~zgu/JDK-8221412-8u/webrev.00/ Thanks, -Zhengyu From zgu at redhat.com Wed May 29 00:13:54 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 28 May 2019 20:13:54 -0400 Subject: [8u] RFR 8221263: [TEST_BUG] RemotePrinterStatusRefresh test is hard to use Message-ID: Please review this 8u backport. The original patch applied cleanly. Bug: https://bugs.openjdk.java.net/browse/JDK-8221263 Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/7f53d59593e2 8u backport: http://cr.openjdk.java.net/~zgu/JDK-8221263-8u/webrev.00/ Thanks, -Zhengyu From xxinliu at amazon.com Wed May 29 05:03:26 2019 From: xxinliu at amazon.com (Liu, Xin) Date: Wed, 29 May 2019 05:03:26 +0000 Subject: [8u] RFR: Backport of JDK-8222670: pathological case of JIT recompilation and code cache bloat In-Reply-To: <8167d8dc-3a13-98ad-079f-a859dbb958d2@redhat.com> References: <29367C39-36D1-4D17-BEB0-7B7C9D590435@amazon.com> <7DE1A3A6-4BCA-4C35-B992-08281C7A6C8B@amazon.com> <50f562af-6061-73f9-e974-bb3820022c9b@redhat.com> <8167d8dc-3a13-98ad-079f-a859dbb958d2@redhat.com> Message-ID: <38125AA4-F3B5-4391-AFD9-60222EA8277D@amazon.com> Hi, Andrew, Thank you to for the feedbacks. In particular, you found the source of changes across multiple repositories! I would rather not pull JDK-8054492. This commit focuses on one thing. Hi, Paul, Andrew has reviewed the following 3 patches. The order matters. I have verified them. Could you check them into 'jdk8u-dev'? 1/3 : https://cr.openjdk.java.net/~xliu/8059575/webrev.01/ 2/3: https://cr.openjdk.java.net/~xliu/8222670/webrev.8u-dev.02/ 3/3: https://cr.openjdk.java.net/~xliu/8223537/webrev.8u-dev/ Thanks, --lx ?On 5/24/19, 11:04 AM, "Andrew John Hughes" wrote: On 18/05/2019 18:20, Liu, Xin wrote: > Hi, Andrew, > Thanks for review it. Even though it's a backport patch, but the review workload as high as original one. Thanks. > My comments are inline. > > ?On 5/16/19, 11:47 AM, "jdk8u-dev on behalf of Andrew John Hughes" wrote: > > On 16/05/2019 18:23, Liu, Xin wrote: > > Hi, Reviewers, > > > > Could you review this backport patch? > > > > BUG: https://bugs.openjdk.java.net/browse/JDK-8222670 > > Webrev: https://cr.openjdk.java.net/~xliu/8222670/webrev.8u-dev/ > > > > I can?t cleanly apply the original patch to jdk8u. I made the following changes. > > > > 1. Include JDK-8223537. It solved suspend problem in blocking mode. One line change. > > I think this should be applied as a pre-requisite clean backport. Just > flag the bug with jdk8u-fix-request, no need for a separate review. > > I added jdk8u-fix-request for JDK-8223537 > The change can trivially apply on jdk8u-dev. Here is webrev. The order does matter, so let's call it 3/3 patch, or last one. > https://cr.openjdk.java.net/~xliu/8223537/webrev.8u-dev/ Ok, this has jdk8u-fix-yes now. Not sure why the webrev still lists 8222670. > > > 2. Shorter wait period. Otherwise, it?s easy to timeout for the test. It?s part of a JDK-8066770. > > https://cr.openjdk.java.net/~xliu/8222670/webrev.8u-dev/test/compiler/whitebox/CompilerWhiteBoxTest.java.udiff.html > > > > 8066770 relies on a lot of WhiteBox API that is not present in 8u so I'm > ok with including just this segment. > > > 1. +1 for Tier4MinInvocationThreshold and Tier4CompileThreshold. Otherwise, we have to backport JDK-8059604, which looks like complicated. > > > > https://cr.openjdk.java.net/~xliu/8222670/webrev.8u-dev/src/share/vm/prims/whitebox.cpp.udiff.html > > JDK-8059604 looks backportable, but I'm ok with including this commented > workaround for now. >>> > It is backportable. Actually, Paul suggested me do it. > I think it's complicated because JDK-8059604 is only part of campaign(JDK-8050853). Taking 8059604 alone to jdk8u seems not be very useful. > Further, I can't evaluate how much impact of changing thresholds from > to >= here. > https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ffe9c8c82350#l5.9 > > I'd like to +1 in whitebox.cpp because it's just a fixture of testing. It won't have runtime risk. Yes, I agree; do this for now and maybe look at that later. > > There seem to be two other changes being included here: > > 1. compileBroker.cpp changes > > These aren't in the original JDK-8222670. In 9, the != NULL test is > added by "8144964: JVMCI compilations need to be disabled until the > module system is initialized". 8 has neither JVMCI or a module system, > so not sure why this test is being added here. Why is this included? >>> > I do need the "task != NULL" protection here. Otherwise, remove(NULL/*task*/); will cash JVM. > If duplication happens , this patch will ditch the task from select_task and return NULL. > > For JDK-8144964, it?s all about JVMCI. That's why I don't want to backport it. Yes, I wasn't suggesting to do so, I just wondered why it was needed. Thanks for clarifying. > > > 2. skiponTieredCompilation in CompilerWhiteBoxTest.java > > This is part of "8059575: JEP-JDK-8043304: Test task: Tiered Compilation > level transition tests" which should also be backported as a pre-requisite. >>> > I backported 8059575 to jdk8u-dev. It's the 1/3 patch, or the first one to apply. > Here is webrev: https://cr.openjdk.java.net/~xliu/8059575/webrev.01/ > > I was wrong at JDK-8059575. It need to polish a little bit to pass all tests. > Here is my change: > 1) add compile_id in NMethod.java. > I got lost from here. > https://hg.openjdk.java.net/jdk9/jdk9/rev/c82ea5393dda That file move obscures things and I think it silently does include the addition of 'final'. The additions to whitebox.cpp & NMethod.java to add compile_id come from JDK-8054492. In both cases though, it's needed for the test, not the actual fix. So whether you want to backport this as well is up to you. It adds a Class.cast intrinsic. > 2) modify @library for LevelTransitionTest.java and ConstantGettersTransitionsTest.java. > It's because auxiliary library locates differently. That's follows from not having the file movement that takes place in 8066433, 8067223 & 8067337 which look odd now they are in the single jdk repository, but previously involved two repositories. The problems you see with tracking the history are because the files were added again in one changeset (to the root repository) and then the other copies removed in another changeset. I don't think we need to do that move as the only JDK test that currently uses whitebox is test/jdk/java/lang/ref/CleanerTest.java and java.lang.ref.Cleaner is part of the Java 9 API. So I'm fine with just changing @library. > > > > Thanks, > > --lx > > > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew > > > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From adinn at redhat.com Wed May 29 07:48:09 2019 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 29 May 2019 08:48:09 +0100 Subject: RFR: 8173910 [backport]: (fs) java/nio/file/FileSystem/Basic.java should conditionally check FileStores In-Reply-To: References: Message-ID: <26474fab-53f3-8608-9aeb-164ae51e15fe@redhat.com> On 28/05/2019 16:21, Andrew Dinn wrote: > I'd like to request a review for a backport of JDK-8173910 to jdk8u. The > original patch does not apply cleanly. A modified patch is provided here: > > changeset: http://cr.openjdk.java.net/~adinn/8173910/ > > Note that this patch assumes prior backport of the patch for JDK-8176237 > which I have just sent out an RFR for. n.b forgot to mention that after this patch the tests pass. 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 adinn at redhat.com Wed May 29 07:48:24 2019 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 29 May 2019 08:48:24 +0100 Subject: RFR: 8176237 [backport]: (fs) java/nio/file/FileStore/Basic.java should conditionally check FileStores In-Reply-To: <79167957-ccf9-611f-352d-ea3d04807f05@redhat.com> References: <79167957-ccf9-611f-352d-ea3d04807f05@redhat.com> Message-ID: On 28/05/2019 21:50, Andrew John Hughes wrote: > The patch looks ok. > > Do the patched tests pass? Yes, they do (sorry, forgot to mention that). 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 adinn at redhat.com Wed May 29 08:12:13 2019 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 29 May 2019 09:12:13 +0100 Subject: RFR: 8202884 [backport]: SA: Attach/detach might fail on Linux if debugee application create/destroy threads during attaching In-Reply-To: References: Message-ID: <2601fa86-41bb-6f06-79f5-0292354a7ac2@redhat.com> On 28/05/2019 18:39, Andrew John Hughes wrote: > This looks mostly like a clean backport apart from: > > . . . > It looks like the ATTACH_FAIL change has been lost and the > ATTACH_THREAD_DEAD change moved to the block above. Was this deliberate? No, that was most definitely an accident. Thank you for spotting it. I could not test the patch (it is tricky to reproduce the error scenario) but I did run a build. I was thinking "it ought not compile with 'return false' in there" but unfortunately it does! > Rest looks ok. I'll have updated the patch in place. Is it ok now? 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 guoge1 at huawei.com Wed May 29 13:38:58 2019 From: guoge1 at huawei.com (guoge (A)) Date: Wed, 29 May 2019 13:38:58 +0000 Subject: RFR: Backport of 8187667: Disable deprecation warning for readdir_r Message-ID: <9D8EABB130A7294DAD4857FC861F5FBF4AE0BED8@dggemm509-mbx.china.huawei.com> I wanted to build jdk8 with gcc 7.3.0, but I got a problem: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated [-Werror=deprecated-declarations] if((status = ::readdir_r(dirp, dbuf, &p)) != 0) { ^~~~~~~~~ note: declared here extern int readdir_r (DIR *__restrict __dirp, ^~~~~~~~~ It seems that the function readdir_r has been deprecated in glibc since version 2.24, and I find the fix had been merged into openjdk7u. So, Could we add a baskport to jdk8u? Bug: https://bugs.openjdk.java.net/browse/JDK-8187667 Patch: http://hg.openjdk.java.net/jdk10/master/rev/f5f2a2d13775 Openjdk7u Backport: https://bugs.openjdk.java.net/browse/JDK-8199962 Thanks Guo Ge From aph at redhat.com Wed May 29 15:00:33 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 29 May 2019 16:00:33 +0100 Subject: RFR: Backport of 8187667: Disable deprecation warning for readdir_r In-Reply-To: <9D8EABB130A7294DAD4857FC861F5FBF4AE0BED8@dggemm509-mbx.china.huawei.com> References: <9D8EABB130A7294DAD4857FC861F5FBF4AE0BED8@dggemm509-mbx.china.huawei.com> Message-ID: <606f964a-90b1-7485-cb22-fe0188123455@redhat.com> On 5/29/19 2:38 PM, guoge (A) wrote: > It seems that the function readdir_r has been deprecated in glibc since version 2.24, and I find the fix had been merged into openjdk7u. > So, Could we add a baskport to jdk8u? That's probably not a great idea because pragma GCC diagnostic push isn't supported on all GCCs. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Wed May 29 15:43:36 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 29 May 2019 16:43:36 +0100 Subject: RFR: Backport of 8187667: Disable deprecation warning for readdir_r In-Reply-To: <9D8EABB130A7294DAD4857FC861F5FBF4AE0BED8@dggemm509-mbx.china.huawei.com> References: <9D8EABB130A7294DAD4857FC861F5FBF4AE0BED8@dggemm509-mbx.china.huawei.com> Message-ID: <0d8ff522-7112-bc35-1f70-f4b3d73c7a57@redhat.com> On 29/05/2019 14:38, guoge (A) wrote: > I wanted to build jdk8 with gcc 7.3.0, but I got a problem: > > error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated [-Werror=deprecated-declarations] > if((status = ::readdir_r(dirp, dbuf, &p)) != 0) { > ^~~~~~~~~ > note: declared here > extern int readdir_r (DIR *__restrict __dirp, > ^~~~~~~~~ > > It seems that the function readdir_r has been deprecated in glibc since version 2.24, and I find the fix had been merged into openjdk7u. > So, Could we add a baskport to jdk8u? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187667 > Patch: http://hg.openjdk.java.net/jdk10/master/rev/f5f2a2d13775 > Openjdk7u Backport: https://bugs.openjdk.java.net/browse/JDK-8199962 > > Thanks > Guo Ge > I'm currently working on a backport of JDK-8202353 to fix this. Stay tuned. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Wed May 29 16:42:08 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 29 May 2019 17:42:08 +0100 Subject: [8u] RFR 8212202: [Windows] Exception if no printers are installed In-Reply-To: References: Message-ID: <8bd017ac-ae24-c0a3-668b-de919a2018c7@redhat.com> On 29/05/2019 01:03, Zhengyu Gu wrote: > Please review this 8u backport. The original patch applied cleanly. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212202 > Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/03163eb3b2d4 > > 8u backport patch: > http://cr.openjdk.java.net/~zgu/JDK-8212202-8u/webrev.00/ > > Thanks, > > -Zhengyu A review is not necessary for a clean backport. However, this does need JDK-8153732 to be applied first. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From aph at redhat.com Wed May 29 16:45:47 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 29 May 2019 17:45:47 +0100 Subject: JDK-8048782, which is designated for u222, fixes a bug, but it also introduces a new one. In-Reply-To: <38E6ACB8-B011-4381-ADBB-6F953346AF81@amazon.com> References: <5D3CFC22-12D6-452E-A99E-C51B2D3C3FA3@amazon.com> <38E6ACB8-B011-4381-ADBB-6F953346AF81@amazon.com> Message-ID: On 5/23/19 6:27 PM, Hohensee, Paul wrote: > Our current 8u222 solution would be to revert the patch for https://bugs.openjdk.java.net/browse/JDK-8221166 (which is the 8u222 backport issue for https://bugs.openjdk.java.net/browse/JDK-8048782). Fine by me. Please open a bug and create a webrev which reverts the patch, and mark it jdk8u-critical-request. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Wed May 29 16:51:51 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 29 May 2019 17:51:51 +0100 Subject: [OpenJDK 2D-Dev] JDK-8048782, which is designated for u222, fixes a bug, but it also introduces a new one. In-Reply-To: References: <5D3CFC22-12D6-452E-A99E-C51B2D3C3FA3@amazon.com> <38E6ACB8-B011-4381-ADBB-6F953346AF81@amazon.com> Message-ID: <7277b3f9-c517-9473-a9c3-87a877da8714@redhat.com> On 29/05/2019 17:45, Andrew Haley wrote: > On 5/23/19 6:27 PM, Hohensee, Paul wrote: >> Our current 8u222 solution would be to revert the patch for https://bugs.openjdk.java.net/browse/JDK-8221166 (which is the 8u222 backport issue for https://bugs.openjdk.java.net/browse/JDK-8048782). > > Fine by me. Please open a bug and create a webrev which reverts the patch, > and mark it jdk8u-critical-request. > jdk8u-fix-request is fine if done before next Wednesday, the 5th of June, when we enter rampdown. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Wed May 29 17:02:46 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 29 May 2019 18:02:46 +0100 Subject: [8u] RFR 8221412: lookupPrintServices() does not always update the list of Windows remote printers In-Reply-To: References: Message-ID: <83019aa3-679f-84cf-fd89-310bb1aae2b3@redhat.com> On 29/05/2019 01:10, Zhengyu Gu wrote: > Please review this 8u backport. The original patch did not apply > cleanly, there were minor conflicts, such as copyright years and > indents, etc. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221412 > Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/31c35004f300 > > 8u backport: http://cr.openjdk.java.net/~zgu/JDK-8221412-8u/webrev.00/ > > Thanks, > > -Zhengyu Looks good. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Wed May 29 17:14:03 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 29 May 2019 18:14:03 +0100 Subject: [8u] RFR: Backport of JDK-8222670: pathological case of JIT recompilation and code cache bloat In-Reply-To: <38125AA4-F3B5-4391-AFD9-60222EA8277D@amazon.com> References: <29367C39-36D1-4D17-BEB0-7B7C9D590435@amazon.com> <7DE1A3A6-4BCA-4C35-B992-08281C7A6C8B@amazon.com> <50f562af-6061-73f9-e974-bb3820022c9b@redhat.com> <8167d8dc-3a13-98ad-079f-a859dbb958d2@redhat.com> <38125AA4-F3B5-4391-AFD9-60222EA8277D@amazon.com> Message-ID: On 29/05/2019 06:03, Liu, Xin wrote: > Hi, Andrew, > > Thank you to for the feedbacks. In particular, you found the source of changes across multiple repositories! > I would rather not pull JDK-8054492. This commit focuses on one thing. > > Hi, Paul, > Andrew has reviewed the following 3 patches. The order matters. > I have verified them. Could you check them into 'jdk8u-dev'? > > 1/3 : https://cr.openjdk.java.net/~xliu/8059575/webrev.01/ > 2/3: https://cr.openjdk.java.net/~xliu/8222670/webrev.8u-dev.02/ > 3/3: https://cr.openjdk.java.net/~xliu/8223537/webrev.8u-dev/ > > Thanks, > --lx > > I'll push them for you. It'll give me a final chance to sanity check them and also co-ordinate with tagging for b05 today. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Wed May 29 17:14:53 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 29 May 2019 18:14:53 +0100 Subject: RFR: 8176237 [backport]: (fs) java/nio/file/FileStore/Basic.java should conditionally check FileStores In-Reply-To: References: <79167957-ccf9-611f-352d-ea3d04807f05@redhat.com> Message-ID: <5db9f9f0-7037-9712-4964-6eab0af1286a@redhat.com> On 29/05/2019 08:48, Andrew Dinn wrote: > On 28/05/2019 21:50, Andrew John Hughes wrote: >> The patch looks ok. >> >> Do the patched tests pass? > Yes, they do (sorry, forgot to mention that). > > 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 > No problem. Good to go then. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Wed May 29 17:28:27 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 29 May 2019 18:28:27 +0100 Subject: RFR: 8202884 [backport]: SA: Attach/detach might fail on Linux if debugee application create/destroy threads during attaching In-Reply-To: <2601fa86-41bb-6f06-79f5-0292354a7ac2@redhat.com> References: <2601fa86-41bb-6f06-79f5-0292354a7ac2@redhat.com> Message-ID: On 29/05/2019 09:12, Andrew Dinn wrote: > On 28/05/2019 18:39, Andrew John Hughes wrote: >> This looks mostly like a clean backport apart from: >> >> . . . >> It looks like the ATTACH_FAIL change has been lost and the >> ATTACH_THREAD_DEAD change moved to the block above. Was this deliberate? > > No, that was most definitely an accident. Thank you for spotting it. > > I could not test the patch (it is tricky to reproduce the error > scenario) but I did run a build. I was thinking "it ought not compile > with 'return false' in there" but unfortunately it does! > >> Rest looks ok. > I'll have updated the patch in place. Is it ok now? > > 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 > Thanks. Revised version looks good to go :) -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From xxinliu at amazon.com Wed May 29 17:53:46 2019 From: xxinliu at amazon.com (Liu, Xin) Date: Wed, 29 May 2019 17:53:46 +0000 Subject: [8u] RFR: Backport of JDK-8222670: pathological case of JIT recompilation and code cache bloat In-Reply-To: References: <29367C39-36D1-4D17-BEB0-7B7C9D590435@amazon.com> <7DE1A3A6-4BCA-4C35-B992-08281C7A6C8B@amazon.com> <50f562af-6061-73f9-e974-bb3820022c9b@redhat.com> <8167d8dc-3a13-98ad-079f-a859dbb958d2@redhat.com> <38125AA4-F3B5-4391-AFD9-60222EA8277D@amazon.com> Message-ID: Thanks. Andrew. Let me know if you run into problem. Thanks, --lx ?On 5/29/19, 10:14 AM, "Andrew John Hughes" wrote: On 29/05/2019 06:03, Liu, Xin wrote: > Hi, Andrew, > > Thank you to for the feedbacks. In particular, you found the source of changes across multiple repositories! > I would rather not pull JDK-8054492. This commit focuses on one thing. > > Hi, Paul, > Andrew has reviewed the following 3 patches. The order matters. > I have verified them. Could you check them into 'jdk8u-dev'? > > 1/3 : https://cr.openjdk.java.net/~xliu/8059575/webrev.01/ > 2/3: https://cr.openjdk.java.net/~xliu/8222670/webrev.8u-dev.02/ > 3/3: https://cr.openjdk.java.net/~xliu/8223537/webrev.8u-dev/ > > Thanks, > --lx > > I'll push them for you. It'll give me a final chance to sanity check them and also co-ordinate with tagging for b05 today. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From hohensee at amazon.com Wed May 29 20:29:59 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 29 May 2019 20:29:59 +0000 Subject: [8u-dev] RFA (S): JDK-8210985: Update the default SSL session cache size to 20480 In-Reply-To: <44fbcc78-c0ef-55c5-8512-bdf335b38694@redhat.com> References: <06A96C44-3C2F-4135-B2BE-F8C1A14C6A93@amazon.com> <233BF768-28CC-48DE-B85C-F2E922D44B43@amazon.com> <44fbcc78-c0ef-55c5-8512-bdf335b38694@redhat.com> Message-ID: <04E16E49-44D0-40CB-9250-A4A1C54B921C@amazon.com> Thanks, and pushed. Paul ?On 5/28/19, 3:38 PM, "Andrew John Hughes" wrote: On 28/05/2019 18:52, Hohensee, Paul wrote: > Thanks for the review, Andrew. > > New webrev: http://cr.openjdk.java.net/~phh/8210985/webrev.8u.01/ > > I commented on the 8u CSR https://bugs.openjdk.java.net/browse/JDK-8224770, > asking who the 8u CSR approver(s) would be if the 8u maintainer(s) wanted to use the CSR process. > > For the time being, there's no 8u CSR process, so imo you can just approve the backport. :) > > I took a look at JDK-8154231. It doesn't apply cleanly, and looks like it needs a previous backport to do so. I didn't investigate further, but imo if we want to do so it should wait for 8u232. > I'm happy for JDK-8154231 to wait, given the updated webrev has restored the use of doPrivileged. Good to go. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From hohensee at amazon.com Wed May 29 20:36:46 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 29 May 2019 20:36:46 +0000 Subject: [8u] RFR 8221263: [TEST_BUG] RemotePrinterStatusRefresh test is hard to use In-Reply-To: References: Message-ID: <870DD2C4-1251-4BA8-95A2-A296F647F2D0@amazon.com> Lgtm. Btw, you don't need a review for a patch that applies cleanly (net of line numbers and file locations). Paul ?On 5/28/19, 5:15 PM, "jdk8u-dev on behalf of Zhengyu Gu" wrote: Please review this 8u backport. The original patch applied cleanly. Bug: https://bugs.openjdk.java.net/browse/JDK-8221263 Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/7f53d59593e2 8u backport: http://cr.openjdk.java.net/~zgu/JDK-8221263-8u/webrev.00/ Thanks, -Zhengyu From zgu at redhat.com Wed May 29 23:59:48 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 29 May 2019 19:59:48 -0400 Subject: [8u] RFR 8221263: [TEST_BUG] RemotePrinterStatusRefresh test is hard to use In-Reply-To: <870DD2C4-1251-4BA8-95A2-A296F647F2D0@amazon.com> References: <870DD2C4-1251-4BA8-95A2-A296F647F2D0@amazon.com> Message-ID: On 5/29/19 4:36 PM, Hohensee, Paul wrote: > Lgtm. Btw, you don't need a review for a patch that applies cleanly (net of line numbers and file locations). Thanks, Paul. > > Paul > > ?On 5/28/19, 5:15 PM, "jdk8u-dev on behalf of Zhengyu Gu" wrote: > > Please review this 8u backport. The original patch applied cleanly. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221263 > Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/7f53d59593e2 > > 8u backport: http://cr.openjdk.java.net/~zgu/JDK-8221263-8u/webrev.00/ > > Thanks, > > -Zhengyu > > From OGATAK at jp.ibm.com Thu May 30 07:10:24 2019 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Thu, 30 May 2019 16:10:24 +0900 Subject: [8u-dev, ppc] RFR for (almost clean) backport of 8185969: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: References: <1bd63cd1-efbb-e70d-62e5-510d364f712b@redhat.com> <6459888e-be23-e362-3b09-c5cd4afa701f@redhat.com> Message-ID: Hi, Fixed a typo in the bug ID in the title. Since it looks there is no further objection, I added jdk8u-fix-request tag in the original bug report. Regards, Ogata Kazunori Ogata/Japan/IBM wrote on 2019/05/28 14:22:20: > From: Kazunori Ogata/Japan/IBM > To: Andrew John Hughes > Cc: "hotspot-compiler-dev at openjdk.java.net" dev at openjdk.java.net>, "jdk8u-dev at openjdk.java.net" dev at openjdk.java.net>, "Doerr, Martin" > Date: 2019/05/28 14:22 > Subject: Re: [EXTERNAL] Re: [8u-dev, ppc] RFR for (almost clean) backport > of 8185696: PPC64: Improve VSR support to use up to 64 registers > > Hi Andrew and Martin, > > Thank you for your comments. > > My original intention to change the copyright year was that I did some > work to apply the original patch to this file. I now realized I made no > change in the code that was modified in the original patch. So I agree > not updating the copyright year is more natural. > > I updated webrev: > http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8185969/webrev.03/ > > Regards, > Ogata > > Andrew John Hughes wrote on 2019/05/28 02:28:28: > > > From: Andrew John Hughes > > To: "Doerr, Martin" , Kazunori Ogata > > , "hotspot-compiler-dev at openjdk.java.net" > compiler-dev at openjdk.java.net>, "jdk8u-dev at openjdk.java.net" > dev at openjdk.java.net> > > Date: 2019/05/28 02:28 > > Subject: [EXTERNAL] Re: [8u-dev, ppc] RFR for (almost clean) backport of > > 8185696: PPC64: Improve VSR support to use up to 64 registers > > > > > > > > On 27/05/2019 17:41, Doerr, Martin wrote: > > > Hi, > > > > > > I think it's fine. > > > > > > I guess the copyright updates in the other files were part of other > > changes which have not been backported. > > > I don't think we have to update copyrights in backport changes other > > than what comes naturally with the change. > > > > > > Best regards, > > > Martin > > > > > > > > > > The change to the copyright header in assembler_ppc.hpp is an addition > > in this backport. So either that should be dropped or the same should be > > applied to register_ppc.{c,h}pp (the remaining file is already 2019). > > > > I tend towards dropping it, but we should at least be consistent within > > the same patch. > > > > Best regards, > > -- > > Andrew :) > > > > Senior Free Java Software Engineer > > Red Hat, Inc. (http://www.redhat.com) > > > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > > https://keybase.io/gnu_andrew > > > > [attachment "signature.asc" deleted by Kazunori Ogata/Japan/IBM] From gnu.andrew at redhat.com Thu May 30 12:57:29 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 30 May 2019 13:57:29 +0100 Subject: [8u] RFR 8055705: Rename UnixPrintServiceLookup and Win32PrintServiceLookup as a platform neutral class name In-Reply-To: <9c1f0ea0-39e5-ec21-ec6d-b59f0d09c2c3@redhat.com> References: <9059c2e9-e472-5536-9f0e-c027808762a0@redhat.com> <36008042-1063-1366-af20-4a311329fd7b@redhat.com> <2136fa67-9103-125b-7e18-102c6e56b91a@redhat.com> <9c1f0ea0-39e5-ec21-ec6d-b59f0d09c2c3@redhat.com> Message-ID: <6a896da3-1d4e-c88e-8c39-3a74d79e783b@redhat.com> On 28/05/2019 19:46, Zhengyu Gu wrote: > > > Updated: http://cr.openjdk.java.net/~zgu/JDK-8055705-8u/webrev.01/ > > Now, it shows moves. > > Thanks, > > -Zhengyu > >>> This version looks a lot better. Can you elaborate more on why the service file renames aren't included? As far as I can tell, it should be possible to move src/solaris/classes/sun/print/services/javax.print.PrintServiceLookup -> src/share/classes/sun/print/services/javax.print.PrintServiceLookup jdk/src/solaris/classes/sun/print/service/javax.print.StreamPrintServiceFactory -> jdk/src/share/classes/sun/print/services/javax.print.StreamPrintServiceFactory and remove the Windows versions in the same way, avoiding what are now identical files in windows and solaris subdirectories. I don't see the need to mirror the rename which adds META-INF into the path, from 8054834 e.g. rename from jdk/src/solaris/classes/sun/print/services/javax.print.PrintServiceLookup rename to jdk/src/java.desktop/unix/classes/META-INF/services/javax.print.PrintServiceLookup rename from jdk/src/solaris/classes/sun/print/services/javax.print.StreamPrintServiceFactory rename to jdk/src/java.desktop/unix/classes/META-INF/services/javax.print.StreamPrintServiceFactory rename from jdk/src/windows/classes/sun/print/services/javax.print.PrintServiceLookup rename to jdk/src/java.desktop/windows/classes/META-INF/services/javax.print.PrintServiceLookup rename from jdk/src/windows/classes/sun/print/services/javax.print.StreamPrintServiceFactory rename to jdk/src/java.desktop/windows/classes/META-INF/services/javax.print.StreamPrintServiceFactory -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From zgu at redhat.com Thu May 30 13:03:20 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 30 May 2019 09:03:20 -0400 Subject: [8u] RFR 8055705: Rename UnixPrintServiceLookup and Win32PrintServiceLookup as a platform neutral class name In-Reply-To: <6a896da3-1d4e-c88e-8c39-3a74d79e783b@redhat.com> References: <9059c2e9-e472-5536-9f0e-c027808762a0@redhat.com> <36008042-1063-1366-af20-4a311329fd7b@redhat.com> <2136fa67-9103-125b-7e18-102c6e56b91a@redhat.com> <9c1f0ea0-39e5-ec21-ec6d-b59f0d09c2c3@redhat.com> <6a896da3-1d4e-c88e-8c39-3a74d79e783b@redhat.com> Message-ID: On 5/30/19 8:57 AM, Andrew John Hughes wrote: > > > On 28/05/2019 19:46, Zhengyu Gu wrote: >> > >> >> Updated: http://cr.openjdk.java.net/~zgu/JDK-8055705-8u/webrev.01/ >> >> Now, it shows moves. >> >> Thanks, >> >> -Zhengyu >> >>>> > > This version looks a lot better. > > Can you elaborate more on why the service file renames aren't included? > As far as I can tell, it should be possible to move > > src/solaris/classes/sun/print/services/javax.print.PrintServiceLookup > -> > src/share/classes/sun/print/services/javax.print.PrintServiceLookup > > jdk/src/solaris/classes/sun/print/service/javax.print.StreamPrintServiceFactory > -> > jdk/src/share/classes/sun/print/services/javax.print.StreamPrintServiceFactory > > and remove the Windows versions in the same way, avoiding what are now > identical files in windows and solaris subdirectories. > > I don't see the need to mirror the rename which adds META-INF into the > path, from 8054834 e.g. > > rename from > jdk/src/solaris/classes/sun/print/services/javax.print.PrintServiceLookup > rename to > jdk/src/java.desktop/unix/classes/META-INF/services/javax.print.PrintServiceLookup > > rename from > jdk/src/solaris/classes/sun/print/services/javax.print.StreamPrintServiceFactory > rename to > jdk/src/java.desktop/unix/classes/META-INF/services/javax.print.StreamPrintServiceFactory > > rename from > jdk/src/windows/classes/sun/print/services/javax.print.PrintServiceLookup > rename to > jdk/src/java.desktop/windows/classes/META-INF/services/javax.print.PrintServiceLookup > > rename from > jdk/src/windows/classes/sun/print/services/javax.print.StreamPrintServiceFactory > rename to > jdk/src/java.desktop/windows/classes/META-INF/services/javax.print.StreamPrintServiceFactory Because we keep old (JDK8) service lookup mechanism, instead of migrating to newer one, which may need to pull in more changesets. Thanks, -Zhengyu > From martijnverburg at gmail.com Thu May 30 16:18:32 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 30 May 2019 17:18:32 +0100 Subject: OpenJDK 8u/11u release information In-Reply-To: <9ED31317-5AF2-4DA5-A96B-744E7CE6F1B6@azul.com> References: <0884e5fb-1e37-3ac7-7fd4-da8796faf9b3@ubuntu.com> <9ED31317-5AF2-4DA5-A96B-744E7CE6F1B6@azul.com> Message-ID: @Gil - this is the clearest answer I've seen yet, thank you! - would you be OK if we cribbed this and put it into a common wiki or in the README for OpenJDK? Cheers, Martijn On Tue, 28 May 2019 at 01:52, Gil Tene wrote: > > > > On May 27, 2019, at 6:34 AM, Matthias Klose wrote: > > > > Hi guys, > > The following is meant to be constructive and informational, so please > don't > read it as anything other than that. With that said, any and all "you are > plain > wrong, and here is why" followups to what I say below are welcome. > > > > > until recently we didn't have any source code releases for OpenJDK at > all. > > Not sure what you mean by this. Can you clarify what you mean when you > use the term "source code releases"? And how the thing you mean differs > from historical practice in OpenJDK? > > By my understanding OpenJDK, as a source code project, has been producing > source code releases pretty much since OpenJDK 6 was first > released, and has never stopped doing so, with continuing update releases > happening within major version project on a pretty regular basis. > > Version formats have changed across major java versions, tagging and > development processes going into a release also evolved and changed over > time. But at all points in the past several years, it's been pretty clear > when a > release happened, and what the source code for that release actually was. > > Binary builds of those released sources have been around for quite a > while as well. But in the past, these may not have been created > consistently > by the project lead for every update. > > What is "new" (AFAIK), specifically in 8u and 11u (and not in other > projects > thus far), is the posting of project-lead blessed, TCK-tested builds of > "vanilla" > released (as well as EA) sources of 8u and 11u (see e.g. > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009105.html > and subsequent discussions) at some external location. That's a very > positive > development, which I certainly hope will last and continue. But as noted in > that e-mail thread, those binaries are simply good, fully-TCK-tested > builds of > the released sources, posted to a known location. They did not change the > release process in any way. > > > I appreciate the effort to have source releases, however the gap to > produce > > binaries based on the source release is way to high. Instead of having > a dozen > > of configuration options to build a binary, please can we have a default > option > > which builds consumable packages by default? > > As things stand, across the various java version projects, the default > build modes > for all sources (including releases) produce consumable-by-the-builder > things, > intentionally labeled in ways that would scare people away from using the > bits as > a release. This is intentional, and is aimed to make sure that things that > look > like an actual release will only happen through intent, assertive actions > and > real choices about reported versions. > > E.g., when I build things using the defaults, I'd get stuff like: > > # bash ./configure > # make all > # build/linux-x86_64-normal-server-release/jdk/bin/java -version > openjdk version "1.8.0-internal" > OpenJDK Runtime Environment (build 1.8.0-internal-gil_2019_05_27_10_48-b00) > OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode) > > And that's a good thing. It prevents the accidental leakage of unfinished > bits > to others. > > To produce things you would give other people ("consumable" by others), > you need to intentionally make assertive (non-default) choices about > configuration. Normally, stating your update version, build version, and > milestone (or "pre" version) at the very least, and likely things like > vendor version, etc. Non of those have good "defaults", as you don't > want any of those to appear "by accident" in a build. > > The same is true for the sources of the actual quarterly releases, which > are > no more than a snapshot of the sources at the release point. > > To create a binary build that does not carry the "-internal" > identification, and > that has specific update and build numbers, you have to assertively > declare those > in the build configuration. But that's not very complicated. E.g. > > # bash ./configure --with-update-version=972 --with-build-number=b41 > --with-milestone="snapshot" > # make clean; make all > # build/linux-x86_64-normal-server-release/jdk/bin/java -version > openjdk version "1.8.0_972-snapshot" > OpenJDK Runtime Environment (build 1.8.0_972-snapshot-b41) > OpenJDK 64-Bit Server VM (build 25.972-b41, mixed mode) > > And with the special milestone called "fcs": > > # bash ./configure --with-update-version=982 --with-build-number=b42 > --with-milestone="fcs" > # make clean; make all > # build/linux-x86_64-normal-server-release/jdk/bin/java -version > openjdk version "1.8.0_982" > OpenJDK Runtime Environment (build 1.8.0_982-b42) > OpenJDK 64-Bit Server VM (build 25.982-b42, mixed mode) > > Note: > For OpenJDK 8u "fcs" is a special milestone. It is the specific thing you > need to do to > get rid of the milestone part of the versions string. Any other value > (including "", which > will revert to "internal") will show up in the version, because of this in > common/autoconf/spec.gmk.in : > > # These variables need to be generated here so that MILESTONE and > # JDK_BUILD_NUMBER can be overridden on the make command line. > ifeq ($(MILESTONE), fcs) > RELEASE=$(JDK_VERSION)$(BUILD_VARIANT_RELEASE) > else > RELEASE=$(JDK_VERSION)-$(MILESTONE)$(BUILD_VARIANT_RELEASE) > endif > > 11u is a little different. The release versioning is more specifically > defined (JEP322), > and the term for that "disqualifier" part for the version that tells you > it is not an > actual release (what 8u sets using --with-milestone) is the "pre-release > identifier" > ($PRE) part of the version string (set --with-version-pre). > > The default behaves the same with regards to "-internal" in the sense that > $PRE defaults > to "internal", a =nd must be assertively set to "" to get rid of it. But > in 11u a default for the > UPDATE portion of the JEP322 version string is typically baked into > make/autoconf/version-numbers (as opposed to having to be set via > --with-update-version > in 8u) > > so e.g.: > > # bash ./configure > # make all > # ./build/linux-x86_64-normal-server-release/jdk/bin/java -version > openjdk version "11.0.3-internal" 2019-04-16 > OpenJDK Runtime Environment (build 11.0.3-internal+0-adhoc.gil.11u1103rel) > OpenJDK 64-Bit Server VM (build 11.0.3-internal+0-adhoc.gil.11u1103rel, > mixed mode) > > But when you build something that is fit for others to consume, you will > still want to provide > a build number with --with-build-number, use -with-version-pre="" if you > want to say it is an > actual release (use e.g. "ea", or just leave blank to make it "internal" > otherwise), and in > addition set --with-version-opt to control that thing that defaults to > "adhoc.$USERNAME.$basedirname". Finally, > --with-vendor-version-string="18.9" is > considered "vanilla" (the year.month for Java SE 11), and that's where > non-vanilla > distros tend put their name in. > > So e.g.: > > # bash ./configure --with-version-build=42 --with-version-opt="" > --with-version-pre="" --with-vendor-version-string="18.9" > # make all > # ./build/linux-x86_64-normal-server-release/jdk/bin/java -version > openjdk version "11.0.3" 2019-04-16 > OpenJDK Runtime Environment 18.9 (build 11.0.3+42) > OpenJDK 64-Bit Server VM 18.9 (build 11.0.3+42, mixed mode) > > > > > OpenJDK doesn't have source releases until recently. Now we have, and > from my > > point of view, such a source release should only have a minimal set of > > configuration options to build a usable image. Things I would like to > see > > > > - I see it's important to display the version string as the first line > > of java -version. The source release should set that correctly. > > See above discussion about why (by long standing OpenJDK historical > practice) version strings are controlled by the build configuration, and > not > by the source code of a release. > > > > > - The OpenJDK source release ships with the vendor set to Oracle. > > Distributors set that to Azul, AdoptJDK, Debian, and probably other > > values. The binaries built by the OpenJDK itself set that to some > > sort of version string. An "unknown" vendor causes issue, because some > > software (LibreOffice, Gradle) uses or at least used that to check > > for a valid java installation. > > I'll assume you are referring to the "18.9" part in the version string > reported > by the "blessed by project lead" builds of the OpenJDK 11u 11.0.3 release: > > # ./openjdk-11.0.3+7/bin/java -version > openjdk version "11.0.3" 2019-04-16 > OpenJDK Runtime Environment 18.9 (build 11.0.3+7) > OpenJDK 64-Bit Server VM 18.9 (build 11.0.3+7, mixed mode) > > That 18.9 part is the "vendor version string" as defined by JEP322 (a new > property that did not exist in 8u). The choice of "18.9" (the year.month > that > Java SE 11 was released) is both the actual example vendor version string > shown in the JEP, and follows the precedent already set for "vanilla" > OpenJDK > builds of 11, 11.0.1, and 11.0.2 produced by the previous project lead > during > the first 6 months of 11u. (note that those were the OpenJDK build posted > by > Oracle, not the Oracle JDK builds). > > Since "18.9" was there as a vendor version string form the very start of > OpenJDK 11, we can assume that anything that knows how to parse JEP322 > versions will not have a problem with it. > > > > > - The version number should be used for both the source release and the > > binary package. E.g. the 11.0.3 source release is missing the -ga > > modifier. > > I'll assume that you are referring to version string reported by the > binary, > e.g. in response to -version, and not to package names, file names, or tags > in source control. > > The version string conventions for each existing Java SE version are > already established, and they (unfortunately) differ by major version. Thus > far, for all Java SE versions I know of which had an OpenJDK project > (6, 7, 8, 9, 10, 11, 12), neither Oracle nor OpenJDK builds have included a > positive (e.g. "-ga") indicator in the version strings of actually-released > versions. Instead, the long standing convention has been to include a > disqualifier ("-ea", "-internal", "-rc1") in non-released builds. The build > system defaults to using the -internal qualifier in all versions to date. > > Thus the current output from the project-lead blessed builds of 8u212 is: > # java -version > openjdk version "1.8.0_212" > OpenJDK Runtime Environment (build 1.8.0_212-b04) > OpenJDK 64-Bit Server VM (build 25.212-b04, mixed mode) > > (which, since there is no "disqualifier" in the version, means that it > reports as a build of an actual release). > > The technical term for this "disqualifier" has varied over the years. As > shown above, 8u calls it "milestone", 11u calls it a "pre-release > identifier". > But in all versions so far, *not* having it there means that it is a > release. > > Changing version string formats and conventions for indicating things > within a major java version is a generally bad idea. Adding "-ga" to actual > update releases of existing Java SE major versions is likely to blow up > a whole bunch of things. For one: a common ways to determine > that a version of OpenJDK or Oracle JDK is an actual released version > (as opposed to some ea/beta/rc1/internal/experimental thing) is to verify > that there is no "-XYZ" part (the milestone or $PRE) in the version string. > > Making changes to conventions across versions is quite possible, and > has been done multiple times (e.g. JEP 322, JEP 223). JEP 322 is what > we currently follow for 11u and above. If it insufficient for some reason, > and we want to change it yet again for e.g. OpenJDK 14, that's something > to discuss, I guess., But such changes should not affect existing Java SE > versions (12 and below). > > > > > - To include a package in a Linux distro, you have to use a monotonically > > increasing version number, and you have to follow the versioning > > constraints for the distro. So sometimes you have to juggle with the > > version numbers. E.g. for Debian/Ubuntu a second dash is problematic > > for version comparisons. I consider uploads to a development distro > > as essential, so I have to plan for these version numbers as well. > > Last time when I asked on the mailing lists, people seemed to be fine > > with the versioning, however if needed, we could document such > > versioning on the OpenJDK wiki? > > This is a good point (make sure your *package* names retain monotonically > growing version numbers), but since these rules apply to the package names > as seen by the distro (and not to the version strings) simple > distro-specific file > name conversion conventions seem to suffice. This is often necessary simply > because conventions and file name requirements can vary widely > between OSs (some don't like dots, some don't like dashes, some deal with > capitalization in interesting ways). > > E.g. you can convert every dash in the version string to to an underscore > in > the .deb or .rpm package names. > > An interesting problem shows up if the parsing of the version string > related fields appears to "go backwards" in your monotonic comparisons > (e.g. if the sorting is text based rather than numeric, and 11.0.10 would > be > considered earlier than 11.0.9, or 8u92 was considered to come after > 8u102). > I can think of a few ways to resolve that with package name conventions, > but I don't really know if this is a problem. Does debian compare > numeric sequence substrings in package name numerically, or > lexicographically? > > > > > - It would be very helpful to see directly in the binary how the build > > was configured. GCC is showing this information with > > gcc -v > > Python is showing that with > > python -c 'import sysconfig; > print(sysconfig.get_config_var("CONFIG_ARGS"))' > > Or maybe this already exists? > > > > Usually binaries in a distro come with a changelog, however sometimes > > even that is stripped away by re-distributors of binaries. > > > > - The configure system has some issues with invalid configure arguments, > e.g. > > configuring --with-version-build='' leads to a failing build. > > Setting --with-version-build="" works on 8u (it is a string). > > In 11u, you'd use --with-version-build=0 (it is an integer). > > > > > Matthias > > From gil at azul.com Thu May 30 16:32:32 2019 From: gil at azul.com (Gil Tene) Date: Thu, 30 May 2019 16:32:32 +0000 Subject: OpenJDK 8u/11u release information In-Reply-To: References: <0884e5fb-1e37-3ac7-7fd4-da8796faf9b3@ubuntu.com> <9ED31317-5AF2-4DA5-A96B-744E7CE6F1B6@azul.com> Message-ID: <26ACCD96-6EC2-417E-8307-03A8933A53D1@azul.com> Sure! > On May 30, 2019, at 9:18 AM, Martijn Verburg wrote: > > @Gil - this is the clearest answer I've seen yet, thank you! - would you be OK if we cribbed this and put it into a common wiki or in the README for OpenJDK? > > Cheers, > Martijn > > > On Tue, 28 May 2019 at 01:52, Gil Tene > wrote: > > > > On May 27, 2019, at 6:34 AM, Matthias Klose > wrote: > > > > Hi guys, > > The following is meant to be constructive and informational, so please don't > read it as anything other than that. With that said, any and all "you are plain > wrong, and here is why" followups to what I say below are welcome. > > > > > until recently we didn't have any source code releases for OpenJDK at all. > > Not sure what you mean by this. Can you clarify what you mean when you > use the term "source code releases"? And how the thing you mean differs > from historical practice in OpenJDK? > > By my understanding OpenJDK, as a source code project, has been producing > source code releases pretty much since OpenJDK 6 was first > released, and has never stopped doing so, with continuing update releases > happening within major version project on a pretty regular basis. > > Version formats have changed across major java versions, tagging and > development processes going into a release also evolved and changed over > time. But at all points in the past several years, it's been pretty clear when a > release happened, and what the source code for that release actually was. > > Binary builds of those released sources have been around for quite a > while as well. But in the past, these may not have been created consistently > by the project lead for every update. > > What is "new" (AFAIK), specifically in 8u and 11u (and not in other projects > thus far), is the posting of project-lead blessed, TCK-tested builds of "vanilla" > released (as well as EA) sources of 8u and 11u (see e.g. https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009105.html > and subsequent discussions) at some external location. That's a very positive > development, which I certainly hope will last and continue. But as noted in > that e-mail thread, those binaries are simply good, fully-TCK-tested builds of > the released sources, posted to a known location. They did not change the > release process in any way. > > > I appreciate the effort to have source releases, however the gap to produce > > binaries based on the source release is way to high. Instead of having a dozen > > of configuration options to build a binary, please can we have a default option > > which builds consumable packages by default? > > As things stand, across the various java version projects, the default build modes > for all sources (including releases) produce consumable-by-the-builder things, > intentionally labeled in ways that would scare people away from using the bits as > a release. This is intentional, and is aimed to make sure that things that look > like an actual release will only happen through intent, assertive actions and > real choices about reported versions. > > E.g., when I build things using the defaults, I'd get stuff like: > > # bash ./configure > # make all > # build/linux-x86_64-normal-server-release/jdk/bin/java -version > openjdk version "1.8.0-internal" > OpenJDK Runtime Environment (build 1.8.0-internal-gil_2019_05_27_10_48-b00) > OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode) > > And that's a good thing. It prevents the accidental leakage of unfinished bits > to others. > > To produce things you would give other people ("consumable" by others), > you need to intentionally make assertive (non-default) choices about > configuration. Normally, stating your update version, build version, and > milestone (or "pre" version) at the very least, and likely things like > vendor version, etc. Non of those have good "defaults", as you don't > want any of those to appear "by accident" in a build. > > The same is true for the sources of the actual quarterly releases, which are > no more than a snapshot of the sources at the release point. > > To create a binary build that does not carry the "-internal" identification, and > that has specific update and build numbers, you have to assertively declare those > in the build configuration. But that's not very complicated. E.g. > > # bash ./configure --with-update-version=972 --with-build-number=b41 --with-milestone="snapshot" > # make clean; make all > # build/linux-x86_64-normal-server-release/jdk/bin/java -version > openjdk version "1.8.0_972-snapshot" > OpenJDK Runtime Environment (build 1.8.0_972-snapshot-b41) > OpenJDK 64-Bit Server VM (build 25.972-b41, mixed mode) > > And with the special milestone called "fcs": > > # bash ./configure --with-update-version=982 --with-build-number=b42 --with-milestone="fcs" > # make clean; make all > # build/linux-x86_64-normal-server-release/jdk/bin/java -version > openjdk version "1.8.0_982" > OpenJDK Runtime Environment (build 1.8.0_982-b42) > OpenJDK 64-Bit Server VM (build 25.982-b42, mixed mode) > > Note: > For OpenJDK 8u "fcs" is a special milestone. It is the specific thing you need to do to > get rid of the milestone part of the versions string. Any other value (including "", which > will revert to "internal") will show up in the version, because of this in common/autoconf/spec.gmk.in : > > # These variables need to be generated here so that MILESTONE and > # JDK_BUILD_NUMBER can be overridden on the make command line. > ifeq ($(MILESTONE), fcs) > RELEASE=$(JDK_VERSION)$(BUILD_VARIANT_RELEASE) > else > RELEASE=$(JDK_VERSION)-$(MILESTONE)$(BUILD_VARIANT_RELEASE) > endif > > 11u is a little different. The release versioning is more specifically defined (JEP322), > and the term for that "disqualifier" part for the version that tells you it is not an > actual release (what 8u sets using --with-milestone) is the "pre-release identifier" > ($PRE) part of the version string (set --with-version-pre). > > The default behaves the same with regards to "-internal" in the sense that $PRE defaults > to "internal", a =nd must be assertively set to "" to get rid of it. But in 11u a default for the > UPDATE portion of the JEP322 version string is typically baked into > make/autoconf/version-numbers (as opposed to having to be set via --with-update-version > in 8u) > > so e.g.: > > # bash ./configure > # make all > # ./build/linux-x86_64-normal-server-release/jdk/bin/java -version > openjdk version "11.0.3-internal" 2019-04-16 > OpenJDK Runtime Environment (build 11.0.3-internal+0-adhoc.gil.11u1103rel) > OpenJDK 64-Bit Server VM (build 11.0.3-internal+0-adhoc.gil.11u1103rel, mixed mode) > > But when you build something that is fit for others to consume, you will still want to provide > a build number with --with-build-number, use -with-version-pre="" if you want to say it is an > actual release (use e.g. "ea", or just leave blank to make it "internal" otherwise), and in > addition set --with-version-opt to control that thing that defaults to > "adhoc.$USERNAME.$basedirname". Finally, --with-vendor-version-string="18.9" is > considered "vanilla" (the year.month for Java SE 11), and that's where non-vanilla > distros tend put their name in. > > So e.g.: > > # bash ./configure --with-version-build=42 --with-version-opt="" --with-version-pre="" --with-vendor-version-string="18.9" > # make all > # ./build/linux-x86_64-normal-server-release/jdk/bin/java -version > openjdk version "11.0.3" 2019-04-16 > OpenJDK Runtime Environment 18.9 (build 11.0.3+42) > OpenJDK 64-Bit Server VM 18.9 (build 11.0.3+42, mixed mode) > > > > > OpenJDK doesn't have source releases until recently. Now we have, and from my > > point of view, such a source release should only have a minimal set of > > configuration options to build a usable image. Things I would like to see > > > > - I see it's important to display the version string as the first line > > of java -version. The source release should set that correctly. > > See above discussion about why (by long standing OpenJDK historical > practice) version strings are controlled by the build configuration, and not > by the source code of a release. > > > > > - The OpenJDK source release ships with the vendor set to Oracle. > > Distributors set that to Azul, AdoptJDK, Debian, and probably other > > values. The binaries built by the OpenJDK itself set that to some > > sort of version string. An "unknown" vendor causes issue, because some > > software (LibreOffice, Gradle) uses or at least used that to check > > for a valid java installation. > > I'll assume you are referring to the "18.9" part in the version string reported > by the "blessed by project lead" builds of the OpenJDK 11u 11.0.3 release: > > # ./openjdk-11.0.3+7/bin/java -version > openjdk version "11.0.3" 2019-04-16 > OpenJDK Runtime Environment 18.9 (build 11.0.3+7) > OpenJDK 64-Bit Server VM 18.9 (build 11.0.3+7, mixed mode) > > That 18.9 part is the "vendor version string" as defined by JEP322 (a new > property that did not exist in 8u). The choice of "18.9" (the year.month that > Java SE 11 was released) is both the actual example vendor version string > shown in the JEP, and follows the precedent already set for "vanilla" OpenJDK > builds of 11, 11.0.1, and 11.0.2 produced by the previous project lead during > the first 6 months of 11u. (note that those were the OpenJDK build posted by > Oracle, not the Oracle JDK builds). > > Since "18.9" was there as a vendor version string form the very start of > OpenJDK 11, we can assume that anything that knows how to parse JEP322 > versions will not have a problem with it. > > > > > - The version number should be used for both the source release and the > > binary package. E.g. the 11.0.3 source release is missing the -ga > > modifier. > > I'll assume that you are referring to version string reported by the binary, > e.g. in response to -version, and not to package names, file names, or tags > in source control. > > The version string conventions for each existing Java SE version are > already established, and they (unfortunately) differ by major version. Thus > far, for all Java SE versions I know of which had an OpenJDK project > (6, 7, 8, 9, 10, 11, 12), neither Oracle nor OpenJDK builds have included a > positive (e.g. "-ga") indicator in the version strings of actually-released > versions. Instead, the long standing convention has been to include a > disqualifier ("-ea", "-internal", "-rc1") in non-released builds. The build > system defaults to using the -internal qualifier in all versions to date. > > Thus the current output from the project-lead blessed builds of 8u212 is: > # java -version > openjdk version "1.8.0_212" > OpenJDK Runtime Environment (build 1.8.0_212-b04) > OpenJDK 64-Bit Server VM (build 25.212-b04, mixed mode) > > (which, since there is no "disqualifier" in the version, means that it > reports as a build of an actual release). > > The technical term for this "disqualifier" has varied over the years. As > shown above, 8u calls it "milestone", 11u calls it a "pre-release identifier". > But in all versions so far, *not* having it there means that it is a release. > > Changing version string formats and conventions for indicating things > within a major java version is a generally bad idea. Adding "-ga" to actual > update releases of existing Java SE major versions is likely to blow up > a whole bunch of things. For one: a common ways to determine > that a version of OpenJDK or Oracle JDK is an actual released version > (as opposed to some ea/beta/rc1/internal/experimental thing) is to verify > that there is no "-XYZ" part (the milestone or $PRE) in the version string. > > Making changes to conventions across versions is quite possible, and > has been done multiple times (e.g. JEP 322, JEP 223). JEP 322 is what > we currently follow for 11u and above. If it insufficient for some reason, > and we want to change it yet again for e.g. OpenJDK 14, that's something > to discuss, I guess., But such changes should not affect existing Java SE > versions (12 and below). > > > > > - To include a package in a Linux distro, you have to use a monotonically > > increasing version number, and you have to follow the versioning > > constraints for the distro. So sometimes you have to juggle with the > > version numbers. E.g. for Debian/Ubuntu a second dash is problematic > > for version comparisons. I consider uploads to a development distro > > as essential, so I have to plan for these version numbers as well. > > Last time when I asked on the mailing lists, people seemed to be fine > > with the versioning, however if needed, we could document such > > versioning on the OpenJDK wiki? > > This is a good point (make sure your *package* names retain monotonically > growing version numbers), but since these rules apply to the package names > as seen by the distro (and not to the version strings) simple distro-specific file > name conversion conventions seem to suffice. This is often necessary simply > because conventions and file name requirements can vary widely > between OSs (some don't like dots, some don't like dashes, some deal with > capitalization in interesting ways). > > E.g. you can convert every dash in the version string to to an underscore in > the .deb or .rpm package names. > > An interesting problem shows up if the parsing of the version string > related fields appears to "go backwards" in your monotonic comparisons > (e.g. if the sorting is text based rather than numeric, and 11.0.10 would be > considered earlier than 11.0.9, or 8u92 was considered to come after 8u102). > I can think of a few ways to resolve that with package name conventions, > but I don't really know if this is a problem. Does debian compare > numeric sequence substrings in package name numerically, or > lexicographically? > > > > > - It would be very helpful to see directly in the binary how the build > > was configured. GCC is showing this information with > > gcc -v > > Python is showing that with > > python -c 'import sysconfig; print(sysconfig.get_config_var("CONFIG_ARGS"))' > > Or maybe this already exists? > > > > Usually binaries in a distro come with a changelog, however sometimes > > even that is stripped away by re-distributors of binaries. > > > > - The configure system has some issues with invalid configure arguments, e.g. > > configuring --with-version-build='' leads to a failing build. > > Setting --with-version-build="" works on 8u (it is a string). > > In 11u, you'd use --with-version-build=0 (it is an integer). > > > > > Matthias > From gnu.andrew at redhat.com Thu May 30 16:33:06 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 30 May 2019 17:33:06 +0100 Subject: [8u-dev, ppc] RFR for (almost clean) backport of 8185969: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: References: <1bd63cd1-efbb-e70d-62e5-510d364f712b@redhat.com> <6459888e-be23-e362-3b09-c5cd4afa701f@redhat.com> Message-ID: On 30/05/2019 08:10, Kazunori Ogata wrote: > Hi, > > Fixed a typo in the bug ID in the title. > > Since it looks there is no further objection, I added jdk8u-fix-request > tag in the original bug report. > > > Regards, > Ogata > The updated webrev looks fine now. However, please don't assume an acceptable review just because there is no objection. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Thu May 30 16:38:10 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 30 May 2019 17:38:10 +0100 Subject: RFR: 8173910 [backport]: (fs) java/nio/file/FileSystem/Basic.java should conditionally check FileStores In-Reply-To: <26474fab-53f3-8608-9aeb-164ae51e15fe@redhat.com> References: <26474fab-53f3-8608-9aeb-164ae51e15fe@redhat.com> Message-ID: On 29/05/2019 08:48, Andrew Dinn wrote: > On 28/05/2019 16:21, Andrew Dinn wrote: >> I'd like to request a review for a backport of JDK-8173910 to jdk8u. The >> original patch does not apply cleanly. A modified patch is provided here: >> >> changeset: http://cr.openjdk.java.net/~adinn/8173910/ >> >> Note that this patch assumes prior backport of the patch for JDK-8176237 >> which I have just sent out an RFR for. > n.b forgot to mention that after this patch the tests pass. > > 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 > Thanks. Looks good. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From hohensee at amazon.com Thu May 30 17:36:18 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 30 May 2019 17:36:18 +0000 Subject: [OpenJDK 2D-Dev] JDK-8048782, which is designated for u222, fixes a bug, but it also introduces a new one. In-Reply-To: <7277b3f9-c517-9473-a9c3-87a877da8714@redhat.com> References: <5D3CFC22-12D6-452E-A99E-C51B2D3C3FA3@amazon.com> <38E6ACB8-B011-4381-ADBB-6F953346AF81@amazon.com> <7277b3f9-c517-9473-a9c3-87a877da8714@redhat.com> Message-ID: <0E2E7888-E11E-4A68-8500-402DF69CFD94@amazon.com> I filed https://bugs.openjdk.java.net/browse/JDK-8225065 to revert https://bugs.openjdk.java.net/browse/JDK-8221166. Separate review request email forthcoming. Thanks, Paul ?On 5/29/19, 9:53 AM, "Andrew John Hughes" wrote: On 29/05/2019 17:45, Andrew Haley wrote: > On 5/23/19 6:27 PM, Hohensee, Paul wrote: >> Our current 8u222 solution would be to revert the patch for https://bugs.openjdk.java.net/browse/JDK-8221166 (which is the 8u222 backport issue for https://bugs.openjdk.java.net/browse/JDK-8048782). > > Fine by me. Please open a bug and create a webrev which reverts the patch, > and mark it jdk8u-critical-request. > jdk8u-fix-request is fine if done before next Wednesday, the 5th of June, when we enter rampdown. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From hohensee at amazon.com Thu May 30 17:42:36 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 30 May 2019 17:42:36 +0000 Subject: [8u-dev] RFR+RFA (S): JDK-8225065: Revert 8221166 (8u backport of 8048782) Message-ID: Please review and approve. Bug: https://bugs.openjdk.java.net/browse/JDK-8225065 Webrev: http://cr.openjdk.java.net/~phh/8225065/webrev.8u.00/ Reverted bug: https://bugs.openjdk.java.net/browse/JDK-8221166 Reverted patch: http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/d9da27985291 Discussion: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/009349.html Thanks, Paul From gnu.andrew at redhat.com Thu May 30 17:56:19 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 30 May 2019 18:56:19 +0100 Subject: [8u] RFR 8055705: Rename UnixPrintServiceLookup and Win32PrintServiceLookup as a platform neutral class name In-Reply-To: References: <9059c2e9-e472-5536-9f0e-c027808762a0@redhat.com> <36008042-1063-1366-af20-4a311329fd7b@redhat.com> <2136fa67-9103-125b-7e18-102c6e56b91a@redhat.com> <9c1f0ea0-39e5-ec21-ec6d-b59f0d09c2c3@redhat.com> <6a896da3-1d4e-c88e-8c39-3a74d79e783b@redhat.com> Message-ID: On 30/05/2019 14:03, Zhengyu Gu wrote: > > > On 5/30/19 8:57 AM, Andrew John Hughes wrote: >> >> >> On 28/05/2019 19:46, Zhengyu Gu wrote: >>> >> >>> >>> Updated: http://cr.openjdk.java.net/~zgu/JDK-8055705-8u/webrev.01/ >>> >>> Now, it shows moves. >>> >>> Thanks, >>> >>> -Zhengyu >>> >>>>> >> >> This version looks a lot better. >> >> Can you elaborate more on why the service file renames aren't included? >> As far as I can tell, it should be possible to move >> >> src/solaris/classes/sun/print/services/javax.print.PrintServiceLookup >> -> >> src/share/classes/sun/print/services/javax.print.PrintServiceLookup >> >> jdk/src/solaris/classes/sun/print/service/javax.print.StreamPrintServiceFactory >> >> -> >> jdk/src/share/classes/sun/print/services/javax.print.StreamPrintServiceFactory >> >> >> and remove the Windows versions in the same way, avoiding what are now >> identical files in windows and solaris subdirectories. >> >> I don't see the need to mirror the rename which adds META-INF into the >> path, from 8054834 e.g. >> >> rename from >> jdk/src/solaris/classes/sun/print/services/javax.print.PrintServiceLookup >> rename to >> jdk/src/java.desktop/unix/classes/META-INF/services/javax.print.PrintServiceLookup >> >> >> rename from >> jdk/src/solaris/classes/sun/print/services/javax.print.StreamPrintServiceFactory >> >> rename to >> jdk/src/java.desktop/unix/classes/META-INF/services/javax.print.StreamPrintServiceFactory >> >> >> rename from >> jdk/src/windows/classes/sun/print/services/javax.print.PrintServiceLookup >> rename to >> jdk/src/java.desktop/windows/classes/META-INF/services/javax.print.PrintServiceLookup >> >> >> rename from >> jdk/src/windows/classes/sun/print/services/javax.print.StreamPrintServiceFactory >> >> rename to >> jdk/src/java.desktop/windows/classes/META-INF/services/javax.print.StreamPrintServiceFactory >> > > Because we keep old (JDK8) service lookup mechanism, instead of > migrating to newer one, which may need to pull in more changesets. > > Thanks, > > -Zhengyu > > >> I'm not suggesting changing the lookup mechanism, just dispensing with duplicate copies of what are now the same file. This worked for me on GNU/Linux with a small Makefile change: https://cr.openjdk.java.net/~andrew/openjdk8/8055705/webrev.01/ Let me know if it works on Windows too. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From goetz.lindenmaier at sap.com Thu May 30 21:15:17 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 30 May 2019 21:15:17 +0000 Subject: jdk11u-dev is now switched to 11.0.5 In-Reply-To: References: <82b7dbfa-6b90-dfb8-496b-4267c47d60de@redhat.com> Message-ID: Hi Andrew, (sorry for the double mail, resent this to all.) > The level of bureaucratic overhead in these projects is getting absurd. We're > going to have to do something about it before we all drown. Yes, there is some overhead, it does not make things more simple. You could delegate some tasks. E.g., * I would volunteer to trigger the update of the JBS version For 11 whenever needed. * You could allow to push the version bump without jdk11u-fix-yes tag. It's obvious we need it. Further, I would propose that we exclude all changes Oracle pushes to their 11.0.x from the tagging if pushed to the open 11.0.x (same x!). They have already been judged to be good for downport by Oracle. The "Fix Request" comment should be added to the change nevertheless. This way one can know that a change is being worked on. Maybe we should note in the bug that it is a downport that went to Oracle's 11.0.x, so it's clear why it is not tagged. Best regards, Goetz. > -----Original Message----- > From: Andrew Haley > Sent: Thursday, May 30, 2019 11:17 AM > To: Lindenmaier, Goetz > Subject: Re: jdk11u-dev is now switched to 11.0.5 > > On 5/30/19 9:44 AM, Lindenmaier, Goetz wrote: > > > Could you please tag > > https://bugs.openjdk.java.net/browse/JDK-8224838 > > 8224838: Bump update version for OpenJDK: jdk-11.0.5 > > Done. > > The level of bureaucratic overhead in these projects is getting absurd. We're > going to have to do something about it before we all drown. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Thu May 30 21:56:48 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 30 May 2019 21:56:48 +0000 Subject: jdk11u-dev is now switched to 11.0.5 In-Reply-To: References: <82b7dbfa-6b90-dfb8-496b-4267c47d60de@redhat.com> Message-ID: Hi, > > The level of bureaucratic overhead in these projects is getting absurd. > We're > > going to have to do something about it before we all drown. > > Yes, there is some overhead, it does not make things more > simple. You could delegate some tasks. > > E.g., > * I would volunteer to trigger the update of the JBS version > For 11 whenever needed. > * You could allow to push the version bump without > jdk11u-fix-yes tag. It's obvious we need it. > > Further, I would propose that we exclude all changes Oracle > pushes to their 11.0.x from the tagging if pushed to > the open 11.0.x (same x!). > They have already been judged to be good for downport by Oracle. > The "Fix Request" comment should be added to the change > nevertheless. This way one can know that a change is being > worked on. Maybe we should note in the bug that it is a downport > that went to Oracle's 11.0.x, so it's clear why it is not tagged. Those seem good suggestions to me. I also think that you could extend the group of maintainers, that is, people who can approve backports. Andrew (Hughes) is already listed for 8u but 11u could also use additional approvers. However, if you do that, you should give some rules and criteria that the approvers have to follow. Best regards Christoph From zgu at redhat.com Fri May 31 02:07:08 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 30 May 2019 22:07:08 -0400 Subject: [8u] RFR 8055705: Rename UnixPrintServiceLookup and Win32PrintServiceLookup as a platform neutral class name In-Reply-To: References: <9059c2e9-e472-5536-9f0e-c027808762a0@redhat.com> <36008042-1063-1366-af20-4a311329fd7b@redhat.com> <2136fa67-9103-125b-7e18-102c6e56b91a@redhat.com> <9c1f0ea0-39e5-ec21-ec6d-b59f0d09c2c3@redhat.com> <6a896da3-1d4e-c88e-8c39-3a74d79e783b@redhat.com> Message-ID: >> >> Because we keep old (JDK8) service lookup mechanism, instead of >> migrating to newer one, which may need to pull in more changesets. >> >> Thanks, >> >> -Zhengyu >> >> >>> > > I'm not suggesting changing the lookup mechanism, just dispensing with > duplicate copies of what are now the same file. > > This worked for me on GNU/Linux with a small Makefile change: > > https://cr.openjdk.java.net/~andrew/openjdk8/8055705/webrev.01/ > > Let me know if it works on Windows too. Yes, works on Windows. Thanks, -Zhengyu > > Thanks, > From OGATAK at jp.ibm.com Fri May 31 04:54:16 2019 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Fri, 31 May 2019 13:54:16 +0900 Subject: [8u-dev, ppc] RFR for (almost clean) backport of 8185969: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: References: <1bd63cd1-efbb-e70d-62e5-510d364f712b@redhat.com> <6459888e-be23-e362-3b09-c5cd4afa701f@redhat.com> Message-ID: Hi Andrew, Thank you for your confirmation. > However, please don't assume an acceptable review just because there is > no objection. I see. I thought review was optional in this case since it is almost clean and no change in the actual code. But I should have waited for your reply, as you reviewed the patch. I'll be more careful. Regards, Ogata Andrew John Hughes wrote on 2019/05/31 01:33:06: > From: Andrew John Hughes > To: Kazunori Ogata , "hotspot-compiler- > dev at openjdk.java.net" , "jdk8u- > dev at openjdk.java.net" > Date: 2019/05/31 01:33 > Subject: [EXTERNAL] Re: [8u-dev, ppc] RFR for (almost clean) backport of > 8185969: PPC64: Improve VSR support to use up to 64 registers > > On 30/05/2019 08:10, Kazunori Ogata wrote: > > Hi, > > > > Fixed a typo in the bug ID in the title. > > > > Since it looks there is no further objection, I added jdk8u-fix-request > > tag in the original bug report. > > > > > > Regards, > > Ogata > > > > The updated webrev looks fine now. > > However, please don't assume an acceptable review just because there is > no objection. > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew > > [attachment "signature.asc" deleted by Kazunori Ogata/Japan/IBM] From gnu.andrew at redhat.com Fri May 31 16:18:22 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 31 May 2019 17:18:22 +0100 Subject: [8u-dev, ppc] RFR for (almost clean) backport of 8185969: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: References: <1bd63cd1-efbb-e70d-62e5-510d364f712b@redhat.com> <6459888e-be23-e362-3b09-c5cd4afa701f@redhat.com> Message-ID: <21b41ea7-f8e8-39ee-aebf-b6f80ab41367@redhat.com> On 31/05/2019 05:54, Kazunori Ogata wrote: > Hi Andrew, > > Thank you for your confirmation. > >> However, please don't assume an acceptable review just because there is >> no objection. > > I see. I thought review was optional in this case since it is almost clean > and no change in the actual code. But I should have waited for your > reply, as you reviewed the patch. I'll be more careful. > > > Regards, > Ogata > > You didn't do anything wrong. I just wanted to clarify that there should always been an explicit ok if a review is required, in case there was any misunderstanding. Regards, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From stooke at redhat.com Fri May 31 16:18:42 2019 From: stooke at redhat.com (Simon Tooke) Date: Fri, 31 May 2019 12:18:42 -0400 Subject: [8u] RFR: backport of 8193830: Xalan Update: Xalan Java 2.7.2 Message-ID: <2f3da7ff-56f6-f6dd-c1b0-980ebb176784@redhat.com> This backport doesn't seem to actually update Xalan, but it does fix xslt transforms in some locales. I had to modify the test code to run (successfully) in 8u, and I did change one indexOf(":") to indexOf(':') for consistency, but other than that it was a fairly clean port.? Passes all the tests in javax.xml, including the new one. Issue: https://bugs.openjdk.java.net/browse/JDK-8193830 Webrevs: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8193830/ (jaxp repo for fixes, jdk repo for new unit test) Is it good? -Simon From gnu.andrew at redhat.com Fri May 31 16:21:20 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 31 May 2019 17:21:20 +0100 Subject: [8u] RFR 8055705: Rename UnixPrintServiceLookup and Win32PrintServiceLookup as a platform neutral class name In-Reply-To: References: <9059c2e9-e472-5536-9f0e-c027808762a0@redhat.com> <36008042-1063-1366-af20-4a311329fd7b@redhat.com> <2136fa67-9103-125b-7e18-102c6e56b91a@redhat.com> <9c1f0ea0-39e5-ec21-ec6d-b59f0d09c2c3@redhat.com> <6a896da3-1d4e-c88e-8c39-3a74d79e783b@redhat.com> Message-ID: <07bcfdb0-3b49-37d1-8598-c1b8116e742f@redhat.com> On 31/05/2019 03:07, Zhengyu Gu wrote: >>> >>> Because we keep old (JDK8) service lookup mechanism, instead of >>> migrating to newer one, which may need to pull in more changesets. >>> >>> Thanks, >>> >>> -Zhengyu >>> >>> >>>> >> >> I'm not suggesting changing the lookup mechanism, just dispensing with >> duplicate copies of what are now the same file. >> >> This worked for me on GNU/Linux with a small Makefile change: >> >> https://cr.openjdk.java.net/~andrew/openjdk8/8055705/webrev.01/ >> >> Let me know if it works on Windows too. > > Yes, works on Windows. > > Thanks, > > -Zhengyu > > >> >> Thanks, >> Ok, I'll push that version. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Fri May 31 16:28:30 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 31 May 2019 17:28:30 +0100 Subject: RFR: [8u] JDK-8225121 Set JDK_UPDATE_VERSION, JDK_BUILD_NUMBER and MILESTONE to correct values by default Message-ID: Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8225121/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8225121 The intention of this simple patch is to provide better defaults for the version output for 8u, which should hopefully make issues with unclear 'ea' builds less frequent. The default version output post patch is: $ /mnt/builder/8u-dev/images/j2sdk-image/bin/java -version openjdk version "1.8.0_222-ea" OpenJDK Runtime Environment (build 1.8.0_222-ea-b06) OpenJDK 64-Bit Server VM (build 25.222-b06, mixed mode) My intention is to reuse this bug ID once approved to update these values as part of the regular tagging process. 8u allows changesets to use the same bug ID and I think that's better than having new bugs every week! It also automatically collates all such changes in the bug database. Going forward, the process will be: * Weekly tag: Update JDK_BUILD_NUMBER to new value * Branch for next release: JDK_UPDATE_VERSION updated and JDK_BUILD_NUMBER reset to b01 in 8u-dev only * Release: Update MILESTONE to "fcs" to produce release builds. Does this sound ok? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From zgu at redhat.com Fri May 31 16:37:33 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 31 May 2019 12:37:33 -0400 Subject: [8u] RFR 8055705: Rename UnixPrintServiceLookup and Win32PrintServiceLookup as a platform neutral class name In-Reply-To: <07bcfdb0-3b49-37d1-8598-c1b8116e742f@redhat.com> References: <9059c2e9-e472-5536-9f0e-c027808762a0@redhat.com> <36008042-1063-1366-af20-4a311329fd7b@redhat.com> <2136fa67-9103-125b-7e18-102c6e56b91a@redhat.com> <9c1f0ea0-39e5-ec21-ec6d-b59f0d09c2c3@redhat.com> <6a896da3-1d4e-c88e-8c39-3a74d79e783b@redhat.com> <07bcfdb0-3b49-37d1-8598-c1b8116e742f@redhat.com> Message-ID: <857f524e-035e-0a7f-8e4b-f37527e0aee9@redhat.com> On 5/31/19 12:21 PM, Andrew John Hughes wrote: > > > On 31/05/2019 03:07, Zhengyu Gu wrote: >>>> >>>> Because we keep old (JDK8) service lookup mechanism, instead of >>>> migrating to newer one, which may need to pull in more changesets. >>>> >>>> Thanks, >>>> >>>> -Zhengyu >>>> >>>> >>>>> >>> >>> I'm not suggesting changing the lookup mechanism, just dispensing with >>> duplicate copies of what are now the same file. >>> >>> This worked for me on GNU/Linux with a small Makefile change: >>> >>> https://cr.openjdk.java.net/~andrew/openjdk8/8055705/webrev.01/ >>> >>> Let me know if it works on Windows too. >> >> Yes, works on Windows. >> >> Thanks, >> >> -Zhengyu >> >> >>> >>> Thanks, >>> > > Ok, I'll push that version. Thanks! -Zhengyu > > Thanks, > From gnu.andrew at redhat.com Fri May 31 16:44:41 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 31 May 2019 17:44:41 +0100 Subject: jdk11u-dev is now switched to 11.0.5 In-Reply-To: References: <82b7dbfa-6b90-dfb8-496b-4267c47d60de@redhat.com> Message-ID: <34e195bf-9c8b-5133-86a5-b7a374876389@redhat.com> On 30/05/2019 22:56, Langer, Christoph wrote: > Hi, > >>> The level of bureaucratic overhead in these projects is getting absurd. >> We're >>> going to have to do something about it before we all drown. >> >> Yes, there is some overhead, it does not make things more >> simple. You could delegate some tasks. >> >> E.g., >> * I would volunteer to trigger the update of the JBS version >> For 11 whenever needed. Do you mean the hgupdater changes via ops? I think usually both 8u & 11u should be handled at the same time to minimise such updates. I'm not sure if anyone but the lead would be accepted for such a request. >> * You could allow to push the version bump without >> jdk11u-fix-yes tag. It's obvious we need it. >> That makes sense to me, given we have no such approval process for the equivalent process of tagging the repository. I've been thinking about this for 8u too [0] and, as both 8u & 11u allow multiple changesets to use the same bug ID, I think keeping such bumps under the same bug ID is a better idea than creating numerous bug IDs just for version updates. That also elegantly solves the approval process issue without the need for exceptional cases. >> Further, I would propose that we exclude all changes Oracle >> pushes to their 11.0.x from the tagging if pushed to >> the open 11.0.x (same x!). >> They have already been judged to be good for downport by Oracle. >> The "Fix Request" comment should be added to the change >> nevertheless. This way one can know that a change is being >> worked on. Maybe we should note in the bug that it is a downport >> that went to Oracle's 11.0.x, so it's clear why it is not tagged. I strongly disagree with this. It would amount to most of the changes not going through the approval process. I can see that with 11u, in its present state, this may mean a lot of rubber stamping of clean backports, because 11u has not diverged much from trunk. However, with 8u, the backported patch can frequently be quite different, and approval should be of that reviewed patch, not based on a decision at Oracle we know nothing about. I expect, with time, 11u will diverge in a similar way and so the approval process will be more involved. I definitely think the solution here is more hands on deck, not effectively removing the process altogether. > > Those seem good suggestions to me. I also think that you could extend the group of maintainers, that is, people who can approve backports. Andrew (Hughes) is already listed for 8u but 11u could also use additional approvers. However, if you do that, you should give some rules and criteria that the approvers have to follow. I'm open to doing 11u as well. I often have to remind myself I can't do that one when something comes up for both 8 & 11. I also think we should have at least a third maintainer on both projects, ideally from outside Red Hat. The primary things I look at for approval is the potential effect it has. Test cases are pretty unproblematic as are arch-specific changes coming from those maintaining that architecture. I'm more critical of general changes and try to ensure that there's nothing in there that will alter API compatibility. Also, ensuring the correct process is followed ends up being part of approval, so e.g. I will ask for a review if one isn't listed and seems needed, and other such sanity checks. > > Best regards > Christoph > [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/009508.html -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Fri May 31 17:17:01 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 31 May 2019 18:17:01 +0100 Subject: RFR: [8u] 8202353: os::readdir should use readdir instead of readdir_r Message-ID: Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8202353/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8202353 As came up again this week [0], 8u doesn't currently build with newer versions of glibc >= 2.24 that deprecate readdir_r. There have been a number of attempts to fix this upstream, some of which I've attempted to backport to 8u in the past. 8202353 seems to be the most complete, so I've backported this and propose it for review. Differences from the 11u version: * The AIX implementation of readdir_r is slightly different in 8u, as 8u lacks JDK-8079125 ([aix] clean up Linux-specific code remnants in AIX coding). As the function is being removed, the difference seems negligible. * Changes to os_perf_aix.cpp, os_perf_linux.cpp, os_perf_solaris.cpp, jfrRepository.cpp & ProblemList.txt are missing, because 8u currently lacks JFR. These will need to be applied to the JFR tree separately. * The readdir_r in Linux is different in 8u because it still actually uses readdir_r, hence causing our problem. 11u already had JDK-8179887 (Build failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated) before JDK-8202353 was applied. * The readdir_r in Solaris is slightly more convoluted in 8u because it doesn't contain JDK-8181787 (Remove Solaris SPARC GCC code). Again, this is immaterial as the function is removed. * There are some slight formatting differences in src/hotspot/os/windows/os_windows.cpp. The 8u style is retained. * The 8u version contains changes to src/share/vm/runtime/arguments.cpp which are similar to those applied in the various perfMemory files. This was necessary because 8u's arguments.cpp still uses readdir_r, while these functions were removed in 11u as part of the removal of support for endorsed JARs (JDK-8183238). i've built the patched version on GNU/Linux and also checked the source for remaining references to the removed readdir_buf_size. Testing on other affected platforms (AIX, Windows, Solaris, *BSD) would be appreciated. [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/009477.html -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From aph at redhat.com Fri May 31 17:25:17 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 31 May 2019 18:25:17 +0100 Subject: jdk11u-dev is now switched to 11.0.5 In-Reply-To: <34e195bf-9c8b-5133-86a5-b7a374876389@redhat.com> References: <82b7dbfa-6b90-dfb8-496b-4267c47d60de@redhat.com> <34e195bf-9c8b-5133-86a5-b7a374876389@redhat.com> Message-ID: <9559ed45-2226-75fd-4b85-867d1a71895f@redhat.com> On 5/31/19 5:44 PM, Andrew John Hughes wrote: > On 30/05/2019 22:56, Langer, Christoph wrote: >> Hi, >> >>>> The level of bureaucratic overhead in these projects is getting absurd. >>> We're >>>> going to have to do something about it before we all drown. >>> >>> Yes, there is some overhead, it does not make things more >>> simple. You could delegate some tasks. But that won't reduce the overhead: all it will do is spread it out. >>> E.g., >>> * I would volunteer to trigger the update of the JBS version >>> For 11 whenever needed. > > Do you mean the hgupdater changes via ops? I think usually both 8u & 11u > should be handled at the same time to minimise such updates. But how? It's not as if the projects are perfectly synchronized. Sure, if they happen to need changing at the same time, then we can do so. > I'm not > sure if anyone but the lead would be accepted for such a request. I'm sure I can delegate anyone to do it. >>> * You could allow to push the version bump without >>> jdk11u-fix-yes tag. It's obvious we need it. > > That makes sense to me, given we have no such approval process for the > equivalent process of tagging the repository. Yes. > I've been thinking about this for 8u too [0] and, as both 8u & 11u allow > multiple changesets to use the same bug ID, I think keeping such bumps > under the same bug ID is a better idea than creating numerous bug IDs > just for version updates. That also elegantly solves the approval > process issue without the need for exceptional cases. > >>> Further, I would propose that we exclude all changes Oracle >>> pushes to their 11.0.x from the tagging if pushed to >>> the open 11.0.x (same x!). >>> They have already been judged to be good for downport by Oracle. >>> The "Fix Request" comment should be added to the change >>> nevertheless. This way one can know that a change is being >>> worked on. Maybe we should note in the bug that it is a downport >>> that went to Oracle's 11.0.x, so it's clear why it is not tagged. > > I strongly disagree with this. It would amount to most of the changes > not going through the approval process. > > I can see that with 11u, in its present state, this may mean a lot of > rubber stamping of clean backports, because 11u has not diverged much > from trunk. However, with 8u, the backported patch can frequently be > quite different, and approval should be of that reviewed patch, not > based on a decision at Oracle we know nothing about. The backported patch, if different from the patch applied at head, will have to be reviewed. That's when the code walkthrough and the impact should be assessed. On the other hand, approval says that, in principle at least, this change is one that we want in the release branch. > I expect, with time, 11u will diverge in a similar way and so the > approval process will be more involved. I definitely think the solution > here is more hands on deck, not effectively removing the process altogether. > >> Those seem good suggestions to me. I also think that you could >> extend the group of maintainers, that is, people who can approve >> backports. Andrew (Hughes) is already listed for 8u but 11u could >> also use additional approvers. However, if you do that, you should >> give some rules and criteria that the approvers have to follow. Definitely, yes. The thing holding me back from appointing more maintainers, still, is that I perceive a lack of consensus about the criteria by which a backport should be judged. I personally would be strict about this: serious bugs and regressions, plus perhaps some important performance improvements. However, there seems to be a general sentiment that we don't want to diverge from Oracle, so some pretty trivial backports have been approved. To some extent I accept the "don't diverge" reasoning because feature differences between OpenJDK and Oracle are to be avoided if possible: we don't want to confuser our users unnecessarily. > I'm open to doing 11u as well. I often have to remind myself I can't > do that one when something comes up for both 8 & 11. I also think we > should have at least a third maintainer on both projects, ideally > from outside Red Hat. > > The primary things I look at for approval is the potential effect it > has. Test cases are pretty unproblematic as are arch-specific > changes coming from those maintaining that architecture. I'm more > critical of general changes and try to ensure that there's nothing > in there that will alter API compatibility. This is a good start. If we can agree what criteria we should apply when approving a backport then we can share the maintainer's role. > Also, ensuring the correct process is followed ends up being part of > approval, so e.g. I will ask for a review if one isn't listed and > seems needed, and other such sanity checks. That imposes a strict ordering: review first, then approval. I think that approval and review can run in parallel: we don't want to fully review every backport patch twice. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From alvdavi at amazon.com Fri May 31 18:59:47 2019 From: alvdavi at amazon.com (Alvarez, David) Date: Fri, 31 May 2019 18:59:47 +0000 Subject: [8u] 8202353: os::readdir should use readdir instead of readdir_r In-Reply-To: References: Message-ID: Hi Andrew, Hi Andrew I remember looking at this for jdk11u. Although 8202353 covers changes to hotspot, there are a bunch of places outside hotspot where readdir_r is still being used, like [0] and [1]. I would suggest to backport JDK-8202794, JDK-8207340 and JDK-8207748. JDK-8207748 is a fixup of JDK-8202794 and can be integrated on it. [0] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/57d6c23af6c9/src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c#l59 [1] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/57d6c23af6c9/src/solaris/native/java/util/TimeZone_md.c#l49 -- David ?On 2019-05-31, 10:19, "jdk8u-dev on behalf of Andrew John Hughes" wrote: Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8202353/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8202353 As came up again this week [0], 8u doesn't currently build with newer versions of glibc >= 2.24 that deprecate readdir_r. There have been a number of attempts to fix this upstream, some of which I've attempted to backport to 8u in the past. 8202353 seems to be the most complete, so I've backported this and propose it for review. Differences from the 11u version: * The AIX implementation of readdir_r is slightly different in 8u, as 8u lacks JDK-8079125 ([aix] clean up Linux-specific code remnants in AIX coding). As the function is being removed, the difference seems negligible. * Changes to os_perf_aix.cpp, os_perf_linux.cpp, os_perf_solaris.cpp, jfrRepository.cpp & ProblemList.txt are missing, because 8u currently lacks JFR. These will need to be applied to the JFR tree separately. * The readdir_r in Linux is different in 8u because it still actually uses readdir_r, hence causing our problem. 11u already had JDK-8179887 (Build failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated) before JDK-8202353 was applied. * The readdir_r in Solaris is slightly more convoluted in 8u because it doesn't contain JDK-8181787 (Remove Solaris SPARC GCC code). Again, this is immaterial as the function is removed. * There are some slight formatting differences in src/hotspot/os/windows/os_windows.cpp. The 8u style is retained. * The 8u version contains changes to src/share/vm/runtime/arguments.cpp which are similar to those applied in the various perfMemory files. This was necessary because 8u's arguments.cpp still uses readdir_r, while these functions were removed in 11u as part of the removal of support for endorsed JARs (JDK-8183238). i've built the patched version on GNU/Linux and also checked the source for remaining references to the removed readdir_buf_size. Testing on other affected platforms (AIX, Windows, Solaris, *BSD) would be appreciated. [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/009477.html -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From christoph.langer at sap.com Fri May 31 19:40:50 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 31 May 2019 19:40:50 +0000 Subject: [8u-dev] RFR+RFA (S): JDK-8225065: Revert 8221166 (8u backport of 8048782) In-Reply-To: References: Message-ID: Hi Paul, looks good. I think the actual bug should be fixed in jdk/jdk now? Best regards Christoph From: 2d-dev <2d-dev-bounces at openjdk.java.net> On Behalf Of Hohensee, Paul Sent: Donnerstag, 30. Mai 2019 19:43 To: jdk8u-dev at openjdk.java.net; 2d-dev at openjdk.java.net Subject: [DMARC FAILURE] [OpenJDK 2D-Dev] [8u-dev] RFR+RFA (S): JDK-8225065: Revert 8221166 (8u backport of 8048782) Please review and approve. Bug: https://bugs.openjdk.java.net/browse/JDK-8225065 Webrev: http://cr.openjdk.java.net/~phh/8225065/webrev.8u.00/ Reverted bug: https://bugs.openjdk.java.net/browse/JDK-8221166 Reverted patch: http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/d9da27985291 Discussion: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/009349.html Thanks, Paul From alvdavi at amazon.com Fri May 31 20:54:21 2019 From: alvdavi at amazon.com (Alvarez, David) Date: Fri, 31 May 2019 20:54:21 +0000 Subject: [8u-dev] RFR+RFA (S): JDK-8225065: Revert 8221166 (8u backport of 8048782) In-Reply-To: References: Message-ID: The bug is exclusive to the old Pisces renderer, Marlin is not affected, so it is indeed fixed in jdk/jdk. ?On 2019-05-31, 12:42, "jdk8u-dev on behalf of Langer, Christoph" wrote: Hi Paul, looks good. I think the actual bug should be fixed in jdk/jdk now? Best regards Christoph From: 2d-dev <2d-dev-bounces at openjdk.java.net> On Behalf Of Hohensee, Paul Sent: Donnerstag, 30. Mai 2019 19:43 To: jdk8u-dev at openjdk.java.net; 2d-dev at openjdk.java.net Subject: [DMARC FAILURE] [OpenJDK 2D-Dev] [8u-dev] RFR+RFA (S): JDK-8225065: Revert 8221166 (8u backport of 8048782) Please review and approve. Bug: https://bugs.openjdk.java.net/browse/JDK-8225065 Webrev: http://cr.openjdk.java.net/~phh/8225065/webrev.8u.00/ Reverted bug: https://bugs.openjdk.java.net/browse/JDK-8221166 Reverted patch: http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/d9da27985291 Discussion: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/009349.html Thanks, Paul From hohensee at amazon.com Fri May 31 22:38:25 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 31 May 2019 22:38:25 +0000 Subject: [8u-dev] RFR+RFA (S): JDK-8225065: Revert 8221166 (8u backport of 8048782) In-Reply-To: References: Message-ID: <240F9801-7ABF-4E87-8A41-65DC88587A0D@amazon.com> Thanks, Christoph. Now to get Andrew to mark it 'jdk8u-fix-yes'... :) Paul ?On 5/31/19, 1:54 PM, "Alvarez, David" wrote: The bug is exclusive to the old Pisces renderer, Marlin is not affected, so it is indeed fixed in jdk/jdk. On 2019-05-31, 12:42, "jdk8u-dev on behalf of Langer, Christoph" wrote: Hi Paul, looks good. I think the actual bug should be fixed in jdk/jdk now? Best regards Christoph From: 2d-dev <2d-dev-bounces at openjdk.java.net> On Behalf Of Hohensee, Paul Sent: Donnerstag, 30. Mai 2019 19:43 To: jdk8u-dev at openjdk.java.net; 2d-dev at openjdk.java.net Subject: [DMARC FAILURE] [OpenJDK 2D-Dev] [8u-dev] RFR+RFA (S): JDK-8225065: Revert 8221166 (8u backport of 8048782) Please review and approve. Bug: https://bugs.openjdk.java.net/browse/JDK-8225065 Webrev: http://cr.openjdk.java.net/~phh/8225065/webrev.8u.00/ Reverted bug: https://bugs.openjdk.java.net/browse/JDK-8221166 Reverted patch: http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/d9da27985291 Discussion: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/009349.html Thanks, Paul From thomas.stuefe at gmail.com Mon May 27 14:59:31 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 27 May 2019 14:59:31 -0000 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: <8FB70808-E4E0-451C-AC86-C9EA1EA2FA30@azul.com> References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> <8FB70808-E4E0-451C-AC86-C9EA1EA2FA30@azul.com> Message-ID: Hi Gil, On Mon, May 27, 2019 at 1:41 AM Gil Tene wrote: > Seriously? > > You see factual reporting (directly documented and dated in the original > posting) of the actual version numbers being used by official docker > images, along with irrefutable proof that the packages used in those were > built weeks before the respective OpenJDK 8u and 11u releases were > complete, as ?fake news?? > > You think that alerting millions of unsuspecting people using exposed, > insecure builds that falsely report their OpenJDK version (as one that > includes e.g. critical security fixes) to the fact as ?marketing?? > > Did you try to contact Debian folks to give them opportunity to fix those security concerns before going public with them? Or did they not react in time? Cheers, Thomas From ebourg at apache.org Mon May 27 15:32:37 2019 From: ebourg at apache.org (Emmanuel Bourg) Date: Mon, 27 May 2019 15:32:37 -0000 Subject: Mystery meat OpenJDK builds strike again In-Reply-To: References: <6B0652EE-3582-4659-9CF2-073180029793@azul.com> <8FB70808-E4E0-451C-AC86-C9EA1EA2FA30@azul.com> Message-ID: <56bca97d-7110-19d2-92c1-a12dc87bd7fb@apache.org> Le 27/05/2019 ? 16:59, Thomas St?fe a ?crit?: > Did you try to contact Debian folks to give them opportunity to fix > those security concerns before going public with them? No he didn't, and I don't think he cares. I'd like to thank Aleksey Shipilev for bringing the issue in a constructive and civilized manner on the debian-java list. This led to the upload of OpenJDK 11.0.3+7 to the Debian 9 "Stretch" backport repository last week. Emmanuel Bourg From amaembo at gmail.com Wed May 22 15:52:40 2019 From: amaembo at gmail.com (Tagir Valeev) Date: Wed, 22 May 2019 15:52:40 -0000 Subject: [8u] RFR (S) 8190974: Parallel stream execution within a custom ForkJoinPool should obey the parallelism In-Reply-To: References: <94d05544-08af-0969-1d28-484b79c597fe@redhat.com> Message-ID: Hello! Looks good to me. I don't think there are any hidden problems with this fix. It was pretty straightforward and should not rely on anything which might not be available in 8. With best regards, Tagir Valeev. ??, 22 ??? 2019 ?., 22:47 Martin Buchholz : > Too bad Paul Sandoz is no longer working on openjdk. > Maybe Doug can review - he was involved with design of stream parallelism > IIRC. > I took a quick look - it Looks Good To Me. > > (But I have misgivings about any sort of auto-parallelization, including > via parallel streams, which will become increasingly important as cpu > counts increase) > > On Thu, May 2, 2019 at 10:45 AM Aleksey Shipilev wrote: > >> Original fix: >> https://bugs.openjdk.java.net/browse/JDK-8190974 >> http://hg.openjdk.java.net/jdk/jdk/rev/e0041b182e31 >> >> This is one of the things that was mentioned multiple times as the >> pitfall in 8u. The patch itself >> is simple enough to consider backporting and fixing that pothole. Once >> related JDK-8154387 [1] >> backport is in, this patch applies with reshuffling to 8u, except for the >> test, which requires >> fitting to the old shape of Stream tests. >> >> 8u webrev: >> http://cr.openjdk.java.net/~shade/8190974/webrev.8u.01/ >> >> Testing: jdk_core tests, including the new test >> >> Thanks, >> -Aleksey >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8154387 >> >>