From shade at redhat.com Wed May 2 10:10:14 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 2 May 2018 12:10:14 +0200 Subject: RFA/RFR [10] 8202540: Zero build is broken after JDK-8189871 (Refactor GC barriers to use declarative semantics) Message-ID: <54d151db-dec8-8407-db07-4c5d72788754@redhat.com> This is a bit unconventional process-wise, because there is a fix in JDK 11, but it comes with the bunch of other unrelated changes that are not backportable to 10u. So, I opted to submit a separate bug for this. I added the jdk10u-fix-request tag and appropriate comment. 10u bug: https://bugs.openjdk.java.net/browse/JDK-8202540 11 bug: https://bugs.openjdk.java.net/browse/JDK-8199220 10u fix: diff -r e4530ef14c08 src/hotspot/cpu/zero/globalDefinitions_zero.hpp --- a/src/hotspot/cpu/zero/globalDefinitions_zero.hpp Wed Mar 28 14:24:17 2018 +0100 +++ b/src/hotspot/cpu/zero/globalDefinitions_zero.hpp Wed May 02 12:03:18 2018 +0200 @@ -26,6 +26,10 @@ #ifndef CPU_ZERO_VM_GLOBALDEFINITIONS_ZERO_HPP #define CPU_ZERO_VM_GLOBALDEFINITIONS_ZERO_HPP +#ifdef _LP64 +#define SUPPORTS_NATIVE_CX8 +#endif + #include // Indicates whether the C calling conventions require that Testing: x86_64 Zero builds Thanks, -Aleksey From sgehwolf at redhat.com Wed May 2 13:19:19 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 02 May 2018 15:19:19 +0200 Subject: Outdated JDK 10 fix request process page? Message-ID: <1525267159.4303.33.camel@redhat.com> Hi, I came across an old fix request page today: http://openjdk.java.net/projects/jdk/10/fix-request-process It seems the above has been superceeded by: http://openjdk.java.net/projects/jdk-updates/approval.html I wonder whether jdk/10/fix-request-process should get updated to redirect to jdk-updates/approval.html or some other form of consolidation is in order. Thoughts? Thanks, Severin From rob.mckenna at oracle.com Wed May 2 15:15:26 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 2 May 2018 16:15:26 +0100 Subject: Outdated JDK 10 fix request process page? In-Reply-To: <1525267159.4303.33.camel@redhat.com> References: <1525267159.4303.33.camel@redhat.com> Message-ID: <20180502151526.GB3340@vimes> Hi Severin, The jdk & jdk-updates projects are considered separate. I personally like the idea of keeping the old JDK fix process pages around for archival purposes, but perhaps it would make sense to add a link pointing to the newer updates processes once the JDK release GA's. Hopefully this would solve your issue? -Rob On 02/05/18 15:19, Severin Gehwolf wrote: > Hi, > > I came across an old fix request page today: > http://openjdk.java.net/projects/jdk/10/fix-request-process > > It seems the above has been superceeded by: > http://openjdk.java.net/projects/jdk-updates/approval.html > > I wonder whether jdk/10/fix-request-process should get updated to > redirect to jdk-updates/approval.html or some other form of > consolidation is in order. Thoughts? > > Thanks, > Severin From jesper.wilhelmsson at oracle.com Wed May 2 15:16:27 2018 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Wed, 2 May 2018 17:16:27 +0200 Subject: Outdated JDK 10 fix request process page? In-Reply-To: <1525267159.4303.33.camel@redhat.com> References: <1525267159.4303.33.camel@redhat.com> Message-ID: Hi Severin, The two pages you link to describes different parts of the process. The (JDK 10) fix request process was/is used to get high priority fixes pushed in RDP2. The approval process is used to get fixes pushed to update releases in the JDK Updates project. These are different use cases. The JDK 10 process is "archived" together with the rest of the JDK 10 process pages on the wiki. You can find older versions of this page on the wiki as well [1]. As far as I know there are no plans on marking older process pages as deprecated or similar. Cheers, /Jesper [1] http://openjdk.java.net/projects/jdk9/fix-request-process > On 2 May 2018, at 15:19, Severin Gehwolf wrote: > > Hi, > > I came across an old fix request page today: > http://openjdk.java.net/projects/jdk/10/fix-request-process > > It seems the above has been superceeded by: > http://openjdk.java.net/projects/jdk-updates/approval.html > > I wonder whether jdk/10/fix-request-process should get updated to > redirect to jdk-updates/approval.html or some other form of > consolidation is in order. Thoughts? > > Thanks, > Severin From sgehwolf at redhat.com Wed May 2 15:46:02 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 02 May 2018 17:46:02 +0200 Subject: Outdated JDK 10 fix request process page? In-Reply-To: <20180502151526.GB3340@vimes> References: <1525267159.4303.33.camel@redhat.com> <20180502151526.GB3340@vimes> Message-ID: <1525275962.4303.45.camel@redhat.com> Hi Rob, On Wed, 2018-05-02 at 16:15 +0100, Rob McKenna wrote: > Hi Severin, > > The jdk & jdk-updates projects are considered separate. OK. > I personally like the idea of keeping the old JDK fix process pages > around for archival purposes, but perhaps it would make sense to add a > link pointing to the newer updates processes once the JDK release GA's. > Hopefully this would solve your issue? That sounds good. Just to clarify my point of view. I'm an OpenJDK contributor and I need to look up documents to find the right process to get fixes in. If there are more than one document describing the fix process for the same release, I get confused. In this instance it's Then I'd be better off to ask what the the right way of doing things in terms of process is. That adds to the burden of both, contributors and maintainers. For that reason I think it would be a good idea if deprecated documents can be marked as such possibly linking to the document which superceeded it. Thanks, Severin > -Rob > > On 02/05/18 15:19, Severin Gehwolf wrote: > > Hi, > > > > I came across an old fix request page today: > > http://openjdk.java.net/projects/jdk/10/fix-request-process > > > > It seems the above has been superceeded by: > > http://openjdk.java.net/projects/jdk-updates/approval.html > > > > I wonder whether jdk/10/fix-request-process should get updated to > > redirect to jdk-updates/approval.html or some other form of > > consolidation is in order. Thoughts? > > > > Thanks, > > Severin From gnu.andrew at redhat.com Fri May 4 14:50:18 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 4 May 2018 15:50:18 +0100 Subject: Outdated JDK 10 fix request process page? In-Reply-To: <1525275962.4303.45.camel@redhat.com> References: <1525267159.4303.33.camel@redhat.com> <20180502151526.GB3340@vimes> <1525275962.4303.45.camel@redhat.com> Message-ID: On 2 May 2018 at 16:46, Severin Gehwolf wrote: > Hi Rob, > > On Wed, 2018-05-02 at 16:15 +0100, Rob McKenna wrote: >> Hi Severin, >> >> The jdk & jdk-updates projects are considered separate. > > OK. > >> I personally like the idea of keeping the old JDK fix process pages >> around for archival purposes, but perhaps it would make sense to add a >> link pointing to the newer updates processes once the JDK release GA's. >> Hopefully this would solve your issue? > > That sounds good. > > Just to clarify my point of view. I'm an OpenJDK contributor and I need > to look up documents to find the right process to get fixes in. If > there are more than one document describing the fix process for the > same release, I get confused. In this instance it's Then I'd be better > off to ask what the the right way of doing things in terms of process > is. That adds to the burden of both, contributors and maintainers. For > that reason I think it would be a good idea if deprecated documents can > be marked as such possibly linking to the document which superceeded > it. > > Thanks, > Severin > I agree. This is a continuing problem with keeping around the old web pages, mailing lists and Mercurial trees. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From rob.mckenna at oracle.com Sat May 5 02:28:05 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Sat, 5 May 2018 03:28:05 +0100 Subject: [jdk-updates-communication] Push approval rule changes In-Reply-To: References: <20180426152340.GB3000@vimes> Message-ID: <20180505022805.GA11805@vimes> Hi Andrew, Good question. In general we consider a P1 to be a critical issue for which there is no workaround. (a reproducible crash or hang for example) We accept that priority is in the eye of the beholder however and so the final decision will rest with the group lead. In addition to P1's & serious regressions we have come up with a list of issue types which we will readily accept into a jdk-update: - CPU merges - TZUpdater changes - Test fixes - Changes to Root CACerts - Changes to the build number - Fixes specific to downstream builders' projects A few entries on this list were added as a result of some recent approval requests and there may be others we haven't considered yet. (I'll get these documented on the project page) For reference, here is a list of P1's from the JDK 10 project: https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20JDK%20and%20fixVersion%20in%20(10)%20and%20resolution%20%3D%20fixed%20and%20(labels%20is%20empty%20or%20labels%20!%3D%20hgupdate-sync)%20and%20priority%20%3D%20P1%20and%20level%20is%20EMPTY -Rob On 28/04/18 05:15, Andrew Hughes wrote: > On 26 April 2018 at 16:23, Rob McKenna wrote: > > A number of push approval requests have been filed which do not obviously > > meet the criteria laid out in the push approval project page. [1] I.e. > > that they are: > > > > - P1 bug, or > > - A serious regression which needs fixing ASAP > > > > What is the criteria for a "P1" bug and who determines whether it is classified > as such? > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Web Site: http://fuseyism.com > Twitter: https://twitter.com/gnu_andrew_java > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From rob.mckenna at oracle.com Sat May 5 02:30:35 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Sat, 5 May 2018 03:30:35 +0100 Subject: [jdk-updates-communication] Push approval rule changes In-Reply-To: <20180505022805.GA11805@vimes> References: <20180426152340.GB3000@vimes> <20180505022805.GA11805@vimes> Message-ID: <20180505023035.GB11805@vimes> s/TZUpdater/TZData/ -Rob On 05/05/18 03:28, Rob McKenna wrote: > Hi Andrew, > > Good question. In general we consider a P1 to be a critical issue for > which there is no workaround. (a reproducible crash or hang for example) > > We accept that priority is in the eye of the beholder however and so the > final decision will rest with the group lead. > > In addition to P1's & serious regressions we have come up with a list of > issue types which we will readily accept into a jdk-update: > > - CPU merges > - TZUpdater changes > - Test fixes > - Changes to Root CACerts > - Changes to the build number > - Fixes specific to downstream builders' projects > > A few entries on this list were added as a result of some recent > approval requests and there may be others we haven't considered yet. > (I'll get these documented on the project page) > > For reference, here is a list of P1's from the JDK 10 project: > > https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20JDK%20and%20fixVersion%20in%20(10)%20and%20resolution%20%3D%20fixed%20and%20(labels%20is%20empty%20or%20labels%20!%3D%20hgupdate-sync)%20and%20priority%20%3D%20P1%20and%20level%20is%20EMPTY > > -Rob > > On 28/04/18 05:15, Andrew Hughes wrote: > > On 26 April 2018 at 16:23, Rob McKenna wrote: > > > A number of push approval requests have been filed which do not obviously > > > meet the criteria laid out in the push approval project page. [1] I.e. > > > that they are: > > > > > > - P1 bug, or > > > - A serious regression which needs fixing ASAP > > > > > > > What is the criteria for a "P1" bug and who determines whether it is classified > > as such? > > > > Thanks, > > -- > > Andrew :) > > > > Senior Free Java Software Engineer > > Red Hat, Inc. (http://www.redhat.com) > > > > Web Site: http://fuseyism.com > > Twitter: https://twitter.com/gnu_andrew_java > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From martinrb at google.com Tue May 8 02:36:33 2018 From: martinrb at google.com (Martin Buchholz) Date: Mon, 7 May 2018 19:36:33 -0700 Subject: Outdated JDK 10 fix request process page? In-Reply-To: References: <1525267159.4303.33.camel@redhat.com> <20180502151526.GB3340@vimes> <1525275962.4303.45.camel@redhat.com> Message-ID: I wish the distinction between updates and ... (I don't even know what to call them - non-updates) projects would just go away. There is no technical reason for an artificial leap at General Availability. A sudden transition to another team promotes over-the-wall-ism. Perhaps the origin is the Java development org chart from decades ago. On Fri, May 4, 2018 at 7:50 AM, Andrew Hughes wrote: > > > I agree. This is a continuing problem with keeping around the old > web pages, mailing lists and Mercurial trees. > From shade at redhat.com Tue May 8 09:09:12 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 8 May 2018 11:09:12 +0200 Subject: RFA/RFR [10] 8202540: Zero build is broken after JDK-8189871 (Refactor GC barriers to use declarative semantics) In-Reply-To: <54d151db-dec8-8407-db07-4c5d72788754@redhat.com> References: <54d151db-dec8-8407-db07-4c5d72788754@redhat.com> Message-ID: <40d5c482-c95d-3fcc-9178-79e1cb4a7a8e@redhat.com> jdk10u-fix-yes was granted for the 10u bug. Do I have to have the formal ack on this review thread as well? If so, please ack. -Aleksey On 05/02/2018 12:10 PM, Aleksey Shipilev wrote: > This is a bit unconventional process-wise, because there is a fix in JDK 11, but it comes with the > bunch of other unrelated changes that are not backportable to 10u. So, I opted to submit a separate > bug for this. I added the jdk10u-fix-request tag and appropriate comment. > > 10u bug: > https://bugs.openjdk.java.net/browse/JDK-8202540 > > 11 bug: > https://bugs.openjdk.java.net/browse/JDK-8199220 > > 10u fix: > > diff -r e4530ef14c08 src/hotspot/cpu/zero/globalDefinitions_zero.hpp > --- a/src/hotspot/cpu/zero/globalDefinitions_zero.hpp Wed Mar 28 14:24:17 2018 +0100 > +++ b/src/hotspot/cpu/zero/globalDefinitions_zero.hpp Wed May 02 12:03:18 2018 +0200 > @@ -26,6 +26,10 @@ > #ifndef CPU_ZERO_VM_GLOBALDEFINITIONS_ZERO_HPP > #define CPU_ZERO_VM_GLOBALDEFINITIONS_ZERO_HPP > > +#ifdef _LP64 > +#define SUPPORTS_NATIVE_CX8 > +#endif > + > #include > > // Indicates whether the C calling conventions require that > > Testing: x86_64 Zero builds > > Thanks, > -Aleksey > From sgehwolf at redhat.com Tue May 8 09:19:16 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 08 May 2018 11:19:16 +0200 Subject: RFA/RFR [10] 8202540: Zero build is broken after JDK-8189871 (Refactor GC barriers to use declarative semantics) In-Reply-To: <40d5c482-c95d-3fcc-9178-79e1cb4a7a8e@redhat.com> References: <54d151db-dec8-8407-db07-4c5d72788754@redhat.com> <40d5c482-c95d-3fcc-9178-79e1cb4a7a8e@redhat.com> Message-ID: <8bf9087a21083fa66af86b57ccbf52c44985e76b.camel@redhat.com> On Tue, 2018-05-08 at 11:09 +0200, Aleksey Shipilev wrote: > jdk10u-fix-yes was granted for the 10u bug. > > Do I have to have the formal ack on this review thread as well? If > so, please ack. I believe since this isn't a straight forward backport from a JDK 11 change it needs to get reviewed by the relevant group. CC'ing hotspot- dev. FWIW, I can confirm that this fixes the Zero fastdebug build on JDK 10u. Thanks, Severin > -Aleksey > > On 05/02/2018 12:10 PM, Aleksey Shipilev wrote: > > This is a bit unconventional process-wise, because there is a fix > > in JDK 11, but it comes with the > > bunch of other unrelated changes that are not backportable to 10u. > > So, I opted to submit a separate > > bug for this. I added the jdk10u-fix-request tag and appropriate > > comment. > > > > 10u bug: > > https://bugs.openjdk.java.net/browse/JDK-8202540 > > > > 11 bug: > > https://bugs.openjdk.java.net/browse/JDK-8199220 > > > > 10u fix: > > > > diff -r e4530ef14c08 > > src/hotspot/cpu/zero/globalDefinitions_zero.hpp > > --- a/src/hotspot/cpu/zero/globalDefinitions_zero.hpp Wed > > Mar 28 14:24:17 2018 +0100 > > +++ b/src/hotspot/cpu/zero/globalDefinitions_zero.hpp Wed > > May 02 12:03:18 2018 +0200 > > @@ -26,6 +26,10 @@ > > #ifndef CPU_ZERO_VM_GLOBALDEFINITIONS_ZERO_HPP > > #define CPU_ZERO_VM_GLOBALDEFINITIONS_ZERO_HPP > > > > +#ifdef _LP64 > > +#define SUPPORTS_NATIVE_CX8 > > +#endif > > + > > #include > > > > // Indicates whether the C calling conventions require that > > > > Testing: x86_64 Zero builds > > > > Thanks, > > -Aleksey > > > > From david.holmes at oracle.com Tue May 8 09:37:14 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 May 2018 19:37:14 +1000 Subject: RFA/RFR [10] 8202540: Zero build is broken after JDK-8189871 (Refactor GC barriers to use declarative semantics) In-Reply-To: <8bf9087a21083fa66af86b57ccbf52c44985e76b.camel@redhat.com> References: <54d151db-dec8-8407-db07-4c5d72788754@redhat.com> <40d5c482-c95d-3fcc-9178-79e1cb4a7a8e@redhat.com> <8bf9087a21083fa66af86b57ccbf52c44985e76b.camel@redhat.com> Message-ID: Reviewed. David On 8/05/2018 7:19 PM, Severin Gehwolf wrote: > On Tue, 2018-05-08 at 11:09 +0200, Aleksey Shipilev wrote: >> jdk10u-fix-yes was granted for the 10u bug. >> >> Do I have to have the formal ack on this review thread as well? If >> so, please ack. > > I believe since this isn't a straight forward backport from a JDK 11 > change it needs to get reviewed by the relevant group. CC'ing hotspot- > dev. > > FWIW, I can confirm that this fixes the Zero fastdebug build on JDK > 10u. > > Thanks, > Severin > >> -Aleksey >> >> On 05/02/2018 12:10 PM, Aleksey Shipilev wrote: >>> This is a bit unconventional process-wise, because there is a fix >>> in JDK 11, but it comes with the >>> bunch of other unrelated changes that are not backportable to 10u. >>> So, I opted to submit a separate >>> bug for this. I added the jdk10u-fix-request tag and appropriate >>> comment. >>> >>> 10u bug: >>> https://bugs.openjdk.java.net/browse/JDK-8202540 >>> >>> 11 bug: >>> https://bugs.openjdk.java.net/browse/JDK-8199220 >>> >>> 10u fix: >>> >>> diff -r e4530ef14c08 >>> src/hotspot/cpu/zero/globalDefinitions_zero.hpp >>> --- a/src/hotspot/cpu/zero/globalDefinitions_zero.hpp Wed >>> Mar 28 14:24:17 2018 +0100 >>> +++ b/src/hotspot/cpu/zero/globalDefinitions_zero.hpp Wed >>> May 02 12:03:18 2018 +0200 >>> @@ -26,6 +26,10 @@ >>> #ifndef CPU_ZERO_VM_GLOBALDEFINITIONS_ZERO_HPP >>> #define CPU_ZERO_VM_GLOBALDEFINITIONS_ZERO_HPP >>> >>> +#ifdef _LP64 >>> +#define SUPPORTS_NATIVE_CX8 >>> +#endif >>> + >>> #include >>> >>> // Indicates whether the C calling conventions require that >>> >>> Testing: x86_64 Zero builds >>> >>> Thanks, >>> -Aleksey >>> >> >> From sgehwolf at redhat.com Tue May 8 12:56:01 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 08 May 2018 14:56:01 +0200 Subject: JDK 10u and generated-configure.sh Message-ID: <3f251397cbcfd0ddd98cea904ef2fe8725d7aeb5.camel@redhat.com> Hi, It just occurred to me that JDK 10u seems to still be using generated- configure.sh. If so there is a good chance that my recent push to jdk10u[1] might have broken something. Is it enough to ammend this with this? diff --git a/make/autoconf/generated-configure.sh b/make/autoconf/generated-configure.sh --- a/make/autoconf/generated-configure.sh +++ b/make/autoconf/generated-configure.sh @@ -5187,7 +5187,7 @@ #CUSTOM_AUTOCONF_INCLUDE # Do not change or remove the following line, it is needed for consistency checks: -DATE_WHEN_GENERATED=1516225089 +DATE_WHEN_GENERATED=1525783673 ############################################################################### # @@ -67486,7 +67486,7 @@ BOOTCYCLE_JVM_ARGS_BIG=-Xms64M # Maximum amount of heap memory and stack size. - JVM_HEAP_LIMIT_32="1024" + JVM_HEAP_LIMIT_32="768" # Running a 64 bit JVM allows for and requires a bigger heap JVM_HEAP_LIMIT_64="1600" STACK_SIZE_32=768 Does somebody at Oracle need to push this for me? My sincere appologies for the trouble! Please advise whether anything needs to be done. Thanks, Severin [1] http://hg.openjdk.java.net/jdk-updates/jdk10u/rev/2f8a4aafe85f From rob.mckenna at oracle.com Tue May 8 13:07:18 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 8 May 2018 14:07:18 +0100 Subject: JDK 10u and generated-configure.sh In-Reply-To: <3f251397cbcfd0ddd98cea904ef2fe8725d7aeb5.camel@redhat.com> References: <3f251397cbcfd0ddd98cea904ef2fe8725d7aeb5.camel@redhat.com> Message-ID: <20180508130718.GB3211@vimes> Hi Severin, You'll need to file a bug and follow the approval request process. http://openjdk.java.net/projects/jdk-updates/approval.html -Rob On 08/05/18 14:56, Severin Gehwolf wrote: > Hi, > > It just occurred to me that JDK 10u seems to still be using generated- > configure.sh. If so there is a good chance that my recent push to > jdk10u[1] might have broken something. Is it enough to ammend this with > this? > > diff --git a/make/autoconf/generated-configure.sh b/make/autoconf/generated-configure.sh > --- a/make/autoconf/generated-configure.sh > +++ b/make/autoconf/generated-configure.sh > @@ -5187,7 +5187,7 @@ > #CUSTOM_AUTOCONF_INCLUDE > > # Do not change or remove the following line, it is needed for consistency checks: > -DATE_WHEN_GENERATED=1516225089 > +DATE_WHEN_GENERATED=1525783673 > > ############################################################################### > # > @@ -67486,7 +67486,7 @@ > BOOTCYCLE_JVM_ARGS_BIG=-Xms64M > > # Maximum amount of heap memory and stack size. > - JVM_HEAP_LIMIT_32="1024" > + JVM_HEAP_LIMIT_32="768" > # Running a 64 bit JVM allows for and requires a bigger heap > JVM_HEAP_LIMIT_64="1600" > STACK_SIZE_32=768 > > Does somebody at Oracle need to push this for me? My sincere appologies for the trouble! > > Please advise whether anything needs to be done. > > Thanks, > Severin > > [1] http://hg.openjdk.java.net/jdk-updates/jdk10u/rev/2f8a4aafe85f From rob.mckenna at oracle.com Tue May 8 13:08:25 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 8 May 2018 14:08:25 +0100 Subject: JDK 10u and generated-configure.sh In-Reply-To: <20180508130718.GB3211@vimes> References: <3f251397cbcfd0ddd98cea904ef2fe8725d7aeb5.camel@redhat.com> <20180508130718.GB3211@vimes> Message-ID: <20180508130825.GC3211@vimes> (also, according to http://db.openjdk.java.net/people/ you have committer rights to the jdk-updates project.) -Rob On 08/05/18 14:07, Rob McKenna wrote: > Hi Severin, > > You'll need to file a bug and follow the approval request process. > > http://openjdk.java.net/projects/jdk-updates/approval.html > > -Rob > > On 08/05/18 14:56, Severin Gehwolf wrote: > > Hi, > > > > It just occurred to me that JDK 10u seems to still be using generated- > > configure.sh. If so there is a good chance that my recent push to > > jdk10u[1] might have broken something. Is it enough to ammend this with > > this? > > > > diff --git a/make/autoconf/generated-configure.sh b/make/autoconf/generated-configure.sh > > --- a/make/autoconf/generated-configure.sh > > +++ b/make/autoconf/generated-configure.sh > > @@ -5187,7 +5187,7 @@ > > #CUSTOM_AUTOCONF_INCLUDE > > > > # Do not change or remove the following line, it is needed for consistency checks: > > -DATE_WHEN_GENERATED=1516225089 > > +DATE_WHEN_GENERATED=1525783673 > > > > ############################################################################### > > # > > @@ -67486,7 +67486,7 @@ > > BOOTCYCLE_JVM_ARGS_BIG=-Xms64M > > > > # Maximum amount of heap memory and stack size. > > - JVM_HEAP_LIMIT_32="1024" > > + JVM_HEAP_LIMIT_32="768" > > # Running a 64 bit JVM allows for and requires a bigger heap > > JVM_HEAP_LIMIT_64="1600" > > STACK_SIZE_32=768 > > > > Does somebody at Oracle need to push this for me? My sincere appologies for the trouble! > > > > Please advise whether anything needs to be done. > > > > Thanks, > > Severin > > > > [1] http://hg.openjdk.java.net/jdk-updates/jdk10u/rev/2f8a4aafe85f From rob.mckenna at oracle.com Tue May 8 13:09:07 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 8 May 2018 14:09:07 +0100 Subject: JDK 10u and generated-configure.sh In-Reply-To: <20180508130825.GC3211@vimes> References: <3f251397cbcfd0ddd98cea904ef2fe8725d7aeb5.camel@redhat.com> <20180508130718.GB3211@vimes> <20180508130825.GC3211@vimes> Message-ID: <20180508130907.GD3211@vimes> Ahem: http://openjdk.java.net/census#jdk-updates -Rob On 08/05/18 14:08, Rob McKenna wrote: > (also, according to http://db.openjdk.java.net/people/ you have > committer rights to the jdk-updates project.) > > -Rob > > On 08/05/18 14:07, Rob McKenna wrote: > > Hi Severin, > > > > You'll need to file a bug and follow the approval request process. > > > > http://openjdk.java.net/projects/jdk-updates/approval.html > > > > -Rob > > > > On 08/05/18 14:56, Severin Gehwolf wrote: > > > Hi, > > > > > > It just occurred to me that JDK 10u seems to still be using generated- > > > configure.sh. If so there is a good chance that my recent push to > > > jdk10u[1] might have broken something. Is it enough to ammend this with > > > this? > > > > > > diff --git a/make/autoconf/generated-configure.sh b/make/autoconf/generated-configure.sh > > > --- a/make/autoconf/generated-configure.sh > > > +++ b/make/autoconf/generated-configure.sh > > > @@ -5187,7 +5187,7 @@ > > > #CUSTOM_AUTOCONF_INCLUDE > > > > > > # Do not change or remove the following line, it is needed for consistency checks: > > > -DATE_WHEN_GENERATED=1516225089 > > > +DATE_WHEN_GENERATED=1525783673 > > > > > > ############################################################################### > > > # > > > @@ -67486,7 +67486,7 @@ > > > BOOTCYCLE_JVM_ARGS_BIG=-Xms64M > > > > > > # Maximum amount of heap memory and stack size. > > > - JVM_HEAP_LIMIT_32="1024" > > > + JVM_HEAP_LIMIT_32="768" > > > # Running a 64 bit JVM allows for and requires a bigger heap > > > JVM_HEAP_LIMIT_64="1600" > > > STACK_SIZE_32=768 > > > > > > Does somebody at Oracle need to push this for me? My sincere appologies for the trouble! > > > > > > Please advise whether anything needs to be done. > > > > > > Thanks, > > > Severin > > > > > > [1] http://hg.openjdk.java.net/jdk-updates/jdk10u/rev/2f8a4aafe85f From sgehwolf at redhat.com Tue May 8 13:22:14 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 08 May 2018 15:22:14 +0200 Subject: JDK 10u and generated-configure.sh In-Reply-To: <20180508130907.GD3211@vimes> References: <3f251397cbcfd0ddd98cea904ef2fe8725d7aeb5.camel@redhat.com> <20180508130718.GB3211@vimes> <20180508130825.GC3211@vimes> <20180508130907.GD3211@vimes> Message-ID: Hi Rob, I can file a bug and follow the approval process and get it pushed. First, I'd like to know whether: A. An action needs to be taken at all? I assume yes, but just making sure. B. Contributors outside Oracle can push generated-configure.sh changes? I seem to remember that for JDK 8 that has to be done by an Oracle sponsor since some generated-configure.sh changes need to be done on closed sources. Not sure whether this info is accurate. Thanks, Severin On Tue, 2018-05-08 at 14:09 +0100, Rob McKenna wrote: > Ahem: http://openjdk.java.net/census#jdk-updates > > -Rob > > On 08/05/18 14:08, Rob McKenna wrote: > > (also, according to http://db.openjdk.java.net/people/ you have > > committer rights to the jdk-updates project.) > > > > -Rob > > > > On 08/05/18 14:07, Rob McKenna wrote: > > > Hi Severin, > > > > > > You'll need to file a bug and follow the approval request process. > > > > > > http://openjdk.java.net/projects/jdk-updates/approval.html > > > > > > -Rob > > > > > > On 08/05/18 14:56, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > It just occurred to me that JDK 10u seems to still be using generated- > > > > configure.sh. If so there is a good chance that my recent push to > > > > jdk10u[1] might have broken something. Is it enough to ammend this with > > > > this? > > > > > > > > diff --git a/make/autoconf/generated-configure.sh b/make/autoconf/generated-configure.sh > > > > --- a/make/autoconf/generated-configure.sh > > > > +++ b/make/autoconf/generated-configure.sh > > > > @@ -5187,7 +5187,7 @@ > > > > #CUSTOM_AUTOCONF_INCLUDE > > > > > > > > # Do not change or remove the following line, it is needed for consistency checks: > > > > -DATE_WHEN_GENERATED=1516225089 > > > > +DATE_WHEN_GENERATED=1525783673 > > > > > > > > ############################################################################### > > > > # > > > > @@ -67486,7 +67486,7 @@ > > > > BOOTCYCLE_JVM_ARGS_BIG=-Xms64M > > > > > > > > # Maximum amount of heap memory and stack size. > > > > - JVM_HEAP_LIMIT_32="1024" > > > > + JVM_HEAP_LIMIT_32="768" > > > > # Running a 64 bit JVM allows for and requires a bigger heap > > > > JVM_HEAP_LIMIT_64="1600" > > > > STACK_SIZE_32=768 > > > > > > > > Does somebody at Oracle need to push this for me? My sincere appologies for the trouble! > > > > > > > > Please advise whether anything needs to be done. > > > > > > > > Thanks, > > > > Severin > > > > > > > > [1] http://hg.openjdk.java.net/jdk-updates/jdk10u/rev/2f8a4aafe85f From rob.mckenna at oracle.com Tue May 8 14:20:22 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 8 May 2018 15:20:22 +0100 Subject: JDK 10u and generated-configure.sh In-Reply-To: References: <3f251397cbcfd0ddd98cea904ef2fe8725d7aeb5.camel@redhat.com> <20180508130718.GB3211@vimes> <20180508130825.GC3211@vimes> <20180508130907.GD3211@vimes> Message-ID: <20180508142022.GE3211@vimes> No, you're correct. The closed changes do need to be handled by someone in Oracle so it makes sense to get an Oracle committer to push. So: A. Yes. B. You're absolutely right. I'll take care of the push once you've got the change codereviewed / approved for push. Thanks, -Rob On 08/05/18 15:22, Severin Gehwolf wrote: > Hi Rob, > > I can file a bug and follow the approval process and get it pushed. > First, I'd like to know whether: > > A. An action needs to be taken at all? I assume yes, but just making > sure. > B. Contributors outside Oracle can push generated-configure.sh changes? > I seem to remember that for JDK 8 that has to be done by an Oracle > sponsor since some generated-configure.sh changes need to be done on > closed sources. Not sure whether this info is accurate. > > Thanks, > Severin > > On Tue, 2018-05-08 at 14:09 +0100, Rob McKenna wrote: > > Ahem: http://openjdk.java.net/census#jdk-updates > > > > -Rob > > > > On 08/05/18 14:08, Rob McKenna wrote: > > > (also, according to http://db.openjdk.java.net/people/ you have > > > committer rights to the jdk-updates project.) > > > > > > -Rob > > > > > > On 08/05/18 14:07, Rob McKenna wrote: > > > > Hi Severin, > > > > > > > > You'll need to file a bug and follow the approval request process. > > > > > > > > http://openjdk.java.net/projects/jdk-updates/approval.html > > > > > > > > -Rob > > > > > > > > On 08/05/18 14:56, Severin Gehwolf wrote: > > > > > Hi, > > > > > > > > > > It just occurred to me that JDK 10u seems to still be using generated- > > > > > configure.sh. If so there is a good chance that my recent push to > > > > > jdk10u[1] might have broken something. Is it enough to ammend this with > > > > > this? > > > > > > > > > > diff --git a/make/autoconf/generated-configure.sh b/make/autoconf/generated-configure.sh > > > > > --- a/make/autoconf/generated-configure.sh > > > > > +++ b/make/autoconf/generated-configure.sh > > > > > @@ -5187,7 +5187,7 @@ > > > > > #CUSTOM_AUTOCONF_INCLUDE > > > > > > > > > > # Do not change or remove the following line, it is needed for consistency checks: > > > > > -DATE_WHEN_GENERATED=1516225089 > > > > > +DATE_WHEN_GENERATED=1525783673 > > > > > > > > > > ############################################################################### > > > > > # > > > > > @@ -67486,7 +67486,7 @@ > > > > > BOOTCYCLE_JVM_ARGS_BIG=-Xms64M > > > > > > > > > > # Maximum amount of heap memory and stack size. > > > > > - JVM_HEAP_LIMIT_32="1024" > > > > > + JVM_HEAP_LIMIT_32="768" > > > > > # Running a 64 bit JVM allows for and requires a bigger heap > > > > > JVM_HEAP_LIMIT_64="1600" > > > > > STACK_SIZE_32=768 > > > > > > > > > > Does somebody at Oracle need to push this for me? My sincere appologies for the trouble! > > > > > > > > > > Please advise whether anything needs to be done. > > > > > > > > > > Thanks, > > > > > Severin > > > > > > > > > > [1] http://hg.openjdk.java.net/jdk-updates/jdk10u/rev/2f8a4aafe85f From sgehwolf at redhat.com Tue May 8 14:39:02 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 08 May 2018 16:39:02 +0200 Subject: [10u] RFR: 8202784: generated-configure.sh changes missing in 8201495 (was: Re: JDK 10u and generated-configure.sh) In-Reply-To: <20180508142022.GE3211@vimes> References: <3f251397cbcfd0ddd98cea904ef2fe8725d7aeb5.camel@redhat.com> <20180508130718.GB3211@vimes> <20180508130825.GC3211@vimes> <20180508130907.GD3211@vimes> <20180508142022.GE3211@vimes> Message-ID: Hi, On Tue, 2018-05-08 at 15:20 +0100, Rob McKenna wrote: > No, you're correct. The closed changes do need to be handled by someone > in Oracle so it makes sense to get an Oracle committer to push. > > So: > > A. Yes. > B. You're absolutely right. I'll take care of the push once you've got > the change codereviewed / approved for push. Thank you, Rob! This seems a rather strange case as the actual change is already pushed[1]. What's missing are the generated-configure.sh changes after "bash make/autoconf/autogen.sh". Not sure what needs to get code- reviewed in this case. Getting the latest revision (ddb10178cbb2) from jdk-updates/jdk10u and then performing the autogen.sh step should give you the changes that need to get pushed. That's what the following webrev is: Bug: https://bugs.openjdk.java.net/browse/JDK-8202784 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8202784/webrev.01/ Anyway, can somebody on the build-team rubber-stamp this, please? Thanks, Severin [1] http://hg.openjdk.java.net/jdk-updates/jdk10u/rev/2f8a4aafe85f > Thanks, > > -Rob > > On 08/05/18 15:22, Severin Gehwolf wrote: > > Hi Rob, > > > > I can file a bug and follow the approval process and get it pushed. > > First, I'd like to know whether: > > > > A. An action needs to be taken at all? I assume yes, but just making > > sure. > > B. Contributors outside Oracle can push generated-configure.sh changes? > > I seem to remember that for JDK 8 that has to be done by an Oracle > > sponsor since some generated-configure.sh changes need to be done on > > closed sources. Not sure whether this info is accurate. > > > > Thanks, > > Severin > > > > On Tue, 2018-05-08 at 14:09 +0100, Rob McKenna wrote: > > > Ahem: http://openjdk.java.net/census#jdk-updates > > > > > > -Rob > > > > > > On 08/05/18 14:08, Rob McKenna wrote: > > > > (also, according to http://db.openjdk.java.net/people/ you have > > > > committer rights to the jdk-updates project.) > > > > > > > > -Rob > > > > > > > > On 08/05/18 14:07, Rob McKenna wrote: > > > > > Hi Severin, > > > > > > > > > > You'll need to file a bug and follow the approval request process. > > > > > > > > > > http://openjdk.java.net/projects/jdk-updates/approval.html > > > > > > > > > > -Rob > > > > > > > > > > On 08/05/18 14:56, Severin Gehwolf wrote: > > > > > > Hi, > > > > > > > > > > > > It just occurred to me that JDK 10u seems to still be using generated- > > > > > > configure.sh. If so there is a good chance that my recent push to > > > > > > jdk10u[1] might have broken something. Is it enough to ammend this with > > > > > > this? > > > > > > > > > > > > diff --git a/make/autoconf/generated-configure.sh b/make/autoconf/generated-configure.sh > > > > > > --- a/make/autoconf/generated-configure.sh > > > > > > +++ b/make/autoconf/generated-configure.sh > > > > > > @@ -5187,7 +5187,7 @@ > > > > > > #CUSTOM_AUTOCONF_INCLUDE > > > > > > > > > > > > # Do not change or remove the following line, it is needed for consistency checks: > > > > > > -DATE_WHEN_GENERATED=1516225089 > > > > > > +DATE_WHEN_GENERATED=1525783673 > > > > > > > > > > > > ############################################################################### > > > > > > # > > > > > > @@ -67486,7 +67486,7 @@ > > > > > > BOOTCYCLE_JVM_ARGS_BIG=-Xms64M > > > > > > > > > > > > # Maximum amount of heap memory and stack size. > > > > > > - JVM_HEAP_LIMIT_32="1024" > > > > > > + JVM_HEAP_LIMIT_32="768" > > > > > > # Running a 64 bit JVM allows for and requires a bigger heap > > > > > > JVM_HEAP_LIMIT_64="1600" > > > > > > STACK_SIZE_32=768 > > > > > > > > > > > > Does somebody at Oracle need to push this for me? My sincere appologies for the trouble! > > > > > > > > > > > > Please advise whether anything needs to be done. > > > > > > > > > > > > Thanks, > > > > > > Severin > > > > > > > > > > > > [1] http://hg.openjdk.java.net/jdk-updates/jdk10u/rev/2f8a4aafe85f From erik.osterlund at oracle.com Tue May 8 10:50:06 2018 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 8 May 2018 12:50:06 +0200 Subject: RFA/RFR [10] 8202540: Zero build is broken after JDK-8189871 (Refactor GC barriers to use declarative semantics) In-Reply-To: <8bf9087a21083fa66af86b57ccbf52c44985e76b.camel@redhat.com> References: <54d151db-dec8-8407-db07-4c5d72788754@redhat.com> <40d5c482-c95d-3fcc-9178-79e1cb4a7a8e@redhat.com> <8bf9087a21083fa66af86b57ccbf52c44985e76b.camel@redhat.com> Message-ID: <5AF180DE.70704@oracle.com> Hi, Looks good. Thanks, /Erik On 2018-05-08 11:19, Severin Gehwolf wrote: > On Tue, 2018-05-08 at 11:09 +0200, Aleksey Shipilev wrote: >> jdk10u-fix-yes was granted for the 10u bug. >> >> Do I have to have the formal ack on this review thread as well? If >> so, please ack. > I believe since this isn't a straight forward backport from a JDK 11 > change it needs to get reviewed by the relevant group. CC'ing hotspot- > dev. > > FWIW, I can confirm that this fixes the Zero fastdebug build on JDK > 10u. > > Thanks, > Severin > >> -Aleksey >> >> On 05/02/2018 12:10 PM, Aleksey Shipilev wrote: >>> This is a bit unconventional process-wise, because there is a fix >>> in JDK 11, but it comes with the >>> bunch of other unrelated changes that are not backportable to 10u. >>> So, I opted to submit a separate >>> bug for this. I added the jdk10u-fix-request tag and appropriate >>> comment. >>> >>> 10u bug: >>> https://bugs.openjdk.java.net/browse/JDK-8202540 >>> >>> 11 bug: >>> https://bugs.openjdk.java.net/browse/JDK-8199220 >>> >>> 10u fix: >>> >>> diff -r e4530ef14c08 >>> src/hotspot/cpu/zero/globalDefinitions_zero.hpp >>> --- a/src/hotspot/cpu/zero/globalDefinitions_zero.hpp Wed >>> Mar 28 14:24:17 2018 +0100 >>> +++ b/src/hotspot/cpu/zero/globalDefinitions_zero.hpp Wed >>> May 02 12:03:18 2018 +0200 >>> @@ -26,6 +26,10 @@ >>> #ifndef CPU_ZERO_VM_GLOBALDEFINITIONS_ZERO_HPP >>> #define CPU_ZERO_VM_GLOBALDEFINITIONS_ZERO_HPP >>> >>> +#ifdef _LP64 >>> +#define SUPPORTS_NATIVE_CX8 >>> +#endif >>> + >>> #include >>> >>> // Indicates whether the C calling conventions require that >>> >>> Testing: x86_64 Zero builds >>> >>> Thanks, >>> -Aleksey >>> >> From tim.bell at oracle.com Tue May 8 14:53:48 2018 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 08 May 2018 07:53:48 -0700 Subject: [10u] RFR: 8202784: generated-configure.sh changes missing in 8201495 In-Reply-To: References: <3f251397cbcfd0ddd98cea904ef2fe8725d7aeb5.camel@redhat.com> <20180508130718.GB3211@vimes> <20180508130825.GC3211@vimes> <20180508130907.GD3211@vimes> <20180508142022.GE3211@vimes> Message-ID: <5AF1B9FC.4070605@oracle.com> See below- On 05/08/18 07:39, Severin Gehwolf wrote: > Hi, > > On Tue, 2018-05-08 at 15:20 +0100, Rob McKenna wrote: >> No, you're correct. The closed changes do need to be handled by someone >> in Oracle so it makes sense to get an Oracle committer to push. >> >> So: >> >> A. Yes. >> B. You're absolutely right. I'll take care of the push once you've got >> the change codereviewed / approved for push. > > Thank you, Rob! > > This seems a rather strange case as the actual change is already > pushed[1]. What's missing are the generated-configure.sh changes after > "bash make/autoconf/autogen.sh". Not sure what needs to get code- > reviewed in this case. > > Getting the latest revision (ddb10178cbb2) from jdk-updates/jdk10u and > then performing the autogen.sh step should give you the changes that > need to get pushed. That's what the following webrev is: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202784 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8202784/webrev.01/ > > Anyway, can somebody on the build-team rubber-stamp this, please? The make/autoconf/generated-configure.sh changes look good. Approved. Over to Rob for the pushing, including the closed generated-configure.sh. Tim > > Thanks, > Severin > > [1] http://hg.openjdk.java.net/jdk-updates/jdk10u/rev/2f8a4aafe85f From erik.joelsson at oracle.com Tue May 8 15:18:02 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 8 May 2018 08:18:02 -0700 Subject: JDK 10u and generated-configure.sh In-Reply-To: <3f251397cbcfd0ddd98cea904ef2fe8725d7aeb5.camel@redhat.com> References: <3f251397cbcfd0ddd98cea904ef2fe8725d7aeb5.camel@redhat.com> Message-ID: <17f754a0-9fd7-ec62-77b2-180fc6baa553@oracle.com> You already got answers on build-dev, but just to confirm. Yes, someone at Oracle still needs to push any configure changes for 10, 9 and 8. We are very unlikely to backport the getting rid of generated-configure to 10u since we don't intend to support 10 for any extended time. If you already pushed the change to the an .m4 file, then a new bugid needs to be created to fix the generated-configure.sh (for both open and Oracle closed). /Erik On 2018-05-08 05:56, Severin Gehwolf wrote: > Hi, > > It just occurred to me that JDK 10u seems to still be using generated- > configure.sh. If so there is a good chance that my recent push to > jdk10u[1] might have broken something. Is it enough to ammend this with > this? > > diff --git a/make/autoconf/generated-configure.sh b/make/autoconf/generated-configure.sh > --- a/make/autoconf/generated-configure.sh > +++ b/make/autoconf/generated-configure.sh > @@ -5187,7 +5187,7 @@ > #CUSTOM_AUTOCONF_INCLUDE > > # Do not change or remove the following line, it is needed for consistency checks: > -DATE_WHEN_GENERATED=1516225089 > +DATE_WHEN_GENERATED=1525783673 > > ############################################################################### > # > @@ -67486,7 +67486,7 @@ > BOOTCYCLE_JVM_ARGS_BIG=-Xms64M > > # Maximum amount of heap memory and stack size. > - JVM_HEAP_LIMIT_32="1024" > + JVM_HEAP_LIMIT_32="768" > # Running a 64 bit JVM allows for and requires a bigger heap > JVM_HEAP_LIMIT_64="1600" > STACK_SIZE_32=768 > > Does somebody at Oracle need to push this for me? My sincere appologies for the trouble! > > Please advise whether anything needs to be done. > > Thanks, > Severin > > [1] http://hg.openjdk.java.net/jdk-updates/jdk10u/rev/2f8a4aafe85f From erik.joelsson at oracle.com Tue May 8 15:21:37 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 8 May 2018 08:21:37 -0700 Subject: [10u] RFR: 8202784: generated-configure.sh changes missing in 8201495 In-Reply-To: <5AF1B9FC.4070605@oracle.com> References: <3f251397cbcfd0ddd98cea904ef2fe8725d7aeb5.camel@redhat.com> <20180508130718.GB3211@vimes> <20180508130825.GC3211@vimes> <20180508130907.GD3211@vimes> <20180508142022.GE3211@vimes> <5AF1B9FC.4070605@oracle.com> Message-ID: Please note that Severin mistakenly pushed just the .m4 change here: http://hg.openjdk.java.net/jdk-updates/jdk10u/rev/2f8a4aafe85f We now need another bugid for pushing just a new generated-configure.sh. This needs to be pushed to both open and closed. To generate it, just do "bash closed/make/autoconf/autogen.sh". /Erik On 2018-05-08 07:53, Tim Bell wrote: > See below- > > On 05/08/18 07:39, Severin Gehwolf wrote: >> Hi, >> >> On Tue, 2018-05-08 at 15:20 +0100, Rob McKenna wrote: >>> No, you're correct. The closed changes do need to be handled by someone >>> in Oracle so it makes sense to get an Oracle committer to push. >>> >>> So: >>> >>> A. Yes. >>> B. You're absolutely right. I'll take care of the push once you've got >>> the change codereviewed / approved for push. >> >> Thank you, Rob! >> >> This seems a rather strange case as the actual change is already >> pushed[1]. What's missing are the generated-configure.sh changes after >> "bash make/autoconf/autogen.sh". Not sure what needs to get code- >> reviewed in this case. >> >> Getting the latest revision (ddb10178cbb2) from jdk-updates/jdk10u and >> then performing the autogen.sh step should give you the changes that >> need to get pushed. That's what the following webrev is: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8202784 >> webrev: >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8202784/webrev.01/ >> >> Anyway, can somebody on the build-team rubber-stamp this, please? > > > The make/autoconf/generated-configure.sh changes look good. Approved. > > Over to Rob for the pushing, including the closed generated-configure.sh. > > Tim > >> >> Thanks, >> Severin >> >> [1] http://hg.openjdk.java.net/jdk-updates/jdk10u/rev/2f8a4aafe85f > From sgehwolf at redhat.com Tue May 8 15:28:59 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 08 May 2018 17:28:59 +0200 Subject: [10u] RFR: 8202784: generated-configure.sh changes missing in 8201495 In-Reply-To: References: <3f251397cbcfd0ddd98cea904ef2fe8725d7aeb5.camel@redhat.com> <20180508130718.GB3211@vimes> <20180508130825.GC3211@vimes> <20180508130907.GD3211@vimes> <20180508142022.GE3211@vimes> <5AF1B9FC.4070605@oracle.com> Message-ID: <27fb782a5957d994f8d881f0f0d0f1ebc2d83cbe.camel@redhat.com> On Tue, 2018-05-08 at 08:21 -0700, Erik Joelsson wrote: > Please note that Severin mistakenly pushed just the .m4 change here: > > http://hg.openjdk.java.net/jdk-updates/jdk10u/rev/2f8a4aafe85f > > We now need another bugid for pushing just a new generated-configure.sh. > This needs to be pushed to both open and closed. To generate it, just do > "bash closed/make/autoconf/autogen.sh". Yes, thanks. I've created a bug for this already: https://bugs.openjdk.java.net/browse/JDK-8202784 My appologies again for this screw-up :-( Cheers, Severin > /Erik > > > On 2018-05-08 07:53, Tim Bell wrote: > > See below- > > > > On 05/08/18 07:39, Severin Gehwolf wrote: > > > Hi, > > > > > > On Tue, 2018-05-08 at 15:20 +0100, Rob McKenna wrote: > > > > No, you're correct. The closed changes do need to be handled by someone > > > > in Oracle so it makes sense to get an Oracle committer to push. > > > > > > > > So: > > > > > > > > A. Yes. > > > > B. You're absolutely right. I'll take care of the push once you've got > > > > the change codereviewed / approved for push. > > > > > > Thank you, Rob! > > > > > > This seems a rather strange case as the actual change is already > > > pushed[1]. What's missing are the generated-configure.sh changes after > > > "bash make/autoconf/autogen.sh". Not sure what needs to get code- > > > reviewed in this case. > > > > > > Getting the latest revision (ddb10178cbb2) from jdk-updates/jdk10u and > > > then performing the autogen.sh step should give you the changes that > > > need to get pushed. That's what the following webrev is: > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202784 > > > webrev: > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8202784/webrev.01/ > > > > > > Anyway, can somebody on the build-team rubber-stamp this, please? > > > > > > The make/autoconf/generated-configure.sh changes look good. Approved. > > > > Over to Rob for the pushing, including the closed generated-configure.sh. > > > > Tim > > > > > > > > Thanks, > > > Severin > > > > > > [1] http://hg.openjdk.java.net/jdk-updates/jdk10u/rev/2f8a4aafe85f > > From dalibor.topic at oracle.com Wed May 9 12:33:48 2018 From: dalibor.topic at oracle.com (dalibor topic) Date: Wed, 9 May 2018 14:33:48 +0200 Subject: [10u-communication] Oracle's plans to contribute to JDK Updates Project in OpenJDK after Java SE 10 End of Public Updates Message-ID: <8da9baa4-ef15-3f88-f159-bdf26930e7dc@oracle.com> Hi, Oracle has updated the Oracle Java SE Support Roadmap with a Java SE 10 End of Public Updates Notice. [0] Oracle doesn't plan to contribute further changes to JDK 10 Updates in this OpenJDK Project once updates of Java SE 10 are no longer being posted to its public download site, after September 2018. Instead, Oracle plans to initiate and contribute to the development JDK 11 Updates within this OpenJDK Project in due course. That makes the July 2018 Critical Patch Update (CPU), 10.0.2, the last planned [1] Oracle-led JDK 10 Update release to be developed within this OpenJDK Project. Users of JDK 10 Updates builds should consider upgrading to JDK 11 when it becomes generally available. As with JDK 6 and JDK 7 Updates Projects in the past, if a suitable party steps forward to maintain the JDK 10 Updates series further once the final Oracle-led JDK 10 Update release has been published, we will discuss how to best enable such a transition on this Project's mailing list. cheers, dalibor topic [0] http://www.oracle.com/technetwork/java/eol-135779.html [1] http://openjdk.java.net/projects/jdk-updates/ -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Tue May 22 10:40:18 2018 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 22 May 2018 12:40:18 +0200 Subject: =?UTF-8?Q?Fwd:_OpenJDK_Committers=e2=80=99_Workshop=2c_1-2_August_2?= =?UTF-8?Q?018?= In-Reply-To: <20180521150628.707D01BCA84@eggemoggin.niobe.net> References: <20180521150628.707D01BCA84@eggemoggin.niobe.net> Message-ID: FYI. -------- Forwarded Message -------- Subject: OpenJDK Committers? Workshop, 1-2 August 2018 Date: Mon, 21 May 2018 08:06:28 -0700 (PDT) From: mark.reinhold at oracle.com Reply-To: discuss at openjdk.java.net, workshop-discuss at openjdk.java.net To: announce at openjdk.java.net OpenJDK Committers and other regular contributors traditionally meet each February, at FOSDEM in Brussels. Now that we?re shipping a new JDK every six months, it?s high time that we try to meet more than once a year. To fill that need, at least for this year, Oracle will host an OpenJDK Committers? Workshop on the first two days of August, immediately after the JVM Language Summit [1] at Oracle?s campus in Santa Clara, California, USA. The Workshop will begin with a few prepared presentations on the state of the OpenJDK Community and the JDK technical roadmap, but most of the time will be an ?unconference? for the discussion of both technical and community issues. Space will be limited, just as at the JVM Language Summit, so this won?t be as broad a gathering as the FOSDEM Free Java meeting. Preference will be given to Committers with a strong record of past contributions, though some space will be made for new Committers who have a strong potential for ongoing future contributions. Oracle will charge an attendance fee of $295 to cover costs. A limited number of scholarships, for that fee and for travel expenses, will be available. The Workshop is organized by: Andrew Haley (Red Hat) Doug Lea (SUNY Oswego) Liam Miller-Cushon (Google) Mark Reinhold (Oracle) Dalibor Topic (Oracle) Johan Vos (Gluon) For further information: http://openjdk.java.net/workshop - Mark [1] http://jvmlangsummit.com