From christoph.langer at sap.com Mon Apr 1 06:05:54 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 1 Apr 2019 06:05:54 +0000 Subject: [PATCH] [8u] Prevent MSDOS8.3 named DLL in built image In-Reply-To: References: Message-ID: Hi Ali, generally, I think this makes sense. Maybe, however, there are still some legacy compile environments around somewhere which will have a problem with that, e.g. very old Windows versions? It's hard to tell but it's probably reasonable to try out the fix. I found the change to be part of a VS2017 enabling fix for JDK11: https://bugs.openjdk.java.net/browse/JDK-8201267 http://hg.openjdk.java.net/jdk/jdk/rev/7c224ec572d0 So I have a general question: Shouldn't this fix be part of a larger change that would enable VS2017 for JDK8? I assume it won't be the only thing to touch... Best regards Christoph > -----Original Message----- > From: jdk8u-dev On Behalf Of Ali > Ince > Sent: Donnerstag, 28. M?rz 2019 20:48 > To: jdk8u-dev at openjdk.java.net > Subject: [PATCH] [8u] Prevent MSDOS8.3 named DLL in built image > > Hi All, > > We're working on building JDK8U with VS2017 at AdoptOpenJDK and found > out that the new vcruntime140.dll is copied to the built image named as > `vcrunt~1.dll` which is basically because of the extra call to > `BASIC_FIXUP_PATH` call in `toolchain_windows.m4` file. If the call is > removed, everything works fine. > > On previous versions of VS, the VC runtime DLL was originally named in 8.3 > style (ex. msvcr100.dll) and BASIC_FIXUP_PATH did not have any affect on > the file name itself. I've checked with `toolchain_windows.m4` files in jdk11u > and onwards and also saw that this call doesn't exist. > > I've came up with the following patch which removes this call. I'm not sure > what's the process about updating the checked-in generated_configure.sh > but I could also add the patch for that if it's required. > > Let me know if you have any feedback or comments. > > Regards, > > Ali > > --------------------------------------------- > > diff -r e0b7721459ee common/autoconf/toolchain_windows.m4 > --- a/common/autoconf/toolchain_windows.m4 Wed Mar 20 16:32:54 2019 > +0000 > +++ b/common/autoconf/toolchain_windows.m4 Thu Mar 28 00:03:10 2019 > +0000 > @@ -493,7 +493,6 @@ > if $ECHO "$MSVC_DLL_FILETYPE" | $GREP "$CORRECT_MSVCR_ARCH" > 2>&1 > /dev/null; then > AC_MSG_RESULT([ok]) > MSVC_DLL="$POSSIBLE_MSVC_DLL" > - BASIC_FIXUP_PATH(MSVC_DLL) > AC_MSG_CHECKING([for $DLL_NAME]) > AC_MSG_RESULT([$MSVC_DLL]) > else > From kevin.walls at oracle.com Mon Apr 1 08:54:16 2019 From: kevin.walls at oracle.com (Kevin Walls) Date: Mon, 1 Apr 2019 09:54:16 +0100 Subject: make reconfigure broken (quoting problem?) In-Reply-To: References: Message-ID: Hi Martin - I recall "make reconfigure" working but clearly there's a complication....? Looks like reconfigure doesn't handle >1 argument.? It looks like it's processing all the args to configure as one, rather than individually? ? I just tried this make change and "make reconfigure" worked with two arguments to configure: diff -r 9a4af54dd074 make/Main.gmk --- a/make/Main.gmk???? Fri Mar 22 17:51:45 2019 +0000 +++ b/make/Main.gmk???? Mon Apr 01 01:44:05 2019 -0700 @@ -238,7 +238,7 @@ ???????? else ????????? @$(ECHO) "Re-running configure using default settings" ???????? endif -?????? @( cd $(OUTPUT_ROOT) && $(BASH) $(TOPDIR)/configure "$(CONFIGURE_COMMAND_LINE)" ) +?????? @( cd $(OUTPUT_ROOT) && $(BASH) $(TOPDIR)/configure $(CONFIGURE_COMMAND_LINE) ) ?.PHONY: langtools corba jaxp jaxws hotspot jdk nashorn images overlay-images install test docs ?.PHONY: langtools-only corba-only jaxp-only jaxws-only hotspot-only jdk-only nashorn-only images-only overlay-images-only install-only test-only docs-only I looked in 11u and this isn't a problem there, it's laid out a little differently and this happens in make/Init.gmk Hope that helps, Kevin On 30/03/2019 01:48, Martin Buchholz wrote: > It looks to me like this feature was broken at the time of its > backport to jdk8u > > changeset:? ?2163:2209644bcac4 > user:? ? ? ? kevinw > date:? ? ? ? 2018-04-10 07:46 -0700 > 8034199: Add 'reconfigure' target for re-creating a configuration > Reviewed-by: ihse, erikj, tbell > > Recipe: > hg update 2209644bcac4 && hg log -r . && bash configure > --with-toolchain-type=gcc --with-boot-jdk=$HOME/jdk/jdk7 && make > reconfigure > ... > configure: Toolchain type gcc --with-boot-jdk=.../jdk/jdk7 is not > valid on this platform. > configure: Valid toolchains: gcc clang. > configure: error: Cannot continue. > > > > On Fri, Mar 29, 2019 at 11:35 AM Andrew John Hughes > > wrote: > > On 29/03/2019 16:23, Martin Buchholz wrote: > > Recipe: > > > > ( rm -rf build; set -x; bash configure --with-toolchain-type=gcc > > --with-boot-jdk=$HOME/jdk/jdk7 && make reconfigure ) > > => > > configure: Toolchain type gcc --with-boot-jdk=.../jdk/jdk7 is > not valid on > > this platform. > > configure: Valid toolchains: gcc clang. > > > > --- > > Do y'all always build from scratch? > > > > Personally speaking, not always. It depends what I've altered. > > Where are you seeing this? jdk8u or jdk8u-dev? And any idea what > change > caused it? > > 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 Apr 1 10:27:27 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 1 Apr 2019 10:27:27 +0000 Subject: [8u-dev] RFR for non-clean backport of 8154156: PPC64: improve array copy stubs by using vector instructions In-Reply-To: References: Message-ID: Hi Ogata, I haven't seen any manual adaptations. You only had to pick parts of different changes if I didn't miss anything. I think the selection makes sense. Looks good to me. I think it will be helpful to get an incremental webrev if you do such changes again in the future. That would make it much easier to see what you've done. Best regards, Martin -----Original Message----- From: jdk8u-dev On Behalf Of Kazunori Ogata Sent: Donnerstag, 28. M?rz 2019 13:56 To: jdk8u-dev at openjdk.java.net Subject: [8u-dev] RFR for non-clean backport of 8154156: PPC64: improve array copy stubs by using vector instructions Hi, May I get review for non-clean backport of 8154156: PPC64: improve array copy stubs by using vector instructions? This is the same change as I posted in January [1], but I updated the patch based on the latest jdk8u-dev tree. As we've had ppc-expert reviewers in jdk8u-dev community, I'd like to request for review. Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/c9d756fa846e Weberv: http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8154156/webrev.02/ I confirmed it was buildable for both release and fastdebug builds, and JTREG caused no degradation. Refs: [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-January/008372.html Regards, Ogata From OGATAK at jp.ibm.com Mon Apr 1 10:55:42 2019 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Mon, 1 Apr 2019 19:55:42 +0900 Subject: [8u-dev] RFR for non-clean backport of 8154156: PPC64: improve array copy stubs by using vector instructions In-Reply-To: References: Message-ID: Hi Martin, Thank you for reviewing. > I think it will be helpful to get an incremental webrev if you do such > changes again in the future. That would make it much easier to see what you've done. Do you mean to create a patch after picking a set of code from one of original changesets, then create another one after picking up from another changeset, etc.? I'll do it in the future cherry picking from multiple change set. Thank you for your suggestion. Regards, Ogata "Doerr, Martin" wrote on 2019/04/01 19:27:27: > From: "Doerr, Martin" > To: Kazunori Ogata , "jdk8u-dev at openjdk.java.net" > > Date: 2019/04/01 19:31 > Subject: RE: [8u-dev] RFR for non-clean backport of 8154156: PPC64: > improve array copy stubs by using vector instructions > > Hi Ogata, > > I haven't seen any manual adaptations. You only had to pick parts of > different changes if I didn't miss anything. I think the selection makes sense. > Looks good to me. > > I think it will be helpful to get an incremental webrev if you do such > changes again in the future. That would make it much easier to see what you've done. > > Best regards, > Martin > > > -----Original Message----- > From: jdk8u-dev On Behalf Of Kazunori Ogata > Sent: Donnerstag, 28. M?rz 2019 13:56 > To: jdk8u-dev at openjdk.java.net > Subject: [8u-dev] RFR for non-clean backport of 8154156: PPC64: improve > array copy stubs by using vector instructions > > Hi, > > May I get review for non-clean backport of 8154156: PPC64: improve array > copy stubs by using vector instructions? > > This is the same change as I posted in January [1], but I updated the > patch based on the latest jdk8u-dev tree. As we've had ppc-expert > reviewers in jdk8u-dev community, I'd like to request for review. > > Original patch: https://urldefense.proofpoint.com/v2/url? > u=http-3A__hg.openjdk.java.net_jdk_jdk_rev_c9d756fa846e&d=DwIFAw&c=jf_iaSHvJObTbx- > siA1ZOg&r=p- > FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=kByIA1iAKsgJMD6pdYyw1l-5xcMR5UypOklN7bgdBqM&s=_EJfiOe4f_0Of- > lvi1RbSMBdvPWsNqvQr5fRnoifzug&e= > Weberv: https://urldefense.proofpoint.com/v2/url? > u=http-3A__cr.openjdk.java.net_-7Ehorii_jdk8u-5Faes-5Fbe_8154156_webrev. > 02_&d=DwIFAw&c=jf_iaSHvJObTbx-siA1ZOg&r=p- > FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=kByIA1iAKsgJMD6pdYyw1l-5xcMR5UypOklN7bgdBqM&s=Tqj6- > lI1D6uSHJn7I8ULG2nPE2Dns-8EXZ30v2CTSl0&e= > > I confirmed it was buildable for both release and fastdebug builds, and > JTREG caused no degradation. > > Refs: > [1] > https://urldefense.proofpoint.com/v2/url? > u=https-3A__mail.openjdk.java.net_pipermail_jdk8u-2Ddev_2019-2DJanuary_008372.html&d=DwIFAw&c=jf_iaSHvJObTbx- > siA1ZOg&r=p- > FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=kByIA1iAKsgJMD6pdYyw1l-5xcMR5UypOklN7bgdBqM&s=os4yIaDEEo_KjCCNEz66kbGPDkZnCa0BcyWxq1fRNi8&e= > > > Regards, > Ogata > > > > From martin.doerr at sap.com Mon Apr 1 11:44:52 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 1 Apr 2019 11:44:52 +0000 Subject: [8u-dev] RFR for non-clean backport of 8154156: PPC64: improve array copy stubs by using vector instructions In-Reply-To: References: Message-ID: > Do you mean to create a patch after picking a set of code from one of > original changesets, then create another one after picking up from another > changeset, etc.? Yes, that would be helpful. Best regards, Martin -----Original Message----- From: Kazunori Ogata Sent: Montag, 1. April 2019 12:56 To: Doerr, Martin Cc: jdk8u-dev at openjdk.java.net Subject: RE: [8u-dev] RFR for non-clean backport of 8154156: PPC64: improve array copy stubs by using vector instructions Hi Martin, Thank you for reviewing. > I think it will be helpful to get an incremental webrev if you do such > changes again in the future. That would make it much easier to see what you've done. Do you mean to create a patch after picking a set of code from one of original changesets, then create another one after picking up from another changeset, etc.? I'll do it in the future cherry picking from multiple change set. Thank you for your suggestion. Regards, Ogata "Doerr, Martin" wrote on 2019/04/01 19:27:27: > From: "Doerr, Martin" > To: Kazunori Ogata , "jdk8u-dev at openjdk.java.net" > > Date: 2019/04/01 19:31 > Subject: RE: [8u-dev] RFR for non-clean backport of 8154156: PPC64: > improve array copy stubs by using vector instructions > > Hi Ogata, > > I haven't seen any manual adaptations. You only had to pick parts of > different changes if I didn't miss anything. I think the selection makes sense. > Looks good to me. > > I think it will be helpful to get an incremental webrev if you do such > changes again in the future. That would make it much easier to see what you've done. > > Best regards, > Martin > > > -----Original Message----- > From: jdk8u-dev On Behalf Of Kazunori Ogata > Sent: Donnerstag, 28. M?rz 2019 13:56 > To: jdk8u-dev at openjdk.java.net > Subject: [8u-dev] RFR for non-clean backport of 8154156: PPC64: improve > array copy stubs by using vector instructions > > Hi, > > May I get review for non-clean backport of 8154156: PPC64: improve array > copy stubs by using vector instructions? > > This is the same change as I posted in January [1], but I updated the > patch based on the latest jdk8u-dev tree. As we've had ppc-expert > reviewers in jdk8u-dev community, I'd like to request for review. > > Original patch: https://urldefense.proofpoint.com/v2/url? > u=http-3A__hg.openjdk.java.net_jdk_jdk_rev_c9d756fa846e&d=DwIFAw&c=jf_iaSHvJObTbx- > siA1ZOg&r=p- > FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=kByIA1iAKsgJMD6pdYyw1l-5xcMR5UypOklN7bgdBqM&s=_EJfiOe4f_0Of- > lvi1RbSMBdvPWsNqvQr5fRnoifzug&e= > Weberv: https://urldefense.proofpoint.com/v2/url? > u=http-3A__cr.openjdk.java.net_-7Ehorii_jdk8u-5Faes-5Fbe_8154156_webrev. > 02_&d=DwIFAw&c=jf_iaSHvJObTbx-siA1ZOg&r=p- > FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=kByIA1iAKsgJMD6pdYyw1l-5xcMR5UypOklN7bgdBqM&s=Tqj6- > lI1D6uSHJn7I8ULG2nPE2Dns-8EXZ30v2CTSl0&e= > > I confirmed it was buildable for both release and fastdebug builds, and > JTREG caused no degradation. > > Refs: > [1] > https://urldefense.proofpoint.com/v2/url? > u=https-3A__mail.openjdk.java.net_pipermail_jdk8u-2Ddev_2019-2DJanuary_008372.html&d=DwIFAw&c=jf_iaSHvJObTbx- > siA1ZOg&r=p- > FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=kByIA1iAKsgJMD6pdYyw1l-5xcMR5UypOklN7bgdBqM&s=os4yIaDEEo_KjCCNEz66kbGPDkZnCa0BcyWxq1fRNi8&e= > > > Regards, > Ogata > > > > From dalibor.topic at oracle.com Mon Apr 1 13:32:04 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Mon, 1 Apr 2019 15:32:04 +0200 Subject: Handling Backport Changesets In-Reply-To: References: Message-ID: <48b692d9-4e07-5524-3919-0a6984c18d9b@oracle.com> Fwiw, JIRA entries for backports record a single Assignee. Quoting from https://wiki.openjdk.java.net/display/general/JBS+Overview "Backports are full issues, but only a few fields are expected to be set: fixVersion: indicates which specific release a backport is targeting or fixed in assignee: holds the engineer responsible for the backport" So my suggestion would be to simply keep that information accurate in JIRA as your 'Backported-by' information, rather than adding a category of metadata to commits. This has a couple of advantages. It's not possible to fix mistakes in commit metadata, for example, while it can be done easily in JIRA. cheers, dalibor topic On 29.03.2019 16:00, Andrew John Hughes wrote: > Just a heads up that I've filed: > > https://bugs.openjdk.java.net/browse/JDK-8221692 > > to try and get backporting formally recognised in changesets, in the > same way as Contributed-by. > > Hopefully, this will resolve the confusion over who to credit for such > changes. > > Thanks, > -- 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 grzesuav at gmail.com Mon Apr 1 16:13:29 2019 From: grzesuav at gmail.com (=?UTF-8?B?R3J6ZWdvcnogR8WCxIVi?=) Date: Mon, 1 Apr 2019 18:13:29 +0200 Subject: Cannot build jdk8 on kernel 5.x Message-ID: Hi, when I tried build openjdk (via adoptopenjdk scripts) I encountered an issue as described here (https://github.com/AdoptOpenJDK/openjdk-build/issues/999) TL;DR missing 5.x in https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/master/hotspot/make/linux/Makefile#L236 (probably equivalent here) Not sure how to report issue on jdk8 bugs, can somebody do it on my behalf? Cheers Grzegorz From shade at redhat.com Mon Apr 1 16:19:06 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 1 Apr 2019 18:19:06 +0200 Subject: Cannot build jdk8 on kernel 5.x In-Reply-To: References: Message-ID: <71258591-0631-bd53-9d04-9985441091f2@redhat.com> On 4/1/19 6:13 PM, Grzegorz G??b wrote: > when I tried build openjdk (via adoptopenjdk scripts) I encountered an > issue as described here > (https://github.com/AdoptOpenJDK/openjdk-build/issues/999) > > TL;DR missing 5.x in > https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/master/hotspot/make/linux/Makefile#L236 > (probably equivalent here) Well, it is fixed in 8u for at least two weeks now: https://bugs.openjdk.java.net/browse/JDK-8217753 http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/5af8ec63c21c Ask AdoptOpenJDK people what exactly do they have in their mirror. It seems their latest sync was 28 days ago -- and that quite probably misses a lot of work done in 8u. -Aleksey From martinrb at google.com Mon Apr 1 19:16:52 2019 From: martinrb at google.com (Martin Buchholz) Date: Mon, 1 Apr 2019 12:16:52 -0700 Subject: make reconfigure broken (quoting problem?) In-Reply-To: References: Message-ID: Kevin - Thanks. This looks like the right fix, making jdk8's behavior consistent with later jdks. Who will volunteer to check in Kevin's fix? On Mon, Apr 1, 2019 at 1:54 AM Kevin Walls wrote: > Hi Martin - > > I recall "make reconfigure" working but clearly there's a > complication.... Looks like reconfigure doesn't handle >1 argument. It > looks like it's processing all the args to configure as one, rather than > individually? I just tried this make change and "make reconfigure" worked > with two arguments to configure: > > diff -r 9a4af54dd074 make/Main.gmk > --- a/make/Main.gmk Fri Mar 22 17:51:45 2019 +0000 > +++ b/make/Main.gmk Mon Apr 01 01:44:05 2019 -0700 > @@ -238,7 +238,7 @@ > else > @$(ECHO) "Re-running configure using default settings" > endif > - @( cd $(OUTPUT_ROOT) && $(BASH) $(TOPDIR)/configure > "$(CONFIGURE_COMMAND_LINE)" ) > + @( cd $(OUTPUT_ROOT) && $(BASH) $(TOPDIR)/configure > $(CONFIGURE_COMMAND_LINE) ) > > .PHONY: langtools corba jaxp jaxws hotspot jdk nashorn images > overlay-images install test docs > .PHONY: langtools-only corba-only jaxp-only jaxws-only hotspot-only > jdk-only nashorn-only images-only overlay-images-only install-only > test-only docs-only > > I looked in 11u and this isn't a problem there, it's laid out a little > differently and this happens in make/Init.gmk > > Hope that helps, > Kevin > > > On 30/03/2019 01:48, Martin Buchholz wrote: > > It looks to me like this feature was broken at the time of its backport to > jdk8u > > changeset: 2163:2209644bcac4 > user: kevinw > date: 2018-04-10 07:46 -0700 > 8034199: Add 'reconfigure' target for re-creating a configuration > Reviewed-by: ihse, erikj, tbell > > Recipe: > hg update 2209644bcac4 && hg log -r . && bash configure > --with-toolchain-type=gcc --with-boot-jdk=$HOME/jdk/jdk7 && make > reconfigure > ... > configure: Toolchain type gcc --with-boot-jdk=.../jdk/jdk7 is not valid on > this platform. > configure: Valid toolchains: gcc clang. > configure: error: Cannot continue. > > > > On Fri, Mar 29, 2019 at 11:35 AM Andrew John Hughes > wrote: > >> On 29/03/2019 16:23, Martin Buchholz wrote: >> > Recipe: >> > >> > ( rm -rf build; set -x; bash configure --with-toolchain-type=gcc >> > --with-boot-jdk=$HOME/jdk/jdk7 && make reconfigure ) >> > => >> > configure: Toolchain type gcc --with-boot-jdk=.../jdk/jdk7 is not valid >> on >> > this platform. >> > configure: Valid toolchains: gcc clang. >> > >> > --- >> > Do y'all always build from scratch? >> > >> >> Personally speaking, not always. It depends what I've altered. >> >> Where are you seeing this? jdk8u or jdk8u-dev? And any idea what change >> caused it? >> >> 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 Mon Apr 1 19:53:36 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 1 Apr 2019 19:53:36 +0000 Subject: Cannot build jdk8 on kernel 5.x In-Reply-To: References: Message-ID: To be clear this may not be a bug per say as opposed to a new platform that jdk8u may need to support (and something Adopt could look to try and help create a patch for). Cheers, Martijn On Mon, 1 Apr 2019 at 17:15, Grzegorz G??b wrote: > Hi, > > when I tried build openjdk (via adoptopenjdk scripts) I encountered an > issue as described here > (https://github.com/AdoptOpenJDK/openjdk-build/issues/999) > > TL;DR missing 5.x in > > https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/master/hotspot/make/linux/Makefile#L236 > (probably equivalent here) > > Not sure how to report issue on jdk8 bugs, can somebody do it on my behalf? > > > Cheers > > > Grzegorz > From hohensee at amazon.com Mon Apr 1 20:27:21 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 1 Apr 2019 20:27:21 +0000 Subject: make reconfigure broken (quoting problem?) In-Reply-To: References: Message-ID: <5B8B711F-D079-4138-8BDC-06406062EDEF@amazon.com> Is there a JBS issue for this? ?On 4/1/19, 12:19 PM, "jdk8u-dev on behalf of Martin Buchholz" wrote: Kevin - Thanks. This looks like the right fix, making jdk8's behavior consistent with later jdks. Who will volunteer to check in Kevin's fix? On Mon, Apr 1, 2019 at 1:54 AM Kevin Walls wrote: > Hi Martin - > > I recall "make reconfigure" working but clearly there's a > complication.... Looks like reconfigure doesn't handle >1 argument. It > looks like it's processing all the args to configure as one, rather than > individually? I just tried this make change and "make reconfigure" worked > with two arguments to configure: > > diff -r 9a4af54dd074 make/Main.gmk > --- a/make/Main.gmk Fri Mar 22 17:51:45 2019 +0000 > +++ b/make/Main.gmk Mon Apr 01 01:44:05 2019 -0700 > @@ -238,7 +238,7 @@ > else > @$(ECHO) "Re-running configure using default settings" > endif > - @( cd $(OUTPUT_ROOT) && $(BASH) $(TOPDIR)/configure > "$(CONFIGURE_COMMAND_LINE)" ) > + @( cd $(OUTPUT_ROOT) && $(BASH) $(TOPDIR)/configure > $(CONFIGURE_COMMAND_LINE) ) > > .PHONY: langtools corba jaxp jaxws hotspot jdk nashorn images > overlay-images install test docs > .PHONY: langtools-only corba-only jaxp-only jaxws-only hotspot-only > jdk-only nashorn-only images-only overlay-images-only install-only > test-only docs-only > > I looked in 11u and this isn't a problem there, it's laid out a little > differently and this happens in make/Init.gmk > > Hope that helps, > Kevin > > > On 30/03/2019 01:48, Martin Buchholz wrote: > > It looks to me like this feature was broken at the time of its backport to > jdk8u > > changeset: 2163:2209644bcac4 > user: kevinw > date: 2018-04-10 07:46 -0700 > 8034199: Add 'reconfigure' target for re-creating a configuration > Reviewed-by: ihse, erikj, tbell > > Recipe: > hg update 2209644bcac4 && hg log -r . && bash configure > --with-toolchain-type=gcc --with-boot-jdk=$HOME/jdk/jdk7 && make > reconfigure > ... > configure: Toolchain type gcc --with-boot-jdk=.../jdk/jdk7 is not valid on > this platform. > configure: Valid toolchains: gcc clang. > configure: error: Cannot continue. > > > > On Fri, Mar 29, 2019 at 11:35 AM Andrew John Hughes > wrote: > >> On 29/03/2019 16:23, Martin Buchholz wrote: >> > Recipe: >> > >> > ( rm -rf build; set -x; bash configure --with-toolchain-type=gcc >> > --with-boot-jdk=$HOME/jdk/jdk7 && make reconfigure ) >> > => >> > configure: Toolchain type gcc --with-boot-jdk=.../jdk/jdk7 is not valid >> on >> > this platform. >> > configure: Valid toolchains: gcc clang. >> > >> > --- >> > Do y'all always build from scratch? >> > >> >> Personally speaking, not always. It depends what I've altered. >> >> Where are you seeing this? jdk8u or jdk8u-dev? And any idea what change >> caused it? >> >> 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 martinrb at google.com Mon Apr 1 21:32:19 2019 From: martinrb at google.com (Martin Buchholz) Date: Mon, 1 Apr 2019 14:32:19 -0700 Subject: make reconfigure broken (quoting problem?) In-Reply-To: <5B8B711F-D079-4138-8BDC-06406062EDEF@amazon.com> References: <5B8B711F-D079-4138-8BDC-06406062EDEF@amazon.com> Message-ID: 1. JDK-8221789 make reconfigure broken (jdk8u only) On Mon, Apr 1, 2019 at 1:27 PM Hohensee, Paul wrote: > Is there a JBS issue for this? > > ?On 4/1/19, 12:19 PM, "jdk8u-dev on behalf of Martin Buchholz" < > jdk8u-dev-bounces at openjdk.java.net on behalf of martinrb at google.com> > wrote: > > Kevin - Thanks. This looks like the right fix, making jdk8's behavior > consistent with later jdks. > > Who will volunteer to check in Kevin's fix? > > On Mon, Apr 1, 2019 at 1:54 AM Kevin Walls > wrote: > > > Hi Martin - > > > > I recall "make reconfigure" working but clearly there's a > > complication.... Looks like reconfigure doesn't handle >1 > argument. It > > looks like it's processing all the args to configure as one, rather > than > > individually? I just tried this make change and "make reconfigure" > worked > > with two arguments to configure: > > > > diff -r 9a4af54dd074 make/Main.gmk > > --- a/make/Main.gmk Fri Mar 22 17:51:45 2019 +0000 > > +++ b/make/Main.gmk Mon Apr 01 01:44:05 2019 -0700 > > @@ -238,7 +238,7 @@ > > else > > @$(ECHO) "Re-running configure using default settings" > > endif > > - @( cd $(OUTPUT_ROOT) && $(BASH) $(TOPDIR)/configure > > "$(CONFIGURE_COMMAND_LINE)" ) > > + @( cd $(OUTPUT_ROOT) && $(BASH) $(TOPDIR)/configure > > $(CONFIGURE_COMMAND_LINE) ) > > > > .PHONY: langtools corba jaxp jaxws hotspot jdk nashorn images > > overlay-images install test docs > > .PHONY: langtools-only corba-only jaxp-only jaxws-only hotspot-only > > jdk-only nashorn-only images-only overlay-images-only install-only > > test-only docs-only > > > > I looked in 11u and this isn't a problem there, it's laid out a > little > > differently and this happens in make/Init.gmk > > > > Hope that helps, > > Kevin > > > > > > On 30/03/2019 01:48, Martin Buchholz wrote: > > > > It looks to me like this feature was broken at the time of its > backport to > > jdk8u > > > > changeset: 2163:2209644bcac4 > > user: kevinw > > date: 2018-04-10 07:46 -0700 > > 8034199: Add 'reconfigure' target for re-creating a configuration > > Reviewed-by: ihse, erikj, tbell > > > > Recipe: > > hg update 2209644bcac4 && hg log -r . && bash configure > > --with-toolchain-type=gcc --with-boot-jdk=$HOME/jdk/jdk7 && make > > reconfigure > > ... > > configure: Toolchain type gcc --with-boot-jdk=.../jdk/jdk7 is not > valid on > > this platform. > > configure: Valid toolchains: gcc clang. > > configure: error: Cannot continue. > > > > > > > > On Fri, Mar 29, 2019 at 11:35 AM Andrew John Hughes < > gnu.andrew at redhat.com> > > wrote: > > > >> On 29/03/2019 16:23, Martin Buchholz wrote: > >> > Recipe: > >> > > >> > ( rm -rf build; set -x; bash configure --with-toolchain-type=gcc > >> > --with-boot-jdk=$HOME/jdk/jdk7 && make reconfigure ) > >> > => > >> > configure: Toolchain type gcc --with-boot-jdk=.../jdk/jdk7 is not > valid > >> on > >> > this platform. > >> > configure: Valid toolchains: gcc clang. > >> > > >> > --- > >> > Do y'all always build from scratch? > >> > > >> > >> Personally speaking, not always. It depends what I've altered. > >> > >> Where are you seeing this? jdk8u or jdk8u-dev? And any idea what > change > >> caused it? > >> > >> 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 grzesuav at gmail.com Mon Apr 1 16:20:43 2019 From: grzesuav at gmail.com (=?UTF-8?B?R3J6ZWdvcnogR8WCxIVi?=) Date: Mon, 1 Apr 2019 18:20:43 +0200 Subject: Cannot build jdk8 on kernel 5.x In-Reply-To: <71258591-0631-bd53-9d04-9985441091f2@redhat.com> References: <71258591-0631-bd53-9d04-9985441091f2@redhat.com> Message-ID: pon., 1 kwi 2019 o 18:19 Aleksey Shipilev napisa?(a): > > On 4/1/19 6:13 PM, Grzegorz G??b wrote: > > when I tried build openjdk (via adoptopenjdk scripts) I encountered an > > issue as described here > > (https://github.com/AdoptOpenJDK/openjdk-build/issues/999) > > > > TL;DR missing 5.x in > > https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/master/hotspot/make/linux/Makefile#L236 > > (probably equivalent here) > > Well, it is fixed in 8u for at least two weeks now: > https://bugs.openjdk.java.net/browse/JDK-8217753 > http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/5af8ec63c21c > > Ask AdoptOpenJDK people what exactly do they have in their mirror. It seems their latest sync was 28 > days ago -- and that quite probably misses a lot of work done in 8u. > > -Aleksey > Thanks! will do, cheers From martijnverburg at gmail.com Mon Apr 1 23:12:43 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 1 Apr 2019 23:12:43 +0000 Subject: Cannot build jdk8 on kernel 5.x In-Reply-To: References: <71258591-0631-bd53-9d04-9985441091f2@redhat.com> Message-ID: Yep our embarrassing bad, we're checking our sync tooling. Sorry for the bad line noise. Cheers, Martijn On Mon, 1 Apr 2019 at 23:13, Grzegorz G??b wrote: > pon., 1 kwi 2019 o 18:19 Aleksey Shipilev napisa?(a): > > > > On 4/1/19 6:13 PM, Grzegorz G??b wrote: > > > when I tried build openjdk (via adoptopenjdk scripts) I encountered an > > > issue as described here > > > (https://github.com/AdoptOpenJDK/openjdk-build/issues/999) > > > > > > TL;DR missing 5.x in > > > > https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/master/hotspot/make/linux/Makefile#L236 > > > (probably equivalent here) > > > > Well, it is fixed in 8u for at least two weeks now: > > https://bugs.openjdk.java.net/browse/JDK-8217753 > > http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/5af8ec63c21c > > > > Ask AdoptOpenJDK people what exactly do they have in their mirror. It > seems their latest sync was 28 > > days ago -- and that quite probably misses a lot of work done in 8u. > > > > -Aleksey > > > > Thanks! > > > will do, > > cheers > From gnu.andrew at redhat.com Tue Apr 2 01:28:27 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 2 Apr 2019 02:28:27 +0100 Subject: [FREEZE] 8u212 NOW FROZEN Message-ID: The release tree: https://hg.openjdk.java.net/jdk8u/jdk8u (and friends) is now frozen in preparation for release on 2019-04-16. The final release will be based on jdk8u212-b02 [0] [1] [2] [3] [4] [5] [6] [7] and will have a version no lower than jdk8u212-b03. [0] https://hg.openjdk.java.net/jdk8u/jdk8u/rev/5218ef8ea6c3 [1] https://hg.openjdk.java.net/jdk8u/jdk8u/nashorn/rev/f470f90fa4f7 [2] https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/20c8a9b1cc6e [3] https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/96fec237fcc0 [4] https://hg.openjdk.java.net/jdk8u/jdk8u/jaxws/rev/edd8659683b4 [5] https://hg.openjdk.java.net/jdk8u/jdk8u/jaxp/rev/7dca173f654e [6] https://hg.openjdk.java.net/jdk8u/jdk8u/corba/rev/b6ed07cab3f8 [7] https://hg.openjdk.java.net/jdk8u/jdk8u/langtools/rev/4c4c8a86bcb2 -- 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 Apr 2 01:47:34 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 2 Apr 2019 02:47:34 +0100 Subject: [FREEZE] 8u212 NOW FROZEN In-Reply-To: References: Message-ID: On 02/04/2019 02:28, Andrew John Hughes wrote: > The release tree: > > https://hg.openjdk.java.net/jdk8u/jdk8u (and friends) > > is now frozen in preparation for release on 2019-04-16. > > The final release will be based on jdk8u212-b02 [0] [1] [2] [3] [4] [5] > [6] [7] and will have a version no lower than jdk8u212-b03. > > [0] https://hg.openjdk.java.net/jdk8u/jdk8u/rev/5218ef8ea6c3 > [1] https://hg.openjdk.java.net/jdk8u/jdk8u/nashorn/rev/f470f90fa4f7 > [2] https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/20c8a9b1cc6e > [3] https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/96fec237fcc0 > [4] https://hg.openjdk.java.net/jdk8u/jdk8u/jaxws/rev/edd8659683b4 > [5] https://hg.openjdk.java.net/jdk8u/jdk8u/jaxp/rev/7dca173f654e > [6] https://hg.openjdk.java.net/jdk8u/jdk8u/corba/rev/b6ed07cab3f8 > [7] https://hg.openjdk.java.net/jdk8u/jdk8u/langtools/rev/4c4c8a86bcb2 > Note that the final part of the Japanese era work: https://bugs.openjdk.java.net/browse/JDK-8205432 will be included in the CPU and I'll backport it to the public jdk8u-dev branch so others can include it 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 Tue Apr 2 19:12:28 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 2 Apr 2019 20:12:28 +0100 Subject: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633 In-Reply-To: References: <627764ae-9c68-4113-920b-f1010086e8c7@default> <494625e0-1b03-d345-7313-1eed01cec68f@oracle.com> <7afc386a-11ac-403c-a6ec-0d7988604818@default> <94b978d4-aabc-4551-8229-3b8a71d37d5f@default> Message-ID: On 26/03/2019 08:09, Langer, Christoph wrote: > Hi Deepak, > >> Thanks for review. I think Naoto and Ramanand are right, we do update the >> copyright year when it is not a clean backport. Please find the updated >> version of webrev. >> >> http://cr.openjdk.java.net/~rpatil/8042131_8210633/webrev.01/ > > Ok, you are right... Still wondering, whether in the test the copyright year should be 2012, 2019, since it is very much derived from the upstream version. But in the end, I don't want to bikeshed. All good for me ?? > > Thanks > Christoph > This still doesn't seem to have been pushed, despite being approved a week ago. As I understand it, this should be included in the upcoming 11.0.3 release, so can it please be pushed as a matter of urgency? 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 ali.ince at gmail.com Tue Apr 2 22:08:26 2019 From: ali.ince at gmail.com (Ali Ince) Date: Tue, 2 Apr 2019 23:08:26 +0100 Subject: [PATCH] [8u] Prevent MSDOS8.3 named DLL in built image In-Reply-To: References: Message-ID: Hi Christoph, Thanks for your reply. I'm on Windows 10 but can also try a build on Windows 7 (which is AFAIK the oldest supported version by MSFT). I can build JDK8 with VS2017 for both 32-bit and 64-bit targets. My builds included the `--disable-warnings-as-errors` flag but it seems reasonable to try the build without this flag to see whether it will surface any errors. I'll give it a try and also make (well at least try) a comparison with the JDK11 changeset you've referenced. Best regards, Ali On Mon, Apr 1, 2019 at 7:06 AM Langer, Christoph wrote: > Hi Ali, > > generally, I think this makes sense. Maybe, however, there are still some > legacy compile environments around somewhere which will have a problem with > that, e.g. very old Windows versions? It's hard to tell but it's probably > reasonable to try out the fix. > > I found the change to be part of a VS2017 enabling fix for JDK11: > > https://bugs.openjdk.java.net/browse/JDK-8201267 > http://hg.openjdk.java.net/jdk/jdk/rev/7c224ec572d0 > > So I have a general question: Shouldn't this fix be part of a larger > change that would enable VS2017 for JDK8? I assume it won't be the only > thing to touch... > > Best regards > Christoph > > > > > -----Original Message----- > > From: jdk8u-dev On Behalf Of Ali > > Ince > > Sent: Donnerstag, 28. M?rz 2019 20:48 > > To: jdk8u-dev at openjdk.java.net > > Subject: [PATCH] [8u] Prevent MSDOS8.3 named DLL in built image > > > > Hi All, > > > > We're working on building JDK8U with VS2017 at AdoptOpenJDK and found > > out that the new vcruntime140.dll is copied to the built image named as > > `vcrunt~1.dll` which is basically because of the extra call to > > `BASIC_FIXUP_PATH` call in `toolchain_windows.m4` file. If the call is > > removed, everything works fine. > > > > On previous versions of VS, the VC runtime DLL was originally named in > 8.3 > > style (ex. msvcr100.dll) and BASIC_FIXUP_PATH did not have any affect on > > the file name itself. I've checked with `toolchain_windows.m4` files in > jdk11u > > and onwards and also saw that this call doesn't exist. > > > > I've came up with the following patch which removes this call. I'm not > sure > > what's the process about updating the checked-in generated_configure.sh > > but I could also add the patch for that if it's required. > > > > Let me know if you have any feedback or comments. > > > > Regards, > > > > Ali > > > > --------------------------------------------- > > > > diff -r e0b7721459ee common/autoconf/toolchain_windows.m4 > > --- a/common/autoconf/toolchain_windows.m4 Wed Mar 20 16:32:54 2019 > > +0000 > > +++ b/common/autoconf/toolchain_windows.m4 Thu Mar 28 00:03:10 2019 > > +0000 > > @@ -493,7 +493,6 @@ > > if $ECHO "$MSVC_DLL_FILETYPE" | $GREP "$CORRECT_MSVCR_ARCH" > > 2>&1 > /dev/null; then > > AC_MSG_RESULT([ok]) > > MSVC_DLL="$POSSIBLE_MSVC_DLL" > > - BASIC_FIXUP_PATH(MSVC_DLL) > > AC_MSG_CHECKING([for $DLL_NAME]) > > AC_MSG_RESULT([$MSVC_DLL]) > > else > > > > From gnu.andrew at redhat.com Wed Apr 3 03:06:51 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 3 Apr 2019 04:06:51 +0100 Subject: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633 In-Reply-To: References: <627764ae-9c68-4113-920b-f1010086e8c7@default> <494625e0-1b03-d345-7313-1eed01cec68f@oracle.com> <7afc386a-11ac-403c-a6ec-0d7988604818@default> <94b978d4-aabc-4551-8229-3b8a71d37d5f@default> Message-ID: On 02/04/2019 20:12, Andrew John Hughes wrote: > > > On 26/03/2019 08:09, Langer, Christoph wrote: >> Hi Deepak, >> >>> Thanks for review. I think Naoto and Ramanand are right, we do update the >>> copyright year when it is not a clean backport. Please find the updated >>> version of webrev. >>> >>> http://cr.openjdk.java.net/~rpatil/8042131_8210633/webrev.01/ >> >> Ok, you are right... Still wondering, whether in the test the copyright year should be 2012, 2019, since it is very much derived from the upstream version. But in the end, I don't want to bikeshed. All good for me ?? >> >> Thanks >> Christoph >> > > This still doesn't seem to have been pushed, despite being approved a > week ago. > > As I understand it, this should be included in the upcoming 11.0.3 > release, so can it please be pushed as a matter of urgency? > > Thanks, > Sorry, that should be 8u212, not 11.0.3 :) -- 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 Wed Apr 3 06:58:15 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 3 Apr 2019 06:58:15 +0000 Subject: [PATCH] [8u] Prevent MSDOS8.3 named DLL in built image In-Reply-To: References: Message-ID: Hi Ali, ok, in that case (working with --disable-warnings-as-errors) it might be worth a separate patch. Then please check whether it?s reasonable to backport a larger part of https://bugs.openjdk.java.net/browse/JDK-8201267. If so, please provide a webrev for it. Otherwise, let me know, too, and I can create a bug for just bringing in your original small fix and run it through the backport process. Best regards Christoph From: Ali Ince Sent: Mittwoch, 3. April 2019 00:08 To: Langer, Christoph Cc: jdk8u-dev at openjdk.java.net Subject: Re: [PATCH] [8u] Prevent MSDOS8.3 named DLL in built image Hi Christoph, Thanks for your reply. I'm on Windows 10 but can also try a build on Windows 7 (which is AFAIK the oldest supported version by MSFT). I can build JDK8 with VS2017 for both 32-bit and 64-bit targets. My builds included the `--disable-warnings-as-errors` flag but it seems reasonable to try the build without this flag to see whether it will surface any errors. I'll give it a try and also make (well at least try) a comparison with the JDK11 changeset you've referenced. Best regards, Ali On Mon, Apr 1, 2019 at 7:06 AM Langer, Christoph > wrote: Hi Ali, generally, I think this makes sense. Maybe, however, there are still some legacy compile environments around somewhere which will have a problem with that, e.g. very old Windows versions? It's hard to tell but it's probably reasonable to try out the fix. I found the change to be part of a VS2017 enabling fix for JDK11: https://bugs.openjdk.java.net/browse/JDK-8201267 http://hg.openjdk.java.net/jdk/jdk/rev/7c224ec572d0 So I have a general question: Shouldn't this fix be part of a larger change that would enable VS2017 for JDK8? I assume it won't be the only thing to touch... Best regards Christoph > -----Original Message----- > From: jdk8u-dev > On Behalf Of Ali > Ince > Sent: Donnerstag, 28. M?rz 2019 20:48 > To: jdk8u-dev at openjdk.java.net > Subject: [PATCH] [8u] Prevent MSDOS8.3 named DLL in built image > > Hi All, > > We're working on building JDK8U with VS2017 at AdoptOpenJDK and found > out that the new vcruntime140.dll is copied to the built image named as > `vcrunt~1.dll` which is basically because of the extra call to > `BASIC_FIXUP_PATH` call in `toolchain_windows.m4` file. If the call is > removed, everything works fine. > > On previous versions of VS, the VC runtime DLL was originally named in 8.3 > style (ex. msvcr100.dll) and BASIC_FIXUP_PATH did not have any affect on > the file name itself. I've checked with `toolchain_windows.m4` files in jdk11u > and onwards and also saw that this call doesn't exist. > > I've came up with the following patch which removes this call. I'm not sure > what's the process about updating the checked-in generated_configure.sh > but I could also add the patch for that if it's required. > > Let me know if you have any feedback or comments. > > Regards, > > Ali > > --------------------------------------------- > > diff -r e0b7721459ee common/autoconf/toolchain_windows.m4 > --- a/common/autoconf/toolchain_windows.m4 Wed Mar 20 16:32:54 2019 > +0000 > +++ b/common/autoconf/toolchain_windows.m4 Thu Mar 28 00:03:10 2019 > +0000 > @@ -493,7 +493,6 @@ > if $ECHO "$MSVC_DLL_FILETYPE" | $GREP "$CORRECT_MSVCR_ARCH" > 2>&1 > /dev/null; then > AC_MSG_RESULT([ok]) > MSVC_DLL="$POSSIBLE_MSVC_DLL" > - BASIC_FIXUP_PATH(MSVC_DLL) > AC_MSG_CHECKING([for $DLL_NAME]) > AC_MSG_RESULT([$MSVC_DLL]) > else > From christoph.langer at sap.com Wed Apr 3 13:20:13 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 3 Apr 2019 13:20:13 +0000 Subject: RFR: JDK8U Backport of JDK-8042131 and JDK-8210633 In-Reply-To: References: <627764ae-9c68-4113-920b-f1010086e8c7@default> <494625e0-1b03-d345-7313-1eed01cec68f@oracle.com> <7afc386a-11ac-403c-a6ec-0d7988604818@default> <94b978d4-aabc-4551-8229-3b8a71d37d5f@default> Message-ID: > On 02/04/2019 20:12, Andrew John Hughes wrote: > > > > > > On 26/03/2019 08:09, Langer, Christoph wrote: > >> Hi Deepak, > >> > >>> Thanks for review. I think Naoto and Ramanand are right, we do update > the > >>> copyright year when it is not a clean backport. Please find the updated > >>> version of webrev. > >>> > >>> http://cr.openjdk.java.net/~rpatil/8042131_8210633/webrev.01/ > >> > >> Ok, you are right... Still wondering, whether in the test the copyright year > should be 2012, 2019, since it is very much derived from the upstream > version. But in the end, I don't want to bikeshed. All good for me ?? > >> > >> Thanks > >> Christoph > >> > > > > This still doesn't seem to have been pushed, despite being approved a > > week ago. > > > > As I understand it, this should be included in the upcoming 11.0.3 > > release, so can it please be pushed as a matter of urgency? > > > > Thanks, > > > > Sorry, that should be 8u212, not 11.0.3 :) To further clarify: Please push to http://hg.openjdk.java.net/jdk8u/jdk8u-dev/ ?? Thanks Christoph From hohensee at amazon.com Wed Apr 3 22:07:22 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 3 Apr 2019 22:07:22 +0000 Subject: JDK-8205432 and Japanese era friends Message-ID: <9E9E49D0-E8A8-4ACD-9596-F4C65B716810@amazon.com> Andrew Hughes just pushed a backport to jdk11u of https://bugs.openjdk.java.net/browse/JDK-8205432. According to the JBS issue, the equivalent backport hasn?t been done for openjdk8u212, but has been done for Oracle 8u212. Should it be done for openjdk8u212? Paul From gnu.andrew at redhat.com Thu Apr 4 02:26:14 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 4 Apr 2019 03:26:14 +0100 Subject: JDK-8205432 and Japanese era friends In-Reply-To: <9E9E49D0-E8A8-4ACD-9596-F4C65B716810@amazon.com> References: <9E9E49D0-E8A8-4ACD-9596-F4C65B716810@amazon.com> Message-ID: <3316ee17-3220-5495-b8c0-81e3d57b5c0f@redhat.com> On 03/04/2019 23:07, Hohensee, Paul wrote: > Andrew Hughes just pushed a backport to jdk11u of https://bugs.openjdk.java.net/browse/JDK-8205432. According to the JBS issue, the equivalent backport hasn?t been done for openjdk8u212, but has been done for Oracle 8u212. Should it be done for openjdk8u212? > > Paul > I've done it. Will post it shortly. 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 Apr 4 03:08:11 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 4 Apr 2019 04:08:11 +0100 Subject: OpenJDK 8u212-b02 EA Released Message-ID: <05a40523-7b8d-ec01-64b1-f731aae20a9a@redhat.com> I've made available an early access source bundle for 8u202, based on the freeze point of jdk8u212-b02: https://openjdk-sources.osci.io/openjdk8/openjdk8u212-b02.tar.xz The tarball is accompanied by a digital signature available at: https://openjdk-sources.osci.io/openjdk8/openjdk8u212-b02.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: 860f1ada08cec63e101236f9cc32a0213d268fab082dbb908155e839e1f0bdb5 openjdk8u212-b02.tar.xz 84a753947e6588bd6e14b39fc47d03f1271bfa9148e9b6bb06f6a200eb2486f6 openjdk8u212-b02.tar.xz.sig They are listed at https://openjdk-sources.osci.io/openjdk8/openjdk8u212-b02.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 neugens at redhat.com Thu Apr 4 10:01:34 2019 From: neugens at redhat.com (Mario Torre) Date: Thu, 04 Apr 2019 12:01:34 +0200 Subject: Status of JFR port and some timelines Message-ID: <1703245efe412f6c919967c82744383aed1719d5.camel@redhat.com> Hi all, First of all, thanks again for moving this forward, I still have to find the time myself to go through the latest couple of patches that were presented, but overall I think we are ready for the next step, so I wanted to have a quick sync up regarding the status of the port. I think we are at a point where we can merge the Azul patch and then the extra features that Alibaba backported. The next CPU is scheduled to be on the 16th of April, so I would like to take this opportunity to have a full sync between our staging repository and the main one once all the security patches have been published, I would say around the 22nd to give some extra time to merge last minute and eventual post errata fixes if there are any. Right after that, we will proceed with the merging of JFR, although we had a round of pre-reviews already and the patch is mostly good to go, I would like Azul to rebase it to the state of the staging repo at that point and send a formal review request, we will push once approved and then start working incrementally on the other features on top, the goal is to have the formal review finished by end of April for the core patch. It is still too early to decide when to merge the code over jdk8u-dev, so we should start maintaining the repository over time, syncing up after the CPU is necessary but if regular patches are flowing faster then the CPU errata I'll try to sync more regularly. I'm thinking to reuse the first JFR bug id for the core patch and then create new bugs for fixes and other features (unless we can track down existing ones for each of them of course), so we don't diverge from the original. I will send an email once the sync is done so we can rebase. Are there any questions or remarks about that plan, or additional suggestions? Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From kevin.walls at oracle.com Thu Apr 4 11:00:49 2019 From: kevin.walls at oracle.com (Kevin Walls) Date: Thu, 4 Apr 2019 12:00:49 +0100 Subject: make reconfigure broken (quoting problem?) In-Reply-To: References: <5B8B711F-D079-4138-8BDC-06406062EDEF@amazon.com> Message-ID: <62979e8b-a68b-672f-5f5c-fcc11c08b939@oracle.com> Hi - I assigned the bug to me, I'll come back with a review email... 8-) On 01/04/2019 22:32, Martin Buchholz wrote: > > 1. JDK-8221789 > > > make reconfigure broken (jdk8u only) > > > > On Mon, Apr 1, 2019 at 1:27 PM Hohensee, Paul > wrote: > > Is there a JBS issue for this? > > ?On 4/1/19, 12:19 PM, "jdk8u-dev on behalf of Martin Buchholz" > on behalf of > martinrb at google.com > wrote: > > ? ? Kevin - Thanks.? This looks like the right fix, making jdk8's > behavior > ? ? consistent with later jdks. > > ? ? Who will volunteer to check in Kevin's fix? > > ? ? On Mon, Apr 1, 2019 at 1:54 AM Kevin Walls > > wrote: > > ? ? > Hi Martin - > ? ? > > ? ? > I recall "make reconfigure" working but clearly there's a > ? ? > complication....? Looks like reconfigure doesn't handle >1 > argument.? It > ? ? > looks like it's processing all the args to configure as one, > rather than > ? ? > individually?? ?I just tried this make change and "make > reconfigure" worked > ? ? > with two arguments to configure: > ? ? > > ? ? > diff -r 9a4af54dd074 make/Main.gmk > ? ? > --- a/make/Main.gmk? ? ?Fri Mar 22 17:51:45 2019 +0000 > ? ? > +++ b/make/Main.gmk? ? ?Mon Apr 01 01:44:05 2019 -0700 > ? ? > @@ -238,7 +238,7 @@ > ? ? >? ? ? ? ? else > ? ? >? ? ? ? ? ?@$(ECHO) "Re-running configure using default settings" > ? ? >? ? ? ? ? endif > ? ? > -? ? ? ?@( cd $(OUTPUT_ROOT) && $(BASH) $(TOPDIR)/configure > ? ? > "$(CONFIGURE_COMMAND_LINE)" ) > ? ? > +? ? ? ?@( cd $(OUTPUT_ROOT) && $(BASH) $(TOPDIR)/configure > ? ? > $(CONFIGURE_COMMAND_LINE) ) > ? ? > > ? ? >? .PHONY: langtools corba jaxp jaxws hotspot jdk nashorn images > ? ? > overlay-images install test docs > ? ? >? .PHONY: langtools-only corba-only jaxp-only jaxws-only > hotspot-only > ? ? > jdk-only nashorn-only images-only overlay-images-only > install-only > ? ? > test-only docs-only > ? ? > > ? ? > I looked in 11u and this isn't a problem there, it's laid > out a little > ? ? > differently and this happens in make/Init.gmk > ? ? > > ? ? > Hope that helps, > ? ? > Kevin > ? ? > > ? ? > > ? ? > On 30/03/2019 01:48, Martin Buchholz wrote: > ? ? > > ? ? > It looks to me like this feature was broken at the time of > its backport to > ? ? > jdk8u > ? ? > > ? ? > changeset:? ?2163:2209644bcac4 > ? ? > user:? ? ? ? kevinw > ? ? > date:? ? ? ? 2018-04-10 07:46 -0700 > ? ? > 8034199: Add 'reconfigure' target for re-creating a > configuration > ? ? > Reviewed-by: ihse, erikj, tbell > ? ? > > ? ? > Recipe: > ? ? > hg update 2209644bcac4 && hg log -r . && bash configure > ? ? > --with-toolchain-type=gcc --with-boot-jdk=$HOME/jdk/jdk7 && make > ? ? > reconfigure > ? ? > ... > ? ? > configure: Toolchain type gcc --with-boot-jdk=.../jdk/jdk7 > is not valid on > ? ? > this platform. > ? ? > configure: Valid toolchains: gcc clang. > ? ? > configure: error: Cannot continue. > ? ? > > ? ? > > ? ? > > ? ? > On Fri, Mar 29, 2019 at 11:35 AM Andrew John Hughes > > > ? ? > wrote: > ? ? > > ? ? >> On 29/03/2019 16:23, Martin Buchholz wrote: > ? ? >> > Recipe: > ? ? >> > > ? ? >> > ( rm -rf build; set -x; bash configure > --with-toolchain-type=gcc > ? ? >> > --with-boot-jdk=$HOME/jdk/jdk7 && make reconfigure ) > ? ? >> > => > ? ? >> > configure: Toolchain type gcc > --with-boot-jdk=.../jdk/jdk7 is not valid > ? ? >> on > ? ? >> > this platform. > ? ? >> > configure: Valid toolchains: gcc clang. > ? ? >> > > ? ? >> > --- > ? ? >> > Do y'all always build from scratch? > ? ? >> > > ? ? >> > ? ? >> Personally speaking, not always. It depends what I've altered. > ? ? >> > ? ? >> Where are you seeing this? jdk8u or jdk8u-dev? And any idea > what change > ? ? >> caused it? > ? ? >> > ? ? >> 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 kevin.walls at oracle.com Thu Apr 4 11:04:57 2019 From: kevin.walls at oracle.com (Kevin Walls) Date: Thu, 4 Apr 2019 12:04:57 +0100 Subject: RFR(S): 8221789: make reconfigure broken (jdk8u only) Message-ID: Hi, I'd like to get a review of this small make change: 8221789: make reconfigure broken (jdk8u only) JBS: https://bugs.openjdk.java.net/browse/JDK-8221789 hg diff pasted in below, and existing discussion: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009036.html This fixes a simple quoting error which broke argument passing in "make reconfigure". Thanks Kevin bash-4.2$ hg diff make/Main.gmk diff -r f6bc08715234 make/Main.gmk --- a/make/Main.gmk???? Mon Apr 01 14:28:36 2019 +0200 +++ b/make/Main.gmk???? Thu Apr 04 03:57:24 2019 -0700 @@ -238,7 +238,7 @@ ???????? else ????????? @$(ECHO) "Re-running configure using default settings" ???????? endif -?????? @( cd $(OUTPUT_ROOT) && $(BASH) $(TOPDIR)/configure "$(CONFIGURE_COMMAND_LINE)" ) +?????? @( cd $(OUTPUT_ROOT) && $(BASH) $(TOPDIR)/configure $(CONFIGURE_COMMAND_LINE) ) ?.PHONY: langtools corba jaxp jaxws hotspot jdk nashorn images overlay-images install test docs ?.PHONY: langtools-only corba-only jaxp-only jaxws-only hotspot-only jdk-only nashorn-only images-only overlay-images-only install-only test-only docs-only From hohensee at amazon.com Thu Apr 4 12:19:47 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 4 Apr 2019 12:19:47 +0000 Subject: RFR(S): 8221789: make reconfigure broken (jdk8u only) In-Reply-To: References: Message-ID: <74008022-4F5B-4F35-BDF9-C69CC7031D8F@amazon.com> Looks good. Paul ?On 4/4/19, 4:06 AM, "jdk8u-dev on behalf of Kevin Walls" wrote: Hi, I'd like to get a review of this small make change: 8221789: make reconfigure broken (jdk8u only) JBS: https://bugs.openjdk.java.net/browse/JDK-8221789 hg diff pasted in below, and existing discussion: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009036.html This fixes a simple quoting error which broke argument passing in "make reconfigure". Thanks Kevin bash-4.2$ hg diff make/Main.gmk diff -r f6bc08715234 make/Main.gmk --- a/make/Main.gmk Mon Apr 01 14:28:36 2019 +0200 +++ b/make/Main.gmk Thu Apr 04 03:57:24 2019 -0700 @@ -238,7 +238,7 @@ else @$(ECHO) "Re-running configure using default settings" endif - @( cd $(OUTPUT_ROOT) && $(BASH) $(TOPDIR)/configure "$(CONFIGURE_COMMAND_LINE)" ) + @( cd $(OUTPUT_ROOT) && $(BASH) $(TOPDIR)/configure $(CONFIGURE_COMMAND_LINE) ) .PHONY: langtools corba jaxp jaxws hotspot jdk nashorn images overlay-images install test docs .PHONY: langtools-only corba-only jaxp-only jaxws-only hotspot-only jdk-only nashorn-only images-only overlay-images-only install-only test-only docs-only From martinrb at google.com Thu Apr 4 14:23:07 2019 From: martinrb at google.com (Martin Buchholz) Date: Thu, 4 Apr 2019 07:23:07 -0700 Subject: RFR(S): 8221789: make reconfigure broken (jdk8u only) In-Reply-To: References: Message-ID: Looks good to me! On Thu, Apr 4, 2019 at 4:05 AM Kevin Walls wrote: > Hi, > > I'd like to get a review of this small make change: > > 8221789: make reconfigure broken (jdk8u only) > JBS: https://bugs.openjdk.java.net/browse/JDK-8221789 > > hg diff pasted in below, and existing discussion: > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009036.html > > This fixes a simple quoting error which broke argument passing in "make > reconfigure". > > Thanks > Kevin > > > bash-4.2$ hg diff make/Main.gmk > diff -r f6bc08715234 make/Main.gmk > --- a/make/Main.gmk Mon Apr 01 14:28:36 2019 +0200 > +++ b/make/Main.gmk Thu Apr 04 03:57:24 2019 -0700 > @@ -238,7 +238,7 @@ > else > @$(ECHO) "Re-running configure using default settings" > endif > - @( cd $(OUTPUT_ROOT) && $(BASH) $(TOPDIR)/configure > "$(CONFIGURE_COMMAND_LINE)" ) > + @( cd $(OUTPUT_ROOT) && $(BASH) $(TOPDIR)/configure > $(CONFIGURE_COMMAND_LINE) ) > > .PHONY: langtools corba jaxp jaxws hotspot jdk nashorn images > overlay-images install test docs > .PHONY: langtools-only corba-only jaxp-only jaxws-only hotspot-only > jdk-only nashorn-only images-only overlay-images-only install-only > test-only docs-only > > > From kevin.walls at oracle.com Thu Apr 4 14:57:56 2019 From: kevin.walls at oracle.com (Kevin Walls) Date: Thu, 4 Apr 2019 15:57:56 +0100 Subject: RFR(S): 8221789: make reconfigure broken (jdk8u only) In-Reply-To: References: Message-ID: <15ead35b-14e6-4be0-fbc5-7355ea74b07d@oracle.com> Thanks Paul, Martin! On 04/04/2019 15:23, Martin Buchholz wrote: > Looks good to me! > > On Thu, Apr 4, 2019 at 4:05 AM Kevin Walls > wrote: > > Hi, > > I'd like to get a review of this small make change: > > 8221789: make reconfigure broken (jdk8u only) > JBS: https://bugs.openjdk.java.net/browse/JDK-8221789 > > hg diff pasted in below, and existing discussion: > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009036.html > > This fixes a simple quoting error which broke argument passing in > "make > reconfigure". > > Thanks > Kevin > > > bash-4.2$ hg diff make/Main.gmk > diff -r f6bc08715234 make/Main.gmk > --- a/make/Main.gmk???? Mon Apr 01 14:28:36 2019 +0200 > +++ b/make/Main.gmk???? Thu Apr 04 03:57:24 2019 -0700 > @@ -238,7 +238,7 @@ > ????????? else > ?????????? @$(ECHO) "Re-running configure using default settings" > ????????? endif > -?????? @( cd $(OUTPUT_ROOT) && $(BASH) $(TOPDIR)/configure > "$(CONFIGURE_COMMAND_LINE)" ) > +?????? @( cd $(OUTPUT_ROOT) && $(BASH) $(TOPDIR)/configure > $(CONFIGURE_COMMAND_LINE) ) > > ??.PHONY: langtools corba jaxp jaxws hotspot jdk nashorn images > overlay-images install test docs > ??.PHONY: langtools-only corba-only jaxp-only jaxws-only hotspot-only > jdk-only nashorn-only images-only overlay-images-only install-only > test-only docs-only > > From gnu.andrew at redhat.com Thu Apr 4 15:35:48 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 4 Apr 2019 16:35:48 +0100 Subject: RFR: [8u] 8219890: Calendar.getDisplayName() returns empty string for new Japanese Era on some locales Message-ID: <310622d7-67fa-9206-745c-3218004ff232@redhat.com> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8219890/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8219890 This is largely a clean patch, with two minor adjustments besides path changes: * The copyright change in src/share/classes/java/util/JapaneseImperialCalendar.java is not applied, as it already has 2019. * The changes to names in test/java/util/Calendar/JapaneseEraNameTest.java had to be manually applied due to one being commented out in 8u (JDK-8220020) -- 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 Apr 4 18:26:34 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 4 Apr 2019 18:26:34 +0000 Subject: [8u] 8219890: Calendar.getDisplayName() returns empty string for new Japanese Era on some locales In-Reply-To: <310622d7-67fa-9206-745c-3218004ff232@redhat.com> References: <310622d7-67fa-9206-745c-3218004ff232@redhat.com> Message-ID: <774E32B0-BAD3-4CE0-9342-566829E4B1E9@amazon.com> Looks good. Paul ?On 4/4/19, 8:38 AM, "jdk8u-dev on behalf of Andrew John Hughes" wrote: Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8219890/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8219890 This is largely a clean patch, with two minor adjustments besides path changes: * The copyright change in src/share/classes/java/util/JapaneseImperialCalendar.java is not applied, as it already has 2019. * The changes to names in test/java/util/Calendar/JapaneseEraNameTest.java had to be manually applied due to one being commented out in 8u (JDK-8220020) -- 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 Apr 8 03:39:22 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 8 Apr 2019 04:39:22 +0100 Subject: [8u] 8219890: Calendar.getDisplayName() returns empty string for new Japanese Era on some locales In-Reply-To: <774E32B0-BAD3-4CE0-9342-566829E4B1E9@amazon.com> References: <310622d7-67fa-9206-745c-3218004ff232@redhat.com> <774E32B0-BAD3-4CE0-9342-566829E4B1E9@amazon.com> Message-ID: <520a3685-21ae-9df2-28de-27c512ac2b90@redhat.com> On 04/04/2019 19:26, Hohensee, Paul wrote: > Looks good. > > Paul > > ?On 4/4/19, 8:38 AM, "jdk8u-dev on behalf of Andrew John Hughes" wrote: > > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8219890/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8219890 > > This is largely a clean patch, with two minor adjustments besides path > changes: > > * The copyright change in > src/share/classes/java/util/JapaneseImperialCalendar.java is not > applied, as it already has 2019. > * The changes to names in > test/java/util/Calendar/JapaneseEraNameTest.java had to be manually > applied due to one being commented out in 8u (JDK-8220020) > -- > 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 > > > Thanks. Pushed: https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/8e126e1398ee -- 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 guangyu.zhu at aliyun.com Mon Apr 8 03:52:23 2019 From: guangyu.zhu at aliyun.com (guangyu.zhu) Date: Mon, 08 Apr 2019 11:52:23 +0800 Subject: =?UTF-8?B?UmU6IFN0YXR1cyBvZiBKRlIgcG9ydCBhbmQgc29tZSB0aW1lbGluZXM=?= In-Reply-To: <1703245efe412f6c919967c82744383aed1719d5.camel@redhat.com> References: <1703245efe412f6c919967c82744383aed1719d5.camel@redhat.com> Message-ID: <9ec45d77-e7cc-497a-85c7-d211170b9763.guangyu.zhu@aliyun.com> Hi Mario, This plan is fine for me. Once the formal review is completed by the end of April, we need a more detailed plan to push the code to jdk8u-dev. Thanks, Guangyu ------------------------------------------------------------------ Sender:Mario Torre Sent At:2019 Apr. 4 (Thu.) 18:01 Recipient:jdk8u-dev Cc:Andrey Petushkov ; guangyu.zhu ; Andrew Haley Subject:Status of JFR port and some timelines Hi all, First of all, thanks again for moving this forward, I still have to find the time myself to go through the latest couple of patches that were presented, but overall I think we are ready for the next step, so I wanted to have a quick sync up regarding the status of the port. I think we are at a point where we can merge the Azul patch and then the extra features that Alibaba backported. The next CPU is scheduled to be on the 16th of April, so I would like to take this opportunity to have a full sync between our staging repository and the main one once all the security patches have been published, I would say around the 22nd to give some extra time to merge last minute and eventual post errata fixes if there are any. Right after that, we will proceed with the merging of JFR, although we had a round of pre-reviews already and the patch is mostly good to go, I would like Azul to rebase it to the state of the staging repo at that point and send a formal review request, we will push once approved and then start working incrementally on the other features on top, the goal is to have the formal review finished by end of April for the core patch. It is still too early to decide when to merge the code over jdk8u-dev, so we should start maintaining the repository over time, syncing up after the CPU is necessary but if regular patches are flowing faster then the CPU errata I'll try to sync more regularly. I'm thinking to reuse the first JFR bug id for the core patch and then create new bugs for fixes and other features (unless we can track down existing ones for each of them of course), so we don't diverge from the original. I will send an email once the sync is done so we can rebase. Are there any questions or remarks about that plan, or additional suggestions? Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From gnu.andrew at redhat.com Mon Apr 8 04:40:01 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 8 Apr 2019 05:40:01 +0100 Subject: RFR: [8u] 8205432: Replace the placeholder Japanese era name Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8205432 Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8205432/webrev.01/ This is a relatively clean backport, with a few exceptions, mostly due to unneeded copyright changes or moved files: * 8u has FormatData_ja.java and JavaTimeSupplementary_ja.java in src/share/classes/sun/text/resources/ja/ rather than src/jdk.localedata/share/classes/sun/text/resources/ext/ * The XML files are in src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ rather than src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ * 8u doesn't have test/jdk/java/util/Calendar/ZoneOffsets.java (JDK-8031145 & JDK-8165296 look like potential future test backports) * The changes in src/java.base/share/classes/sun/util/calendar/LocalGregorianCalendar.java take place in src/share/lib/calendars.properties in 8u I compared both with the 11u version of this patch and the 8u version of JDK-8202088, as well as searching the code base for 'NewEra'. 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 Mon Apr 8 08:26:14 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 8 Apr 2019 09:26:14 +0100 Subject: RFR: [8u] 8205432: Replace the placeholder Japanese era name In-Reply-To: References: Message-ID: On 4/8/19 5:40 AM, Andrew John Hughes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8205432 > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8205432/webrev.01/ OK, thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From deepak.kejriwal at oracle.com Mon Apr 8 08:25:27 2019 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Mon, 8 Apr 2019 01:25:27 -0700 (PDT) Subject: RFR: [8u] 8205432: Replace the placeholder Japanese era name In-Reply-To: References: Message-ID: Hi Andrew, Thanks for working on this. Please find below few minor comments:- 1>. For "src/share/classes/java/util/JapaneseImperialCalendar.java" and "src/share/classes/sun/util/calendar/Era.java" please changes the date time format to be consistent with existing defined eras:- * 4 Heisei 1989-01-08 midnight local time - * 5 NewEra 2019-05-01 midnight local time + * 5 Reiwa 2019-05-01T00:00:00 local time Please change "2019-05-01T00:00:00 local time" to "2019-05-01 midnight local time" 2>. For "test/java/time/test/java/time/chrono/TestJapaneseChronology.java" please align "JapaneseEra.of(3)" with existing defined eras in "Object[][] eraNameData()". Regards, Deepak -----Original Message----- From: Andrew John Hughes Sent: Monday, April 8, 2019 10:10 AM To: jdk8u-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Subject: RFR: [8u] 8205432: Replace the placeholder Japanese era name Bug: https://bugs.openjdk.java.net/browse/JDK-8205432 Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8205432/webrev.01/ This is a relatively clean backport, with a few exceptions, mostly due to unneeded copyright changes or moved files: * 8u has FormatData_ja.java and JavaTimeSupplementary_ja.java in src/share/classes/sun/text/resources/ja/ rather than src/jdk.localedata/share/classes/sun/text/resources/ext/ * The XML files are in src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ rather than src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ * 8u doesn't have test/jdk/java/util/Calendar/ZoneOffsets.java (JDK-8031145 & JDK-8165296 look like potential future test backports) * The changes in src/java.base/share/classes/sun/util/calendar/LocalGregorianCalendar.java take place in src/share/lib/calendars.properties in 8u I compared both with the 11u version of this patch and the 8u version of JDK-8202088, as well as searching the code base for 'NewEra'. 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 Apr 9 03:26:52 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 9 Apr 2019 04:26:52 +0100 Subject: RFR: [8u] 8205432: Replace the placeholder Japanese era name In-Reply-To: References: Message-ID: <1732312a-2e9b-59bb-6619-06500830e22d@redhat.com> On 08/04/2019 09:25, Deepak Kejriwal wrote: > Hi Andrew, > > Thanks for working on this. Please find below few minor comments:- > > 1>. For "src/share/classes/java/util/JapaneseImperialCalendar.java" and "src/share/classes/sun/util/calendar/Era.java" please changes the date time format to be consistent with existing defined eras:- > * 4 Heisei 1989-01-08 midnight local time > - * 5 NewEra 2019-05-01 midnight local time > + * 5 Reiwa 2019-05-01T00:00:00 local time > > Please change "2019-05-01T00:00:00 local time" to "2019-05-01 midnight local time" > The change in style is a cleanup that is part of JDK-8048123 [0]. I think we're better bringing over those cleanups than making Reiwa use the bad format, so I've incorporated those parts of [1] into the revised webrev. > 2>. For "test/java/time/test/java/time/chrono/TestJapaneseChronology.java" please align "JapaneseEra.of(3)" with existing defined eras in "Object[][] eraNameData()". > I've fixed this too, but note that this comes from the original patch in 11 and up. So it actually needs fixing there too. Revised webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8205432/webrev.02/ > > Regards, > Deepak > [0] https://mail.openjdk.java.net/pipermail/i18n-dev/2014-July/001438.html [1] https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/91ea77c474b9 -- 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 andrey at azul.com Tue Apr 9 11:48:05 2019 From: andrey at azul.com (Andrey Petushkov) Date: Tue, 9 Apr 2019 11:48:05 +0000 Subject: Status of JFR port and some timelines In-Reply-To: <9ec45d77-e7cc-497a-85c7-d211170b9763.guangyu.zhu@aliyun.com> References: <1703245efe412f6c919967c82744383aed1719d5.camel@redhat.com> <9ec45d77-e7cc-497a-85c7-d211170b9763.guangyu.zhu@aliyun.com> Message-ID: Hi guys, the plan sounds fine with me either. I'll prepare rebased patch as soon as baseline is ready BTW, the current code have two bugs around thread sampling functionality (both coming from Azul's side of the patch). I'll publish fixes along the main patch (inside or outside, whatever you prefer) Regards, Andrey > On 8 Apr 2019, at 06:52, guangyu.zhu wrote: > > Hi Mario, > > This plan is fine for me. Once the formal review is completed by the end of April, we need a more detailed plan to push the code to jdk8u-dev. > > Thanks, > Guangyu > ------------------------------------------------------------------ > Sender:Mario Torre > Sent At:2019 Apr. 4 (Thu.) 18:01 > Recipient:jdk8u-dev > Cc:Andrey Petushkov ; guangyu.zhu ; Andrew Haley > Subject:Status of JFR port and some timelines > > Hi all, > > First of all, thanks again for moving this forward, I still have to > find the time myself to go through the latest couple of patches that > were presented, but overall I think we are ready for the next step, so > I wanted to have a quick sync up regarding the status of the port. > > I think we are at a point where we can merge the Azul patch and then > the extra features that Alibaba backported. > > The next CPU is scheduled to be on the 16th of April, so I would like > to take this opportunity to have a full sync between our staging > repository and the main one once all the security patches have been > published, I would say around the 22nd to give some extra time to merge > last minute and eventual post errata fixes if there are any. > > Right after that, we will proceed with the merging of JFR, although we > had a round of pre-reviews already and the patch is mostly good to go, > I would like Azul to rebase it to the state of the staging repo at that > point and send a formal review request, we will push once approved and > then start working incrementally on the other features on top, the goal > is to have the formal review finished by end of April for the core > patch. > > It is still too early to decide when to merge the code over jdk8u-dev, > so we should start maintaining the repository over time, syncing up > after the CPU is necessary but if regular patches are flowing faster > then the CPU errata I'll try to sync more regularly. > > I'm thinking to reuse the first JFR bug id for the core patch and then > create new bugs for fixes and other features (unless we can track down > existing ones for each of them of course), so we don't diverge from the > original. > > I will send an email once the sync is done so we can rebase. > > Are there any questions or remarks about that plan, or additional > suggestions? > > 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 Tue Apr 9 12:43:10 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 9 Apr 2019 12:43:10 +0000 Subject: Classify JDK-8219890 and JDK-8208656 as critical in JBS Message-ID: Hi Andrew, I can see that the changes for JDK-8219890 [0] and JDK-8208656 [1] have been pushed to jdk8u-dev and jdk11u-dev in the meanwhile. These are most probably prerequisites of the Japanese era update JDK-8205432 [2] that comes with the JDK 8u212 and JDK 11.0.3 CPUs. Can you confirm that? Since I strongly believe so, I have added "jdk11u-critical-request" and "jdk8u-critical-request" to both plus a fix request comment that states its relation to JDK-8205432. I think we should make sure that public fixes which get integrated into the CPU repositories and will hence get merged on the release day are flagged as "critical-yes". This will bring them up in the relevant JBS views, e.g. [3] for jdk8u and [4] for jdk11u and downstream providers of OpenJDK can easily check which public changes will be included on top of the last public tag and get merged in on the release day. Thanks & best regards Christoph [0] https://bugs.openjdk.java.net/browse/JDK-8219890 [1] https://bugs.openjdk.java.net/browse/JDK-8208656 [2] https://bugs.openjdk.java.net/browse/JDK-8205432 [3] https://bugs.openjdk.java.net/issues/?filter=36562 [4] https://bugs.openjdk.java.net/issues/?filter=36558 From aph at redhat.com Tue Apr 9 12:58:46 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 9 Apr 2019 13:58:46 +0100 Subject: RFR: [8u] 8205432: Replace the placeholder Japanese era name In-Reply-To: <1732312a-2e9b-59bb-6619-06500830e22d@redhat.com> References: <1732312a-2e9b-59bb-6619-06500830e22d@redhat.com> Message-ID: <48241cb3-f0ef-04a3-225a-1387803c79fb@redhat.com> On 4/9/19 4:26 AM, Andrew John Hughes wrote: > I've fixed this too, but note that this comes from the original patch in > 11 and up. So it actually needs fixing there too. > > Revised webrev: > https://cr.openjdk.java.net/~andrew/openjdk8/8205432/webrev.02/ OK. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From hohensee at amazon.com Tue Apr 9 15:53:29 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 9 Apr 2019 15:53:29 +0000 Subject: [8u] 8205432: Replace the placeholder Japanese era name Message-ID: <12F0D3AE-3F14-492E-8CD1-1611D70262D2@amazon.com> +1. Paul ?On 4/8/19, 8:28 PM, "core-libs-dev on behalf of Andrew John Hughes" wrote: On 08/04/2019 09:25, Deepak Kejriwal wrote: > Hi Andrew, > > Thanks for working on this. Please find below few minor comments:- > > 1>. For "src/share/classes/java/util/JapaneseImperialCalendar.java" and "src/share/classes/sun/util/calendar/Era.java" please changes the date time format to be consistent with existing defined eras:- > * 4 Heisei 1989-01-08 midnight local time > - * 5 NewEra 2019-05-01 midnight local time > + * 5 Reiwa 2019-05-01T00:00:00 local time > > Please change "2019-05-01T00:00:00 local time" to "2019-05-01 midnight local time" > The change in style is a cleanup that is part of JDK-8048123 [0]. I think we're better bringing over those cleanups than making Reiwa use the bad format, so I've incorporated those parts of [1] into the revised webrev. > 2>. For "test/java/time/test/java/time/chrono/TestJapaneseChronology.java" please align "JapaneseEra.of(3)" with existing defined eras in "Object[][] eraNameData()". > I've fixed this too, but note that this comes from the original patch in 11 and up. So it actually needs fixing there too. Revised webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8205432/webrev.02/ > > Regards, > Deepak > [0] https://mail.openjdk.java.net/pipermail/i18n-dev/2014-July/001438.html [1] https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/91ea77c474b9 -- 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 Apr 9 17:18:20 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 9 Apr 2019 17:18:20 +0000 Subject: [8u] 8205432: Replace the placeholder Japanese era name In-Reply-To: <12F0D3AE-3F14-492E-8CD1-1611D70262D2@amazon.com> References: <12F0D3AE-3F14-492E-8CD1-1611D70262D2@amazon.com> Message-ID: <22BEE3A9-5368-4538-AC0C-4C90E9B42B3B@amazon.com> I meant the current webrev https://cr.openjdk.java.net/~andrew/openjdk8/8205432/webrev.02/ is fine. Just backport what's in tip and fix whatever's wrong later as another backport or backports. Paul ?On 4/9/19, 8:56 AM, "core-libs-dev on behalf of Hohensee, Paul" wrote: +1. Paul On 4/8/19, 8:28 PM, "core-libs-dev on behalf of Andrew John Hughes" wrote: On 08/04/2019 09:25, Deepak Kejriwal wrote: > Hi Andrew, > > Thanks for working on this. Please find below few minor comments:- > > 1>. For "src/share/classes/java/util/JapaneseImperialCalendar.java" and "src/share/classes/sun/util/calendar/Era.java" please changes the date time format to be consistent with existing defined eras:- > * 4 Heisei 1989-01-08 midnight local time > - * 5 NewEra 2019-05-01 midnight local time > + * 5 Reiwa 2019-05-01T00:00:00 local time > > Please change "2019-05-01T00:00:00 local time" to "2019-05-01 midnight local time" > The change in style is a cleanup that is part of JDK-8048123 [0]. I think we're better bringing over those cleanups than making Reiwa use the bad format, so I've incorporated those parts of [1] into the revised webrev. > 2>. For "test/java/time/test/java/time/chrono/TestJapaneseChronology.java" please align "JapaneseEra.of(3)" with existing defined eras in "Object[][] eraNameData()". > I've fixed this too, but note that this comes from the original patch in 11 and up. So it actually needs fixing there too. Revised webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8205432/webrev.02/ > > Regards, > Deepak > [0] https://mail.openjdk.java.net/pipermail/i18n-dev/2014-July/001438.html [1] https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/91ea77c474b9 -- 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 Apr 9 17:26:36 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 9 Apr 2019 18:26:36 +0100 Subject: [8u] 8205432: Replace the placeholder Japanese era name In-Reply-To: <22BEE3A9-5368-4538-AC0C-4C90E9B42B3B@amazon.com> References: <12F0D3AE-3F14-492E-8CD1-1611D70262D2@amazon.com> <22BEE3A9-5368-4538-AC0C-4C90E9B42B3B@amazon.com> Message-ID: On 09/04/2019 18:18, Hohensee, Paul wrote: > I meant the current webrev > > https://cr.openjdk.java.net/~andrew/openjdk8/8205432/webrev.02/ > > is fine. Just backport what's in tip and fix whatever's wrong later as another backport or backports. > > Paul Thanks. I've pushed based on the review of yourself & aph: https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/ee55428fe158 I can't credit Deepak anyway, as he's not a reviewer, but his suggestions have been incorporated in this latest webrev. -- 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 Apr 9 17:48:39 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 9 Apr 2019 18:48:39 +0100 Subject: Classify JDK-8219890 and JDK-8208656 as critical in JBS In-Reply-To: References: Message-ID: <4457948b-4bf5-c2ee-0148-4ceb00ea04fd@redhat.com> On 09/04/2019 13:43, Langer, Christoph wrote: > Hi Andrew, > > ? > > I can see that the changes for JDK-8219890 [0] and JDK-8208656 [1] have > been pushed to jdk8u-dev and jdk11u-dev in the meanwhile. > > ? > > These are most probably prerequisites of the Japanese era update > JDK-8205432 [2] that comes with the JDK 8u212 and JDK 11.0.3 CPUs. Can > you confirm that? They are. It would be a little easier to answer such questions if you included the summaries so I know which bugs you're referring to. All these numbers are pretty meaningless. > > ? > > Since I strongly believe so, I have added ?jdk11u-critical-request? and > ?jdk8u-critical-request? to both plus a fix request comment that states > its relation to JDK-8205432. > > ? > > I think we should make sure that public fixes which get integrated into > the CPU repositories and will hence get merged on the release day are > flagged as ?critical-yes?. This will bring them up in the relevant JBS > views, e.g. [3] for jdk8u and [4] for jdk11u and downstream providers of > OpenJDK can easily check which public changes will be included on top of > the last public tag and get merged in on the release day. I've assumed jdkx-critical-request to be relevant during the period between branch and freeze. Changes after freeze will be posted, reviewed and approved in bulk (as Oracle did with the full set). It is uncommon for any of these changes to be public. These Japanese changes are unusual in that they had to wait until the era name was announced on 2019-04-01. Most of the changes after freeze are not visible bugs to which I can apply such a label, and, where we can, it may also be confusing to apply the critical label and then push to the -dev tree. They can't be pushed to the main tree because they are preceded by embargoed changes. For downstream providers who are members of the vulnerability group, I have provided an exact list of what is included after the freeze. I think that's clearer than trying to work it out from the bug database, which will inevitably be incomplete. Those who are not members of the group can not know the full set of changes in the final release until the unembargo date. So, in short, I don't have a strong objection to using the tag for these later changes, but they are not going to provide a complete picture of the release. If they did, we would just be pushing the changes directly to the main tree. > > ? > > Thanks & best regards > > Christoph > > ? > > [0] https://bugs.openjdk.java.net/browse/JDK-8219890 > > [1] https://bugs.openjdk.java.net/browse/JDK-8208656 > > [2] https://bugs.openjdk.java.net/browse/JDK-8205432 > > [3] https://bugs.openjdk.java.net/issues/?filter=36562 > > [4] https://bugs.openjdk.java.net/issues/?filter=36558 > -- 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 Wed Apr 10 08:05:48 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 10 Apr 2019 08:05:48 +0000 Subject: Classify JDK-8219890 and JDK-8208656 as critical in JBS In-Reply-To: <4457948b-4bf5-c2ee-0148-4ceb00ea04fd@redhat.com> References: <4457948b-4bf5-c2ee-0148-4ceb00ea04fd@redhat.com> Message-ID: Hi Andrew, > > I can see that the changes for JDK-8219890 [0] and JDK-8208656 [1] have > > been pushed to jdk8u-dev and jdk11u-dev in the meanwhile. > > > > > > > > These are most probably prerequisites of the Japanese era update > > JDK-8205432 [2] that comes with the JDK 8u212 and JDK 11.0.3 CPUs. Can > > you confirm that? > > They are. > > It would be a little easier to answer such questions if you included the > summaries so I know which bugs you're referring to. All these numbers > are pretty meaningless. OK, right, will try to remember next time. ?? > > > > Since I strongly believe so, I have added ?jdk11u-critical-request? and > > ?jdk8u-critical-request? to both plus a fix request comment that states > > its relation to JDK-8205432. > > > > > > > > I think we should make sure that public fixes which get integrated into > > the CPU repositories and will hence get merged on the release day are > > flagged as ?critical-yes?. This will bring them up in the relevant JBS > > views, e.g. [3] for jdk8u and [4] for jdk11u and downstream providers of > > OpenJDK can easily check which public changes will be included on top of > > the last public tag and get merged in on the release day. > > I've assumed jdkx-critical-request to be relevant during the period > between branch and freeze. > > Changes after freeze will be posted, reviewed and approved in bulk (as > Oracle did with the full set). It is uncommon for any of these changes > to be public. These Japanese changes are unusual in that they had to > wait until the era name was announced on 2019-04-01. Most of the changes > after freeze are not visible bugs to which I can apply such a label, > and, where we can, it may also be confusing to apply the critical label > and then push to the -dev tree. They can't be pushed to the main tree > because they are preceded by embargoed changes. > > For downstream providers who are members of the vulnerability group, I > have provided an exact list of what is included after the freeze. I > think that's clearer than trying to work it out from the bug database, > which will inevitably be incomplete. Those who are not members of the > group can not know the full set of changes in the final release until > the unembargo date. > > So, in short, I don't have a strong objection to using the tag for these > later changes, but they are not going to provide a complete picture of > the release. If they did, we would just be pushing the changes directly > to the main tree. I can see your points. That's a bit of a process discussion I guess. ?? So, right, most of the changes after freeze are probably embargoed changes to invisible bugs. However, there will also be some public fixes, e.g. prerequisites to other CPU changes or fixes that we need to pull into a CPU for other reasons, such as the Japanese era. The latter were somewhat special in that they were pushed to jdk8u-dev and jdk11u-dev as well instead of waiting for the merge back from CPU. It's also good that you provide the full list of changes to the vulnerability group, which for sure would be the only way to get a complete picture. However, for the public JBS part I'd like to have some tagging to the visible bugs that go into a CPU. I think the "critical" labels would be a good way to do this. This of course will not mean that a change can/will be pushed to the dev codelines in advance such as the Japanese era stuff. But these tags will give the complete picture when comparing the contents of the OpenJDK community release with the Oracle release. And, the information about public bugs being part of a CPU was always visible for Oracle updates via the JBS backport items. Though you could not see the actual fix obviously. Maybe there's some feedback from other people about this? Thanks Christoph From christoph.langer at sap.com Wed Apr 10 08:39:00 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 10 Apr 2019 08:39:00 +0000 Subject: JDK-8221355 Performance regression after JDK-8155635 backport into 8u not in 8u212 Message-ID: Hi, I want to make you aware of the following: As per the diff filter OpenJDK 8u212 vs. Oracle 8u212 [0], the issue JDK-8221355 "Performance regression after JDK-8155635 backport into 8u" is part of Oracle's update but not in the OpenJDK version. This fix is not available in public but I guess it can be done by an experienced engineer from the issue comments. Best regards Christoph [0] https://bugs.openjdk.java.net/issues/?filter=36394 [1] https://bugs.openjdk.java.net/browse/JDK-8221355 From shade at redhat.com Wed Apr 10 08:48:10 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 10 Apr 2019 10:48:10 +0200 Subject: JDK-8221355 Performance regression after JDK-8155635 backport into 8u not in 8u212 In-Reply-To: References: Message-ID: On 4/10/19 10:39 AM, Langer, Christoph wrote: > As per the diff filter OpenJDK 8u212 vs. Oracle 8u212 [0], the issue JDK-8221355 "Performance > regression after JDK-8155635 backport into 8u" is part of Oracle's update but not in the OpenJDK > version. > > This fix is not available in public but I guess it can be done by an experienced engineer from > the issue comments. I'll take a look (or loop in Roland). Maybe Oracle folks do us a solid one and publish the fix? -Aleksey From shade at redhat.com Wed Apr 10 08:53:34 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 10 Apr 2019 10:53:34 +0200 Subject: JDK-8221355 Performance regression after JDK-8155635 backport into 8u not in 8u212 In-Reply-To: References: Message-ID: <1a33d396-640a-e966-a462-7769053c75c1@redhat.com> On 4/10/19 10:48 AM, Aleksey Shipilev wrote: > On 4/10/19 10:39 AM, Langer, Christoph wrote: >> As per the diff filter OpenJDK 8u212 vs. Oracle 8u212 [0], the issue JDK-8221355 "Performance >> regression after JDK-8155635 backport into 8u" is part of Oracle's update but not in the OpenJDK >> version. >> >> This fix is not available in public but I guess it can be done by an experienced engineer from >> the issue comments. > > I'll take a look (or loop in Roland). Maybe Oracle folks do us a solid one and publish the fix? Forgot to mention: this probably misses ongoing CPU, as the compiler fix there is risky and invalidates lots of testing already done. Unless we collectively think the absence of it is the end of the world. -Aleksey From shade at redhat.com Wed Apr 10 09:19:25 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 10 Apr 2019 11:19:25 +0200 Subject: JDK-8221355 Performance regression after JDK-8155635 backport into 8u not in 8u212 In-Reply-To: <1a33d396-640a-e966-a462-7769053c75c1@redhat.com> References: <1a33d396-640a-e966-a462-7769053c75c1@redhat.com> Message-ID: <3117a26a-fad9-c939-a608-dad0d585372f@redhat.com> On 4/10/19 10:53 AM, Aleksey Shipilev wrote: > On 4/10/19 10:48 AM, Aleksey Shipilev wrote: >> On 4/10/19 10:39 AM, Langer, Christoph wrote: >>> As per the diff filter OpenJDK 8u212 vs. Oracle 8u212 [0], the issue JDK-8221355 "Performance >>> regression after JDK-8155635 backport into 8u" is part of Oracle's update but not in the OpenJDK >>> version. >>> >>> This fix is not available in public but I guess it can be done by an experienced engineer from >>> the issue comments. >> >> I'll take a look (or loop in Roland). Maybe Oracle folks do us a solid one and publish the fix? > > Forgot to mention: this probably misses ongoing CPU, as the compiler fix there is risky and > invalidates lots of testing already done. Unless we collectively think the absence of it is the end > of the world. Severin had successfully reproduced the regression, handing over to him. Plus, we think that the fix in the comment there is the final one: https://bugs.openjdk.java.net/browse/JDK-8221355?focusedCommentId=14255045#comment-14255045 Thanks, -Aleksey From zhaixiang at loongson.cn Wed Apr 10 10:07:51 2019 From: zhaixiang at loongson.cn (Leslie Zhai) Date: Wed, 10 Apr 2019 18:07:51 +0800 Subject: Request for Comments: Backport of JDK-8206955: MethodHandleProxies.asInterfaceInstance does not support default methods Message-ID: Hi, I would like to backport the fix for: https://bugs.openjdk.java.net/browse/JDK-8206955 To OpenJDK 8 updates dev: http://hg.openjdk.java.net/jdk8u/jdk8u-dev The fix is mostly the same as the version that was committed in 12. Webrev: http://cr.openjdk.java.net/~lzhai/8206955-8u/webrev.00/ Please review it and give me some comments. Thanks, Leslie Zhai From sgehwolf at redhat.com Wed Apr 10 11:18:36 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 10 Apr 2019 13:18:36 +0200 Subject: [8u] RFR: 8221355: Performance regression after JDK-8155635 backport into 8u Message-ID: <464fcc0f70569534892d11976a857cd3eb7a9494.camel@redhat.com> Hi, Could I please get a review of this 8u212 performance regression fix? webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8221355/01/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8221355 Before this fix: $ time ./bin/java UnsafeGetObject 1204 ms 1212 ms 1237 ms 1289 ms 1348 ms real 0m6.354s user 0m6.330s sys 0m0.023s After this fix: $ time ./bin/java UnsafeGetObject 54 ms 51 ms 43 ms 45 ms 44 ms real 0m0.302s user 0m0.303s sys 0m0.009s UnsafeGetObject.java is from: https://bugs.openjdk.java.net/browse/JDK-8181822 Testing: Sanity testing with java.{,io,lang,math,net,nio,security,util} tests. Thoughts? Thanks, Severin From sgehwolf at redhat.com Wed Apr 10 11:19:48 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 10 Apr 2019 13:19:48 +0200 Subject: JDK-8221355 Performance regression after JDK-8155635 backport into 8u not in 8u212 In-Reply-To: <3117a26a-fad9-c939-a608-dad0d585372f@redhat.com> References: <1a33d396-640a-e966-a462-7769053c75c1@redhat.com> <3117a26a-fad9-c939-a608-dad0d585372f@redhat.com> Message-ID: <933c5ae1d4c1d84d6eec88e6c16a23654848e73f.camel@redhat.com> On Wed, 2019-04-10 at 11:19 +0200, Aleksey Shipilev wrote: > On 4/10/19 10:53 AM, Aleksey Shipilev wrote: > > On 4/10/19 10:48 AM, Aleksey Shipilev wrote: > > > On 4/10/19 10:39 AM, Langer, Christoph wrote: > > > > As per the diff filter OpenJDK 8u212 vs. Oracle 8u212 [0], the issue JDK-8221355 "Performance > > > > regression after JDK-8155635 backport into 8u" is part of Oracle's update but not in the OpenJDK > > > > version. > > > > > > > > This fix is not available in public but I guess it can be done by an experienced engineer from > > > > the issue comments. > > > > > > I'll take a look (or loop in Roland). Maybe Oracle folks do us a solid one and publish the fix? > > > > Forgot to mention: this probably misses ongoing CPU, as the compiler fix there is risky and > > invalidates lots of testing already done. Unless we collectively think the absence of it is the end > > of the world. > > Severin had successfully reproduced the regression, handing over to him. Plus, we think that the fix > in the comment there is the final one: > https://bugs.openjdk.java.net/browse/JDK-8221355?focusedCommentId=14255045#comment-14255045 RFR is here: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009079.html Thanks, Severin From shade at redhat.com Wed Apr 10 11:25:02 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 10 Apr 2019 13:25:02 +0200 Subject: [8u] RFR: 8221355: Performance regression after JDK-8155635 backport into 8u In-Reply-To: <464fcc0f70569534892d11976a857cd3eb7a9494.camel@redhat.com> References: <464fcc0f70569534892d11976a857cd3eb7a9494.camel@redhat.com> Message-ID: <7f2abab8-0998-8e12-0c33-faa35216b6dc@redhat.com> On 4/10/19 1:18 PM, Severin Gehwolf wrote: > Could I please get a review of this 8u212 performance regression fix? > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8221355/01/webrev/ This is not the same patch that Oracle apparently pushed, or that I tested myself. Compare with: http://cr.openjdk.java.net/~shade/8221355/8221355-01.patch The difference is not critical, but better match? It should definitely be in 8u-dev (next CPU). I'll leave the decision for 8u (current CPU) to 8u maintainers. -Aleksey From sgehwolf at redhat.com Wed Apr 10 12:42:31 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 10 Apr 2019 14:42:31 +0200 Subject: [8u] RFR: 8221355: Performance regression after JDK-8155635 backport into 8u In-Reply-To: <7f2abab8-0998-8e12-0c33-faa35216b6dc@redhat.com> References: <464fcc0f70569534892d11976a857cd3eb7a9494.camel@redhat.com> <7f2abab8-0998-8e12-0c33-faa35216b6dc@redhat.com> Message-ID: <02c9168afbbe33980567a3e3898a3c7f924ad205.camel@redhat.com> Hi Aleksey, Thanks for the review! On Wed, 2019-04-10 at 13:25 +0200, Aleksey Shipilev wrote: > On 4/10/19 1:18 PM, Severin Gehwolf wrote: > > Could I please get a review of this 8u212 performance regression fix? > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8221355/01/webrev/ > > This is not the same patch that Oracle apparently pushed, or that I tested myself. Compare with: > http://cr.openjdk.java.net/~shade/8221355/8221355-01.patch > > The difference is not critical, but better match? Is there a reason to keep unused local variable 'can_access_non_heap' around in JDK 8? It makes sense for the JDK 9 change as its being used further down in the same function: http://hg.openjdk.java.net/jdk-updates/jdk9u/hotspot/file/22d7a88dbe78/src/share/vm/opto/library_call.cpp#l2493 That's not the case for JDK 8u, though. Thoughts? The left over comment is misleading, though, which I've now removed: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8221355/02/webrev/ > It should definitely be in 8u-dev (next CPU). I'll leave the decision for 8u (current CPU) to 8u > maintainers. Yes, I'd be aiming this for 8u-dev for now. Thanks, Severin From shade at redhat.com Wed Apr 10 12:55:29 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 10 Apr 2019 14:55:29 +0200 Subject: [8u] RFR: 8221355: Performance regression after JDK-8155635 backport into 8u In-Reply-To: <02c9168afbbe33980567a3e3898a3c7f924ad205.camel@redhat.com> References: <464fcc0f70569534892d11976a857cd3eb7a9494.camel@redhat.com> <7f2abab8-0998-8e12-0c33-faa35216b6dc@redhat.com> <02c9168afbbe33980567a3e3898a3c7f924ad205.camel@redhat.com> Message-ID: On 4/10/19 2:42 PM, Severin Gehwolf wrote: > Is there a reason to keep unused local variable 'can_access_non_heap' > around in JDK 8? It makes sense for the JDK 9 change as its being used > further down in the same function: > http://hg.openjdk.java.net/jdk-updates/jdk9u/hotspot/file/22d7a88dbe78/src/share/vm/opto/library_call.cpp#l2493 > > That's not the case for JDK 8u, though. Thoughts? Right. I don't think there is a reason to keep the can_access_non_heap. > The left over comment is misleading, though, which I've now removed: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8221355/02/webrev/ ...but now I am confused how that patch is supposed to work. It seems to me it accepts the accesses to off-heap when object passed it is actually null, but not transparently-null for the compiler? That is probably acceptable, but maybe someone savvy in this code can take a look? Vladimir I, Roland? -- Thanks, -Aleksey From rwestrel at redhat.com Wed Apr 10 13:16:41 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 10 Apr 2019 15:16:41 +0200 Subject: [8u] RFR: 8221355: Performance regression after JDK-8155635 backport into 8u In-Reply-To: References: <464fcc0f70569534892d11976a857cd3eb7a9494.camel@redhat.com> <7f2abab8-0998-8e12-0c33-faa35216b6dc@redhat.com> <02c9168afbbe33980567a3e3898a3c7f924ad205.camel@redhat.com> Message-ID: <87r2aaov9i.fsf@redhat.com> >> The left over comment is misleading, though, which I've now removed: >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8221355/02/webrev/ > > ...but now I am confused how that patch is supposed to work. It seems to me it accepts the accesses > to off-heap when object passed it is actually null, but not transparently-null for the compiler? > That is probably acceptable, but maybe someone savvy in this code can take a look? Vladimir I, Roland? When base is known to be null, this patch causes c2 to not intrinsify object accesses and the native method is called. Without this patch, c2 doesn't intrinsify object accesses unless it knows base to be not null which is indeed too conservative. That looks good to me. Roland. From hohensee at amazon.com Wed Apr 10 13:27:54 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 10 Apr 2019 13:27:54 +0000 Subject: [8u] 8205432: Replace the placeholder Japanese era name In-Reply-To: References: <12F0D3AE-3F14-492E-8CD1-1611D70262D2@amazon.com> <22BEE3A9-5368-4538-AC0C-4C90E9B42B3B@amazon.com> Message-ID: Thanks, Andrew. :) ?On 4/9/19, 10:27 AM, "Andrew John Hughes" wrote: On 09/04/2019 18:18, Hohensee, Paul wrote: > I meant the current webrev > > https://cr.openjdk.java.net/~andrew/openjdk8/8205432/webrev.02/ > > is fine. Just backport what's in tip and fix whatever's wrong later as another backport or backports. > > Paul Thanks. I've pushed based on the review of yourself & aph: https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/ee55428fe158 I can't credit Deepak anyway, as he's not a reviewer, but his suggestions have been incorporated in this latest webrev. -- 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 Apr 10 15:26:50 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 10 Apr 2019 16:26:50 +0100 Subject: [8u] RFR: 8221355: Performance regression after JDK-8155635 backport into 8u In-Reply-To: <7f2abab8-0998-8e12-0c33-faa35216b6dc@redhat.com> References: <464fcc0f70569534892d11976a857cd3eb7a9494.camel@redhat.com> <7f2abab8-0998-8e12-0c33-faa35216b6dc@redhat.com> Message-ID: On 10/04/2019 12:25, Aleksey Shipilev wrote: > On 4/10/19 1:18 PM, Severin Gehwolf wrote: >> Could I please get a review of this 8u212 performance regression fix? >> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8221355/01/webrev/ > > This is not the same patch that Oracle apparently pushed, or that I tested myself. Compare with: > http://cr.openjdk.java.net/~shade/8221355/8221355-01.patch > > The difference is not critical, but better match? > > It should definitely be in 8u-dev (next CPU). I'll leave the decision for 8u (current CPU) to 8u > maintainers. > > -Aleksey > I think it should be 8u212 to avoid a performance regression between OpenJDK 8u212 and Oracle's 8u212. Once Severin has pushed his patch, I'll pull that into my local version of jdk8u and the result will be tagged jdk8u212-b04. -- 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 Wed Apr 10 15:32:29 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 10 Apr 2019 17:32:29 +0200 Subject: [8u] RFR: 8221355: Performance regression after JDK-8155635 backport into 8u In-Reply-To: <87r2aaov9i.fsf@redhat.com> References: <464fcc0f70569534892d11976a857cd3eb7a9494.camel@redhat.com> <7f2abab8-0998-8e12-0c33-faa35216b6dc@redhat.com> <02c9168afbbe33980567a3e3898a3c7f924ad205.camel@redhat.com> <87r2aaov9i.fsf@redhat.com> Message-ID: On Wed, 2019-04-10 at 15:16 +0200, Roland Westrelin wrote: > > > The left over comment is misleading, though, which I've now removed: > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8221355/02/webrev/ > > > > ...but now I am confused how that patch is supposed to work. It seems to me it accepts the accesses > > to off-heap when object passed it is actually null, but not transparently-null for the compiler? > > That is probably acceptable, but maybe someone savvy in this code can take a look? Vladimir I, Roland? > > When base is known to be null, this patch causes c2 to not intrinsify > object accesses and the native method is called. Without this patch, c2 > doesn't intrinsify object accesses unless it knows base to be not null > which is indeed too conservative. > > That looks good to me. Thanks for the review! Cheers, Severin From gnu.andrew at redhat.com Wed Apr 10 15:32:54 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 10 Apr 2019 16:32:54 +0100 Subject: Classify JDK-8219890 and JDK-8208656 as critical in JBS In-Reply-To: References: <4457948b-4bf5-c2ee-0148-4ceb00ea04fd@redhat.com> Message-ID: On 10/04/2019 09:05, Langer, Christoph wrote: snip... > > However, for the public JBS part I'd like to have some tagging to the visible bugs that go into a CPU. I think the "critical" labels would be a good way to do this. This of course will not mean that a change can/will be pushed to the dev codelines in advance such as the Japanese era stuff. But these tags will give the complete picture when comparing the contents of the OpenJDK community release with the Oracle release. As I say, I have no real issue with this either way. And, the information about public bugs being part of a CPU was always visible for Oracle updates via the JBS backport items. Though you could not see the actual fix obviously. Yeah, you're not going to have that in this case as I can't push to jdk8u without rebasing the entire CPU (the CPU patches appear before the Japanese fixes & the imminent performance regression fix) > > Maybe there's some feedback from other people about this? > > Thanks > Christoph > -- 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 Wed Apr 10 15:50:57 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 10 Apr 2019 17:50:57 +0200 Subject: [8u] RFR: 8221355: Performance regression after JDK-8155635 backport into 8u In-Reply-To: References: <464fcc0f70569534892d11976a857cd3eb7a9494.camel@redhat.com> <7f2abab8-0998-8e12-0c33-faa35216b6dc@redhat.com> Message-ID: <841cb14a37079b216ba3c64bea17e6f47a76d54d.camel@redhat.com> On Wed, 2019-04-10 at 16:26 +0100, Andrew John Hughes wrote: > > On 10/04/2019 12:25, Aleksey Shipilev wrote: > > On 4/10/19 1:18 PM, Severin Gehwolf wrote: > > > Could I please get a review of this 8u212 performance regression fix? > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8221355/01/webrev/ > > > > This is not the same patch that Oracle apparently pushed, or that I tested myself. Compare with: > > http://cr.openjdk.java.net/~shade/8221355/8221355-01.patch > > > > The difference is not critical, but better match? > > > > It should definitely be in 8u-dev (next CPU). I'll leave the decision for 8u (current CPU) to 8u > > maintainers. > > > > -Aleksey > > > > I think it should be 8u212 to avoid a performance regression between > OpenJDK 8u212 and Oracle's 8u212. > > Once Severin has pushed his patch, I'll pull that into my local version > of jdk8u and the result will be tagged jdk8u212-b04. Pushed: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/0cbfe6c38b2e Thanks, Severin From xxinliu at amazon.com Wed Apr 10 18:13:50 2019 From: xxinliu at amazon.com (Liu, Xin) Date: Wed, 10 Apr 2019 18:13:50 +0000 Subject: Gcc 4.4.6 has been broken to build jdk8u-dev Message-ID: This line doesn?t look like other for-loops. https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/ee55428fe158/src/solaris/native/sun/awt/multiVis.c#l405 gcc 4.4.6 has trouble to deal with it. /src/jdk/src/solaris/native/sun/awt/multiVis.c: In function 'ReadRegionsInList': /src/jdk/src/solaris/native/sun/awt/multiVis.c:405: error: 'for' loop initial declarations are only allowed in C99 mode /src/jdk/src/solaris/native/sun/awt/multiVis.c:405: note: use option -std=c99 or -std=gnu99 to compile your code /src/jdk/src/solaris/native/sun/awt/multiVis.c:409: error: 'for' loop initial declarations are only allowed in C99 mode gmake[2]: *** [/build/jdk/objs/libawt_xawt/multiVis.o] Error 1 Shall we drop gcc 4.4.6 support or just update it? Thanks, --lx From hohensee at amazon.com Wed Apr 10 18:19:52 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 10 Apr 2019 18:19:52 +0000 Subject: Gcc 4.4.6 has been broken to build jdk8u-dev In-Reply-To: References: Message-ID: There's a JBS issue for this, https://bugs.openjdk.java.net/browse/JDK-8197546 , which needs to be backported. The issue is already marked jdk8u-fix-yes. I'll push it. Paul ?On 4/10/19, 11:16 AM, "jdk8u-dev on behalf of Liu, Xin" wrote: This line doesn?t look like other for-loops. https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/ee55428fe158/src/solaris/native/sun/awt/multiVis.c#l405 gcc 4.4.6 has trouble to deal with it. /src/jdk/src/solaris/native/sun/awt/multiVis.c: In function 'ReadRegionsInList': /src/jdk/src/solaris/native/sun/awt/multiVis.c:405: error: 'for' loop initial declarations are only allowed in C99 mode /src/jdk/src/solaris/native/sun/awt/multiVis.c:405: note: use option -std=c99 or -std=gnu99 to compile your code /src/jdk/src/solaris/native/sun/awt/multiVis.c:409: error: 'for' loop initial declarations are only allowed in C99 mode gmake[2]: *** [/build/jdk/objs/libawt_xawt/multiVis.o] Error 1 Shall we drop gcc 4.4.6 support or just update it? Thanks, --lx From gil at azul.com Wed Apr 10 19:29:35 2019 From: gil at azul.com (Gil Tene) Date: Wed, 10 Apr 2019 19:29:35 +0000 Subject: [8u] RFR: 8221355: Performance regression after JDK-8155635 backport into 8u In-Reply-To: References: <464fcc0f70569534892d11976a857cd3eb7a9494.camel@redhat.com> <7f2abab8-0998-8e12-0c33-faa35216b6dc@redhat.com> Message-ID: Before we jump ahead and integrate this into the upcoming April 8u212, and bump the build number from b03 to b04, I'd like to point out that the Oracle backport (https://bugs.openjdk.java.net/browse/JDK-8221954) appears to be to their 8u212 b31, which is likely a BPR, and not the initial version of 8u212 that will be out in a week. So the premise that not including this in the initial version of OpenJDK 8u212 will lead to a performance regression compared Oracle's 8u212 is not quite right. The difference will happen when oracle publishes their 8u212-b31. Given the time crunch, the risk, and the fact that Oracle's April 16 update will likely NOT include this fix to the regression initially introduced in 8u202, I would advocate to still build a 8u212-b03, which would not include this back-port, and to either do a b04 later, or push this to July. ? Gil. > On Apr 10, 2019, at 8:26 AM, Andrew John Hughes wrote: > > > > On 10/04/2019 12:25, Aleksey Shipilev wrote: >> On 4/10/19 1:18 PM, Severin Gehwolf wrote: >>> Could I please get a review of this 8u212 performance regression fix? >>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8221355/01/webrev/ >> >> This is not the same patch that Oracle apparently pushed, or that I tested myself. Compare with: >> http://cr.openjdk.java.net/~shade/8221355/8221355-01.patch >> >> The difference is not critical, but better match? >> >> It should definitely be in 8u-dev (next CPU). I'll leave the decision for 8u (current CPU) to 8u >> maintainers. >> >> -Aleksey >> > > > I think it should be 8u212 to avoid a performance regression between > OpenJDK 8u212 and Oracle's 8u212. > > Once Severin has pushed his patch, I'll pull that into my local version > of jdk8u and the result will be tagged jdk8u212-b04. > -- > 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 Apr 10 19:30:57 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 10 Apr 2019 19:30:57 +0000 Subject: Gcc 4.4.6 has been broken to build jdk8u-dev In-Reply-To: References: Message-ID: <722D9A20-0805-4BBB-87B5-1362BA2718A6@amazon.com> Pushed. ?On 4/10/19, 11:20 AM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: There's a JBS issue for this, https://bugs.openjdk.java.net/browse/JDK-8197546 , which needs to be backported. The issue is already marked jdk8u-fix-yes. I'll push it. Paul On 4/10/19, 11:16 AM, "jdk8u-dev on behalf of Liu, Xin" wrote: This line doesn?t look like other for-loops. https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/ee55428fe158/src/solaris/native/sun/awt/multiVis.c#l405 gcc 4.4.6 has trouble to deal with it. /src/jdk/src/solaris/native/sun/awt/multiVis.c: In function 'ReadRegionsInList': /src/jdk/src/solaris/native/sun/awt/multiVis.c:405: error: 'for' loop initial declarations are only allowed in C99 mode /src/jdk/src/solaris/native/sun/awt/multiVis.c:405: note: use option -std=c99 or -std=gnu99 to compile your code /src/jdk/src/solaris/native/sun/awt/multiVis.c:409: error: 'for' loop initial declarations are only allowed in C99 mode gmake[2]: *** [/build/jdk/objs/libawt_xawt/multiVis.o] Error 1 Shall we drop gcc 4.4.6 support or just update it? Thanks, --lx From xxinliu at amazon.com Wed Apr 10 20:50:09 2019 From: xxinliu at amazon.com (Liu, Xin) Date: Wed, 10 Apr 2019 20:50:09 +0000 Subject: Gcc 4.4.6 has been broken to build jdk8u-dev In-Reply-To: References: Message-ID: <4EC1F0C4-C7A4-4EE4-A6CD-AD96F4BECBD2@amazon.com> A fix has been Pushed. https://bugs.openjdk.java.net/browse/JDK-8222291 I can confirm that the nightly build has resumed. Thanks, --lx ?On 4/10/19, 11:16 AM, "jdk8u-dev on behalf of Liu, Xin" wrote: This line doesn?t look like other for-loops. https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/ee55428fe158/src/solaris/native/sun/awt/multiVis.c#l405 gcc 4.4.6 has trouble to deal with it. /src/jdk/src/solaris/native/sun/awt/multiVis.c: In function 'ReadRegionsInList': /src/jdk/src/solaris/native/sun/awt/multiVis.c:405: error: 'for' loop initial declarations are only allowed in C99 mode /src/jdk/src/solaris/native/sun/awt/multiVis.c:405: note: use option -std=c99 or -std=gnu99 to compile your code /src/jdk/src/solaris/native/sun/awt/multiVis.c:409: error: 'for' loop initial declarations are only allowed in C99 mode gmake[2]: *** [/build/jdk/objs/libawt_xawt/multiVis.o] Error 1 Shall we drop gcc 4.4.6 support or just update it? Thanks, --lx From hohensee at amazon.com Thu Apr 11 21:37:55 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 11 Apr 2019 21:37:55 +0000 Subject: [8u-dev] RFR+RFA (M): JDK-8176100: [REDO][REDO] G1 Needs pre barrier on dereference of weak JNI handles Message-ID: <8A7A3619-56E2-4E19-A1E0-BA47CBB5BAE4@amazon.com> 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 From zhaixiang at loongson.cn Fri Apr 12 02:56:13 2019 From: zhaixiang at loongson.cn (Leslie Zhai) Date: Fri, 12 Apr 2019 10:56:13 +0800 Subject: Request for Comments: Backport of JDK-8206955: MethodHandleProxies.asInterfaceInstance does not support default methods In-Reply-To: References: Message-ID: <17a40cd9-6a38-25b8-23df-20cd243531d7@loongson.cn> Hi Andrew, I fixed the similar issue as JDK-8203699 for jdk-mips, and I need to backport the fix for jdk-mips to jdk8-mips, because JDK-8203699 is also reproducible after backport the fix for JDK-8206955 to jdk8-mips. ? 2019?04?10? 18:07, Leslie Zhai ??: > Hi, > > I would like to backport the fix for: Could I backport the fix? Thanks, Leslie Zhai > > > https://bugs.openjdk.java.net/browse/JDK-8206955 > > To OpenJDK 8 updates dev: > > http://hg.openjdk.java.net/jdk8u/jdk8u-dev > > The fix is mostly the same as the version that was committed in 12. > > Webrev: http://cr.openjdk.java.net/~lzhai/8206955-8u/webrev.00/ > > Please review it and give me some comments. > > Thanks, > > Leslie Zhai > > From gil at azul.com Fri Apr 12 06:11:56 2019 From: gil at azul.com (Gil Tene) Date: Fri, 12 Apr 2019 06:11:56 +0000 Subject: [8u] RFR: 8221355: Performance regression after JDK-8155635 backport into 8u In-Reply-To: References: <464fcc0f70569534892d11976a857cd3eb7a9494.camel@redhat.com> <7f2abab8-0998-8e12-0c33-faa35216b6dc@redhat.com> Message-ID: <1C5E25A9-E464-4F95-B60F-236C45B52CBF@azul.com> Since there is a time crunch on this, and no new update has been posted in the thread in the past ~35 hours in response to the below, we will proceed with the assumption that the plan in the e-mail from Andrew Hughes below (to include the pushed patch in an expected final 8u212-b04) is going forward. Lets not change from that at this late point. In future cycles, I think that we probably need a bit more time for review and input before making such a call so close to the final release. We went from first identification (https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009074.html ) to decision (https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009086.html) in under 7 hours, which occurred between 1:39AM and 8:26AM Pacific time. ? Gil. > On Apr 10, 2019, at 12:29 PM, Gil Tene wrote: > > Before we jump ahead and integrate this into the upcoming April 8u212, and bump the > build number from b03 to b04, I'd like to point out that the Oracle backport > (https://bugs.openjdk.java.net/browse/JDK-8221954) appears to be to their 8u212 b31, > which is likely a BPR, and not the initial version of 8u212 that will be out in a week. > > So the premise that not including this in the initial version of OpenJDK 8u212 will lead to a > performance regression compared Oracle's 8u212 is not quite right. The difference will > happen when oracle publishes their 8u212-b31. > > Given the time crunch, the risk, and the fact that Oracle's April 16 update will likely NOT > include this fix to the regression initially introduced in 8u202, I would advocate to still build > a 8u212-b03, which would not include this back-port, and to either do a b04 later, or push > this to July. > > ? Gil. > >> On Apr 10, 2019, at 8:26 AM, Andrew John Hughes wrote: >> >> >> >> On 10/04/2019 12:25, Aleksey Shipilev wrote: >>> On 4/10/19 1:18 PM, Severin Gehwolf wrote: >>>> Could I please get a review of this 8u212 performance regression fix? >>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8221355/01/webrev/ >>> >>> This is not the same patch that Oracle apparently pushed, or that I tested myself. Compare with: >>> http://cr.openjdk.java.net/~shade/8221355/8221355-01.patch >>> >>> The difference is not critical, but better match? >>> >>> It should definitely be in 8u-dev (next CPU). I'll leave the decision for 8u (current CPU) to 8u >>> maintainers. >>> >>> -Aleksey >>> >> >> >> I think it should be 8u212 to avoid a performance regression between >> OpenJDK 8u212 and Oracle's 8u212. >> >> Once Severin has pushed his patch, I'll pull that into my local version >> of jdk8u and the result will be tagged jdk8u212-b04. >> -- >> 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 Apr 12 07:38:23 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 12 Apr 2019 08:38:23 +0100 Subject: [8u] RFR: 8221355: Performance regression after JDK-8155635 backport into 8u In-Reply-To: <1C5E25A9-E464-4F95-B60F-236C45B52CBF@azul.com> References: <464fcc0f70569534892d11976a857cd3eb7a9494.camel@redhat.com> <7f2abab8-0998-8e12-0c33-faa35216b6dc@redhat.com> <1C5E25A9-E464-4F95-B60F-236C45B52CBF@azul.com> Message-ID: <97d7c7cf-8b80-7825-ba73-51d6633b22eb@redhat.com> On 4/12/19 7:11 AM, Gil Tene wrote: > Since there is a time crunch on this, and no new update has been > posted in the thread in the past ~35 hours in response to the below, > we will proceed with the assumption that the plan in the e-mail from > Andrew Hughes below (to include the pushed patch in an expected > final 8u212-b04) is going forward. Lets not change from that at this > late point. > > In future cycles, I think that we probably need a bit more time for > review and input before making such a call so close to the final > release. We went from first identification > (https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009074.html > ) to decision > (https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009086.html) > in under 7 hours, which occurred between 1:39AM and 8:26AM Pacific > time. We're not always the masters of our destiny. We got notice of this regression very late in the cycle and I had to make a judgment call. There was time to apply the backport, just, and it was better to get it in than spend time discussing whether we should; there is a lot of latency on this list and such a discussion would surely have led to failure. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gil at azul.com Fri Apr 12 11:23:23 2019 From: gil at azul.com (Gil Tene) Date: Fri, 12 Apr 2019 11:23:23 +0000 Subject: [8u] RFR: 8221355: Performance regression after JDK-8155635 backport into 8u In-Reply-To: <97d7c7cf-8b80-7825-ba73-51d6633b22eb@redhat.com> References: <464fcc0f70569534892d11976a857cd3eb7a9494.camel@redhat.com> <7f2abab8-0998-8e12-0c33-faa35216b6dc@redhat.com> <1C5E25A9-E464-4F95-B60F-236C45B52CBF@azul.com>, <97d7c7cf-8b80-7825-ba73-51d6633b22eb@redhat.com> Message-ID: <9F5E36A0-BEED-40B3-AE70-9693FC7E5C82@azul.com> > On Apr 12, 2019, at 12:38 AM, Andrew Haley wrote: > >> On 4/12/19 7:11 AM, Gil Tene wrote: >> >> Since there is a time crunch on this, and no new update has been >> posted in the thread in the past ~35 hours in response to the below, >> we will proceed with the assumption that the plan in the e-mail from >> Andrew Hughes below (to include the pushed patch in an expected >> final 8u212-b04) is going forward. Lets not change from that at this >> late point. >> >> In future cycles, I think that we probably need a bit more time for >> review and input before making such a call so close to the final >> release. We went from first identification >> (https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009074.html >> ) to decision >> (https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009086.html) >> in under 7 hours, which occurred between 1:39AM and 8:26AM Pacific >> time. > > We're not always the masters of our destiny. We got notice of this > regression very late in the cycle and I had to make a judgment > call. There was time to apply the backport, just, and it was better to > get it in than spend time discussing whether we should; there is a lot > of latency on this list and such a discussion would surely have led to > failure. You are the project lead (which I am happy for) and the decision is yours. As I note above, I do not wish to have it changed at this point. I also fully recognize that judgement calls need to be made, and that not all will be perfect. We stick with them and move on. My note above (and below) is seeking to improve similar situations In future cycles, and not as a critique or challenge to the decision already made. A couple of things to note that may help us potentially do better next time: 1. The choice itself was driven by wanting to ?avoid a performance regression between OpenJDK 8u212 and Oracle's 8u212?. At least that?s what the open discussion here shows. I believe that the informational basis motivating the choice was a bit off (see my previous email on the thread), and that we would have ended up with a different choice if we had more eyes looking at It, or more time to dig and notice that Oracle is (likely) not Including the same patch until a later BPR. (Again, not looking to change it now, but looking to keep the situation in mind next time we are up against a similar last minute decision) Potential improvement for future cycles: Both more time (let 24 hours pass so all time zones are in) and a hard line, e.g. 7 days before the release, where ?nothing more goes in unless it?s a newly discovered regression introduced by changes made since the last release?, would separately help avoid at least some of these crunch-time choices. [in this case either mechanism would likely have ended up with you making a different choice, as we would have either discovered the additional detail of the BPR, or determined that this is not a regression introduced by changes made since the last release] 2. Once I replied on the thread (within 4 hours) , the choice itself was in ?limbo? (at least for us), with 6 days before the anticipated release. I ended up proactively ?backing off? of the subject purely for timing reasons (after 1.5 days) in order to get out of the this ?limbo? state. Had this been one week earlier, the discussion would likely have continued with a potentially different outcome. Potential improvement for future cycles: Declaring some line (e.g. 5 day or 7 days before release) where subsequent not-yet-visible patch inclusion decisions become final upon declaring them would be useful in the future, so that we can avoid some limbo situations so close to the line. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From hohensee at amazon.com Fri Apr 12 14:35:05 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 12 Apr 2019 14:35:05 +0000 Subject: Request for Comments: Backport of JDK-8206955: MethodHandleProxies.asInterfaceInstance does not support default methods In-Reply-To: <17a40cd9-6a38-25b8-23df-20cd243531d7@loongson.cn> References: <17a40cd9-6a38-25b8-23df-20cd243531d7@loongson.cn> Message-ID: <40B6AD7C-33F7-4BF9-91ED-13563C0D413B@amazon.com> This looks fine, except for a nit: In MethodHandleProxies.java, add a blank line after " import java.util.concurrent.ConcurrentHashMap;" as in the original patch. I see you're not a jdk8u committer, so if you like I'll sponsor and push the patch (with the extra blank line :)). I've added a jdk8u fix request to JDK-8206955. This patch should also be backported to jdk11u. No need for an email for patches such as this that apply cleanly. You should be able to just tag JDK-8206955 with jdk11u-fix-request. I'll sponsor/push that too if you like. Thanks, Paul ?On 4/11/19, 7:57 PM, "jdk8u-dev on behalf of Leslie Zhai" wrote: Hi Andrew, I fixed the similar issue as JDK-8203699 for jdk-mips, and I need to backport the fix for jdk-mips to jdk8-mips, because JDK-8203699 is also reproducible after backport the fix for JDK-8206955 to jdk8-mips. ? 2019?04?10? 18:07, Leslie Zhai ??: > Hi, > > I would like to backport the fix for: Could I backport the fix? Thanks, Leslie Zhai > > > https://bugs.openjdk.java.net/browse/JDK-8206955 > > To OpenJDK 8 updates dev: > > http://hg.openjdk.java.net/jdk8u/jdk8u-dev > > The fix is mostly the same as the version that was committed in 12. > > Webrev: http://cr.openjdk.java.net/~lzhai/8206955-8u/webrev.00/ > > Please review it and give me some comments. > > Thanks, > > Leslie Zhai > > From gnu.andrew at redhat.com Fri Apr 12 16:40:30 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 12 Apr 2019 17:40:30 +0100 Subject: Gcc 4.4.6 has been broken to build jdk8u-dev In-Reply-To: References: Message-ID: On 10/04/2019 19:19, Hohensee, Paul wrote: > There's a JBS issue for this, https://bugs.openjdk.java.net/browse/JDK-8197546 , which needs to be backported. The issue is already marked jdk8u-fix-yes. I'll push it. > > Paul > Thanks. I meant to do this after the Japanese fixes, but got caught up with the CPU. -- 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 Apr 12 17:01:36 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 12 Apr 2019 18:01:36 +0100 Subject: [8u] RFR: 8221355: Performance regression after JDK-8155635 backport into 8u In-Reply-To: References: <464fcc0f70569534892d11976a857cd3eb7a9494.camel@redhat.com> <7f2abab8-0998-8e12-0c33-faa35216b6dc@redhat.com> Message-ID: On 10/04/2019 20:29, Gil Tene wrote: > Before we jump ahead and integrate this into the upcoming April 8u212, and bump the > build number from b03 to b04, I'd like to point out that the Oracle backport > (https://bugs.openjdk.java.net/browse/JDK-8221954) appears to be to their 8u212 b31, > which is likely a BPR, and not the initial version of 8u212 that will be out in a week. > > So the premise that not including this in the initial version of OpenJDK 8u212 will lead to a > performance regression compared Oracle's 8u212 is not quite right. The difference will > happen when oracle publishes their 8u212-b31. > > Given the time crunch, the risk, and the fact that Oracle's April 16 update will likely NOT > include this fix to the regression initially introduced in 8u202, I would advocate to still build > a 8u212-b03, which would not include this back-port, and to either do a b04 later, or push > this to July. > > ? Gil. > We'll be pushing up to jdk8u212-b04 on Tuesday. OpenJDK builds are being created for each build, but b04 may have to be released shortly after the unembargo. Others producing builds ahead of time are free to make their own call on this. If you don't have time to build & test b04, there is no issue with building b03 as that contains all the security updates. I don't see how that's any different to Oracle's situation, where they have clearly tagged a build of 8u212 with this fix in it, but, judging by the build number, it may not be available on Tuesday. We can always, of course, make the decision to point jdk8u212-ga at jdk8u212-b03. Again, there's precedent for that in the OpenJDK codebase from Oracle's tenure. -- 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 Apr 12 17:13:24 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 12 Apr 2019 17:13:24 +0000 Subject: Gcc 4.4.6 has been broken to build jdk8u-dev In-Reply-To: References: Message-ID: <4CD193D9-E959-4BF9-AD95-45F1CB9B5751@amazon.com> No problem. :) ?On 4/12/19, 9:43 AM, "jdk8u-dev on behalf of Andrew John Hughes" wrote: On 10/04/2019 19:19, Hohensee, Paul wrote: > There's a JBS issue for this, https://bugs.openjdk.java.net/browse/JDK-8197546 , which needs to be backported. The issue is already marked jdk8u-fix-yes. I'll push it. > > Paul > Thanks. I meant to do this after the Japanese fixes, but got caught up with the CPU. -- 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 zhaixiang at loongson.cn Sat Apr 13 01:51:41 2019 From: zhaixiang at loongson.cn (Leslie Zhai) Date: Sat, 13 Apr 2019 09:51:41 +0800 Subject: Request for Comments: Backport of JDK-8206955: MethodHandleProxies.asInterfaceInstance does not support default methods In-Reply-To: <40B6AD7C-33F7-4BF9-91ED-13563C0D413B@amazon.com> References: <17a40cd9-6a38-25b8-23df-20cd243531d7@loongson.cn> <40B6AD7C-33F7-4BF9-91ED-13563C0D413B@amazon.com> Message-ID: <90fc83e2-f656-49ff-d198-610f5bc905b5@loongson.cn> Hi Paul, Thanks for your kind response! ? 2019?04?12? 22:35, Hohensee, Paul ??: > This looks fine, except for a nit: > > In MethodHandleProxies.java, add a blank line after " import java.util.concurrent.ConcurrentHashMap;" as in the original patch. Thanks for your review! Updated: http://cr.openjdk.java.net/~lzhai/8206955-8u/webrev.01/ > > I see you're not a jdk8u committer, so if you like I'll sponsor and push the patch (with the extra blank line :)). I've added a jdk8u fix request to JDK-8206955. Thanks for your sponsor! > > This patch should also be backported to jdk11u. No need for an email for patches such as this that apply cleanly. You should be able to just tag JDK-8206955 with jdk11u-fix-request. I'll sponsor/push that too if you like. Taged :) Thanks, Leslie Zhai > > Thanks, > > Paul > > ?On 4/11/19, 7:57 PM, "jdk8u-dev on behalf of Leslie Zhai" wrote: > > Hi Andrew, > > I fixed the similar issue as JDK-8203699 for jdk-mips, and I need to > backport the fix for jdk-mips to jdk8-mips, because JDK-8203699 is also > reproducible after backport the fix for JDK-8206955 to jdk8-mips. > > ? 2019?04?10? 18:07, Leslie Zhai ??: > > Hi, > > > > I would like to backport the fix for: > > Could I backport the fix? > > Thanks, > Leslie Zhai > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8206955 > > > > To OpenJDK 8 updates dev: > > > > http://hg.openjdk.java.net/jdk8u/jdk8u-dev > > > > The fix is mostly the same as the version that was committed in 12. > > > > Webrev: http://cr.openjdk.java.net/~lzhai/8206955-8u/webrev.00/ > > > > Please review it and give me some comments. > > > > Thanks, > > > > Leslie Zhai > > > > > > > > From aph at redhat.com Mon Apr 15 10:25:09 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 15 Apr 2019 11:25:09 +0100 Subject: OpenJDK Updates Project Builds Message-ID: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> In the past Oracle provided builds of OpenJDK updates. Now that we're maintaining JDK updates outside Oracle, these are missing. There are many organizations producing OpenJDK builds, Red Hat included, all with subtle variations. As project lead, I believe that our users need pure "vanilla" binaries, fully TCK'd, equivalent to those Oracle builds, for reference and for production use. With the co-operation of AdoptOpenJDK, we now have early access preview Linux and Windows binaries (currently x86-64 only) at https://adoptopenjdk.net/upstream.html These are (for now) built and tested at Red Hat, and signed by me as Update project lead. I thank Red Hat for the use of its build and test infrastructure, Severin Gehwolf in particular, and AdoptOpenJDK for their help. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From martijnverburg at gmail.com Mon Apr 15 11:32:55 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 15 Apr 2019 12:32:55 +0100 Subject: OpenJDK Updates Project Builds In-Reply-To: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> Message-ID: Hi all, We'll also link to these builds from Adopt's home page starting from today/tomorrow. It should give the extra eyes it deserves for those looking for the unbranded / untouched builds. Cheers, Martijn On Mon, 15 Apr 2019 at 11:25, Andrew Haley wrote: > In the past Oracle provided builds of OpenJDK updates. Now that we're > maintaining JDK updates outside Oracle, these are missing. > > There are many organizations producing OpenJDK builds, Red Hat > included, all with subtle variations. As project lead, I believe that > our users need pure "vanilla" binaries, fully TCK'd, equivalent to > those Oracle builds, for reference and for production use. > > With the co-operation of AdoptOpenJDK, we now have early access > preview Linux and Windows binaries (currently x86-64 only) at > > https://adoptopenjdk.net/upstream.html > > These are (for now) built and tested at Red Hat, and signed by me as > Update project lead. I thank Red Hat for the use of its build and test > infrastructure, Severin Gehwolf in particular, and AdoptOpenJDK for > their help. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From yamadamn at gmail.com Mon Apr 15 13:34:00 2019 From: yamadamn at gmail.com (Takahiro YAMADA) Date: Mon, 15 Apr 2019 22:34:00 +0900 Subject: OpenJDK Updates Project Builds In-Reply-To: References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> Message-ID: Hi Andrew and Martin, Thank you for all your cooperation. I have waited for these early access builds for LTS release. But I'm afraid that the build number is old for now. e.g. JDK-8221798[1] is resolved in 8u212-b10, but I can download 8u212-b02 from the site[2]. I hope this will improve in the future. Maybe 8u212 from Oracle will release April 16 in GMT. I concern that the build might be different from your builds. Do you have any idea? [1] https://bugs.openjdk.java.net/browse/JDK-8221798 [2] https://adoptopenjdk.net/upstream.html Regards, Takahiro YAMADA 2019?4?15?(?) 20:34 Martijn Verburg : > Hi all, > > We'll also link to these builds from Adopt's home page starting from > today/tomorrow. It should give the extra eyes it deserves for those > looking for the unbranded / untouched builds. > > Cheers, > Martijn > > > On Mon, 15 Apr 2019 at 11:25, Andrew Haley wrote: > > > In the past Oracle provided builds of OpenJDK updates. Now that we're > > maintaining JDK updates outside Oracle, these are missing. > > > > There are many organizations producing OpenJDK builds, Red Hat > > included, all with subtle variations. As project lead, I believe that > > our users need pure "vanilla" binaries, fully TCK'd, equivalent to > > those Oracle builds, for reference and for production use. > > > > With the co-operation of AdoptOpenJDK, we now have early access > > preview Linux and Windows binaries (currently x86-64 only) at > > > > https://adoptopenjdk.net/upstream.html > > > > These are (for now) built and tested at Red Hat, and signed by me as > > Update project lead. I thank Red Hat for the use of its build and test > > infrastructure, Severin Gehwolf in particular, and AdoptOpenJDK for > > their help. > > > > -- > > Andrew Haley > > Java Platform Lead Engineer > > Red Hat UK Ltd. > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > > From sgehwolf at redhat.com Mon Apr 15 14:19:39 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 15 Apr 2019 16:19:39 +0200 Subject: OpenJDK Updates Project Builds In-Reply-To: References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> Message-ID: Hi, I'm neither Andrew, nor Martijn, but I'll try to answer regardless. On Mon, 2019-04-15 at 22:34 +0900, Takahiro YAMADA wrote: > Hi Andrew and Martin, > > Thank you for all your cooperation. > I have waited for these early access builds for LTS release. > > But I'm afraid that the build number is old for now. > e.g. JDK-8221798[1] is resolved in 8u212-b10, but I can download 8u212-b02 > from the site[2]. This is a bit confusing, I have to admit. Resolved in 8u212-b10 means it's resolved in Oracle JDK's 8u212-b10. You can see that by the "Fix Version/s" field of [1]. It's "8u212", not "openjdk8u212". The latter refers to OpenJDK fixes. There won't be an exact match with regards to build numbers going forward as we won't have any control over what Oracle does downstream. 8u212-b02 is the latest *OpenJDK* tag[i]. As to your question with regards to JDK-8205432, "Replace the placeholder Japanese era name". A backport for JDK 8u[ii] will be part of the upcoming OpenJDK 8u212 *final* release due April 16, 2019. > I hope this will improve in the future. > Maybe 8u212 from Oracle will release April 16 in GMT. > I concern that the build might be different from your builds. > Do you have any idea? We are trying to match Oracle JDK with our OpenJDK releases as much as possible. Hope this helps. Thanks, Severin [i] http://hg.openjdk.java.net/jdk8u/jdk8u/tags [ii] https://bugs.openjdk.java.net/browse/JDK-8222220 > [1] https://bugs.openjdk.java.net/browse/JDK-8221798 > [2] https://adoptopenjdk.net/upstream.html > > Regards, > Takahiro YAMADA > > 2019?4?15?(?) 20:34 Martijn Verburg : > > > Hi all, > > > > We'll also link to these builds from Adopt's home page starting from > > today/tomorrow. It should give the extra eyes it deserves for those > > looking for the unbranded / untouched builds. > > > > Cheers, > > Martijn > > > > > > On Mon, 15 Apr 2019 at 11:25, Andrew Haley wrote: > > > > > In the past Oracle provided builds of OpenJDK updates. Now that we're > > > maintaining JDK updates outside Oracle, these are missing. > > > > > > There are many organizations producing OpenJDK builds, Red Hat > > > included, all with subtle variations. As project lead, I believe that > > > our users need pure "vanilla" binaries, fully TCK'd, equivalent to > > > those Oracle builds, for reference and for production use. > > > > > > With the co-operation of AdoptOpenJDK, we now have early access > > > preview Linux and Windows binaries (currently x86-64 only) at > > > > > > https://adoptopenjdk.net/upstream.html > > > > > > These are (for now) built and tested at Red Hat, and signed by me as > > > Update project lead. I thank Red Hat for the use of its build and test > > > infrastructure, Severin Gehwolf in particular, and AdoptOpenJDK for > > > their help. > > > > > > -- > > > Andrew Haley > > > Java Platform Lead Engineer > > > Red Hat UK Ltd. > > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > > From martijnverburg at gmail.com Mon Apr 15 14:27:45 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 15 Apr 2019 15:27:45 +0100 Subject: OpenJDK Updates Project Builds In-Reply-To: References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> Message-ID: Hi Takahiro, The official 8u212 release build (as tagged by Andrew H) will likely appear tomorrow or the day after (assuming it passes all of the testing on Red Hat's servers). Cheers, Martijn On Mon, 15 Apr 2019 at 14:34, Takahiro YAMADA wrote: > Hi Andrew and Martin, > > Thank you for all your cooperation. > I have waited for these early access builds for LTS release. > > But I'm afraid that the build number is old for now. > e.g. JDK-8221798[1] is resolved in 8u212-b10, but I can download 8u212-b02 > from the site[2]. > I hope this will improve in the future. > Maybe 8u212 from Oracle will release April 16 in GMT. > I concern that the build might be different from your builds. > Do you have any idea? > > [1] https://bugs.openjdk.java.net/browse/JDK-8221798 > [2] https://adoptopenjdk.net/upstream.html > > Regards, > Takahiro YAMADA > > 2019?4?15?(?) 20:34 Martijn Verburg : > >> Hi all, >> >> We'll also link to these builds from Adopt's home page starting from >> today/tomorrow. It should give the extra eyes it deserves for those >> looking for the unbranded / untouched builds. >> >> Cheers, >> Martijn >> >> >> On Mon, 15 Apr 2019 at 11:25, Andrew Haley wrote: >> >> > In the past Oracle provided builds of OpenJDK updates. Now that we're >> > maintaining JDK updates outside Oracle, these are missing. >> > >> > There are many organizations producing OpenJDK builds, Red Hat >> > included, all with subtle variations. As project lead, I believe that >> > our users need pure "vanilla" binaries, fully TCK'd, equivalent to >> > those Oracle builds, for reference and for production use. >> > >> > With the co-operation of AdoptOpenJDK, we now have early access >> > preview Linux and Windows binaries (currently x86-64 only) at >> > >> > https://adoptopenjdk.net/upstream.html >> > >> > These are (for now) built and tested at Red Hat, and signed by me as >> > Update project lead. I thank Red Hat for the use of its build and test >> > infrastructure, Severin Gehwolf in particular, and AdoptOpenJDK for >> > their help. >> > >> > -- >> > Andrew Haley >> > Java Platform Lead Engineer >> > Red Hat UK Ltd. >> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >> > >> > From machunhui2 at huawei.com Tue Apr 16 07:53:38 2019 From: machunhui2 at huawei.com (machunhui (C)) Date: Tue, 16 Apr 2019 07:53:38 +0000 Subject: OpenJDK 8u212-b02 EA Released Message-ID: <4ddc6a51c26d4b63a780aa40409240e8@huawei.com> Hi I didn?t see tag 8u211, does that mean there is no security vulnerabilities and critical bug fixes between 8u202 and 8u212? Thanks. -------------------------------------------------- ??? Ma Chunhui Mail: machunhui2 at huawei.com 2012???-???????? 2012 Laboratories-Language VM Lab,2012Labs From hohensee at amazon.com Tue Apr 16 13:32:00 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 16 Apr 2019 13:32:00 +0000 Subject: OpenJDK 8u212-b02 EA Released In-Reply-To: <4ddc6a51c26d4b63a780aa40409240e8@huawei.com> References: <4ddc6a51c26d4b63a780aa40409240e8@huawei.com> Message-ID: <412681B5-A4F9-4B72-A11F-A45FD3CE08DA@amazon.com> There is no OpenJDK 8u211. OpenJDK 8u212 includes all the security and critical bug fixes that are in Oracle JDK 8u211. Paul ?On 4/16/19, 12:54 AM, "jdk8u-dev on behalf of machunhui (C)" wrote: Hi I didn?t see tag 8u211, does that mean there is no security vulnerabilities and critical bug fixes between 8u202 and 8u212? Thanks. -------------------------------------------------- ??? Ma Chunhui Mail: machunhui2 at huawei.com 2012???-???????? 2012 Laboratories-Language VM Lab,2012Labs From dalibor.topic at oracle.com Tue Apr 16 17:31:07 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Tue, 16 Apr 2019 19:31:07 +0200 Subject: OpenJDK Updates Project Builds In-Reply-To: References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> Message-ID: <6092753a-f4d0-da63-6b84-5565f652b75e@oracle.com> On 15.04.2019 16:19, Severin Gehwolf wrote: >> I hope this will improve in the future. Maybe 8u212 from Oracle >> will release April 16 in GMT. I concern that the build might be >> different from your builds. Do you have any idea? > > We are trying to match Oracle JDK with our OpenJDK releases as much > as possible. Fwiw, the functional equivalence between Oracle JDK and OpenJDK only started with JDK 11, and holds only for as long as Oracle maintains a particular update series (i.e. at least six months). Once Oracle stops participating, other developers still developing the updates in OpenJDK may and typically will make their own, often different decisions about the timing, scope and suitability of features, enhancements and bug fixes to include in the 'OpenJDK updates' source code going forward, so functional equivalence should not be expected. Historically, once Oracle stops participating in the development of an update release in OpenJDK, it tends to quickly become different from the Oracle JDK releases. There are multiple reasons for that: * OpenJDK 8u source code is available under an open source license, so changes are possible and should be expected. Different organizations will prioritize different changes and work on different schedules. * Considering that feature and bug fix differences already exist between various downstream builds of OpenJDK 8u outside of Oracle, and some of them contain dozens or more additional changes for various reasons, it's not really possible for them not to be different from Oracle JDK releases or from each other. * Different organizations may care about different sets of platforms and functionality. At Oracle, the set of supported platforms for Oracle JDK 8 is documented at https://www.oracle.com/technetwork/java/javase/certconfig-2095354.html . The set of actively supported platforms within OpenJDK 8u may overlap in some ways, miss other platforms available in Oracle JDK, but on the other hand also add additional ones, depending on what the current configuration of contributors is at any given time. For example, as OpenJFX contributors have moved on to newer releases decoupled from the JDK, there are no OpenJDK contributors left willing to maintain OpenJFX 8 further. Relying on OpenJDK 8 updates as a runtime for JavaFX applications could therefore become a challenge going forward. * Different organizations may make different technological evolution choices. For example, a non-trivial part of the effort around updates is keeping HotSpot in great shape from one release to next. If an organization's focus is on reducing the amount of work they spend on backporting changes from later releases it might be appealing for them to move to later versions of HotSpot, adjusting the code in the process to work within the context of the Java SE 8 specification and users' expectations (such as handling removed VM flags, for example). On the other hand, if their priority is to provide a stable HotSpot platform with similar behavioral characteristics between releases, they'll try to minimize the amount of changes. Those two approaches are obviously mutually exclusive. 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 dalibor.topic at oracle.com Tue Apr 16 19:49:14 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Tue, 16 Apr 2019 21:49:14 +0200 Subject: OpenJDK Updates Project Builds In-Reply-To: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> Message-ID: <9e3b46db-c190-5a8a-3d26-050aab48d8ac@oracle.com> On 15.04.2019 12:25, Andrew Haley wrote: > we now have early access > preview Linux and Windows binaries (currently x86-64 only) at > > https://adoptopenjdk.net/upstream.html I would suggest using the version nomenclature per JEP 322, i.e. "A version string is a version number, $VNUM, possibly followed by pre-release, build, and other optional information, one of: $VNUM(-$PRE)?\+$BUILD(-$OPT)? $VNUM-$PRE(-$OPT)? $VNUM(+-$OPT)? where $PRE is a pre-release identifier (e.g., ea), $BUILD is a build number, and $OPT is optional build information." i.e. 11.0.3-ea+6, for example. 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 hohensee at amazon.com Tue Apr 16 20:10:52 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 16 Apr 2019 20:10:52 +0000 Subject: Request for Comments: Backport of JDK-8206955: MethodHandleProxies.asInterfaceInstance does not support default methods In-Reply-To: <90fc83e2-f656-49ff-d198-610f5bc905b5@loongson.cn> References: <17a40cd9-6a38-25b8-23df-20cd243531d7@loongson.cn> <40B6AD7C-33F7-4BF9-91ED-13563C0D413B@amazon.com> <90fc83e2-f656-49ff-d198-610f5bc905b5@loongson.cn> Message-ID: Pushed to jdk8u-dev. Waiting for jdk11u-fix-yes. Paul ?On 4/12/19, 6:52 PM, "Leslie Zhai" wrote: Hi Paul, Thanks for your kind response! ? 2019?04?12? 22:35, Hohensee, Paul ??: > This looks fine, except for a nit: > > In MethodHandleProxies.java, add a blank line after " import java.util.concurrent.ConcurrentHashMap;" as in the original patch. Thanks for your review! Updated: http://cr.openjdk.java.net/~lzhai/8206955-8u/webrev.01/ > > I see you're not a jdk8u committer, so if you like I'll sponsor and push the patch (with the extra blank line :)). I've added a jdk8u fix request to JDK-8206955. Thanks for your sponsor! > > This patch should also be backported to jdk11u. No need for an email for patches such as this that apply cleanly. You should be able to just tag JDK-8206955 with jdk11u-fix-request. I'll sponsor/push that too if you like. Taged :) Thanks, Leslie Zhai > > Thanks, > > Paul > > On 4/11/19, 7:57 PM, "jdk8u-dev on behalf of Leslie Zhai" wrote: > > Hi Andrew, > > I fixed the similar issue as JDK-8203699 for jdk-mips, and I need to > backport the fix for jdk-mips to jdk8-mips, because JDK-8203699 is also > reproducible after backport the fix for JDK-8206955 to jdk8-mips. > > ? 2019?04?10? 18:07, Leslie Zhai ??: > > Hi, > > > > I would like to backport the fix for: > > Could I backport the fix? > > Thanks, > Leslie Zhai > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8206955 > > > > To OpenJDK 8 updates dev: > > > > http://hg.openjdk.java.net/jdk8u/jdk8u-dev > > > > The fix is mostly the same as the version that was committed in 12. > > > > Webrev: http://cr.openjdk.java.net/~lzhai/8206955-8u/webrev.00/ > > > > Please review it and give me some comments. > > > > Thanks, > > > > Leslie Zhai > > > > > > > > From gnu.andrew at redhat.com Tue Apr 16 21:26:16 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 16 Apr 2019 22:26:16 +0100 Subject: OpenJDK 8u212 Released Message-ID: <5af06e83-2cf6-d808-35db-3be761d007dd@redhat.com> We are pleased to announce the release of OpenJDK 8u212. The source tarball is available from: * https://openjdk-sources.osci.io/openjdk8/openjdk8u212-b03.tar.xz The tarball is accompanied by a digital signature available at: * https://openjdk-sources.osci.io/openjdk8/openjdk8u212-b03.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: 892a2332265c3d43c0796de420cfaff4938b48e04e8ba063cdbcf67371e5f542 openjdk8u212-b03.tar.xz 6f40c483bb1a1f81b39485f583711eae63b9d289922387f0d2998846243ea25b openjdk8u212-b03.tar.xz.sig The checksums can be downloaded from: * https://openjdk-sources.osci.io/openjdk8/openjdk8u212-b03.sha256 What's New? =========== New in OpenJDK 8u212-b03: * Security fixes - S8211936, CVE-2019-2602: Better String parsing - S8218453, CVE-2019-2684: More dynamic RMI interactions - S8219066, CVE-2019-2698: Fuzzing TrueType fonts: setCurrGlyphID() * Other changes - S7127191: SA JSDB does not display native symbols correctly for transported Linux cores - S8027434: "-XX:OnOutOfMemoryError" uses fork instead of vfork - S8028254: gc/arguments/TestMinInitialErgonomics.java failed with unexpected initial heap size - S8029661: Support TLS v1.2 algorithm in SunPKCS11 provider - S8042131: DateTimeFormatterBuilder Mapped-values do not work for JapaneseDate - S8043387: java/time/test/java/util/TestFormatter.java failed. - S8044047: Missing null pointer checks for streams - S8059038: Create new launcher for SA tools - S8065749: [TESTBUG]: gc/arguments/TestG1HeapRegionSize.java fails at nightly - S8068269: RTM tests that assert on non-zero lock statistics are too strict in RTMTotalCountIncrRate > 1 cases - S8076164: [JTextField] When input too long Thai character, cursor's behavior is odd - S8076274: [TESTBUG] Remove @ignore from runtime\NMT\JcmdDetailDiff.java - S8076458: java/util/stream/test/org/openjdk/tests/java/util/stream/FlatMapOpTest.java timeout - S8077608: [TESTBUG] Enable Hotspot jtreg tests to run in agentvm mode - S8080932: [TEST_BUG] Test java/awt/BasicStroke/DashStrokeTest.java fails with Bad script error due to improper @run notation - S8129822: Define "headful" jtreg keyword - S8132136: [PIT] RTL orientation in JEditorPane is broken - S8132985: Crash in freetypescaler.c due to double free - S8133108: [PIT] Container size is wrong in JEditorPane - S8133731: [TEST_BUG] Unmappable in ASCII character such as Thai should be escaped in the regtests targeted for a regular non-I18n runs - S8133802: replace some tags (obsolete in html5) in security-libs docs - S8133984: print_compressed_class_space() is only defined in 64-bit VM - S8139803: Fix for 8132985 breaks OpenJDK build on windows. - S8141491: Unaligned memory access in Bits.c - S8145096: Undefined behaviour in HotSpot - S8148928: java/util/stream/test/**/SequentialOpTest.java timed out intermittently - S8164656: krb5 does not retry if TCP connection timeouts - S8170681: Remove fontconfig header files from JDK source tree - S8175120: Remove old tests on kdc timeout policy - S8180469: Wrong short form text for supplemental Japanese era - S8180904: Hotspot tests running with -agentvm failing due to classpath - S8184309: Build warnings from GCC 7.1 on Fedora 26 - S8185975: PPC64: Fix vsldoi interface according to the ISA - S8187364: Unable to enter zero width non-joiner (ZWNJ) symbol in Swing text component - S8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR, VENDOR, but no configure flag - S8193764: Cannot set COMPANY_NAME when configuring a build - S8195153: [test] runtime/6981737/Test6981737.java shouldn't check 'java.vendor' and 'java.vm.vendor' properties - S8197429: Increased stack guard causes segfaults on x86-32 - S8200109: NMT: diff_malloc_site assert(early->flags() == current->flags(), "Must be the same memory type") - S8200115: System property java.vm.vendor value includes quotation marks - S8202088: Japanese new era implementation - S8204142: AWT hang occurs when sequenced events arrive out of sequence in multiple AppContexts - S8205432: Replace the placeholder Japanese era name - S8206075: On x86, assert on unbound assembler Labels used as branch targets - S8206120: Add test cases for lenient Japanese era parsing - S8207070: Webstart app popup on wrong screen in a one-screen setup changing to multi-monitor - S8207152: Placeholder for Japanese new era should be two characters - S8207258: Distrust TLS server certificates anchored by Symantec Root CAs - S8208480: Test failure: assert(is_bound() || is_unused()) after JDK-8206075 in C1 - S8208656: Move java/util/Calendar/CalendarTestScripts tests into OpenJDK - S8210633: Cannot parse JapaneseDate string with DateTimeFormatterBuilder Mapped-values - S8210647: libsaproc is being compiled without optimization - S8211106: [windows] Update OS detection code to recognize Windows Server 2019 - S8211231: BarrierSetC1::generate_referent_check() confuses register allocator - S8211382: ISO2022JP and GB18030 NIO converter issues - S8211398: Square character support for the Japanese new era - S8211435: Exception in thread "AWT-EventQueue-1" java.lang.IllegalArgumentException: null source - S8211926: Catastrophic size_t underflow in BitMap::*_large methods - S8212110: Build of saproc.dll broken on Windows 32 bit after JDK-8210647 - S8212178: Soft reference reclamation race in com.sun.xml.internal.stream.util.ThreadLocalBufferAllocator - S8212914: Test javax/imageio/plugins/bmp/BMP8BPPLoadTest.java fails - S8212941: Support new Japanese era in java.time.chrono.JapaneseEra - S8213151: [AIX] Some class library files are missing the Classpath exception - S8213154: Update copyright headers of files in src tree that are missing Classpath exception - S8213419: C2 may hang in MulLNode::Ideal()/MulINode::Ideal() with gcc 8.2.1 - S8213583: Error while opening the JFileChooser when desktop contains shortcuts pointing to deleted files. - S8213952: Relax DNSName restriction as per RFC 1123 - S8213983: [macosx] Keyboard shortcut ?cmd +`? stops working properly if popup window is displayed - S8213992: Rename and make DieOnSafepointTimeout the diagnostic option - S8214059: Undefined behaviour in ADLC - S8214061: Buffer written into itself - S8214189: test/hotspot/jtreg/compiler/intrinsics/mathexact/MulExactLConstantTest.java fails on Windows x64 when run with -XX:-TieredCompilation - S8214206: Fix for JDK-8213419 is broken on 32-bit - S8215364: JavaFX crashes on Ubuntu 18.04 with Wayland while using Swing-FX interop - S8215934: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results - S8215976: Fix gmtime_r declaration conflicts in zip.cpp with linux header files - S8216037: Avoid calling vm_update with a NULL name - S8216058: [TESTBUG] tools/launcher/VersionCheck.java fails after JDK-8215992 - S8216396: Support new Japanese era and new currency code points in java.lang.Character for Java SE 8 - S8217305: Missing 0 in java.dll file version cause issues with patch management software - S8217432: MetaspaceGC::_capacity_until_GC exceeds MaxMetaspaceSize - S8217520: Remove vm.opt.MaxGCPauseMillis == "null" from TestOldGenCollectionUsage.java - S8217579: TLS_EMPTY_RENEGOTIATION_INFO_SCSV is disabled after 8211883 - S8217609: New era placeholder not recognized by java.text.SimpleDateFormat - S8217710: Add 5 currency code points to Java SE 8uX - S8217753: Enable HotSpot builds on 5.x Linux kernels - S8218613: [TESTBUG] runtime/ErrorHandling tests are building incorrect testlibrary classes - S8218915: Change isJavaIdentifierStart and isJavaIdentifierPart to handle new code points - S8219636: Windows build failure after JDK-8207070 8u backport - S8219890: Calendar.getDisplayName() returns empty string for new Japanese Era on some locales - S8219961: [ppc64] Increase code size for interpreter generation. - S8220397: REGRESSION: JDK-8036003 backport regresses no_strip builds - S8220641: [TESTBUG] New test KdcPolicy.java introduced by JDK-8164656 needs same change as JDK-8190690 -- 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 Apr 16 22:17:45 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 16 Apr 2019 23:17:45 +0100 Subject: [RFR] [8u] jdk8u212-b03 & jdk8u212-b04 Message-ID: <3277b3a3-9c2d-bf9f-0666-7417b8f406d8@redhat.com> OpenJDK 8u212 has been released: http://bitly.com/oj8u212 Here are the remaining changes for the jdk8u repository: Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8u212/ Changes in jdk8u212-b03: - S8042131: DateTimeFormatterBuilder Mapped-values do not work for JapaneseDate - S8205432: Replace the placeholder Japanese era name - S8208656: Move java/util/Calendar/CalendarTestScripts tests into OpenJDK - S8210633: Cannot parse JapaneseDate string with DateTimeFormatterBuilder Mapped-values - S8211936: Better String parsing - S8218453: More dynamic RMI interactions - S8219066: Fuzzing TrueType fonts: setCurrGlyphID() - S8219890: Calendar.getDisplayName() returns empty string for new Japanese Era on some locales Changes in jdk8u212-b04: - S8221355: Performance regression after JDK-8155635 backport into 8u jdk8u212-b03 is tagged as jdk8u212-ga. jdk8u221-b04 is available for those who want the additional performance fix. -- 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 Tue Apr 16 22:26:04 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 17 Apr 2019 00:26:04 +0200 Subject: [RFR] [8u] jdk8u212-b03 & jdk8u212-b04 In-Reply-To: <3277b3a3-9c2d-bf9f-0666-7417b8f406d8@redhat.com> References: <3277b3a3-9c2d-bf9f-0666-7417b8f406d8@redhat.com> Message-ID: <1c59c9f1-6e1b-a0e1-2c78-1a35ced55985@redhat.com> On 4/17/19 12:17 AM, Andrew John Hughes wrote: > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8u212/ corba changes are trivially fine. hotspot changes are fine. jaxp changes are trivially fine. jaxws changes are trivially fine. jdk changes look fine. I spot-checked the change against 2 CVE patches pushed to 12u langtools changes are trivially fine. nashorn changes are trivially fine. root changes are trivially fine. Thumbs up. -Aleksey From gnu.andrew at redhat.com Tue Apr 16 22:32:27 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 16 Apr 2019 23:32:27 +0100 Subject: [RFR] [8u] jdk8u212-b03 & jdk8u212-b04 In-Reply-To: <1c59c9f1-6e1b-a0e1-2c78-1a35ced55985@redhat.com> References: <3277b3a3-9c2d-bf9f-0666-7417b8f406d8@redhat.com> <1c59c9f1-6e1b-a0e1-2c78-1a35ced55985@redhat.com> Message-ID: <14ec5646-ff03-a469-1e35-d581ad448016@redhat.com> On 16/04/2019 23:26, Aleksey Shipilev wrote: > On 4/17/19 12:17 AM, Andrew John Hughes wrote: >> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8u212/ > > corba changes are trivially fine. > hotspot changes are fine. > jaxp changes are trivially fine. > jaxws changes are trivially fine. > jdk changes look fine. I spot-checked the change against 2 CVE patches pushed to 12u > langtools changes are trivially fine. > nashorn changes are trivially fine. > root changes are trivially fine. > > Thumbs up. > > -Aleksey > Thanks. Pushed. -- 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 zhaixiang at loongson.cn Wed Apr 17 01:14:58 2019 From: zhaixiang at loongson.cn (Leslie Zhai) Date: Wed, 17 Apr 2019 09:14:58 +0800 Subject: Request for Comments: Backport of JDK-8206955: MethodHandleProxies.asInterfaceInstance does not support default methods In-Reply-To: References: <17a40cd9-6a38-25b8-23df-20cd243531d7@loongson.cn> <40B6AD7C-33F7-4BF9-91ED-13563C0D413B@amazon.com> <90fc83e2-f656-49ff-d198-610f5bc905b5@loongson.cn> Message-ID: Hi Paul, Thanks a lot! Patch[1] applies cleanly, comes with its own test for jdk11-x86. Cheers, Leslie Zhai [1] http://hg.openjdk.java.net/jdk/jdk/rev/3142a04a2f6d ? 2019?04?17? 04:10, Hohensee, Paul ??: > Pushed to jdk8u-dev. Waiting for jdk11u-fix-yes. > > Paul > > ?On 4/12/19, 6:52 PM, "Leslie Zhai" wrote: > > Hi Paul, > > Thanks for your kind response! > > > ? 2019?04?12? 22:35, Hohensee, Paul ??: > > This looks fine, except for a nit: > > > > In MethodHandleProxies.java, add a blank line after " import java.util.concurrent.ConcurrentHashMap;" as in the original patch. > > Thanks for your review! Updated: > http://cr.openjdk.java.net/~lzhai/8206955-8u/webrev.01/ > > > > > I see you're not a jdk8u committer, so if you like I'll sponsor and push the patch (with the extra blank line :)). I've added a jdk8u fix request to JDK-8206955. > > Thanks for your sponsor! > > > > > This patch should also be backported to jdk11u. No need for an email for patches such as this that apply cleanly. You should be able to just tag JDK-8206955 with jdk11u-fix-request. I'll sponsor/push that too if you like. > > Taged :) > > Thanks, > Leslie Zhai > > > > > Thanks, > > > > Paul > > > > On 4/11/19, 7:57 PM, "jdk8u-dev on behalf of Leslie Zhai" wrote: > > > > Hi Andrew, > > > > I fixed the similar issue as JDK-8203699 for jdk-mips, and I need to > > backport the fix for jdk-mips to jdk8-mips, because JDK-8203699 is also > > reproducible after backport the fix for JDK-8206955 to jdk8-mips. > > > > ? 2019?04?10? 18:07, Leslie Zhai ??: > > > Hi, > > > > > > I would like to backport the fix for: > > > > Could I backport the fix? > > > > Thanks, > > Leslie Zhai > > > > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8206955 > > > > > > To OpenJDK 8 updates dev: > > > > > > http://hg.openjdk.java.net/jdk8u/jdk8u-dev > > > > > > The fix is mostly the same as the version that was committed in 12. > > > > > > Webrev: http://cr.openjdk.java.net/~lzhai/8206955-8u/webrev.00/ > > > > > > Please review it and give me some comments. > > > > > > Thanks, > > > > > > Leslie Zhai > > > > > > > > > > > > > > > > > > From sgehwolf at redhat.com Wed Apr 17 08:40:58 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 17 Apr 2019 10:40:58 +0200 Subject: OpenJDK Updates Project Builds In-Reply-To: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> Message-ID: On Mon, 2019-04-15 at 11:25 +0100, Andrew Haley wrote: > > https://adoptopenjdk.net/upstream.html > > These are (for now) built and tested at Red Hat, and signed by me as > Update project lead. This page now also has OpenJDK 11.0.3 GA and OpenJDK 8u212 GA binary builds for Linux x64 and Windows x64. Thanks, Severin From adinn at redhat.com Wed Apr 17 09:30:30 2019 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 17 Apr 2019 10:30:30 +0100 Subject: OpenJDK Updates Project Builds In-Reply-To: <6092753a-f4d0-da63-6b84-5565f652b75e@oracle.com> References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> <6092753a-f4d0-da63-6b84-5565f652b75e@oracle.com> Message-ID: <94c0602c-423f-341d-63c0-fc3889efaf23@redhat.com> On 16/04/2019 18:31, Dalibor Topic wrote: > Fwiw, the functional equivalence between Oracle JDK and OpenJDK only > started with JDK 11, and holds only for as long as Oracle maintains a > particular update series (i.e. at least six months). > > Once Oracle stops participating, other developers still developing the > updates in OpenJDK may and typically will make their own, often > different decisions about the timing, scope and suitability of features, > enhancements and bug fixes to include in the 'OpenJDK updates' source > code going forward, so functional equivalence should not be expected. Just to be clear, can I take it that you are only talking about difference between Oracle's proprietary JDK11u releases and the common feature set used in all subsequent OpenJDK JDK11u update releases? Ditto for JDK8u? I ask that because your comment comes across to me as suggesting that the different JDK11u release providers (Oracle excluded) are in some danger of providing different feature sets in their releases of jdk11u. I have to disagree. I have seen, and expect to continue to see, every intention of avoiding such a state of disarray and disunity on the part of all the providers still involved in working on JDK11u (Oracle being exempt from that group). > Historically, once Oracle stops participating in the development of an > update release in OpenJDK, it tends to quickly become different from the > Oracle JDK releases. It is, of course, Oracle's legitimate choice to introduce such a divergence for their proprietary builds. I think it is unfortunate they would make such a choice rather than work with those still involved in JDK11u to ensure consistency in all releases. > There are multiple reasons for that: > > * OpenJDK 8u source code is available under an open source license, so > changes are possible and should be expected. Different organizations > will prioritize different changes and work on different schedules. Yet, it seems to me that all the organizations still involved in the JDK8u project (Oracle exempted) are striving to avoid differences in their OpenJDK releases and, where differences exist for historical reasons, to upstream a common feature set into the open repos for all to use. This seems to me to be the biggest priority that is driving the jdk8u project, after back-porting security updates (naturally). > * Considering that feature and bug fix differences already exist between > various downstream builds of OpenJDK 8u outside of Oracle, and some of > them contain dozens or more additional changes for various reasons, it's > not really possible for them not to be different from Oracle JDK > releases or from each other. That may or may not be an accurate account of why any difference might still be present. However, in my eyes at least, it does not justify the rather blithe way in which you comtemplate and excuse Oracle introducing /extra/ differences into new proprietary releases. Java is supposed to be about write once run anywhere. By pursuing its own development path in private, proprietary releases I feel that Oracle is prejudicing that very important goal. > * Different organizations may care about different sets of platforms and > functionality. At Oracle, the set of supported platforms for Oracle JDK > 8 is documented at > https://www.oracle.com/technetwork/java/javase/certconfig-2095354.html . > > The set of actively supported platforms within OpenJDK 8u may overlap in > some ways, miss other platforms available in Oracle JDK, but on the > other hand also add additional ones, depending on what the current > configuration of contributors is at any given time. Indeed Oracle has chosen only to address a subset of available platforms and also configurations. As an example of the latter, Oracle, quite legitimately, has chosen not to build the Shenandoah GC into their releases. Given that Oracle's engineers had no part to play in creating, and very little in maintaining, Shenandoah it is understandable that they might wish to avoid incurring the liability of supporting that capability in their releases. However, unfortunate as that is I still suggest there is a difference in kind between that omission and the action of /creating/ divergent behaviour on the same platform for the same configuration and selected feature set. > * Different organizations may make different technological evolution > choices. Indeed. Yet, the important point is that those currently involved in the jdk8u and jdk11u projects are working to minimize the effect of such choices on users. Of course, in all cases the TCK ensures a very large degree of compatibility between Oracle's Java releases and the corresponding OpenJDK releases so we are only talking about minor discrepancies here. However, the continuing OpenJDK JKD11u and JDK8u projects are certainly taking even such minor discrepancies very seriously. > For example, a non-trivial part of the effort around updates is keeping > HotSpot in great shape from one release to next. If an organization's > focus is on reducing the amount of work they spend on backporting > changes from later releases it might be appealing for them to move to > later versions of HotSpot, adjusting the code in the process to work > within the context of the Java SE 8 specification and users' > expectations (such as handling removed VM flags, for example). > On the other hand, if their priority is to provide a stable HotSpot > platform with similar behavioral characteristics between releases, > they'll try to minimize the amount of changes. The cost of backporting is one reason why all those currently involved the JDK11u and JDK8u projects have been working together on the latest releases to ensure we all use common patches for any backports. To me your presentation of the case belies that, suggesting that there is disunity and competition here when in fact there is co-operation and pooling of both resources and gains -- for us and for our users. n.b. I don't claim to speak here on behalf of all those still involved in the JDK11u or JDK8u projects, nor even on behalf of Red Hat. This is just my personal response to things I found to ring false in your post. 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 ecki at zusammenkunft.net Wed Apr 17 22:43:16 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 17 Apr 2019 22:43:16 +0000 Subject: Refresh cacert File? In-Reply-To: References: Message-ID: hello, I think it was discussed on security-dev before but did not result in some action as far as I understand it. Currently the ?cacert? file shipped with 8u upstream builds is a bit outdated. It contains multiple expired certificates and misses latest additions. Also I noted there are multiple vendors struggling with this file. Since the later Java releases have a canonical source for that file with vetted licensing it totally would make sense to refresh I.e. backport the changes. Is there anything planned in that direction? (An Alternative would be to synchronize it with the Oracle SE version, this allows easier migration between the two packages, however I am not sure if this is an option from the licensing side) Greetings Bernd -- http://bernd.eckenfels.net From gnu.andrew at redhat.com Thu Apr 18 03:44:34 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 18 Apr 2019 04:44:34 +0100 Subject: OpenJDK Updates Project Builds In-Reply-To: <94c0602c-423f-341d-63c0-fc3889efaf23@redhat.com> References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> <6092753a-f4d0-da63-6b84-5565f652b75e@oracle.com> <94c0602c-423f-341d-63c0-fc3889efaf23@redhat.com> Message-ID: On 17/04/2019 10:30, Andrew Dinn wrote: > On 16/04/2019 18:31, Dalibor Topic wrote: snip... >> * Considering that feature and bug fix differences already exist between >> various downstream builds of OpenJDK 8u outside of Oracle, and some of >> them contain dozens or more additional changes for various reasons, it's >> not really possible for them not to be different from Oracle JDK >> releases or from each other. > All I have to add to Andrew's response is to simply point out that it is OpenJDK that is the reference implementation, not Oracle JDK. We would be more than happy for Oracle to contribute to the OpenJDK project as others do. If they instead choose to work in isolation, then that is their choice to diverge from OpenJDK. Those of us working on the OpenJDK 8u and 11u releases the last few months have strived to do our best to work to a common base and continue to contribute any fixes that originate downstream to the upstream code base. Historically, the primary reason "dozens or more additional changes" have accumulated in downstream builds is because it has been difficult to get them included upstream. 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 sgehwolf at redhat.com Thu Apr 18 08:34:16 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 18 Apr 2019 10:34:16 +0200 Subject: Refresh cacert File? In-Reply-To: References: Message-ID: <73f19aa62ddfb725c4e9f2a974103e597dbfd8f6.camel@redhat.com> Hi, On Wed, 2019-04-17 at 22:43 +0000, Bernd Eckenfels wrote: > hello, > > I think it was discussed on security-dev before but did not result in > some action as far as I understand it. Currently the ?cacert? file > shipped with 8u upstream builds is a bit outdated. It contains > multiple expired certificates and misses latest additions. Are you referring to these builds? https://adoptopenjdk.net/upstream.html The reason for this is that for OpenJDK 8u upstream builds the cacerts file will be empty unless the --with-cacerts-file configure option is being used. That's the case for the above 8u builds[1]. > Also I noted there are multiple vendors struggling with this file. There is bound to be divergence as no cacerts file is included upstream in OpenJDK 8u. > Since the later Java releases have a canonical source for that file > with vetted licensing it totally would make sense to refresh I.e. > backport the changes. Is there anything planned in that direction? There has been a proposal and IMO it would make sense to backport JEP319 to JDK 8u: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-March/008975.html Thanks, Severin [1] https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/blob/master/build-openjdk8.sh#L36 From ecki at zusammenkunft.net Thu Apr 18 08:52:48 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 18 Apr 2019 08:52:48 +0000 Subject: Refresh cacert File? In-Reply-To: <73f19aa62ddfb725c4e9f2a974103e597dbfd8f6.camel@redhat.com> References: , <73f19aa62ddfb725c4e9f2a974103e597dbfd8f6.camel@redhat.com> Message-ID: Hello, Yes I would have expected the RH ?upstream? builds to have an empty cacerts file as they are described to be ?pristine?. However thanks for the pointer that this is not entirely the case. So 8u cacerts is still empty, which is I guess better than outdated. I would consider the content of the cacert file to be somewhat related to the security baseline version of Java and backporting the JEP (or actually refreshing the file before each release) would help a lot. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: Severin Gehwolf Gesendet: Donnerstag, April 18, 2019 10:34 AM An: Bernd Eckenfels; jdk8u-dev at openjdk.java.net Cc: security-dev at openjdk.java.net Betreff: Re: Refresh cacert File? Hi, On Wed, 2019-04-17 at 22:43 +0000, Bernd Eckenfels wrote: > hello, > > I think it was discussed on security-dev before but did not result in > some action as far as I understand it. Currently the ?cacert? file > shipped with 8u upstream builds is a bit outdated. It contains > multiple expired certificates and misses latest additions. Are you referring to these builds? https://adoptopenjdk.net/upstream.html The reason for this is that for OpenJDK 8u upstream builds the cacerts file will be empty unless the --with-cacerts-file configure option is being used. That's the case for the above 8u builds[1]. > Also I noted there are multiple vendors struggling with this file. There is bound to be divergence as no cacerts file is included upstream in OpenJDK 8u. > Since the later Java releases have a canonical source for that file > with vetted licensing it totally would make sense to refresh I.e. > backport the changes. Is there anything planned in that direction? There has been a proposal and IMO it would make sense to backport JEP319 to JDK 8u: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-March/008975.html Thanks, Severin [1] https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/blob/master/build-openjdk8.sh#L36 From doko at ubuntu.com Thu Apr 18 13:46:28 2019 From: doko at ubuntu.com (Matthias Klose) Date: Thu, 18 Apr 2019 15:46:28 +0200 Subject: OpenJDK Updates Project Builds In-Reply-To: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> Message-ID: <386ee3ee-d30f-d6a4-2ab9-3bc4c826b4b3@ubuntu.com> On 15.04.19 12:25, Andrew Haley wrote: > In the past Oracle provided builds of OpenJDK updates. Now that we're > maintaining JDK updates outside Oracle, these are missing. > > There are many organizations producing OpenJDK builds, Red Hat > included, all with subtle variations. As project lead, I believe that > our users need pure "vanilla" binaries, fully TCK'd, equivalent to > those Oracle builds, for reference and for production use. > > With the co-operation of AdoptOpenJDK, we now have early access > preview Linux and Windows binaries (currently x86-64 only) at > > https://adoptopenjdk.net/upstream.html > > These are (for now) built and tested at Red Hat, and signed by me as > Update project lead. I thank Red Hat for the use of its build and test > infrastructure, Severin Gehwolf in particular, and AdoptOpenJDK for > their help. Please document how these are configured/built, including the build environment. Or is this information included in the binary packages? From sgehwolf at redhat.com Thu Apr 18 14:18:30 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 18 Apr 2019 16:18:30 +0200 Subject: OpenJDK Updates Project Builds In-Reply-To: <386ee3ee-d30f-d6a4-2ab9-3bc4c826b4b3@ubuntu.com> References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> <386ee3ee-d30f-d6a4-2ab9-3bc4c826b4b3@ubuntu.com> Message-ID: <092487ee78cc136836fcfc838f003ff400d096f4.camel@redhat.com> On Thu, 2019-04-18 at 15:46 +0200, Matthias Klose wrote: > On 15.04.19 12:25, Andrew Haley wrote: > > In the past Oracle provided builds of OpenJDK updates. Now that we're > > maintaining JDK updates outside Oracle, these are missing. > > > > There are many organizations producing OpenJDK builds, Red Hat > > included, all with subtle variations. As project lead, I believe that > > our users need pure "vanilla" binaries, fully TCK'd, equivalent to > > those Oracle builds, for reference and for production use. > > > > With the co-operation of AdoptOpenJDK, we now have early access > > preview Linux and Windows binaries (currently x86-64 only) at > > > > https://adoptopenjdk.net/upstream.html > > > > These are (for now) built and tested at Red Hat, and signed by me as > > Update project lead. I thank Red Hat for the use of its build and test > > infrastructure, Severin Gehwolf in particular, and AdoptOpenJDK for > > their help. > > Please document how these are configured/built, including the build environment. > Or is this information included in the binary packages? These should have all the info you need (for Linux): https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries https://github.com/AdoptOpenJDK/openjdk11-upstream-binaries Thanks, Severin From gromero at linux.vnet.ibm.com Mon Apr 22 14:02:18 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 22 Apr 2019 11:02:18 -0300 Subject: [8u-dev] RFR for non-clean backport of 8154156: PPC64: improve array copy stubs by using vector instructions In-Reply-To: References: Message-ID: Hi Ogata, On 03/28/2019 09:55 AM, Kazunori Ogata wrote: > May I get review for non-clean backport of 8154156: PPC64: improve array > copy stubs by using vector instructions? > > > Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/c9d756fa846e > Weberv: http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8154156/webrev.02/ Change looks good. Only a nit: it's missing a small change from Volker to cast a pointor to in: user: simonis date: Mon May 04 18:41:53 2015 +0200 summary: 8079280: Fix format warning/error in vm_version_ppc.cpp diff -r 3d55863a66ba -r 751a7698b62e hotspot/src/cpu/ppc/vm/vm_version_ppc.cpp --- a/hotspot/src/cpu/ppc/vm/vm_version_ppc.cpp Sat May 02 00:16:29 2015 -0700 +++ b/hotspot/src/cpu/ppc/vm/vm_version_ppc.cpp Mon May 04 18:41:53 2015 +0200 @@ -629,7 +629,7 @@ // Print the detection code. if (PrintAssembly) { ttyLocker ttyl; - tty->print_cr("Decoding dscr configuration stub at " INTPTR_FORMAT " before execution:", code); + tty->print_cr("Decoding dscr configuration stub at " INTPTR_FORMAT " before execution:", p2i(code)); Disassembler::decode((u_char*)code, (u_char*)code_end, tty); } Without that change it will fail to compile on some distros, like Ubuntu. I don't need a new webrev tho. I'll fix it before pushing. So, hearing no objections I'll push it tomorrow to jdk8u/jdk8u-dev/hotspot. Thanks for downporting it. @Martin, thanks a lot for reviewing it. Best regards, Gustavo From epeterson at interactivebrokers.com Mon Apr 22 18:18:06 2019 From: epeterson at interactivebrokers.com (Eric Peterson) Date: Mon, 22 Apr 2019 18:18:06 +0000 Subject: OpenJDK - CPU Matrix Message-ID: <5D246673-4A6B-4B2F-A0CB-BC34310E94C7@interactivebrokers.com> Hi all, I'm wondering if there is an equivalent page for OpenJDK that tracks fixed vulnerabilities for the April release, similar to what Oracle posted for their recent CPU: https://www.oracle.com/technetwork/security-advisory/cpuapr2019-5072813.html#AppendixJAVA I have hunted around a bit but not found anything so far. --Eric From ecki at zusammenkunft.net Mon Apr 22 19:28:13 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 22 Apr 2019 19:28:13 +0000 Subject: OpenJDK - CPU Matrix In-Reply-To: <5D246673-4A6B-4B2F-A0CB-BC34310E94C7@interactivebrokers.com> References: <5D246673-4A6B-4B2F-A0CB-BC34310E94C7@interactivebrokers.com> Message-ID: Hello Eric, the fixed CVEs and other security fixes(!) are listed in the release announcements. Not sure if there is an aggregated view on them. https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009115.html (BTW it should be same for the other releases) As a personal recommendation I would always look up the associated Bugs or CVE numbers in the RedHat big tracker, in all cases I checked (in the past) it was way less secretive and more detailed (after the embargo) than the Oracle/OpenJDK JIRA. (Also Azul publishes a CVE Map for their releases, I am not sure if that document is public, I received it with subscriber access) Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: jdk8u-dev im Auftrag von Eric Peterson Gesendet: Montag, April 22, 2019 8:29 PM An: jdk-updates-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net Betreff: OpenJDK - CPU Matrix Hi all, I'm wondering if there is an equivalent page for OpenJDK that tracks fixed vulnerabilities for the April release, similar to what Oracle posted for their recent CPU: https://www.oracle.com/technetwork/security-advisory/cpuapr2019-5072813.html#AppendixJAVA I have hunted around a bit but not found anything so far. --Eric From OGATAK at jp.ibm.com Tue Apr 23 04:17:44 2019 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Tue, 23 Apr 2019 13:17:44 +0900 Subject: [8u-dev] RFR for non-clean backport of 8154156: PPC64: improve array copy stubs by using vector instructions In-Reply-To: References: Message-ID: Hi Gustavo, Thank you for reviewing and pointing the issue. I wasn't aware that it can cause build error. I'll be cautious. Also thank you to sponsor this backport. Regards, Ogata "Gustavo Romero" wrote on 2019/04/22 23:02:18: > From: "Gustavo Romero" > To: Kazunori Ogata/Japan/IBM at IBMJP, jdk8u-dev at openjdk.java.net > Cc: "Doerr, Martin" , "Andrew Hughes" > Date: 2019/04/22 23:02 > Subject: Re: [8u-dev] RFR for non-clean backport of 8154156: PPC64: > improve array copy stubs by using vector instructions > > Hi Ogata, > > On 03/28/2019 09:55 AM, Kazunori Ogata wrote: > > May I get review for non-clean backport of 8154156: PPC64: improve array > > copy stubs by using vector instructions? > > > > > > > Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/c9d756fa846e > > Weberv: http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8154156/webrev.02/ > > Change looks good. > > Only a nit: it's missing a small change from Volker to cast a pointor to in: > > user: simonis > date: Mon May 04 18:41:53 2015 +0200 > summary: 8079280: Fix format warning/error in vm_version_ppc.cpp > > diff -r 3d55863a66ba -r 751a7698b62e hotspot/src/cpu/ppc/vm/vm_version_ppc.cpp > --- a/hotspot/src/cpu/ppc/vm/vm_version_ppc.cpp Sat May 02 00:16:29 2015 -0700 > +++ b/hotspot/src/cpu/ppc/vm/vm_version_ppc.cpp Mon May 04 18:41:53 2015 +0200 > @@ -629,7 +629,7 @@ > // Print the detection code. > if (PrintAssembly) { > ttyLocker ttyl; > - tty->print_cr("Decoding dscr configuration stub at " INTPTR_FORMAT " > before execution:", code); > + tty->print_cr("Decoding dscr configuration stub at " INTPTR_FORMAT " > before execution:", p2i(code)); > Disassembler::decode((u_char*)code, (u_char*)code_end, tty); > } > > Without that change it will fail to compile on some distros, like Ubuntu. > > I don't need a new webrev tho. I'll fix it before pushing. > > So, hearing no objections I'll push it tomorrow to jdk8u/jdk8u-dev/hotspot. > > Thanks for downporting it. > > @Martin, thanks a lot for reviewing it. > > Best regards, > Gustavo From christoph.langer at sap.com Tue Apr 23 10:11:27 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 23 Apr 2019 10:11:27 +0000 Subject: 8u-critical and 11u-critical request cleanup Message-ID: Hi Andrew, as the April CPUs have been released and the July CPUs were not yet branched to jdk8u and jdk11u, I'd like to ask you to clean up the critical request labels on a few bugs. For OpenJDK 8 updates, please look at this filter: https://bugs.openjdk.java.net/issues/?filter=36564 Both bugs were part of the CPU and should hence be flagged 8u-critical-yes to reflect their actual state. For OpenJDK 11 updates, have a look here: https://bugs.openjdk.java.net/issues/?filter=36559 I think for JDK-8222397 and JDK-8170494, you have accidentally set the 11u-critical flag when approving them this morning for jdk11u-dev. And the other two bugs are Japanese era bugs being part of the April CPU, so should be flagged 11u-critical-yes. Thanks Christoph From hohensee at amazon.com Tue Apr 23 18:15:11 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 23 Apr 2019 18:15:11 +0000 Subject: [8u-dev] RFR+RFA (M): JDK-8176100: [REDO][REDO] G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: <8A7A3619-56E2-4E19-A1E0-BA47CBB5BAE4@amazon.com> References: <8A7A3619-56E2-4E19-A1E0-BA47CBB5BAE4@amazon.com> Message-ID: <25EF3922-AC36-4D6F-B5D6-49B202A44986@amazon.com> Ping. And, may I have a jdk8u-fix-yes tag? ?On 4/11/19, 2:38 PM, "jdk8u-dev on behalf of Hohensee, Paul" 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 From pavel at azul.com Tue Apr 23 18:54:29 2019 From: pavel at azul.com (Pavel Petroshenko) Date: Tue, 23 Apr 2019 18:54:29 +0000 Subject: OpenJDK - CPU Matrix In-Reply-To: References: <5D246673-4A6B-4B2F-A0CB-BC34310E94C7@interactivebrokers.com> Message-ID: <1438249B-7441-4E26-B54F-720716EA0254@azul.com> Hello Eric, Bernd, A CVE fixes matrix for public Azul Community bundles is publicly available at https://docs.azul.com/zulu/zulurelnotes/index.htm#ZuluReleaseNotes/CA_CVE_Fixes_April19.htm Regards, Pavel On Apr 22, 2019, at 12:28 PM, Bernd Eckenfels > wrote: Hello Eric, the fixed CVEs and other security fixes(!) are listed in the release announcements. Not sure if there is an aggregated view on them. https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009115.html (BTW it should be same for the other releases) As a personal recommendation I would always look up the associated Bugs or CVE numbers in the RedHat big tracker, in all cases I checked (in the past) it was way less secretive and more detailed (after the embargo) than the Oracle/OpenJDK JIRA. (Also Azul publishes a CVE Map for their releases, I am not sure if that document is public, I received it with subscriber access) Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: jdk8u-dev im Auftrag von Eric Peterson Gesendet: Montag, April 22, 2019 8:29 PM An: jdk-updates-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net Betreff: OpenJDK - CPU Matrix Hi all, I'm wondering if there is an equivalent page for OpenJDK that tracks fixed vulnerabilities for the April release, similar to what Oracle posted for their recent CPU: https://www.oracle.com/technetwork/security-advisory/cpuapr2019-5072813.html#AppendixJAVA I have hunted around a bit but not found anything so far. --Eric From gnu.andrew at redhat.com Wed Apr 24 04:38:56 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 24 Apr 2019 05:38:56 +0100 Subject: [8u-dev] RFR+RFA (M): JDK-8176100: [REDO][REDO] G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: <25EF3922-AC36-4D6F-B5D6-49B202A44986@amazon.com> References: <8A7A3619-56E2-4E19-A1E0-BA47CBB5BAE4@amazon.com> <25EF3922-AC36-4D6F-B5D6-49B202A44986@amazon.com> Message-ID: <84e8f725-ae22-a6ce-355c-713141b9bcdd@redhat.com> 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" 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 gnu.andrew at redhat.com Wed Apr 24 04:57:54 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 24 Apr 2019 05:57:54 +0100 Subject: Timeline for 11.0.4 development In-Reply-To: References: <78da027e-5956-7168-5704-77a687122412@redhat.com> <9a994c26-9e28-2597-1aee-08c0acbfad0b@redhat.com> Message-ID: <43b0fb22-fe9e-bb87-959a-d2b261b7933a@redhat.com> On 03/04/2019 08:26, Langer, Christoph wrote: > Hi Andrew, snip... [Moving this onto the 8u list] > >> Do you plan a similar schedule for 8u? > > I think when we have the schedule confirmed for jdk11u, we can simply take it over to jdk8u. I can do the announcement mail and update both Wikis (jdk8u and jdk11u). > > As for jdk8u in general: Since the SAP team does not build a downstream SapMachine 8 binary, we are looking at OpenJDK8u with quite low focus. E.g. we don't have the extensive testing environment at hand as we do for JDK11. So beginning with the next update release, I would step back from doing the tagging/integration work in jdk8u. > > Best regards > Christoph > Was the schedule confirmed and wiki updated? I can take over the tagging/integration work for 8u - it will fit in nicely with the downstream work with aarch64/shenandoah-jdk8u - but can you provide me details as to what your process was, so I can apply the same? 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 Wed Apr 24 06:01:58 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 24 Apr 2019 06:01:58 +0000 Subject: Timeline for 11.0.4 development In-Reply-To: <43b0fb22-fe9e-bb87-959a-d2b261b7933a@redhat.com> References: <78da027e-5956-7168-5704-77a687122412@redhat.com> <9a994c26-9e28-2597-1aee-08c0acbfad0b@redhat.com> <43b0fb22-fe9e-bb87-959a-d2b261b7933a@redhat.com> Message-ID: Hi Andrew, > >> Do you plan a similar schedule for 8u? > > > > I think when we have the schedule confirmed for jdk11u, we can simply > take it over to jdk8u. I can do the announcement mail and update both Wikis > (jdk8u and jdk11u). > > > > As for jdk8u in general: Since the SAP team does not build a downstream > SapMachine 8 binary, we are looking at OpenJDK8u with quite low focus. E.g. > we don't have the extensive testing environment at hand as we do for > JDK11. So beginning with the next update release, I would step back from > doing the tagging/integration work in jdk8u. > > > > Best regards > > Christoph > > > > Was the schedule confirmed and wiki updated? As there were no objections, I'll update the Wiki pages and send a heads up notification on the mailing list later today. I initially planned to do this earlier but then there was this wiki outage followed by the public holidays. > > I can take over the tagging/integration work for 8u - it will fit in > nicely with the downstream work with aarch64/shenandoah-jdk8u - but can > you provide me details as to what your process was, so I can apply the same? Great. I'll put some details about the steps into the Wiki. I already started something for JDK11 updates [0]. The first step now should be to integrate jdk8u212-ga/jdk8u212-b04 back to jdk8u-dev. I did similar for jdk11u/jdk11u-dev last week already. I'll get back to you later when the Wiki is updated. Thanks Christoph [0] https://wiki.openjdk.java.net/display/JDKUpdates/Detailed+Process+Description From aph at redhat.com Wed Apr 24 09:04:32 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 24 Apr 2019 10:04:32 +0100 Subject: 8u-critical and 11u-critical request cleanup In-Reply-To: References: Message-ID: On 4/23/19 11:11 AM, Langer, Christoph wrote: > For OpenJDK 11 updates, have a look here: > https://bugs.openjdk.java.net/issues/?filter=36559 > > I think for JDK-8222397 and JDK-8170494, you have accidentally set the 11u-critical flag Which 11u-critical flag do you mean? > when approving them this morning for jdk11u-dev. And the other two bugs are Japanese era bugs being part of the April CPU, so should be flagged 11u-critical-yes. -- 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 Wed Apr 24 09:56:02 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 24 Apr 2019 09:56:02 +0000 Subject: 8u222 release schedule Message-ID: Hi all, following the schedule for OpenJDK 11 update 11.0.4, I've now published the following schedule for 8u222 on the Wiki [0]: March 2019: jdk8u-dev forest open (tag: jdk8u222-b00) Tuesday, April 30 2019: Branch jdk8u-dev to jdk8u Wednesday, May 1 2019: First build (tag: jdk8u222-b01) Wednesday, May 29 2019: RDP2 Wednesday June 26 2019: Last tag before code freeze Tuesday, July 16 2019: GA (tag: jdk8u222-ga) It means that we'll branch next week from jdk8u-dev to jdk8u! There are the same open questions as for JDK 11.0.4: Is everyone in agreement? Do we want to have an explicit RDP2 date between branch from jdk8u-dev and code freeze? Thanks Christoph [0] https://wiki.openjdk.java.net/display/jdk8u/Main From christoph.langer at sap.com Wed Apr 24 12:15:33 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 24 Apr 2019 12:15:33 +0000 Subject: Set new hgupdater versions for jdk8u and jdk11u Message-ID: Hi Andrew, as the April CPU is out of the door and we don't expect any more changes for OpenJDK 8u212 and 11.0.3, I think it's time to ask ops to bump the versions for hgupdater in the release branches: https://hg.openjdk.java.net/jdk8u/ -> openjdk8u222 http://hg.openjdk.java.net/jdk-updates/jdk11u/ -> 11.0.4 The new setting needs to be active before we can merge from dev to release. Thanks Christoph From aph at redhat.com Wed Apr 24 13:06:51 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 24 Apr 2019 14:06:51 +0100 Subject: Set new hgupdater versions for jdk8u and jdk11u In-Reply-To: References: Message-ID: <4848cf43-caf6-2069-09bf-c20dbf6b25bf@redhat.com> On 4/24/19 1:15 PM, Langer, Christoph wrote: > as the April CPU is out of the door and we don't expect any more changes for OpenJDK 8u212 and 11.0.3, I think it's time to ask ops to bump the versions for hgupdater in the release branches: > > https://hg.openjdk.java.net/jdk8u/ -> openjdk8u222 > http://hg.openjdk.java.net/jdk-updates/jdk11u/ -> 11.0.4 > > The new setting needs to be active before we can merge from dev to release. Yep, was about to. Thanks for the reminder. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Wed Apr 24 14:47:05 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 24 Apr 2019 15:47:05 +0100 Subject: 8u222 release schedule In-Reply-To: References: Message-ID: <3a4f9110-42c3-0098-c0f5-755fc37773b7@redhat.com> On 24/04/2019 10:56, Langer, Christoph wrote: > Hi all, > > ? > > following the schedule for OpenJDK 11 update 11.0.4, I?ve now published > the following schedule for 8u222 on the Wiki [0]: > > ? > > ??? March 2019: jdk8u-dev forest open (tag: jdk8u222-b00) > > ??? Tuesday, April 30 2019: Branch jdk8u-dev to jdk8u > > ??? Wednesday, May 1 2019: First build (tag: jdk8u222-b01) > > ??? Wednesday, May 29 2019: RDP2 > > ??? Wednesday June 26 2019: Last tag before code freeze > > ??? Tuesday, July 16 2019: GA (tag: jdk8u222-ga) > > ? > > It means that we?ll branch next week from jdk8u-dev to jdk8u! > > ? > > There are the same open questions as for JDK 11.0.4: Is everyone in > agreement? Do we want to have an explicit RDP2 date between branch from > jdk8u-dev and code freeze? > > ? > > Thanks > > Christoph > > ? > > [0] https://wiki.openjdk.java.net/display/jdk8u/Main > > ? > It's not clear to me what the difference is between 'branch jdk8u-dev' and RDP2. I thought they were the same thing. So my impression is that the process for release x goes as follows: 1. jdk8u is tagged jdk8ux-b00 2. Initial work on jdk8ux takes place in jdk8u-dev tree 3. Each Wednesday, jdk8u-dev is merged to jdk8u and tagged with the next incremental build number. 3. At RDP2, weekly merges cease and fixes for jdk8u have to be explicitly requested by jdk8u-critical-request. jdk8u-dev moves on to release x+1. 4. At code freeze, no more changes are made to jdk8u publicly until after 13h00 PT (20h00 UTC Apr/Jul/Oct, 21h00 UTC Jan) on the unembargo date when the embargo is lifted. The security fixes are then reviewed and pushed, including the final tag jdk8ux-ga. 5. Return to #1 for x+1. What am I missing? 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 Apr 24 15:07:25 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 24 Apr 2019 15:07:25 +0000 Subject: 8u212 missing fixes Message-ID: From Oracle?s 8u211 release notes at https://www.oracle.com/technetwork/java/javase/2col/8u211-bugfixes-5292912.html, this issue https://bugs.openjdk.java.net/browse/JDK-8129988: JSSE should create a single instance of the cacerts KeyStore was in Oracle?s 8u211, but not in OpenJDK 8u212. I?ve just pushed a backport to jdk8u-dev. There are two more of these. https://bugs.openjdk.java.net/browse/JDK-8174268: Declare a public field in JapaneseEra for the era starting May 2019 This has a patch we can backport, which I?ll do. https://bugs.openjdk.java.net/browse/JDK-8216577: Add GlobalSign?s R6 Root certificate https://bugs.openjdk.java.net/browse/JDK-8214188: Certify GlobalSign?s R6 root certificate This doesn?t have a patch, but the necessary info is in JBS. I don?t know how to add a cert, however, so it?d be best if someone knowledgeable did the work. Thanks, Paul From christoph.langer at sap.com Wed Apr 24 15:16:11 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 24 Apr 2019 15:16:11 +0000 Subject: 8u222 release schedule In-Reply-To: <3a4f9110-42c3-0098-c0f5-755fc37773b7@redhat.com> References: <3a4f9110-42c3-0098-c0f5-755fc37773b7@redhat.com> Message-ID: > It's not clear to me what the difference is between 'branch jdk8u-dev' > and RDP2. I thought they were the same thing. > > So my impression is that the process for release x goes as follows: > > 1. jdk8u is tagged jdk8ux-b00 Yes. > 2. Initial work on jdk8ux takes place in jdk8u-dev tree Yes. > 3. Each Wednesday, jdk8u-dev is merged to jdk8u and tagged with the next > incremental build number. Nope, there would be only one merge jdk8u-dev->jdk8u, as stated in the timeline. After that, fixes targeted for jdk8u would have to be done in jdk8u. The weekly merge then goes the other way jdk8u->jdk8u-dev. > 3. At RDP2, weekly merges cease and fixes for jdk8u have to be > explicitly requested by jdk8u-critical-request. jdk8u-dev moves on to > release x+1. Nope, as stated above. RDP2 in that case would probably only mean some more restricted criteria for allowing fixes into jdk8u. But jdk8u-critical-request will be needed for each push into jdk8u, starting from the initial merge jdk8u-dev->jdk8u. > 4. At code freeze, no more changes are made to jdk8u publicly until > after 13h00 PT (20h00 UTC Apr/Jul/Oct, 21h00 UTC Jan) on the unembargo > date when the embargo is lifted. The security fixes are then reviewed > and pushed, including the final tag jdk8ux-ga. Yes. > 5. Return to #1 for x+1. Yes. So, however, let's wait for the outcome of the discussion in [0]. Maybe we end up moving the jdk8u-dev->jdk8u to the RDP2 date, unless somebody seconds Goetz with good arguments. Maybe in the end, Andrew (aph) needs to make a decision ?? Best regards Christoph [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/001004.html From christoph.langer at sap.com Wed Apr 24 15:17:51 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 24 Apr 2019 15:17:51 +0000 Subject: 8u212 missing fixes In-Reply-To: References: Message-ID: Hi Paul, as for the certs, I'm preparing a patch that brings the certificates from jdk11 and higher into jdk8. Best regards Christoph > -----Original Message----- > From: jdk8u-dev On Behalf Of > Hohensee, Paul > Sent: Mittwoch, 24. April 2019 17:07 > To: Andrew Hughes ; jdk8u- > dev at openjdk.java.net > Subject: [DMARC FAILURE] 8u212 missing fixes > > From Oracle?s 8u211 release notes at > https://www.oracle.com/technetwork/java/javase/2col/8u211-bugfixes- > 5292912.html, this issue > > https://bugs.openjdk.java.net/browse/JDK-8129988: JSSE should create a > single instance of the cacerts KeyStore > > was in Oracle?s 8u211, but not in OpenJDK 8u212. I?ve just pushed a backport > to jdk8u-dev. > > There are two more of these. > > https://bugs.openjdk.java.net/browse/JDK-8174268: Declare a public field in > JapaneseEra for the era starting May 2019 > > This has a patch we can backport, which I?ll do. > > https://bugs.openjdk.java.net/browse/JDK-8216577: Add GlobalSign?s R6 > Root certificate > https://bugs.openjdk.java.net/browse/JDK-8214188: Certify GlobalSign?s R6 > root certificate > > This doesn?t have a patch, but the necessary info is in JBS. I don?t know how > to add a cert, however, so it?d be best if someone knowledgeable did the > work. > > Thanks, > > Paul From gnu.andrew at redhat.com Wed Apr 24 15:21:42 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 24 Apr 2019 16:21:42 +0100 Subject: 8u212 missing fixes In-Reply-To: References: Message-ID: <683d238d-feba-ec74-c36e-a09ec02e0a5d@redhat.com> On 24/04/2019 16:07, Hohensee, Paul wrote: > From Oracle?s 8u211 release notes at > https://www.oracle.com/technetwork/java/javase/2col/8u211-bugfixes-5292912.html, > this issue > > ? > > https://bugs.openjdk.java.net/browse/JDK-8129988: JSSE should create a > single instance of the cacerts KeyStore > > ? > > was in Oracle?s 8u211, but not in OpenJDK 8u212. I?ve just pushed a > backport to jdk8u-dev. > > ? Yes, as I mentioned when approving the 8u request, this seems to have slipped through because it was marked as fixed in 8u202, but in a BPR which didn't make OpenJDK. That suggests a flaw in the filter we used. I don't know if it's worth rectifying now, as it only applies to the crossover phase. Maybe something to bear in mind if we end up maintaining OpenJDK 14 or something. > > There are two more of these. > > ? > > https://bugs.openjdk.java.net/browse/JDK-8174268: Declare a public field > in JapaneseEra for the era starting May 2019 > > ? > > This has a patch we can backport, which I?ll do. > This is marked as "Won't Fix" for 11 & 8. Is it really in Oracle 8u? The bug immediately screams "TCK breakage" to me if it's adding a public constant in an API class. > ? > > https://bugs.openjdk.java.net/browse/JDK-8216577: Add GlobalSign?s R6 > Root certificate > > https://bugs.openjdk.java.net/browse/JDK-8214188: Certify GlobalSign?s > R6 root certificate > > ? > > This doesn?t have a patch, but the necessary info is in JBS. I don?t > know how to add a cert, however, so it?d be best if someone > knowledgeable did the work. > 8u doesn't have any certificates, so a pre-requisite would be backporting the work that added them. > ? > > 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 Apr 24 16:02:49 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 24 Apr 2019 17:02:49 +0100 Subject: [11u]: 11.0.4 release schedule In-Reply-To: References: Message-ID: [Bringing jdk8u-dev into this as well as there's a lot of common material] On 24/04/2019 16:08, Langer, Christoph wrote: > Hi, > >> On 4/24/19 11:01 AM, Aleksey Shipilev wrote: >>> On 4/24/19 11:47 AM, Langer, Christoph wrote: >>>> I've now published the following schedule for 11.0.4 on the Wiki [0]: >>>> >>>> March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) >>>> Tuesday, April 30 2019: Branch jdk11u-dev to jdk11u >>>> Wednesday, May 1 2019: First build (tag: jdk-11.0.4+1) >>>> Wednesday, May 29 2019: RDP2 >>>> Wednesday June 26 2019: Last tag before code freeze >>>> Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga) >>>> >>>> Is everyone in agreement with that? >>>> >>>> Note: It means that we'll branch next week from jdk11u-dev to jdk11u! >>> >>> That also means outstanding 11.0.4-oracle things are better to get to 11u- >> dev within a week, right? >>> https://bugs.openjdk.java.net/issues/?filter=36409 >>> >>> I have my doubts about having 2.5 months gap between fork and release. >> That feels too early. Or >>> maybe not, given there is a pending 13 freeze in between, and also >> summer vacations. >> >> That feels early to me too. What will happen is a ton of jdk11u-critcial- >> requests >> for trivial bugs, simply to get them into the next release. > > Well, I had discussions with Goetz about this... I also have/had the feeling, that the proposed date to do the branch is too early. I would also rather propose to do the jdk11u-dev -> jdk11u transport at about the date mentioned as RDP2 above. > > I think, Goetz' reasoning behind suggesting the early branch is, if there was some late checkin which destabilizes things, there would only be about 4 weeks to get it fixed when branching late. Oracle also has an early branch/RDP2 date for their updates. E.g. 12.0.2 is probably branched about now. > > But I would be fine with changing the schedule to this: > > March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) > Tuesday, May 28 2019: RDP2, Branch jdk11u-dev to jdk11u > Wednesday, May 29 2019: First build (tag: jdk-11.0.4+1) > Wednesday June 26 2019: Last tag before code freeze > Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga) > > So, I guess we shall wait a bit and collect further comments on this, e.g. from Goetz himself. Depending on the outcome of the discussion I'd update the Wiki at the end of the week. > > Best regards > Christoph > This looks better. The addition I'd like to see is to start the weekly promotions earlier, so they also happen in the first stage. That would avoid b01 being so huge. I think that's a good halfway house between proposing entering the critical fix stage next week and not promoting anything until the end of May. That would mean multiple jdk11u-dev->jdk11u & jdk8u-dev->jdk8u merges from next Wednesday 1st of May through to the final one of May 29: March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) ================= RDP1 ===================================== = 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 RDP1 build (tag: jdk-11.0.4+5) ================= RDP2 ===================================== = jdk11u tree gets changes only by jdk11u-critical-request = ============================================================ Wednesday, June 5, 2019: First RDP2 build (tag: jdk-11.0.4+6) Wednesday, June 12, 2019: Second RDP2 build (tag: jdk-11.0.4+7) Wednesday, June 19, 2019: Third RDP2 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) This allows regular testing earlier in the cycle, but without restricting the process down to critical fixes early. -- 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 gromero at linux.vnet.ibm.com Wed Apr 24 16:13:47 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 24 Apr 2019 13:13:47 -0300 Subject: [8u-dev] RFR for non-clean backport of 8154156: PPC64: improve array copy stubs by using vector instructions In-Reply-To: References: Message-ID: <6fc4288e-0915-39fc-9777-bf2a4d84b5b9@linux.vnet.ibm.com> Hi, Pushed to jdk/jdk8u-dev: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/6eedcffa129d Thanks, Gustavo On 04/23/2019 01:17 AM, Kazunori Ogata wrote: > Hi Gustavo, > > Thank you for reviewing and pointing the issue. I wasn't aware that it > can cause build error. I'll be cautious. > > Also thank you to sponsor this backport. > > > Regards, > Ogata > > "Gustavo Romero" wrote on 2019/04/22 > 23:02:18: > >> From: "Gustavo Romero" >> To: Kazunori Ogata/Japan/IBM at IBMJP, jdk8u-dev at openjdk.java.net >> Cc: "Doerr, Martin" , "Andrew Hughes" > >> Date: 2019/04/22 23:02 >> Subject: Re: [8u-dev] RFR for non-clean backport of 8154156: PPC64: >> improve array copy stubs by using vector instructions >> >> Hi Ogata, >> >> On 03/28/2019 09:55 AM, Kazunori Ogata wrote: >>> May I get review for non-clean backport of 8154156: PPC64: improve > array >>> copy stubs by using vector instructions? >>> >> >>> >>> Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/c9d756fa846e >>> Weberv: > http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8154156/webrev.02/ >> >> Change looks good. >> >> Only a nit: it's missing a small change from Volker to cast a pointor to > in: >> >> user: simonis >> date: Mon May 04 18:41:53 2015 +0200 >> summary: 8079280: Fix format warning/error in vm_version_ppc.cpp >> >> diff -r 3d55863a66ba -r 751a7698b62e > hotspot/src/cpu/ppc/vm/vm_version_ppc.cpp >> --- a/hotspot/src/cpu/ppc/vm/vm_version_ppc.cpp Sat May 02 00:16:29 2015 > -0700 >> +++ b/hotspot/src/cpu/ppc/vm/vm_version_ppc.cpp Mon May 04 18:41:53 2015 > +0200 >> @@ -629,7 +629,7 @@ >> // Print the detection code. >> if (PrintAssembly) { >> ttyLocker ttyl; >> - tty->print_cr("Decoding dscr configuration stub at " INTPTR_FORMAT > " >> before execution:", code); >> + tty->print_cr("Decoding dscr configuration stub at " INTPTR_FORMAT > " >> before execution:", p2i(code)); >> Disassembler::decode((u_char*)code, (u_char*)code_end, tty); >> } >> >> Without that change it will fail to compile on some distros, like > Ubuntu. >> >> I don't need a new webrev tho. I'll fix it before pushing. >> >> So, hearing no objections I'll push it tomorrow to > jdk8u/jdk8u-dev/hotspot. >> >> Thanks for downporting it. >> >> @Martin, thanks a lot for reviewing it. >> >> Best regards, >> Gustavo > > From stooke at redhat.com Wed Apr 24 19:29:58 2019 From: stooke at redhat.com (Simon Tooke) Date: Wed, 24 Apr 2019 15:29:58 -0400 Subject: [8u-dev] RFR for partial backport of 8031567: Better model for storing source revision information Message-ID: <1f857eb6-be66-c552-3333-acac64ae0093@redhat.com> Hi, In the process of the latest CPU, I found the 'release' file differed between the Linux and Windows built images, and tracked it down to the use of 'hg tip' instead of 'hg id'. As luck would have it, this was previously reported (JDK-8031567) and fixed in JDK 9.? Rather than backport the entire PR to jdk8u, I propose only enough to fix the actual problem; replacing the calls to 'hg tip' with calls to 'hg id -i'. Original JBS: https://bugs.openjdk.java.net/browse/JDK-8031567 Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8031567/ I'm open to a full backport, but wanted to minimize perturbation of 8u.? If this is misguided, please correct me... Thank you for your time, -Simon From xxinliu at amazon.com Thu Apr 25 01:34:11 2019 From: xxinliu at amazon.com (Liu, Xin) Date: Thu, 25 Apr 2019 01:34:11 +0000 Subject: [8u] 8205916: [test] Fix jdk/tools/launcher/RunpathTest to handle both, RPATH and RUNPATH Message-ID: Hi, Reviewers, Bug: https://bugs.openjdk.java.net/browse/JDK-8205916 Webrev: https://cr.openjdk.java.net/~xliu/8205916/webrev.00/ Some systems, including AmazonLinux , choose to generate RUNPATH over RPATH. We have to apply this patch to pass jtreg tests. The backport patch applies clearly. Thanks, --lx From OGATAK at jp.ibm.com Thu Apr 25 04:00:56 2019 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Thu, 25 Apr 2019 13:00:56 +0900 Subject: [8u-dev] RFR for non-clean backport of 8154156: PPC64: improve array copy stubs by using vector instructions In-Reply-To: <6fc4288e-0915-39fc-9777-bf2a4d84b5b9@linux.vnet.ibm.com> References: <6fc4288e-0915-39fc-9777-bf2a4d84b5b9@linux.vnet.ibm.com> Message-ID: Thank you, Gustavo. Regards, Ogata "Gustavo Romero" wrote on 2019/04/25 01:13:47: > From: "Gustavo Romero" > To: Kazunori Ogata/Japan/IBM at IBMJP > Cc: "Andrew Hughes" , jdk8u-dev at openjdk.java.net, > "Doerr, Martin" > Date: 2019/04/25 01:13 > Subject: Re: [8u-dev] RFR for non-clean backport of 8154156: PPC64: > improve array copy stubs by using vector instructions > > Hi, > > Pushed to jdk/jdk8u-dev: > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/6eedcffa129d > > Thanks, > Gustavo > > On 04/23/2019 01:17 AM, Kazunori Ogata wrote: > > Hi Gustavo, > > > > Thank you for reviewing and pointing the issue. I wasn't aware that it > > can cause build error. I'll be cautious. > > > > Also thank you to sponsor this backport. > > > > > > Regards, > > Ogata > > > > "Gustavo Romero" wrote on 2019/04/22 > > 23:02:18: > > > >> From: "Gustavo Romero" > >> To: Kazunori Ogata/Japan/IBM at IBMJP, jdk8u-dev at openjdk.java.net > >> Cc: "Doerr, Martin" , "Andrew Hughes" > > > >> Date: 2019/04/22 23:02 > >> Subject: Re: [8u-dev] RFR for non-clean backport of 8154156: PPC64: > >> improve array copy stubs by using vector instructions > >> > >> Hi Ogata, > >> > >> On 03/28/2019 09:55 AM, Kazunori Ogata wrote: > >>> May I get review for non-clean backport of 8154156: PPC64: improve > > array > >>> copy stubs by using vector instructions? > >>> > >> > >>> > >>> Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/c9d756fa846e > >>> Weberv: > > http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8154156/webrev.02/ > >> > >> Change looks good. > >> > >> Only a nit: it's missing a small change from Volker to cast a pointor to > > in: > >> > >> user: simonis > >> date: Mon May 04 18:41:53 2015 +0200 > >> summary: 8079280: Fix format warning/error in vm_version_ppc.cpp > >> > >> diff -r 3d55863a66ba -r 751a7698b62e > > hotspot/src/cpu/ppc/vm/vm_version_ppc.cpp > >> --- a/hotspot/src/cpu/ppc/vm/vm_version_ppc.cpp Sat May 02 00:16:29 2015 > > -0700 > >> +++ b/hotspot/src/cpu/ppc/vm/vm_version_ppc.cpp Mon May 04 18:41:53 2015 > > +0200 > >> @@ -629,7 +629,7 @@ > >> // Print the detection code. > >> if (PrintAssembly) { > >> ttyLocker ttyl; > >> - tty->print_cr("Decoding dscr configuration stub at " INTPTR_FORMAT > > " > >> before execution:", code); > >> + tty->print_cr("Decoding dscr configuration stub at " INTPTR_FORMAT > > " > >> before execution:", p2i(code)); > >> Disassembler::decode((u_char*)code, (u_char*)code_end, tty); > >> } > >> > >> Without that change it will fail to compile on some distros, like > > Ubuntu. > >> > >> I don't need a new webrev tho. I'll fix it before pushing. > >> > >> So, hearing no objections I'll push it tomorrow to > > jdk8u/jdk8u-dev/hotspot. > >> > >> Thanks for downporting it. > >> > >> @Martin, thanks a lot for reviewing it. > >> > >> Best regards, > >> Gustavo > > > > From gnu.andrew at redhat.com Thu Apr 25 04:04:45 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 25 Apr 2019 05:04:45 +0100 Subject: [8u] 8205916: [test] Fix jdk/tools/launcher/RunpathTest to handle both, RPATH and RUNPATH In-Reply-To: References: Message-ID: <6d928c19-2d89-8339-dfe0-bd512ce7d396@redhat.com> On 25/04/2019 02:34, Liu, Xin wrote: > Hi, Reviewers, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8205916 > Webrev: https://cr.openjdk.java.net/~xliu/8205916/webrev.00/ > > Some systems, including AmazonLinux , choose to generate RUNPATH over RPATH. > We have to apply this patch to pass jtreg tests. The backport patch applies clearly. > > Thanks, > --lx > > Looks fine, thanks. I've approved the request with jdk8u-fix-yes as well. -- 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 Apr 25 04:29:40 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 25 Apr 2019 05:29:40 +0100 Subject: [8u-dev] RFR for partial backport of 8031567: Better model for storing source revision information In-Reply-To: <1f857eb6-be66-c552-3333-acac64ae0093@redhat.com> References: <1f857eb6-be66-c552-3333-acac64ae0093@redhat.com> Message-ID: On 24/04/2019 20:29, Simon Tooke wrote: > Hi, > > In the process of the latest CPU, I found the 'release' file differed > between the Linux and Windows built images, and tracked it down to the > use of 'hg tip' instead of 'hg id'. > > As luck would have it, this was previously reported (JDK-8031567) and > fixed in JDK 9.? > > Rather than backport the entire PR to jdk8u, I propose only enough to > fix the actual problem; replacing the calls to 'hg tip' with calls to > 'hg id -i'. > > Original JBS: https://bugs.openjdk.java.net/browse/JDK-8031567 > > Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8031567/ > > I'm open to a full backport, but wanted to minimize perturbation of 8u.? > If this is misguided, please correct me... > > Thank you for your time, > > -Simon > > > > > Given that 8031567 is an enhancement which rewrites the offending code altogether, I don't think a smaller, different change should really go in under the same ID. It will make it look like 8031567 is present in OpenJDK 8, but none of the actual code that is in 9+ will be there. I'd prefer a full backport of 8031567 for consistency with 9+, but the current webrev is fine too, as long as it is committed under its own ID. -- 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 Thu Apr 25 06:17:14 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 25 Apr 2019 06:17:14 +0000 Subject: [11u, 8u] Updated Wiki pages Message-ID: Hi, I have now finished an overhaul of the Wiki pages for OpenJDK 8 [0] and 11 [1] updates. I implemented some feedback that I?ve gotten. The main goal for the entry pages is to have all important information at hand while also helping (new) contributors to get an understanding of what to do if they were to contribute. So I extracted technical/process detail information to separate pages [2], [3] and link to it from the ?General information? section. I enriched the technical/process detail pages with a checklist for things to do in the release cycle of an update release to be used by release engineers. This is still work in progress. I also added a small section about ?Contributing? which points to a more detailed recipe of things to do [4] (suggested by Aleksey). The rest of the information should be pretty up to date. I added a ?Releases? section with links (to source, binaries, filters etc.) for the April releases 8u212 and 11.0.3. Any feedback is welcome. ?? Thanks Christoph [0] https://wiki.openjdk.java.net/display/jdk8u [1] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u [2] https://wiki.openjdk.java.net/display/JDKUpdates/Detailed+Process+Description [3] https://wiki.openjdk.java.net/display/jdk8u/Detailed+Process+Description [4] https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix From christoph.langer at sap.com Thu Apr 25 06:24:56 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 25 Apr 2019 06:24:56 +0000 Subject: [11u]: 11.0.4 release schedule In-Reply-To: References: Message-ID: Hi, > On 24/04/2019 16:08, Langer, Christoph wrote: > > But I would be fine with changing the schedule to this: > > > > March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) > > Tuesday, May 28 2019: RDP2, Branch jdk11u-dev to jdk11u > > Wednesday, May 29 2019: First build (tag: jdk-11.0.4+1) > > Wednesday June 26 2019: Last tag before code freeze > > Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga) > > > > This looks better. > > The addition I'd like to see is to start the weekly promotions earlier, > so they also happen in the first stage. That would avoid b01 being so > huge. I think that's a good halfway house between proposing entering the > critical fix stage next week and not promoting anything until the end of > May. > > That would mean multiple jdk11u-dev->jdk11u & jdk8u-dev->jdk8u merges > from next Wednesday 1st of May through to the final one of May 29: > > March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) > ================= RDP1 ===================================== > = 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 RDP1 build (tag: jdk-11.0.4+5) > ================= RDP2 ===================================== > = jdk11u tree gets changes only by jdk11u-critical-request = > ========================================================== > == > Wednesday, June 5, 2019: First RDP2 build (tag: jdk-11.0.4+6) > Wednesday, June 12, 2019: Second RDP2 build (tag: jdk-11.0.4+7) > Wednesday, June 19, 2019: Third RDP2 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) > > This allows regular testing earlier in the cycle, but without > restricting the process down to critical fixes early. Sounds like a good suggestion to me as I can see the need to have EA builds early. I think technically we should then tag in jdk11u-dev/jdk8u-dev until the 29th of May and pull these tags into jdk11u/jdk8u. We'll have to confirm with ops whether this will correctly resolve the bugs in JBS (e.g. with the right build associated). Best regards Christoph From gnu.andrew at redhat.com Thu Apr 25 06:25:47 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 25 Apr 2019 07:25:47 +0100 Subject: [RFR] [8u] 8222965: Build Breakage from JDK-8129988 Message-ID: <6d56c8eb-5eee-22fc-a728-9bbd6d7009a6@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8222965 Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8222965/webrev.01/ The recent backport of JDK-8129988: https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/900e4921e59d omitted adding a couple of files, causing build breakage. Full details in the bug description. The webrev above fixes this. -- 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 Apr 25 06:28:02 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 25 Apr 2019 07:28:02 +0100 Subject: [8u-merge] jdk8u->jdk8u-dev: jdk8u212-ga Message-ID: <9d756582-4d1e-1665-f55a-ad6a8e6d8d3f@redhat.com> I've merged jdk8u212-ga back into jdk8u-dev. -- 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 Thu Apr 25 06:34:07 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 25 Apr 2019 06:34:07 +0000 Subject: JDK 8u release engineering (Was: Timeline for 11.0.4 development) Message-ID: Hi Andrew, > > I can take over the tagging/integration work for 8u - it will fit in > > nicely with the downstream work with aarch64/shenandoah-jdk8u - but > can > > you provide me details as to what your process was, so I can apply the > same? > > Great. I'll put some details about the steps into the Wiki. I already started > something for JDK11 updates [0]. > > The first step now should be to integrate jdk8u212-ga/jdk8u212-b04 back to > jdk8u-dev. I did similar for jdk11u/jdk11u-dev last week already. > > I'll get back to you later when the Wiki is updated. Great, I saw that you've integrated jdk8u212-ga/jdk8u212-b04 back to jdk8u-dev. ?? As for the further process recipe, can you check the process description that I created in the Wiki [0]? I'd hope that the information in there helps you to find everything you need. It would also be great if you could develop this document further. The special thing about jdk8u is the mercurial forest structure. So the command line instructions for tagging and pulling should probably be scripted to go over the whole forest. Let me know if you have further questions/suggestions on that one. Thanks Christoph [0] https://wiki.openjdk.java.net/display/jdk8u/Detailed+Process+Description From aph at redhat.com Thu Apr 25 07:48:44 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 25 Apr 2019 08:48:44 +0100 Subject: 8u222 release schedule In-Reply-To: References: <3a4f9110-42c3-0098-c0f5-755fc37773b7@redhat.com> Message-ID: <163fd890-3b93-1893-7d42-6a11cafc7f0e@redhat.com> On 4/24/19 4:16 PM, Langer, Christoph wrote: >> 3. Each Wednesday, jdk8u-dev is merged to jdk8u and tagged with the >> next incremental build number. > > Nope, there would be only one merge jdk8u-dev->jdk8u, as stated in > the timeline. After that, fixes targeted for jdk8u would have to be > done in jdk8u. The weekly merge then goes the other way > jdk8u->jdk8u-dev. I think this suggestion should be accompanied by an explanation of why you want to do it that way. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sgehwolf at redhat.com Thu Apr 25 07:48:51 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 25 Apr 2019 09:48:51 +0200 Subject: [11u]: 11.0.4 release schedule In-Reply-To: References: Message-ID: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> On Thu, 2019-04-25 at 06:24 +0000, Langer, Christoph wrote: > Hi, > > > On 24/04/2019 16:08, Langer, Christoph wrote: > > > > > > But I would be fine with changing the schedule to this: > > > > > > March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) > > > Tuesday, May 28 2019: RDP2, Branch jdk11u-dev to jdk11u > > > Wednesday, May 29 2019: First build (tag: jdk-11.0.4+1) > > > Wednesday June 26 2019: Last tag before code freeze > > > Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga) > > > > > > > This looks better. > > > > The addition I'd like to see is to start the weekly promotions earlier, > > so they also happen in the first stage. That would avoid b01 being so > > huge. I think that's a good halfway house between proposing entering the > > critical fix stage next week and not promoting anything until the end of > > May. > > > > That would mean multiple jdk11u-dev->jdk11u & jdk8u-dev->jdk8u merges > > from next Wednesday 1st of May through to the final one of May 29: > > > > March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) > > ================= RDP1 ===================================== > > = 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 RDP1 build (tag: jdk-11.0.4+5) > > ================= RDP2 ===================================== > > = jdk11u tree gets changes only by jdk11u-critical-request = > > ========================================================== > > == > > Wednesday, June 5, 2019: First RDP2 build (tag: jdk-11.0.4+6) > > Wednesday, June 12, 2019: Second RDP2 build (tag: jdk-11.0.4+7) > > Wednesday, June 19, 2019: Third RDP2 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) > > > > This allows regular testing earlier in the cycle, but without > > restricting the process down to critical fixes early. > > Sounds like a good suggestion to me as I can see the need to have EA builds early. > I think technically we should then tag in jdk11u-dev/jdk8u-dev until the 29th of May and pull these tags into jdk11u/jdk8u. > We'll have to confirm with ops whether this will correctly resolve the bugs in JBS (e.g. with the right build associated). +1 Thanks, Severin From sgehwolf at redhat.com Thu Apr 25 08:56:46 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 25 Apr 2019 10:56:46 +0200 Subject: [11u, 8u] Updated Wiki pages In-Reply-To: References: Message-ID: On Thu, 2019-04-25 at 06:17 +0000, Langer, Christoph wrote: > The rest of the information should be pretty up to date. I added a > ?Releases? section with links (to source, binaries, filters etc.) for > the April releases 8u212 and 11.0.3. I think the binary release links should point to: https://adoptopenjdk.net/upstream.html It would remove the need to update yet another page when releases are being cut. Or perhaps we should create a wiki page detailing which build the user is supposed to download for a specific release and explain how to verify the GPG signature. Thoughts? Thanks, Severin From christoph.langer at sap.com Thu Apr 25 09:15:06 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 25 Apr 2019 09:15:06 +0000 Subject: [8u] 8205916: [test] Fix jdk/tools/launcher/RunpathTest to handle both, RPATH and RUNPATH In-Reply-To: References: Message-ID: Hi, thanks for doing this backport. It would be appreciated if you could add a Fix Request comment to the Bug, e.g. referring to this review thread and/or adding a short comment why this patch shall be backported (just as you've written below). Best regards Christoph > -----Original Message----- > From: jdk8u-dev On Behalf Of Liu, > Xin > Sent: Donnerstag, 25. April 2019 03:34 > To: jdk8u-dev at openjdk.java.net > Subject: [DMARC FAILURE] [8u] 8205916: [test] Fix > jdk/tools/launcher/RunpathTest to handle both, RPATH and RUNPATH > > Hi, Reviewers, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8205916 > Webrev: https://cr.openjdk.java.net/~xliu/8205916/webrev.00/ > > Some systems, including AmazonLinux , choose to generate RUNPATH over > RPATH. > We have to apply this patch to pass jtreg tests. The backport patch applies > clearly. > > Thanks, > --lx > From christoph.langer at sap.com Thu Apr 25 09:40:00 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 25 Apr 2019 09:40:00 +0000 Subject: 8u212 missing fixes In-Reply-To: <683d238d-feba-ec74-c36e-a09ec02e0a5d@redhat.com> References: <683d238d-feba-ec74-c36e-a09ec02e0a5d@redhat.com> Message-ID: Hi Paul, Andrew, > On 24/04/2019 16:07, Hohensee, Paul wrote: > > From Oracle?s 8u211 release notes at > > https://www.oracle.com/technetwork/java/javase/2col/8u211-bugfixes- > 5292912.html, > > this issue > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8129988: JSSE should create a > > single instance of the cacerts KeyStore > > > > > > > > was in Oracle?s 8u211, but not in OpenJDK 8u212. I?ve just pushed a > > backport to jdk8u-dev. > > > > > > Yes, as I mentioned when approving the 8u request, this seems to have > slipped through because it was marked as fixed in 8u202, but in a BPR > which didn't make OpenJDK. That suggests a flaw in the filter we used. I > don't know if it's worth rectifying now, as it only applies to the > crossover phase. Maybe something to bear in mind if we end up > maintaining OpenJDK 14 or something. I've had a closer look to the filters. It seems that changes being part of 8u202 b31 have never made it to the OpenJDK repo while the filter assumed so. I've updated the filters to account for backports being integrated in b31+ builds. The 8u212 filter now shows 7 items: https://bugs.openjdk.java.net/issues/?filter=36394 The 8u222 filter also includes these items now (That is, 6 items because you pushed JDK-8129988): https://bugs.openjdk.java.net/issues/?filter=36456 With that, we should be on the safe side now and get everything into OpenJDK8u222 in time. Best regards Christoph From christoph.langer at sap.com Thu Apr 25 10:42:11 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 25 Apr 2019 10:42:11 +0000 Subject: [11u, 8u] Updated Wiki pages In-Reply-To: References: Message-ID: Hi Severin, my thought was to link to the exact release build. As far as I understand, https://adoptopenjdk.net/upstream.html will always show the latest build. When a release is done, the information in the Wiki needs to be updated anyway. Best regards Christoph > -----Original Message----- > From: Severin Gehwolf > Sent: Donnerstag, 25. April 2019 10:57 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net; jdk8u-dev at openjdk.java.net > Subject: Re: [11u, 8u] Updated Wiki pages > > On Thu, 2019-04-25 at 06:17 +0000, Langer, Christoph wrote: > > The rest of the information should be pretty up to date. I added a > > ?Releases? section with links (to source, binaries, filters etc.) for > > the April releases 8u212 and 11.0.3. > > I think the binary release links should point to: > https://adoptopenjdk.net/upstream.html > > It would remove the need to update yet another page when releases are > being cut. > > Or perhaps we should create a wiki page detailing which build the user > is supposed to download for a specific release and explain how to > verify the GPG signature. > > Thoughts? > > Thanks, > Severin From sgehwolf at redhat.com Thu Apr 25 11:52:19 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 25 Apr 2019 13:52:19 +0200 Subject: [11u, 8u] Updated Wiki pages In-Reply-To: References: Message-ID: Hi Christoph, On Thu, 2019-04-25 at 10:42 +0000, Langer, Christoph wrote: > Hi Severin, > > my thought was to link to the exact release build. As far as I > understand, https://adoptopenjdk.net/upstream.html will always show > the latest build. OK, I thought so. It's OK, I guess and seems to work nicely for archived wiki pages too (if that ever happens). > When a release is done, the information in the Wiki needs to be > updated anyway. Fair point. Thanks, Severin > Best regards > Christoph > > > -----Original Message----- > > From: Severin Gehwolf > > Sent: Donnerstag, 25. April 2019 10:57 > > To: Langer, Christoph ; jdk-updates- > > dev at openjdk.java.net; jdk8u-dev at openjdk.java.net > > Subject: Re: [11u, 8u] Updated Wiki pages > > > > On Thu, 2019-04-25 at 06:17 +0000, Langer, Christoph wrote: > > > The rest of the information should be pretty up to date. I added > > > a > > > ?Releases? section with links (to source, binaries, filters etc.) > > > for > > > the April releases 8u212 and 11.0.3. > > > > I think the binary release links should point to: > > https://adoptopenjdk.net/upstream.html > > > > It would remove the need to update yet another page when releases > > are > > being cut. > > > > Or perhaps we should create a wiki page detailing which build the > > user > > is supposed to download for a specific release and explain how to > > verify the GPG signature. > > > > Thoughts? > > > > Thanks, > > Severin From epeterson at interactivebrokers.com Thu Apr 25 12:21:32 2019 From: epeterson at interactivebrokers.com (Eric Peterson) Date: Thu, 25 Apr 2019 12:21:32 +0000 Subject: 8u212 missing fixes In-Reply-To: References: <683d238d-feba-ec74-c36e-a09ec02e0a5d@redhat.com> Message-ID: On Apr 25, 2019, at 5:40 AM, Langer, Christoph > wrote: Hi Paul, Andrew, On 24/04/2019 16:07, Hohensee, Paul wrote: From Oracle?s 8u211 release notes at https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.oracle.com%2Ftechnetwork%2Fjava%2Fjavase%2F2col%2F8u211-bugfixes-&data=01%7C01%7Cepeterson%40interactivebrokers.com%7Cc2da785c1fc14a47932a08d6c9621884%7C7abd04ef837d48e69ba869d84f65a110%7C0&sdata=T6kmuEBv1RIedFsSAGaFxGCiyuz6nryPK9n6b0gLY60%3D&reserved=0 5292912.html, this issue https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8129988&data=01%7C01%7Cepeterson%40interactivebrokers.com%7Cc2da785c1fc14a47932a08d6c9621884%7C7abd04ef837d48e69ba869d84f65a110%7C0&sdata=KUHtpnm0pdXlfLdcW14xIN8APur%2FT2yIwmTKQXNrGzw%3D&reserved=0: JSSE should create a single instance of the cacerts KeyStore was in Oracle?s 8u211, but not in OpenJDK 8u212. I?ve just pushed a backport to jdk8u-dev. Yes, as I mentioned when approving the 8u request, this seems to have slipped through because it was marked as fixed in 8u202, but in a BPR which didn't make OpenJDK. That suggests a flaw in the filter we used. I don't know if it's worth rectifying now, as it only applies to the crossover phase. Maybe something to bear in mind if we end up maintaining OpenJDK 14 or something. I've had a closer look to the filters. It seems that changes being part of 8u202 b31 have never made it to the OpenJDK repo while the filter assumed so. I've updated the filters to account for backports being integrated in b31+ builds. The 8u212 filter now shows 7 items: https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fissues%2F%3Ffilter%3D36394&data=01%7C01%7Cepeterson%40interactivebrokers.com%7Cc2da785c1fc14a47932a08d6c9621884%7C7abd04ef837d48e69ba869d84f65a110%7C0&sdata=6ARzhKAJY%2FUEgEEfqIaKKqdxqMI5xqOXLoEWleIsd%2Bs%3D&reserved=0 The 8u222 filter also includes these items now (That is, 6 items because you pushed JDK-8129988): https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fissues%2F%3Ffilter%3D36456&data=01%7C01%7Cepeterson%40interactivebrokers.com%7Cc2da785c1fc14a47932a08d6c9621884%7C7abd04ef837d48e69ba869d84f65a110%7C0&sdata=lwICzparu2PLr8R5yU76VpxHMTEUsGgIthwg8UJWS1Q%3D&reserved=0 The recent OpenJDK 8u212 release mentioned fixes for three CVEs: * S8211936, CVE-2019-2602: Better String parsing * S8218453, CVE-2019-2684: More dynamic RMI interactions * S8219066, CVE-2019-2698: Fuzzing TrueType fonts: setCurrGlyphID() But the Oracle 8u212 release mentions two additional fixed CVEs: * CVE-2019-2699 * CVE-2019-2697 Was OpenJDK 8u212 missing fixes for those vulnerabilities? Or perhaps they were just inadvertently left out of the release notes, or did not need to be applied? I tried to check on the "missing" fixes using the JBS filters given above, but they require a login. ?Eric From epeterson at interactivebrokers.com Thu Apr 25 12:35:46 2019 From: epeterson at interactivebrokers.com (Eric Peterson) Date: Thu, 25 Apr 2019 12:35:46 +0000 Subject: [11u, 8u] Updated Wiki pages In-Reply-To: References: Message-ID: As a new member of the community, I found those pages to be very helpful! Thanks Christoph. One thing that would be helpful is a glossary. There are many acronyms floating around and it can sometimes be hard to figure out what they are. For instance: GA - General Availability (?) CPU - Critical Patch Update JBS - JDK Bug System BPR - ? RDP1/2 - ? CSR - ? Perhaps such a thing exists already and I just haven't come across it. Also an explanation of the versioning scheme somewhere would be helpful. Versions 11+ seem to use fairly standard semver, but 8 has a custom scheme that I still don't quite understand. I found a Wikipedia page [0] and Oracle page [1] on the subject, but they don't explain why the update number increments by 10 each quarter (192 => 202 => 212 etc.) Thanks! Eric [0] https://en.wikipedia.org/wiki/Java_version_history#Java_8_updates [1] https://www.oracle.com/technetwork/java/javase/jdk8-naming-2157130.html > On Apr 25, 2019, at 2:17 AM, Langer, Christoph wrote: > > Hi, > > I have now finished an overhaul of the Wiki pages for OpenJDK 8 [0] and 11 [1] updates. I implemented some feedback that I?ve gotten. > > The main goal for the entry pages is to have all important information at hand while also helping (new) contributors to get an understanding of what to do if they were to contribute. > > So I extracted technical/process detail information to separate pages [2], [3] and link to it from the ?General information? section. I enriched the technical/process detail pages with a checklist for things to do in the release cycle of an update release to be used by release engineers. This is still work in progress. > I also added a small section about ?Contributing? which points to a more detailed recipe of things to do [4] (suggested by Aleksey). > > The rest of the information should be pretty up to date. I added a ?Releases? section with links (to source, binaries, filters etc.) for the April releases 8u212 and 11.0.3. > > Any feedback is welcome. ?? > > Thanks > Christoph > > [0] https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.openjdk.java.net%2Fdisplay%2Fjdk8u&data=01%7C01%7Cepeterson%40interactivebrokers.com%7Ca530ff117d69422281f108d6c945c0b5%7C7abd04ef837d48e69ba869d84f65a110%7C0&sdata=dhkIhode4Wt7KaqACTkaUYf%2Fm%2FX%2BJury9HrbsteThWA%3D&reserved=0 > [1] https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.openjdk.java.net%2Fdisplay%2FJDKUpdates%2FJDK11u&data=01%7C01%7Cepeterson%40interactivebrokers.com%7Ca530ff117d69422281f108d6c945c0b5%7C7abd04ef837d48e69ba869d84f65a110%7C0&sdata=pJN9xQcKw6TUoD2pYp3c0PhILmELgLJZqi7W%2BGwvnR0%3D&reserved=0 > [2] https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.openjdk.java.net%2Fdisplay%2FJDKUpdates%2FDetailed%2BProcess%2BDescription&data=01%7C01%7Cepeterson%40interactivebrokers.com%7Ca530ff117d69422281f108d6c945c0b5%7C7abd04ef837d48e69ba869d84f65a110%7C0&sdata=l3efCNHxtOyjTSvz9zqYXE7kk%2BCxOr0i52fYa3K2Fys%3D&reserved=0 > [3] https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.openjdk.java.net%2Fdisplay%2Fjdk8u%2FDetailed%2BProcess%2BDescription&data=01%7C01%7Cepeterson%40interactivebrokers.com%7Ca530ff117d69422281f108d6c945c0b5%7C7abd04ef837d48e69ba869d84f65a110%7C0&sdata=j2NlAshITRwa%2Fi5B7sQHPLXpS%2F6rB%2FXNwrPLQ0cFoiw%3D&reserved=0 > [4] https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.openjdk.java.net%2Fdisplay%2FJDKUpdates%2FHow%2Bto%2Bcontribute%2Ba%2Bfix&data=01%7C01%7Cepeterson%40interactivebrokers.com%7Ca530ff117d69422281f108d6c945c0b5%7C7abd04ef837d48e69ba869d84f65a110%7C0&sdata=tIIzUwOhTf9%2FfmGmSPain8y6o%2BctKvesC5g92ERYBWI%3D&reserved=0 > From gil at azul.com Thu Apr 25 12:59:00 2019 From: gil at azul.com (Gil Tene) Date: Thu, 25 Apr 2019 12:59:00 +0000 Subject: 8u212 missing fixes In-Reply-To: References: <683d238d-feba-ec74-c36e-a09ec02e0a5d@redhat.com> , Message-ID: <7BEF16CB-D8B2-4455-8E42-3958D82FB593@azul.com> > On Apr 25, 2019, at 5:22 AM, Eric Peterson wrote: > ... > The recent OpenJDK 8u212 release mentioned fixes for three CVEs: > > * S8211936, CVE-2019-2602: Better String parsing > * S8218453, CVE-2019-2684: More dynamic RMI interactions > * S8219066, CVE-2019-2698: Fuzzing TrueType fonts: setCurrGlyphID() > > But the Oracle 8u212 release mentions two additional fixed CVEs: > > * CVE-2019-2699 > * CVE-2019-2697 > > Was OpenJDK 8u212 missing fixes for those vulnerabilities? Or perhaps they were just inadvertently left out of the release notes, or did not need to be applied? To my knowledge: CVE-2019-2699 was related to an artifact of choices made in the build environment, and as such existed in some 8u distros but not in others. So it is not a source-code-project thing (but individual distros have dealt with it and may want to mention it). CVE-2019-2697 was specific to Oracle JDK 8 code that is not included in OpenJDK 8u, so it is not applicable to OpenJDK 8u. ? Gil From christoph.langer at sap.com Thu Apr 25 13:04:20 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 25 Apr 2019 13:04:20 +0000 Subject: [11u, 8u] Updated Wiki pages In-Reply-To: References: Message-ID: Hi Eric, thanks for the feedback. ?? I can understand that something like a glossary would be helpful if you're not into all these abbreviations. I even find myself contemplating about things like "What again does RDP mean?" etc. So, let's see if I can add something like this in a later update. As for the update versioning scheme: I don't know of a link that explains the numbering for JDK8u. I think it's incremented by ten each quarter, such as 802, 812, 822 etc. Oracle also does security-only fixes, known as CPU which end with the digit '1', e.g. 801, 811, 821. But for OpenJDK we decided to combine these and don't ship versions with only security fixes. Regarding Java version 9+: There is a JEP about this topic: https://openjdk.java.net/jeps/223 Best regards Christoph > -----Original Message----- > From: Eric Peterson > Sent: Donnerstag, 25. April 2019 14:36 > To: Langer, Christoph > Cc: jdk-updates-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net > Subject: Re: [11u, 8u] Updated Wiki pages > > As a new member of the community, I found those pages to be very helpful! > Thanks Christoph. > > One thing that would be helpful is a glossary. There are many acronyms > floating around and it can sometimes be hard to figure out what they are. For > instance: > GA - General Availability (?) > CPU - Critical Patch Update > JBS - JDK Bug System > BPR - ? > RDP1/2 - ? > CSR - ? > Perhaps such a thing exists already and I just haven't come across it. > > Also an explanation of the versioning scheme somewhere would be helpful. > Versions 11+ seem to use fairly standard semver, but 8 has a custom scheme > that I still don't quite understand. I found a Wikipedia page [0] and Oracle > page [1] on the subject, but they don't explain why the update number > increments by 10 each quarter (192 => 202 => 212 etc.) > > Thanks! > Eric > > [0] https://en.wikipedia.org/wiki/Java_version_history#Java_8_updates > [1] https://www.oracle.com/technetwork/java/javase/jdk8-naming- > 2157130.html > > > > On Apr 25, 2019, at 2:17 AM, Langer, Christoph > wrote: > > > > Hi, > > > > I have now finished an overhaul of the Wiki pages for OpenJDK 8 [0] and 11 > [1] updates. I implemented some feedback that I?ve gotten. > > > > The main goal for the entry pages is to have all important information at > hand while also helping (new) contributors to get an understanding of what > to do if they were to contribute. > > > > So I extracted technical/process detail information to separate pages [2], > [3] and link to it from the ?General information? section. I enriched the > technical/process detail pages with a checklist for things to do in the release > cycle of an update release to be used by release engineers. This is still work > in progress. > > I also added a small section about ?Contributing? which points to a more > detailed recipe of things to do [4] (suggested by Aleksey). > > > > The rest of the information should be pretty up to date. I added a > ?Releases? section with links (to source, binaries, filters etc.) for the April > releases 8u212 and 11.0.3. > > > > Any feedback is welcome. ?? > > > > Thanks > > Christoph > > > > [0] > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki. > openjdk.java.net%2Fdisplay%2Fjdk8u&data=01%7C01%7Cepeterson%4 > 0interactivebrokers.com%7Ca530ff117d69422281f108d6c945c0b5%7C7abd04 > ef837d48e69ba869d84f65a110%7C0&sdata=dhkIhode4Wt7KaqACTkaUY > f%2Fm%2FX%2BJury9HrbsteThWA%3D&reserved=0 > > [1] > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki. > openjdk.java.net%2Fdisplay%2FJDKUpdates%2FJDK11u&data=01%7C01 > %7Cepeterson%40interactivebrokers.com%7Ca530ff117d69422281f108d6c94 > 5c0b5%7C7abd04ef837d48e69ba869d84f65a110%7C0&sdata=pJN9xQcK > w6TUoD2pYp3c0PhILmELgLJZqi7W%2BGwvnR0%3D&reserved=0 > > [2] > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki. > openjdk.java.net%2Fdisplay%2FJDKUpdates%2FDetailed%2BProcess%2BDes > cription&data=01%7C01%7Cepeterson%40interactivebrokers.com%7Ca > 530ff117d69422281f108d6c945c0b5%7C7abd04ef837d48e69ba869d84f65a110 > %7C0&sdata=l3efCNHxtOyjTSvz9zqYXE7kk%2BCxOr0i52fYa3K2Fys%3D& > amp;reserved=0 > > [3] > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki. > openjdk.java.net%2Fdisplay%2Fjdk8u%2FDetailed%2BProcess%2BDescriptio > n&data=01%7C01%7Cepeterson%40interactivebrokers.com%7Ca530ff1 > 17d69422281f108d6c945c0b5%7C7abd04ef837d48e69ba869d84f65a110%7C0& > amp;sdata=j2NlAshITRwa%2Fi5B7sQHPLXpS%2F6rB%2FXNwrPLQ0cFoiw%3D > &reserved=0 > > [4] > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki. > openjdk.java.net%2Fdisplay%2FJDKUpdates%2FHow%2Bto%2Bcontribute% > 2Ba%2Bfix&data=01%7C01%7Cepeterson%40interactivebrokers.com%7 > Ca530ff117d69422281f108d6c945c0b5%7C7abd04ef837d48e69ba869d84f65a1 > 10%7C0&sdata=tIIzUwOhTf9%2FfmGmSPain8y6o%2BctKvesC5g92ERYB > WI%3D&reserved=0 > > From gnu.andrew at redhat.com Thu Apr 25 15:14:12 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 25 Apr 2019 16:14:12 +0100 Subject: [8u] 8205916: [test] Fix jdk/tools/launcher/RunpathTest to handle both, RPATH and RUNPATH In-Reply-To: References: Message-ID: On 25/04/2019 10:15, Langer, Christoph wrote: > Hi, > > thanks for doing this backport. > > It would be appreciated if you could add a Fix Request comment to the Bug, e.g. referring to this review thread and/or adding a short comment why this patch shall be backported (just as you've written below). > > Best regards > Christoph > A link to this thread should be sufficient, which I've now added. This is the downside of switching to the bug database for some elements, but still having reviews on mailing lists. -- 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 Apr 25 15:15:14 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 25 Apr 2019 16:15:14 +0100 Subject: 8u212 missing fixes In-Reply-To: References: <683d238d-feba-ec74-c36e-a09ec02e0a5d@redhat.com> Message-ID: <67690451-ca43-6ada-8fc4-072574809bb9@redhat.com> On 25/04/2019 10:40, Langer, Christoph wrote: > Hi Paul, Andrew, > >> On 24/04/2019 16:07, Hohensee, Paul wrote: >>> From Oracle?s 8u211 release notes at >>> https://www.oracle.com/technetwork/java/javase/2col/8u211-bugfixes- >> 5292912.html, >>> this issue >>> >>> >>> >>> https://bugs.openjdk.java.net/browse/JDK-8129988: JSSE should create a >>> single instance of the cacerts KeyStore >>> >>> >>> >>> was in Oracle?s 8u211, but not in OpenJDK 8u212. I?ve just pushed a >>> backport to jdk8u-dev. >>> >>> >> >> Yes, as I mentioned when approving the 8u request, this seems to have >> slipped through because it was marked as fixed in 8u202, but in a BPR >> which didn't make OpenJDK. That suggests a flaw in the filter we used. I >> don't know if it's worth rectifying now, as it only applies to the >> crossover phase. Maybe something to bear in mind if we end up >> maintaining OpenJDK 14 or something. > > I've had a closer look to the filters. It seems that changes being part of 8u202 b31 have never made it to the OpenJDK repo while the filter assumed so. I've updated the filters to account for backports being integrated in b31+ builds. > > The 8u212 filter now shows 7 items: https://bugs.openjdk.java.net/issues/?filter=36394 > The 8u222 filter also includes these items now (That is, 6 items because you pushed JDK-8129988): https://bugs.openjdk.java.net/issues/?filter=36456 > > With that, we should be on the safe side now and get everything into OpenJDK8u222 in time. > > Best regards > Christoph > Thanks for this. Those filters make my head ache :) -- 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 Thu Apr 25 15:23:04 2019 From: stooke at redhat.com (Simon Tooke) Date: Thu, 25 Apr 2019 11:23:04 -0400 Subject: [8u-dev] RFR: JDK-8222975: Fix 'release' file to reflect actual repo checkin used to compile JDK In-Reply-To: References: <1f857eb6-be66-c552-3333-acac64ae0093@redhat.com> Message-ID: On 4/25/2019 12:29 AM, Andrew John Hughes wrote: > > On 24/04/2019 20:29, Simon Tooke wrote: >> Hi, >> >> In the process of the latest CPU, I found the 'release' file differed >> between the Linux and Windows built images, and tracked it down to the >> use of 'hg tip' instead of 'hg id'. >> >> As luck would have it, this was previously reported (JDK-8031567) and >> fixed in JDK 9.? >> >> Rather than backport the entire PR to jdk8u, I propose only enough to >> fix the actual problem; replacing the calls to 'hg tip' with calls to >> 'hg id -i'. >> >> Original JBS: https://bugs.openjdk.java.net/browse/JDK-8031567 >> >> Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8031567/ >> >> I'm open to a full backport, but wanted to minimize perturbation of 8u.? >> If this is misguided, please correct me... >> >> Thank you for your time, >> >> -Simon >> >> > Given that 8031567 is an enhancement which rewrites the offending code > altogether, I don't think a smaller, different change should really go > in under the same ID. It will make it look like 8031567 is present in > OpenJDK 8, but none of the actual code that is in 9+ will be there. > > I'd prefer a full backport of 8031567 for consistency with 9+, but the > current webrev is fine too, as long as it is committed under its own ID. That makes sense.? I've created a new bug entry: Issue: https://bugs.openjdk.java.net/browse/JDK-8222975 Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8222975/ -Simon From gnu.andrew at redhat.com Thu Apr 25 16:19:36 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 25 Apr 2019 17:19:36 +0100 Subject: [8u-dev] RFR: JDK-8222975: Fix 'release' file to reflect actual repo checkin used to compile JDK In-Reply-To: References: <1f857eb6-be66-c552-3333-acac64ae0093@redhat.com> Message-ID: On 25/04/2019 16:23, Simon Tooke wrote: > > On 4/25/2019 12:29 AM, Andrew John Hughes wrote: >> >> On 24/04/2019 20:29, Simon Tooke wrote: >>> Hi, >>> >>> In the process of the latest CPU, I found the 'release' file differed >>> between the Linux and Windows built images, and tracked it down to the >>> use of 'hg tip' instead of 'hg id'. >>> >>> As luck would have it, this was previously reported (JDK-8031567) and >>> fixed in JDK 9.? >>> >>> Rather than backport the entire PR to jdk8u, I propose only enough to >>> fix the actual problem; replacing the calls to 'hg tip' with calls to >>> 'hg id -i'. >>> >>> Original JBS: https://bugs.openjdk.java.net/browse/JDK-8031567 >>> >>> Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8031567/ >>> >>> I'm open to a full backport, but wanted to minimize perturbation of 8u.? >>> If this is misguided, please correct me... >>> >>> Thank you for your time, >>> >>> -Simon >>> >>> >> Given that 8031567 is an enhancement which rewrites the offending code >> altogether, I don't think a smaller, different change should really go >> in under the same ID. It will make it look like 8031567 is present in >> OpenJDK 8, but none of the actual code that is in 9+ will be there. >> >> I'd prefer a full backport of 8031567 for consistency with 9+, but the >> current webrev is fine too, as long as it is committed under its own ID. > > That makes sense.? I've created a new bug entry: > > Issue: https://bugs.openjdk.java.net/browse/JDK-8222975 > > Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8222975/ > > -Simon > > Ok, change looks good to me. Flag the bug with jdk8u-fix-request and I'll approve it. Do you have push rights or does someone need to do so on your behalf? 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 Apr 25 16:44:20 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 25 Apr 2019 17:44:20 +0100 Subject: 8u212 missing fixes In-Reply-To: <7BEF16CB-D8B2-4455-8E42-3958D82FB593@azul.com> References: <683d238d-feba-ec74-c36e-a09ec02e0a5d@redhat.com> <7BEF16CB-D8B2-4455-8E42-3958D82FB593@azul.com> Message-ID: <07704ee6-f779-cccb-710e-8a96c7de0041@redhat.com> On 25/04/2019 13:59, Gil Tene wrote: > >> On Apr 25, 2019, at 5:22 AM, Eric Peterson wrote: >> ... >> The recent OpenJDK 8u212 release mentioned fixes for three CVEs: >> >> * S8211936, CVE-2019-2602: Better String parsing >> * S8218453, CVE-2019-2684: More dynamic RMI interactions >> * S8219066, CVE-2019-2698: Fuzzing TrueType fonts: setCurrGlyphID() >> >> But the Oracle 8u212 release mentions two additional fixed CVEs: >> >> * CVE-2019-2699 >> * CVE-2019-2697 >> >> Was OpenJDK 8u212 missing fixes for those vulnerabilities? Or perhaps they were just inadvertently left out of the release notes, or did not need to be applied? > > To my knowledge: > > CVE-2019-2699 was related to an artifact of choices made in the build environment, and as such existed in some 8u distros but not in others. So it is not a source-code-project thing (but individual distros have dealt with it and may want to mention it). > > CVE-2019-2697 was specific to Oracle JDK 8 code that is not included in OpenJDK 8u, so it is not applicable to OpenJDK 8u. > > ? Gil > Yeah, neither are applicable to OpenJDK. CVE-2019-2699 is a Windows-only issue relating to an old version of msvrcr100.dll (10.00.40219.1) being included with some OpenJDK-based binaries for Windows. They are susceptible to [0]. This depends on the build environment used to create the Windows binary, so there is no fix in the OpenJDK code base and some binaries weren't affected (e.g. Red Hat's Windows binaries) CVE-2019-2697, as with some past CVEs, covers proprietary code that Oracle add on top of OpenJDK, especially in older releases. In this case, it's the t2k library and only on Oracle's 7 & 8 JDKs. [1] [0] https://docs.microsoft.com/en-us/security-updates/SecurityBulletins/2011/ms11-025 [1] https://packetstormsecurity.com/files/cve/CVE-2019-2697 -- 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 Thu Apr 25 16:50:30 2019 From: xxinliu at amazon.com (Liu, Xin) Date: Thu, 25 Apr 2019 16:50:30 +0000 Subject: [8u] 8205916: [test] Fix jdk/tools/launcher/RunpathTest to handle both, RPATH and RUNPATH In-Reply-To: References: Message-ID: Thanks, Andrew and Christoph, Thanks for the head-up. I see Andrew has pasted the link for this code review. Paul will push it on behalf of me. Thanks, --lx ?On 4/25/19, 8:15 AM, "jdk8u-dev on behalf of Andrew John Hughes" wrote: On 25/04/2019 10:15, Langer, Christoph wrote: > Hi, > > thanks for doing this backport. > > It would be appreciated if you could add a Fix Request comment to the Bug, e.g. referring to this review thread and/or adding a short comment why this patch shall be backported (just as you've written below). > > Best regards > Christoph > A link to this thread should be sufficient, which I've now added. This is the downside of switching to the bug database for some elements, but still having reviews on mailing lists. -- 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 philip.race at oracle.com Thu Apr 25 16:55:55 2019 From: philip.race at oracle.com (Phil Race) Date: Thu, 25 Apr 2019 09:55:55 -0700 Subject: This (and other) bug updates are incorrect. In-Reply-To: References: Message-ID: Hi Alexey, "8" specifically means 8 GA. It does not mean "some release in the 8 train" If you read https://bugs.openjdk.java.net/browse/JDK-8218605 you will see that it says this issue was introduced in 8u211 So when you added "8" you are saying that this bug affects a release before the cause was introduced, which is plainly impossible. In fact this bug is about a detail of a feature which got backported? very recently so it really is wrong to mark it as affects 8. I think you need to explain what you are trying to achieve and then maybe the previous Oracle 8u maintainers can explain how you should actually be doing this and help you correct the various bugs that are now incorrectly marked as affecting 8 GA. -phil. -------- Forwarded Message -------- Subject: [JBS] {Updated} (JDK-8218605) Startup Splash Screen of SwingSet2 flashes in smaller coordinates before appearing in the final size Date: Thu, 25 Apr 2019 10:09:01 +0000 (UTC) From: Aleksey Shipilev (JBS) To: philip.race at oracle.com Message Title Aleksey Shipilev *updated* an issue JDK / Bug JDK-8218605 Startup Splash Screen of SwingSet2 flashes in smaller coordinates before appearing in the final size Change By: Aleksey Shipilev Affects Version/s: 8 Add Comment Add Comment This message was sent by Atlassian Jira (v7.13.0#713000-sha1:fbf4068) Atlassian logo From stooke at redhat.com Thu Apr 25 16:57:50 2019 From: stooke at redhat.com (Simon Tooke) Date: Thu, 25 Apr 2019 12:57:50 -0400 Subject: [8u-dev] RFR: JDK-8222975: Fix 'release' file to reflect actual repo checkin used to compile JDK In-Reply-To: References: <1f857eb6-be66-c552-3333-acac64ae0093@redhat.com> Message-ID: <99670eb0-1ec3-1c07-8f6b-4d10413f599e@redhat.com> On 4/25/2019 12:19 PM, Andrew John Hughes wrote: > On 25/04/2019 16:23, Simon Tooke wrote: >> On 4/25/2019 12:29 AM, Andrew John Hughes wrote: >>> On 24/04/2019 20:29, Simon Tooke wrote: >>>> Hi, >>>> >>>> In the process of the latest CPU, I found the 'release' file differed >>>> between the Linux and Windows built images, and tracked it down to the >>>> use of 'hg tip' instead of 'hg id'. >>>> >>>> As luck would have it, this was previously reported (JDK-8031567) and >>>> fixed in JDK 9.? >>>> >>>> Rather than backport the entire PR to jdk8u, I propose only enough to >>>> fix the actual problem; replacing the calls to 'hg tip' with calls to >>>> 'hg id -i'. >>>> >>>> Original JBS: https://bugs.openjdk.java.net/browse/JDK-8031567 >>>> >>>> Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8031567/ >>>> >>>> I'm open to a full backport, but wanted to minimize perturbation of 8u.? >>>> If this is misguided, please correct me... >>>> >>>> Thank you for your time, >>>> >>>> -Simon >>>> >>>> >>> Given that 8031567 is an enhancement which rewrites the offending code >>> altogether, I don't think a smaller, different change should really go >>> in under the same ID. It will make it look like 8031567 is present in >>> OpenJDK 8, but none of the actual code that is in 9+ will be there. >>> >>> I'd prefer a full backport of 8031567 for consistency with 9+, but the >>> current webrev is fine too, as long as it is committed under its own ID. >> That makes sense.? I've created a new bug entry: >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8222975 >> >> Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8222975/ >> >> -Simon >> >> > Ok, change looks good to me. > > Flag the bug with jdk8u-fix-request and I'll approve it. > > Do you have push rights or does someone need to do so on your behalf? > > Thanks, Thanks for the review! I've flagged the bug as requested, but unfortunately I don't yet have push rights. -simon From shade at redhat.com Thu Apr 25 17:43:31 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 25 Apr 2019 19:43:31 +0200 Subject: This (and other) bug updates are incorrect. In-Reply-To: References: Message-ID: Hi Phil, On 4/25/19 6:55 PM, Phil Race wrote: > "8" specifically means 8 GA. It does not mean "some release in the 8 train" I don't think it means "8 GA", I think it means "some release in the 8 train", see below. > So when you added "8" you are saying that this bug affects a release before > the cause was introduced, which is plainly impossible. > In fact this bug is about a detail of a feature which got backported? very recently > so it really is wrong to mark it as affects 8. > > I think you need to explain what you are trying to achieve and then > maybe the previous Oracle 8u maintainers can explain how you should > actually be doing this and help you correct the various bugs that are > now incorrectly marked as affecting 8 GA. Well, I can explain if you ask nicely :) Here it goes: I think we routinely mark Affected-Version with the major release train: 7, 8, 11, 12, 13, without mentioning the exact version that issue affects. This helps to keep versions list tidy, and automation saner. For example, for the new issues affecting every build up to 8u212, do I have to actually run with all these versions to figure out which version started to fail? This puts too much strain to submitters. It is also inconvenient for most filters and queries that would have to list/wildcard minor versions. My goal is to have backports-monitor to track the release trains status w.r.t. backports. Others also do JIRA queries for the same reason. Using only the major release version is a common practice. Just poking at random issues for client-libs, for example: https://bugs.openjdk.java.net/browse/JDK-8218617 It fixes the bug triggered by JDK-8062164, which went to 8u40. By the "8 specifically means 8 GA" logic, JDK-8218617 should have been marked "8u40". But it is not, in fact history says its original Affected-Versions was "8u202", then it got changed to "8". I can understand why: nobody has time to figure out the minor version where it started to fail, and why would anyone bother? It mostly matters that 8u should get the fix, hence the major version only is mentioned. I believe this is why the overwhelming majority of issues are marked with major version only. For example, again poking randomly: https://bugs.openjdk.java.net/browse/JDK-8222477 (submitted as "8, 12, 13") https://bugs.openjdk.java.net/browse/JDK-8217263 (submitted as "8, 11, 12, 13") https://bugs.openjdk.java.net/browse/JDK-8210863 (submitted as "8, 11, 12") ... Sure, if you know the precise version, you are welcome to put it into Affected-Versions. This does not prevent anyone else to mark it afterwards with the release train. Having "8, 8u202" does not lose any information. Bottom-line: I don't see what is "incorrect" here. -Aleksey From daniel.daugherty at oracle.com Thu Apr 25 18:05:54 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 25 Apr 2019 14:05:54 -0400 Subject: This (and other) bug updates are incorrect. In-Reply-To: References: Message-ID: On 4/25/19 1:43 PM, Aleksey Shipilev wrote: > Hi Phil, > > On 4/25/19 6:55 PM, Phil Race wrote: >> "8" specifically means 8 GA. It does not mean "some release in the 8 train" > I don't think it means "8 GA", I think it means "some release in the 8 train", see below. > >> So when you added "8" you are saying that this bug affects a release before >> the cause was introduced, which is plainly impossible. >> In fact this bug is about a detail of a feature which got backported? very recently >> so it really is wrong to mark it as affects 8. >> >> I think you need to explain what you are trying to achieve and then >> maybe the previous Oracle 8u maintainers can explain how you should >> actually be doing this and help you correct the various bugs that are >> now incorrectly marked as affecting 8 GA. > Well, I can explain if you ask nicely :) Here it goes: > > I think we routinely mark Affected-Version with the major release train: 7, 8, 11, 12, 13, without > mentioning the exact version that issue affects. This helps to keep versions list tidy, and > automation saner. For example, for the new issues affecting every build up to 8u212, do I have to > actually run with all these versions to figure out which version started to fail? This puts too much > strain to submitters. > > It is also inconvenient for most filters and queries that would have to list/wildcard minor > versions. My goal is to have backports-monitor to track the release trains status w.r.t. backports. > Others also do JIRA queries for the same reason. > > Using only the major release version is a common practice. Just poking at random issues for > client-libs, for example: > https://bugs.openjdk.java.net/browse/JDK-8218617 > > It fixes the bug triggered by JDK-8062164, which went to 8u40. By the "8 specifically means 8 GA" > logic, JDK-8218617 should have been marked "8u40". But it is not, in fact history says its original > Affected-Versions was "8u202", then it got changed to "8". I can understand why: nobody has time to > figure out the minor version where it started to fail, and why would anyone bother? > > It mostly matters that 8u should get the fix, hence the major version only is mentioned. I believe > this is why the overwhelming majority of issues are marked with major version only. For example, > again poking randomly: > https://bugs.openjdk.java.net/browse/JDK-8222477 (submitted as "8, 12, 13") > https://bugs.openjdk.java.net/browse/JDK-8217263 (submitted as "8, 11, 12, 13") > https://bugs.openjdk.java.net/browse/JDK-8210863 (submitted as "8, 11, 12") > ... > > Sure, if you know the precise version, you are welcome to put it into Affected-Versions. This does > not prevent anyone else to mark it afterwards with the release train. Having "8, 8u202" does not > lose any information. > > Bottom-line: I don't see what is "incorrect" here. > > -Aleksey > Sorry Aleksey. Version value '8' historically means JDK8-GA. It should only used used for bugs that reproduce with JDK8-GA. If the OpenJDK8u project wants to add an '8u' that means some version after JDK8-GA, then that is fine. Dan From daniel.daugherty at oracle.com Thu Apr 25 18:13:31 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 25 Apr 2019 14:13:31 -0400 Subject: This (and other) bug updates are incorrect. In-Reply-To: References: Message-ID: On 4/25/19 2:05 PM, Daniel D. Daugherty wrote: > On 4/25/19 1:43 PM, Aleksey Shipilev wrote: >> Hi Phil, >> >> On 4/25/19 6:55 PM, Phil Race wrote: >>> ? "8" specifically means 8 GA. It does not mean "some release in the >>> 8 train" >> I don't think it means "8 GA", I think it means "some release in the >> 8 train", see below. >> >>> So when you added "8" you are saying that this bug affects a release >>> before >>> the cause was introduced, which is plainly impossible. >>> In fact this bug is about a detail of a feature which got >>> backported? very recently >>> so it really is wrong to mark it as affects 8. >>> >>> I think you need to explain what you are trying to achieve and then >>> maybe the previous Oracle 8u maintainers can explain how you should >>> actually be doing this and help you correct the various bugs that are >>> now incorrectly marked as affecting 8 GA. >> Well, I can explain if you ask nicely :) Here it goes: >> >> I think we routinely mark Affected-Version with the major release >> train: 7, 8, 11, 12, 13, without >> mentioning the exact version that issue affects. This helps to keep >> versions list tidy, and >> automation saner. For example, for the new issues affecting every >> build up to 8u212, do I have to >> actually run with all these versions to figure out which version >> started to fail? This puts too much >> strain to submitters. >> >> It is also inconvenient for most filters and queries that would have >> to list/wildcard minor >> versions. My goal is to have backports-monitor to track the release >> trains status w.r.t. backports. >> Others also do JIRA queries for the same reason. >> >> Using only the major release version is a common practice. Just >> poking at random issues for >> client-libs, for example: >> ?? https://bugs.openjdk.java.net/browse/JDK-8218617 >> >> It fixes the bug triggered by JDK-8062164, which went to 8u40. By the >> "8 specifically means 8 GA" >> logic, JDK-8218617 should have been marked "8u40". But it is not, in >> fact history says its original >> Affected-Versions was "8u202", then it got changed to "8". I can >> understand why: nobody has time to >> figure out the minor version where it started to fail, and why would >> anyone bother? >> >> It mostly matters that 8u should get the fix, hence the major version >> only is mentioned. I believe >> this is why the overwhelming majority of issues are marked with major >> version only. For example, >> again poking randomly: >> ?? https://bugs.openjdk.java.net/browse/JDK-8222477 (submitted as "8, >> 12, 13") >> ?? https://bugs.openjdk.java.net/browse/JDK-8217263 (submitted as "8, >> 11, 12, 13") >> ?? https://bugs.openjdk.java.net/browse/JDK-8210863 (submitted as "8, >> 11, 12") >> ?? ... >> >> Sure, if you know the precise version, you are welcome to put it into >> Affected-Versions. This does >> not prevent anyone else to mark it afterwards with the release train. >> Having "8, 8u202" does not >> lose any information. >> >> Bottom-line: I don't see what is "incorrect" here. >> >> -Aleksey >> > > Sorry Aleksey. Version value '8' historically means JDK8-GA. It should > only used used for bugs that reproduce with JDK8-GA. If the OpenJDK8u > project wants to add an '8u' that means some version after JDK8-GA, then > that is fine. > > Dan Another way to think about is this: We're having this conversation on the jdk8u-dev at openjdk.java.net alias. We are not having this conversation on the jdk8-dev at openjdk.java.net alias. Why? Because the OpenJDK8 project is done. We now have an OpenJDK8u project... There are a few examples of emails that come in on jdk8-dev at openjdk.java.net where we redirect the folks to jdk8u-dev at openjdk.java.net because the OpenJDK8 project is done. Dan From kevin.rushforth at oracle.com Thu Apr 25 18:30:26 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 25 Apr 2019 11:30:26 -0700 Subject: This (and other) bug updates are incorrect. In-Reply-To: References: Message-ID: On 4/25/2019 11:05 AM, Daniel D. Daugherty wrote: > On 4/25/19 1:43 PM, Aleksey Shipilev wrote: >> Hi Phil, >> >> On 4/25/19 6:55 PM, Phil Race wrote: >>> ? "8" specifically means 8 GA. It does not mean "some release in the >>> 8 train" >> I don't think it means "8 GA", I think it means "some release in the >> 8 train", see below. >> >>> So when you added "8" you are saying that this bug affects a release >>> before >>> the cause was introduced, which is plainly impossible. >>> In fact this bug is about a detail of a feature which got >>> backported? very recently >>> so it really is wrong to mark it as affects 8. >>> >>> I think you need to explain what you are trying to achieve and then >>> maybe the previous Oracle 8u maintainers can explain how you should >>> actually be doing this and help you correct the various bugs that are >>> now incorrectly marked as affecting 8 GA. >> Well, I can explain if you ask nicely :) Here it goes: >> >> I think we routinely mark Affected-Version with the major release >> train: 7, 8, 11, 12, 13, without >> mentioning the exact version that issue affects. This helps to keep >> versions list tidy, and >> automation saner. For example, for the new issues affecting every >> build up to 8u212, do I have to >> actually run with all these versions to figure out which version >> started to fail? This puts too much >> strain to submitters. >> >> It is also inconvenient for most filters and queries that would have >> to list/wildcard minor >> versions. My goal is to have backports-monitor to track the release >> trains status w.r.t. backports. >> Others also do JIRA queries for the same reason. >> >> Using only the major release version is a common practice. Just >> poking at random issues for >> client-libs, for example: >> ?? https://bugs.openjdk.java.net/browse/JDK-8218617 >> >> It fixes the bug triggered by JDK-8062164, which went to 8u40. By the >> "8 specifically means 8 GA" >> logic, JDK-8218617 should have been marked "8u40". But it is not, in >> fact history says its original >> Affected-Versions was "8u202", then it got changed to "8". I can >> understand why: nobody has time to >> figure out the minor version where it started to fail, and why would >> anyone bother? >> >> It mostly matters that 8u should get the fix, hence the major version >> only is mentioned. I believe >> this is why the overwhelming majority of issues are marked with major >> version only. For example, >> again poking randomly: >> ?? https://bugs.openjdk.java.net/browse/JDK-8222477 (submitted as "8, >> 12, 13") >> ?? https://bugs.openjdk.java.net/browse/JDK-8217263 (submitted as "8, >> 11, 12, 13") >> ?? https://bugs.openjdk.java.net/browse/JDK-8210863 (submitted as "8, >> 11, 12") >> ?? ... >> >> Sure, if you know the precise version, you are welcome to put it into >> Affected-Versions. This does >> not prevent anyone else to mark it afterwards with the release train. >> Having "8, 8u202" does not >> lose any information. >> >> Bottom-line: I don't see what is "incorrect" here. >> >> -Aleksey >> > > Sorry Aleksey. Version value '8' historically means JDK8-GA. It should > only used used for bugs that reproduce with JDK8-GA. Exactly. > If the OpenJDK8u > project wants to add an '8u' that means some version after JDK8-GA, then > that is fine. Would the existing "openjdk8u" release version work? If not, then adding a release value of "8u" seems like a reasonable compromise. -- Kevin From shade at redhat.com Thu Apr 25 18:47:14 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 25 Apr 2019 20:47:14 +0200 Subject: This (and other) bug updates are incorrect. In-Reply-To: References: Message-ID: On 4/25/19 8:13 PM, Daniel D. Daugherty wrote: >> Sorry Aleksey. Version value '8' historically means JDK8-GA. It should >> only used used for bugs that reproduce with JDK8-GA. If the OpenJDK8u >> project wants to add an '8u' that means some version after JDK8-GA, then >> that is fine. My problem with "historically" is that it is very open to interpretation. What you are saying implies that every bug that has affectedVersion = 8 is checked to be reproduce-able with 8 GA. Which does not ring true, since submitters usually check only with the some current version of 8u, and I see that "8" serves as blanket "some (presumably latest) version of 8" designator for many recent issues. That's how people use it today, no matter the history. I think that is a fair compromise: if you know the exact version the issue appeared in, put in the exact version. But if you don't, you are not pressured to figure it out, put the blanket major version, and move on. Having both does not look incorrect. If using 7, 8, 11, 12, 13 as blanket designators is incorrect, then it is incorrect in many places around JBS, and you have to go and say it somewhere, *and* provide consistent replacements for all of them. Changing it only for 8u does not bring any added consistency. The closest alternative I can see is 7-pool, 8-pool, 11-pool, 12-pool, 13-pool, etc, but I don't know their exact meaning. > Another way to think about is this: > > We're having this conversation on the jdk8u-dev at openjdk.java.net alias. > We are not having this conversation on the jdk8-dev at openjdk.java.net alias. > > Why? Because the OpenJDK8 project is done. We now have an OpenJDK8u project... That's a weird argument, to be honest. By that argument, we have to have 11u, 12u, etc as JIRA versions, which we don't. -Aleksey From philip.race at oracle.com Thu Apr 25 18:53:25 2019 From: philip.race at oracle.com (Philip Race) Date: Thu, 25 Apr 2019 11:53:25 -0700 Subject: This (and other) bug updates are incorrect. In-Reply-To: References: Message-ID: <5CC20225.7040006@oracle.com> A lot of 8[u] bug reports originate from some migrating from the 7 train to the 8 train. The example you cited earlier https://bugs.openjdk.java.net/browse/JDK-8218617 is one where you can see the submitter is comparing 7[u] and 8[u] behaviour and submitted against 8 without really knowing. This *should* have been fixed by the engineer who evaluated it. That it was not fixed and that there remains a mistake in the release value does not make it policy .. "8" means "8.0.0" if you think about it in the JDK 9 + nomenclature. -phil. On 4/25/19, 11:47 AM, Aleksey Shipilev wrote: > My problem with "historically" is that it is very open to interpretation. What you are saying > implies that every bug that has affectedVersion = 8 is checked to be reproduce-able with 8 GA. Which > does not ring true, since submitters usually check only with the some current version of 8u, and I > see that "8" serves as blanket "some (presumably latest) version of 8" designator for many recent > issues. From daniel.daugherty at oracle.com Thu Apr 25 19:02:47 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 25 Apr 2019 15:02:47 -0400 Subject: This (and other) bug updates are incorrect. In-Reply-To: References: Message-ID: <90019867-8351-ef57-0c8e-84d52aa5a4cb@oracle.com> On 4/25/19 2:47 PM, Aleksey Shipilev wrote: > On 4/25/19 8:13 PM, Daniel D. Daugherty wrote: >>> Sorry Aleksey. Version value '8' historically means JDK8-GA. It should >>> only used used for bugs that reproduce with JDK8-GA. If the OpenJDK8u >>> project wants to add an '8u' that means some version after JDK8-GA, then >>> that is fine. > My problem with "historically" is that it is very open to interpretation. What you are saying > implies that every bug that has affectedVersion = 8 is checked to be reproduce-able with 8 GA. Which > does not ring true, since submitters usually check only with the some current version of 8u, and I > see that "8" serves as blanket "some (presumably latest) version of 8" designator for many recent > issues. Then those issues are wrong. If I was working on those bugs I would first nail down the proper version info. > That's how people use it today, no matter the history. I think that is a fair compromise: if you > know the exact version the issue appeared in, put in the exact version. But if you don't, you are > not pressured to figure it out, put the blanket major version, and move on. Having both does not > look incorrect. No, that's not correct usage. What I expect folks to do is file the bug with the specific version that they tested. If you test 8u172, then I expect the bug to be filed against 8u172. I personally don't expect the submitter to track the bug back to the earliest version of 8u or even JDK8-GA. That's not their job. If I see a recent bug filed against '8', then I would be very suspicious that '8' is not the correct version. If I was working on such a bug, then my first task would be to nail down where the real sighting is. > If using 7, 8, 11, 12, 13 as blanket designators is incorrect, then it is incorrect in many places > around JBS, and you have to go and say it somewhere, *and* provide consistent replacements for all > of them. Changing it only for 8u does not bring any added consistency. The closest alternative I can > see is 7-pool, 8-pool, 11-pool, 12-pool, 13-pool, etc, but I don't know their exact meaning. You misunderstand me. If the OpenJDK8u project wants a blanket designator, then that project is welcome to create one. I do not recommend doing that. A bug filed with a blanket version designator is initially useless to the evaluator because the first thing you have to do is figure out the real version where the issue was sighted. However, that's my opinion. I'm not working on the OpenJDK8u project. >> Another way to think about is this: >> >> We're having this conversation on the jdk8u-dev at openjdk.java.net alias. >> We are not having this conversation on the jdk8-dev at openjdk.java.net alias. >> >> Why? Because the OpenJDK8 project is done. We now have an OpenJDK8u project... > That's a weird argument, to be honest. By that argument, we have to have 11u, 12u, etc as JIRA > versions, which we don't. And the folks that run those projects can choose to have those blanket version values. However, I do not recommend it. Just to be clear: Please do not use '8' as a blanket version designator value. That release value belongs to the OpenJDK8 project and _does not_ belong to the OpenJDK8u project. And as Phil requested, please fix the bugs that you recently touched to no longer use '8'. Dan > > -Aleksey > From shade at redhat.com Thu Apr 25 19:07:33 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 25 Apr 2019 21:07:33 +0200 Subject: This (and other) bug updates are incorrect. In-Reply-To: <5CC20225.7040006@oracle.com> References: <5CC20225.7040006@oracle.com> Message-ID: <40a6c8fd-0a2d-cc5f-0409-95fc0ca0004b@redhat.com> On 4/25/19 8:53 PM, Philip Race wrote: > A lot of 8[u] bug reports originate from some migrating from the 7 train to the 8 train. > The example you cited earlier > > https://bugs.openjdk.java.net/browse/JDK-8218617 > > is one where you can see the submitter is comparing 7[u] and 8[u] behaviour and > submitted against 8 without really knowing. > This *should* have been fixed by the engineer who evaluated it. > That it was not fixed and that there remains a mistake in the release value does not make it policy .. That's the problem right here. You guys mention "historically", but does not make it policy either. I can agree there is a disagreement about the interpretation for the meaning of "8", but unless the official meaning is actually codified somewhere easily accessible to all JBS users (e.g. can JIRA provide help about what each version means?), this confusion would happen again and again. I can yield and drop some of the additions of "8", where it does not make sense if we accept "8" to mean "8 GA", but the same thing would happen very soon with someone else. -Aleksey From shade at redhat.com Thu Apr 25 19:44:11 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 25 Apr 2019 21:44:11 +0200 Subject: This (and other) bug updates are incorrect. In-Reply-To: <90019867-8351-ef57-0c8e-84d52aa5a4cb@oracle.com> References: <90019867-8351-ef57-0c8e-84d52aa5a4cb@oracle.com> Message-ID: <55292d7a-5c9c-26bf-e50d-c65ffa34183e@redhat.com> On 4/25/19 9:02 PM, Daniel D. Daugherty wrote: > You misunderstand me. If the OpenJDK8u project wants a blanket designator, > then that project is welcome to create one. I do not recommend doing that. > A bug filed with a blanket version designator is initially useless to the > evaluator because the first thing you have to do is figure out the real > version where the issue was sighted. However, that's my opinion. I'm not > working on the OpenJDK8u project. You misunderstand me as well, I think. What I am saying that projects need blanket designators. If there are none, people would invent/reuse the closest one, like the blank major revision. This will happen soon with somebody else, because the confusion is real; any many do this around JBS as well. More examples below. > Just to be clear: Please do not use '8' as a blanket version > designator value. That release value belongs to the OpenJDK8 > project and _does not_ belong to the OpenJDK8u project. I wasn't aware there is such thing as "JIRA version belongs to a project". > And as Phil requested, please fix the bugs that you recently > touched to no longer use '8'. Right, I dropped "8" from the issues that have the obvious affected-version. I would keep "8" for issues that are supposed to be reproduced with 8 GA. But, I have trouble fixing these oddly versioned ones: == "Update GIFlib library to the 5.1.8": https://bugs.openjdk.java.net/browse/JDK-8220495 Which "Affects Version" should it take? If we look back to issue history, there is a previous update happened here: https://bugs.openjdk.java.net/browse/JDK-8155691 Should it be 8u161 then? == "Xalan Update: Xalan Java 2.7.2": https://bugs.openjdk.java.net/browse/JDK-8193830 The issue already has 8u backports, but affects-version did not have any "8*" version. Which version to put there? The bug does not even link any related issues to see when was the latest update. I put "8" there this morning, which version should I put instead? I think this is one of those cases where "8" fits: it is not a bug, and 8 GA does not have new Xalan. == "Upgrade IANA LSR data" https://bugs.openjdk.java.net/browse/JDK-8213294 So it has backport to 8u221, which version to use then? 8u201? Or, using the logic from Xalan issue above, it is also proper "8"? == "[Windows] Exception if no printers are installed." https://bugs.openjdk.java.net/browse/JDK-8212202 It had backports to 8u212 and 8u231. It seems to be caused by JDK-8153732, which was backported to 8u212 and 8u231, which versions to use then? 8u212? -Aleksey From shade at redhat.com Thu Apr 25 20:40:03 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 25 Apr 2019 22:40:03 +0200 Subject: [RFR] [8u] 8222965: Build Breakage from JDK-8129988 In-Reply-To: <6d56c8eb-5eee-22fc-a728-9bbd6d7009a6@redhat.com> References: <6d56c8eb-5eee-22fc-a728-9bbd6d7009a6@redhat.com> Message-ID: <8d6a3bdb-7bf2-b678-013b-4d7b6b61b2ce@redhat.com> On 4/25/19 8:25 AM, Andrew John Hughes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8222965 > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8222965/webrev.01/ Looks good. Let's unbreak the build: it fixes the build for me. I eyeballed that we have the same files checking in as the original webrev (plus the generics fix). -Aleksey From daniel.daugherty at oracle.com Thu Apr 25 20:57:24 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 25 Apr 2019 16:57:24 -0400 Subject: This (and other) bug updates are incorrect. In-Reply-To: <55292d7a-5c9c-26bf-e50d-c65ffa34183e@redhat.com> References: <90019867-8351-ef57-0c8e-84d52aa5a4cb@oracle.com> <55292d7a-5c9c-26bf-e50d-c65ffa34183e@redhat.com> Message-ID: <1b507c6d-f1e5-7989-f7f0-4a5202990ab3@oracle.com> On 4/25/19 3:44 PM, Aleksey Shipilev wrote: > On 4/25/19 9:02 PM, Daniel D. Daugherty wrote: >> You misunderstand me. If the OpenJDK8u project wants a blanket designator, >> then that project is welcome to create one. I do not recommend doing that. >> A bug filed with a blanket version designator is initially useless to the >> evaluator because the first thing you have to do is figure out the real >> version where the issue was sighted. However, that's my opinion. I'm not >> working on the OpenJDK8u project. > You misunderstand me as well, I think. > > What I am saying that projects need blanket designators. I think I understand that it is your opinion quite well. And I have no problem if an OpenJDK Update project wants to define such a version value. > If there are none, people would > invent/reuse the closest one, like the blank major revision. This will happen soon with somebody > else, because the confusion is real; any many do this around JBS as well. More examples below. I guess I'm not understanding why someone would file an issue without specifying the exact version number they are seeing the issue reproduce with. >> Just to be clear: Please do not use '8' as a blanket version >> designator value. That release value belongs to the OpenJDK8 >> project and _does not_ belong to the OpenJDK8u project. > I wasn't aware there is such thing as "JIRA version belongs to a project". It is the project that requests that the version values be added to JIRA. Some projects have a version value for each projected build, some have 'N-alpa', 'N-beta', and 'N'. It really is up to the project to request the version values. Dan >> And as Phil requested, please fix the bugs that you recently >> touched to no longer use '8'. > Right, I dropped "8" from the issues that have the obvious affected-version. I would keep "8" for > issues that are supposed to be reproduced with 8 GA. > > But, I have trouble fixing these oddly versioned ones: > > == "Update GIFlib library to the 5.1.8": > https://bugs.openjdk.java.net/browse/JDK-8220495 > > Which "Affects Version" should it take? If we look back to issue history, there is a previous update > happened here: > https://bugs.openjdk.java.net/browse/JDK-8155691 > > Should it be 8u161 then? > > == "Xalan Update: Xalan Java 2.7.2": > https://bugs.openjdk.java.net/browse/JDK-8193830 > > The issue already has 8u backports, but affects-version did not have any "8*" version. Which version > to put there? The bug does not even link any related issues to see when was the latest update. I put > "8" there this morning, which version should I put instead? I think this is one of those cases where > "8" fits: it is not a bug, and 8 GA does not have new Xalan. > > == "Upgrade IANA LSR data" > https://bugs.openjdk.java.net/browse/JDK-8213294 > > So it has backport to 8u221, which version to use then? 8u201? Or, using the logic from Xalan issue > above, it is also proper "8"? > > == "[Windows] Exception if no printers are installed." > https://bugs.openjdk.java.net/browse/JDK-8212202 > > It had backports to 8u212 and 8u231. It seems to be caused by JDK-8153732, which was backported to > 8u212 and 8u231, which versions to use then? 8u212? > > > > -Aleksey > > > From shade at redhat.com Thu Apr 25 21:03:30 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 25 Apr 2019 23:03:30 +0200 Subject: This (and other) bug updates are incorrect. In-Reply-To: <1b507c6d-f1e5-7989-f7f0-4a5202990ab3@oracle.com> References: <90019867-8351-ef57-0c8e-84d52aa5a4cb@oracle.com> <55292d7a-5c9c-26bf-e50d-c65ffa34183e@redhat.com> <1b507c6d-f1e5-7989-f7f0-4a5202990ab3@oracle.com> Message-ID: <60052bf7-25e4-ca16-c9bc-78e22e53fb90@redhat.com> On 4/25/19 10:57 PM, Daniel D. Daugherty wrote: > On 4/25/19 3:44 PM, Aleksey Shipilev wrote: >> If there are none, people would >> invent/reuse the closest one, like the blank major revision. This will happen soon with somebody >> else, because the confusion is real; any many do this around JBS as well. More examples below. > > I guess I'm not understanding why someone would file an issue > without specifying the exact version number they are seeing > the issue reproduce with. Because sometimes it is rather unclear what the "exact version where issue reproduces" is. If this looks very clear to you, would you mind guiding me through properly versioning the issues below? >> But, I have trouble fixing these oddly versioned ones: >> >> == "Update GIFlib library to the 5.1.8": >> ?? https://bugs.openjdk.java.net/browse/JDK-8220495 >> >> Which "Affects Version" should it take? If we look back to issue history, there is a previous update >> happened here: >> ?? https://bugs.openjdk.java.net/browse/JDK-8155691 >> >> Should it be 8u161 then? >> >> == "Xalan Update: Xalan Java 2.7.2": >> ?? https://bugs.openjdk.java.net/browse/JDK-8193830 >> >> The issue already has 8u backports, but affects-version did not have any "8*" version. Which version >> to put there? The bug does not even link any related issues to see when was the latest update. I put >> "8" there this morning, which version should I put instead? I think this is one of those cases where >> "8" fits: it is not a bug, and 8 GA does not have new Xalan. >> >> == "Upgrade IANA LSR data" >> ?? https://bugs.openjdk.java.net/browse/JDK-8213294 >> >> So it has backport to 8u221, which version to use then? 8u201? Or, using the logic from Xalan issue >> above, it is also proper "8"? >> >> == "[Windows] Exception if no printers are installed." >> ?? https://bugs.openjdk.java.net/browse/JDK-8212202 >> >> It had backports to 8u212 and 8u231. It seems to be caused by JDK-8153732, which was backported to >> 8u212 and 8u231, which versions to use then? 8u212? Thanks, -Aleksey From daniel.daugherty at oracle.com Thu Apr 25 21:33:54 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 25 Apr 2019 17:33:54 -0400 Subject: This (and other) bug updates are incorrect. In-Reply-To: <60052bf7-25e4-ca16-c9bc-78e22e53fb90@redhat.com> References: <90019867-8351-ef57-0c8e-84d52aa5a4cb@oracle.com> <55292d7a-5c9c-26bf-e50d-c65ffa34183e@redhat.com> <1b507c6d-f1e5-7989-f7f0-4a5202990ab3@oracle.com> <60052bf7-25e4-ca16-c9bc-78e22e53fb90@redhat.com> Message-ID: On 4/25/19 5:03 PM, Aleksey Shipilev wrote: > On 4/25/19 10:57 PM, Daniel D. Daugherty wrote: >> On 4/25/19 3:44 PM, Aleksey Shipilev wrote: >>> If there are none, people would >>> invent/reuse the closest one, like the blank major revision. This will happen soon with somebody >>> else, because the confusion is real; any many do this around JBS as well. More examples below. >> I guess I'm not understanding why someone would file an issue >> without specifying the exact version number they are seeing >> the issue reproduce with. > Because sometimes it is rather unclear what the "exact version where issue reproduces" is. If this > looks very clear to you, would you mind guiding me through properly versioning the issues below? > >>> But, I have trouble fixing these oddly versioned ones: >>> >>> == "Update GIFlib library to the 5.1.8": >>> ?? https://bugs.openjdk.java.net/browse/JDK-8220495 >>> >>> Which "Affects Version" should it take? For this bug, I would drop '7', '8', '11' and '12'. I would only set an affects version on the 7u, 8u, 11u and 12u trains that match the current version for each of those trains. By "current version", I mean the current version that includes the old version of the library. >>> If we look back to issue history, there is a previous update >>> happened here: >>> ?? https://bugs.openjdk.java.net/browse/JDK-8155691 >>> >>> Should it be 8u161 then? This bug's affects version is set to only '9' and I'm good with that. The backport issues make it clear which update release has the newer version of the library. Pretty safe to assume that an older version of 7u and 8u has the older version of the library. In this example, "less is more" for the "Affects Version/s" field. Would I go back and add more "Affects Version/s" values?? No, I would not, but that doesn't mean other folks won't do it. >>> >>> == "Xalan Update: Xalan Java 2.7.2": >>> ?? https://bugs.openjdk.java.net/browse/JDK-8193830 >>> >>> The issue already has 8u backports, but affects-version did not have any "8*" version. Which version >>> to put there? The bug does not even link any related issues to see when was the latest update. I put >>> "8" there this morning, which version should I put instead? I think this is one of those cases where >>> "8" fits: it is not a bug, and 8 GA does not have new Xalan. You are quite correct in stating that '8' has the old library so this issue applies there. Is that good information? Not really. Like JDK-8155691 above, I would have left "Affects Version/s" at '10' and not added any '8u' versions. Again, the Backports tell you which '8u' version has the new version of the library and anything older doesn't. >>> >>> == "Upgrade IANA LSR data" >>> ?? https://bugs.openjdk.java.net/browse/JDK-8213294 >>> >>> So it has backport to 8u221, which version to use then? 8u201? Or, using the logic from Xalan issue >>> above, it is also proper "8"? It looks like this issue had an empty "Affects Version/s" that you set to '8', '11', and '12'. I would probably left it empty since this isn't a hotspot bug and that team may not have rules about setting the "Affects Version/s" field. If I really felt compelled to set an "Affects Version/s" value, I would have set just '12'. Again, the Backports tell you which '8u' and which '11u' version has the new version of the library and anything older doesn't. >>> >>> == "[Windows] Exception if no printers are installed." >>> ?? https://bugs.openjdk.java.net/browse/JDK-8212202 >>> >>> It had backports to 8u212 and 8u231. It seems to be caused by JDK-8153732, which was backported to >>> 8u212 and 8u231, which versions to use then? 8u212? You added '8'. Since JDK-8153732 isn't fixed in '8', that's the wrong value. If you had to add an "Affects Version/s" value, I would add 8u212 and maybe 8u231. You could also skip adding an "Affects Version/s" value and let the Backports do the talking. Obviously, those are my opinions. YMMV. Dan > Thanks, > -Aleksey > From alexey.ivanov at oracle.com Thu Apr 25 22:17:17 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Thu, 25 Apr 2019 23:17:17 +0100 Subject: This (and other) bug updates are incorrect. In-Reply-To: <55292d7a-5c9c-26bf-e50d-c65ffa34183e@redhat.com> References: <90019867-8351-ef57-0c8e-84d52aa5a4cb@oracle.com> <55292d7a-5c9c-26bf-e50d-c65ffa34183e@redhat.com> Message-ID: <713ef127-987e-0b23-0812-54c289d8275c@oracle.com> Hi Aleksey, This issue does not affect 8u at all. It is a regression from https://bugs.openjdk.java.net/browse/JDK-8153732 as stated in the bug description. The chain of the four fixes: JDK-8212202, JDK-8212202, JDK-8221412, JDK-8221263 was backported to 8u. None of the follow-up bugs affects 8u. On 25/04/2019 20:44, Aleksey Shipilev wrote: > == "[Windows] Exception if no printers are installed." > https://bugs.openjdk.java.net/browse/JDK-8212202 > > It had backports to 8u212 and 8u231. It seems to be caused by JDK-8153732, which was backported to > 8u212 and 8u231, which versions to use then? 8u212? -- Regards, Alexey From gnu.andrew at redhat.com Fri Apr 26 03:41:06 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 26 Apr 2019 04:41:06 +0100 Subject: [RFR] [8u] 8222965: Build Breakage from JDK-8129988 In-Reply-To: <8d6a3bdb-7bf2-b678-013b-4d7b6b61b2ce@redhat.com> References: <6d56c8eb-5eee-22fc-a728-9bbd6d7009a6@redhat.com> <8d6a3bdb-7bf2-b678-013b-4d7b6b61b2ce@redhat.com> Message-ID: <9a96362a-5cc1-347c-9cb8-c9768474a4ba@redhat.com> On 25/04/2019 21:40, Aleksey Shipilev wrote: > On 4/25/19 8:25 AM, Andrew John Hughes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8222965 >> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8222965/webrev.01/ > > Looks good. Let's unbreak the build: it fixes the build for me. I eyeballed that we have the same > files checking in as the original webrev (plus the generics fix). > > -Aleksey > Thanks. I just need jdk8u-fix-yes and I can push. CCing aph. -- 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 Apr 26 05:05:27 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 26 Apr 2019 06:05:27 +0100 Subject: This (and other) bug updates are incorrect. In-Reply-To: References: Message-ID: <0a935ca3-27cc-aeb3-27af-7a540fb86070@redhat.com> On 25/04/2019 19:13, Daniel D. Daugherty wrote: snip... >>> >> >> Sorry Aleksey. Version value '8' historically means JDK8-GA. It should >> only used used for bugs that reproduce with JDK8-GA. If the OpenJDK8u >> project wants to add an '8u' that means some version after JDK8-GA, then >> that is fine. >> >> Dan > It would seem to make more sense to designate those that are known to reproduce specifically on OpenJDK 8 GA with a new label '8-ga' rather than creating a distinction between '8' and '8u' which is far from obvious. To me, it makes more sense to use Affects to specify the major versions the issue is applicable to, and use the 'Introduced in Version' & 'Introduced in Build' fields to specify exact information about where the issue was reproduced. Affects is then a useful source of information as to whether an issue needs to be backported or not. How is Affects used for issues that occur before GA? > Another way to think about is this: > > We're having this conversation on the jdk8u-dev at openjdk.java.net alias. > We are not having this conversation on the jdk8-dev at openjdk.java.net alias. > > Why? Because the OpenJDK8 project is done. We now have an OpenJDK8u > project... > > There are a few examples of emails that come in on > jdk8-dev at openjdk.java.net > where we redirect the folks to jdk8u-dev at openjdk.java.net because the > OpenJDK8 project is done. > Which suggests that the existence of both is a continuing source of confusion. > Dan > -- 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 sean.coffey at oracle.com Fri Apr 26 10:58:15 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 26 Apr 2019 11:58:15 +0100 Subject: This (and other) bug updates are incorrect. In-Reply-To: <0a935ca3-27cc-aeb3-27af-7a540fb86070@redhat.com> References: <0a935ca3-27cc-aeb3-27af-7a540fb86070@redhat.com> Message-ID: <525a72eb-ca62-27e0-e2c1-483072430b47@oracle.com> Alot of this discussion boils down to a requirement to better document OpenJDK process. If clarification is necessary, let's please have a proposal/discussion elsewhere and get agreement before modifying JBS data which could impact historical data. Currently, there are 20k+ records with affectsVersion = 8. My understanding has always been that this denotes 8 GA, just like a fix Version of '8' corresponds to a build of JDK 8. The "introduced in" field can complement the affectsVersion field when a release is in early access mode. The current JBS document[1] makes reference to the affectsVersion field. It suggests: "The special version values like tbd_minor should not be used in the affectedVersion field; only version values corresponding to actual releases should be used." It also points out: "affectedVersion: what version(s) of a product are affected by an issue? This multi-valued field can hold multiple versions that are impacted by an issue. This field is informative and the set of releases listed is not intended to be exhaustive." This original email thread was started to point out that adding affectsVersion of '8' to JDK-8218605 was questionable. I'd be in agreement with Phil Race on that and I'm glad to see it's been cleared up. [1] https://wiki.openjdk.java.net/display/general/JBS+Overview Regards, Sean. On 26/04/19 06:05, Andrew John Hughes wrote: > On 25/04/2019 19:13, Daniel D. Daugherty wrote: > > snip... > >>> Sorry Aleksey. Version value '8' historically means JDK8-GA. It should >>> only used used for bugs that reproduce with JDK8-GA. If the OpenJDK8u >>> project wants to add an '8u' that means some version after JDK8-GA, then >>> that is fine. >>> >>> Dan > It would seem to make more sense to designate those that are known to > reproduce specifically on OpenJDK 8 GA with a new label '8-ga' rather > than creating a distinction between '8' and '8u' which is far from obvious. > > To me, it makes more sense to use Affects to specify the major versions > the issue is applicable to, and use the 'Introduced in Version' & > 'Introduced in Build' fields to specify exact information about where > the issue was reproduced. Affects is then a useful source of information > as to whether an issue needs to be backported or not. > > How is Affects used for issues that occur before GA? > >> Another way to think about is this: >> >> We're having this conversation on the jdk8u-dev at openjdk.java.net alias. >> We are not having this conversation on the jdk8-dev at openjdk.java.net alias. >> >> Why? Because the OpenJDK8 project is done. We now have an OpenJDK8u >> project... >> >> There are a few examples of emails that come in on >> jdk8-dev at openjdk.java.net >> where we redirect the folks to jdk8u-dev at openjdk.java.net because the >> OpenJDK8 project is done. >> > Which suggests that the existence of both is a continuing source of > confusion. > >> Dan >> From dalibor.topic at oracle.com Fri Apr 26 11:02:27 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 26 Apr 2019 13:02:27 +0200 Subject: This (and other) bug updates are incorrect. In-Reply-To: <0a935ca3-27cc-aeb3-27af-7a540fb86070@redhat.com> References: <0a935ca3-27cc-aeb3-27af-7a540fb86070@redhat.com> Message-ID: On 26.04.2019 07:05, Andrew John Hughes wrote: > On 25/04/2019 19:13, Daniel D. Daugherty wrote: > > snip... > >>>> >>> >>> Sorry Aleksey. Version value '8' historically means JDK8-GA. It should >>> only used used for bugs that reproduce with JDK8-GA. If the OpenJDK8u >>> project wants to add an '8u' that means some version after JDK8-GA, then >>> that is fine. >>> >>> Dan >> > > It would seem to make more sense to designate those that are known to > reproduce specifically on OpenJDK 8 GA with a new label '8-ga' rather > than creating a distinction between '8' and '8u' which is far from obvious. I think that it's great that the various parties collaborating around OpenJDK 8 Updates maintenance are now embracing usage of JIRA as a common source of truth. But let's not rewrite issue history, please. In the context of OpenJDK development, various parties have their own automation tools and rely on existing semantics of labels, versions etc. to mean specific things to them. Please don't just deliberately break other people's workflows you may not be aware of without due consideration and consultation, regardless of how strongly you may feel justified in doing so. In that regard, it would be wiser and nicer to define your desired new semantics, which Aleksey argues for, for new tags/labels/releases, and to document them on the Project's wiki. Then the next set of maintainers that comes along once you step down can decide to embrace and continue to use them, if they fit their workflow, or deliberately make different choices. 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 shade at redhat.com Fri Apr 26 11:23:22 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 26 Apr 2019 13:23:22 +0200 Subject: This (and other) bug updates are incorrect. In-Reply-To: References: <0a935ca3-27cc-aeb3-27af-7a540fb86070@redhat.com> Message-ID: <91691913-5477-5800-a2e9-9aca2bdc3bba@redhat.com> On 4/26/19 1:02 PM, Dalibor Topic wrote: > On 26.04.2019 07:05, Andrew John Hughes wrote: >> It would seem to make more sense to designate those that are known to >> reproduce specifically on OpenJDK 8 GA with a new label '8-ga' rather >> than creating a distinction between '8' and '8u' which is far from obvious. > > I think that it's great that the various parties collaborating around OpenJDK 8 Updates maintenance > are now embracing usage of JIRA as a common source of truth. But let's not rewrite issue history, > please. Well, "rewrite issue history" did not happen. The JDK-8218605 in question was _amended_ to capture "8", and "8u211" was kept intact. If it was a destructive update, then yes, that would be a significant problem. Since it wasn't destructive, it is a minor snag. For me, the actionable lesson from here is this: if there is a specific affected-versions set, like "8u211", then adding the lower one (e.g. "8") is not called for, unless actually verified that version is affected (e.g. "8 GA"). The existing version says enough about the release train where the issue was discovered. Similarly, if there are no reliable data what exact version in a release train the issue affects, it is fine to put the provisional "8u201" (or whatever is latest now) to the affected-version, assuming the fix needs to be in latest release, with the intent to amend it, if/when the actual affected point in 8u is discovered. If we know the issue affects 8 GA (as the frequently the case for RFE/updates that sink backwards from higher releases), we can go and put "8". In all these cases, the affected-version tags would tell the affected release train (which our tools want, and can figure out by stripping minor versions), and keep the issue metadata as precise as possible (which seems to be the original complaint). Have I summed it up correctly to everyone's agreement? -Aleksey From dalibor.topic at oracle.com Fri Apr 26 12:11:50 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 26 Apr 2019 14:11:50 +0200 Subject: OpenJDK Updates Project Builds In-Reply-To: <9e3b46db-c190-5a8a-3d26-050aab48d8ac@oracle.com> References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> <9e3b46db-c190-5a8a-3d26-050aab48d8ac@oracle.com> Message-ID: <70ef08c2-d452-bac8-53d9-914b95fdaccf@oracle.com> Hi, the Early Access (EA) builds on https://adoptopenjdk.net/upstream.html are still confusingly versioned on that site, unfortunately. To quote from [0]: "E.g. what tells an end user that +7 and +31 are release builds, but +6 and +11 are not?" cheers, dalibor topic [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000962.html On 16.04.2019 21:49, Dalibor Topic wrote: > On 15.04.2019 12:25, Andrew Haley wrote: >> we now have early access >> preview Linux and Windows binaries (currently x86-64 only) at >> >> https://adoptopenjdk.net/upstream.html > > I would suggest using the version nomenclature per JEP 322, i.e. > > "A version string is a version number, $VNUM, possibly followed by > pre-release, build, and other optional information, one of: > > $VNUM(-$PRE)?\+$BUILD(-$OPT)? > $VNUM-$PRE(-$OPT)? > $VNUM(+-$OPT)? > > where $PRE is a pre-release identifier (e.g., ea), $BUILD is a build > number, and $OPT is optional build information." > > i.e. 11.0.3-ea+6, for example. > > 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 sgehwolf at redhat.com Fri Apr 26 12:28:11 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 26 Apr 2019 14:28:11 +0200 Subject: OpenJDK Updates Project Builds In-Reply-To: <70ef08c2-d452-bac8-53d9-914b95fdaccf@oracle.com> References: <6ef8a504-dae3-6456-f446-49ffc131a2ab@redhat.com> <9e3b46db-c190-5a8a-3d26-050aab48d8ac@oracle.com> <70ef08c2-d452-bac8-53d9-914b95fdaccf@oracle.com> Message-ID: <9ca2b175cb0add0b6ff3da32d2b705af210c592b.camel@redhat.com> On Fri, 2019-04-26 at 14:11 +0200, Dalibor Topic wrote: > Hi, > > the Early Access (EA) builds on https://adoptopenjdk.net/upstream.html > are still confusingly versioned on that site, unfortunately. To quote > from [0]: > > "E.g. what tells an end user that +7 and +31 are release builds, but +6 > and +11 are not?" I'm not 100% clear what you mean. To answer the question: The filename? "java -version" output? $ ls -1 OpenJDK11U-x64_linux_11.0.3_6_ea.tar.gz OpenJDK11U-x64_linux_11.0.3_7.tar.gz $ ./openjdk-11.0.3+6/bin/java -version openjdk version "11.0.3-ea" 2019-04-16 OpenJDK Runtime Environment 18.9 (build 11.0.3-ea+6) OpenJDK 64-Bit Server VM 18.9 (build 11.0.3-ea+6, mixed mode) $ ./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) For JDK 8u it won't show up in the version output, but I'm not sure that can be helped. Archive file names still have "ea" in their name and the build numbers show up in version output so as to distinguish them. Thanks, Severin > cheers, > dalibor topic > > [0] > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000962.html > > On 16.04.2019 21:49, Dalibor Topic wrote: > > On 15.04.2019 12:25, Andrew Haley wrote: > > > we now have early access > > > preview Linux and Windows binaries (currently x86-64 only) at > > > > > > https://adoptopenjdk.net/upstream.html > > > > I would suggest using the version nomenclature per JEP 322, i.e. > > > > "A version string is a version number, $VNUM, possibly followed by > > pre-release, build, and other optional information, one of: > > > > $VNUM(-$PRE)?\+$BUILD(-$OPT)? > > $VNUM-$PRE(-$OPT)? > > $VNUM(+-$OPT)? > > > > where $PRE is a pre-release identifier (e.g., ea), $BUILD is a > > build > > number, and $OPT is optional build information." > > > > i.e. 11.0.3-ea+6, for example. > > > > cheers, > > dalibor topic > > From dalibor.topic at oracle.com Fri Apr 26 12:54:39 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 26 Apr 2019 14:54:39 +0200 Subject: OpenJDK Updates Project Builds In-Reply-To: <9ca2b175cb0add0b6ff3da32d2b705af210c592b.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> Message-ID: <12978a20-3fc7-9629-bfca-556ec45040c3@oracle.com> On 26.04.2019 14:28, Severin Gehwolf wrote: > On Fri, 2019-04-26 at 14:11 +0200, Dalibor Topic wrote: >> Hi, >> >> the Early Access (EA) builds on https://adoptopenjdk.net/upstream.html >> are still confusingly versioned on that site, unfortunately. [snip] > I'm not 100% clear what you mean. Thanks for your reply, Severin, and apologies for not being precise enough. While the EA build file names contain an 'ea' substring, the HTML anchor tag's text content unfortunately doesn't. 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 sgehwolf at redhat.com Fri Apr 26 13:06:12 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 26 Apr 2019 15:06:12 +0200 Subject: OpenJDK Updates Project Builds In-Reply-To: <12978a20-3fc7-9629-bfca-556ec45040c3@oracle.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> <12978a20-3fc7-9629-bfca-556ec45040c3@oracle.com> Message-ID: <4e23c04630da5fd08753327b4d408c32be84838e.camel@redhat.com> On Fri, 2019-04-26 at 14:54 +0200, Dalibor Topic wrote: > On 26.04.2019 14:28, Severin Gehwolf wrote: > > On Fri, 2019-04-26 at 14:11 +0200, Dalibor Topic wrote: > > > Hi, > > > > > > the Early Access (EA) builds on https://adoptopenjdk.net/upstream.html > > > are still confusingly versioned on that site, unfortunately. > [snip] > > I'm not 100% clear what you mean. > > Thanks for your reply, Severin, and apologies for not being precise enough. > > While the EA build file names contain an 'ea' substring, the HTML anchor > tag's text content unfortunately doesn't. Fair enough :) There are two separate tables, though. One for the release bits and another for EA. In addition to that, the rows in corresponding tables are "OpenJDK X" for release and "OpenJDK X EA" for EA. Do we really need another "ea" added somewhere? For brevity in the table I'd rather not. That's just my opinion, though. Thanks, Severin From dalibor.topic at oracle.com Fri Apr 26 13:27:04 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 26 Apr 2019 15:27:04 +0200 Subject: OpenJDK Updates Project Builds In-Reply-To: <4e23c04630da5fd08753327b4d408c32be84838e.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> <12978a20-3fc7-9629-bfca-556ec45040c3@oracle.com> <4e23c04630da5fd08753327b4d408c32be84838e.camel@redhat.com> Message-ID: <3d864740-027b-60b5-db57-7696f8d71fad@oracle.com> On 26.04.2019 15:06, Severin Gehwolf wrote: > There are two separate tables, though. One for the release bits and > another for EA. In addition to that, the rows in corresponding tables > are "OpenJDK X" for release and "OpenJDK X EA" for EA. Do we really > need another "ea" added somewhere? For brevity in the table I'd rather > not. That's just my opinion, though. My experience has been that some users can get confused if (i.e. in your case: when) there is a build with a 'higher' version than a GA release that's not clearly recognizable as an Early Access build in all possible ways. Basically, not everyone is necessarily an expert at JDK development or its versioning. ;) 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 martijnverburg at gmail.com Fri Apr 26 13:59:04 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Fri, 26 Apr 2019 14:59:04 +0100 Subject: OpenJDK Updates Project Builds In-Reply-To: <3d864740-027b-60b5-db57-7696f8d71fad@oracle.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> <12978a20-3fc7-9629-bfca-556ec45040c3@oracle.com> <4e23c04630da5fd08753327b4d408c32be84838e.camel@redhat.com> <3d864740-027b-60b5-db57-7696f8d71fad@oracle.com> Message-ID: Bug reports and Pull Requests welcome https://www.github.com/adoptopenjdk/openjdk-website ;-) In all seriousness - closed via https://github.com/AdoptOpenJDK/openjdk-website/pull/471 Cheers, Martijn On Fri, 26 Apr 2019 at 14:27, Dalibor Topic wrote: > On 26.04.2019 15:06, Severin Gehwolf wrote: > > > There are two separate tables, though. One for the release bits and > > another for EA. In addition to that, the rows in corresponding tables > > are "OpenJDK X" for release and "OpenJDK X EA" for EA. Do we really > > need another "ea" added somewhere? For brevity in the table I'd rather > > not. That's just my opinion, though. > > My experience has been that some users can get confused if (i.e. in your > case: when) there is a build with a 'higher' version than a GA release > that's not clearly recognizable as an Early Access build in all possible > ways. > > Basically, not everyone is necessarily an expert at JDK development or > its versioning. ;) > > 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 gnu.andrew at redhat.com Fri Apr 26 14:40:40 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 26 Apr 2019 15:40:40 +0100 Subject: This (and other) bug updates are incorrect. In-Reply-To: References: <0a935ca3-27cc-aeb3-27af-7a540fb86070@redhat.com> Message-ID: <45cb1840-2929-b970-6416-a1925c76f3a3@redhat.com> On 26/04/2019 12:02, Dalibor Topic wrote: > On 26.04.2019 07:05, Andrew John Hughes wrote: >> On 25/04/2019 19:13, Daniel D. Daugherty wrote: >> >> snip... >> >>>>> >>>> >>>> Sorry Aleksey. Version value '8' historically means JDK8-GA. It should >>>> only used used for bugs that reproduce with JDK8-GA. If the OpenJDK8u >>>> project wants to add an '8u' that means some version after JDK8-GA, >>>> then >>>> that is fine. >>>> >>>> Dan >>> >> >> It would seem to make more sense to designate those that are known to >> reproduce specifically on OpenJDK 8 GA with a new label '8-ga' rather >> than creating a distinction between '8' and '8u' which is far from >> obvious. > > > I think that it's great that the various parties collaborating around > OpenJDK 8 Updates maintenance are now embracing usage of JIRA as a > common source of truth. But let's not rewrite issue history, please. > We have been using JIRA since it was first adopted for OpenJDK. There is nothing new about this. In the context of OpenJDK 8, we have adopted it to a greater degree than was the case under Oracle stewardship. > In the context of OpenJDK development, various parties have their own > automation tools and rely on existing semantics of labels, versions etc. > to mean specific things to them. Please don't just deliberately break > other people's workflows you may not be aware of without due > consideration and consultation, regardless of how strongly you may feel > justified in doing so. > > In that regard, it would be wiser and nicer to define your desired new > semantics, which Aleksey argues for, for new tags/labels/releases, and > to document them on the Project's wiki. Then the next set of maintainers > that comes along once you step down can decide to embrace and continue > to use them, if they fit their workflow, or deliberately make different > choices. > Nobody is trying to "deliberately break" anything. Until this thread, we were unaware that "8" meant "8 GA" to some. I have not seen any mention of this interpretation being documented anywhere. We have used it as "8" meaning "some version of OpenJDK 8". The end result of this is that "8" is being used within the current bug database with two different sets of semantics (and likewise for other OpenJDK versions). Some common agreement needs to be reached as to how it should be used. My suggestion was simply that "x" and "x-ga" is clearer than "x" and "xu", especially given that the "-ga" nomenclature is already used in the Mercurial repositories under both the old and new version systems, while the "u" suffix seems to have been abandoned from OpenJDK 9 onwards. I don't see a different solution being adopted for OpenJDK 8 only as a solution, but more the potential source of more confusion. > cheers, > dalibor topic > -- 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 Fri Apr 26 14:47:22 2019 From: gil at azul.com (Gil Tene) Date: Fri, 26 Apr 2019 14:47:22 +0000 Subject: OpenJDK Updates Project Builds In-Reply-To: <9ca2b175cb0add0b6ff3da32d2b705af210c592b.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> Message-ID: <515BB18C-F37C-44F6-81ED-E71F4DEF5FDF@azul.com> Sent from my iPad On Apr 26, 2019, at 5:28 AM, Severin Gehwolf > wrote: On Fri, 2019-04-26 at 14:11 +0200, Dalibor Topic wrote: Hi, the Early Access (EA) builds on https://adoptopenjdk.net/upstream.html are still confusingly versioned on that site, unfortunately. To quote from [0]: "E.g. what tells an end user that +7 and +31 are release builds, but +6 and +11 are not?" I'm not 100% clear what you mean. To answer the question: The filename? "java -version" output? $ ls -1 OpenJDK11U-x64_linux_11.0.3_6_ea.tar.gz OpenJDK11U-x64_linux_11.0.3_7.tar.gz $ ./openjdk-11.0.3+6/bin/java -version openjdk version "11.0.3-ea" 2019-04-16 OpenJDK Runtime Environment 18.9 (build 11.0.3-ea+6) OpenJDK 64-Bit Server VM 18.9 (build 11.0.3-ea+6, mixed mode) $ ./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) For JDK 8u it won't show up in the version output, but I'm not sure that can be helped. Archive file names still have "ea" in their name and the build numbers show up in version output so as to distinguish them. I would highly recommend/request/beg/plead that the -version string of any posed EA builds be modified to clearly identify as EA (like the 11 builds do above). And that all current builds that don?t do that be taken down ASAP to prevent damage. This (EA builds of 8u that show -version numbers that look very much like releases but are not) is a very serious problem. The file name, the web link, and the text in the web page don?t survive installation. And what you have left around then is a ?mystery meat? JDK that made it into the wild. These things can (and do) then end up in places and situations where vast numbers of people end up using unreleased builds, often in production, without knowing it. For a concrete historical example of how bad something like this can (and did) get when you don?t take care to identify EA?ness in the actual version string output: Between Sep. 2014 and March 2015 (I.e. for the ~6 month period before 8u40 was actually released) running ?docker run java:8 -version? reported the version as 8u40, with nothing to indicate the JDK you were running was experimental or EA. This was a result of an unfortunate choice to take the blessed docker java image?s JDK from a Debian unstable release, which was building an unreleased OpenJDK (with the Debian folks probably thinking ?this Debian distro and repo are clearly unstable/experimental, so people would know not to take bits from it to production?). This JDK then ended up in the ?blessed? docker image for java, with nothing to identify it as a non-released JDK. And as a result everyone that read articles like https://blog.giantswarm.io/getting-started-with-java-development-on-docker/ ended up using an 8u40 that wasn?t 8u40 without knowing it, and with no obvious way to tell, even after the real 8 u40 was released. It is likely that millions of people were affected by this. Bottom line: Please please please don?t put up binary builds of non-released JDKs that do not clearly identify them as such in the version actual string output. And if you did, please tear them down ASAP to limit potential damage. Thanks, Severin cheers, dalibor topic [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000962.html On 16.04.2019 21:49, Dalibor Topic wrote: On 15.04.2019 12:25, Andrew Haley wrote: we now have early access preview Linux and Windows binaries (currently x86-64 only) at https://adoptopenjdk.net/upstream.html I would suggest using the version nomenclature per JEP 322, i.e. "A version string is a version number, $VNUM, possibly followed by pre-release, build, and other optional information, one of: $VNUM(-$PRE)?\+$BUILD(-$OPT)? $VNUM-$PRE(-$OPT)? $VNUM(+-$OPT)? where $PRE is a pre-release identifier (e.g., ea), $BUILD is a build number, and $OPT is optional build information." i.e. 11.0.3-ea+6, for example. cheers, dalibor topic From gnu.andrew at redhat.com Fri Apr 26 14:49:44 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 26 Apr 2019 15:49:44 +0100 Subject: [RFR] [8u] 8222965: Build Breakage from JDK-8129988 In-Reply-To: <9a96362a-5cc1-347c-9cb8-c9768474a4ba@redhat.com> References: <6d56c8eb-5eee-22fc-a728-9bbd6d7009a6@redhat.com> <8d6a3bdb-7bf2-b678-013b-4d7b6b61b2ce@redhat.com> <9a96362a-5cc1-347c-9cb8-c9768474a4ba@redhat.com> Message-ID: <28fd2e8c-0160-dbe5-a063-165ee1cc5986@redhat.com> On 26/04/2019 04:41, Andrew John Hughes wrote: > > > On 25/04/2019 21:40, Aleksey Shipilev wrote: >> On 4/25/19 8:25 AM, Andrew John Hughes wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222965 >>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8222965/webrev.01/ >> >> Looks good. Let's unbreak the build: it fixes the build for me. I eyeballed that we have the same >> files checking in as the original webrev (plus the generics fix). >> >> -Aleksey >> > > Thanks. I just need jdk8u-fix-yes and I can push. CCing aph. > And pushed: https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/b014bff7ba96 -- 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 Apr 26 15:47:03 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 26 Apr 2019 16:47:03 +0100 Subject: This (and other) bug updates are incorrect. In-Reply-To: References: <90019867-8351-ef57-0c8e-84d52aa5a4cb@oracle.com> <55292d7a-5c9c-26bf-e50d-c65ffa34183e@redhat.com> <1b507c6d-f1e5-7989-f7f0-4a5202990ab3@oracle.com> <60052bf7-25e4-ca16-c9bc-78e22e53fb90@redhat.com> Message-ID: <19ee962f-2096-eccb-a66b-607b35db39c5@redhat.com> snip... > > This bug's affects version is set to only '9' and I'm good with > that. The backport issues make it clear which update release has > the newer version of the library. Pretty safe to assume that an > older version of 7u and 8u has the older version of the library. > > In this example, "less is more" for the "Affects Version/s" field. > > Would I go back and add more "Affects Version/s" values?? No, I > would not, but that doesn't mean other folks won't do it. > The obvious question that arises from this for me is what about cases where there is not yet any backport issues for a particular major version, but the issue itself exists on that version? We've been adding additional Affects values in order to capture the need for a backport. It is indeed pretty clear that the issue affects a particular major version if there are already backport issues in place. Is there an actual objection to the addition of further Affects values or is it just a case of not wanting '7', '8', etc. to be used because of some historical interpretation of those values as being the initial GA version of that release stream? 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 Apr 26 16:00:13 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 26 Apr 2019 17:00:13 +0100 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> Message-ID: On 25/04/2019 08:48, Severin Gehwolf wrote: > On Thu, 2019-04-25 at 06:24 +0000, Langer, Christoph wrote: >> Hi, >> >>> On 24/04/2019 16:08, Langer, Christoph wrote: >> >> >> >>>> But I would be fine with changing the schedule to this: >>>> >>>> March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) >>>> Tuesday, May 28 2019: RDP2, Branch jdk11u-dev to jdk11u >>>> Wednesday, May 29 2019: First build (tag: jdk-11.0.4+1) >>>> Wednesday June 26 2019: Last tag before code freeze >>>> Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga) >>>> >>> >>> This looks better. >>> >>> The addition I'd like to see is to start the weekly promotions earlier, >>> so they also happen in the first stage. That would avoid b01 being so >>> huge. I think that's a good halfway house between proposing entering the >>> critical fix stage next week and not promoting anything until the end of >>> May. >>> >>> That would mean multiple jdk11u-dev->jdk11u & jdk8u-dev->jdk8u merges >>> from next Wednesday 1st of May through to the final one of May 29: >>> >>> March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) >>> ================= RDP1 ===================================== >>> = 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 RDP1 build (tag: jdk-11.0.4+5) >>> ================= RDP2 ===================================== >>> = jdk11u tree gets changes only by jdk11u-critical-request = >>> ========================================================== >>> == >>> Wednesday, June 5, 2019: First RDP2 build (tag: jdk-11.0.4+6) >>> Wednesday, June 12, 2019: Second RDP2 build (tag: jdk-11.0.4+7) >>> Wednesday, June 19, 2019: Third RDP2 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) >>> >>> This allows regular testing earlier in the cycle, but without >>> restricting the process down to critical fixes early. >> >> Sounds like a good suggestion to me as I can see the need to have EA builds early. >> I think technically we should then tag in jdk11u-dev/jdk8u-dev until the 29th of May and pull these tags into jdk11u/jdk8u. >> We'll have to confirm with ops whether this will correctly resolve the bugs in JBS (e.g. with the right build associated). > > +1 > > Thanks, > Severin > That sounds sensible. My primary concern is that something is available and tagged in 8u/11u for people not necessarily active in development to consume and test, perhaps first integrating into downstream repositories as we do with our Shenandoah repositories. If there are no objections to the above by Tuesday, I suggest we adopt the above schedule for the upcoming 8u222 & 11.0.4 releases. 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 Apr 26 16:14:41 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 26 Apr 2019 17:14:41 +0100 Subject: [8u-dev] RFR: JDK-8222975: Fix 'release' file to reflect actual repo checkin used to compile JDK In-Reply-To: <99670eb0-1ec3-1c07-8f6b-4d10413f599e@redhat.com> References: <1f857eb6-be66-c552-3333-acac64ae0093@redhat.com> <99670eb0-1ec3-1c07-8f6b-4d10413f599e@redhat.com> Message-ID: <459fbf2a-7b8a-3a62-1c34-32ae35649a35@redhat.com> On 25/04/2019 17:57, Simon Tooke wrote: > > On 4/25/2019 12:19 PM, Andrew John Hughes wrote: >> On 25/04/2019 16:23, Simon Tooke wrote: >>> On 4/25/2019 12:29 AM, Andrew John Hughes wrote: >>>> On 24/04/2019 20:29, Simon Tooke wrote: >>>>> Hi, >>>>> >>>>> In the process of the latest CPU, I found the 'release' file differed >>>>> between the Linux and Windows built images, and tracked it down to the >>>>> use of 'hg tip' instead of 'hg id'. >>>>> >>>>> As luck would have it, this was previously reported (JDK-8031567) and >>>>> fixed in JDK 9.? >>>>> >>>>> Rather than backport the entire PR to jdk8u, I propose only enough to >>>>> fix the actual problem; replacing the calls to 'hg tip' with calls to >>>>> 'hg id -i'. >>>>> >>>>> Original JBS: https://bugs.openjdk.java.net/browse/JDK-8031567 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8031567/ >>>>> >>>>> I'm open to a full backport, but wanted to minimize perturbation of 8u.? >>>>> If this is misguided, please correct me... >>>>> >>>>> Thank you for your time, >>>>> >>>>> -Simon >>>>> >>>>> >>>> Given that 8031567 is an enhancement which rewrites the offending code >>>> altogether, I don't think a smaller, different change should really go >>>> in under the same ID. It will make it look like 8031567 is present in >>>> OpenJDK 8, but none of the actual code that is in 9+ will be there. >>>> >>>> I'd prefer a full backport of 8031567 for consistency with 9+, but the >>>> current webrev is fine too, as long as it is committed under its own ID. >>> That makes sense.? I've created a new bug entry: >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8222975 >>> >>> Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8222975/ >>> >>> -Simon >>> >>> >> Ok, change looks good to me. >> >> Flag the bug with jdk8u-fix-request and I'll approve it. >> >> Do you have push rights or does someone need to do so on your behalf? >> >> Thanks, > > Thanks for the review! > > I've flagged the bug as requested, but unfortunately I don't yet have > push rights. > > -simon > > > Approved and pushed: https://hg.openjdk.java.net/jdk8u/jdk8u-dev/rev/84adf64edebb 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 Fri Apr 26 16:22:37 2019 From: gil at azul.com (Gil Tene) Date: Fri, 26 Apr 2019 16:22:37 +0000 Subject: OpenJDK Updates Project Builds In-Reply-To: <515BB18C-F37C-44F6-81ED-E71F4DEF5FDF@azul.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> Message-ID: > On Apr 26, 2019, at 7:47 AM, Gil Tene wrote: > > > > Sent from my iPad > > On Apr 26, 2019, at 5:28 AM, Severin Gehwolf > wrote: > > On Fri, 2019-04-26 at 14:11 +0200, Dalibor Topic wrote: > Hi, > > the Early Access (EA) builds on https://adoptopenjdk.net/upstream.html > are still confusingly versioned on that site, unfortunately. To quote > from [0]: > > "E.g. what tells an end user that +7 and +31 are release builds, but +6 > and +11 are not?" > > I'm not 100% clear what you mean. To answer the question: The filename? > "java -version" output? > > $ ls -1 > OpenJDK11U-x64_linux_11.0.3_6_ea.tar.gz > OpenJDK11U-x64_linux_11.0.3_7.tar.gz > > $ ./openjdk-11.0.3+6/bin/java -version > openjdk version "11.0.3-ea" 2019-04-16 > OpenJDK Runtime Environment 18.9 (build 11.0.3-ea+6) > OpenJDK 64-Bit Server VM 18.9 (build 11.0.3-ea+6, mixed mode) > > $ ./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) > > For JDK 8u it won't show up in the version output, but I'm not sure > that can be helped. Archive file names still have "ea" in their name > and the build numbers show up in version output so as to distinguish > them. > > I would highly recommend/request/beg/plead that the -version string of any posed EA builds be modified to clearly identify as EA (like the 11 builds do above). And that all current builds that don?t do that be taken down ASAP to prevent damage. > > This (EA builds of 8u that show -version numbers that look very much like releases but are not) is a very serious problem. The file name, the web link, and the text in the web page don?t survive installation. And what you have left around then is a ?mystery meat? JDK that made it into the wild. These things can (and do) then end up in places and situations where vast numbers of people end up using unreleased builds, often in production, without knowing it. > > For a concrete historical example of how bad something like this can (and did) get when you don?t take care to identify EA?ness in the actual version string output: Between Sep. 2014 and March 2015 (I.e. for the ~6 month period before 8u40 was actually released) running ?docker run java:8 -version? reported the version as 8u40, with nothing to indicate the JDK you were running was experimental or EA. This was a result of an unfortunate choice to take the blessed docker java image?s JDK from a Debian unstable release, which was building an unreleased OpenJDK (with the Debian folks probably thinking ?this Debian distro and repo are clearly unstable/experimental, so people would know not to take bits from it to production?). This JDK then ended up in the ?blessed? docker image for java, with nothing to identify it as a non-released JDK. And as a result everyone that read articles like https://blog.giantswarm.io/getting-started-with-java-development-on-docker/ ended up using an 8u40 that wasn?t 8u40 without knowing it, and with no obvious way to tell, even after the real 8 u40 was released. It is likely that millions of people were affected by this. > > Bottom line: Please please please don?t put up binary builds of non-released JDKs that do not clearly identify them as such in the version actual string output. And if you did, please tear them down ASAP to limit potential damage. for specific reference: If I go to https://adoptopenjdk.net/upstream.html And follow the link labeld "Linux x86_64 8u212-b02-ea" to https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/download/jdk8u212-b02/OpenJDK8U-x64_linux_8u212b02_ea.tar.gz And untar it It untar to a directory called openjdk-8u212-b02. If I then come back three months later looking for 8u212, I'll find this nice openjdk-8u212-b02 thing there, and if I run it I would see: gil at ubuntu:~/work/openjdk-8u212-b02$ bin/java -version openjdk version "1.8.0_212" OpenJDK Runtime Environment (build 1.8.0_212-b02) OpenJDK 64-Bit Server VM (build 25.212-b02, mixed mode) If I were super diligent about checking all build bumbers against konw build numbers of actual releases, I might notice that b02 was never released. But the likelihood of noticing that is very low? A "better named" directory might help a bit, but the only real place to label things is in the -version output. That's the thing all of us look at when we want to find our what a build actually is. > > > Thanks, > Severin > > > > cheers, > dalibor topic > > [0] > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000962.html > > On 16.04.2019 21:49, Dalibor Topic wrote: > On 15.04.2019 12:25, Andrew Haley wrote: > we now have early access > preview Linux and Windows binaries (currently x86-64 only) at > > https://adoptopenjdk.net/upstream.html > > I would suggest using the version nomenclature per JEP 322, i.e. > > "A version string is a version number, $VNUM, possibly followed by > pre-release, build, and other optional information, one of: > > $VNUM(-$PRE)?\+$BUILD(-$OPT)? > $VNUM-$PRE(-$OPT)? > $VNUM(+-$OPT)? > > where $PRE is a pre-release identifier (e.g., ea), $BUILD is a > build > number, and $OPT is optional build information." > > i.e. 11.0.3-ea+6, for example. > > cheers, > dalibor topic From neugens at redhat.com Fri Apr 26 16:29:16 2019 From: neugens at redhat.com (Mario Torre) Date: Fri, 26 Apr 2019 18:29:16 +0200 Subject: OpenJDK Updates Project Builds In-Reply-To: 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> Message-ID: I tend to agree with Gil here, it's a matter of consistency to have EA builds advertise as EA builds in the most clear way possible, as well as a courtesy. Cheers, Mario On Fri, Apr 26, 2019 at 6:23 PM Gil Tene wrote: > > > > > On Apr 26, 2019, at 7:47 AM, Gil Tene wrote: > > > > > > > > Sent from my iPad > > > > On Apr 26, 2019, at 5:28 AM, Severin Gehwolf > wrote: > > > > On Fri, 2019-04-26 at 14:11 +0200, Dalibor Topic wrote: > > Hi, > > > > the Early Access (EA) builds on https://adoptopenjdk.net/upstream.html > > are still confusingly versioned on that site, unfortunately. To quote > > from [0]: > > > > "E.g. what tells an end user that +7 and +31 are release builds, but +6 > > and +11 are not?" > > > > I'm not 100% clear what you mean. To answer the question: The filename? > > "java -version" output? > > > > $ ls -1 > > OpenJDK11U-x64_linux_11.0.3_6_ea.tar.gz > > OpenJDK11U-x64_linux_11.0.3_7.tar.gz > > > > $ ./openjdk-11.0.3+6/bin/java -version > > openjdk version "11.0.3-ea" 2019-04-16 > > OpenJDK Runtime Environment 18.9 (build 11.0.3-ea+6) > > OpenJDK 64-Bit Server VM 18.9 (build 11.0.3-ea+6, mixed mode) > > > > $ ./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) > > > > For JDK 8u it won't show up in the version output, but I'm not sure > > that can be helped. Archive file names still have "ea" in their name > > and the build numbers show up in version output so as to distinguish > > them. > > > > I would highly recommend/request/beg/plead that the -version string of any posed EA builds be modified to clearly identify as EA (like the 11 builds do above). And that all current builds that don?t do that be taken down ASAP to prevent damage. > > > > This (EA builds of 8u that show -version numbers that look very much like releases but are not) is a very serious problem. The file name, the web link, and the text in the web page don?t survive installation. And what you have left around then is a ?mystery meat? JDK that made it into the wild. These things can (and do) then end up in places and situations where vast numbers of people end up using unreleased builds, often in production, without knowing it. > > > > For a concrete historical example of how bad something like this can (and did) get when you don?t take care to identify EA?ness in the actual version string output: Between Sep. 2014 and March 2015 (I.e. for the ~6 month period before 8u40 was actually released) running ?docker run java:8 -version? reported the version as 8u40, with nothing to indicate the JDK you were running was experimental or EA. This was a result of an unfortunate choice to take the blessed docker java image?s JDK from a Debian unstable release, which was building an unreleased OpenJDK (with the Debian folks probably thinking ?this Debian distro and repo are clearly unstable/experimental, so people would know not to take bits from it to production?). This JDK then ended up in the ?blessed? docker image for java, with nothing to identify it as a non-released JDK. And as a result everyone that read articles like https://blog.giantswarm.io/getting-started-with-java-development-on-docker/ ended up using an 8u40 that wasn?t 8u40 without knowing it, and with no obvious way to tell, even after the real 8 u40 was released. It is likely that millions of people were affected by this. > > > > Bottom line: Please please please don?t put up binary builds of non-released JDKs that do not clearly identify them as such in the version actual string output. And if you did, please tear them down ASAP to limit potential damage. > > for specific reference: > > If I go to https://adoptopenjdk.net/upstream.html > > And follow the link labeld "Linux x86_64 8u212-b02-ea" to https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/download/jdk8u212-b02/OpenJDK8U-x64_linux_8u212b02_ea.tar.gz > > And untar it > > It untar to a directory called openjdk-8u212-b02. > > If I then come back three months later looking for 8u212, I'll find this nice openjdk-8u212-b02 thing there, and if I run it I would see: > > gil at ubuntu:~/work/openjdk-8u212-b02$ bin/java -version > openjdk version "1.8.0_212" > OpenJDK Runtime Environment (build 1.8.0_212-b02) > OpenJDK 64-Bit Server VM (build 25.212-b02, mixed mode) > > If I were super diligent about checking all build bumbers against konw build numbers of actual releases, I might notice that b02 was never released. But the likelihood of noticing that is very low? > > A "better named" directory might help a bit, but the only real place to label things is in the -version output. That's the thing all of us look at when we want to find our what a build actually is. > > > > > > > Thanks, > > Severin > > > > > > > > cheers, > > dalibor topic > > > > [0] > > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000962.html > > > > On 16.04.2019 21:49, Dalibor Topic wrote: > > On 15.04.2019 12:25, Andrew Haley wrote: > > we now have early access > > preview Linux and Windows binaries (currently x86-64 only) at > > > > https://adoptopenjdk.net/upstream.html > > > > I would suggest using the version nomenclature per JEP 322, i.e. > > > > "A version string is a version number, $VNUM, possibly followed by > > pre-release, build, and other optional information, one of: > > > > $VNUM(-$PRE)?\+$BUILD(-$OPT)? > > $VNUM-$PRE(-$OPT)? > > $VNUM(+-$OPT)? > > > > where $PRE is a pre-release identifier (e.g., ea), $BUILD is a > > build > > number, and $OPT is optional build information." > > > > i.e. 11.0.3-ea+6, for example. > > > > cheers, > > dalibor topic > -- 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 Apr 26 17:10:25 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 26 Apr 2019 17:10:25 +0000 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> Message-ID: Hi Andrew, > >>> March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) > >>> ================= RDP1 > ===================================== > >>> = 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 RDP1 build (tag: jdk-11.0.4+5) > >>> ================= RDP2 > ===================================== > >>> = jdk11u tree gets changes only by jdk11u-critical-request = > >>> > ========================================================== > >>> == > >>> Wednesday, June 5, 2019: First RDP2 build (tag: jdk-11.0.4+6) > >>> Wednesday, June 12, 2019: Second RDP2 build (tag: jdk-11.0.4+7) > >>> Wednesday, June 19, 2019: Third RDP2 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) > >>> > >>> This allows regular testing earlier in the cycle, but without > >>> restricting the process down to critical fixes early. > >> > >> Sounds like a good suggestion to me as I can see the need to have EA > builds early. > >> I think technically we should then tag in jdk11u-dev/jdk8u-dev until the > 29th of May and pull these tags into jdk11u/jdk8u. > >> We'll have to confirm with ops whether this will correctly resolve the bugs > in JBS (e.g. with the right build associated). > > > > +1 > > > > Thanks, > > Severin > > > > That sounds sensible. My primary concern is that something is available > and tagged in 8u/11u for people not necessarily active in development to > consume and test, perhaps first integrating into downstream repositories > as we do with our Shenandoah repositories. I don't fully get your point here... so, are you saying we should also tag in jdk8u/jdk11u vs jdk8u-dev/jdk11u-dev until RDP2? The former has the disadvantage that there's some more merging back and forth and we'll probably see more merge changesets... Or do you mean to say something else? ?? Thanks Christoph From gnu.andrew at redhat.com Fri Apr 26 17:18:11 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 26 Apr 2019 18:18:11 +0100 Subject: OpenJDK Updates Project Builds In-Reply-To: <515BB18C-F37C-44F6-81ED-E71F4DEF5FDF@azul.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> Message-ID: On 26/04/2019 15:47, Gil Tene wrote: > snip... > I would highly recommend/request/beg/plead that the -version string of any posed EA builds be modified to clearly identify as EA (like the 11 builds do above). And that all current builds that don?t do that be taken down ASAP to prevent damage. > > This (EA builds of 8u that show -version numbers that look very much like releases but are not) is a very serious problem. The file name, the web link, and the text in the web page don?t survive installation. And what you have left around then is a ?mystery meat? JDK that made it into the wild. These things can (and do) then end up in places and situations where vast numbers of people end up using unreleased builds, often in production, without knowing it. > > For a concrete historical example of how bad something like this can (and did) get when you don?t take care to identify EA?ness in the actual version string output: Between Sep. 2014 and March 2015 (I.e. for the ~6 month period before 8u40 was actually released) running ?docker run java:8 -version? reported the version as 8u40, with nothing to indicate the JDK you were running was experimental or EA. This was a result of an unfortunate choice to take the blessed docker java image?s JDK from a Debian unstable release, which was building an unreleased OpenJDK (with the Debian folks probably thinking ?this Debian distro and repo are clearly unstable/experimental, so people would know not to take bits from it to production?). This JDK then ended up in the ?blessed? docker image for java, with nothing to identify it as a non-released JDK. And as a result everyone that read articles like https://blog.giantswarm.io/getting-started-with-java-development-on-docker/ ended up using an 8u40 that wasn?t 8u40 without knowing it, and with no obvious way to tell, even after the real 8 u40 was released. It is likely that millions of people were affected by this. > > Bottom line: Please please please don?t put up binary builds of non-released JDKs that do not clearly identify them as such in the version actual string output. And if you did, please tear them down ASAP to limit potential damage. > > > Thanks, > Severin > 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. Further to that, I was musing over the idea earlier in the week that we should have better defaults for versioning in 8u. At present, downstreams have to add the update & build numbers, with the default being along the lines of: $ /mnt/builder/8u-dev/images/j2sdk-image/bin/java -version openjdk version "1.8.0-internal" OpenJDK Runtime Environment (build 1.8.0-internal-andre_2019_04_25_05_13-b00) OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode) Unlike 11, the version numbers are not included in common/autoconf/version-numbers, but instead have to be set by downstreams. I feel, if we have better defaults there, there would be less cause for downstream builds to set these values and cause divergence. That would mean updating these values in OpenJDK as part of the tagging process, and explicitly removing and re-adding "ea" either side of "ga". However, I do take issue with this idea of a "real 8u40". What would that be? Is it the vanilla OpenJDK sources as tagged? With those early releases, it's not even obvious from the repositories which is "ga". If that is the "real 8u40", then few people are using it, because Oracle's 8u40 diverges from upstream, as do most other downstreams packaged in various distributions and the like. For instance, anyone using 8u with the AArch32 or AArch64 ports does not have the "real" 8u because those ports are added downstream in the appropriate projects. So, while I agree that we should make clear which builds produced by the OpenJDK projects are intended for production use and which aren't, the idea that a particular update designation such as "8u40" in a build always refers to one built from the same exact set of sources is fanciful at best. The end user needs to be aware of where they are obtaining their builds from and what that entails. 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 Apr 26 17:24:57 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 26 Apr 2019 18:24:57 +0100 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> Message-ID: On 26/04/2019 18:10, Langer, Christoph wrote: snip.. > > I don't fully get your point here... so, are you saying we should also tag in jdk8u/jdk11u vs jdk8u-dev/jdk11u-dev until RDP2? > > The former has the disadvantage that there's some more merging back and forth and we'll probably see more merge changesets... > > Or do you mean to say something else? ?? > > Thanks > Christoph > I was agreeing with what I interpreted you to be saying, which I believe was: During RDP1: 1. Tag in jdk8u-dev/jdk11u-dev 2. Pull into jdk8u / jdk11u and thus the tag will be in both repositories. In RDP2: 1. Tag in jdk8u / jdk11u 2. Pull into jdk8u-dev / jdk11u-dev with again the end result being that the tag is in both repos. During both stages, someone not involved in development can ignore jdk8u-dev & jdk11u-dev and just pull each new tag from jdk8u & jdk11u for builds & testing. I think that keeps things simpler for downstreams who primarily want to consume the results rather than participate in their production. Hope that's clearer, -- 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 Apr 26 18:35:06 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 26 Apr 2019 18:35:06 +0000 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> Message-ID: > -----Original Message----- > From: Andrew John Hughes > Sent: Freitag, 26. April 2019 19:25 > To: Langer, Christoph > Cc: Severin Gehwolf ; 'jdk8u- > dev at openjdk.java.net' ; Andrew Haley > ; Aleksey Shipilev ; jdk-updates- > dev at openjdk.java.net; Lindenmaier, Goetz > Subject: Re: [11u]: 8u222 & 11.0.4 release schedule > > > > On 26/04/2019 18:10, Langer, Christoph wrote: > > snip.. > > > > > I don't fully get your point here... so, are you saying we should also tag in > jdk8u/jdk11u vs jdk8u-dev/jdk11u-dev until RDP2? > > > > The former has the disadvantage that there's some more merging back and > forth and we'll probably see more merge changesets... > > > > Or do you mean to say something else? ?? > > > > Thanks > > Christoph > > > > I was agreeing with what I interpreted you to be saying, which I believe > was: > > During RDP1: > > 1. Tag in jdk8u-dev/jdk11u-dev > 2. Pull into jdk8u / jdk11u > > and thus the tag will be in both repositories. > > In RDP2: > > 1. Tag in jdk8u / jdk11u > 2. Pull into jdk8u-dev / jdk11u-dev > > with again the end result being that the tag is in both repos. > > During both stages, someone not involved in development can ignore > jdk8u-dev & jdk11u-dev and just pull each new tag from jdk8u & jdk11u > for builds & testing. > > I think that keeps things simpler for downstreams who primarily want to > consume the results rather than participate in their production. > > Hope that's clearer, Ah, I see. So, yes, we're in full understanding and agreement then. ?? /Christoph From gil at azul.com Fri Apr 26 23:18:06 2019 From: gil at azul.com (Gil Tene) Date: Fri, 26 Apr 2019 23:18:06 +0000 Subject: OpenJDK Updates Project Builds In-Reply-To: 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> Message-ID: <2D43C7EE-CF58-46CB-BBA2-02A343377624@azul.com> > On Apr 26, 2019, at 10:18 AM, Andrew John Hughes wrote: > > > > On 26/04/2019 15:47, Gil Tene wrote: >> > snip... > >> I would highly recommend/request/beg/plead that the -version string of any posed EA builds be modified to clearly identify as EA (like the 11 builds do above). And that all current builds that don?t do that be taken down ASAP to prevent damage. >> >> This (EA builds of 8u that show -version numbers that look very much like releases but are not) is a very serious problem. The file name, the web link, and the text in the web page don?t survive installation. And what you have left around then is a ?mystery meat? JDK that made it into the wild. These things can (and do) then end up in places and situations where vast numbers of people end up using unreleased builds, often in production, without knowing it. >> >> For a concrete historical example of how bad something like this can (and did) get when you don?t take care to identify EA?ness in the actual version string output: Between Sep. 2014 and March 2015 (I.e. for the ~6 month period before 8u40 was actually released) running ?docker run java:8 -version? reported the version as 8u40, with nothing to indicate the JDK you were running was experimental or EA. This was a result of an unfortunate choice to take the blessed docker java image?s JDK from a Debian unstable release, which was building an unreleased OpenJDK (with the Debian folks probably thinking ?this Debian distro and repo are clearly unstable/experimental, so people would know not to take bits from it to production?). This JDK then ended up in the ?blessed? docker image for java, with nothing to identify it as a non-released JDK. And as a result everyone that read articles like https://blog.giantswarm.io/getting-started-with-java-development-on-docker/ ended up using an 8u40 that wasn?t 8u40 without knowing it, and with no obvious way to tell, even after the real 8 u40 was released. It is likely that millions of people were affected by this. >> >> Bottom line: Please please please don?t put up binary builds of non-released JDKs that do not clearly identify them as such in the version actual string output. And if you did, please tear them down ASAP to limit potential damage. >> >> >> Thanks, >> Severin >> > > 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. > > Further to that, I was musing over the idea earlier in the week that we > should have better defaults for versioning in 8u. At present, > downstreams have to add the update & build numbers, with the default > being along the lines of: > > $ /mnt/builder/8u-dev/images/j2sdk-image/bin/java -version > openjdk version "1.8.0-internal" > OpenJDK Runtime Environment (build > 1.8.0-internal-andre_2019_04_25_05_13-b00) > OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode) > > Unlike 11, the version numbers are not included in > common/autoconf/version-numbers, but instead have to be set by > downstreams. I feel, if we have better defaults there, there would be > less cause for downstream builds to set these values and cause > divergence. That would mean updating these values in OpenJDK as part of > the tagging process, and explicitly removing and re-adding "ea" either > side of "ga". > > However, I do take issue with this idea of a "real 8u40". What would > that be? Is it the vanilla OpenJDK sources as tagged? I'm in no way saying that "8u40" identifies a specific build or a specific set of code. What I am saying is that before 8u40 was actually released (in the project, with a known set of code for it's "ga"), nothing else can be called 8u40 (without a clear "this is not the final 8u40" thing in the version string) without sowing lasting confusion. IMO anything reporting as e.g. "8u40" after the GA is purporting to be "based on" the actual GA'ed 8u40. It can include significant changes (as do some downstream variants) and still call itself 8u40 IMO. However, "I'll replace half the code but still have an identical version string output" is probably bad practice. When a build significantly differs in functionality from what a vanilla build of the same GA'ed version name in the OpenJDK 8u project sources would be, it should probably clearly identify itself as something else in the version string as well. Most of us seem to do that clearly with things like "IcedTea", "Zulu", "Corretto", "AdoptOpenJDK", etc. sowing up in e.g. the second line of the version string. > With those early > releases, it's not even obvious from the repositories which is "ga". It's pretty clear what "GA" for 8u40 was: https://wiki.openjdk.java.net/display/jdk8u/JDK+8u40 And this was not that early. This was a year into 8u. Well beyond where e.g. 11u is right now. > If that is the "real 8u40", then few people are using it, because Oracle's > 8u40 diverges from upstream, as do most other downstreams packaged in > various distributions and the like. I'd bet tens of millions of installations were running various OpenJDK 8u builds by the date that this "fake 8u40" was no longer the thing that "docker run java" was giving you. And because of the unfortunate seepage of this specific example into docker's "blessed" images for java:8 for a period of 6 months, millions of instances were likely running something that was quite different from what they thought it was. Real releases were being made (e.g. both 8u25 and 8u31 happened during this timeframe), but docker java:8 users would have seen this "fake 8u40" instead without knowing it. > For instance, anyone using 8u with > the AArch32 or AArch64 ports does not have the "real" 8u because those > ports are added downstream in the appropriate projects. I would hope that when AArch32 and AArch64 builds calling themselves 8u40 (or any other version) without some clear EA marking, they would be based on the source code in 8u40, and not on some snapshot of that code's evolution 5 months before GA. > > So, while I agree that we should make clear which builds produced by the > OpenJDK projects are intended for production use and which aren't, the > idea that a particular update designation such as "8u40" in a build > always refers to one built from the same exact set of sources is > fanciful at best. We agree that there is no "same exact set of sources" meaning here. And I suspect that we also agreed that it should be "based on the actually released set of sources". > The end user needs to be aware of where they are > obtaining their builds from and what that entails. That's a pretty impossible thing to ask the "end user" of an installed JDK or a docker image. Such users can only practically verify the thing they are running by asking it what it is (with e.g. -version). If such users know that they got their stuff "from a reputable source" (e.g. they rememeber that they only downloaded their JDKs from https://adoptopenjdk.net/upstream.html, or from the docker hub's blessed "java" image), they will tend to trust that the -version update means what it says, even when they run the java -version command months after they installed the JDK. This is why reputable sources should never provide early access builds with version output that does not clearly identify them as such. > > > 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 me at basilcrow.com Sun Apr 28 19:37:49 2019 From: me at basilcrow.com (Basil Crow) Date: Sun, 28 Apr 2019 12:37:49 -0700 Subject: Request for Backport of JDK-8159127 hprof heap dumps broken for lambda classdata Message-ID: Hi all, I am writing to request a backport of JDK-8159127 to 8u. My high-level goal is to extract a usable hprof heap from a core file of a Java program where lambdas are in use. By "usable" I mean that finding objects by retained size in VisualVM should work. This works in 9u and later, but it does not work in 8u due to JDK-8159127. Note that a usable hprof heap dump is generated in 8u when a live process (rather than a core file) is used or when lambdas are not in use, as described in JDK-8159127. This bug effectively prevents one from debugging memory leaks from core dumps on 8u. Unfortunately, I don't think the backport will be trivial. I applied the fixes from JDK-8159127 onto 8u. Apart from file renames and a trivial merge conflict in vmStructs.cpp, I was able to apply all the changes and build a JDK. All existing automated tests still passed, but the new automated test added in JDK-8159127 did not run for some reason. I then tried to verify the fix with a manual test (described below), which failed. It is clear that further work is required for this backport. As someone who just built OpenJDK for the first time minutes ago, I am likely not the best candidate to do this work. For anyone who is interested in taking this on, here is the procedure I used for manual testing. This is the same procedure I described in JDK-8159127, but with some additional clarifications. First, build and run the test program: $ cat LambdaSleep.java import java.util.Arrays; public class LambdaSleep { public static void main(String[] args) throws InterruptedException { String[] words = new String[] {"longer", "short"}; Arrays.sort(words, (first, second) -> Integer.compare(first.length(), second.length())); Thread.sleep(300000); } } $ javac LambdaSleep.java $ java LambdaSleep & [1] 4528 Next, we'll take two heap dumps of this program. The first, live4528.hprof, comes from the live process: $ jmap -dump:format=b,file=live4528.hprof 4528 Heap dump file created The second, core4528.hprof, comes from a core dump. First, let's take the core dump: # gcore 4528 [...] Saved corefile core.4528 [Inferior 1 (process 4528) detached] Next, let's generate an hprof heap dump from the core dump. In 9u and later, this is done with jhsdb(1): $ jhsdb jmap --binaryheap --dumpfile core4528.hprof --exe $JAVA_HOME/bin/java --core core.4528 Attaching to core core.4528 from executable /opt/jdk-11.0.3+7/bin/java, please wait... Debugger attached successfully. Server compiler detected. JVM version is 11.0.3+7 heap written to core4528.hprof In 8u, this is done with jmap(1): $ jmap -dump:format=b,file=core4528.hprof /opt/jdk/bin/java core.4528 Attaching to core core.4528 from executable /opt/jdk/bin/java, please wait... Debugger attached successfully. Server compiler detected. JVM version is 25.60-b23 Dumping heap to core4528.hprof ... Heap dump file created Either way, we now have two hprof heap dumps, which should be functionally identical when used in VisualVM. Next, open each hprof heap dump in VisualVM and attempt to find objects by retained size. For the heap dump generated from the live process, this will work for all Java versions. For the heap dump generated from the core file, this will only work in 9u and later, due to JDK-8159127. On 8u, VisualVM will hang on "computing retained sizes." After applying the patches from JDK-8159127 onto 8u, the hang no longer occurred, but VisualVM threw a NullPointerException instead. To complete this backport, this should be investigated. It also remains unclear why the automated test didn't run on 8u. Note that Eclipse MAT prior to 1.6.1 also used to crash when presented with these bad hprof heap dumps. However, as of 1.6.1, a workaround [1] was put in place that substitutes dummy classes for the missing information from the bad hprof heap dump. Therefore I recommend testing with VisualVM, which still fails explicitly when a bad hprof heap dump is encountered. Thanks in advance from the production debugging trenches! Basil [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=471757 From sgehwolf at redhat.com Mon Apr 29 08:40:49 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 29 Apr 2019 10:40:49 +0200 Subject: OpenJDK Updates Project Builds In-Reply-To: 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> Message-ID: <19529ef56caca7311d40fdb51bee0e27a3cefb86.camel@redhat.com> 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. Thanks, Severin From dalibor.topic at oracle.com Mon Apr 29 09:44:10 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Mon, 29 Apr 2019 11:44:10 +0200 Subject: OpenJDK Updates Project Builds In-Reply-To: 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> <12978a20-3fc7-9629-bfca-556ec45040c3@oracle.com> <4e23c04630da5fd08753327b4d408c32be84838e.camel@redhat.com> <3d864740-027b-60b5-db57-7696f8d71fad@oracle.com> Message-ID: Thank you, Martijn. As I pointed out in https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009113.html the JEP 322 version nomenclature is "A version string is a version number, $VNUM, possibly followed by pre-release, build, and other optional information, one of: $VNUM(-$PRE)?\+$BUILD(-$OPT)? $VNUM-$PRE(-$OPT)? $VNUM(+-$OPT)? where $PRE is a pre-release identifier (e.g., ea), $BUILD is a build number, and $OPT is optional build information." i.e. the anchor text should be 11.0.3-ea+6, for example, rather than 11.0.3+6-ea. The component after the build number, $OPT, is used to denote a series of releases for which an implementor offers long-term support e.g., 11.0.2+13-LTS, rather than Early Access status of individual builds. cheers, dalibor topic On 26.04.2019 15:59, Martijn Verburg wrote: > Bug reports and Pull Requests welcome > https://www.github.com/adoptopenjdk/openjdk-website ;-) > > In all seriousness - closed via > https://github.com/AdoptOpenJDK/openjdk-website/pull/471 > > Cheers, > Martijn > > > On Fri, 26 Apr 2019 at 14:27, Dalibor Topic > wrote: > > On 26.04.2019 15:06, Severin Gehwolf wrote: > > > There are two separate tables, though. One for the release bits and > > another for EA. In addition to that, the rows in corresponding tables > > are "OpenJDK X" for release and "OpenJDK X EA" for EA. Do we really > > need another "ea" added somewhere? For brevity in the table I'd > rather > > not. That's just my opinion, though. > > My experience has been that some users can get confused if (i.e. in > your > case: when) there is a build with a 'higher' version than a GA release > that's not clearly recognizable as an Early Access build in all > possible > ways. > > Basically, not everyone is necessarily an expert at JDK development or > its versioning. ;) > > 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 > -- 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 martijnverburg at gmail.com Mon Apr 29 09:52:53 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 29 Apr 2019 10:52:53 +0100 Subject: OpenJDK Updates Project Builds In-Reply-To: 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> <12978a20-3fc7-9629-bfca-556ec45040c3@oracle.com> <4e23c04630da5fd08753327b4d408c32be84838e.camel@redhat.com> <3d864740-027b-60b5-db57-7696f8d71fad@oracle.com> Message-ID: Hi Dalibor, Sure thing, I'll pick that up in my next sweep. Cheers, Martijn On Mon, 29 Apr 2019 at 10:44, Dalibor Topic wrote: > Thank you, Martijn. > > As I pointed out in > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009113.html > the JEP 322 version nomenclature is > > "A version string is a version number, $VNUM, possibly followed by > pre-release, build, and other optional information, one of: > > $VNUM(-$PRE)?\+$BUILD(-$OPT)? > $VNUM-$PRE(-$OPT)? > $VNUM(+-$OPT)? > > where $PRE is a pre-release identifier (e.g., ea), $BUILD is a build > number, and $OPT is optional build information." > > i.e. the anchor text should be 11.0.3-ea+6, for example, rather than > 11.0.3+6-ea. > > The component after the build number, $OPT, is used to denote a series > of releases for which an implementor offers long-term support e.g., > 11.0.2+13-LTS, rather than Early Access status of individual builds. > > cheers, > dalibor topic > > On 26.04.2019 15:59, Martijn Verburg wrote: > > Bug reports and Pull Requests welcome > > https://www.github.com/adoptopenjdk/openjdk-website ;-) > > > > In all seriousness - closed via > > https://github.com/AdoptOpenJDK/openjdk-website/pull/471 > > > > Cheers, > > Martijn > > > > > > On Fri, 26 Apr 2019 at 14:27, Dalibor Topic > > wrote: > > > > On 26.04.2019 15:06, Severin Gehwolf wrote: > > > > > There are two separate tables, though. One for the release bits > and > > > another for EA. In addition to that, the rows in corresponding > tables > > > are "OpenJDK X" for release and "OpenJDK X EA" for EA. Do we > really > > > need another "ea" added somewhere? For brevity in the table I'd > > rather > > > not. That's just my opinion, though. > > > > My experience has been that some users can get confused if (i.e. in > > your > > case: when) there is a build with a 'higher' version than a GA > release > > that's not clearly recognizable as an Early Access build in all > > possible > > ways. > > > > Basically, not everyone is necessarily an expert at JDK development > or > > its versioning. ;) > > > > 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 > > > > -- > 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 goetz.lindenmaier at sap.com Mon Apr 29 09:54:08 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 29 Apr 2019 09:54:08 +0000 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> Message-ID: Hi, OK, as the majority seems to agree, let's push the split between jdk11u-dev and jdk11u to 28.5.2018. > During RDP1: > 1. Tag in jdk8u-dev/jdk11u-dev > 2. Pull into jdk8u / jdk11u I would like to express this differently though. I would not announce that we tag in jdk11u-dev and later in jdk11u. This can be confusing. I would phrase this differently: "From 1.5 to 28.5 merges from jdk11u-dev to jdk11u will be done weekly before tagging jdk11u." Or better: "Before RDP2, merges from jdk11u-dev to jdk11u will be done weekly before tagging jdk11u." Then, tags are always done in jdk11u, and then merged to jdk11u-dev. Also, we need to state that jdk11.0.5 development only starts on 29.5.2019. Else, it would have started 2.5.2019. And, do I understand correctly, you want to enforce RDP1 restrictions on both repos starting 1.5.2019? That would mean you can not push enhancements to jdk11u at all for four weeks! https://openjdk.java.net/jeps/3 Best regards, Goetz. > -----Original Message----- > From: Andrew John Hughes > Sent: Freitag, 26. April 2019 19:25 > To: Langer, Christoph > Cc: Severin Gehwolf ; 'jdk8u-dev at openjdk.java.net' > ; Andrew Haley ; Aleksey > Shipilev ; jdk-updates-dev at openjdk.java.net; > Lindenmaier, Goetz > Subject: Re: [11u]: 8u222 & 11.0.4 release schedule > > > > On 26/04/2019 18:10, Langer, Christoph wrote: > > snip.. > > > > > I don't fully get your point here... so, are you saying we should also tag in > jdk8u/jdk11u vs jdk8u-dev/jdk11u-dev until RDP2? > > > > The former has the disadvantage that there's some more merging back and > forth and we'll probably see more merge changesets... > > > > Or do you mean to say something else? ?? > > > > Thanks > > Christoph > > > > I was agreeing with what I interpreted you to be saying, which I believe > was: > > > and thus the tag will be in both repositories. > > In RDP2: > > 1. Tag in jdk8u / jdk11u > 2. Pull into jdk8u-dev / jdk11u-dev > > with again the end result being that the tag is in both repos. > > During both stages, someone not involved in development can ignore > jdk8u-dev & jdk11u-dev and just pull each new tag from jdk8u & jdk11u > for builds & testing. > > I think that keeps things simpler for downstreams who primarily want to > consume the results rather than participate in their production. > > Hope that's clearer, > -- > 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 Apr 29 10:52:01 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Mon, 29 Apr 2019 12:52:01 +0200 Subject: OpenJDK Updates Project Builds In-Reply-To: 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> <12978a20-3fc7-9629-bfca-556ec45040c3@oracle.com> <4e23c04630da5fd08753327b4d408c32be84838e.camel@redhat.com> <3d864740-027b-60b5-db57-7696f8d71fad@oracle.com> Message-ID: <9c930903-83ee-23db-594d-7035cdff7610@oracle.com> Thank you very much, Martijn. cheers, dalibor topic On 29.04.2019 11:52, Martijn Verburg wrote: > Hi Dalibor, > > Sure thing, I'll pick that up in my next sweep. > > Cheers, > Martijn > > > On Mon, 29 Apr 2019 at 10:44, Dalibor Topic > wrote: > > Thank you, Martijn. > > As I pointed out in > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009113.html > > the JEP 322 version nomenclature is > > "A version string is a version number, $VNUM, possibly followed by > pre-release, build, and other optional information, one of: > > $VNUM(-$PRE)?\+$BUILD(-$OPT)? > $VNUM-$PRE(-$OPT)? > $VNUM(+-$OPT)? > > where $PRE is a pre-release identifier (e.g., ea), $BUILD is a build > number, and $OPT is optional build information." > > i.e. the anchor text should be 11.0.3-ea+6, for example, rather than > 11.0.3+6-ea. > > The component after the build number, $OPT, is used to denote a series > of releases for which an implementor offers long-term support e.g., > 11.0.2+13-LTS, rather than Early Access status of individual builds. > > cheers, > dalibor topic > > On 26.04.2019 15:59, Martijn Verburg wrote: > > Bug reports and Pull Requests welcome > > https://www.github.com/adoptopenjdk/openjdk-website ;-) > > > > In all seriousness - closed via > > https://github.com/AdoptOpenJDK/openjdk-website/pull/471 > > > > Cheers, > > Martijn > > > > > > On Fri, 26 Apr 2019 at 14:27, Dalibor Topic > > > >> wrote: > > > >? ? ?On 26.04.2019 15:06, Severin Gehwolf wrote: > > > >? ? ? > There are two separate tables, though. One for the release > bits and > >? ? ? > another for EA. In addition to that, the rows in > corresponding tables > >? ? ? > are "OpenJDK X" for release and "OpenJDK X EA" for EA. Do > we really > >? ? ? > need another "ea" added somewhere? For brevity in the > table I'd > >? ? ?rather > >? ? ? > not. That's just my opinion, though. > > > >? ? ?My experience has been that some users can get confused if > (i.e. in > >? ? ?your > >? ? ?case: when) there is a build with a 'higher' version than a > GA release > >? ? ?that's not clearly recognizable as an Early Access build in all > >? ? ?possible > >? ? ?ways. > > > >? ? ?Basically, not everyone is necessarily an expert at JDK > development or > >? ? ?its versioning. ;) > > > >? ? ?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 > > > > -- > 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 > -- 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 gnu.andrew at redhat.com Mon Apr 29 14:03:46 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 29 Apr 2019 15:03:46 +0100 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> Message-ID: <833668ba-d134-fdd0-2363-f682b19eced7@redhat.com> On 29/04/2019 10:54, Lindenmaier, Goetz wrote: > Hi, > > OK, as the majority seems to agree, let's push the > split between jdk11u-dev and jdk11u to 28.5.2018. > This is my latest proposal [0]: March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) ================= RDP1 ===================================== = 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 RDP1 build (tag: jdk-11.0.4+5) ================= RDP2 ===================================== = jdk11u tree gets changes only by jdk11u-critical-request = ============================================================ Wednesday, June 5, 2019: First RDP2 build (tag: jdk-11.0.4+6) Wednesday, June 12, 2019: Second RDP2 build (tag: jdk-11.0.4+7) Wednesday, June 19, 2019: Third RDP2 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 yes, the split would be 2019-05-28 (which I presume is what you meant, not 2018 :) ) but the first merge to jdk11u would be this Wednesday. [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/001005.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 gil at azul.com Mon Apr 29 14:18:29 2019 From: gil at azul.com (Gil Tene) Date: Mon, 29 Apr 2019 14:18:29 +0000 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: <7A1DE69A-1763-48F6-ADA9-8D2D842124F6@azul.com> +1 Sent from my iPad > On Apr 29, 2019, at 1:41 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. > > Thanks, > Severin From goetz.lindenmaier at sap.com Mon Apr 29 14:22:28 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 29 Apr 2019 14:22:28 +0000 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: <833668ba-d134-fdd0-2363-f682b19eced7@redhat.com> References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> <833668ba-d134-fdd0-2363-f682b19eced7@redhat.com> Message-ID: Hi Andrew, yes, this is the same as what I tried to phrase. Just one thing: you are mentioning RDP1. How do you want to handle this? Will we announce that only P1-P3 bugs (no P4,P5, no enhancements of priority P1-P5) may be pushed to jdk11u-dev starting tomorrow? This is what https://openjdk.java.net/jeps/3 is saying and how jdk development is handled. Or should we just say jdk11u-dev is open for development, i.e., any changes, until RDP2? And leave out mentioning RDP1. Best regards, Goetz. > -----Original Message----- > From: Andrew John Hughes > Sent: Montag, 29. April 2019 16:04 > To: Lindenmaier, Goetz ; 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 > > > > On 29/04/2019 10:54, Lindenmaier, Goetz wrote: > > Hi, > > > > OK, as the majority seems to agree, let's push the > > split between jdk11u-dev and jdk11u to 28.5.2018. > > > > This is my latest proposal [0]: > > March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) > ================= RDP1 ===================================== > = 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 RDP1 build (tag: jdk-11.0.4+5) > ================= RDP2 ===================================== > = jdk11u tree gets changes only by jdk11u-critical-request = > ============================================================ > Wednesday, June 5, 2019: First RDP2 build (tag: jdk-11.0.4+6) > Wednesday, June 12, 2019: Second RDP2 build (tag: jdk-11.0.4+7) > Wednesday, June 19, 2019: Third RDP2 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 yes, the split would be 2019-05-28 (which I presume is what you > meant, not 2018 :) ) but the first merge to jdk11u would be this Wednesday. > > [0] > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019- > April/001005.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 goetz.lindenmaier at sap.com Mon Apr 29 14:50:54 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 29 Apr 2019 14:50:54 +0000 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: <833668ba-d134-fdd0-2363-f682b19eced7@redhat.com> References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> <833668ba-d134-fdd0-2363-f682b19eced7@redhat.com> Message-ID: Hi, 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 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. 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 Best regards, Goetz. I would pick a change in jdk11u-dev before Tuesday 18:00 CET and run tests on this, and push it to jdk11u on Wednesday including the tag if all went fine. This would continue the same > -----Original Message----- > From: Andrew John Hughes > Sent: Montag, 29. April 2019 16:04 > To: Lindenmaier, Goetz ; 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 > > > > On 29/04/2019 10:54, Lindenmaier, Goetz wrote: > > Hi, > > > > OK, as the majority seems to agree, let's push the > > split between jdk11u-dev and jdk11u to 28.5.2018. > > > > This is my latest proposal [0]: > > March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) > ================= RDP1 ===================================== > = 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 RDP1 build (tag: jdk-11.0.4+5) > ================= RDP2 ===================================== > = jdk11u tree gets changes only by jdk11u-critical-request = > ============================================================ > Wednesday, June 5, 2019: First RDP2 build (tag: jdk-11.0.4+6) > Wednesday, June 12, 2019: Second RDP2 build (tag: jdk-11.0.4+7) > Wednesday, June 19, 2019: Third RDP2 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 yes, the split would be 2019-05-28 (which I presume is what you > meant, not 2018 :) ) but the first merge to jdk11u would be this Wednesday. > > [0] > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019- > April/001005.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 Mon Apr 29 17:24:46 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 29 Apr 2019 18:24:46 +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: <40f66d37-6ad3-fc23-42a0-399790eac4f8@redhat.com> On 29/04/2019 15:22, Lindenmaier, Goetz wrote: > Hi Andrew, > > yes, this is the same as what I tried to phrase. > > Just one thing: you are mentioning RDP1. > How do you want to handle this? > Will we announce that only P1-P3 bugs (no P4,P5, > no enhancements of priority P1-P5) may be pushed > to jdk11u-dev starting tomorrow? > This is what https://openjdk.java.net/jeps/3 is saying > and how jdk development is handled. > > Or should we just say jdk11u-dev is open for development, > i.e., any changes, until RDP2? And leave out mentioning > RDP1. > > Best regards, > Goetz. > > > That's a good point and a case of bad terminology on my side :( I used "RDP1" because we were already talking about RDP2, without really thinking of the implication. Because I've been focused on the last release until the last week or so, I'm still very much of the frame of mind that we are still relatively early in the next releases and it wasn't my intention to suggest we'd be locking things down so soon. The update projects differ from the main JDK project in a number of ways: they have half the life span (three months rather than six), all changes require explicit approval as well as review, and the very nature of an update release means that it isn't the place for major new features. Hence, I'm not sure the priority matrix in JEP3 really makes much sense in our context, as a maintainer can choose to block a particular fix anyway, and, in many cases, the original priority will have been determined by someone other than the backporter. Hence, I would prefer a simpler three stage structure - development, rampdown and freeze - which is what was in my mind when I wrote the previous schedule (if not the terminology). So, for clarity: 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 Mon Apr 29 17:45:29 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 29 Apr 2019 18:45:29 +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 29/04/2019 15:50, Lindenmaier, Goetz wrote: > Hi, > > 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. > 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. > 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 > > Best regards, > Goetz. > > > 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. What testing do you do? And what would be regarded as a showstopper? One of my aims this time around is to do more frequent downstream merges so I can test each tag on a wider range of architectures, and not be caught out by arch-specific build failures late in the cycle. 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 christoph.langer at sap.com Mon Apr 29 18:53:25 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 29 Apr 2019 18:53:25 +0000 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: <40f66d37-6ad3-fc23-42a0-399790eac4f8@redhat.com> References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> <833668ba-d134-fdd0-2363-f682b19eced7@redhat.com> <40f66d37-6ad3-fc23-42a0-399790eac4f8@redhat.com> Message-ID: > -----Original Message----- > From: Andrew John Hughes > Sent: Montag, 29. April 2019 19:25 > To: Lindenmaier, Goetz ; 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 > > > > On 29/04/2019 15:22, Lindenmaier, Goetz wrote: > > Hi Andrew, > > > > yes, this is the same as what I tried to phrase. > > > > Just one thing: you are mentioning RDP1. > > How do you want to handle this? > > Will we announce that only P1-P3 bugs (no P4,P5, > > no enhancements of priority P1-P5) may be pushed > > to jdk11u-dev starting tomorrow? > > This is what https://openjdk.java.net/jeps/3 is saying > > and how jdk development is handled. > > > > Or should we just say jdk11u-dev is open for development, > > i.e., any changes, until RDP2? And leave out mentioning > > RDP1. > > > > Best regards, > > Goetz. > > > > > > > > That's a good point and a case of bad terminology on my side :( > I used "RDP1" because we were already talking about RDP2, without really > thinking of the implication. Because I've been focused on the last > release until the last week or so, I'm still very much of the frame of > mind that we are still relatively early in the next releases and it > wasn't my intention to suggest we'd be locking things down so soon. > > The update projects differ from the main JDK project in a number of > ways: they have half the life span (three months rather than six), all > changes require explicit approval as well as review, and the very nature > of an update release means that it isn't the place for major new > features. Hence, I'm not sure the priority matrix in JEP3 really makes > much sense in our context, as a maintainer can choose to block a > particular fix anyway, and, in many cases, the original priority will > have been determined by someone other than the backporter. > > Hence, I would prefer a simpler three stage structure - development, > rampdown and freeze - which is what was in my mind when I wrote the > previous schedule (if not the terminology). +1 to what you are saying here. I think JEP 3 applies to upstream jdk release development. But for the update projects it only applies in parts. We'll have to define our own stages and fix criteria. I like this thinking of three stages: development, rampdown and freeze. I already tried to spell out the fix criteria for ramp down in the Wiki like this: ...The maintainers will only consider fixes that Oracle have brought to their corresponding JDK 11 update release, fixes for high priority issues or important test fixes at this point... Once we agree on this, I can change the description in the Wiki in that sense. > > So, for clarity: > > 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. Sounds good. A schedule to publish on the Wiki could be this (I wouldn't explicitly mention build tags there): OpenJDK 11.0.4 March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) Wednesday, May 1 2019: First build (tag: jdk-11.0.4+1) Tuesday, May 28 2019, 12:00 CEST: Rampdown phase start, last merge jdk11u-dev->jdk11u Tuesday, June 25 2019, 12:00 CEST: Code freeze, jdk11u closed Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga) Thoughts? Best regards Christoph From christoph.langer at sap.com Mon Apr 29 18:55:10 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 29 Apr 2019 18:55:10 +0000 Subject: Set new hgupdater versions for jdk8u and jdk11u In-Reply-To: <4848cf43-caf6-2069-09bf-c20dbf6b25bf@redhat.com> References: <4848cf43-caf6-2069-09bf-c20dbf6b25bf@redhat.com> Message-ID: Hi Andrew, any news (from ops) on that one? Before we merge anything into jdk11u or jdk8u (later this week hopefully), this needs to be set up correctly. Otherwise, we'll blow the JBS history for 11.0.3... Thanks Christoph > -----Original Message----- > From: Andrew Haley > Sent: Mittwoch, 24. April 2019 15:07 > To: Langer, Christoph > Cc: 'jdk8u-dev at openjdk.java.net' ; jdk- > updates-dev at openjdk.java.net; 'Andrew John Hughes' > > Subject: Re: Set new hgupdater versions for jdk8u and jdk11u > > On 4/24/19 1:15 PM, Langer, Christoph wrote: > > as the April CPU is out of the door and we don't expect any more changes > for OpenJDK 8u212 and 11.0.3, I think it's time to ask ops to bump the > versions for hgupdater in the release branches: > > > > https://hg.openjdk.java.net/jdk8u/ -> openjdk8u222 > > http://hg.openjdk.java.net/jdk-updates/jdk11u/ -> 11.0.4 > > > > The new setting needs to be active before we can merge from dev to > release. > > Yep, was about to. Thanks for the reminder. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Mon Apr 29 19:01:42 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 29 Apr 2019 20:01:42 +0100 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> <833668ba-d134-fdd0-2363-f682b19eced7@redhat.com> <40f66d37-6ad3-fc23-42a0-399790eac4f8@redhat.com> Message-ID: snip... > > A schedule to publish on the Wiki could be this (I wouldn't explicitly mention build tags there): > > OpenJDK 11.0.4 > > March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) > Wednesday, May 1 2019: First build (tag: jdk-11.0.4+1) > Tuesday, May 28 2019, 12:00 CEST: Rampdown phase start, last merge jdk11u-dev->jdk11u > Tuesday, June 25 2019, 12:00 CEST: Code freeze, jdk11u closed > Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga) > > Thoughts? > > Best regards > Christoph > Looks good to me. The date & times of the phases are helpful, because those are the cut-offs for actual changes going in, rather than the Wednesday dates when tags are pushed. -- 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 Mon Apr 29 18:40:00 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 29 Apr 2019 18:40:00 +0000 Subject: [8u-dev] RFR+RFA (M): JDK-8176100: [REDO][REDO] G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: <84e8f725-ae22-a6ce-355c-713141b9bcdd@redhat.com> References: <8A7A3619-56E2-4E19-A1E0-BA47CBB5BAE4@amazon.com> <25EF3922-AC36-4D6F-B5D6-49B202A44986@amazon.com> <84e8f725-ae22-a6ce-355c-713141b9bcdd@redhat.com> Message-ID: Thank you, Andrew. Oracle indeed doesn't support sparc starting with 12, and never paid much attention to linux-sparc. Paul ?On 4/23/19, 9:40 PM, "jdk8u-dev on behalf of 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" 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 christoph.langer at sap.com Mon Apr 29 20:55:35 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 29 Apr 2019 20:55:35 +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 Andrew, at the end of last week I was thinking the same as you with regards on how we should do the pulling, merging and tagging. However, today Goetz came back from vacation and we discussed this a bit in more and came up with the approach he suggested in his mail. I actually think the approach as outlined by Goetz will help to have higher quality in the tags and we also don't ever need to flip repositories. The only change in week-to-week process would be to stop the integration from jdk11u-dev to jdk11u on the Wednesday when we reach ramp down. During the development stage, we'll pull each Wednesday from jdk11u-dev and will then have 6 days until the following Wednesday to fix high priority issues such as build failures or whatever exceptional thing we can think of (which will hopefully all be rather seldom though). Find below some comments on your remarks: > On 29/04/2019 15:50, Lindenmaier, Goetz wrote: > > Hi, > > > > 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. Obviously, before we do a first tag in jdk11u we have to pull something from jdk11u-dev. Otherwise we would tag nothing. So, for this week I think we should pull jdk11u-dev on Wednesday and tag 11.0.3+1 next Tuesday. As of now, we must not pull anything over to jdk11u anyway, since there's no indication that hgupdater has been updated on jdk11u to account for 11.0.4. Probably, after we have word by ops that hgupdater is up to date, we should pull one test patch first to see if everything really works correctly. The good thing if we were to tag the first build only next week is that we have a few more days to have ops complete their work. > > 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. See my comment above. ?? > > 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 > > > What testing do you do? And what would be regarded as a showstopper? As for our testing: Goetz had enumerated it here a while ago: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000648.html Showstoppers for tags would merely be build errors, I guess. Probably also very severe regressions compared to the last tag... Best regards Christoph [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000648.html From christoph.langer at sap.com Mon Apr 29 20:57:53 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 29 Apr 2019 20:57:53 +0000 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> <833668ba-d134-fdd0-2363-f682b19eced7@redhat.com> <40f66d37-6ad3-fc23-42a0-399790eac4f8@redhat.com> Message-ID: If we were to do the process suggested by Goetz, I'd have to make one change to the timeline (since we'd pull jdk11u-dev -> jdk11u on Wednesday): Wednesday, May 29 2019, 12:00 CEST: Rampdown phase start, last merge jdk11u-dev->jdk11u > > A schedule to publish on the Wiki could be this (I wouldn't explicitly > mention build tags there): > > > > OpenJDK 11.0.4 > > > > March 2019: jdk11u-dev repo open (tag: jdk-11.0.4+0) > > Wednesday, May 1 2019: First build (tag: jdk-11.0.4+1) > > Tuesday, May 28 2019, 12:00 CEST: Rampdown phase start, last merge jdk11u-dev->jdk11u > > Tuesday, June 25 2019, 12:00 CEST: Code freeze, jdk11u closed > > Tuesday, July 16 2019: GA (tag: jdk-11.0.4-ga) > > > > Thoughts? > > > > Best regards > > Christoph > > > > Looks good to me. > > The date & times of the phases are helpful, because those are the > cut-offs for actual changes going in, rather than the Wednesday dates > when tags are pushed. > -- > 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 Apr 30 02:34:14 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 30 Apr 2019 03:34:14 +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: <78f11d5f-dd4d-3bb8-4baf-bf3bf8f899e4@redhat.com> On 29/04/2019 21:55, Langer, Christoph wrote: > Hi Andrew, > > at the end of last week I was thinking the same as you with regards on how we should do the pulling, merging and tagging. However, today Goetz came back from vacation and we discussed this a bit in more and came up with the approach he suggested in his mail. I actually think the approach as outlined by Goetz will help to have higher quality in the tags and we also don't ever need to flip repositories. The only change in week-to-week process would be to stop the integration from jdk11u-dev to jdk11u on the Wednesday when we reach ramp down. During the development stage, we'll pull each Wednesday from jdk11u-dev and will then have 6 days until the following Wednesday to fix high priority issues such as build failures or whatever exceptional thing we can think of (which will hopefully all be rather seldom though). > > Find below some comments on your remarks: > >> On 29/04/2019 15:50, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> 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. > > Obviously, before we do a first tag in jdk11u we have to pull something from jdk11u-dev. Otherwise we would tag nothing. So, for this week I think we should pull jdk11u-dev on Wednesday and tag 11.0.3+1 next Tuesday. > > As of now, we must not pull anything over to jdk11u anyway, since there's no indication that hgupdater has been updated on jdk11u to account for 11.0.4. Probably, after we have word by ops that hgupdater is up to date, we should pull one test patch first to see if everything really works correctly. The good thing if we were to tag the first build only next week is that we have a few more days to have ops complete their work. > >>> 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. > > See my comment above. ?? > >>> 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 >>> > > > > >> What testing do you do? And what would be regarded as a showstopper? > > As for our testing: Goetz had enumerated it here a while ago: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000648.html > Showstoppers for tags would merely be build errors, I guess. Probably also very severe regressions compared to the last tag... > > Best regards > Christoph > > [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-February/000648.html > I find this very confusing. You may not have to change things over in the different stages, but you instead have this odd situation where you essentially run a week behind, and tag a bunch of changes that are, by then, a week old. I think what I suggested is a lot clearer. I spent a good five minutes reading over this and still not sure I have it right. I'm not sure how this leads to "higher quality" as you're still tagging the same thing. The issue with hgupdater is easily resolved in my scenario by just not touching jdk11u until it's ready. The tags will be still added in jdk11u-dev. The pull in jdk11u is simply delayed. It's not clear to me what happens in your case. Do you push the changes to jdk11u but not tag them? Or is it all just kept locally for a week? 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 Tue Apr 30 06:58:39 2019 From: dcherepanov at azul.com (Dmitry Cherepanov) Date: Tue, 30 Apr 2019 06:58:39 +0000 Subject: [8u-dev] RFR+RFA (M): JDK-8176100: [REDO][REDO] G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: <84e8f725-ae22-a6ce-355c-713141b9bcdd@redhat.com> References: <8A7A3619-56E2-4E19-A1E0-BA47CBB5BAE4@amazon.com> <25EF3922-AC36-4D6F-B5D6-49B202A44986@amazon.com> <84e8f725-ae22-a6ce-355c-713141b9bcdd@redhat.com> Message-ID: <9EEBDA2A-196F-40AC-AE42-8C0D69E94025@azul.com> 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" 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 Apr 30 10:29:27 2019 From: neugens at redhat.com (Mario Torre) Date: Tue, 30 Apr 2019 12:29:27 +0200 Subject: JFR backport status Message-ID: 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 Andrey, can you please use this bug for the review request and subsequent push? I will create more of those to track the additional efforts, it would be best however if this first commit includes all the known fixes to the base patch already, with only the additional features that Alibaba backported excluded (this will be a separate bug). I'm looking forward to see the updated patch! Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From sgehwolf at redhat.com Tue Apr 30 11:37:38 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 30 Apr 2019 13:37:38 +0200 Subject: [8u] RFR: 8210416: [linux] Poor StrictMath performance due to non-optimized compilation Message-ID: <2dce878b0d25f63974f2988f58d022d810af81bd.camel@redhat.com> 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+. 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 From goetz.lindenmaier at sap.com Tue Apr 30 12:40:55 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 30 Apr 2019 12:40:55 +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 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. 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. > > 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? > > 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. We should try to build a process that is easy to communicate 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. 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. > 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. These tests with real applications often show incompatibilities in the jdk changes ... > And what would be regarded as a showstopper? If we have 6 days in jdk11u before the tag, we could push an urgent fix directly to jdk11u before adding the tag. I.e., we could hopefully avoid showstoppers. I think we should only skip or delay a tag in very rare cases, as downstream work depends on the tags. Instead, we should open bugs and refer to the tag that shows the bug. > One of my aims this time around is to do more frequent downstream merges > so I can test each tag on a wider range of architectures, and not be > caught out by arch-specific build failures late in the cycle. That would be great :) Best regards, Goetz. > > 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 goetz.lindenmaier at sap.com Tue Apr 30 12:43:08 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 30 Apr 2019 12:43:08 +0000 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: <40f66d37-6ad3-fc23-42a0-399790eac4f8@redhat.com> References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> <833668ba-d134-fdd0-2363-f682b19eced7@redhat.com> <40f66d37-6ad3-fc23-42a0-399790eac4f8@redhat.com> Message-ID: Hi Andrew, ... sorry for all these long mails :) ... but I think it's important to get to a common understanding of all the motivations behind these things. So here I go: > That's a good point and a case of bad terminology on my side :( > I used "RDP1" because we were already talking about RDP2, without really > thinking of the implication. Because I've been focused on the last > release until the last week or so, I'm still very much of the frame of > mind that we are still relatively early in the next releases and it > wasn't my intention to suggest we'd be locking things down so soon. Ok. > The update projects differ from the main JDK project in a number of > ways: they have half the life span (three months rather than six), all > changes require explicit approval as well as review, and the very nature > of an update release means that it isn't the place for major new > features. Hence, I'm not sure the priority matrix in JEP3 really makes > much sense in our context, as a maintainer can choose to block a > particular fix anyway, and, in many cases, > the original priority will > have been determined by someone other than the backporter. It's not a priority that expresses how urgent to work on it. It is a rating at how severe the bug is. It is not well documented: https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report but this at least helps a bit. In the end, it is the assessment of the persons that worked on the bug, who are experts on the issue. Thus I think it well applies to an updates project. And yes, the changes brought to the updates project are more stable/smaller than in a new release. But on the other side introducing a regression is much more severe. The security updates go to productive systems with much less testing than for new releases. Finally I think all the people in the OpenJDK community are familiar with the OpenJDK development process. To make the jdk11u process easy to understand, we should use as much of the terminology etc. that is also used in the development of new releases, documented on all the wiki pages, and known to the developers. Again, this is not about me, you, Christoph, Aleksey or Andrew Haley, it's all about the other contributors. It must be simple to understand for them. What I would like is: jdk11u-dev: push anything, no tags, jdk11u-fix-request. jdk11u: rampdown of next release. push according to rules. tagged. jdk11u-critical-request. 4 weeks RDP2 4 weeks RDP1 3 weeks RC / frozen (Always open to all changes downported by Oracle). Or maybe 3+3+2 weeks ... This gives three months 'free' development for a release in 11u-dev plus 11 weeks of rampdown in 11u. (The 4 additional merges 11u-dev->11u shorten this by 4 weeks rampdown and pushes the start of n+1 development back 4 weeks.) But I already gave up on this simple thing with longer rampdown :). Which is fine... and also the reason we have our own build (SapMachine) where we can do quick fixes and releases on our own. > Hence, I would prefer a simpler three stage structure - development, > rampdown and freeze - which is what was in my mind when I wrote the > previous schedule (if not the terminology). > > So, for clarity: > > 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 = Could you give a specification of what changes qualify to be pushed in this phase? I think we need to document this for the 11u project if we don't reuse the established terms. E.g., a contributor needs to know whether to hurry to catch the deadline of the start of the rampdown phase. Also, If I want to downport a bug, I want to have some way to determine which repo to target with it. > ============================================================ > 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. Maybe we should even start regular tagging in jdk11u-dev right after we bumped the version to 11.0.5 ... there seems to be a need of tagged development versions, as the downstream builds are triggered by tags. Best regards, Goetz. > > 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 goetz.lindenmaier at sap.com Tue Apr 30 12:48:15 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 30 Apr 2019 12:48:15 +0000 Subject: [11u]: 8u222 & 11.0.4 release schedule In-Reply-To: <40f66d37-6ad3-fc23-42a0-399790eac4f8@redhat.com> References: <057dbf2fc44372db75f3437166bf92246357a6b1.camel@redhat.com> <833668ba-d134-fdd0-2363-f682b19eced7@redhat.com> <40f66d37-6ad3-fc23-42a0-399790eac4f8@redhat.com> Message-ID: 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 matthias.baesken at sap.com Tue Apr 30 12:52:02 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 30 Apr 2019 12:52:02 +0000 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: Hi Severin, looks okay to me (not a reviewer however). In our proprietary JVM8 we had set (on Linux) BUILD_LIBFDLIBM_OPTIMIZATION := HIGH and FDLIBM_CFLAGS += -ffp-contract=off for a long time and did not observe any issues . (but we always build with gcc 4.8.x so cannot tell much about lower gcc versions ). But I really wonder - wouldn?t it be better in the long run to go for a min. gcc versions >= 4.6 (or even 4.8) in OpenJDK8 ? Maybe some people from the distros could comment on this . Best regards, Matthias > -----Original Message----- > From: ppc-aix-port-dev On > Behalf Of Severin Gehwolf > Sent: Dienstag, 30. April 2019 13:38 > To: jdk8u-dev ; build-dev dev at openjdk.java.net> > Cc: ppc-aix-port-dev > Subject: [8u] RFR: 8210416: [linux] Poor StrictMath performance due to non- > optimized compilation > > 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+. > > 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 > > > > From sgehwolf at redhat.com Tue Apr 30 13:14:53 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 30 Apr 2019 15:14:53 +0200 Subject: [8u] RFR: 8210416: [linux] Poor StrictMath performance due to non-optimized compilation In-Reply-To: References: <2dce878b0d25f63974f2988f58d022d810af81bd.camel@redhat.com> Message-ID: Hi Matthias, Thanks for the review! On Tue, 2019-04-30 at 12:52 +0000, Baesken, Matthias wrote: > Hi Severin, looks okay to me (not a reviewer however). > In our proprietary JVM8 we had set (on > Linux) BUILD_LIBFDLIBM_OPTIMIZATION := > HIGH and FDLIBM_CFLAGS += -ffp-contract=off for a long time > and did not observe any issues . Good to know. We do the same in Fedora, fwiw. > (but we always build with gcc 4.8.x so cannot tell much about lower > gcc versions ). > > But I really wonder - wouldn?t it be better in the long run to go > for a min. gcc versions >= 4.6 (or even 4.8) in OpenJDK8 ? > > Maybe some people from the distros could comment on this . Perhaps, but it's hard to effectively figure out what that minimal version should be. Note that this change for the alternative of -ffp-contract=off was introduced to JDK 8 by SAP. See: https://bugs.openjdk.java.net/browse/JDK-8172053 Reading that bug it appears that minimum gcc is version 4.3? Either way, this patch will do the right thing(tm) for both as far as I could tell. It would use -mno-fused-madd -fno-strict-aliasing over --ffp- contract=off. My focus for this backport was to not break existing behaviour. Supporting -ffp-contract=off only would also break our upstream build machinery, as for them we build on RHEL 6 with gcc 4.4.7. >From our point of view JDK 8 minimal GCC would be 4.4.7 :) Thanks, Severin > > Best regards, Matthias > > > > -----Original Message----- > > From: ppc-aix-port-dev > > On > > Behalf Of Severin Gehwolf > > Sent: Dienstag, 30. April 2019 13:38 > > To: jdk8u-dev ; build-dev > dev at openjdk.java.net> > > Cc: ppc-aix-port-dev > > Subject: [8u] RFR: 8210416: [linux] Poor StrictMath performance due > > to non- > > optimized compilation > > > > 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+. > > > > 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 > > > > > > > > From andrey at azul.com Tue Apr 30 13:59:33 2019 From: andrey at azul.com (Andrey Petushkov) Date: Tue, 30 Apr 2019 13:59:33 +0000 Subject: JFR backport status In-Reply-To: References: Message-ID: <36BE6590-C715-49C1-AEEE-E001F062D145@azul.com> Hi Mario, Thank you, will proceed with this plan Regards, Andrey > On 30 Apr 2019, at 13: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 > > Andrey, can you please use this bug for the review request and subsequent push? > > I will create more of those to track the additional efforts, it would > be best however if this first commit includes all the known fixes to > the base patch already, with only the additional features that Alibaba > backported excluded (this will be a separate bug). > > I'm looking forward to see the updated patch! > > 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 Apr 30 14:09:27 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 30 Apr 2019 15:09:27 +0100 Subject: Set new hgupdater versions for jdk8u and jdk11u In-Reply-To: References: <4848cf43-caf6-2069-09bf-c20dbf6b25bf@redhat.com> Message-ID: On 4/29/19 7:55 PM, Langer, Christoph wrote: > Hi Andrew, > > any news (from ops) on that one? > > Before we merge anything into jdk11u or jdk8u (later this week hopefully), this needs to be set up correctly. Otherwise, we'll blow the JBS history for 11.0.3... Yes. There was some confusion because we have to set 8u and 8u-dev to the same version. I have confirmed. -- 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 Apr 30 14:14:01 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 30 Apr 2019 14:14:01 +0000 Subject: Set new hgupdater versions for jdk8u and jdk11u In-Reply-To: References: <4848cf43-caf6-2069-09bf-c20dbf6b25bf@redhat.com> Message-ID: > > Hi Andrew, > > > > any news (from ops) on that one? > > > > Before we merge anything into jdk11u or jdk8u (later this week hopefully), > this needs to be set up correctly. Otherwise, we'll blow the JBS history for > 11.0.3... > > Yes. There was some confusion because we have to set 8u and 8u-dev to the > same version. > I have confirmed. Hm, what exactly do you mean? You have confirmation from ops that the change should be done from their end? We can proceed merging stuff into jdk8u and jdk11u? Thanks Christoph From aph at redhat.com Tue Apr 30 14:56:00 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 30 Apr 2019 15:56:00 +0100 Subject: Set new hgupdater versions for jdk8u and jdk11u In-Reply-To: References: <4848cf43-caf6-2069-09bf-c20dbf6b25bf@redhat.com> Message-ID: <0aaa1010-6287-fc64-9316-2a1625d038a7@redhat.com> On 4/30/19 3:14 PM, Langer, Christoph wrote: > Hm, what exactly do you mean? You have confirmation from ops that the change should be done from their end? We can proceed merging stuff into jdk8u and jdk11u? I made the request. Ops asked me to confirm what I wanted. I have done so. No, the change isn't done yet. -- 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 Apr 30 14:56:34 2019 From: neugens at redhat.com (Mario Torre) Date: Tue, 30 Apr 2019 16:56:34 +0200 Subject: JFR backport status In-Reply-To: <36BE6590-C715-49C1-AEEE-E001F062D145@azul.com> References: <36BE6590-C715-49C1-AEEE-E001F062D145@azul.com> Message-ID: Thanks! Cheers, Mario On Tue, Apr 30, 2019 at 3:59 PM Andrey Petushkov wrote: > > Hi Mario, > > Thank you, will proceed with this plan > > Regards, > Andrey > > > On 30 Apr 2019, at 13: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 > > > > Andrey, can you please use this bug for the review request and subsequent push? > > > > I will create more of those to track the additional efforts, it would > > be best however if this first commit includes all the known fixes to > > the base patch already, with only the additional features that Alibaba > > backported excluded (this will be a separate bug). > > > > I'm looking forward to see the updated patch! > > > > 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 Tue Apr 30 14:57:59 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 30 Apr 2019 14:57:59 +0000 Subject: Set new hgupdater versions for jdk8u and jdk11u In-Reply-To: <0aaa1010-6287-fc64-9316-2a1625d038a7@redhat.com> References: <4848cf43-caf6-2069-09bf-c20dbf6b25bf@redhat.com> <0aaa1010-6287-fc64-9316-2a1625d038a7@redhat.com> Message-ID: > > Hm, what exactly do you mean? You have confirmation from ops that the > change should be done from their end? We can proceed merging stuff into > jdk8u and jdk11u? > > I made the request. Ops asked me to confirm what I wanted. I have > done so. No, the change isn't done yet. Understood. Thanks ?? From gnu.andrew at redhat.com Tue Apr 30 15:15:13 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 30 Apr 2019 16:15:13 +0100 Subject: JFR backport status In-Reply-To: References: Message-ID: 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? -- 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 Apr 30 15:19:23 2019 From: neugens at redhat.com (Mario Torre) Date: Tue, 30 Apr 2019 17:19:23 +0200 Subject: JFR backport status In-Reply-To: References: Message-ID: 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 -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From gnu.andrew at redhat.com Tue Apr 30 15:26:52 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 30 Apr 2019 16:26:52 +0100 Subject: JFR backport status In-Reply-To: References: Message-ID: 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 :) -- 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 Apr 30 15:49:00 2019 From: neugens at redhat.com (Mario Torre) Date: Tue, 30 Apr 2019 17:49:00 +0200 Subject: JFR backport status In-Reply-To: References: Message-ID: 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 shade at redhat.com Tue Apr 30 16:21:34 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 30 Apr 2019 18:21:34 +0200 Subject: [8u] RFR (S) 8151539: Remove duplicate AlwaysTrueClosures Message-ID: <59f3ef8f-42b4-13f6-8e91-3b76014b9d13@redhat.com> 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 -- Thanks, -Aleksey From stefan.karlsson at oracle.com Tue Apr 30 19:45:03 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 30 Apr 2019 21:45:03 +0200 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: Backport looks good. StefanK On 2019-04-30 18: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 > From hohensee at amazon.com Tue Apr 30 21:35:44 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 30 Apr 2019 21:35:44 +0000 Subject: [8u-dev] RFR+RFA (M): JDK-8176100: [REDO][REDO] G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: <9EEBDA2A-196F-40AC-AE42-8C0D69E94025@azul.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> Message-ID: <20665D4C-C717-4FE3-93B3-149378615B26@amazon.com> Thank you, Dmitry. Now we just need ppc results. Paul ?On 4/29/19, 11:59 PM, "jdk8u-dev on behalf of Dmitry Cherepanov" 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" 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 hohensee at amazon.com Tue Apr 30 21:40:38 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 30 Apr 2019 21:40:38 +0000 Subject: [8u] 8205916: [test] Fix jdk/tools/launcher/RunpathTest to handle both, RPATH and RUNPATH In-Reply-To: References: Message-ID: <54B4E2A0-A283-4129-9A67-F089A57DF7AF@amazon.com> Pushed. Thanks, Paul ?On 4/25/19, 9:51 AM, "jdk8u-dev on behalf of Liu, Xin" wrote: Thanks, Andrew and Christoph, Thanks for the head-up. I see Andrew has pasted the link for this code review. Paul will push it on behalf of me. Thanks, --lx On 4/25/19, 8:15 AM, "jdk8u-dev on behalf of Andrew John Hughes" wrote: On 25/04/2019 10:15, Langer, Christoph wrote: > Hi, > > thanks for doing this backport. > > It would be appreciated if you could add a Fix Request comment to the Bug, e.g. referring to this review thread and/or adding a short comment why this patch shall be backported (just as you've written below). > > Best regards > Christoph > A link to this thread should be sufficient, which I've now added. This is the downside of switching to the bug database for some elements, but still having reviews on mailing lists. -- 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 Apr 30 21:53:56 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 30 Apr 2019 21:53:56 +0000 Subject: [RFR] [8u] 8222965: Build Breakage from JDK-8129988 In-Reply-To: <28fd2e8c-0160-dbe5-a063-165ee1cc5986@redhat.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> Message-ID: <9AD53AF4-8431-40F1-9DBE-F82EF589DBCD@amazon.com> My apologies for messing this up, and thanks for fixing it. Paul ?On 4/26/19, 7:51 AM, "jdk8u-dev on behalf of Andrew John Hughes" wrote: On 26/04/2019 04:41, Andrew John Hughes wrote: > > > On 25/04/2019 21:40, Aleksey Shipilev wrote: >> On 4/25/19 8:25 AM, Andrew John Hughes wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222965 >>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8222965/webrev.01/ >> >> Looks good. Let's unbreak the build: it fixes the build for me. I eyeballed that we have the same >> files checking in as the original webrev (plus the generics fix). >> >> -Aleksey >> > > Thanks. I just need jdk8u-fix-yes and I can push. CCing aph. > And pushed: https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/b014bff7ba96 -- 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