From takiguc at linux.vnet.ibm.com Fri Mar 1 05:59:04 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Fri, 01 Mar 2019 14:59:04 +0900 Subject: JBS Filters for JDK update work In-Reply-To: <3fa6de91b4c44736a6570256851c52d3@sap.com> References: <3fa6de91b4c44736a6570256851c52d3@sap.com> Message-ID: <5c897bc2d8e51bf79126136f586651f5@linux.vnet.ibm.com> Hello Langer. About "Unapproved requests", it's better to use following search text. labels = jdk11u-fix-request AND labels not in (jdk11u-fix-no, jdk11u-fix-yes) On current query, 2 jdk11u-fix-no are there, they are always displayed. Thanks, Ichiroh Takiguchi On 2019-02-27 23:34, Langer, Christoph wrote: > Hi all, > > after putting some more efforts into my issue filters for jdk-updates > projects, here is a current list of the available ones. It might be of > value to some folks? As always: You need to be logged in to JBS, > otherwise these won?t work. If you find bugs, please report to me. > > Unapproved requests (for the maintainers/approvers): > 8u: https://bugs.openjdk.java.net/issues/?filter=36415 > 11u: https://bugs.openjdk.java.net/issues/?filter=36358 > 12u: https://bugs.openjdk.java.net/issues/?filter=36359 > > Approved requests without push (?orphans?): > 8u: https://bugs.openjdk.java.net/issues/?filter=36427 > 11u: https://bugs.openjdk.java.net/issues/?filter=36412 > 12u: https://bugs.openjdk.java.net/issues/?filter=36425 > > Open Downports Oracle -> OpenJDK: > 8u212: https://bugs.openjdk.java.net/issues/?filter=36394 > 8u222: https://bugs.openjdk.java.net/issues/?filter=36456 > 11.0.3: https://bugs.openjdk.java.net/issues/?filter=36366 > 11.0.4: https://bugs.openjdk.java.net/issues/?filter=36409 > > Additional commits in OpenJDK vs. the equivalent Oracle release > 8u212: https://bugs.openjdk.java.net/issues/?filter=36458 > 8u222: https://bugs.openjdk.java.net/issues/?filter=36459 > 11.0.3: https://bugs.openjdk.java.net/issues/?filter=36414 > 11.0.4: https://bugs.openjdk.java.net/issues/?filter=36457 > > To sort out some issues that are not relevant to OpenJDK, I introduced > a new label ?openjdk-na?. If you flag a bug with this, it?ll > fall out of my views. > If you want to check whether I flagged something wrongly (where?s my > bug?), you can check here: > https://bugs.openjdk.java.net/issues/?jql=labels+%3D+openjdk-na > > For jdk8u I filter issues which have originally been fixed in > openjfx12 or openjfx13 as those probably don?t affect OpenJDK. Maybe > we should check the list of openjdkfx bugs for an 8u release at some > time during the cycle manually to check that nothing slipped through. > > Have fun backporting ?? > Christoph From christoph.langer at sap.com Fri Mar 1 08:11:27 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 1 Mar 2019 08:11:27 +0000 Subject: JBS Filters for JDK update work In-Reply-To: <5c897bc2d8e51bf79126136f586651f5@linux.vnet.ibm.com> References: <3fa6de91b4c44736a6570256851c52d3@sap.com> <5c897bc2d8e51bf79126136f586651f5@linux.vnet.ibm.com> Message-ID: <60a488357aa9427d8fb43774a6c8a14e@sap.com> Hi Ichiroh, thanks for this hint. I fixed it and I also added views for rejected requests: 8u: https://bugs.openjdk.java.net/issues/?filter=36465 11u: https://bugs.openjdk.java.net/issues/?filter=36466 12u: https://bugs.openjdk.java.net/issues/?filter=36467 Best regards Christoph > -----Original Message----- > From: Ichiroh Takiguchi > Sent: Freitag, 1. M?rz 2019 06:59 > To: Langer, Christoph > Cc: jdk-updates-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net > Subject: Re: JBS Filters for JDK update work > > Hello Langer. > > About "Unapproved requests", it's better to use following search text. > labels = jdk11u-fix-request AND labels not in (jdk11u-fix-no, > jdk11u-fix-yes) > On current query, 2 jdk11u-fix-no are there, they are always displayed. > > Thanks, > Ichiroh Takiguchi > > On 2019-02-27 23:34, Langer, Christoph wrote: > > Hi all, > > > > after putting some more efforts into my issue filters for jdk-updates > > projects, here is a current list of the available ones. It might be of > > value to some folks? As always: You need to be logged in to JBS, > > otherwise these won?t work. If you find bugs, please report to me. > > > > Unapproved requests (for the maintainers/approvers): > > 8u: https://bugs.openjdk.java.net/issues/?filter=36415 > > 11u: https://bugs.openjdk.java.net/issues/?filter=36358 > > 12u: https://bugs.openjdk.java.net/issues/?filter=36359 > > > > Approved requests without push (?orphans?): > > 8u: https://bugs.openjdk.java.net/issues/?filter=36427 > > 11u: https://bugs.openjdk.java.net/issues/?filter=36412 > > 12u: https://bugs.openjdk.java.net/issues/?filter=36425 > > > > Open Downports Oracle -> OpenJDK: > > 8u212: https://bugs.openjdk.java.net/issues/?filter=36394 > > 8u222: https://bugs.openjdk.java.net/issues/?filter=36456 > > 11.0.3: https://bugs.openjdk.java.net/issues/?filter=36366 > > 11.0.4: https://bugs.openjdk.java.net/issues/?filter=36409 > > > > Additional commits in OpenJDK vs. the equivalent Oracle release > > 8u212: https://bugs.openjdk.java.net/issues/?filter=36458 > > 8u222: https://bugs.openjdk.java.net/issues/?filter=36459 > > 11.0.3: https://bugs.openjdk.java.net/issues/?filter=36414 > > 11.0.4: https://bugs.openjdk.java.net/issues/?filter=36457 > > > > To sort out some issues that are not relevant to OpenJDK, I introduced > > a new label ?openjdk-na?. If you flag a bug with this, it?ll > > fall out of my views. > > If you want to check whether I flagged something wrongly (where?s my > > bug?), you can check here: > > https://bugs.openjdk.java.net/issues/?jql=labels+%3D+openjdk-na > > > > For jdk8u I filter issues which have originally been fixed in > > openjfx12 or openjfx13 as those probably don?t affect OpenJDK. Maybe > > we should check the list of openjdkfx bugs for an 8u release at some > > time during the cycle manually to check that nothing slipped through. > > > > Have fun backporting ?? > > Christoph From christoph.langer at sap.com Fri Mar 1 08:33:05 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 1 Mar 2019 08:33:05 +0000 Subject: 11u: Fix request process & Where to push? Message-ID: <6a0001c4e3074f12833b5eaeb82df0fb@sap.com> Hi all, The topic has been discussed in several threads but I feel the need for some explicit communication: Changes that get approved (via the jdk11u-fix-yes label) have to be pushed to the jdk11u-dev repository: http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/. At the moment, those will reach OpenJDK 11.0.4. Do not push to jdk11u !! If you think a fix should still reach 11.0.3, the exceptional process would be that you explicitly state in the "Fix Request" comment that you request the fix to be in 11.0.3 and provide some reasoning for that. The approver will then decide and give the according directions. Thank you! Christoph From christoph.langer at sap.com Fri Mar 1 08:48:52 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 1 Mar 2019 08:48:52 +0000 Subject: 11u: Push of JDK-8210192 to jkd11u repository Message-ID: Hi, the backport for JDK-8210192 has been pushed to jdk11u. Looking at the fix request, I don't think it was explicitly targeted for 11.0.3, so it should have been gone to jk11u-dev (11.0.4). Looking at the issue, I think it's simple and riskless enough to keep it and not taking some "repair" action such as backing it out. Andrew, do you concur? In any case, we should try to avoid such pushes in the future. Best regards Christoph From shade at redhat.com Fri Mar 1 08:56:56 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 1 Mar 2019 09:56:56 +0100 Subject: 11u: Push of JDK-8210192 to jkd11u repository In-Reply-To: References: Message-ID: On 3/1/19 9:48 AM, Langer, Christoph wrote: > the backport for JDK-8210192 has been pushed to jdk11u. Looking at the fix request, I don't think > it was explicitly targeted for 11.0.3, so it should have been gone to jk11u-dev (11.0.4). > > Looking at the issue, I think it's simple and riskless enough to keep it and not taking some > "repair" action such as backing it out. Andrew, do you concur? I think it is harmless enough to ignore. -Aleksey P.S. Accidental push to the wrong repository? Here it goes. (clears throat) Told you so! :P From aph at redhat.com Fri Mar 1 09:03:13 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 1 Mar 2019 09:03:13 +0000 Subject: 11u: Push of JDK-8210192 to jkd11u repository In-Reply-To: References: Message-ID: <214daea8-4826-9e9d-6995-0ec990d4f3e3@redhat.com> On 3/1/19 8:48 AM, Langer, Christoph wrote: > the backport for JDK-8210192 has been pushed to jdk11u. Looking at > the fix request, I don't think it was explicitly targeted for > 11.0.3, so it should have been gone to jk11u-dev (11.0.4). Oh Lord, I didn't expect Aleksey to be proved right quite as quickly as that. Argh. Never mind for now, as Aleksey says, we can leave this patch. And I'll think about what to do. -- 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 Fri Mar 1 09:05:34 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 1 Mar 2019 09:05:34 +0000 Subject: 11u: Push of JDK-8210192 to jkd11u repository In-Reply-To: <214daea8-4826-9e9d-6995-0ec990d4f3e3@redhat.com> References: <214daea8-4826-9e9d-6995-0ec990d4f3e3@redhat.com> Message-ID: > > the backport for JDK-8210192 has been pushed to jdk11u. Looking at > > the fix request, I don't think it was explicitly targeted for > > 11.0.3, so it should have been gone to jk11u-dev (11.0.4). > > Oh Lord, I didn't expect Aleksey to be proved right quite as quickly as > that. Argh. > > Never mind for now, as Aleksey says, we can leave this patch. And I'll think > about what to do. Maybe, for the moment, we can claim it's a lack of education and the process just changed. But we should monitor closely. /Christoph From aph at redhat.com Fri Mar 1 14:26:18 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 1 Mar 2019 14:26:18 +0000 Subject: 11u: Push of JDK-8210192 to jkd11u repository In-Reply-To: References: <214daea8-4826-9e9d-6995-0ec990d4f3e3@redhat.com> Message-ID: <855b80ea-4650-b364-e7b6-c2c9d9a9fe50@redhat.com> On 3/1/19 9:05 AM, Langer, Christoph wrote: > Maybe, for the moment, we can claim it's a lack of education and the process just changed. That's what I thought too. -- 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 Fri Mar 1 19:21:08 2019 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 1 Mar 2019 19:21:08 +0000 Subject: 8u/11u repo access and Jira changes In-Reply-To: <3f49543e8bd14cf5b3ed7381abaad339@sap.com> References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com> <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com> <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com> <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com> <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com> <06f09798-cade-b882-fb3e-4049733fa8cc@redhat.com> <3f49543e8bd14cf5b3ed7381abaad339@sap.com> Message-ID: On Tue, 26 Feb 2019 at 21:41, Langer, Christoph wrote: > > Hi Andrew, > > > The questions I really need answers to are: > > > > 1. Who is going to push from jdk8u-dev -> jdk8u? > > The maintainers (you, Aleksey, me, Goetz, ...) > > > 2. What is the frequency of these pushes going to be? > > Ok, again, here's our proposal (from the SAP folks): > > We sync once per CPU release cycle from jdk8u-dev -> jdk8u, respectively from jdk11u-dev to jdk11u. For jdk11u, we've kind of done it now by the creation of the jdk11u-dev repo. For jdk8u I propose to do the initial push to jdk8u once all open Oracle backports were integrated. > Then, I expect a few pushes to jdk8u/jdk11u and we'll tag these once in a while like jdk-11.0.3+1 etc. These tags will be integrated back to dev regularly (by those who set the tags, that is, the maintainers). > At the release day, you'll sync your security work on top of jdk8u/jdk11u and add a final jdk-11.0.3+xx tag and the jdk-11.0.3-ga tag (which should point to the same change). And this will be integrated back to jdk11u-dev. > > What do you think of that? I can live with that. I'm a bit nervous about pushing changes to jdk8u before jdk8u-dev, but as long as it is tested regularly and integrated back into jdk8u-dev, it's ok. Incidentally, has 11u being tagged yet? On your final point, the -ga tag will be the point at which we branch + the private CPU changes (which will be smaller than the batches Oracle pushed, as we are only keeping private those that are embargoed, not the entire release set). This is why I suggest we declare the branch frozen at the point we use as a base internally, so there are not changes between the baseline for the CPU and when we push upstream. Tagging -ga after a merge would represent something different from what we have already based our update binaries on. The tagging is no different from the way things worked under Oracle; they also tagged what their binaries were built from, not the point it was merged. Where I hope we can be more open is in making it clear what our base looks like for these CPU patches, and those within the vulnerability group should be able to replicate the same thing for their own pre-embargo binaries. > > > 3. What testing is going to be performed prior to these pushes? > > Good question, currently I guess it's our quality testing at SAP plus whatever you have at RedHat. We should eventually get to something better, e.g. have some open test results from AdoptOpenJDK...?? Ok, I guess once we have the changes tagged in a repository, people can do their testing and report issues. > > > I'd prefer regular pushes with tags, because that would help us > > downstream (aarch64-port/jdk8u-shenandoah, > > shenandoah/jdk11) in being able to integrate changes more frequently. > > Under Oracle, we've had to do that at GA time only. > > That should be helped with our concept. Sounds good. > > Best regards > Christoph > 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 manc at google.com Fri Mar 1 20:18:30 2019 From: manc at google.com (Man Cao) Date: Fri, 1 Mar 2019 12:18:30 -0800 Subject: 11u: Push of JDK-8210192 to jkd11u repository In-Reply-To: <855b80ea-4650-b364-e7b6-c2c9d9a9fe50@redhat.com> References: <214daea8-4826-9e9d-6995-0ec990d4f3e3@redhat.com> <855b80ea-4650-b364-e7b6-c2c9d9a9fe50@redhat.com> Message-ID: Apologies for our uneducated push. We were unaware of the change in push policy for jdk11u. Thank you for taking that patch in 11.0.3 instead of rolling it back! -Man On Fri, Mar 1, 2019 at 6:27 AM Andrew Haley wrote: > On 3/1/19 9:05 AM, Langer, Christoph wrote: > > Maybe, for the moment, we can claim it's a lack of education and the > process just changed. > > That's what I thought too. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From manc at google.com Fri Mar 1 20:29:58 2019 From: manc at google.com (Man Cao) Date: Fri, 1 Mar 2019 12:29:58 -0800 Subject: 11u: Fix request process & Where to push? In-Reply-To: <6a0001c4e3074f12833b5eaeb82df0fb@sap.com> References: <6a0001c4e3074f12833b5eaeb82df0fb@sap.com> Message-ID: I think it is better to spell out this push policy on one of the documentation sites, e.g.: https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u https://openjdk.java.net/projects/jdk-updates/ New contributors (like me) may not be subscribed to jdk-updates-dev@ when these kinds of announcement for policy change were made. Also given that there is no jdk8u-dev or jdk12u-dev, the distinction in 11u's policy is worth being listed at more obvious places. -Man On Fri, Mar 1, 2019 at 12:34 AM Langer, Christoph wrote: > Hi all, > > The topic has been discussed in several threads but I feel the need for > some explicit communication: > > Changes that get approved (via the jdk11u-fix-yes label) have to be pushed > to the jdk11u-dev repository: > http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/. At the moment, those > will reach OpenJDK 11.0.4. Do not push to jdk11u !! > > If you think a fix should still reach 11.0.3, the exceptional process > would be that you explicitly state in the "Fix Request" comment that you > request the fix to be in 11.0.3 and provide some reasoning for that. The > approver will then decide and give the according directions. > > Thank you! > Christoph > > From jianglizhou at google.com Fri Mar 1 16:01:57 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Fri, 1 Mar 2019 08:01:57 -0800 Subject: 11u: Push of JDK-8210192 to jkd11u repository In-Reply-To: References: Message-ID: Hi Christoph, Thank you for noticing this! Sorry for pushing to the wrong repo. It is indeed my mistake due to a lack of education on the update repo process. To make sure I won't make the same mistake again in the future, could you (or Andrew or Aleksey) please point me to the current process guideline (still catching up on these). Thanks! Best regards, Jiangli On Fri, Mar 1, 2019 at 12:49 AM Langer, Christoph wrote: > Hi, > > > > the backport for JDK-8210192 has been pushed to jdk11u. Looking at the fix > request, I don?t think it was explicitly targeted for 11.0.3, so it should > have been gone to jk11u-dev (11.0.4). > > > > Looking at the issue, I think it?s simple and riskless enough to keep it > and not taking some ?repair? action such as backing it out. Andrew, do you > concur? > > > > In any case, we should try to avoid such pushes in the future. > > > > Best regards > > Christoph > > > From jianglizhou at google.com Fri Mar 1 16:30:57 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Fri, 1 Mar 2019 08:30:57 -0800 Subject: 11u: Push of JDK-8210192 to jkd11u repository In-Reply-To: References: Message-ID: On Fri, Mar 1, 2019 at 8:01 AM Jiangli Zhou wrote: > Hi Christoph, > > Thank you for noticing this! Sorry for pushing to the wrong repo. It is > indeed my mistake due to a lack of education on the update repo process. > > To make sure I won't make the same mistake again in the future, could you > (or Andrew or Aleksey) please point me to the current process guideline > (still catching up on these). Thanks! > Please ignore the above. I found the info on jdk-updates-dev mailing list. Looks like my new email address is still not added to the jdk-updates-dev mailing list, so I haven't noticed the process change (my email sending to the mailing list doesn't go through either currently). I'll try to ping Rob on the mailing list access. Thanks! Jiangli > Best regards, > Jiangli > > > > On Fri, Mar 1, 2019 at 12:49 AM Langer, Christoph < > christoph.langer at sap.com> wrote: > >> Hi, >> >> >> >> the backport for JDK-8210192 has been pushed to jdk11u. Looking at the >> fix request, I don?t think it was explicitly targeted for 11.0.3, so it >> should have been gone to jk11u-dev (11.0.4). >> >> >> >> Looking at the issue, I think it?s simple and riskless enough to keep it >> and not taking some ?repair? action such as backing it out. Andrew, do you >> concur? >> >> >> >> In any case, we should try to avoid such pushes in the future. >> >> >> >> Best regards >> >> Christoph >> >> >> > From rob.mckenna at oracle.com Sat Mar 2 00:41:49 2019 From: rob.mckenna at oracle.com (Rob McKenna) Date: Sat, 2 Mar 2019 00:41:49 +0000 Subject: 11u: Push of JDK-8210192 to jkd11u repository In-Reply-To: References: Message-ID: <20190302004149.GB3805@tecra> Please subscribe to the list at: http://mail.openjdk.java.net/mailman/listinfo/jdk-updates-dev -Rob On 01/03/19 08:30, Jiangli Zhou wrote: > On Fri, Mar 1, 2019 at 8:01 AM Jiangli Zhou wrote: > > > Hi Christoph, > > > > Thank you for noticing this! Sorry for pushing to the wrong repo. It is > > indeed my mistake due to a lack of education on the update repo process. > > > > To make sure I won't make the same mistake again in the future, could you > > (or Andrew or Aleksey) please point me to the current process guideline > > (still catching up on these). Thanks! > > > > Please ignore the above. I found the info on jdk-updates-dev mailing list. > Looks like my new email address is still not added to the jdk-updates-dev > mailing list, so I haven't noticed the process change (my email sending to > the mailing list doesn't go through either currently). I'll try to ping Rob > on the mailing list access. > > Thanks! > Jiangli > > > > Best regards, > > Jiangli > > > > > > > > On Fri, Mar 1, 2019 at 12:49 AM Langer, Christoph < > > christoph.langer at sap.com> wrote: > > > >> Hi, > >> > >> > >> > >> the backport for JDK-8210192 has been pushed to jdk11u. Looking at the > >> fix request, I don?t think it was explicitly targeted for 11.0.3, so it > >> should have been gone to jk11u-dev (11.0.4). > >> > >> > >> > >> Looking at the issue, I think it?s simple and riskless enough to keep it > >> and not taking some ?repair? action such as backing it out. Andrew, do you > >> concur? > >> > >> > >> > >> In any case, we should try to avoid such pushes in the future. > >> > >> > >> > >> Best regards > >> > >> Christoph > >> > >> > >> > > From jianglizhou at google.com Sat Mar 2 01:04:45 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Fri, 1 Mar 2019 17:04:45 -0800 Subject: 11u: Push of JDK-8210192 to jkd11u repository In-Reply-To: <20190302004149.GB3805@tecra> References: <20190302004149.GB3805@tecra> Message-ID: Done. Thanks!! Jiangli On Fri, Mar 1, 2019 at 4:42 PM Rob McKenna wrote: > Please subscribe to the list at: > > http://mail.openjdk.java.net/mailman/listinfo/jdk-updates-dev > > -Rob > > On 01/03/19 08:30, Jiangli Zhou wrote: > > On Fri, Mar 1, 2019 at 8:01 AM Jiangli Zhou > wrote: > > > > > Hi Christoph, > > > > > > Thank you for noticing this! Sorry for pushing to the wrong repo. It is > > > indeed my mistake due to a lack of education on the update repo > process. > > > > > > To make sure I won't make the same mistake again in the future, could > you > > > (or Andrew or Aleksey) please point me to the current process guideline > > > (still catching up on these). Thanks! > > > > > > > Please ignore the above. I found the info on jdk-updates-dev mailing > list. > > Looks like my new email address is still not added to the jdk-updates-dev > > mailing list, so I haven't noticed the process change (my email sending > to > > the mailing list doesn't go through either currently). I'll try to ping > Rob > > on the mailing list access. > > > > Thanks! > > Jiangli > > > > > > > Best regards, > > > Jiangli > > > > > > > > > > > > On Fri, Mar 1, 2019 at 12:49 AM Langer, Christoph < > > > christoph.langer at sap.com> wrote: > > > > > >> Hi, > > >> > > >> > > >> > > >> the backport for JDK-8210192 has been pushed to jdk11u. Looking at the > > >> fix request, I don?t think it was explicitly targeted for 11.0.3, so > it > > >> should have been gone to jk11u-dev (11.0.4). > > >> > > >> > > >> > > >> Looking at the issue, I think it?s simple and riskless enough to keep > it > > >> and not taking some ?repair? action such as backing it out. Andrew, > do you > > >> concur? > > >> > > >> > > >> > > >> In any case, we should try to avoid such pushes in the future. > > >> > > >> > > >> > > >> Best regards > > >> > > >> Christoph > > >> > > >> > > >> > > > > From aph at redhat.com Sat Mar 2 09:41:42 2019 From: aph at redhat.com (Andrew Haley) Date: Sat, 2 Mar 2019 09:41:42 +0000 Subject: 11u: Push of JDK-8210192 to jkd11u repository In-Reply-To: References: <214daea8-4826-9e9d-6995-0ec990d4f3e3@redhat.com> <855b80ea-4650-b364-e7b6-c2c9d9a9fe50@redhat.com> Message-ID: <377c5750-6624-f4f6-4187-bc6395c1c65c@redhat.com> On 3/1/19 8:18 PM, Man Cao wrote: > Apologies for our uneducated push. We were unaware of the change in push > policy for jdk11u. > Thank you for taking that patch in 11.0.3 instead of rolling it back! It wasn't your fault at all. We're just getting used to the new processes and I'm partly to blame for not communicating everything. -- 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 Mon Mar 4 06:42:08 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 4 Mar 2019 06:42:08 +0000 Subject: 8u/11u repo access and Jira changes In-Reply-To: References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com> <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com> <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com> <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com> <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com> <06f09798-cade-b882-fb3e-4049733fa8cc@redhat.com> <3f49543e8bd14cf5b3ed7381abaad339@sap.com> Message-ID: <5bcb63d5207144c7b436d3594d9cb789@sap.com> Hi Andrew, > > We sync once per CPU release cycle from jdk8u-dev -> jdk8u, respectively > from jdk11u-dev to jdk11u. For jdk11u, we've kind of done it now by the > creation of the jdk11u-dev repo. For jdk8u I propose to do the initial push to > jdk8u once all open Oracle backports were integrated. > > Then, I expect a few pushes to jdk8u/jdk11u and we'll tag these once in a > while like jdk-11.0.3+1 etc. These tags will be integrated back to dev regularly > (by those who set the tags, that is, the maintainers). > > At the release day, you'll sync your security work on top of jdk8u/jdk11u > and add a final jdk-11.0.3+xx tag and the jdk-11.0.3-ga tag (which should > point to the same change). And this will be integrated back to jdk11u-dev. > > > > What do you think of that? > > I can live with that. I'm a bit nervous about pushing changes to jdk8u > before jdk8u-dev, but as long as it is tested regularly and integrated > back into jdk8u-dev, it's ok. Incidentally, has 11u being tagged yet? It has, yes. > On your final point, the -ga tag will be the point at which we branch > + the private CPU changes (which will be smaller than the batches > Oracle pushed, as we are only keeping private those that are > embargoed, not the entire release set). This is why I suggest we > declare the branch frozen at the point we use as a base internally, so > there are not changes between the baseline for the CPU and when we > push upstream. Tagging -ga after a merge would represent something > different from what we have already based our update binaries on. Well, jdk11u is virtually frozen already (with about 6 weeks to go until GA). We only expect few stabilization changes. And whenever you start your work on the security repo, you can do merges from jdk11u back into your private repository at any time. Having said that, I, however, agree, that 'ga' should not be a merge between something that you worked on an tested in private and something that has diverged meanwhile in the public. That means, between the point when you've synced the last public jdk11.0.3+x into your private repo and the sync back of jdk11.0.3+(x+1) == jdk11.0.3-ga, there must not be changes in the public repository. So we should announce on the mailing list when we have a tag that we intend to use base for GA. And after that, no pushes any more to jdk11u, that's your hard freeze. :) What'll be the time you need for that final round of testing? Maybe 1-2 weeks before GA? Best regards Christoph From takiguc at linux.vnet.ibm.com Mon Mar 4 11:10:30 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Mon, 04 Mar 2019 20:10:30 +0900 Subject: Confirmation about jdk11u approval process In-Reply-To: <709b444897ff7f16718ca52952e7e0cc@linux.vnet.ibm.com> References: <634770840670d2ee3a21f7c531da3b0b@linux.vnet.ibm.com> <2e7d6ad873235c18aaa3226bbc829556@linux.vnet.ibm.com> <76e25246-9c59-958f-e810-22e589394fb8@redhat.com> <709b444897ff7f16718ca52952e7e0cc@linux.vnet.ibm.com> Message-ID: <9deb06ddd428c2ac0918d74d0097ef83@linux.vnet.ibm.com> Hello Andrew. Sorry for disturb you again. Thank you for handing jdk11u-fix-request. I got jdk11u-fix-yes for following bug ids. JDK-8211393 [1], JDK-8208634 [2], JDK-8213618 [3], JDK-8212794 [4], JDK-8214533 [5], JDK-8217880 [6] I have additional question. How can I determine these are for 11.0.3 or 11.0.4 ? If these are for 11.0.3, I need to find out the sponsor for them as soon as possible. [1] https://bugs.openjdk.java.net/browse/JDK-8211393 [2] https://bugs.openjdk.java.net/browse/JDK-8208634 [3] https://bugs.openjdk.java.net/browse/JDK-8213618 [4] https://bugs.openjdk.java.net/browse/JDK-8212794 [5] https://bugs.openjdk.java.net/browse/JDK-8214533 [6] https://bugs.openjdk.java.net/browse/JDK-8217880 Thanks, Ichiroh Takiguchi On 2019-03-01 03:35, Ichiroh Takiguchi wrote: > Hello Andrew. > >> What makes this critical? It looks like a minor memory leak. How long >> would it >> take interacting with an application before a user noticed a problem? > It depends on how many characters user typed. > I assume memory leak size is less than 1KB for each input method > handling event. > I did not check the impact for this issue... > > Thanks, > Ichiroh Takiguchi > > On 2019-02-28 22:51, Andrew Haley wrote: >> Hi, >> >> On 2/28/19 1:22 PM, Ichiroh Takiguchi wrote: >>> I did not know about milestones for jdk11u. >>> So I was late... >>> >>> Critical one may be JDK-8211393 [1] for Unix platform. >> >> What makes this critical? It looks like a minor memory leak. How long >> would it >> take interacting with an application before a user noticed a problem? From shade at redhat.com Mon Mar 4 11:13:44 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 4 Mar 2019 12:13:44 +0100 Subject: Confirmation about jdk11u approval process In-Reply-To: <9deb06ddd428c2ac0918d74d0097ef83@linux.vnet.ibm.com> References: <634770840670d2ee3a21f7c531da3b0b@linux.vnet.ibm.com> <2e7d6ad873235c18aaa3226bbc829556@linux.vnet.ibm.com> <76e25246-9c59-958f-e810-22e589394fb8@redhat.com> <709b444897ff7f16718ca52952e7e0cc@linux.vnet.ibm.com> <9deb06ddd428c2ac0918d74d0097ef83@linux.vnet.ibm.com> Message-ID: <508bb433-9980-0e1c-c52b-f889b7bc0648@redhat.com> On 3/4/19 12:10 PM, Ichiroh Takiguchi wrote: > I have additional question. > How can I determine these are for 11.0.3 or 11.0.4 ? 11.0.3 had been forked for stabilization already. If you haven't had the agreement with maintainer (Andrew) about pushing some of them to 11.0.3, all these go to 11.0.4. It looks to me only [1] can be considered critical, but I also see Andrew being skeptical about the impact of it. Me too, actually, given how old the bug is: it seems to go all we way back to JDK 1.2, 20 years? Seems like there is no rush to get it in 11.0.3, and it can go to 11.0.4? > If these are for 11.0.3, I need to find out the sponsor for them > as soon as possible. I can sponsor these for you. > [1] https://bugs.openjdk.java.net/browse/JDK-8211393 > [2] https://bugs.openjdk.java.net/browse/JDK-8208634 > [3] https://bugs.openjdk.java.net/browse/JDK-8213618 > [4] https://bugs.openjdk.java.net/browse/JDK-8212794 > [5] https://bugs.openjdk.java.net/browse/JDK-8214533 > [6] https://bugs.openjdk.java.net/browse/JDK-8217880 -Aleksey From takiguc at linux.vnet.ibm.com Mon Mar 4 12:13:19 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Mon, 04 Mar 2019 21:13:19 +0900 Subject: Confirmation about jdk11u approval process In-Reply-To: <508bb433-9980-0e1c-c52b-f889b7bc0648@redhat.com> References: <634770840670d2ee3a21f7c531da3b0b@linux.vnet.ibm.com> <2e7d6ad873235c18aaa3226bbc829556@linux.vnet.ibm.com> <76e25246-9c59-958f-e810-22e589394fb8@redhat.com> <709b444897ff7f16718ca52952e7e0cc@linux.vnet.ibm.com> <9deb06ddd428c2ac0918d74d0097ef83@linux.vnet.ibm.com> <508bb433-9980-0e1c-c52b-f889b7bc0648@redhat.com> Message-ID: <233528c2770b617d06f0df662a41b61a@linux.vnet.ibm.com> Hello Aleksey. For [1], it's only happened on 64bit CPU. So actually, JDK6. But it's still older... I will obey maintainers decision. I appreciate if you push [2] - [6] to 11.0.3. Thanks, Ichiroh Takiguchi On 2019-03-04 20:13, Aleksey Shipilev wrote: > On 3/4/19 12:10 PM, Ichiroh Takiguchi wrote: >> I have additional question. >> How can I determine these are for 11.0.3 or 11.0.4 ? > > 11.0.3 had been forked for stabilization already. If you haven't had > the agreement with maintainer > (Andrew) about pushing some of them to 11.0.3, all these go to 11.0.4. > > It looks to me only [1] can be considered critical, but I also see > Andrew being skeptical about the > impact of it. Me too, actually, given how old the bug is: it seems to > go all we way back to JDK 1.2, > 20 years? Seems like there is no rush to get it in 11.0.3, and it can > go to 11.0.4? > >> If these are for 11.0.3, I need to find out the sponsor for them >> as soon as possible. > > I can sponsor these for you. > >> [1] https://bugs.openjdk.java.net/browse/JDK-8211393 >> [2] https://bugs.openjdk.java.net/browse/JDK-8208634 >> [3] https://bugs.openjdk.java.net/browse/JDK-8213618 >> [4] https://bugs.openjdk.java.net/browse/JDK-8212794 >> [5] https://bugs.openjdk.java.net/browse/JDK-8214533 >> [6] https://bugs.openjdk.java.net/browse/JDK-8217880 > > -Aleksey From shade at redhat.com Mon Mar 4 13:09:07 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 4 Mar 2019 14:09:07 +0100 Subject: Confirmation about jdk11u approval process In-Reply-To: <233528c2770b617d06f0df662a41b61a@linux.vnet.ibm.com> References: <634770840670d2ee3a21f7c531da3b0b@linux.vnet.ibm.com> <2e7d6ad873235c18aaa3226bbc829556@linux.vnet.ibm.com> <76e25246-9c59-958f-e810-22e589394fb8@redhat.com> <709b444897ff7f16718ca52952e7e0cc@linux.vnet.ibm.com> <9deb06ddd428c2ac0918d74d0097ef83@linux.vnet.ibm.com> <508bb433-9980-0e1c-c52b-f889b7bc0648@redhat.com> <233528c2770b617d06f0df662a41b61a@linux.vnet.ibm.com> Message-ID: <88b81bd3-e18e-940e-b35f-c537b0aa4e40@redhat.com> On 3/4/19 1:13 PM, Ichiroh Takiguchi wrote: > Hello Aleksey. > > For [1], it's only happened on 64bit CPU. > So actually, JDK6. > But it's still older... > I will obey maintainers decision. > > I appreciate if you push [2] - [6] to 11.0.3. Wait. As I said, all current pushes go to 11.0.4, *unless* maintainer specifically granted the approval specifically for 11.0.3. Which did not happen for any of these six issues. So, [1]-[6] would go to 11.0.4, okay? As I applied all the patches to current jdk11u-dev, I realized that some of them are AIX-specific. While the whole bunch passes tier1 tests on my Linux x86_64, we better confirm it does not break AIX. It is unclear from the Fix Requests: have you tested these on AIX? Or, should we ask Christoph to do it? The changeset bunch is here: http://cr.openjdk.java.net/~shade/backports-11u/ibm-charsets/webrev.01/ -Aleksey From goetz.lindenmaier at sap.com Mon Mar 4 14:36:22 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 4 Mar 2019 14:36:22 +0000 Subject: Confirmation about jdk11u approval process In-Reply-To: <9deb06ddd428c2ac0918d74d0097ef83@linux.vnet.ibm.com> References: <634770840670d2ee3a21f7c531da3b0b@linux.vnet.ibm.com> <2e7d6ad873235c18aaa3226bbc829556@linux.vnet.ibm.com> <76e25246-9c59-958f-e810-22e589394fb8@redhat.com> <709b444897ff7f16718ca52952e7e0cc@linux.vnet.ibm.com> <9deb06ddd428c2ac0918d74d0097ef83@linux.vnet.ibm.com> Message-ID: Hi Ichiroh, To go to 11.0.3, they need to be P1 or P2 bugs, or pure test changes. Jdk11.0.3 in the jdk11u reporsitory is in rampdown phase two: https://openjdk.java.net/jeps/3 If they were P1 or P2, and you had wanted to get them to 11.0.3, it would have been best if you hsd stated so in the Fix Request comment. Thus, please get the changes pushed to jdk11u-dev. Best regards, Goetz > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Ichiroh Takiguchi > Sent: Monday, March 4, 2019 12:11 PM > To: Andrew Haley > Cc: jdk-updates-dev at openjdk.java.net > Subject: Re: Confirmation about jdk11u approval process > > Hello Andrew. > > Sorry for disturb you again. > > Thank you for handing jdk11u-fix-request. > I got jdk11u-fix-yes for following bug ids. > > JDK-8211393 [1], JDK-8208634 [2], JDK-8213618 [3], JDK-8212794 [4], > JDK-8214533 [5], JDK-8217880 [6] > > I have additional question. > How can I determine these are for 11.0.3 or 11.0.4 ? > > If these are for 11.0.3, I need to find out the sponsor for them > as soon as possible. > > [1] https://bugs.openjdk.java.net/browse/JDK-8211393 > [2] https://bugs.openjdk.java.net/browse/JDK-8208634 > [3] https://bugs.openjdk.java.net/browse/JDK-8213618 > [4] https://bugs.openjdk.java.net/browse/JDK-8212794 > [5] https://bugs.openjdk.java.net/browse/JDK-8214533 > [6] https://bugs.openjdk.java.net/browse/JDK-8217880 > > Thanks, > Ichiroh Takiguchi > > On 2019-03-01 03:35, Ichiroh Takiguchi wrote: > > Hello Andrew. > > > >> What makes this critical? It looks like a minor memory leak. How long > >> would it > >> take interacting with an application before a user noticed a problem? > > It depends on how many characters user typed. > > I assume memory leak size is less than 1KB for each input method > > handling event. > > I did not check the impact for this issue... > > > > Thanks, > > Ichiroh Takiguchi > > > > On 2019-02-28 22:51, Andrew Haley wrote: > >> Hi, > >> > >> On 2/28/19 1:22 PM, Ichiroh Takiguchi wrote: > >>> I did not know about milestones for jdk11u. > >>> So I was late... > >>> > >>> Critical one may be JDK-8211393 [1] for Unix platform. > >> > >> What makes this critical? It looks like a minor memory leak. How long > >> would it > >> take interacting with an application before a user noticed a problem? From goetz.lindenmaier at sap.com Mon Mar 4 15:17:19 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 4 Mar 2019 15:17:19 +0000 Subject: 8u/11u repo access and Jira changes In-Reply-To: <90c57878b5254c6ca2d496a2a59b8eb8@sap.com> References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com> <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com> <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com> <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com> <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com> <06f09798-cade-b882-fb3e-4049733fa8cc@redhat.com> <3f49543e8bd14cf5b3ed7381abaad339@sap.com> <90c57878b5254c6ca2d496a2a59b8eb8@sap.com> Message-ID: Hi Andrew, Aleksey, community, Before, I proposed this, but got no comments: > I (backed up by Christoph and the rest of the SAP team) would volunteer to > 1. tag jdk11u on a weekly basis after running our tests (if there was a change) > 2. merge the tag to jdk11u-dev and run tests on the merged repo > 3. push the changes to jdk11u-dev the day after. Should SAP take the role of doing above merges? Best regards, Goetz > > I would propose to tag the change that is built by our infrastructure on > > the night Tuesday-Wednesday, which is usually pulled on Tuesday 18:00 CET. > > In the night Wednesday-Thursday, the tests would run on jdk11u-dev > including > > the changes merged from jdk11u. Test results will pop up during the day > (Thursday), > > the merged changes could be pushed on Thursday evening or Friday morning. > > > > Our testing currently covers the following: > > > > We build the following platforms: > > Aix > > Linux ppc64 > > Linux ppc64le > > Linux s390x > > Linux x86_64 > > mac > > Solaris sparc > > Windows x86_64 > > Windows x86_32 > > We finally got an aarch64 machine, we could add that to the tests. > > > > We run the following tests every night: > > A big part of the jck tests (excluding those requiring manual testing, and a > list of shaky tests) > > The jck tests with -Xcomp and C1, and with -Xcomp and C2. > > The hotspot and jdk jtreg tests, excluding those marked with key "headful", > "printer" and "intermittent" > > Jvm2008, jbb2015, jvm98 > > And finally some SAP applications. > > > > But I'm also fine with leaving this task to RedHat, Aleksey or Andrew Hughes > or whoever > > would be available on your side. > > > > For the move jdk11u-dev-->jdk11u, which happens only once a release, we > should > > do this by communication on the mailing list. > > > > Best regards, > > Goetz. > > > > > > > > > -----Original Message----- > > > From: Langer, Christoph > > > Sent: Tuesday, February 26, 2019 10:41 PM > > > To: Andrew Hughes > > > Cc: jdk8u-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net; > > > Lindenmaier, Goetz ; Aleksey Shipilev > > > > > > Subject: RE: 8u/11u repo access and Jira changes > > > > > > Hi Andrew, > > > > > > > The questions I really need answers to are: > > > > > > > > 1. Who is going to push from jdk8u-dev -> jdk8u? > > > > > > The maintainers (you, Aleksey, me, Goetz, ...) > > > > > > > 2. What is the frequency of these pushes going to be? > > > > > > Ok, again, here's our proposal (from the SAP folks): > > > > > > We sync once per CPU release cycle from jdk8u-dev -> jdk8u, respectively > > > from jdk11u-dev to jdk11u. For jdk11u, we've kind of done it now by the > > > creation of the jdk11u-dev repo. For jdk8u I propose to do the initial push > to > > > jdk8u once all open Oracle backports were integrated. > > > Then, I expect a few pushes to jdk8u/jdk11u and we'll tag these once in a > > > while like jdk-11.0.3+1 etc. These tags will be integrated back to dev > regularly > > > (by those who set the tags, that is, the maintainers). > > > At the release day, you'll sync your security work on top of jdk8u/jdk11u > and > > > add a final jdk-11.0.3+xx tag and the jdk-11.0.3-ga tag (which should point > to > > > the same change). And this will be integrated back to jdk11u-dev. > > > > > > What do you think of that? > > > > > > > 3. What testing is going to be performed prior to these pushes? > > > > > > Good question, currently I guess it's our quality testing at SAP plus > whatever > > > you have at RedHat. We should eventually get to something better, e.g. > have > > > some open test results from AdoptOpenJDK...?? > > > > > > > I'd prefer regular pushes with tags, because that would help us > > > > downstream (aarch64-port/jdk8u-shenandoah, > > > > shenandoah/jdk11) in being able to integrate changes more frequently. > > > > Under Oracle, we've had to do that at GA time only. > > > > > > That should be helped with our concept. > > > > > > Best regards > > > Christoph > From gnu.andrew at redhat.com Mon Mar 4 17:09:07 2019 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 4 Mar 2019 17:09:07 +0000 Subject: 8u/11u repo access and Jira changes In-Reply-To: <5bcb63d5207144c7b436d3594d9cb789@sap.com> References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com> <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com> <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com> <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com> <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com> <06f09798-cade-b882-fb3e-4049733fa8cc@redhat.com> <3f49543e8bd14cf5b3ed7381abaad339@sap.com> <5bcb63d5207144c7b436d3594d9cb789@sap.com> Message-ID: On Mon, 4 Mar 2019 at 06:42, Langer, Christoph wrote: > > Hi Andrew, > > > > We sync once per CPU release cycle from jdk8u-dev -> jdk8u, respectively > > from jdk11u-dev to jdk11u. For jdk11u, we've kind of done it now by the > > creation of the jdk11u-dev repo. For jdk8u I propose to do the initial push to > > jdk8u once all open Oracle backports were integrated. > > > Then, I expect a few pushes to jdk8u/jdk11u and we'll tag these once in a > > while like jdk-11.0.3+1 etc. These tags will be integrated back to dev regularly > > (by those who set the tags, that is, the maintainers). > > > At the release day, you'll sync your security work on top of jdk8u/jdk11u > > and add a final jdk-11.0.3+xx tag and the jdk-11.0.3-ga tag (which should > > point to the same change). And this will be integrated back to jdk11u-dev. > > > > > > What do you think of that? > > > > I can live with that. I'm a bit nervous about pushing changes to jdk8u > > before jdk8u-dev, but as long as it is tested regularly and integrated > > back into jdk8u-dev, it's ok. Incidentally, has 11u being tagged yet? > > It has, yes. Ok. In future, it may be best not to miss out the equivalent of jdk-11.0.3+0 :-) > > > On your final point, the -ga tag will be the point at which we branch > > + the private CPU changes (which will be smaller than the batches > > Oracle pushed, as we are only keeping private those that are > > embargoed, not the entire release set). This is why I suggest we > > declare the branch frozen at the point we use as a base internally, so > > there are not changes between the baseline for the CPU and when we > > push upstream. Tagging -ga after a merge would represent something > > different from what we have already based our update binaries on. > > Well, jdk11u is virtually frozen already (with about 6 weeks to go until GA). We only expect few stabilization changes. And whenever you start your work on the security repo, you can do merges from jdk11u back into your private repository at any time. > > Having said that, I, however, agree, that 'ga' should not be a merge between something that you worked on an tested in private and something that has diverged meanwhile in the public. > That means, between the point when you've synced the last public jdk11.0.3+x into your private repo and the sync back of jdk11.0.3+(x+1) == jdk11.0.3-ga, there must not be changes in the public repository. > So we should announce on the mailing list when we have a tag that we intend to use base for GA. And after that, no pushes any more to jdk11u, that's your hard freeze. :) > What'll be the time you need for that final round of testing? Maybe 1-2 weeks before GA? Yeah, I'd prefer to keep such merges to a minimum and only really essential fixes should be going in during the later stages. i see four changes already post-tag. It depends a lot on the vulnerability group, but yes, I was thinking the start of the month of the CPU (so April for this next one). > > Best regards > Christoph > -- 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 goetz.lindenmaier at sap.com Mon Mar 4 17:18:42 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 4 Mar 2019 17:18:42 +0000 Subject: 8u/11u repo access and Jira changes In-Reply-To: References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com> <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com> <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com> <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com> <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com> <06f09798-cade-b882-fb3e-4049733fa8cc@redhat.com> <3f49543e8bd14cf5b3ed7381abaad339@sap.com> <5bcb63d5207144c7b436d3594d9cb789@sap.com> Message-ID: Hi Andrew, > It depends a lot on the vulnerability group, but yes, I was thinking > the start of the month of the CPU (so April for this next one). That seems to be a good point, I don't think we should go more later, rather more early. If it wasn't for jcheck not accepting other tags, I would propose to tag it at that point with 11.0.3-rc (For release candidate, see JEP 3). Best regards, Goetz. > -----Original Message----- > From: Andrew Hughes > Sent: Monday, March 4, 2019 6:09 PM > To: Langer, Christoph > Cc: jdk8u-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net; > Lindenmaier, Goetz ; Aleksey Shipilev > > Subject: Re: 8u/11u repo access and Jira changes > > On Mon, 4 Mar 2019 at 06:42, Langer, Christoph > wrote: > > > > Hi Andrew, > > > > > > We sync once per CPU release cycle from jdk8u-dev -> jdk8u, > respectively > > > from jdk11u-dev to jdk11u. For jdk11u, we've kind of done it now by the > > > creation of the jdk11u-dev repo. For jdk8u I propose to do the initial push > to > > > jdk8u once all open Oracle backports were integrated. > > > > Then, I expect a few pushes to jdk8u/jdk11u and we'll tag these once in > a > > > while like jdk-11.0.3+1 etc. These tags will be integrated back to dev > regularly > > > (by those who set the tags, that is, the maintainers). > > > > At the release day, you'll sync your security work on top of > jdk8u/jdk11u > > > and add a final jdk-11.0.3+xx tag and the jdk-11.0.3-ga tag (which should > > > point to the same change). And this will be integrated back to jdk11u-dev. > > > > > > > > What do you think of that? > > > > > > I can live with that. I'm a bit nervous about pushing changes to jdk8u > > > before jdk8u-dev, but as long as it is tested regularly and integrated > > > back into jdk8u-dev, it's ok. Incidentally, has 11u being tagged yet? > > > > It has, yes. > > Ok. In future, it may be best not to miss out the equivalent of jdk-11.0.3+0 :-) > > > > > > On your final point, the -ga tag will be the point at which we branch > > > + the private CPU changes (which will be smaller than the batches > > > Oracle pushed, as we are only keeping private those that are > > > embargoed, not the entire release set). This is why I suggest we > > > declare the branch frozen at the point we use as a base internally, so > > > there are not changes between the baseline for the CPU and when we > > > push upstream. Tagging -ga after a merge would represent something > > > different from what we have already based our update binaries on. > > > > Well, jdk11u is virtually frozen already (with about 6 weeks to go until GA). > We only expect few stabilization changes. And whenever you start your work > on the security repo, you can do merges from jdk11u back into your private > repository at any time. > > > > Having said that, I, however, agree, that 'ga' should not be a merge > between something that you worked on an tested in private and something > that has diverged meanwhile in the public. > > That means, between the point when you've synced the last public > jdk11.0.3+x into your private repo and the sync back of jdk11.0.3+(x+1) == > jdk11.0.3-ga, there must not be changes in the public repository. > > So we should announce on the mailing list when we have a tag that we > intend to use base for GA. And after that, no pushes any more to jdk11u, > that's your hard freeze. :) > > What'll be the time you need for that final round of testing? Maybe 1-2 > weeks before GA? > > Yeah, I'd prefer to keep such merges to a minimum and only really > essential fixes should be going in during the later stages. > i see four changes already post-tag. > > It depends a lot on the vulnerability group, but yes, I was thinking > the start of the month of the CPU (so April for this next one). > > > > > Best regards > > Christoph > > > > > -- > 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 takiguc at linux.vnet.ibm.com Mon Mar 4 18:15:19 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 05 Mar 2019 03:15:19 +0900 Subject: Confirmation about jdk11u approval process In-Reply-To: <88b81bd3-e18e-940e-b35f-c537b0aa4e40@redhat.com> References: <634770840670d2ee3a21f7c531da3b0b@linux.vnet.ibm.com> <2e7d6ad873235c18aaa3226bbc829556@linux.vnet.ibm.com> <76e25246-9c59-958f-e810-22e589394fb8@redhat.com> <709b444897ff7f16718ca52952e7e0cc@linux.vnet.ibm.com> <9deb06ddd428c2ac0918d74d0097ef83@linux.vnet.ibm.com> <508bb433-9980-0e1c-c52b-f889b7bc0648@redhat.com> <233528c2770b617d06f0df662a41b61a@linux.vnet.ibm.com> <88b81bd3-e18e-940e-b35f-c537b0aa4e40@redhat.com> Message-ID: <3d8dda5b2dd4e0e2928bcd8d4cd5d3cd@linux.vnet.ibm.com> Hello Aleksey. Sorry, I was confused... According to make/autoconf/version-numbers. GA date will be 2019-04-16 (I did not know that...) RDP2 date might be 2019-01-22... (12 weeks before GA) I appreciate if you put the changesets to 11.0.4 (jdk11u-dev). BTW, I have one more question. Japanese era name will be changed on May 1, 2019. Then new Japanese era name will be announced on April 1, 2019. [1] Is it possible to apply the changes for new Japanese era name into 11.0.3 ? I assume i18n members will submit the changes. [1] https://www.japantimes.co.jp/news/2019/01/04/national/politics-diplomacy/name-japans-next-imperial-era-announced-april-1-abe-confirms/#.XH1mZWPgqpo Thanks, Ichiroh Takiguchi On 2019-03-04 22:09, Aleksey Shipilev wrote: > On 3/4/19 1:13 PM, Ichiroh Takiguchi wrote: >> Hello Aleksey. >> >> For [1], it's only happened on 64bit CPU. >> So actually, JDK6. >> But it's still older... >> I will obey maintainers decision. >> >> I appreciate if you push [2] - [6] to 11.0.3. > > Wait. As I said, all current pushes go to 11.0.4, *unless* maintainer > specifically granted the > approval specifically for 11.0.3. Which did not happen for any of > these six issues. So, [1]-[6] > would go to 11.0.4, okay? > > As I applied all the patches to current jdk11u-dev, I realized that > some of them are AIX-specific. > While the whole bunch passes tier1 tests on my Linux x86_64, we better > confirm it does not break > AIX. It is unclear from the Fix Requests: have you tested these on > AIX? Or, should we ask Christoph > to do it? > > The changeset bunch is here: > > http://cr.openjdk.java.net/~shade/backports-11u/ibm-charsets/webrev.01/ > > -Aleksey From takiguc at linux.vnet.ibm.com Mon Mar 4 18:22:19 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 05 Mar 2019 03:22:19 +0900 Subject: Confirmation about jdk11u approval process In-Reply-To: References: <634770840670d2ee3a21f7c531da3b0b@linux.vnet.ibm.com> <2e7d6ad873235c18aaa3226bbc829556@linux.vnet.ibm.com> <76e25246-9c59-958f-e810-22e589394fb8@redhat.com> <709b444897ff7f16718ca52952e7e0cc@linux.vnet.ibm.com> <9deb06ddd428c2ac0918d74d0097ef83@linux.vnet.ibm.com> Message-ID: <973d63017bf162de95898284569439b4@linux.vnet.ibm.com> Hello Goetz. Thank you for your explanation. I sent a new request to Aleksey to put the changesets into 11.0.4 (jdk11u-dev). Thanks, Ichiroh Takiguchi On 2019-03-04 23:36, Lindenmaier, Goetz wrote: > Hi Ichiroh, > > To go to 11.0.3, they need to be P1 or P2 bugs, or pure test > changes. Jdk11.0.3 in the jdk11u reporsitory is in rampdown > phase two: https://openjdk.java.net/jeps/3 > If they were P1 or P2, and you had wanted to get them to 11.0.3, > it would have been best if you hsd stated so in the Fix Request > comment. > > Thus, please get the changes pushed to jdk11u-dev. > > Best regards, > Goetz > > >> -----Original Message----- >> From: jdk-updates-dev On >> Behalf Of Ichiroh Takiguchi >> Sent: Monday, March 4, 2019 12:11 PM >> To: Andrew Haley >> Cc: jdk-updates-dev at openjdk.java.net >> Subject: Re: Confirmation about jdk11u approval process >> >> Hello Andrew. >> >> Sorry for disturb you again. >> >> Thank you for handing jdk11u-fix-request. >> I got jdk11u-fix-yes for following bug ids. >> >> JDK-8211393 [1], JDK-8208634 [2], JDK-8213618 [3], JDK-8212794 [4], >> JDK-8214533 [5], JDK-8217880 [6] >> >> I have additional question. >> How can I determine these are for 11.0.3 or 11.0.4 ? >> >> If these are for 11.0.3, I need to find out the sponsor for them >> as soon as possible. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8211393 >> [2] https://bugs.openjdk.java.net/browse/JDK-8208634 >> [3] https://bugs.openjdk.java.net/browse/JDK-8213618 >> [4] https://bugs.openjdk.java.net/browse/JDK-8212794 >> [5] https://bugs.openjdk.java.net/browse/JDK-8214533 >> [6] https://bugs.openjdk.java.net/browse/JDK-8217880 >> >> Thanks, >> Ichiroh Takiguchi >> >> On 2019-03-01 03:35, Ichiroh Takiguchi wrote: >> > Hello Andrew. >> > >> >> What makes this critical? It looks like a minor memory leak. How long >> >> would it >> >> take interacting with an application before a user noticed a problem? >> > It depends on how many characters user typed. >> > I assume memory leak size is less than 1KB for each input method >> > handling event. >> > I did not check the impact for this issue... >> > >> > Thanks, >> > Ichiroh Takiguchi >> > >> > On 2019-02-28 22:51, Andrew Haley wrote: >> >> Hi, >> >> >> >> On 2/28/19 1:22 PM, Ichiroh Takiguchi wrote: >> >>> I did not know about milestones for jdk11u. >> >>> So I was late... >> >>> >> >>> Critical one may be JDK-8211393 [1] for Unix platform. >> >> >> >> What makes this critical? It looks like a minor memory leak. How long >> >> would it >> >> take interacting with an application before a user noticed a problem? From goetz.lindenmaier at sap.com Mon Mar 4 20:06:38 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 4 Mar 2019 20:06:38 +0000 Subject: Confirmation about jdk11u approval process In-Reply-To: <3d8dda5b2dd4e0e2928bcd8d4cd5d3cd@linux.vnet.ibm.com> References: <634770840670d2ee3a21f7c531da3b0b@linux.vnet.ibm.com> <2e7d6ad873235c18aaa3226bbc829556@linux.vnet.ibm.com> <76e25246-9c59-958f-e810-22e589394fb8@redhat.com> <709b444897ff7f16718ca52952e7e0cc@linux.vnet.ibm.com> <9deb06ddd428c2ac0918d74d0097ef83@linux.vnet.ibm.com> <508bb433-9980-0e1c-c52b-f889b7bc0648@redhat.com> <233528c2770b617d06f0df662a41b61a@linux.vnet.ibm.com> <88b81bd3-e18e-940e-b35f-c537b0aa4e40@redhat.com> <3d8dda5b2dd4e0e2928bcd8d4cd5d3cd@linux.vnet.ibm.com> Message-ID: Hi Ichiroh, > BTW, I have one more question. > Japanese era name will be changed on May 1, 2019. > Then new Japanese era name will be announced on April 1, 2019. [1] > Is it possible to apply the changes for new Japanese era name into > 11.0.3 ? > I assume i18n members will submit the changes. We pushed some era changes to 11.0.3 aka jdk11u. Is something missing? Maybe you can verify them ?? ... I'm not familiar with Japanese eras ... Best regards, Goetz > > [1] > https://www.japantimes.co.jp/news/2019/01/04/national/politics- > diplomacy/name-japans-next-imperial-era-announced-april-1-abe- > confirms/#.XH1mZWPgqpo > > Thanks, > Ichiroh Takiguchi > > On 2019-03-04 22:09, Aleksey Shipilev wrote: > > On 3/4/19 1:13 PM, Ichiroh Takiguchi wrote: > >> Hello Aleksey. > >> > >> For [1], it's only happened on 64bit CPU. > >> So actually, JDK6. > >> But it's still older... > >> I will obey maintainers decision. > >> > >> I appreciate if you push [2] - [6] to 11.0.3. > > > > Wait. As I said, all current pushes go to 11.0.4, *unless* maintainer > > specifically granted the > > approval specifically for 11.0.3. Which did not happen for any of > > these six issues. So, [1]-[6] > > would go to 11.0.4, okay? > > > > As I applied all the patches to current jdk11u-dev, I realized that > > some of them are AIX-specific. > > While the whole bunch passes tier1 tests on my Linux x86_64, we better > > confirm it does not break > > AIX. It is unclear from the Fix Requests: have you tested these on > > AIX? Or, should we ask Christoph > > to do it? > > > > The changeset bunch is here: > > > > http://cr.openjdk.java.net/~shade/backports-11u/ibm- > charsets/webrev.01/ > > > > -Aleksey From takiguc at linux.vnet.ibm.com Tue Mar 5 04:28:27 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 05 Mar 2019 13:28:27 +0900 Subject: Confirmation about jdk11u approval process In-Reply-To: References: <634770840670d2ee3a21f7c531da3b0b@linux.vnet.ibm.com> <2e7d6ad873235c18aaa3226bbc829556@linux.vnet.ibm.com> <76e25246-9c59-958f-e810-22e589394fb8@redhat.com> <709b444897ff7f16718ca52952e7e0cc@linux.vnet.ibm.com> <9deb06ddd428c2ac0918d74d0097ef83@linux.vnet.ibm.com> <508bb433-9980-0e1c-c52b-f889b7bc0648@redhat.com> <233528c2770b617d06f0df662a41b61a@linux.vnet.ibm.com> <88b81bd3-e18e-940e-b35f-c537b0aa4e40@redhat.com> <3d8dda5b2dd4e0e2928bcd8d4cd5d3cd@linux.vnet.ibm.com> Message-ID: Hello Goetz. jdk11 and the latest jdk11u has placeholder (dummy data). It should be changed to official one after new Japanese era name is announced. Thanks, Ichiroh Takiguchi On 2019-03-05 05:06, Lindenmaier, Goetz wrote: > Hi Ichiroh, > >> BTW, I have one more question. >> Japanese era name will be changed on May 1, 2019. >> Then new Japanese era name will be announced on April 1, 2019. [1] >> Is it possible to apply the changes for new Japanese era name into >> 11.0.3 ? >> I assume i18n members will submit the changes. > We pushed some era changes to 11.0.3 aka jdk11u. Is something > missing? Maybe you can verify them ?? ... I'm not familiar with > Japanese eras ... > > Best regards, > Goetz > > >> >> [1] >> https://www.japantimes.co.jp/news/2019/01/04/national/politics- >> diplomacy/name-japans-next-imperial-era-announced-april-1-abe- >> confirms/#.XH1mZWPgqpo >> >> Thanks, >> Ichiroh Takiguchi >> >> On 2019-03-04 22:09, Aleksey Shipilev wrote: >> > On 3/4/19 1:13 PM, Ichiroh Takiguchi wrote: >> >> Hello Aleksey. >> >> >> >> For [1], it's only happened on 64bit CPU. >> >> So actually, JDK6. >> >> But it's still older... >> >> I will obey maintainers decision. >> >> >> >> I appreciate if you push [2] - [6] to 11.0.3. >> > >> > Wait. As I said, all current pushes go to 11.0.4, *unless* maintainer >> > specifically granted the >> > approval specifically for 11.0.3. Which did not happen for any of >> > these six issues. So, [1]-[6] >> > would go to 11.0.4, okay? >> > >> > As I applied all the patches to current jdk11u-dev, I realized that >> > some of them are AIX-specific. >> > While the whole bunch passes tier1 tests on my Linux x86_64, we better >> > confirm it does not break >> > AIX. It is unclear from the Fix Requests: have you tested these on >> > AIX? Or, should we ask Christoph >> > to do it? >> > >> > The changeset bunch is here: >> > >> > http://cr.openjdk.java.net/~shade/backports-11u/ibm- >> charsets/webrev.01/ >> > >> > -Aleksey From christoph.langer at sap.com Tue Mar 5 06:51:15 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 5 Mar 2019 06:51:15 +0000 Subject: Confirmation about jdk11u approval process In-Reply-To: References: <634770840670d2ee3a21f7c531da3b0b@linux.vnet.ibm.com> <2e7d6ad873235c18aaa3226bbc829556@linux.vnet.ibm.com> <76e25246-9c59-958f-e810-22e589394fb8@redhat.com> <709b444897ff7f16718ca52952e7e0cc@linux.vnet.ibm.com> <9deb06ddd428c2ac0918d74d0097ef83@linux.vnet.ibm.com> <508bb433-9980-0e1c-c52b-f889b7bc0648@redhat.com> <233528c2770b617d06f0df662a41b61a@linux.vnet.ibm.com> <88b81bd3-e18e-940e-b35f-c537b0aa4e40@redhat.com> <3d8dda5b2dd4e0e2928bcd8d4cd5d3cd@linux.vnet.ibm.com> Message-ID: Hi Ichiroh, > jdk11 and the latest jdk11u has placeholder (dummy data). > It should be changed to official one after new Japanese era name is > announced. Yes, I think Oracle's plan is to create the change for the new Japanese Era name beginning of April once it is available and before GA of the April patch (16th of April). So we'll most probably also include this in 11.0.3. @gnu.andrew: That's also a heads up for you. This change will very likely be done in the "freeze" period of 11u. Best regards Christoph From christoph.langer at sap.com Tue Mar 5 06:55:46 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 5 Mar 2019 06:55:46 +0000 Subject: Confirmation about jdk11u approval process In-Reply-To: <88b81bd3-e18e-940e-b35f-c537b0aa4e40@redhat.com> References: <634770840670d2ee3a21f7c531da3b0b@linux.vnet.ibm.com> <2e7d6ad873235c18aaa3226bbc829556@linux.vnet.ibm.com> <76e25246-9c59-958f-e810-22e589394fb8@redhat.com> <709b444897ff7f16718ca52952e7e0cc@linux.vnet.ibm.com> <9deb06ddd428c2ac0918d74d0097ef83@linux.vnet.ibm.com> <508bb433-9980-0e1c-c52b-f889b7bc0648@redhat.com> <233528c2770b617d06f0df662a41b61a@linux.vnet.ibm.com> <88b81bd3-e18e-940e-b35f-c537b0aa4e40@redhat.com> Message-ID: <830e45786cc4401d8308ed01138dbe76@sap.com> Hi Ichiroh, Aleksey, > As I applied all the patches to current jdk11u-dev, I realized that some of > them are AIX-specific. > While the whole bunch passes tier1 tests on my Linux x86_64, we better > confirm it does not break > AIX. It is unclear from the Fix Requests: have you tested these on AIX? Or, > should we ask Christoph > to do it? > > The changeset bunch is here: > http://cr.openjdk.java.net/~shade/backports-11u/ibm- > charsets/webrev.01/ We'll run it through our test queue. Maybe you'll have to bear with me for a few days as we're currently setting up things for building/testing jdk11u-dev (Before, we only had jdk11u). I'll let you know when it ran through and has some valid results. Best regards Christoph From christoph.langer at sap.com Tue Mar 5 07:32:44 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 5 Mar 2019 07:32:44 +0000 Subject: 8u/11u repo access and Jira changes In-Reply-To: References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com> <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com> <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com> <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com> <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com> <06f09798-cade-b882-fb3e-4049733fa8cc@redhat.com> <3f49543e8bd14cf5b3ed7381abaad339@sap.com> <5bcb63d5207144c7b436d3594d9cb789@sap.com> Message-ID: <739e16adb54c490eb551e226b09f84de@sap.com> Hi Andrew, > Ok. In future, it may be best not to miss out the equivalent of jdk-11.0.3+0 :-) Sure, jdk-11.0.4+0 is already present in jdk11u-dev. :) If jdk-11.0.3+0 is particularly important to you for some reason, we can still tag some change with that label... Do you need that? /Christoph From aph at redhat.com Tue Mar 5 09:39:23 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 Mar 2019 09:39:23 +0000 Subject: Confirmation about jdk11u approval process In-Reply-To: References: <634770840670d2ee3a21f7c531da3b0b@linux.vnet.ibm.com> <2e7d6ad873235c18aaa3226bbc829556@linux.vnet.ibm.com> <76e25246-9c59-958f-e810-22e589394fb8@redhat.com> <709b444897ff7f16718ca52952e7e0cc@linux.vnet.ibm.com> <9deb06ddd428c2ac0918d74d0097ef83@linux.vnet.ibm.com> <508bb433-9980-0e1c-c52b-f889b7bc0648@redhat.com> <233528c2770b617d06f0df662a41b61a@linux.vnet.ibm.com> <88b81bd3-e18e-940e-b35f-c537b0aa4e40@redhat.com> <3d8dda5b2dd4e0e2928bcd8d4cd5d3cd@linux.vnet.ibm.com> Message-ID: <713c2b19-a803-ac8d-3af5-a6bb4e5f1bc0@redhat.com> On 3/5/19 6:51 AM, Langer, Christoph wrote: > >> jdk11 and the latest jdk11u has placeholder (dummy data). >> It should be changed to official one after new Japanese era name is >> announced. > Yes, I think Oracle's plan is to create the change for the new Japanese Era name beginning of April once it is available and before GA of the April patch (16th of April). So we'll most probably also include this in 11.0.3. > > @gnu.andrew: That's also a heads up for you. This change will very likely be done in the "freeze" period of 11u. Thank you. That's very useful to know. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Tue Mar 5 17:18:45 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 5 Mar 2019 18:18:45 +0100 Subject: Confirmation about jdk11u approval process In-Reply-To: <830e45786cc4401d8308ed01138dbe76@sap.com> References: <634770840670d2ee3a21f7c531da3b0b@linux.vnet.ibm.com> <2e7d6ad873235c18aaa3226bbc829556@linux.vnet.ibm.com> <76e25246-9c59-958f-e810-22e589394fb8@redhat.com> <709b444897ff7f16718ca52952e7e0cc@linux.vnet.ibm.com> <9deb06ddd428c2ac0918d74d0097ef83@linux.vnet.ibm.com> <508bb433-9980-0e1c-c52b-f889b7bc0648@redhat.com> <233528c2770b617d06f0df662a41b61a@linux.vnet.ibm.com> <88b81bd3-e18e-940e-b35f-c537b0aa4e40@redhat.com> <830e45786cc4401d8308ed01138dbe76@sap.com> Message-ID: <5cbd9f1a-3ed0-a83d-948b-d1288343398c@redhat.com> On 3/5/19 7:55 AM, Langer, Christoph wrote: >> While the whole bunch passes tier1 tests on my Linux x86_64, we better confirm it does not >> break AIX. It is unclear from the Fix Requests: have you tested these on AIX? Or, should we ask >> Christoph to do it? >> >> The changeset bunch is here: >> http://cr.openjdk.java.net/~shade/backports-11u/ibm-charsets/webrev.01/ > > We'll run it through our test queue. Maybe you'll have to bear with me for a few days as we're currently setting up things for building/testing jdk11u-dev (Before, we only had jdk11u). I'll let you know when it ran through and has some valid results. No problem, this can wait a few days. Tell me when testing is done. -Aleksey From goetz.lindenmaier at sap.com Tue Mar 5 20:47:43 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 5 Mar 2019 20:47:43 +0000 Subject: 8u/11u repo access and Jira changes In-Reply-To: References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com> <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com> <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com> <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com> <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com> <06f09798-cade-b882-fb3e-4049733fa8cc@redhat.com> <3f49543e8bd14cf5b3ed7381abaad339@sap.com> <90c57878b5254c6ca2d496a2a59b8eb8@sap.com> Message-ID: Hmm, no comments yet on this ... assuming nobody objects I will tag tomorrow and run the tests tomorrow night. Best regards, Goetz > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Monday, March 4, 2019 4:17 PM > To: Lindenmaier, Goetz ; Langer, Christoph > ; Andrew Hughes > Cc: jdk8u-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net > Subject: RE: 8u/11u repo access and Jira changes > > Hi Andrew, Aleksey, community, > > Before, I proposed this, but got no comments: > > I (backed up by Christoph and the rest of the SAP team) would volunteer > to > > 1. tag jdk11u on a weekly basis after running our tests (if there was a > change) > > 2. merge the tag to jdk11u-dev and run tests on the merged repo > > 3. push the changes to jdk11u-dev the day after. > > Should SAP take the role of doing above merges? > > Best regards, > Goetz > > > > > > > I would propose to tag the change that is built by our infrastructure on > > > > the night Tuesday-Wednesday, which is usually pulled on Tuesday 18:00 > CET. > > > > In the night Wednesday-Thursday, the tests would run on jdk11u-dev > > including > > > > the changes merged from jdk11u. Test results will pop up during the day > > (Thursday), > > > > the merged changes could be pushed on Thursday evening or Friday > morning. > > > > > > > > Our testing currently covers the following: > > > > > > > > We build the following platforms: > > > > Aix > > > > Linux ppc64 > > > > Linux ppc64le > > > > Linux s390x > > > > Linux x86_64 > > > > mac > > > > Solaris sparc > > > > Windows x86_64 > > > > Windows x86_32 > > > > We finally got an aarch64 machine, we could add that to the tests. > > > > > > > > We run the following tests every night: > > > > A big part of the jck tests (excluding those requiring manual testing, and a > > list of shaky tests) > > > > The jck tests with -Xcomp and C1, and with -Xcomp and C2. > > > > The hotspot and jdk jtreg tests, excluding those marked with key > "headful", > > "printer" and "intermittent" > > > > Jvm2008, jbb2015, jvm98 > > > > And finally some SAP applications. > > > > > > > > But I'm also fine with leaving this task to RedHat, Aleksey or Andrew > Hughes > > or whoever > > > > would be available on your side. > > > > > > > > For the move jdk11u-dev-->jdk11u, which happens only once a release, we > > should > > > > do this by communication on the mailing list. > > > > > > > > Best regards, > > > > Goetz. > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Langer, Christoph > > > > > Sent: Tuesday, February 26, 2019 10:41 PM > > > > > To: Andrew Hughes > > > > > Cc: jdk8u-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net; > > > > > Lindenmaier, Goetz ; Aleksey Shipilev > > > > > > > > > > Subject: RE: 8u/11u repo access and Jira changes > > > > > > > > > > Hi Andrew, > > > > > > > > > > > The questions I really need answers to are: > > > > > > > > > > > > 1. Who is going to push from jdk8u-dev -> jdk8u? > > > > > > > > > > The maintainers (you, Aleksey, me, Goetz, ...) > > > > > > > > > > > 2. What is the frequency of these pushes going to be? > > > > > > > > > > Ok, again, here's our proposal (from the SAP folks): > > > > > > > > > > We sync once per CPU release cycle from jdk8u-dev -> jdk8u, > respectively > > > > > from jdk11u-dev to jdk11u. For jdk11u, we've kind of done it now by the > > > > > creation of the jdk11u-dev repo. For jdk8u I propose to do the initial push > > to > > > > > jdk8u once all open Oracle backports were integrated. > > > > > Then, I expect a few pushes to jdk8u/jdk11u and we'll tag these once in a > > > > > while like jdk-11.0.3+1 etc. These tags will be integrated back to dev > > regularly > > > > > (by those who set the tags, that is, the maintainers). > > > > > At the release day, you'll sync your security work on top of jdk8u/jdk11u > > and > > > > > add a final jdk-11.0.3+xx tag and the jdk-11.0.3-ga tag (which should point > > to > > > > > the same change). And this will be integrated back to jdk11u-dev. > > > > > > > > > > What do you think of that? > > > > > > > > > > > 3. What testing is going to be performed prior to these pushes? > > > > > > > > > > Good question, currently I guess it's our quality testing at SAP plus > > whatever > > > > > you have at RedHat. We should eventually get to something better, e.g. > > have > > > > > some open test results from AdoptOpenJDK...?? > > > > > > > > > > > I'd prefer regular pushes with tags, because that would help us > > > > > > downstream (aarch64-port/jdk8u-shenandoah, > > > > > > shenandoah/jdk11) in being able to integrate changes more frequently. > > > > > > Under Oracle, we've had to do that at GA time only. > > > > > > > > > > That should be helped with our concept. > > > > > > > > > > Best regards > > > > > Christoph > > From ali.ince at gmail.com Wed Mar 6 00:03:44 2019 From: ali.ince at gmail.com (Ali Ince) Date: Wed, 6 Mar 2019 00:03:44 +0000 Subject: [11u] 8215123: Crash in runtime image built with jlink --compress=2 Message-ID: Hi All, I would like to backport this fix to 11u as it was the first reported environment and still suffers from the reported error. Bug: https://bugs.openjdk.java.net/browse/JDK-8215123 Fix (Original): http://hg.openjdk.java.net/jdk/client/rev/818b7bf2af49 I've verified the patch and would be glad if someone could sponsor the backport. The original patch itself can directly be applied into 11u without any changes, and can be found below as well. Thanks, Ali ------- # HG changeset patch # User aivanov # Date 1544537517 0 # Node ID 818b7bf2af49e40e0a4fb0ba62fc8ba500d0c709 # Parent a659ccd1888d9d9ff444a62df04ad264f4d2eb1a 8215123: Crash in runtime image built with jlink --compress=2 Reviewed-by: ihse, alanb diff -r a659ccd1888d -r 818b7bf2af49 src/java.base/share/native/libjimage/imageDecompressor.cpp --- a/src/java.base/share/native/libjimage/imageDecompressor.cpp Tue Dec 11 11:45:43 2018 +0530 +++ b/src/java.base/share/native/libjimage/imageDecompressor.cpp Tue Dec 11 14:11:57 2018 +0000 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2015, 2016, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions @@ -38,8 +38,8 @@ #include #endif -typedef jboolean (JNICALL *ZipInflateFully_t)(void *inBuf, jlong inLen, - void *outBuf, jlong outLen, char **pmsg); +typedef jboolean (*ZipInflateFully_t)(void *inBuf, jlong inLen, + void *outBuf, jlong outLen, char **pmsg); static ZipInflateFully_t ZipInflateFully = NULL; #ifndef WIN32 From christoph.langer at sap.com Wed Mar 6 07:24:31 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 6 Mar 2019 07:24:31 +0000 Subject: [11u] 8215123: Crash in runtime image built with jlink --compress=2 In-Reply-To: References: Message-ID: Hi Ali, Your request sounds reasonable to me. I've tagged the issue with "jdk11u-fix-request". When it gets accepted, I'll sponsor it for jdk11u-dev (11.0.4). Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Ali Ince > Sent: Mittwoch, 6. M?rz 2019 01:04 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] 8215123: Crash in runtime image built with jlink --compress=2 > > Hi All, > > I would like to backport this fix to 11u as it was the first reported > environment and still suffers from the reported error. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215123 > Fix (Original): http://hg.openjdk.java.net/jdk/client/rev/818b7bf2af49 > > I've verified the patch and would be glad if someone could sponsor the > backport. > > The original patch itself can directly be applied into 11u without any > changes, and can be found below as well. > > Thanks, > > Ali > > ------- > > # HG changeset patch > # User aivanov > # Date 1544537517 0 > # Node ID 818b7bf2af49e40e0a4fb0ba62fc8ba500d0c709 > # Parent a659ccd1888d9d9ff444a62df04ad264f4d2eb1a > 8215123: Crash in runtime image built with jlink --compress=2 > Reviewed-by: ihse, alanb > > diff -r a659ccd1888d -r 818b7bf2af49 > src/java.base/share/native/libjimage/imageDecompressor.cpp > --- a/src/java.base/share/native/libjimage/imageDecompressor.cpp Tue Dec > 11 > 11:45:43 2018 +0530 > +++ b/src/java.base/share/native/libjimage/imageDecompressor.cpp Tue > Dec 11 > 14:11:57 2018 +0000 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2015, 2016, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights > reserved. > * > * Redistribution and use in source and binary forms, with or without > * modification, are permitted provided that the following conditions > @@ -38,8 +38,8 @@ > #include > #endif > > -typedef jboolean (JNICALL *ZipInflateFully_t)(void *inBuf, jlong inLen, > - void *outBuf, jlong outLen, > char **pmsg); > +typedef jboolean (*ZipInflateFully_t)(void *inBuf, jlong inLen, > + void *outBuf, jlong outLen, char > **pmsg); > static ZipInflateFully_t ZipInflateFully = NULL; > > #ifndef WIN32 From christoph.langer at sap.com Wed Mar 6 16:23:57 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 6 Mar 2019 16:23:57 +0000 Subject: Confirmation about jdk11u approval process In-Reply-To: <5cbd9f1a-3ed0-a83d-948b-d1288343398c@redhat.com> References: <634770840670d2ee3a21f7c531da3b0b@linux.vnet.ibm.com> <2e7d6ad873235c18aaa3226bbc829556@linux.vnet.ibm.com> <76e25246-9c59-958f-e810-22e589394fb8@redhat.com> <709b444897ff7f16718ca52952e7e0cc@linux.vnet.ibm.com> <9deb06ddd428c2ac0918d74d0097ef83@linux.vnet.ibm.com> <508bb433-9980-0e1c-c52b-f889b7bc0648@redhat.com> <233528c2770b617d06f0df662a41b61a@linux.vnet.ibm.com> <88b81bd3-e18e-940e-b35f-c537b0aa4e40@redhat.com> <830e45786cc4401d8308ed01138dbe76@sap.com> <5cbd9f1a-3ed0-a83d-948b-d1288343398c@redhat.com> Message-ID: Hi guys, seems like our test infrastructure for jdk11u-dev is now at a point where it is usable. ?? So I'll run the patch through verification tonight. Would you mind when I do the push tomorrow, assuming no regressions observed? /Christoph > -----Original Message----- > From: Aleksey Shipilev > Sent: Dienstag, 5. M?rz 2019 18:19 > To: Langer, Christoph ; Ichiroh Takiguchi > > Cc: jdk-updates-dev at openjdk.java.net > Subject: Re: Confirmation about jdk11u approval process > > On 3/5/19 7:55 AM, Langer, Christoph wrote: > >> While the whole bunch passes tier1 tests on my Linux x86_64, we better > confirm it does not > >> break AIX. It is unclear from the Fix Requests: have you tested these on > AIX? Or, should we ask > >> Christoph to do it? > >> > >> The changeset bunch is here: > >> http://cr.openjdk.java.net/~shade/backports-11u/ibm- > charsets/webrev.01/ > > > > We'll run it through our test queue. Maybe you'll have to bear with me for > a few days as we're currently setting up things for building/testing jdk11u- > dev (Before, we only had jdk11u). I'll let you know when it ran through and > has some valid results. > > No problem, this can wait a few days. Tell me when testing is done. > > -Aleksey > From shade at redhat.com Wed Mar 6 16:26:30 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 6 Mar 2019 17:26:30 +0100 Subject: Confirmation about jdk11u approval process In-Reply-To: References: <634770840670d2ee3a21f7c531da3b0b@linux.vnet.ibm.com> <2e7d6ad873235c18aaa3226bbc829556@linux.vnet.ibm.com> <76e25246-9c59-958f-e810-22e589394fb8@redhat.com> <709b444897ff7f16718ca52952e7e0cc@linux.vnet.ibm.com> <9deb06ddd428c2ac0918d74d0097ef83@linux.vnet.ibm.com> <508bb433-9980-0e1c-c52b-f889b7bc0648@redhat.com> <233528c2770b617d06f0df662a41b61a@linux.vnet.ibm.com> <88b81bd3-e18e-940e-b35f-c537b0aa4e40@redhat.com> <830e45786cc4401d8308ed01138dbe76@sap.com> <5cbd9f1a-3ed0-a83d-948b-d1288343398c@redhat.com> Message-ID: <8594868b-eca2-ffdd-44f7-80a591099a17@redhat.com> On 3/6/19 5:23 PM, Langer, Christoph wrote: > Would you mind when I do the push tomorrow, assuming no regressions observed? No problems from me. I tested the bunch on Linux x86_64, and it seems fine. -Aleksey From gnu.andrew at redhat.com Wed Mar 6 18:13:03 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 6 Mar 2019 18:13:03 +0000 Subject: 8u/11u repo access and Jira changes In-Reply-To: References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com> <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com> <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com> <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com> <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com> <06f09798-cade-b882-fb3e-4049733fa8cc@redhat.com> <3f49543e8bd14cf5b3ed7381abaad339@sap.com> <90c57878b5254c6ca2d496a2a59b8eb8@sap.com> Message-ID: On 05/03/2019 20:47, Remainder, Goethe wrote: > Hmm, no comments yet on this ... assuming nobody objects > I will tag tomorrow and run the tests tomorrow night. > > Best regards, > Goetz > >> -----Original Message----- >> From: Lindenmaier, Goetz >> Sent: Monday, March 4, 2019 4:17 PM >> To: Lindenmaier, Goetz ; Langer, Christoph >> ; Andrew Hughes >> Cc: jdk8u-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net >> Subject: RE: 8u/11u repo access and Jira changes >> >> Hi Andrew, Aleksey, community, >> >> Before, I proposed this, but got no comments: >>> I (backed up by Christoph and the rest of the SAP team) would volunteer >> to >>> 1. tag jdk11u on a weekly basis after running our tests (if there was a >> change) >>> 2. merge the tag to jdk11u-dev and run tests on the merged repo >>> 3. push the changes to jdk11u-dev the day after. >> >> Should SAP take the role of doing above merges? >> >> Best regards, >> Goetz >> Sorry, I meant to reply with a +1 on this. Are we planning to do something similar with 8U as well? I guess we need to first decide when we are ready to do the first merge from 8U-deb. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inca. (http://www.redhat.com) PP Key: de25519/0FDA0F9B35964222 (kph://keys.gnu.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CODA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Wed Mar 6 18:47:44 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 6 Mar 2019 18:47:44 +0000 Subject: Confirmation about jdk11u approval process In-Reply-To: References: <634770840670d2ee3a21f7c531da3b0b@linux.vnet.ibm.com> <2e7d6ad873235c18aaa3226bbc829556@linux.vnet.ibm.com> <76e25246-9c59-958f-e810-22e589394fb8@redhat.com> <709b444897ff7f16718ca52952e7e0cc@linux.vnet.ibm.com> <9deb06ddd428c2ac0918d74d0097ef83@linux.vnet.ibm.com> <508bb433-9980-0e1c-c52b-f889b7bc0648@redhat.com> <233528c2770b617d06f0df662a41b61a@linux.vnet.ibm.com> <88b81bd3-e18e-940e-b35f-c537b0aa4e40@redhat.com> <3d8dda5b2dd4e0e2928bcd8d4cd5d3cd@linux.vnet.ibm.com> Message-ID: <33e3e9f3-7c22-4bb5-9053-7f96b65e9fb2@redhat.com> On 05/03/2019 06:51, Langer, Christoph wrote: > Hi Ichiroh, > >> jdk11 and the latest jdk11u has placeholder (dummy data). >> It should be changed to official one after new Japanese era name is >> announced. > > Yes, I think Oracle's plan is to create the change for the new Japanese Era name beginning of April once it is available and before GA of the April patch (16th of April). So we'll most probably also include this in 11.0.3. > > @gnu.andrew: That's also a heads up for you. This change will very likely be done in the "freeze" period of 11u. > > Best regards > Christoph > Yes, I'm aware of this. It's something that'll need to go in across 7, 8 and 11. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Wed Mar 6 18:49:09 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 6 Mar 2019 18:49:09 +0000 Subject: 8u/11u repo access and Jira changes In-Reply-To: <739e16adb54c490eb551e226b09f84de@sap.com> References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com> <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com> <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com> <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com> <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com> <06f09798-cade-b882-fb3e-4049733fa8cc@redhat.com> <3f49543e8bd14cf5b3ed7381abaad339@sap.com> <5bcb63d5207144c7b436d3594d9cb789@sap.com> <739e16adb54c490eb551e226b09f84de@sap.com> Message-ID: On 05/03/2019 07:32, Langer, Christoph wrote: > Hi Andrew, > >> Ok. In future, it may be best not to miss out the equivalent of jdk-11.0.3+0 :-) > > Sure, jdk-11.0.4+0 is already present in jdk11u-dev. :) If jdk-11.0.3+0 is particularly important to you for some reason, we can still tag some change with that label... Do you need that? > > /Christoph > No, it was just a consistency thing. As long as we go from 0 in future, I'm fine with it as is. I wasn't aware we were tagging in jdk11u-dev. Is that on a similar regular cycle? 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 Mar 6 21:51:51 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 6 Mar 2019 21:51:51 +0000 Subject: 8u/11u repo access and Jira changes In-Reply-To: References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com> <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com> <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com> <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com> <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com> <06f09798-cade-b882-fb3e-4049733fa8cc@redhat.com> <3f49543e8bd14cf5b3ed7381abaad339@sap.com> <5bcb63d5207144c7b436d3594d9cb789@sap.com> <739e16adb54c490eb551e226b09f84de@sap.com> Message-ID: Hi Andrew, > I wasn't aware we were tagging in jdk11u-dev. Is that on a similar > regular cycle? No, the plan is only to tag ...+0 in jdk11u-dev at the moment we branch off to jdk11u (e.g. next time jdk11.0.5+0 end of May/beginning of June). All further tags well be set in jdk11u and will be merged back regularly. Best regards Christoph From christoph.langer at sap.com Wed Mar 6 22:00:25 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 6 Mar 2019 22:00:25 +0000 Subject: 8u/11u repo access and Jira changes In-Reply-To: References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com> <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com> <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com> <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com> <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com> <06f09798-cade-b882-fb3e-4049733fa8cc@redhat.com> <3f49543e8bd14cf5b3ed7381abaad339@sap.com> <90c57878b5254c6ca2d496a2a59b8eb8@sap.com> Message-ID: Hi, > >> -----Original Message----- > >> From: Lindenmaier, Goetz > >> Sent: Monday, March 4, 2019 4:17 PM > >> To: Lindenmaier, Goetz ; Langer, Christoph > >> ; Andrew Hughes > > >> Cc: jdk8u-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net > >> Subject: RE: 8u/11u repo access and Jira changes > >> > >> Hi Andrew, Aleksey, community, > >> > >> Before, I proposed this, but got no comments: > >>> I (backed up by Christoph and the rest of the SAP team) would > volunteer > >> to > >>> 1. tag jdk11u on a weekly basis after running our tests (if there was a > >> change) > >>> 2. merge the tag to jdk11u-dev and run tests on the merged repo > >>> 3. push the changes to jdk11u-dev the day after. > >> > Are we planning to do something similar with 8U as well? I guess we > need to first decide when we are ready to do the first merge from 8U-deb. I suggest the same should be done with jdk8u. There are 9 issues left: https://bugs.openjdk.java.net/issues/?filter=36394 I think these should be handled now that we can merge to jdk8u. I also looked at the tags: There's no +0 tag in 8u (tag format looks a bit different there, anyway). So I suggest after jdk8u-dev was transported to jdk8u, it should be tagged jdk8u212-b1 in jdk8u. Best regards Christoph From christoph.langer at sap.com Wed Mar 6 23:14:14 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 6 Mar 2019 23:14:14 +0000 Subject: 11u: Fix request process & Where to push? In-Reply-To: References: <6a0001c4e3074f12833b5eaeb82df0fb@sap.com> Message-ID: Hi Man, you have been heard, please look at https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u :) @aph, gnu.andrew, Goetz, Aleksey: I have added/updated information about the 11u processes and timelines to the Wiki. Please review and feel free to correct and update me in the Wiki, be it in spelling/syntax or in content. Thanks & Best regards Christoph From: Man Cao Sent: Freitag, 1. M?rz 2019 21:30 To: jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph Subject: Re: 11u: Fix request process & Where to push? I think it is better to spell out this push policy on one of the documentation sites, e.g.: https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u https://openjdk.java.net/projects/jdk-updates/ New contributors (like me) may not be subscribed to jdk-updates-dev@ when these kinds of announcement for policy change were made. Also given that there is no jdk8u-dev or jdk12u-dev, the distinction in 11u's policy is worth being listed at more obvious places. -Man On Fri, Mar 1, 2019 at 12:34 AM Langer, Christoph > wrote: Hi all, The topic has been discussed in several threads but I feel the need for some explicit communication: Changes that get approved (via the jdk11u-fix-yes label) have to be pushed to the jdk11u-dev repository: http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/. At the moment, those will reach OpenJDK 11.0.4. Do not push to jdk11u !! If you think a fix should still reach 11.0.3, the exceptional process would be that you explicitly state in the "Fix Request" comment that you request the fix to be in 11.0.3 and provide some reasoning for that. The approver will then decide and give the according directions. Thank you! Christoph From sgehwolf at redhat.com Thu Mar 7 09:23:36 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 07 Mar 2019 10:23:36 +0100 Subject: 11u: Fix request process & Where to push? In-Reply-To: References: <6a0001c4e3074f12833b5eaeb82df0fb@sap.com> Message-ID: <41593f1f7196b296ecdc96bf00df14401555d748.camel@redhat.com> Hi, On Wed, 2019-03-06 at 23:14 +0000, Langer, Christoph wrote: > Hi Man, > > you have been heard, please look at > https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u :) > > @aph, gnu.andrew, Goetz, Aleksey: I have added/updated information > about the 11u processes and timelines to the Wiki. Please review and > feel free to correct and update me in the Wiki, be it in > spelling/syntax or in content. Incidentally, I've been working on a more general guidance doc for JDK backports. You can see it here: http://cr.openjdk.java.net/~sgehwolf/upstream-backports-doc.txt Perhaps something like this should go to the updates wiki, but not sure where. Any suggestions? Would this be useful? Thanks, Severin > Thanks & Best regards > Christoph > > From: Man Cao > Sent: Freitag, 1. M?rz 2019 21:30 > To: jdk-updates-dev at openjdk.java.net > Cc: Langer, Christoph > Subject: Re: 11u: Fix request process & Where to push? > > I think it is better to spell out this push policy on one of the > documentation sites, e.g.: > https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u > https://openjdk.java.net/projects/jdk-updates/ > > New contributors (like me) may not be subscribed to jdk-updates-dev@ > when these kinds of announcement for policy change were made. > Also given that there is no jdk8u-dev or jdk12u-dev, the distinction > in 11u's policy is worth being listed at more obvious places. > > -Man > > > On Fri, Mar 1, 2019 at 12:34 AM Langer, Christoph < > christoph.langer at sap.com> wrote: > Hi all, > > The topic has been discussed in several threads but I feel the need > for some explicit communication: > > Changes that get approved (via the jdk11u-fix-yes label) have to be > pushed to the jdk11u-dev repository: > http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/. At the moment, > those will reach OpenJDK 11.0.4. Do not push to jdk11u !! > > If you think a fix should still reach 11.0.3, the exceptional process > would be that you explicitly state in the "Fix Request" comment that > you request the fix to be in 11.0.3 and provide some reasoning for > that. The approver will then decide and give the according > directions. > > Thank you! > Christoph From christoph.langer at sap.com Thu Mar 7 10:43:54 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 7 Mar 2019 10:43:54 +0000 Subject: 11u: Fix request process & Where to push? In-Reply-To: <41593f1f7196b296ecdc96bf00df14401555d748.camel@redhat.com> References: <6a0001c4e3074f12833b5eaeb82df0fb@sap.com> <41593f1f7196b296ecdc96bf00df14401555d748.camel@redhat.com> Message-ID: Hi Severin, > Incidentally, I've been working on a more general guidance doc for JDK > backports. You can see it here: > http://cr.openjdk.java.net/~sgehwolf/upstream-backports-doc.txt > > Perhaps something like this should go to the updates wiki, but not sure > where. Any suggestions? Would this be useful? To me this looks quite helpful as a general guidance about how to tackle backports. You could add it as a separate page under https://wiki.openjdk.java.net/display/JDKUpdates Best regards Christoph From sgehwolf at redhat.com Thu Mar 7 14:35:14 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 07 Mar 2019 15:35:14 +0100 Subject: 11u: Fix request process & Where to push? In-Reply-To: References: <6a0001c4e3074f12833b5eaeb82df0fb@sap.com> <41593f1f7196b296ecdc96bf00df14401555d748.camel@redhat.com> Message-ID: On Thu, 2019-03-07 at 10:43 +0000, Langer, Christoph wrote: > Hi Severin, > > > Incidentally, I've been working on a more general guidance doc for JDK > > backports. You can see it here: > > http://cr.openjdk.java.net/~sgehwolf/upstream-backports-doc.txt > > > > Perhaps something like this should go to the updates wiki, but not sure > > where. Any suggestions? Would this be useful? > > To me this looks quite helpful as a general guidance about how to > tackle backports. You could add it as a separate page under > https://wiki.openjdk.java.net/display/JDKUpdates OK thanks. Here it is (those WYSIWYG editors are fighting me): https://wiki.openjdk.java.net/display/JDKUpdates/JDK+Updates+Guidance Thanks, Severin From christoph.langer at sap.com Thu Mar 7 15:33:26 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 7 Mar 2019 15:33:26 +0000 Subject: Confirmation about jdk11u approval process In-Reply-To: <5cbd9f1a-3ed0-a83d-948b-d1288343398c@redhat.com> References: <634770840670d2ee3a21f7c531da3b0b@linux.vnet.ibm.com> <2e7d6ad873235c18aaa3226bbc829556@linux.vnet.ibm.com> <76e25246-9c59-958f-e810-22e589394fb8@redhat.com> <709b444897ff7f16718ca52952e7e0cc@linux.vnet.ibm.com> <9deb06ddd428c2ac0918d74d0097ef83@linux.vnet.ibm.com> <508bb433-9980-0e1c-c52b-f889b7bc0648@redhat.com> <233528c2770b617d06f0df662a41b61a@linux.vnet.ibm.com> <88b81bd3-e18e-940e-b35f-c537b0aa4e40@redhat.com> <830e45786cc4401d8308ed01138dbe76@sap.com> <5cbd9f1a-3ed0-a83d-948b-d1288343398c@redhat.com> Message-ID: Hi, I pushed the bunch to jdk11u-dev. Best regards Christoph > -----Original Message----- > From: Aleksey Shipilev > Sent: Dienstag, 5. M?rz 2019 18:19 > To: Langer, Christoph ; Ichiroh Takiguchi > > Cc: jdk-updates-dev at openjdk.java.net > Subject: Re: Confirmation about jdk11u approval process > > On 3/5/19 7:55 AM, Langer, Christoph wrote: > >> While the whole bunch passes tier1 tests on my Linux x86_64, we better > confirm it does not > >> break AIX. It is unclear from the Fix Requests: have you tested these on > AIX? Or, should we ask > >> Christoph to do it? > >> > >> The changeset bunch is here: > >> http://cr.openjdk.java.net/~shade/backports-11u/ibm- > charsets/webrev.01/ > > > > We'll run it through our test queue. Maybe you'll have to bear with me for > a few days as we're currently setting up things for building/testing jdk11u- > dev (Before, we only had jdk11u). I'll let you know when it ran through and > has some valid results. > > No problem, this can wait a few days. Tell me when testing is done. > > -Aleksey > From hohensee at amazon.com Thu Mar 7 20:04:09 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 7 Mar 2019 20:04:09 +0000 Subject: openjdk8u212 and openjdk11.0.3 code freeze/rampdown dates Message-ID: We?re roughly 6 weeks from when 8u211/212 and 11.0.3 will ship. There are two 11.0.3 tags in jdk11u-dev, but no 8u212 tags in the jdk8u-dev. There are 9 backports left on the u211/212 list. One is out for review (JDK-8180904/8077608 by Xin), one is unassigned (JDK-8213983), and one looks to be taken by Aleksey (JDK-8217305). I?m willing to do the remaining 6: they?re all pretty small. Just need jdk8u-fix-yes tags. :) I haven?t seen code freeze dates for non-embargoed patches candidates, but may have missed them going by. If they aren?t yet determined, it?d be excellent to have them so we can plan rampdown. Thanks, Paul From hohensee at amazon.com Thu Mar 7 20:10:10 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 7 Mar 2019 20:10:10 +0000 Subject: openjdk8u212 and openjdk11.0.3 code freeze/rampdown dates In-Reply-To: References: Message-ID: <61B8D31A-696A-42B7-B1EF-A56318EB15E7@amazon.com> But the presence of 11.0.3 tags means I missed that 11.0.3 has already been forked for rampdown, correct? ?On 3/7/19, 12:04 PM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: We?re roughly 6 weeks from when 8u211/212 and 11.0.3 will ship. There are two 11.0.3 tags in jdk11u-dev, but no 8u212 tags in the jdk8u-dev. There are 9 backports left on the u211/212 list. One is out for review (JDK-8180904/8077608 by Xin), one is unassigned (JDK-8213983), and one looks to be taken by Aleksey (JDK-8217305). I?m willing to do the remaining 6: they?re all pretty small. Just need jdk8u-fix-yes tags. :) I haven?t seen code freeze dates for non-embargoed patches candidates, but may have missed them going by. If they aren?t yet determined, it?d be excellent to have them so we can plan rampdown. Thanks, Paul From ali.ince at gmail.com Thu Mar 7 22:24:49 2019 From: ali.ince at gmail.com (Ali Ince) Date: Thu, 7 Mar 2019 22:24:49 +0000 Subject: [12u] 8214122: JDWP is broken on 32 bit Windows: transport library missing onLoad entry Message-ID: <1943628C-F582-4CB4-931D-A352EC641E01@gmail.com> Hi All, I would like to request backport of this fix to 12u as it seems to be the only version that's not covered yet. Bug: https://bugs.openjdk.java.net/browse/JDK-8214122 Fix (Original): http://hg.openjdk.java.net/jdk/jdk/rev/9eee0b148002 The patch itself applies cleanly and I've verified locally that the fix resolves the issue. Best regards, Ali From christoph.langer at sap.com Thu Mar 7 23:05:26 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 7 Mar 2019 23:05:26 +0000 Subject: [12u] 8214122: JDWP is broken on 32 bit Windows: transport library missing onLoad entry In-Reply-To: <1943628C-F582-4CB4-931D-A352EC641E01@gmail.com> References: <1943628C-F582-4CB4-931D-A352EC641E01@gmail.com> Message-ID: Hi Ali, I've requested push approval for 12u. Will push once approval is there. Thanks Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Ali Ince > Sent: Donnerstag, 7. M?rz 2019 23:25 > To: jdk-updates-dev at openjdk.java.net > Subject: [12u] 8214122: JDWP is broken on 32 bit Windows: transport library > missing onLoad entry > > Hi All, > > I would like to request backport of this fix to 12u as it seems to be the only > version that's not covered yet. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214122 > Fix (Original): http://hg.openjdk.java.net/jdk/jdk/rev/9eee0b148002 > > The patch itself applies cleanly and I've verified locally that the fix resolves > the issue. > > Best regards, > > Ali From christoph.langer at sap.com Thu Mar 7 23:16:44 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 7 Mar 2019 23:16:44 +0000 Subject: openjdk8u212 and openjdk11.0.3 code freeze/rampdown dates In-Reply-To: <61B8D31A-696A-42B7-B1EF-A56318EB15E7@amazon.com> References: <61B8D31A-696A-42B7-B1EF-A56318EB15E7@amazon.com> Message-ID: Hi Paul, I've updated the Wiki https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u yesterday, adding some process description and timeline information. Didn't get feedback from Andrew so far. But I think I should add similar information to https://wiki.openjdk.java.net/display/jdk8u as well. > But the presence of 11.0.3 tags means I missed that 11.0.3 has already been > forked for rampdown, correct? Yes, 11.03 has been moved to the jdk11u repository for rampdown. jdk11u-dev is now the working repository for 11.0.4. > We?re roughly 6 weeks from when 8u211/212 and 11.0.3 will ship. There > are two 11.0.3 tags in jdk11u-dev, but no 8u212 tags in the jdk8u-dev. There > are 9 backports left on the u211/212 list. One is out for review (JDK- > 8180904/8077608 by Xin), one is unassigned (JDK-8213983), and one looks to > be taken by Aleksey (JDK-8217305). I?m willing to do the remaining 6: they?re > all pretty small. Just need jdk8u-fix-yes tags. :) > > I haven?t seen code freeze dates for non-embargoed patches candidates, > but may have missed them going by. If they aren?t yet determined, it?d be > excellent to have them so we can plan rampdown. It would be great if you can do the remaining 6 issues. As soon as the list of backports is empty, we shall do the rampdown. For 8u222 and following we can do this hopefully a bit earlier. Best regards Christoph From ali.ince at gmail.com Thu Mar 7 23:41:13 2019 From: ali.ince at gmail.com (Ali Ince) Date: Thu, 7 Mar 2019 23:41:13 +0000 Subject: [11u] 8210803: Compilation failure in codeBlob.cpp for Windows 32-bit Message-ID: Hi All, I have another backport request for this fix in order to get windows 32-bit jdk11u build on Visual Studio 2017. Bug: https://bugs.openjdk.java.net/browse/JDK-8210803 Fix: http://hg.openjdk.java.net/jdk/jdk/rev/43081c586d77 The patch itself applies cleanly and I?ve verified locally that it resolves the issue. Best regards, Ali From christoph.langer at sap.com Fri Mar 8 07:51:39 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 8 Mar 2019 07:51:39 +0000 Subject: [11u] 8210803: Compilation failure in codeBlob.cpp for Windows 32-bit In-Reply-To: References: Message-ID: Hi Ali, I've requested the backport in the bug on your behalf. You should really become an OpenJDK author to get a JBS user ID ?? Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Ali Ince > Sent: Freitag, 8. M?rz 2019 00:41 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] 8210803: Compilation failure in codeBlob.cpp for Windows 32- > bit > > Hi All, > > I have another backport request for this fix in order to get windows 32-bit > jdk11u build on Visual Studio 2017. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210803 > Fix: http://hg.openjdk.java.net/jdk/jdk/rev/43081c586d77 > > The patch itself applies cleanly and I?ve verified locally that it resolves the > issue. > > Best regards, > > Ali From mlists at juma.me.uk Fri Mar 8 09:29:24 2019 From: mlists at juma.me.uk (Ismael Juma) Date: Fri, 8 Mar 2019 01:29:24 -0800 Subject: Encryption fix in HotSpot In-Reply-To: References: Message-ID: Looks like this change introduced a regression, fix available: https://bugs.openjdk.java.net/browse/JDK-8220165 Ismael On Tue, Feb 26, 2019 at 5:56 AM Gidon Gershinsky wrote: > An AES-GCM encryption problem, causing a glacially slow startup, had been > recently fixed in Java 13. > https://hg.openjdk.java.net/jdk/jdk/rev/f35a8aaabcb9 > > The fix has also been backported to Java 12 and Oracle Java 11. > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8201633 > > Can it also be backported to OpenJDK Java 11? This is a very significant > performance problem, that needs to be fixed in order for AES-GCM (one of > the main encryption modes today) to be really workable in Java 11. > > > > Regards, > Gidon > > > > From aph at redhat.com Fri Mar 8 09:31:37 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 8 Mar 2019 09:31:37 +0000 Subject: [11u] 8210803: Compilation failure in codeBlob.cpp for Windows 32-bit In-Reply-To: References: Message-ID: <9eb60065-4d9d-191b-ab57-3354f3d2ecd6@redhat.com> On 3/8/19 7:51 AM, Langer, Christoph wrote: > I've requested the backport in the bug on your behalf. I don't see any labels. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Fri Mar 8 09:35:46 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 8 Mar 2019 10:35:46 +0100 Subject: Encryption fix in HotSpot In-Reply-To: References: Message-ID: On 3/8/19 10:29 AM, Ismael Juma wrote: > Looks like this change introduced a regression, fix available: > > https://bugs.openjdk.java.net/browse/JDK-8220165 (sighs) I'll handle it. -Aleksey From christoph.langer at sap.com Fri Mar 8 10:01:07 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 8 Mar 2019 10:01:07 +0000 Subject: [11u] 8210803: Compilation failure in codeBlob.cpp for Windows 32-bit In-Reply-To: <9eb60065-4d9d-191b-ab57-3354f3d2ecd6@redhat.com> References: <9eb60065-4d9d-191b-ab57-3354f3d2ecd6@redhat.com> Message-ID: > On 3/8/19 7:51 AM, Langer, Christoph wrote: > > I've requested the backport in the bug on your behalf. > > I don't see any labels. Sorry, I accidentally tagged JDK-8218031. Fixed. From sean.coffey at oracle.com Fri Mar 8 12:19:24 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 8 Mar 2019 12:19:24 +0000 Subject: Encryption fix in HotSpot In-Reply-To: References: Message-ID: I see you've already requested integration for JDK 12 Updates also. Thanks, Sean. On 08/03/19 09:35, Aleksey Shipilev wrote: > On 3/8/19 10:29 AM, Ismael Juma wrote: >> Looks like this change introduced a regression, fix available: >> >> https://bugs.openjdk.java.net/browse/JDK-8220165 > (sighs) I'll handle it. > > -Aleksey > From shade at redhat.com Fri Mar 8 13:02:53 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 8 Mar 2019 14:02:53 +0100 Subject: Encryption fix in HotSpot In-Reply-To: References: Message-ID: <25b145fc-8d11-1407-f696-1c5c81472c70@redhat.com> Yes, because failing backport got there too. It would be awkward to release broken 12u :) -Aleksey On 3/8/19 1:19 PM, Se?n Coffey wrote: > I see you've already requested integration for JDK 12 Updates also. > > Thanks, > Sean. > > On 08/03/19 09:35, Aleksey Shipilev wrote: >> On 3/8/19 10:29 AM, Ismael Juma wrote: >>> Looks like this change introduced a regression, fix available: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8220165 >> (sighs) I'll handle it. >> >> -Aleksey >> > From christoph.langer at sap.com Fri Mar 8 14:15:40 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 8 Mar 2019 14:15:40 +0000 Subject: [11u] 8210803: Compilation failure in codeBlob.cpp for Windows 32-bit In-Reply-To: References: Message-ID: Pushed to jdk11u-dev: http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/4fc61287d36e > -----Original Message----- > From: Langer, Christoph > Sent: Freitag, 8. M?rz 2019 08:52 > To: Ali Ince ; jdk-updates-dev at openjdk.java.net > Subject: RE: [11u] 8210803: Compilation failure in codeBlob.cpp for Windows > 32-bit > > Hi Ali, > > I've requested the backport in the bug on your behalf. You should really > become an OpenJDK author to get a JBS user ID ?? > > Best regards > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Ali Ince > > Sent: Freitag, 8. M?rz 2019 00:41 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [11u] 8210803: Compilation failure in codeBlob.cpp for Windows > 32- > > bit > > > > Hi All, > > > > I have another backport request for this fix in order to get windows 32-bit > > jdk11u build on Visual Studio 2017. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210803 > > Fix: http://hg.openjdk.java.net/jdk/jdk/rev/43081c586d77 > > > > The patch itself applies cleanly and I?ve verified locally that it resolves the > > issue. > > > > Best regards, > > > > Ali From christoph.langer at sap.com Fri Mar 8 14:39:45 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 8 Mar 2019 14:39:45 +0000 Subject: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux Message-ID: Hi, please review the CSR backport https://bugs.openjdk.java.net/browse/JDK-8220362. It is the backport of https://bugs.openjdk.java.net/browse/JDK-8214511 to JDK11. We want to backport JDK-8212828 to jdk11u and hence backporting the CSR is a prerequisite. The CSR is, however, more or less identical for 11u. Thank you and Best regards Christoph From martijnverburg at gmail.com Fri Mar 8 14:40:49 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Fri, 8 Mar 2019 14:40:49 +0000 Subject: [12u] 8214122: JDWP is broken on 32 bit Windows: transport library missing onLoad entry In-Reply-To: References: <1943628C-F582-4CB4-931D-A352EC641E01@gmail.com> Message-ID: Thanks - these are all issues that we are picking up at the Adopt build farm and we appreciate the backportibg on our behalf until we get more authors On Thu, 7 Mar 2019 at 23:06, Langer, Christoph wrote: > Hi Ali, > > I've requested push approval for 12u. Will push once approval is there. > > Thanks > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Ali Ince > > Sent: Donnerstag, 7. M?rz 2019 23:25 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [12u] 8214122: JDWP is broken on 32 bit Windows: transport > library > > missing onLoad entry > > > > Hi All, > > > > I would like to request backport of this fix to 12u as it seems to be > the only > > version that's not covered yet. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214122 > > Fix (Original): http://hg.openjdk.java.net/jdk/jdk/rev/9eee0b148002 > > > > The patch itself applies cleanly and I've verified locally that the fix > resolves > > the issue. > > > > Best regards, > > > > Ali > -- Cheers, Martijn (Sent from Gmail Mobile) From aph at redhat.com Fri Mar 8 15:20:42 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 8 Mar 2019 15:20:42 +0000 Subject: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux In-Reply-To: References: Message-ID: On 3/8/19 2:39 PM, Langer, Christoph wrote: > please review the CSR backport https://bugs.openjdk.java.net/browse/JDK-8220362. > > It is the backport of https://bugs.openjdk.java.net/browse/JDK-8214511 to JDK11. > > We want to backport JDK-8212828 to jdk11u and hence backporting the CSR is a prerequisite. The CSR is, however, more or less identical for 11u. I don't see any explanation of why this should go into jdk11. -- 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 Mar 11 04:36:44 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 11 Mar 2019 04:36:44 +0000 Subject: 8u/11u repo access and Jira changes In-Reply-To: References: <372f2232-1c3d-a358-17d7-28fa1d563995@redhat.com> <242e376c-0b96-1d87-dd51-e9d35844d021@redhat.com> <9d4c5d26-b02e-daac-0ba4-9780412451a5@redhat.com> <2f1b50ed-bb26-add1-bc64-012f6e5fc208@redhat.com> <3dd8687d-e9c6-4f1b-ec47-a8d9506894dd@redhat.com> <06f09798-cade-b882-fb3e-4049733fa8cc@redhat.com> <3f49543e8bd14cf5b3ed7381abaad339@sap.com> <90c57878b5254c6ca2d496a2a59b8eb8@sap.com> Message-ID: <4efa6e6f-ae3a-e912-615f-11bb743dd5ca@redhat.com> On 06/03/2019 22:00, Langer, Christoph wrote snip... > I also looked at the tags: There's no +0 tag in 8u (tag format looks a bit different there, anyway). So I suggest after jdk8u-dev was transported to jdk8u, it should be tagged jdk8u212-b1 in jdk8u. > > Best regards > Christoph > jdk8u212-b00 I'd say: $ cat ../upstream/jdk8/.hgtags |grep '\-b00'|tail|uniq ccac71a8778d18186967618df12bd2612d758f4b jdk8u162-b00 d66f57333c7fcc735f87eb0903ffdc0aaf899b32 jdk8u171-b00 f2d13f7195163a34af334e0613c953ddec40e115 jdk8u181-b00 e91f5717d8a5df396c8646da9b5a7bcd526bf288 jdk8u172-b00 f2d13f7195163a34af334e0613c953ddec40e115 jdk8u181-b00 dda7b81e20a3bb3ea6877d93dd6145381b52b6e4 jdk8u191-b00 d6007fa4ffae140f4c4ad551a1ee290a0704a094 jdk8u201-b00 3b5b53db61f2aaa5a94fd9ca51162d83565faabe jdk8u182-b00 dcfe85bcd9017741198b4e4a2045fdaaab212c74 jdk8u192-b00 6d8d269ee313fb1420375c2a81dd71c0b660a65f jdk8u202-b00 -- 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 Mar 11 08:15:25 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 11 Mar 2019 08:15:25 +0000 Subject: [11u] RFR 8202884: SA: Attach/detach might fail on Linux if debugee application create/destroy threads during attaching Message-ID: Hi, please review the backport of 8202884 to jdk11u-dev: Bug: https://bugs.openjdk.java.net/browse/JDK-8202884 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8202884.jdk11u-dev/ It applied cleanly, except from some header mismatch in src/jdk.hotspot.agent/linux/native/libsaproc/ps_proc.c. Thanks Christoph From shade at redhat.com Mon Mar 11 10:16:56 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 Mar 2019 11:16:56 +0100 Subject: [11u] RFR 8202884: SA: Attach/detach might fail on Linux if debugee application create/destroy threads during attaching In-Reply-To: References: Message-ID: <72e1e146-e8fc-8d85-8254-bad8c9f6e072@redhat.com> On 3/11/19 9:15 AM, Langer, Christoph wrote: > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8202884.jdk11u-dev/ Backport patch looks good. -Aleksey From shade at redhat.com Mon Mar 11 10:34:36 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 Mar 2019 11:34:36 +0100 Subject: [11u] RFR 8217765: Internal Error (javaCalls.cpp:61) guarantee(thread->can_call_java()) failed Message-ID: <2a65dd09-f829-dfca-e04c-c3a9451452c4@redhat.com> Please review the backport to 11u. It was backported to 12u and 11u-oracle. Original bug: https://bugs.openjdk.java.net/browse/JDK-8217765 Original fix: http://hg.openjdk.java.net/jdk/jdk/rev/81a9748bc86c 12u backport: http://hg.openjdk.java.net/jdk-updates/jdk12u/rev/604112e45466 11u backport (in this review): http://cr.openjdk.java.net/~shade/8217765/webrev.11u.01/ Testing: hotspot tier1 Thanks, -Aleksey From goetz.lindenmaier at sap.com Mon Mar 11 10:37:09 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 11 Mar 2019 10:37:09 +0000 Subject: [11u] RFR 8202884: SA: Attach/detach might fail on Linux if debugee application create/destroy threads during attaching In-Reply-To: References: Message-ID: Hi, The conflicts were resolved nicely, looks good :) Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Langer, Christoph > Sent: Montag, 11. M?rz 2019 09:15 > To: jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] [11u] RFR 8202884: SA: Attach/detach might fail on Linux > if debugee application create/destroy threads during attaching > > Hi, > > please review the backport of 8202884 to jdk11u-dev: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202884 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8202884.jdk11u-dev/ > > It applied cleanly, except from some header mismatch in > src/jdk.hotspot.agent/linux/native/libsaproc/ps_proc.c. > > Thanks > Christoph From goetz.lindenmaier at sap.com Mon Mar 11 10:44:22 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 11 Mar 2019 10:44:22 +0000 Subject: [11u] RFR 8217765: Internal Error (javaCalls.cpp:61) guarantee(thread->can_call_java()) failed In-Reply-To: <2a65dd09-f829-dfca-e04c-c3a9451452c4@redhat.com> References: <2a65dd09-f829-dfca-e04c-c3a9451452c4@redhat.com> Message-ID: Hi Aleksey, this looks good. .. but why do you need a review? Best regards Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Aleksey Shipilev > Sent: Montag, 11. M?rz 2019 11:35 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR 8217765: Internal Error (javaCalls.cpp:61) > guarantee(thread->can_call_java()) failed > > Please review the backport to 11u. It was backported to 12u and 11u-oracle. > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8217765 > > Original fix: > http://hg.openjdk.java.net/jdk/jdk/rev/81a9748bc86c > > 12u backport: > http://hg.openjdk.java.net/jdk-updates/jdk12u/rev/604112e45466 > > 11u backport (in this review): > http://cr.openjdk.java.net/~shade/8217765/webrev.11u.01/ > > Testing: hotspot tier1 > > Thanks, > -Aleksey From shade at redhat.com Mon Mar 11 10:46:47 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 Mar 2019 11:46:47 +0100 Subject: [11u] RFR 8217765: Internal Error (javaCalls.cpp:61) guarantee(thread->can_call_java()) failed In-Reply-To: References: <2a65dd09-f829-dfca-e04c-c3a9451452c4@redhat.com> Message-ID: <03d2b19a-990a-412b-eb59-5a24ae2fc7b9@redhat.com> On 3/11/19 11:44 AM, Lindenmaier, Goetz wrote: > this looks good. > > .. but why do you need a review? Sorry, forgot to mention it. The patch does not apply cleanly, because surrounding code is a bit different. I need review to check that I put the hunks in correct places. -Aleksey From goetz.lindenmaier at sap.com Mon Mar 11 10:54:25 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 11 Mar 2019 10:54:25 +0000 Subject: [11u] RFR 8217765: Internal Error (javaCalls.cpp:61) guarantee(thread->can_call_java()) failed In-Reply-To: <03d2b19a-990a-412b-eb59-5a24ae2fc7b9@redhat.com> References: <2a65dd09-f829-dfca-e04c-c3a9451452c4@redhat.com> <03d2b19a-990a-412b-eb59-5a24ae2fc7b9@redhat.com> Message-ID: Ah, thanks ... I could not spot the differences. Best regards, Goetz. > -----Original Message----- > From: Aleksey Shipilev > Sent: Montag, 11. M?rz 2019 11:47 > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: Re: [11u] RFR 8217765: Internal Error (javaCalls.cpp:61) > guarantee(thread->can_call_java()) failed > > On 3/11/19 11:44 AM, Lindenmaier, Goetz wrote: > > this looks good. > > > > .. but why do you need a review? > > Sorry, forgot to mention it. The patch does not apply cleanly, because > surrounding code is a bit > different. I need review to check that I put the hunks in correct places. > > -Aleksey From david.holmes at oracle.com Mon Mar 11 11:53:30 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 11 Mar 2019 21:53:30 +1000 Subject: [11u] RFR 8217765: Internal Error (javaCalls.cpp:61) guarantee(thread->can_call_java()) failed In-Reply-To: <2a65dd09-f829-dfca-e04c-c3a9451452c4@redhat.com> References: <2a65dd09-f829-dfca-e04c-c3a9451452c4@redhat.com> Message-ID: <150dc42f-ec01-f4aa-32c6-5c1aecf17bc6@oracle.com> On 11/03/2019 8:34 pm, Aleksey Shipilev wrote: > Please review the backport to 11u. It was backported to 12u and 11u-oracle. Looks good. Cheers, David ----- > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8217765 > > Original fix: > http://hg.openjdk.java.net/jdk/jdk/rev/81a9748bc86c > > 12u backport: > http://hg.openjdk.java.net/jdk-updates/jdk12u/rev/604112e45466 > > 11u backport (in this review): > http://cr.openjdk.java.net/~shade/8217765/webrev.11u.01/ > > Testing: hotspot tier1 > > Thanks, > -Aleksey > From david.lloyd at redhat.com Mon Mar 11 13:09:45 2019 From: david.lloyd at redhat.com (David Lloyd) Date: Mon, 11 Mar 2019 08:09:45 -0500 Subject: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux In-Reply-To: References: Message-ID: Is vfork still guaranteed to be functional by the end of the Java 11 support frame, from the perspective of any organization which supports JDKs of this version? On Fri, Mar 8, 2019 at 9:22 AM Andrew Haley wrote: > > On 3/8/19 2:39 PM, Langer, Christoph wrote: > > please review the CSR backport https://bugs.openjdk.java.net/browse/JDK-8220362. > > > > It is the backport of https://bugs.openjdk.java.net/browse/JDK-8214511 to JDK11. > > > > We want to backport JDK-8212828 to jdk11u and hence backporting the CSR is a prerequisite. The CSR is, however, more or less identical for 11u. > > I don't see any explanation of why this should go into jdk11. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 -- - DML From christoph.langer at sap.com Mon Mar 11 15:38:57 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 11 Mar 2019 15:38:57 +0000 Subject: [11u] RFR 8202884: SA: Attach/detach might fail on Linux if debugee application create/destroy threads during attaching In-Reply-To: References: Message-ID: Thanks Aleksey and Goetz for the reviews. Pushed it. > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Montag, 11. M?rz 2019 11:37 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR 8202884: SA: Attach/detach might fail on Linux if > debugee application create/destroy threads during attaching > > Hi, > > The conflicts were resolved nicely, looks good :) > > Best regards, > Goetz. > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Langer, Christoph > > Sent: Montag, 11. M?rz 2019 09:15 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [CAUTION] [11u] RFR 8202884: SA: Attach/detach might fail on > Linux > > if debugee application create/destroy threads during attaching > > > > Hi, > > > > please review the backport of 8202884 to jdk11u-dev: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202884 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8202884.jdk11u- > dev/ > > > > It applied cleanly, except from some header mismatch in > > src/jdk.hotspot.agent/linux/native/libsaproc/ps_proc.c. > > > > Thanks > > Christoph From sgehwolf at redhat.com Mon Mar 11 16:11:18 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 11 Mar 2019 17:11:18 +0100 Subject: [11u] Heads-up: JDK-8220283 going into 11.0.3 Message-ID: <18f0cc99ba5f8aea7c89825bfc71706566a35373.camel@redhat.com> Hi, I'm going to push JDK-8220283[1] to jdk-updates/jdk11u (upcoming 11.0.3). This is a heads-up should you notice any issues. Thanks, Severin [1] https://bugs.openjdk.java.net/browse/JDK-8220283 From nick.gasson at arm.com Tue Mar 12 06:06:29 2019 From: nick.gasson at arm.com (Nick Gasson) Date: Tue, 12 Mar 2019 14:06:29 +0800 Subject: RFR: [11u] 8216350: AArch64: monitor unlock fast path not called Message-ID: <94e43d92-1d33-de76-24cf-64831a48b6c0@arm.com> Hi, Please review this backport of the fix for 8216350 to 11u: Original bug: https://bugs.openjdk.java.net/browse/JDK-8216350 Webrev: http://cr.openjdk.java.net/~ngasson/8216350/webrev.11u.0/ Justification is that it improves performance in non-micro benchmarks (SPECjbb). The original patch has been modified slightly so it applies cleanly on 11u. Most of the conflicts were from checking the EmitSync flag in 11 which has been removed in 12/13. I've also removed the change to the micro benchmark as these files are not in 11u. Testing: jtreg, jcstress (*), and ran the micro benchmark to check the performance regression is fixed. * Note that some jcstress tests are failing on 11u (with and without this patch). You can reproduce this easily by running jcstress with "-t varHandles.*GetAndSetTest". This was fixed in 12/13 by: 8211320: Aarch64: unsafe.compareAndSetByte() and unsafe.compareAndSetShort() c2 intrinsics broken with negative expected value I suggest we also backport the above to 11u? Thanks, Nick From aph at redhat.com Tue Mar 12 08:36:50 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 12 Mar 2019 08:36:50 +0000 Subject: [aarch64-port-dev ] RFR: [11u] 8216350: AArch64: monitor unlock fast path not called In-Reply-To: <94e43d92-1d33-de76-24cf-64831a48b6c0@arm.com> References: <94e43d92-1d33-de76-24cf-64831a48b6c0@arm.com> Message-ID: <5fa7634c-4de7-1f0b-6730-e849293c90e3@redhat.com> On 3/12/19 6:06 AM, Nick Gasson wrote: > Original bug: https://bugs.openjdk.java.net/browse/JDK-8216350 > Webrev: http://cr.openjdk.java.net/~ngasson/8216350/webrev.11u.0/ > > Justification is that it improves performance in non-micro benchmarks > (SPECjbb). Looks good. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Mar 12 08:43:23 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 12 Mar 2019 08:43:23 +0000 Subject: [aarch64-port-dev ] RFR: [11u] 8216350: AArch64: monitor unlock fast path not called In-Reply-To: <94e43d92-1d33-de76-24cf-64831a48b6c0@arm.com> References: <94e43d92-1d33-de76-24cf-64831a48b6c0@arm.com> Message-ID: <7e74d72f-bff6-f239-89e7-cf7e09adfffc@redhat.com> On 3/12/19 6:06 AM, Nick Gasson wrote: > Hi, > > Please review this backport of the fix for 8216350 to 11u: > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8216350 > Webrev: http://cr.openjdk.java.net/~ngasson/8216350/webrev.11u.0/ > > Justification is that it improves performance in non-micro benchmarks > (SPECjbb). > > The original patch has been modified slightly so it applies cleanly on > 11u. Most of the conflicts were from checking the EmitSync flag in 11 > which has been removed in 12/13. I've also removed the change to the > micro benchmark as these files are not in 11u. > > Testing: jtreg, jcstress (*), and ran the micro benchmark to check the > performance regression is fixed. OK. > * Note that some jcstress tests are failing on 11u (with and without > this patch). You can reproduce this easily by running jcstress with "-t > varHandles.*GetAndSetTest". This was fixed in 12/13 by: > > 8211320: Aarch64: unsafe.compareAndSetByte() and > unsafe.compareAndSetShort() c2 intrinsics broken with negative expected > value > > I suggest we also backport the above to 11u? Yes, thanks. -- 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 Mar 12 10:25:47 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 12 Mar 2019 10:25:47 +0000 Subject: [8u, 11u] Wiki Page updates Message-ID: Hi, I have updated the Wiki Pages for both, jdk11u and jdk8u so that they look consistent. JDK8u: https://wiki.openjdk.java.net/display/jdk8u JDK11u: https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u I have written some sentences about processes and infrastructure, covering also the push approval process. Furthermore, I've added the upcoming release dates and links to the JBS filters. Please review this documentation, whether it's correct in content and also whether it's understandable. Thanks in advance for any feedback. Best regards Christoph From martijnverburg at gmail.com Tue Mar 12 11:11:40 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Tue, 12 Mar 2019 11:11:40 +0000 Subject: [8u, 11u] Wiki Page updates In-Reply-To: References: Message-ID: Thank you! On Tue, 12 Mar 2019 at 10:26, Langer, Christoph wrote: > Hi, > > I have updated the Wiki Pages for both, jdk11u and jdk8u so that they look > consistent. > > JDK8u: https://wiki.openjdk.java.net/display/jdk8u > JDK11u: https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u > > I have written some sentences about processes and infrastructure, covering > also the push approval process. Furthermore, I've added the upcoming > release dates and links to the JBS filters. > > Please review this documentation, whether it's correct in content and also > whether it's understandable. Thanks in advance for any feedback. > > Best regards > Christoph > > -- Cheers, Martijn (Sent from Gmail Mobile) From shade at redhat.com Tue Mar 12 17:01:56 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 12 Mar 2019 18:01:56 +0100 Subject: [12u] RFR (S) 8220350: Refactor ShenandoahHeap::initialize Message-ID: Hi, Please review the backport for Shenandoah change that allows to unblock follow-up functionality fixes. Original RFE: https://bugs.openjdk.java.net/browse/JDK-8220350 Original change: http://cr.openjdk.java.net/~shade/8220350/webrev.02/ Patch does not apply cleanly, because there are minor changes in SATBQueue interface and whitespace difference. 12u change: http://cr.openjdk.java.net/~shade/8220350/webrev.12u.02/ Testing: hotspot_gc_shenandoah, eyeballing the differences against original change -Aleksey From rkennke at redhat.com Tue Mar 12 17:19:31 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 12 Mar 2019 18:19:31 +0100 Subject: [12u] RFR (S) 8220350: Refactor ShenandoahHeap::initialize In-Reply-To: References: Message-ID: <574a1ff1-7d2c-a728-2f36-352b13ac185d@redhat.com> > Please review the backport for Shenandoah change that allows to unblock follow-up functionality fixes. > > Original RFE: > https://bugs.openjdk.java.net/browse/JDK-8220350 > > Original change: > http://cr.openjdk.java.net/~shade/8220350/webrev.02/ > > Patch does not apply cleanly, because there are minor changes in SATBQueue interface and whitespace > difference. 12u change: > http://cr.openjdk.java.net/~shade/8220350/webrev.12u.02/ > > Testing: hotspot_gc_shenandoah, eyeballing the differences against original change Looks good to me! Thanks! Roman From christoph.langer at sap.com Wed Mar 13 07:58:47 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 13 Mar 2019 07:58:47 +0000 Subject: [8u, 11u] Wiki Page updates In-Reply-To: <3016c55d-61d7-b64c-fba9-a6a2a8fe743f@redhat.com> References: <3016c55d-61d7-b64c-fba9-a6a2a8fe743f@redhat.com> Message-ID: Hi Andrew, > As I said yesterday [0], I think we need a label for fixes that are in > 8u-dev but are candidates for the current 8u after the initial > integration. Leaving this to bug comments makes them hard for us to find. > > I suggest 8u-CPU-critical-request and 11u-CPU-critical-request as > previously used [1]. I think it sounds reasonable. We can use jdk8u-critical-request and jdk11u-critical-request, since we are not planning to ship CPUs in OpenJDK. This will avoid namespace collisions with Oracle. I also think this should not only apply for changes that are already in jdk8u-dev/jdk11u-dev and shall be brought to jdk8u/jdk11u but also for direct pushes into jdk8u/jdk11u. What do other people think, especially aph? If we agree on it, I'll update this part in the wiki and we can start living up to it. > Some other minor issues; I'd prefer we referred to the security work as > taking place in a secure environment with internal testing. The word > "closed" has associations with "closed source". Also, it's "Red Hat" > with a space, not "RedHat". Yep, that sounds better. I fixed it ?? > > [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019- > March/008870.html > [1] > https://wiki.openjdk.java.net/display/jdk8u/Proposing+critical+8u+fixes+for > +CPU+releases Best regards Christoph From nick.gasson at arm.com Wed Mar 13 09:18:19 2019 From: nick.gasson at arm.com (Nick Gasson) Date: Wed, 13 Mar 2019 17:18:19 +0800 Subject: [aarch64-port-dev ] RFR: [11u] 8216350: AArch64: monitor unlock fast path not called In-Reply-To: <7e74d72f-bff6-f239-89e7-cf7e09adfffc@redhat.com> References: <94e43d92-1d33-de76-24cf-64831a48b6c0@arm.com> <7e74d72f-bff6-f239-89e7-cf7e09adfffc@redhat.com> Message-ID: Thanks Andrew. Is anyone able to sponsor this patch for me? Nick On 12/03/2019 16:43, Andrew Haley wrote: > On 3/12/19 6:06 AM, Nick Gasson wrote: >> Hi, >> >> Please review this backport of the fix for 8216350 to 11u: >> >> Original bug: https://bugs.openjdk.java.net/browse/JDK-8216350 >> Webrev: http://cr.openjdk.java.net/~ngasson/8216350/webrev.11u.0/ >> >> Justification is that it improves performance in non-micro benchmarks >> (SPECjbb). >> >> The original patch has been modified slightly so it applies cleanly on >> 11u. Most of the conflicts were from checking the EmitSync flag in 11 >> which has been removed in 12/13. I've also removed the change to the >> micro benchmark as these files are not in 11u. >> >> Testing: jtreg, jcstress (*), and ran the micro benchmark to check the >> performance regression is fixed. > > OK. > >> * Note that some jcstress tests are failing on 11u (with and without >> this patch). You can reproduce this easily by running jcstress with "-t >> varHandles.*GetAndSetTest". This was fixed in 12/13 by: >> >> 8211320: Aarch64: unsafe.compareAndSetByte() and >> unsafe.compareAndSetShort() c2 intrinsics broken with negative expected >> value >> >> I suggest we also backport the above to 11u? > > Yes, thanks. > From shade at redhat.com Wed Mar 13 10:12:09 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 13 Mar 2019 11:12:09 +0100 Subject: [11u] RFR 8217094: HttpClient SSL race if a socket IOException is raised before ALPN is available Message-ID: Hi, Please review the 11u backport. Original bug: https://bugs.openjdk.java.net/browse/JDK-8217094 Original fix: http://hg.openjdk.java.net/jdk/jdk/rev/a47b8125b7cc The patch applies cleanly, but the test cannot compile due to testlibrary changes. 11u webrev: http://cr.openjdk.java.net/~shade/8217094/webrev.11u.01/ It differs from the original version by this: diff -r 0eca35f9f944 test/jdk/java/net/httpclient/ALPNProxyFailureTest.java --- a/test/jdk/java/net/httpclient/ALPNProxyFailureTest.java Wed Jan 16 19:09:16 2019 +0000 +++ b/test/jdk/java/net/httpclient/ALPNProxyFailureTest.java Wed Mar 13 11:10:47 2019 +0100 @@ -28,6 +28,6 @@ * during the handshake. * @bug 8217094 - * @library /test/lib http2/server - * @build jdk.test.lib.net.SimpleSSLContext HttpServerAdapters DigestEchoServer + * @library /lib/testlibrary http2/server + * @build jdk.testlibrary.SimpleSSLContext HttpServerAdapters DigestEchoServer * ALPNFailureTest ALPNProxyFailureTest * @modules java.net.http/jdk.internal.net.http.common @@ -44,5 +44,5 @@ import javax.net.ServerSocketFactory; import javax.net.ssl.SSLContext; -import jdk.test.lib.net.SimpleSSLContext; +import jdk.testlibrary.SimpleSSLContext; import java.net.InetAddress; import java.net.ProxySelector; Testing: jdk/java/net/httpclient tests, which includes two new regression tests Thanks, -Aleksey From daniel.fuchs at oracle.com Wed Mar 13 10:26:35 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 13 Mar 2019 10:26:35 +0000 Subject: [11u] RFR 8217094: HttpClient SSL race if a socket IOException is raised before ALPN is available In-Reply-To: References: Message-ID: <731bf4a9-1ef8-3919-6c9b-fff645293f0c@oracle.com> Looks good to me Aleksey. best regards, -- daniel On 13/03/2019 10:12, Aleksey Shipilev wrote: > Hi, > > Please review the 11u backport. > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8217094 > > Original fix: > http://hg.openjdk.java.net/jdk/jdk/rev/a47b8125b7cc > > The patch applies cleanly, but the test cannot compile due to testlibrary changes. > > 11u webrev: > http://cr.openjdk.java.net/~shade/8217094/webrev.11u.01/ > > It differs from the original version by this: > > diff -r 0eca35f9f944 test/jdk/java/net/httpclient/ALPNProxyFailureTest.java > --- a/test/jdk/java/net/httpclient/ALPNProxyFailureTest.java Wed Jan 16 19:09:16 2019 +0000 > +++ b/test/jdk/java/net/httpclient/ALPNProxyFailureTest.java Wed Mar 13 11:10:47 2019 +0100 > @@ -28,6 +28,6 @@ > * during the handshake. > * @bug 8217094 > - * @library /test/lib http2/server > - * @build jdk.test.lib.net.SimpleSSLContext HttpServerAdapters DigestEchoServer > + * @library /lib/testlibrary http2/server > + * @build jdk.testlibrary.SimpleSSLContext HttpServerAdapters DigestEchoServer > * ALPNFailureTest ALPNProxyFailureTest > * @modules java.net.http/jdk.internal.net.http.common > @@ -44,5 +44,5 @@ > import javax.net.ServerSocketFactory; > import javax.net.ssl.SSLContext; > -import jdk.test.lib.net.SimpleSSLContext; > +import jdk.testlibrary.SimpleSSLContext; > import java.net.InetAddress; > import java.net.ProxySelector; > > Testing: jdk/java/net/httpclient tests, which includes two new regression tests > > Thanks, > -Aleksey > From gnu.andrew at redhat.com Wed Mar 13 15:55:37 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 13 Mar 2019 15:55:37 +0000 Subject: [8u, 11u] Wiki Page updates In-Reply-To: References: <3016c55d-61d7-b64c-fba9-a6a2a8fe743f@redhat.com> Message-ID: <22437ea4-8b2d-0791-a6c4-42e54a613833@redhat.com> On 13/03/2019 07:58, Langer, Christoph wrote: > Hi Andrew, > >> As I said yesterday [0], I think we need a label for fixes that are in >> 8u-dev but are candidates for the current 8u after the initial >> integration. Leaving this to bug comments makes them hard for us to find. >> >> I suggest 8u-CPU-critical-request and 11u-CPU-critical-request as >> previously used [1]. > > I think it sounds reasonable. We can use jdk8u-critical-request and jdk11u-critical-request, since we are not planning to ship CPUs in OpenJDK. This will avoid namespace collisions with Oracle. > > I also think this should not only apply for changes that are already in jdk8u-dev/jdk11u-dev and shall be brought to jdk8u/jdk11u but also for direct pushes into jdk8u/jdk11u. > > What do other people think, especially aph? If we agree on it, I'll update this part in the wiki and we can start living up to it. > That sounds fine to me. Presumably, these would be paired with jdk8u-critical-approved and jdk11u-critical-approved. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Thu Mar 14 09:10:03 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 14 Mar 2019 10:10:03 +0100 Subject: [aarch64-port-dev ] RFR: [11u] 8216350: AArch64: monitor unlock fast path not called In-Reply-To: References: <94e43d92-1d33-de76-24cf-64831a48b6c0@arm.com> <7e74d72f-bff6-f239-89e7-cf7e09adfffc@redhat.com> Message-ID: On 3/13/19 10:18 AM, Nick Gasson wrote: > Thanks Andrew. Is anyone able to sponsor this patch for me? I can sponsor this for you. I imagine you need a sponsor for this one too? https://bugs.openjdk.java.net/browse/JDK-8215951 -Aleksey From nick.gasson at arm.com Thu Mar 14 09:12:51 2019 From: nick.gasson at arm.com (Nick Gasson) Date: Thu, 14 Mar 2019 17:12:51 +0800 Subject: [aarch64-port-dev ] RFR: [11u] 8216350: AArch64: monitor unlock fast path not called In-Reply-To: References: <94e43d92-1d33-de76-24cf-64831a48b6c0@arm.com> <7e74d72f-bff6-f239-89e7-cf7e09adfffc@redhat.com> Message-ID: <5cf3922f-4fa7-6577-639a-da871d29332d@arm.com> On 14/03/2019 17:10, Aleksey Shipilev wrote: > On 3/13/19 10:18 AM, Nick Gasson wrote: >> Thanks Andrew. Is anyone able to sponsor this patch for me? > > I can sponsor this for you. Thanks Aleksey! > > I imagine you need a sponsor for this one too? > https://bugs.openjdk.java.net/browse/JDK-8215951 > Yes please :-) Nick From goetz.lindenmaier at sap.com Thu Mar 14 09:28:25 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 14 Mar 2019 09:28:25 +0000 Subject: openjdk8u212 and openjdk11.0.3 code freeze/rampdown dates In-Reply-To: References: Message-ID: Hi Paul, > There are two 11.0.3 tags in jdk11u-dev, Please note that it is jdk11u that is tagged, the changes are thereafter merged to jdk11u-dev, so the tags happen to show up there, too. jdk11u-dev contains changes targeted to 11.0.4. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Hohensee, Paul > Sent: Donnerstag, 7. M?rz 2019 21:04 > To: jdk8u-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net > Subject: [DMARC FAILURE] openjdk8u212 and openjdk11.0.3 code > freeze/rampdown dates > > We?re roughly 6 weeks from when 8u211/212 and 11.0.3 will ship. There are > two 11.0.3 tags in jdk11u-dev, but no 8u212 tags in the jdk8u-dev. There are 9 > backports left on the u211/212 list. One is out for review (JDK- > 8180904/8077608 by Xin), one is unassigned (JDK-8213983), and one looks to > be taken by Aleksey (JDK-8217305). I?m willing to do the remaining 6: they?re > all pretty small. Just need jdk8u-fix-yes tags. :) > > I haven?t seen code freeze dates for non-embargoed patches candidates, but > may have missed them going by. If they aren?t yet determined, it?d be excellent > to have them so we can plan rampdown. > > Thanks, > > Paul From shade at redhat.com Thu Mar 14 10:31:44 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 14 Mar 2019 11:31:44 +0100 Subject: AArch64: 8216350 and 8215951 Message-ID: <5fefc972-210f-ce06-0d53-7a8f756ea907@redhat.com> Hey Andrew, I remember you we talking about important fixes for AArch64. I see two approved backports: 8216350: AArch64: monitor unlock fast path not called 8215951: AArch64: jtreg test vmTestbase/nsk/jvmti/PopFrame/popframe005 segfaults Are these the issues you were talking about? If so, can/should I push these to jdk11u (11.0.3)? -Aleksey From aph at redhat.com Thu Mar 14 11:27:53 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Mar 2019 11:27:53 +0000 Subject: AArch64: 8216350 and 8215951 In-Reply-To: <5fefc972-210f-ce06-0d53-7a8f756ea907@redhat.com> References: <5fefc972-210f-ce06-0d53-7a8f756ea907@redhat.com> Message-ID: On 3/14/19 10:31 AM, Aleksey Shipilev wrote: > Hey Andrew, > > I remember you we talking about important fixes for AArch64. > > I see two approved backports: > 8216350: AArch64: monitor unlock fast path not called > 8215951: AArch64: jtreg test vmTestbase/nsk/jvmti/PopFrame/popframe005 segfaults > > Are these the issues you were talking about? If so, can/should I push these to jdk11u (11.0.3)? Yes, these are fine. The most important one, though, is JDK-8211320: AArch64: unsafe.compareAndSetByte() and unsafe.compareAndSetShort() c2 intrinsics broken with negative expected value -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Thu Mar 14 11:30:00 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Mar 2019 11:30:00 +0000 Subject: AArch64: 8216350 and 8215951 In-Reply-To: References: <5fefc972-210f-ce06-0d53-7a8f756ea907@redhat.com> Message-ID: On 3/14/19 11:27 AM, Andrew Haley wrote: > Yes, these are fine. The most important one, though, is > > JDK-8211320: AArch64: unsafe.compareAndSetByte() and unsafe.compareAndSetShort() c2 intrinsics broken with negative expected value Would it help if I tested the patch for 11u? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Thu Mar 14 11:30:56 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 14 Mar 2019 12:30:56 +0100 Subject: AArch64: 8216350 and 8215951 In-Reply-To: References: <5fefc972-210f-ce06-0d53-7a8f756ea907@redhat.com> Message-ID: On 3/14/19 12:27 PM, Andrew Haley wrote: > On 3/14/19 10:31 AM, Aleksey Shipilev wrote: >> I see two approved backports: >> 8216350: AArch64: monitor unlock fast path not called >> 8215951: AArch64: jtreg test vmTestbase/nsk/jvmti/PopFrame/popframe005 segfaults >> >> Are these the issues you were talking about? If so, can/should I push these to jdk11u (11.0.3)? > > Yes, these are fine. The most important one, though, is > > JDK-8211320: AArch64: unsafe.compareAndSetByte() and unsafe.compareAndSetShort() c2 intrinsics broken with negative expected value Okay, I can push all three (8211320, 8216350, 8215951) to jdk11u (11.0.3). Confirm? -Aleksey From shade at redhat.com Thu Mar 14 11:32:39 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 14 Mar 2019 12:32:39 +0100 Subject: AArch64: 8216350 and 8215951 In-Reply-To: References: <5fefc972-210f-ce06-0d53-7a8f756ea907@redhat.com> Message-ID: <4cd4f73b-554e-b1ea-9401-bf73711010f1@redhat.com> On 3/14/19 12:30 PM, Andrew Haley wrote: > On 3/14/19 11:27 AM, Andrew Haley wrote: >> Yes, these are fine. The most important one, though, is >> >> JDK-8211320: AArch64: unsafe.compareAndSetByte() and unsafe.compareAndSetShort() c2 intrinsics broken with negative expected value > > Would it help if I tested the patch for 11u? Please do. I can build and run it on Raspi 3, but that machine is too slow to run tests. -Aleksey From shade at redhat.com Thu Mar 14 13:05:20 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 14 Mar 2019 14:05:20 +0100 Subject: [8u, 11u] Wiki Page updates In-Reply-To: References: Message-ID: <72570676-d5df-d003-2364-f693a7be6be5@redhat.com> On 3/12/19 11:25 AM, Langer, Christoph wrote: > JDK11u: > https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u It is a good start, but I feel it does not help the outsiders, who would be as puzzled after reading that page. Concrete suggestions: *) Let's spell out: "Current status: jdk-updates/jdk11u-dev repository collects non-critical update fixes, targeted to 11.0.4. jdk-updates/jdk11u repository is stabilizing for 11.0.3 release" *) We need a verbose "How Do I" section, for example ------ 8< ----------------------------------------------------------------------- How Do I... ...Suggest the Change Normally, requesters are expected to do the bulk of the backporting work. If do not have time and resources to do the work, you have to find someone who would. You can ask around the original authors of the change and/or current (co-)maintainers in the update release. ...Request the Backport Backports are the issues that exist in later JDK versions and need to be applied to lower ones as well. 1. Pick the existing issue from the JBS - Take careful note of the linked issues that need to be brought with the fix, especially the follow-up fixes; - If there are relevant issues that prevent clean backport, consider backporting those first (within reason) 2. Check out the jdk-updates/jdk11u-dev, and try to apply the patch there - Make sure to keep the changeset metadata: original authors, Reviewed-by: lines, etc 3. If patch does not apply cleanly, you have to start the RFR thread at jdk-updates-dev@ - Need to state what changes were needed and why - Optionally, seek the review from the original authors 4. Test the patch - "tier1" tests should be passing at all times - Look at what area the patch affects, and run the tests from there - New regression tests that come with the patch should pass - Optionally, new regression tests may need to be verified to fail without the patch 5. Once everything is done, put jdk11u-fix-request tag and the "Fix Request" comment on the issue - Fix Request should explain why the fix should be backported, what testing was done, and the risk estimate 6. Wait for maintainer approval, which would manifest as jdk11u-fix-yes tag on the issue 7. Push the change - You might need a sponsor in jdk-updates project, ask at jdk-updates-dev@ list 8. Wait around to resolve any problems that might arise from the push ...Request the Change (without Backport) There are cases when the lower JDK release needs to have the patch that is not required for the higher JDK releases. The same rule set applies, as for backports, with mandatory RFR at jdk-updates-dev list. ...Keep the Changeset Metadata The easiest way to keep metadata is to import the full changeset from Mercurial. ...Test the Change ...Submit the RFR (Request For Review) ------ 8< ----------------------------------------------------------------------- -Aleksey From christoph.langer at sap.com Thu Mar 14 13:22:55 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 14 Mar 2019 13:22:55 +0000 Subject: [8u, 11u] Wiki Page updates In-Reply-To: <72570676-d5df-d003-2364-f693a7be6be5@redhat.com> References: <72570676-d5df-d003-2364-f693a7be6be5@redhat.com> Message-ID: Hi Aleksey, > It is a good start, but I feel it does not help the outsiders, who would be as > puzzled after reading that page. yeah, I tend to agree... > Concrete suggestions: > > *) Let's spell out: > "Current status: > jdk-updates/jdk11u-dev repository collects non-critical update fixes, > targeted to 11.0.4. > jdk-updates/jdk11u repository is stabilizing for 11.0.3 release" > Good idea. I'll add that section. With that section it is important, though, that we keep it up to date. Maybe I shall also create a "release engineers recipe/to do list" for things to do during a release cycle, e.g. bump version numbers, set initial tags, branches etc. Probably worth another Wiki page. I'll look into that, too. > *) We need a verbose "How Do I" section, for example > > ------ 8< ----------------------------------------------------------------------- > How Do I... > > ...Suggest the Change > > Normally, requesters are expected to do the bulk of the backporting work. If > do not have time and > resources to do the work, you have to find someone who would. You can ask > around the original > authors of the change and/or current (co-)maintainers in the update release. > > ...Request the Backport > > Backports are the issues that exist in later JDK versions and need to be > applied to lower ones as well. > > 1. Pick the existing issue from the JBS > - Take careful note of the linked issues that need to be brought with > the fix, especially the follow-up fixes; > - If there are relevant issues that prevent clean backport, consider > backporting > those first (within reason) > 2. Check out the jdk-updates/jdk11u-dev, and try to apply the patch there > - Make sure to keep the changeset metadata: original authors, Reviewed- > by: lines, etc > 3. If patch does not apply cleanly, you have to start the RFR thread at jdk- > updates-dev@ > - Need to state what changes were needed and why > - Optionally, seek the review from the original authors > 4. Test the patch > - "tier1" tests should be passing at all times > - Look at what area the patch affects, and run the tests from there > - New regression tests that come with the patch should pass > - Optionally, new regression tests may need to be verified to fail without > the patch > 5. Once everything is done, put jdk11u-fix-request tag and the "Fix Request" > comment on the issue > - Fix Request should explain why the fix should be backported, what > testing was done, > and the risk estimate > 6. Wait for maintainer approval, which would manifest as jdk11u-fix-yes tag > on the issue > 7. Push the change > - You might need a sponsor in jdk-updates project, ask at jdk-updates- > dev@ list > 8. Wait around to resolve any problems that might arise from the push > > > ...Request the Change (without Backport) > > There are cases when the lower JDK release needs to have the patch that is > not required for the > higher JDK releases. The same rule set applies, as for backports, with > mandatory RFR at > jdk-updates-dev list. > > > ...Keep the Changeset Metadata > > The easiest way to keep metadata is to import the full changeset from > Mercurial. > > > ...Test the Change > > > > ...Submit the RFR (Request For Review) > > > > ------ 8< ----------------------------------------------------------------------- That's also a very good idea. I will look into adding such a HowTo starting off with your proposal. Do you think it should be on the main page or shall I create a separate page and link to it? It's quite a bit content and might bloat the main page. It's also maybe a bit orthogonal to Severin's guide: https://wiki.openjdk.java.net/display/JDKUpdates/JDK+Updates+Guidance. Best regards Christoph From christoph.langer at sap.com Thu Mar 14 13:25:29 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 14 Mar 2019 13:25:29 +0000 Subject: [8u, 11u] Wiki Page updates In-Reply-To: <22437ea4-8b2d-0791-a6c4-42e54a613833@redhat.com> References: <3016c55d-61d7-b64c-fba9-a6a2a8fe743f@redhat.com> <22437ea4-8b2d-0791-a6c4-42e54a613833@redhat.com> Message-ID: Hi Andrew, > >> As I said yesterday [0], I think we need a label for fixes that are in > >> 8u-dev but are candidates for the current 8u after the initial > >> integration. Leaving this to bug comments makes them hard for us to find. > >> > >> I suggest 8u-CPU-critical-request and 11u-CPU-critical-request as > >> previously used [1]. > > > > I think it sounds reasonable. We can use jdk8u-critical-request and jdk11u- > critical-request, since we are not planning to ship CPUs in OpenJDK. This will > avoid namespace collisions with Oracle. > > > > I also think this should not only apply for changes that are already in jdk8u- > dev/jdk11u-dev and shall be brought to jdk8u/jdk11u but also for direct > pushes into jdk8u/jdk11u. > > > > What do other people think, especially aph? If we agree on it, I'll update > this part in the wiki and we can start living up to it. > > > > That sounds fine to me. Presumably, these would be paired with > jdk8u-critical-approved and jdk11u-critical-approved. Ok, let's wait a bit for further feedback to this. But if I don't get objections, I'll amend that to the process description on the wiki page and I'll also create appropriate JBS filters which we'd need then. Best regards Christoph From shade at redhat.com Thu Mar 14 13:31:37 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 14 Mar 2019 14:31:37 +0100 Subject: [8u, 11u] Wiki Page updates In-Reply-To: References: <72570676-d5df-d003-2364-f693a7be6be5@redhat.com> Message-ID: <215ef40d-3d8d-8ff8-5249-9f8d62aad0f0@redhat.com> On 3/14/19 2:22 PM, Langer, Christoph wrote: > That's also a very good idea. I will look into adding such a HowTo starting off with your > proposal. Do you think it should be on the main page or shall I create a separate page and link > to it? It's quite a bit content and might bloat the main page. I think all the "fast path" info should be on the main page. Gory details may be in sub-pages. Thinking from the outsider perspective, I should come in, spend 5 minutes to read the checklist, understand what is nominally expected and start doing it. As I go, maintainers and reviewers can point me to "full" policies on other pages. -Aleksey From aph at redhat.com Thu Mar 14 13:37:37 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Mar 2019 13:37:37 +0000 Subject: AArch64: 8216350 and 8215951 In-Reply-To: References: <5fefc972-210f-ce06-0d53-7a8f756ea907@redhat.com> Message-ID: On 3/14/19 11:30 AM, Aleksey Shipilev wrote: > Okay, I can push all three (8211320, 8216350, 8215951) to jdk11u (11.0.3). Confirm? Yes. Also please look at https://bugs.openjdk.java.net/browse/JDK-8211064. Please label it with jdk11u-fix-request. This is an old one which seems to have fallen down the back of the sofa. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Thu Mar 14 13:38:28 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 14 Mar 2019 14:38:28 +0100 Subject: AArch64: 8216350 and 8215951 In-Reply-To: References: <5fefc972-210f-ce06-0d53-7a8f756ea907@redhat.com> Message-ID: On 3/14/19 2:37 PM, Andrew Haley wrote: > On 3/14/19 11:30 AM, Aleksey Shipilev wrote: >> Okay, I can push all three (8211320, 8216350, 8215951) to jdk11u (11.0.3). Confirm? > > Yes. Also please look at https://bugs.openjdk.java.net/browse/JDK-8211064. Please > label it with jdk11u-fix-request. This is an old one which seems to have fallen > down the back of the sofa. Looking now. -Aleksey From shade at redhat.com Thu Mar 14 13:55:59 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 14 Mar 2019 14:55:59 +0100 Subject: AArch64: 8216350 and 8215951 In-Reply-To: References: <5fefc972-210f-ce06-0d53-7a8f756ea907@redhat.com> Message-ID: <0872d3f2-786e-06dd-6c58-c6029235d5e6@redhat.com> On 3/14/19 2:38 PM, Aleksey Shipilev wrote: > On 3/14/19 2:37 PM, Andrew Haley wrote: >> On 3/14/19 11:30 AM, Aleksey Shipilev wrote: >>> Okay, I can push all three (8211320, 8216350, 8215951) to jdk11u (11.0.3). Confirm? >> >> Yes. Also please look at https://bugs.openjdk.java.net/browse/JDK-8211064. Please >> label it with jdk11u-fix-request. This is an old one which seems to have fallen >> down the back of the sofa. > > Looking now. ...and done! So, I am pushing all four (8211320, 8216350, 8215951, 8211064) to jdk11u (11.0.3). :) -Aleksey From shade at redhat.com Thu Mar 14 15:22:43 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 14 Mar 2019 16:22:43 +0100 Subject: AArch64: 8216350 and 8215951 In-Reply-To: <0872d3f2-786e-06dd-6c58-c6029235d5e6@redhat.com> References: <5fefc972-210f-ce06-0d53-7a8f756ea907@redhat.com> <0872d3f2-786e-06dd-6c58-c6029235d5e6@redhat.com> Message-ID: <499c64c7-8ee6-40a3-da2b-2f6ef4bfe37c@redhat.com> On 3/14/19 2:55 PM, Aleksey Shipilev wrote: > On 3/14/19 2:38 PM, Aleksey Shipilev wrote: >> On 3/14/19 2:37 PM, Andrew Haley wrote: >>> On 3/14/19 11:30 AM, Aleksey Shipilev wrote: >>>> Okay, I can push all three (8211320, 8216350, 8215951) to jdk11u (11.0.3). Confirm? >>> >>> Yes. Also please look at https://bugs.openjdk.java.net/browse/JDK-8211064. Please >>> label it with jdk11u-fix-request. This is an old one which seems to have fallen >>> down the back of the sofa. >> >> Looking now. > > ...and done! So, I am pushing all four (8211320, 8216350, 8215951, 8211064) to jdk11u (11.0.3). :) Pushed. -Aleksey From aph at redhat.com Thu Mar 14 17:26:49 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Mar 2019 17:26:49 +0000 Subject: AArch64: 8216350 and 8215951 In-Reply-To: <499c64c7-8ee6-40a3-da2b-2f6ef4bfe37c@redhat.com> References: <5fefc972-210f-ce06-0d53-7a8f756ea907@redhat.com> <0872d3f2-786e-06dd-6c58-c6029235d5e6@redhat.com> <499c64c7-8ee6-40a3-da2b-2f6ef4bfe37c@redhat.com> Message-ID: On 3/14/19 3:22 PM, Aleksey Shipilev wrote: >> ...and done! So, I am pushing all four (8211320, 8216350, 8215951, 8211064) to jdk11u (11.0.3). :) > Pushed. Passed bootcycle-images and tier1, no regressions. -- 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 Thu Mar 14 18:59:22 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 14 Mar 2019 18:59:22 +0000 Subject: openjdk8u212 and openjdk11.0.3 code freeze/rampdown dates In-Reply-To: References: Message-ID: <8A7BCA18-7EBA-43E8-B0CF-E196B00F370B@amazon.com> Thanks, that clarifies things for me. Paul ?On 3/14/19, 2:29 AM, "Lindenmaier, Goetz" wrote: Hi Paul, > There are two 11.0.3 tags in jdk11u-dev, Please note that it is jdk11u that is tagged, the changes are thereafter merged to jdk11u-dev, so the tags happen to show up there, too. jdk11u-dev contains changes targeted to 11.0.4. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Hohensee, Paul > Sent: Donnerstag, 7. M?rz 2019 21:04 > To: jdk8u-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net > Subject: [DMARC FAILURE] openjdk8u212 and openjdk11.0.3 code > freeze/rampdown dates > > We?re roughly 6 weeks from when 8u211/212 and 11.0.3 will ship. There are > two 11.0.3 tags in jdk11u-dev, but no 8u212 tags in the jdk8u-dev. There are 9 > backports left on the u211/212 list. One is out for review (JDK- > 8180904/8077608 by Xin), one is unassigned (JDK-8213983), and one looks to > be taken by Aleksey (JDK-8217305). I?m willing to do the remaining 6: they?re > all pretty small. Just need jdk8u-fix-yes tags. :) > > I haven?t seen code freeze dates for non-embargoed patches candidates, but > may have missed them going by. If they aren?t yet determined, it?d be excellent > to have them so we can plan rampdown. > > Thanks, > > Paul From martin.doerr at sap.com Fri Mar 15 12:03:04 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 15 Mar 2019 12:03:04 +0000 Subject: RFR: [11u, 12u] 8219584: Try to dump error file by thread which causes safepoint timeout Message-ID: Hi, I'd like to backport this change to 11u and 12u for 2 reasons: 1. This feature can detect what causes safepoint timeouts. 2. Enable other backports. JDK-8220374 contains a new test which requires this change. https://bugs.openjdk.java.net/browse/JDK-8219584 It applies cleanly, but I'd like to make a functional adaptation because of "8203469: Faster safepoints" which is only in jdk13. The timeout condition changed and it should be the same as a few lines above in the code. Please review this adaptation: 11u/12u: diff -r 20d87ac7aa4d src/hotspot/share/runtime/safepoint.cpp --- a/src/hotspot/share/runtime/safepoint.cpp Fri Mar 08 11:23:30 2019 +0100 +++ b/src/hotspot/share/runtime/safepoint.cpp Wed Mar 13 17:44:48 2019 +0100 @@ -997,7 +997,10 @@ if (AbortVMOnSafepointTimeout) { // Send the blocking thread a signal to terminate and write an error file. for (JavaThreadIteratorWithHandle jtiwh; JavaThread *cur_thread = jtiwh.next(); ) { - if (cur_thread->safepoint_state()->is_running()) { + ThreadSafepointState *cur_state = cur_thread->safepoint_state(); + if (cur_thread->thread_state() != _thread_blocked && + ((reason == _spinning_timeout && cur_state->is_running()) || + (reason == _blocking_timeout && !cur_state->has_called_back()))) { if (!os::signal_thread(cur_thread, SIGILL, "blocking a safepoint")) { break; // Could not send signal. Report fatal error. } In addition, jdk 11u does not support compiler availability checks, so I'd like to add the following part of "8207965: C2-only debug build fails". Please review this addition for 11u: --- a/test/hotspot/jtreg/TEST.ROOT Fri Mar 08 11:23:30 2019 +0100 +++ b/test/hotspot/jtreg/TEST.ROOT Thu Mar 14 14:30:59 2019 +0100 @@ -62,6 +62,8 @@ vm.cds.custom.loaders \ vm.cds.archived.java.heap \ vm.graal.enabled \ + vm.compiler1.enabled \ + vm.compiler2.enabled \ docker.support # Minimum jtreg version diff -r 4840f7c74108 test/jdk/TEST.ROOT --- a/test/jdk/TEST.ROOT Fri Mar 08 11:23:30 2019 +0100 +++ b/test/jdk/TEST.ROOT Thu Mar 14 13:51:09 2019 +0100 @@ -39,6 +39,8 @@ java.runtime.name \ vm.gc.Z \ vm.graal.enabled \ + vm.compiler1.enabled \ + vm.compiler2.enabled \ vm.cds \ vm.hasSA \ vm.hasSAandCanAttach \ diff -r 4840f7c74108 test/jtreg-ext/requires/VMProps.java --- a/test/jtreg-ext/requires/VMProps.java Fri Mar 08 11:23:30 2019 +0100 +++ b/test/jtreg-ext/requires/VMProps.java Thu Mar 14 13:51:09 2019 +0100 @@ -92,6 +92,8 @@ map.put("vm.cds.archived.java.heap", vmCDSForArchivedJavaHeap()); // vm.graal.enabled is true if Graal is used as JIT map.put("vm.graal.enabled", isGraalEnabled()); + map.put("vm.compiler1.enabled", isCompiler1Enabled()); + map.put("vm.compiler2.enabled", isCompiler2Enabled()); map.put("docker.support", dockerSupport()); map.put("release.implementor", implementor()); vmGC(map); // vm.gc.X = true/false @@ -390,6 +392,23 @@ return Compiler.isGraalEnabled() ? "true" : "false"; } + /** + * Check if Compiler1 is present. + * + * @return true if Compiler1 is used as JIT compiler, either alone or as part of the tiered system. + */ + protected String isCompiler1Enabled() { + return Compiler.isC1Enabled() ? "true" : "false"; + } + + /** + * Check if Compiler2 is present. + * + * @return true if Compiler2 is used as JIT compiler, either alone or as part of the tiered system. + */ + protected String isCompiler2Enabled() { + return Compiler.isC2Enabled() ? "true" : "false"; + } /** * A simple check for docker support Best regards, Martin From sgehwolf at redhat.com Fri Mar 15 13:11:46 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 15 Mar 2019 14:11:46 +0100 Subject: RFR: [11u, 12u] 8219584: Try to dump error file by thread which causes safepoint timeout In-Reply-To: References: Message-ID: <3f80f38bb0c0dcfc80337411dbe52f1a0eca8675.camel@redhat.com> Hi Martin, On Fri, 2019-03-15 at 12:03 +0000, Doerr, Martin wrote: > Hi, > > I'd like to backport this change to 11u and 12u for 2 reasons: > 1. This feature can detect what causes safepoint timeouts. > 2. Enable other backports. JDK-8220374 contains a new test which requires this change. > > https://bugs.openjdk.java.net/browse/JDK-8219584 Please also consider backporting JDK-8220353 with it so as to continue to have tier one tests passing: https://bugs.openjdk.java.net/browse/JDK-8220353 JDK-8210584 makes SavePointALot a diagnostic option over develop that broke one test: http://hg.openjdk.java.net/jdk/jdk/rev/feea57b38a1c#l3.8 Thanks, Severin > > It applies cleanly, but I'd like to make a functional adaptation because of "8203469: Faster safepoints" which is only in jdk13. > The timeout condition changed and it should be the same as a few lines above in the code. > > Please review this adaptation: > > 11u/12u: > diff -r 20d87ac7aa4d src/hotspot/share/runtime/safepoint.cpp > --- a/src/hotspot/share/runtime/safepoint.cpp Fri Mar 08 11:23:30 2019 +0100 > +++ b/src/hotspot/share/runtime/safepoint.cpp Wed Mar 13 17:44:48 2019 +0100 > @@ -997,7 +997,10 @@ > if (AbortVMOnSafepointTimeout) { > // Send the blocking thread a signal to terminate and write an error file. > for (JavaThreadIteratorWithHandle jtiwh; JavaThread *cur_thread = jtiwh.next(); ) { > - if (cur_thread->safepoint_state()->is_running()) { > + ThreadSafepointState *cur_state = cur_thread->safepoint_state(); > + if (cur_thread->thread_state() != _thread_blocked && > + ((reason == _spinning_timeout && cur_state->is_running()) || > + (reason == _blocking_timeout && !cur_state->has_called_back()))) { > if (!os::signal_thread(cur_thread, SIGILL, "blocking a safepoint")) { > break; // Could not send signal. Report fatal error. > } > > > In addition, jdk 11u does not support compiler availability checks, > so I'd like to add the following part of "8207965: C2-only debug build fails". > Please review this addition for 11u: > > --- a/test/hotspot/jtreg/TEST.ROOT Fri Mar 08 11:23:30 2019 +0100 > +++ b/test/hotspot/jtreg/TEST.ROOT Thu Mar 14 14:30:59 2019 +0100 > @@ -62,6 +62,8 @@ > vm.cds.custom.loaders \ > vm.cds.archived.java.heap \ > vm.graal.enabled \ > + vm.compiler1.enabled \ > + vm.compiler2.enabled \ > docker.support > > # Minimum jtreg version > diff -r 4840f7c74108 test/jdk/TEST.ROOT > --- a/test/jdk/TEST.ROOT Fri Mar 08 11:23:30 2019 +0100 > +++ b/test/jdk/TEST.ROOT Thu Mar 14 13:51:09 2019 +0100 > @@ -39,6 +39,8 @@ > java.runtime.name \ > vm.gc.Z \ > vm.graal.enabled \ > + vm.compiler1.enabled \ > + vm.compiler2.enabled \ > vm.cds \ > vm.hasSA \ > vm.hasSAandCanAttach \ > diff -r 4840f7c74108 test/jtreg-ext/requires/VMProps.java > --- a/test/jtreg-ext/requires/VMProps.java Fri Mar 08 11:23:30 2019 +0100 > +++ b/test/jtreg-ext/requires/VMProps.java Thu Mar 14 13:51:09 2019 +0100 > @@ -92,6 +92,8 @@ > map.put("vm.cds.archived.java.heap", vmCDSForArchivedJavaHeap()); > // vm.graal.enabled is true if Graal is used as JIT > map.put("vm.graal.enabled", isGraalEnabled()); > + map.put("vm.compiler1.enabled", isCompiler1Enabled()); > + map.put("vm.compiler2.enabled", isCompiler2Enabled()); > map.put("docker.support", dockerSupport()); > map.put("release.implementor", implementor()); > vmGC(map); // vm.gc.X = true/false > @@ -390,6 +392,23 @@ > return Compiler.isGraalEnabled() ? "true" : "false"; > } > > + /** > + * Check if Compiler1 is present. > + * > + * @return true if Compiler1 is used as JIT compiler, either alone or as part of the tiered system. > + */ > + protected String isCompiler1Enabled() { > + return Compiler.isC1Enabled() ? "true" : "false"; > + } > + > + /** > + * Check if Compiler2 is present. > + * > + * @return true if Compiler2 is used as JIT compiler, either alone or as part of the tiered system. > + */ > + protected String isCompiler2Enabled() { > + return Compiler.isC2Enabled() ? "true" : "false"; > + } > > /** > * A simple check for docker support > > > Best regards, > Martin > From martin.doerr at sap.com Fri Mar 15 13:17:17 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 15 Mar 2019 13:17:17 +0000 Subject: RFR: [11u, 12u] 8219584: Try to dump error file by thread which causes safepoint timeout In-Reply-To: <3f80f38bb0c0dcfc80337411dbe52f1a0eca8675.camel@redhat.com> References: <3f80f38bb0c0dcfc80337411dbe52f1a0eca8675.camel@redhat.com> Message-ID: Hi Severin, I'm aware of that. I'll backport JDK-8220353 together with it if I get approval for this change. But thanks for pointing this out. I should have mentioned it in my previous email. Best regards, Martin -----Original Message----- From: Severin Gehwolf Sent: Freitag, 15. M?rz 2019 14:12 To: Doerr, Martin ; hotspot-runtime-dev at openjdk.java.net Cc: jdk-updates-dev at openjdk.java.net Subject: Re: RFR: [11u, 12u] 8219584: Try to dump error file by thread which causes safepoint timeout Hi Martin, On Fri, 2019-03-15 at 12:03 +0000, Doerr, Martin wrote: > Hi, > > I'd like to backport this change to 11u and 12u for 2 reasons: > 1. This feature can detect what causes safepoint timeouts. > 2. Enable other backports. JDK-8220374 contains a new test which requires this change. > > https://bugs.openjdk.java.net/browse/JDK-8219584 Please also consider backporting JDK-8220353 with it so as to continue to have tier one tests passing: https://bugs.openjdk.java.net/browse/JDK-8220353 JDK-8210584 makes SavePointALot a diagnostic option over develop that broke one test: http://hg.openjdk.java.net/jdk/jdk/rev/feea57b38a1c#l3.8 Thanks, Severin > > It applies cleanly, but I'd like to make a functional adaptation because of "8203469: Faster safepoints" which is only in jdk13. > The timeout condition changed and it should be the same as a few lines above in the code. > > Please review this adaptation: > > 11u/12u: > diff -r 20d87ac7aa4d src/hotspot/share/runtime/safepoint.cpp > --- a/src/hotspot/share/runtime/safepoint.cpp Fri Mar 08 11:23:30 2019 +0100 > +++ b/src/hotspot/share/runtime/safepoint.cpp Wed Mar 13 17:44:48 2019 +0100 > @@ -997,7 +997,10 @@ > if (AbortVMOnSafepointTimeout) { > // Send the blocking thread a signal to terminate and write an error file. > for (JavaThreadIteratorWithHandle jtiwh; JavaThread *cur_thread = jtiwh.next(); ) { > - if (cur_thread->safepoint_state()->is_running()) { > + ThreadSafepointState *cur_state = cur_thread->safepoint_state(); > + if (cur_thread->thread_state() != _thread_blocked && > + ((reason == _spinning_timeout && cur_state->is_running()) || > + (reason == _blocking_timeout && !cur_state->has_called_back()))) { > if (!os::signal_thread(cur_thread, SIGILL, "blocking a safepoint")) { > break; // Could not send signal. Report fatal error. > } > > > In addition, jdk 11u does not support compiler availability checks, > so I'd like to add the following part of "8207965: C2-only debug build fails". > Please review this addition for 11u: > > --- a/test/hotspot/jtreg/TEST.ROOT Fri Mar 08 11:23:30 2019 +0100 > +++ b/test/hotspot/jtreg/TEST.ROOT Thu Mar 14 14:30:59 2019 +0100 > @@ -62,6 +62,8 @@ > vm.cds.custom.loaders \ > vm.cds.archived.java.heap \ > vm.graal.enabled \ > + vm.compiler1.enabled \ > + vm.compiler2.enabled \ > docker.support > > # Minimum jtreg version > diff -r 4840f7c74108 test/jdk/TEST.ROOT > --- a/test/jdk/TEST.ROOT Fri Mar 08 11:23:30 2019 +0100 > +++ b/test/jdk/TEST.ROOT Thu Mar 14 13:51:09 2019 +0100 > @@ -39,6 +39,8 @@ > java.runtime.name \ > vm.gc.Z \ > vm.graal.enabled \ > + vm.compiler1.enabled \ > + vm.compiler2.enabled \ > vm.cds \ > vm.hasSA \ > vm.hasSAandCanAttach \ > diff -r 4840f7c74108 test/jtreg-ext/requires/VMProps.java > --- a/test/jtreg-ext/requires/VMProps.java Fri Mar 08 11:23:30 2019 +0100 > +++ b/test/jtreg-ext/requires/VMProps.java Thu Mar 14 13:51:09 2019 +0100 > @@ -92,6 +92,8 @@ > map.put("vm.cds.archived.java.heap", vmCDSForArchivedJavaHeap()); > // vm.graal.enabled is true if Graal is used as JIT > map.put("vm.graal.enabled", isGraalEnabled()); > + map.put("vm.compiler1.enabled", isCompiler1Enabled()); > + map.put("vm.compiler2.enabled", isCompiler2Enabled()); > map.put("docker.support", dockerSupport()); > map.put("release.implementor", implementor()); > vmGC(map); // vm.gc.X = true/false > @@ -390,6 +392,23 @@ > return Compiler.isGraalEnabled() ? "true" : "false"; > } > > + /** > + * Check if Compiler1 is present. > + * > + * @return true if Compiler1 is used as JIT compiler, either alone or as part of the tiered system. > + */ > + protected String isCompiler1Enabled() { > + return Compiler.isC1Enabled() ? "true" : "false"; > + } > + > + /** > + * Check if Compiler2 is present. > + * > + * @return true if Compiler2 is used as JIT compiler, either alone or as part of the tiered system. > + */ > + protected String isCompiler2Enabled() { > + return Compiler.isC2Enabled() ? "true" : "false"; > + } > > /** > * A simple check for docker support > > > Best regards, > Martin > From sgehwolf at redhat.com Fri Mar 15 13:20:19 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 15 Mar 2019 14:20:19 +0100 Subject: RFR: [11u, 12u] 8219584: Try to dump error file by thread which causes safepoint timeout In-Reply-To: References: <3f80f38bb0c0dcfc80337411dbe52f1a0eca8675.camel@redhat.com> Message-ID: <925b95ad2dce5deacc1c888b2d1bd58603296c43.camel@redhat.com> On Fri, 2019-03-15 at 13:17 +0000, Doerr, Martin wrote: > I'm aware of that. > I'll backport JDK-8220353 together with it if I get approval for this change. Great, thanks! Cheers, Severin From gnu.andrew at redhat.com Fri Mar 15 16:34:37 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 15 Mar 2019 16:34:37 +0000 Subject: AArch64: 8216350 and 8215951 In-Reply-To: References: <5fefc972-210f-ce06-0d53-7a8f756ea907@redhat.com> Message-ID: <03a81fea-e8a6-1bb0-0b34-24432a6042bc@redhat.com> On 14/03/2019 13:37, Andrew Haley wrote: > On 3/14/19 11:30 AM, Aleksey Shipilev wrote: >> Okay, I can push all three (8211320, 8216350, 8215951) to jdk11u (11.0.3). Confirm? > Can we please use the critical-request/approved labels as suggested in [0] for these cases? At present, it is not clear from the bugs why they were pushed to 11.0.3 instead of 11.0.4, and there's no easy way to search for such cases otherwise. Speaking for myself doing maintenance work on 8u, I would prefer to be able to easily prioritise those bugs for the imminent release, rather than the next one. > Yes. Also please look at https://bugs.openjdk.java.net/browse/JDK-8211064. Please > label it with jdk11u-fix-request. This is an old one which seems to have fallen > down the back of the sofa. > Interestingly, this actually found its way to 7 before 11! https://icedtea.classpath.org/bugzilla/show_bug.cgi?id=3669 [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-March/008916.html -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From aph at redhat.com Fri Mar 15 16:36:39 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 15 Mar 2019 16:36:39 +0000 Subject: AArch64: 8216350 and 8215951 In-Reply-To: <03a81fea-e8a6-1bb0-0b34-24432a6042bc@redhat.com> References: <5fefc972-210f-ce06-0d53-7a8f756ea907@redhat.com> <03a81fea-e8a6-1bb0-0b34-24432a6042bc@redhat.com> Message-ID: <2c0c030e-3643-45f9-8423-b3c3cc1b274c@redhat.com> On 3/15/19 4:34 PM, Andrew John Hughes wrote: > Can we please use the critical-request/approved labels as suggested in > [0] for these cases? At present, it is not clear from the bugs why they > were pushed to 11.0.3 instead of 11.0.4, and there's no easy way to > search for such cases otherwise. > > Speaking for myself doing maintenance work on 8u, I would prefer to be > able to easily prioritise those bugs for the imminent release, rather > than the next one. OK. -- 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 Fri Mar 15 21:23:07 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 15 Mar 2019 21:23:07 +0000 Subject: [jdk8u, jdk11u] Process update: Patch approval process for fixes after RDP2 Message-ID: Hi, as discussed on the mailing list [0], we have updated our process for critical fixes that should go into the OpenJDK update release that is stabilized in jdk8u/jdk11u after RDP2 (such as 11.0.3 at the moment and 8u212 in a few days). If a fix shall be brought to jdk8u/jdk11u directly, please use the labels jdk8u-critical-request/jdk11u-critical-request. The maintainer will then set jdk8u-critical-yes/jdk11u-critical-yes if the fix request is approved or jdk8u-critical-no/jdk11u-critical-no otherwise. I?ve updated the Wiki page for the jdk11u updates project [1] accordingly and will do this for jdk8u next week, too. As always, feedback is welcome ?? Best regards Christoph [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-March/000777.html [1] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u From christoph.langer at sap.com Mon Mar 18 06:46:44 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 18 Mar 2019 06:46:44 +0000 Subject: [11u] Backport of fix for CDS and JVM-TI agent crash ? Message-ID: Hi Ioi, I'd like to ping you again on this one. What are your current plans on backporting https://bugs.openjdk.java.net/browse/JDK-8212200 and whatever needs to go with it? Ideally you still want to do it, but if not I'd appreciate if you could let us know. Thanks a lot in advance Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Ioi Lam > Sent: Dienstag, 29. Januar 2019 01:33 > To: jdk-updates-dev at openjdk.java.net > Subject: Re: Backport of fix for CDS and JVM-TI agent crash ? > > There are CDS 3 bugs that I plan to backport to 11. I hope to post the > requests this week. > > https://bugs.openjdk.java.net/issues/?filter=36209 > > Thanks > > - Ioi > > On 1/28/19 8:35 AM, Lindenmaier, Goetz wrote: > > Hi, > > > > The fact a downport bug was opened does not matter, > > you could still flag jdk11u-fix-request and just push it > > if approved. This bug will then be closed as it is flagged 11-pool. > > > > More gentle it would be to ask Ioi what's going on ... > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: jdk-updates-dev > On > >> Behalf Of Volker Simonis > >> Sent: Monday, January 28, 2019 5:02 PM > >> To: Michael Rasmussen > >> Cc: jdk-updates-dev at openjdk.java.net > >> Subject: Re: Backport of fix for CDS and JVM-TI agent crash ? > >> > >> On Mon, Jan 28, 2019 at 4:17 PM Michael Rasmussen > >> wrote: > >>> Hi, > >>> > >>> I was wondering if there are any plans to backport > >> https://bugs.openjdk.java.net/browse/JDK-8212200 to jdk11u. > >>> I can see https://bugs.openjdk.java.net/browse/JDK-8213164 has been > >> created, but don't know if there are any active plans to actually do it? > >> Hi Michael, > >> > >> I actually don't really understand what this means. Usually, you do a > >> down-port by first requesting it on the original bug by applying a > >> "jdku-fix-request" tag. Once the downport will be approved > >> (by application of a "jdku-fix-yes" tag), the corresponding > >> fix can be pushed to the updates repository. This push automatically > >> triggers the creation of the corresponding backport issue in JBS. > >> > >> I don't know what it means for the downport process [1] if somebody > >> (apparently manually) creates a backport issue like > >> https://bugs.openjdk.java.net/browse/JDK-8213164 ? > >> > >> Regards, > >> Volker > >> > >> [1] http://openjdk.java.net/projects/jdk-updates/approval.html > >> > >>> Kind regards > >>> /Michael From goetz.lindenmaier at sap.com Mon Mar 18 11:55:16 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 18 Mar 2019 11:55:16 +0000 Subject: RFR: [11u, 12u] 8219584: Try to dump error file by thread which causes safepoint timeout In-Reply-To: References: Message-ID: Hi, the change looks good, the adaptions make sense. I'd appreciate a webrev next time ... maybe an incremental one in this case as the other applies clean (checked :)). Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Doerr, Martin > Sent: Freitag, 15. M?rz 2019 13:03 > To: hotspot-runtime-dev at openjdk.java.net > Cc: jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] RFR: [11u, 12u] 8219584: Try to dump error file by thread > which causes safepoint timeout > > Hi, > > I'd like to backport this change to 11u and 12u for 2 reasons: > 1. This feature can detect what causes safepoint timeouts. > 2. Enable other backports. JDK-8220374 contains a new test which requires > this change. > > https://bugs.openjdk.java.net/browse/JDK-8219584 > > > It applies cleanly, but I'd like to make a functional adaptation because of > "8203469: Faster safepoints" which is only in jdk13. > The timeout condition changed and it should be the same as a few lines above > in the code. > > Please review this adaptation: > > 11u/12u: > diff -r 20d87ac7aa4d src/hotspot/share/runtime/safepoint.cpp > --- a/src/hotspot/share/runtime/safepoint.cpp Fri Mar 08 11:23:30 2019 > +0100 > +++ b/src/hotspot/share/runtime/safepoint.cpp Wed Mar 13 17:44:48 2019 > +0100 > @@ -997,7 +997,10 @@ > if (AbortVMOnSafepointTimeout) { > // Send the blocking thread a signal to terminate and write an error file. > for (JavaThreadIteratorWithHandle jtiwh; JavaThread *cur_thread = > jtiwh.next(); ) { > - if (cur_thread->safepoint_state()->is_running()) { > + ThreadSafepointState *cur_state = cur_thread->safepoint_state(); > + if (cur_thread->thread_state() != _thread_blocked && > + ((reason == _spinning_timeout && cur_state->is_running()) || > + (reason == _blocking_timeout && !cur_state->has_called_back()))) { > if (!os::signal_thread(cur_thread, SIGILL, "blocking a safepoint")) { > break; // Could not send signal. Report fatal error. > } > > > In addition, jdk 11u does not support compiler availability checks, > so I'd like to add the following part of "8207965: C2-only debug build fails". > Please review this addition for 11u: > > --- a/test/hotspot/jtreg/TEST.ROOT Fri Mar 08 11:23:30 2019 +0100 > +++ b/test/hotspot/jtreg/TEST.ROOT Thu Mar 14 14:30:59 2019 +0100 > @@ -62,6 +62,8 @@ > vm.cds.custom.loaders \ > vm.cds.archived.java.heap \ > vm.graal.enabled \ > + vm.compiler1.enabled \ > + vm.compiler2.enabled \ > docker.support > > # Minimum jtreg version > diff -r 4840f7c74108 test/jdk/TEST.ROOT > --- a/test/jdk/TEST.ROOT Fri Mar 08 11:23:30 2019 +0100 > +++ b/test/jdk/TEST.ROOT Thu Mar 14 13:51:09 2019 +0100 > @@ -39,6 +39,8 @@ > java.runtime.name \ > vm.gc.Z \ > vm.graal.enabled \ > + vm.compiler1.enabled \ > + vm.compiler2.enabled \ > vm.cds \ > vm.hasSA \ > vm.hasSAandCanAttach \ > diff -r 4840f7c74108 test/jtreg-ext/requires/VMProps.java > --- a/test/jtreg-ext/requires/VMProps.java Fri Mar 08 11:23:30 2019 +0100 > +++ b/test/jtreg-ext/requires/VMProps.java Thu Mar 14 13:51:09 2019 > +0100 > @@ -92,6 +92,8 @@ > map.put("vm.cds.archived.java.heap", vmCDSForArchivedJavaHeap()); > // vm.graal.enabled is true if Graal is used as JIT > map.put("vm.graal.enabled", isGraalEnabled()); > + map.put("vm.compiler1.enabled", isCompiler1Enabled()); > + map.put("vm.compiler2.enabled", isCompiler2Enabled()); > map.put("docker.support", dockerSupport()); > map.put("release.implementor", implementor()); > vmGC(map); // vm.gc.X = true/false > @@ -390,6 +392,23 @@ > return Compiler.isGraalEnabled() ? "true" : "false"; > } > > + /** > + * Check if Compiler1 is present. > + * > + * @return true if Compiler1 is used as JIT compiler, either alone or as part > of the tiered system. > + */ > + protected String isCompiler1Enabled() { > + return Compiler.isC1Enabled() ? "true" : "false"; > + } > + > + /** > + * Check if Compiler2 is present. > + * > + * @return true if Compiler2 is used as JIT compiler, either alone or as part > of the tiered system. > + */ > + protected String isCompiler2Enabled() { > + return Compiler.isC2Enabled() ? "true" : "false"; > + } > > /** > * A simple check for docker support > > > Best regards, > Martin From martin.doerr at sap.com Mon Mar 18 11:58:18 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 18 Mar 2019 11:58:18 +0000 Subject: RFR: [11u, 12u] 8219584: Try to dump error file by thread which causes safepoint timeout In-Reply-To: References: Message-ID: Hi G?tz, an incremental webrev sounds like a good idea. I'll try to remember that next time. Thank you for the review. Best regards, Martin -----Original Message----- From: Lindenmaier, Goetz Sent: Montag, 18. M?rz 2019 12:55 To: Doerr, Martin ; hotspot-runtime-dev at openjdk.java.net Cc: jdk-updates-dev at openjdk.java.net Subject: RE: RFR: [11u, 12u] 8219584: Try to dump error file by thread which causes safepoint timeout Hi, the change looks good, the adaptions make sense. I'd appreciate a webrev next time ... maybe an incremental one in this case as the other applies clean (checked :)). Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Doerr, Martin > Sent: Freitag, 15. M?rz 2019 13:03 > To: hotspot-runtime-dev at openjdk.java.net > Cc: jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] RFR: [11u, 12u] 8219584: Try to dump error file by thread > which causes safepoint timeout > > Hi, > > I'd like to backport this change to 11u and 12u for 2 reasons: > 1. This feature can detect what causes safepoint timeouts. > 2. Enable other backports. JDK-8220374 contains a new test which requires > this change. > > https://bugs.openjdk.java.net/browse/JDK-8219584 > > > It applies cleanly, but I'd like to make a functional adaptation because of > "8203469: Faster safepoints" which is only in jdk13. > The timeout condition changed and it should be the same as a few lines above > in the code. > > Please review this adaptation: > > 11u/12u: > diff -r 20d87ac7aa4d src/hotspot/share/runtime/safepoint.cpp > --- a/src/hotspot/share/runtime/safepoint.cpp Fri Mar 08 11:23:30 2019 > +0100 > +++ b/src/hotspot/share/runtime/safepoint.cpp Wed Mar 13 17:44:48 2019 > +0100 > @@ -997,7 +997,10 @@ > if (AbortVMOnSafepointTimeout) { > // Send the blocking thread a signal to terminate and write an error file. > for (JavaThreadIteratorWithHandle jtiwh; JavaThread *cur_thread = > jtiwh.next(); ) { > - if (cur_thread->safepoint_state()->is_running()) { > + ThreadSafepointState *cur_state = cur_thread->safepoint_state(); > + if (cur_thread->thread_state() != _thread_blocked && > + ((reason == _spinning_timeout && cur_state->is_running()) || > + (reason == _blocking_timeout && !cur_state->has_called_back()))) { > if (!os::signal_thread(cur_thread, SIGILL, "blocking a safepoint")) { > break; // Could not send signal. Report fatal error. > } > > > In addition, jdk 11u does not support compiler availability checks, > so I'd like to add the following part of "8207965: C2-only debug build fails". > Please review this addition for 11u: > > --- a/test/hotspot/jtreg/TEST.ROOT Fri Mar 08 11:23:30 2019 +0100 > +++ b/test/hotspot/jtreg/TEST.ROOT Thu Mar 14 14:30:59 2019 +0100 > @@ -62,6 +62,8 @@ > vm.cds.custom.loaders \ > vm.cds.archived.java.heap \ > vm.graal.enabled \ > + vm.compiler1.enabled \ > + vm.compiler2.enabled \ > docker.support > > # Minimum jtreg version > diff -r 4840f7c74108 test/jdk/TEST.ROOT > --- a/test/jdk/TEST.ROOT Fri Mar 08 11:23:30 2019 +0100 > +++ b/test/jdk/TEST.ROOT Thu Mar 14 13:51:09 2019 +0100 > @@ -39,6 +39,8 @@ > java.runtime.name \ > vm.gc.Z \ > vm.graal.enabled \ > + vm.compiler1.enabled \ > + vm.compiler2.enabled \ > vm.cds \ > vm.hasSA \ > vm.hasSAandCanAttach \ > diff -r 4840f7c74108 test/jtreg-ext/requires/VMProps.java > --- a/test/jtreg-ext/requires/VMProps.java Fri Mar 08 11:23:30 2019 +0100 > +++ b/test/jtreg-ext/requires/VMProps.java Thu Mar 14 13:51:09 2019 > +0100 > @@ -92,6 +92,8 @@ > map.put("vm.cds.archived.java.heap", vmCDSForArchivedJavaHeap()); > // vm.graal.enabled is true if Graal is used as JIT > map.put("vm.graal.enabled", isGraalEnabled()); > + map.put("vm.compiler1.enabled", isCompiler1Enabled()); > + map.put("vm.compiler2.enabled", isCompiler2Enabled()); > map.put("docker.support", dockerSupport()); > map.put("release.implementor", implementor()); > vmGC(map); // vm.gc.X = true/false > @@ -390,6 +392,23 @@ > return Compiler.isGraalEnabled() ? "true" : "false"; > } > > + /** > + * Check if Compiler1 is present. > + * > + * @return true if Compiler1 is used as JIT compiler, either alone or as part > of the tiered system. > + */ > + protected String isCompiler1Enabled() { > + return Compiler.isC1Enabled() ? "true" : "false"; > + } > + > + /** > + * Check if Compiler2 is present. > + * > + * @return true if Compiler2 is used as JIT compiler, either alone or as part > of the tiered system. > + */ > + protected String isCompiler2Enabled() { > + return Compiler.isC2Enabled() ? "true" : "false"; > + } > > /** > * A simple check for docker support > > > Best regards, > Martin From shade at redhat.com Mon Mar 18 15:41:01 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 18 Mar 2019 16:41:01 +0100 Subject: [11u] RFR (XS) 8220718: Missing ResourceMark in nmethod::metadata_do Message-ID: Hi, Please review a small fix in 11u. It cherry-picks the one-liner change that was pushed to 12u in a much larger one. See the rationale and details in the bug: https://bugs.openjdk.java.net/browse/JDK-8220718 Patch: http://cr.openjdk.java.net/~shade/8220718/webrev.11u.01/ Testing: tier {1,2,3} locally Thanks, -Aleksey From martin.doerr at sap.com Mon Mar 18 15:57:12 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 18 Mar 2019 15:57:12 +0000 Subject: [11u] RFR (XS) 8220718: Missing ResourceMark in nmethod::metadata_do In-Reply-To: References: Message-ID: Hi Aleksey, looks good. Thanks for fixing this memory leak in 11u. Best regards, Martin -----Original Message----- From: jdk-updates-dev On Behalf Of Aleksey Shipilev Sent: Montag, 18. M?rz 2019 16:41 To: hotspot-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net Subject: [11u] RFR (XS) 8220718: Missing ResourceMark in nmethod::metadata_do Hi, Please review a small fix in 11u. It cherry-picks the one-liner change that was pushed to 12u in a much larger one. See the rationale and details in the bug: https://bugs.openjdk.java.net/browse/JDK-8220718 Patch: http://cr.openjdk.java.net/~shade/8220718/webrev.11u.01/ Testing: tier {1,2,3} locally Thanks, -Aleksey From zgu at redhat.com Mon Mar 18 16:11:51 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 18 Mar 2019 12:11:51 -0400 Subject: [11u] RFR (XS) 8220718: Missing ResourceMark in nmethod::metadata_do In-Reply-To: References: Message-ID: Looks good. -Zhengyu On 3/18/19 11:41 AM, Aleksey Shipilev wrote: > Hi, > > Please review a small fix in 11u. It cherry-picks the one-liner change that was pushed to 12u in a > much larger one. See the rationale and details in the bug: > https://bugs.openjdk.java.net/browse/JDK-8220718 > > Patch: > http://cr.openjdk.java.net/~shade/8220718/webrev.11u.01/ > > Testing: tier {1,2,3} locally > > Thanks, > -Aleksey > From ioi.lam at oracle.com Mon Mar 18 18:26:45 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 18 Mar 2019 11:26:45 -0700 Subject: [11u] Backport of fix for CDS and JVM-TI agent crash ? In-Reply-To: References: Message-ID: <2d9733c7-f629-1838-856e-dc06e908a20f@oracle.com> Hi Christoph, I have been reassigned (and I've removed myself as the assigned engineer for those bugs) so I think it's best for the openjdk community to pick up these backports. Thanks - Ioi On 3/17/19 11:46 PM, Langer, Christoph wrote: > Hi Ioi, > > I'd like to ping you again on this one. What are your current plans on backporting https://bugs.openjdk.java.net/browse/JDK-8212200 and whatever needs to go with it? Ideally you still want to do it, but if not I'd appreciate if you could let us know. > > Thanks a lot in advance > Christoph > > >> -----Original Message----- >> From: jdk-updates-dev On >> Behalf Of Ioi Lam >> Sent: Dienstag, 29. Januar 2019 01:33 >> To: jdk-updates-dev at openjdk.java.net >> Subject: Re: Backport of fix for CDS and JVM-TI agent crash ? >> >> There are CDS 3 bugs that I plan to backport to 11. I hope to post the >> requests this week. >> >> https://bugs.openjdk.java.net/issues/?filter=36209 >> >> Thanks >> >> - Ioi >> >> On 1/28/19 8:35 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> The fact a downport bug was opened does not matter, >>> you could still flag jdk11u-fix-request and just push it >>> if approved. This bug will then be closed as it is flagged 11-pool. >>> >>> More gentle it would be to ask Ioi what's going on ... >>> >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: jdk-updates-dev >> On >>>> Behalf Of Volker Simonis >>>> Sent: Monday, January 28, 2019 5:02 PM >>>> To: Michael Rasmussen >>>> Cc: jdk-updates-dev at openjdk.java.net >>>> Subject: Re: Backport of fix for CDS and JVM-TI agent crash ? >>>> >>>> On Mon, Jan 28, 2019 at 4:17 PM Michael Rasmussen >>>> wrote: >>>>> Hi, >>>>> >>>>> I was wondering if there are any plans to backport >>>> https://bugs.openjdk.java.net/browse/JDK-8212200 to jdk11u. >>>>> I can see https://bugs.openjdk.java.net/browse/JDK-8213164 has been >>>> created, but don't know if there are any active plans to actually do it? >>>> Hi Michael, >>>> >>>> I actually don't really understand what this means. Usually, you do a >>>> down-port by first requesting it on the original bug by applying a >>>> "jdku-fix-request" tag. Once the downport will be approved >>>> (by application of a "jdku-fix-yes" tag), the corresponding >>>> fix can be pushed to the updates repository. This push automatically >>>> triggers the creation of the corresponding backport issue in JBS. >>>> >>>> I don't know what it means for the downport process [1] if somebody >>>> (apparently manually) creates a backport issue like >>>> https://bugs.openjdk.java.net/browse/JDK-8213164 ? >>>> >>>> Regards, >>>> Volker >>>> >>>> [1] http://openjdk.java.net/projects/jdk-updates/approval.html >>>> >>>>> Kind regards >>>>> /Michael From christoph.langer at sap.com Mon Mar 18 21:08:45 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 18 Mar 2019 21:08:45 +0000 Subject: [11u] Backport of fix for CDS and JVM-TI agent crash ? In-Reply-To: <2d9733c7-f629-1838-856e-dc06e908a20f@oracle.com> References: <2d9733c7-f629-1838-856e-dc06e908a20f@oracle.com> Message-ID: Hi Ioi, ok, thanks for that information. Can you let us know, what exactly these 3 bugs were, that should be backported? I guess it's about JDK-8212200, JDK-8213182 which fixes a build failure after the former one. And what's the 3rd issue? Thanks Christoph > -----Original Message----- > From: Ioi Lam > Sent: Montag, 18. M?rz 2019 19:27 > To: Langer, Christoph > Cc: jdk-updates-dev at openjdk.java.net; Michael Rasmussen > > Subject: Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? > > Hi Christoph, I have been reassigned (and I've removed myself as the > assigned engineer for those bugs) so I think it's best for the openjdk > community to pick up these backports. > > Thanks > > - Ioi > > On 3/17/19 11:46 PM, Langer, Christoph wrote: > > Hi Ioi, > > > > I'd like to ping you again on this one. What are your current plans on > backporting https://bugs.openjdk.java.net/browse/JDK-8212200 and > whatever needs to go with it? Ideally you still want to do it, but if not I'd > appreciate if you could let us know. > > > > Thanks a lot in advance > > Christoph > > > > > >> -----Original Message----- > >> From: jdk-updates-dev > On > >> Behalf Of Ioi Lam > >> Sent: Dienstag, 29. Januar 2019 01:33 > >> To: jdk-updates-dev at openjdk.java.net > >> Subject: Re: Backport of fix for CDS and JVM-TI agent crash ? > >> > >> There are CDS 3 bugs that I plan to backport to 11. I hope to post the > >> requests this week. > >> > >> https://bugs.openjdk.java.net/issues/?filter=36209 > >> > >> Thanks > >> > >> - Ioi > >> > >> On 1/28/19 8:35 AM, Lindenmaier, Goetz wrote: > >>> Hi, > >>> > >>> The fact a downport bug was opened does not matter, > >>> you could still flag jdk11u-fix-request and just push it > >>> if approved. This bug will then be closed as it is flagged 11-pool. > >>> > >>> More gentle it would be to ask Ioi what's going on ... > >>> > >>> Best regards, > >>> Goetz. > >>> > >>>> -----Original Message----- > >>>> From: jdk-updates-dev bounces at openjdk.java.net> > >> On > >>>> Behalf Of Volker Simonis > >>>> Sent: Monday, January 28, 2019 5:02 PM > >>>> To: Michael Rasmussen > >>>> Cc: jdk-updates-dev at openjdk.java.net > >>>> Subject: Re: Backport of fix for CDS and JVM-TI agent crash ? > >>>> > >>>> On Mon, Jan 28, 2019 at 4:17 PM Michael Rasmussen > >>>> wrote: > >>>>> Hi, > >>>>> > >>>>> I was wondering if there are any plans to backport > >>>> https://bugs.openjdk.java.net/browse/JDK-8212200 to jdk11u. > >>>>> I can see https://bugs.openjdk.java.net/browse/JDK-8213164 has > been > >>>> created, but don't know if there are any active plans to actually do it? > >>>> Hi Michael, > >>>> > >>>> I actually don't really understand what this means. Usually, you do a > >>>> down-port by first requesting it on the original bug by applying a > >>>> "jdku-fix-request" tag. Once the downport will be approved > >>>> (by application of a "jdku-fix-yes" tag), the corresponding > >>>> fix can be pushed to the updates repository. This push automatically > >>>> triggers the creation of the corresponding backport issue in JBS. > >>>> > >>>> I don't know what it means for the downport process [1] if somebody > >>>> (apparently manually) creates a backport issue like > >>>> https://bugs.openjdk.java.net/browse/JDK-8213164 ? > >>>> > >>>> Regards, > >>>> Volker > >>>> > >>>> [1] http://openjdk.java.net/projects/jdk-updates/approval.html > >>>> > >>>>> Kind regards > >>>>> /Michael From christoph.langer at sap.com Tue Mar 19 08:22:00 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 19 Mar 2019 08:22:00 +0000 Subject: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux In-Reply-To: References: Message-ID: I have removed the jdk11u-fix-no label from the bug and added a fix request comment to trigger reconsideration. /Christoph From: Thomas St?fe Sent: Dienstag, 19. M?rz 2019 08:33 To: Andrew Haley Cc: Langer, Christoph ; Java Core Libs ; Alan Bateman ; Roger Riggs ; jdk-updates-dev at openjdk.java.net; David Lloyd Subject: Re: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux Hi Andrew, This would be good to have in jdk11 for the following reason: The established (since decades) method of forking off on Linux JDKs has been to use vfork(3). Using vfork is risky. There are chances of crashing the parent process. The risk of this happening is very low, but not zero. Since analyzing those crashes and attributing them to vfork(3) is very difficult, there may be a number of reported cases not associated with vfork(3) but in fact caused by it. The patch adds a second, safer way to fork off childs, using posix_spawn(3). This one has been the default on other platforms for quite some while. The patch does not change the default fork mode - which remains vfork(3). So installations would not be affected unless they explicitely choose to use vfork(3). Having this possibility would allow us to use posix_spawn(3) in situations where we are analysing crashes and want to exclude vfork(3) as a cause. It also would enable us to use posix_spawn(3) as a safe alternative by default if we choose to do so. In addition to that, as David Loyd mentioned, vfork(3) is marked as obsolete and may be vanish at some point in the life span of JDK 11. I admit the chance of this happening is low. Kind Regards, Thomas On Fri, Mar 8, 2019 at 4:20 PM Andrew Haley > wrote: On 3/8/19 2:39 PM, Langer, Christoph wrote: > please review the CSR backport https://bugs.openjdk.java.net/browse/JDK-8220362. > > It is the backport of https://bugs.openjdk.java.net/browse/JDK-8214511 to JDK11. > > We want to backport JDK-8212828 to jdk11u and hence backporting the CSR is a prerequisite. The CSR is, however, more or less identical for 11u. I don't see any explanation of why this should go into jdk11. -- 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 Mar 19 09:00:30 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 19 Mar 2019 09:00:30 +0000 Subject: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux In-Reply-To: References: Message-ID: Hm, I?m not sure about the ?reconsideration? process? I restored jdk11u-fix-no, because it?s probably not in my powers to remove it. But still the request for reconsideration remains ?? /Christoph From: Langer, Christoph Sent: Dienstag, 19. M?rz 2019 09:22 To: Thomas St?fe ; Andrew Haley Cc: Java Core Libs ; Alan Bateman ; Roger Riggs ; jdk-updates-dev at openjdk.java.net; David Lloyd Subject: RE: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux I have removed the jdk11u-fix-no label from the bug and added a fix request comment to trigger reconsideration. /Christoph From: Thomas St?fe > Sent: Dienstag, 19. M?rz 2019 08:33 To: Andrew Haley > Cc: Langer, Christoph >; Java Core Libs >; Alan Bateman >; Roger Riggs >; jdk-updates-dev at openjdk.java.net; David Lloyd > Subject: Re: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux Hi Andrew, This would be good to have in jdk11 for the following reason: The established (since decades) method of forking off on Linux JDKs has been to use vfork(3). Using vfork is risky. There are chances of crashing the parent process. The risk of this happening is very low, but not zero. Since analyzing those crashes and attributing them to vfork(3) is very difficult, there may be a number of reported cases not associated with vfork(3) but in fact caused by it. The patch adds a second, safer way to fork off childs, using posix_spawn(3). This one has been the default on other platforms for quite some while. The patch does not change the default fork mode - which remains vfork(3). So installations would not be affected unless they explicitely choose to use vfork(3). Having this possibility would allow us to use posix_spawn(3) in situations where we are analysing crashes and want to exclude vfork(3) as a cause. It also would enable us to use posix_spawn(3) as a safe alternative by default if we choose to do so. In addition to that, as David Loyd mentioned, vfork(3) is marked as obsolete and may be vanish at some point in the life span of JDK 11. I admit the chance of this happening is low. Kind Regards, Thomas On Fri, Mar 8, 2019 at 4:20 PM Andrew Haley > wrote: On 3/8/19 2:39 PM, Langer, Christoph wrote: > please review the CSR backport https://bugs.openjdk.java.net/browse/JDK-8220362. > > It is the backport of https://bugs.openjdk.java.net/browse/JDK-8214511 to JDK11. > > We want to backport JDK-8212828 to jdk11u and hence backporting the CSR is a prerequisite. The CSR is, however, more or less identical for 11u. I don't see any explanation of why this should go into jdk11. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Mar 19 09:34:19 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 Mar 2019 09:34:19 +0000 Subject: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux In-Reply-To: References: Message-ID: <98e664a5-9511-db44-5528-5ad57eb30c91@redhat.com> On 3/11/19 1:09 PM, David Lloyd wrote: > Is vfork still guaranteed to be functional by the end of the Java 11 > support frame, from the perspective of any organization which supports > JDKs of this version? It's extremely unlikely to be made nonfunctional. Linux backwards compatibility is excellent. Besides, if vfork() is nonfunctional we'll need to change the Linux default -- not just provide an alternative -- so this patch will be inadequate. All this patch does is provide an alternative to experiment with. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Mar 19 09:39:18 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 Mar 2019 09:39:18 +0000 Subject: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux In-Reply-To: References: Message-ID: On 3/19/19 7:33 AM, Thomas St?fe wrote: > The established (since decades) method of forking off on Linux JDKs > has been to use vfork(3). Using vfork is risky. There are chances of > crashing the parent process. The risk of this happening is very low, > but not zero. Do you have a reference to this? If we're at risk, I'd like to know exactly what the risk is. > Since analyzing those crashes and attributing them to vfork(3) is > very difficult, there may be a number of reported cases not > associated with vfork(3) but in fact caused by it. > The patch adds a second, safer way to fork off childs, using > posix_spawn(3). This one has been the default on other platforms for > quite some while. The patch does not change the default fork mode - > which remains vfork(3). So installations would not be affected > unless they explicitely choose to use vfork(3). > > Having this possibility would allow us to use posix_spawn(3) in > situations where we are analysing crashes and want to exclude > vfork(3) as a cause. It also would enable us to use posix_spawn(3) > as a safe alternative by default if we choose to do so. > > In addition to that, as David Loyd mentioned, vfork(3) is marked as > obsolete and may be vanish at some point in the life span of JDK > 11. I admit the chance of this happening is low. Sure, but as I replied to him, this patch doesn't solve that problem. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Mar 19 09:39:42 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 Mar 2019 09:39:42 +0000 Subject: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux In-Reply-To: References: Message-ID: On 3/8/19 2:39 PM, Langer, Christoph wrote: > please review the CSR backport https://bugs.openjdk.java.net/browse/JDK-8220362. > > It is the backport of https://bugs.openjdk.java.net/browse/JDK-8214511 to JDK11. > > We want to backport JDK-8212828 to jdk11u and hence backporting the CSR is a prerequisite. The CSR is, however, more or less identical for 11u. OK. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From thomas.stuefe at gmail.com Tue Mar 19 10:51:35 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 19 Mar 2019 11:51:35 +0100 Subject: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux In-Reply-To: References: Message-ID: On Tue, Mar 19, 2019 at 10:39 AM Andrew Haley wrote: > On 3/19/19 7:33 AM, Thomas St?fe wrote: > > > The established (since decades) method of forking off on Linux JDKs > > has been to use vfork(3). Using vfork is risky. There are chances of > > crashing the parent process. The risk of this happening is very low, > > but not zero. > > Do you have a reference to this? If we're at risk, I'd like to know > exactly what the risk is. > Sure, see here an old mail from me to core libs last year: https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055333.html (Please ignore my proposed fix, turned out David Loyd's posix_spawn proposal was a way simpler solution.) very short version: After child process is spawned via vfork() but before it calls exec() both parent and child are vulnerable in the following way: A signal received by the child may damage or kill the parent. True for both synchronous (error) signals in the child and outside signals sent to the child. - since the child process code is old and stable, error signals are not likely, with one possible exception: hitting a stack overflow in the child process (e.g. when calling fork in a low stack situation) - asynchronous signals could be sent from the outside. Unlikely to be a targeted kill, since the parent cannot yet have communicated the child pid to the outside; but could be a group kill. Note that the risk depends on the the length of the time span between fork and exec, which depends on the number of open file descriptors in the parent. As I wrote, the risk is low - a freak accident - but not zero and has a question mark around it since these crashes are hard to attribute to vfork. Typical symptom is that the parent process just dies without a trace. --- As to the question: if it is so important why do we not switch the default? This is the result of a discussion with the core-libs maintainers and a trade off between the vfork() risk and the risk of adding this patch. Roger preferred to provide the non-default alternative for 12 and switch the default to posix_spawn() for 13. I think long term it definitely will make sense to switch the default to posix_spawn on 11 and 12 too, maybe after a grace period. Cheers, Thomas > > Since analyzing those crashes and attributing them to vfork(3) is > > very difficult, there may be a number of reported cases not > > associated with vfork(3) but in fact caused by it. > > > The patch adds a second, safer way to fork off childs, using > > posix_spawn(3). This one has been the default on other platforms for > > quite some while. The patch does not change the default fork mode - > > which remains vfork(3). So installations would not be affected > > unless they explicitely choose to use vfork(3). > > > > Having this possibility would allow us to use posix_spawn(3) in > > situations where we are analysing crashes and want to exclude > > vfork(3) as a cause. It also would enable us to use posix_spawn(3) > > as a safe alternative by default if we choose to do so. > > > > In addition to that, as David Loyd mentioned, vfork(3) is marked as > > obsolete and may be vanish at some point in the life span of JDK > > 11. I admit the chance of this happening is low. > > Sure, but as I replied to him, this patch doesn't solve that problem. > Fair enough. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From thomas.stuefe at gmail.com Tue Mar 19 07:33:04 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 19 Mar 2019 08:33:04 +0100 Subject: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux In-Reply-To: References: Message-ID: Hi Andrew, This would be good to have in jdk11 for the following reason: The established (since decades) method of forking off on Linux JDKs has been to use vfork(3). Using vfork is risky. There are chances of crashing the parent process. The risk of this happening is very low, but not zero. Since analyzing those crashes and attributing them to vfork(3) is very difficult, there may be a number of reported cases not associated with vfork(3) but in fact caused by it. The patch adds a second, safer way to fork off childs, using posix_spawn(3). This one has been the default on other platforms for quite some while. The patch does not change the default fork mode - which remains vfork(3). So installations would not be affected unless they explicitely choose to use vfork(3). Having this possibility would allow us to use posix_spawn(3) in situations where we are analysing crashes and want to exclude vfork(3) as a cause. It also would enable us to use posix_spawn(3) as a safe alternative by default if we choose to do so. In addition to that, as David Loyd mentioned, vfork(3) is marked as obsolete and may be vanish at some point in the life span of JDK 11. I admit the chance of this happening is low. Kind Regards, Thomas On Fri, Mar 8, 2019 at 4:20 PM Andrew Haley wrote: > On 3/8/19 2:39 PM, Langer, Christoph wrote: > > please review the CSR backport > https://bugs.openjdk.java.net/browse/JDK-8220362. > > > > It is the backport of https://bugs.openjdk.java.net/browse/JDK-8214511 > to JDK11. > > > > We want to backport JDK-8212828< > https://bugs.openjdk.java.net/browse/JDK-8212828> to jdk11u and hence > backporting the CSR is a prerequisite. The CSR is, however, more or less > identical for 11u. > > I don't see any explanation of why this should go into jdk11. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From martinrb at google.com Tue Mar 19 16:10:16 2019 From: martinrb at google.com (Martin Buchholz) Date: Tue, 19 Mar 2019 09:10:16 -0700 Subject: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux In-Reply-To: References: Message-ID: I'm the one who introduced vfork for process spawning, and I support Thomas' plan to switch to posix_spawn. (although I have not seen a crash attributed to using vfork on Linux) From aph at redhat.com Tue Mar 19 16:42:24 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 Mar 2019 16:42:24 +0000 Subject: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux In-Reply-To: References: Message-ID: <70a875dc-3cdb-5dd8-9dfc-443c1c002713@redhat.com> On 3/19/19 4:10 PM, Martin Buchholz wrote: > I'm the one who introduced vfork for process spawning, and I support Thomas' plan to switch to posix_spawn. > (although I have not seen a crash attributed to using vfork on Linux) Thanks. I get that, I'm just questioning the need to backport it to 11. No matter, I've approved it now. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From thomas.stuefe at gmail.com Tue Mar 19 17:32:08 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 19 Mar 2019 18:32:08 +0100 Subject: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux In-Reply-To: <70a875dc-3cdb-5dd8-9dfc-443c1c002713@redhat.com> References: <70a875dc-3cdb-5dd8-9dfc-443c1c002713@redhat.com> Message-ID: Thank you, Andrew .. Thomas On Tue, Mar 19, 2019, 5:42 PM Andrew Haley wrote: > On 3/19/19 4:10 PM, Martin Buchholz wrote: > > I'm the one who introduced vfork for process spawning, and I support > Thomas' plan to switch to posix_spawn. > > (although I have not seen a crash attributed to using vfork on Linux) > > Thanks. I get that, I'm just questioning the need to backport it to 11. > No matter, I've approved it now. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From ioi.lam at oracle.com Tue Mar 19 21:37:46 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 19 Mar 2019 14:37:46 -0700 Subject: [11u] Backport of fix for CDS and JVM-TI agent crash ? In-Reply-To: References: <2d9733c7-f629-1838-856e-dc06e908a20f@oracle.com> Message-ID: The 3 issues that I wanted to backport were: Issue?????? BP-of?? Synopsis JDK-8212991 8212205 VM asserts after CDS archive has been unmapped JDK-8213273 8213250 CDS archive creation aborts due to metaspace object allocation failure JDK-8213164 8212200 assert(on_stack()) failed when shared java.lang.object is redefined by JVMTI agent They are all backport issues related to CDS with (fixVersion = 11-pool). Only the last one is related to JVMTI, but the other 2 are kind of serious as well. But due to reassignment, I wasn't able to do the backport :-( Thanks - Ioi On 3/18/19 2:08 PM, Langer, Christoph wrote: > Hi Ioi, > > ok, thanks for that information. > > Can you let us know, what exactly these 3 bugs were, that should be backported? I guess it's about JDK-8212200, JDK-8213182 which fixes a build failure after the former one. And what's the 3rd issue? > > Thanks > Christoph > >> -----Original Message----- >> From: Ioi Lam >> Sent: Montag, 18. M?rz 2019 19:27 >> To: Langer, Christoph >> Cc: jdk-updates-dev at openjdk.java.net; Michael Rasmussen >> >> Subject: Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? >> >> Hi Christoph, I have been reassigned (and I've removed myself as the >> assigned engineer for those bugs) so I think it's best for the openjdk >> community to pick up these backports. >> >> Thanks >> >> - Ioi >> >> On 3/17/19 11:46 PM, Langer, Christoph wrote: >>> Hi Ioi, >>> >>> I'd like to ping you again on this one. What are your current plans on >> backporting https://bugs.openjdk.java.net/browse/JDK-8212200 and >> whatever needs to go with it? Ideally you still want to do it, but if not I'd >> appreciate if you could let us know. >>> Thanks a lot in advance >>> Christoph >>> >>> >>>> -----Original Message----- >>>> From: jdk-updates-dev >> On >>>> Behalf Of Ioi Lam >>>> Sent: Dienstag, 29. Januar 2019 01:33 >>>> To: jdk-updates-dev at openjdk.java.net >>>> Subject: Re: Backport of fix for CDS and JVM-TI agent crash ? >>>> >>>> There are CDS 3 bugs that I plan to backport to 11. I hope to post the >>>> requests this week. >>>> >>>> https://bugs.openjdk.java.net/issues/?filter=36209 >>>> >>>> Thanks >>>> >>>> - Ioi >>>> >>>> On 1/28/19 8:35 AM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> The fact a downport bug was opened does not matter, >>>>> you could still flag jdk11u-fix-request and just push it >>>>> if approved. This bug will then be closed as it is flagged 11-pool. >>>>> >>>>> More gentle it would be to ask Ioi what's going on ... >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>>> -----Original Message----- >>>>>> From: jdk-updates-dev > bounces at openjdk.java.net> >>>> On >>>>>> Behalf Of Volker Simonis >>>>>> Sent: Monday, January 28, 2019 5:02 PM >>>>>> To: Michael Rasmussen >>>>>> Cc: jdk-updates-dev at openjdk.java.net >>>>>> Subject: Re: Backport of fix for CDS and JVM-TI agent crash ? >>>>>> >>>>>> On Mon, Jan 28, 2019 at 4:17 PM Michael Rasmussen >>>>>> wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I was wondering if there are any plans to backport >>>>>> https://bugs.openjdk.java.net/browse/JDK-8212200 to jdk11u. >>>>>>> I can see https://bugs.openjdk.java.net/browse/JDK-8213164 has >> been >>>>>> created, but don't know if there are any active plans to actually do it? >>>>>> Hi Michael, >>>>>> >>>>>> I actually don't really understand what this means. Usually, you do a >>>>>> down-port by first requesting it on the original bug by applying a >>>>>> "jdku-fix-request" tag. Once the downport will be approved >>>>>> (by application of a "jdku-fix-yes" tag), the corresponding >>>>>> fix can be pushed to the updates repository. This push automatically >>>>>> triggers the creation of the corresponding backport issue in JBS. >>>>>> >>>>>> I don't know what it means for the downport process [1] if somebody >>>>>> (apparently manually) creates a backport issue like >>>>>> https://bugs.openjdk.java.net/browse/JDK-8213164 ? >>>>>> >>>>>> Regards, >>>>>> Volker >>>>>> >>>>>> [1] http://openjdk.java.net/projects/jdk-updates/approval.html >>>>>> >>>>>>> Kind regards >>>>>>> /Michael From christoph.langer at sap.com Wed Mar 20 08:02:12 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 20 Mar 2019 08:02:12 +0000 Subject: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux In-Reply-To: <70a875dc-3cdb-5dd8-9dfc-443c1c002713@redhat.com> References: <70a875dc-3cdb-5dd8-9dfc-443c1c002713@redhat.com> Message-ID: Hi Andrew, > Thanks. I get that, I'm just questioning the need to backport it to 11. > No matter, I've approved it now. What do you mean by that? The bug JDK-8220362 [0] still has jdk11u-fix-no. In case you approve JDK-8220362, I'll set the CSR (JDK-8220362 [1]) to finalized, referring to your approval. Thanks Christoph [0] https://bugs.openjdk.java.net/browse/JDK-8212828 [1] https://bugs.openjdk.java.net/browse/JDK-8220362 From thomas.stuefe at gmail.com Wed Mar 20 08:37:52 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 20 Mar 2019 09:37:52 +0100 Subject: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux In-Reply-To: References: Message-ID: On Tue, Mar 19, 2019 at 5:10 PM Martin Buchholz wrote: > I'm the one who introduced vfork for process spawning, and I support > Thomas' plan to switch to posix_spawn. > (although I have not seen a crash attributed to using vfork on Linux) > Thanks Martin. I think for a long time vfork was the best alternative. I remember seeing one or two cases in the last five years which could have been caused by vfork. In both cases, in a fork-heavy environment with many short-lived processes, a broken script killed the wrong pid - a just spawned child - and pid's father disappeared at the same time without a trace. Cheers, Thomas From aph at redhat.com Wed Mar 20 09:38:42 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 20 Mar 2019 09:38:42 +0000 Subject: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux In-Reply-To: References: <70a875dc-3cdb-5dd8-9dfc-443c1c002713@redhat.com> Message-ID: On 3/20/19 8:02 AM, Langer, Christoph wrote: > Hi Andrew, > >> Thanks. I get that, I'm just questioning the need to backport it to 11. >> No matter, I've approved it now. > > What do you mean by that? The bug JDK-8220362 [0] still has jdk11u-fix-no. No it doesn't. JDK-8212828 still had a jdk11u-fix-no, so I fixed that. -- 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 Mar 20 10:35:19 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 20 Mar 2019 10:35:19 +0000 Subject: [11u]: RFR CSR backport: JDK-8220362: Add "POSIX_SPAWN" as valid value to jdk.lang.Process.launchMechanism on Linux In-Reply-To: References: <70a875dc-3cdb-5dd8-9dfc-443c1c002713@redhat.com> Message-ID: > On 3/20/19 8:02 AM, Langer, Christoph wrote: > > Hi Andrew, > > > >> Thanks. I get that, I'm just questioning the need to backport it to 11. > >> No matter, I've approved it now. > > > > What do you mean by that? The bug JDK-8220362 [0] still has jdk11u-fix-no. > > No it doesn't. JDK-8212828 still had a jdk11u-fix-no, so I fixed that. Sorry, copy&paste error. I meant JDK-8212828, of course. Thanks for approving. I've set CSR JDK-8220362 to "Finalized" now. /Christoph From christoph.langer at sap.com Wed Mar 20 15:12:37 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 20 Mar 2019 15:12:37 +0000 Subject: [11u] Backport of fix for CDS and JVM-TI agent crash ? In-Reply-To: References: <2d9733c7-f629-1838-856e-dc06e908a20f@oracle.com> Message-ID: Hi Ioi, thanks again for the update. I'll take care of these backports then. Thanks Christoph > -----Original Message----- > From: Ioi Lam > Sent: Dienstag, 19. M?rz 2019 22:38 > To: Langer, Christoph > Cc: jdk-updates-dev at openjdk.java.net; Michael Rasmussen > > Subject: Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? > > The 3 issues that I wanted to backport were: > > Issue?????? BP-of?? Synopsis > JDK-8212991 8212205 VM asserts after CDS archive has been unmapped > JDK-8213273 8213250 CDS archive creation aborts due to metaspace object > allocation failure > JDK-8213164 8212200 assert(on_stack()) failed when shared > java.lang.object is redefined by JVMTI agent > > They are all backport issues related to CDS with (fixVersion = 11-pool). > Only the last one is related to JVMTI, but the other 2 are kind of > serious as well. But due to reassignment, I wasn't able to do the > backport :-( > > Thanks > - Ioi > > On 3/18/19 2:08 PM, Langer, Christoph wrote: > > Hi Ioi, > > > > ok, thanks for that information. > > > > Can you let us know, what exactly these 3 bugs were, that should be > backported? I guess it's about JDK-8212200, JDK-8213182 which fixes a build > failure after the former one. And what's the 3rd issue? > > > > Thanks > > Christoph > > > >> -----Original Message----- > >> From: Ioi Lam > >> Sent: Montag, 18. M?rz 2019 19:27 > >> To: Langer, Christoph > >> Cc: jdk-updates-dev at openjdk.java.net; Michael Rasmussen > >> > >> Subject: Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? > >> > >> Hi Christoph, I have been reassigned (and I've removed myself as the > >> assigned engineer for those bugs) so I think it's best for the openjdk > >> community to pick up these backports. > >> > >> Thanks > >> > >> - Ioi > >> > >> On 3/17/19 11:46 PM, Langer, Christoph wrote: > >>> Hi Ioi, > >>> > >>> I'd like to ping you again on this one. What are your current plans on > >> backporting https://bugs.openjdk.java.net/browse/JDK-8212200 and > >> whatever needs to go with it? Ideally you still want to do it, but if not I'd > >> appreciate if you could let us know. > >>> Thanks a lot in advance > >>> Christoph > >>> > >>> > >>>> -----Original Message----- > >>>> From: jdk-updates-dev bounces at openjdk.java.net> > >> On > >>>> Behalf Of Ioi Lam > >>>> Sent: Dienstag, 29. Januar 2019 01:33 > >>>> To: jdk-updates-dev at openjdk.java.net > >>>> Subject: Re: Backport of fix for CDS and JVM-TI agent crash ? > >>>> > >>>> There are CDS 3 bugs that I plan to backport to 11. I hope to post the > >>>> requests this week. > >>>> > >>>> https://bugs.openjdk.java.net/issues/?filter=36209 > >>>> > >>>> Thanks > >>>> > >>>> - Ioi > >>>> > >>>> On 1/28/19 8:35 AM, Lindenmaier, Goetz wrote: > >>>>> Hi, > >>>>> > >>>>> The fact a downport bug was opened does not matter, > >>>>> you could still flag jdk11u-fix-request and just push it > >>>>> if approved. This bug will then be closed as it is flagged 11-pool. > >>>>> > >>>>> More gentle it would be to ask Ioi what's going on ... > >>>>> > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: jdk-updates-dev >> bounces at openjdk.java.net> > >>>> On > >>>>>> Behalf Of Volker Simonis > >>>>>> Sent: Monday, January 28, 2019 5:02 PM > >>>>>> To: Michael Rasmussen > >>>>>> Cc: jdk-updates-dev at openjdk.java.net > >>>>>> Subject: Re: Backport of fix for CDS and JVM-TI agent crash ? > >>>>>> > >>>>>> On Mon, Jan 28, 2019 at 4:17 PM Michael Rasmussen > >>>>>> wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> I was wondering if there are any plans to backport > >>>>>> https://bugs.openjdk.java.net/browse/JDK-8212200 to jdk11u. > >>>>>>> I can see https://bugs.openjdk.java.net/browse/JDK-8213164 has > >> been > >>>>>> created, but don't know if there are any active plans to actually do it? > >>>>>> Hi Michael, > >>>>>> > >>>>>> I actually don't really understand what this means. Usually, you do a > >>>>>> down-port by first requesting it on the original bug by applying a > >>>>>> "jdku-fix-request" tag. Once the downport will be > approved > >>>>>> (by application of a "jdku-fix-yes" tag), the corresponding > >>>>>> fix can be pushed to the updates repository. This push automatically > >>>>>> triggers the creation of the corresponding backport issue in JBS. > >>>>>> > >>>>>> I don't know what it means for the downport process [1] if > somebody > >>>>>> (apparently manually) creates a backport issue like > >>>>>> https://bugs.openjdk.java.net/browse/JDK-8213164 ? > >>>>>> > >>>>>> Regards, > >>>>>> Volker > >>>>>> > >>>>>> [1] http://openjdk.java.net/projects/jdk-updates/approval.html > >>>>>> > >>>>>>> Kind regards > >>>>>>> /Michael From christoph.langer at sap.com Fri Mar 22 09:31:35 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 22 Mar 2019 09:31:35 +0000 Subject: RFR [11u] : 8221318: [11u] do not disable c99 on Solaris In-Reply-To: References: Message-ID: Hi Matthias, first of all: The change looks good to me, +1. I assume you have run it through our build/test infrastructure and see no regressions... As for the process: In your case, you want to backport a change and the original patch does not apply cleanly. For that scenario, you don't have to create a new bug (as JDK-8221318 in your case). You should just ask for review under the original bug id (JDK-8215710). When you have reviews and push approval, you need to push the change with the original patch message, referencing the original bug (JDK-8215710). The hgupdater daemon will then create a new backport bug and creates the according links. For your case, I've set fix version of JDK-8221318 to 11-pool. Then hgupdater will pick it up and resolve it for the right release. Maybe you ping me, when you're going to push, then we can check things together ?? Best regards Christoph > -----Original Message----- > From: build-dev On Behalf Of > Baesken, Matthias > Sent: Freitag, 22. M?rz 2019 09:50 > To: 'build-dev at openjdk.java.net' ; jdk- > updates-dev at openjdk.java.net > Subject: [CAUTION] RFR [11u] : 8221318: [11u] do not disable c99 on Solaris > > Hello, please review this change. > > It is a downport of jdk13 change > https://bugs.openjdk.java.net/browse/JDK-8215710 to 11u . > > JDK-8215710 removed the disabling of C99 on Solaris in jdk13. > Reason was : > "Currently we disable C99 in the Solaris build by setting -xc99=%none%. > This differs from a lot of other build environments like gcc/Linux or > VS2013/2017 on Windows where C99 features work. > We should remove this difference on Solaris and remove or replace the > setting. " > > > It would be helpful to have this downported to jdk11, because it would make > downporting changes easier (brings build settings of the releases closer > together) . > (I was already running into one issue because of the different build > settings ) > > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8221318 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8221318.0/ > > > Thanks, Matthias From goetz.lindenmaier at sap.com Fri Mar 22 10:08:00 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 22 Mar 2019 10:08:00 +0000 Subject: RFR [11u] : 8221318: [11u] do not disable c99 on Solaris In-Reply-To: References: Message-ID: Looks good to me, thanks for downporting. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Langer, Christoph > Sent: Freitag, 22. M?rz 2019 10:32 > To: Baesken, Matthias ; 'build- > dev at openjdk.java.net' ; jdk-updates- > dev at openjdk.java.net > Subject: [CAUTION] RE: RFR [11u] : 8221318: [11u] do not disable c99 on > Solaris > > Hi Matthias, > > first of all: The change looks good to me, +1. > I assume you have run it through our build/test infrastructure and see no > regressions... > > As for the process: > In your case, you want to backport a change and the original patch does not > apply cleanly. For that scenario, you don't have to create a new bug (as JDK- > 8221318 in your case). You should just ask for review under the original bug id > (JDK-8215710). When you have reviews and push approval, you need to push > the change with the original patch message, referencing the original bug (JDK- > 8215710). The hgupdater daemon will then create a new backport bug and > creates the according links. > > For your case, I've set fix version of JDK-8221318 to 11-pool. Then hgupdater > will pick it up and resolve it for the right release. Maybe you ping me, when > you're going to push, then we can check things together ?? > > Best regards > Christoph > > > -----Original Message----- > > From: build-dev On Behalf Of > > Baesken, Matthias > > Sent: Freitag, 22. M?rz 2019 09:50 > > To: 'build-dev at openjdk.java.net' ; jdk- > > updates-dev at openjdk.java.net > > Subject: [CAUTION] RFR [11u] : 8221318: [11u] do not disable c99 on Solaris > > > > Hello, please review this change. > > > > It is a downport of jdk13 change > > https://bugs.openjdk.java.net/browse/JDK-8215710 to 11u . > > > > JDK-8215710 removed the disabling of C99 on Solaris in jdk13. > > Reason was : > > "Currently we disable C99 in the Solaris build by setting -xc99=%none%. > > This differs from a lot of other build environments like gcc/Linux or > > VS2013/2017 on Windows where C99 features work. > > We should remove this difference on Solaris and remove or replace the > > setting. " > > > > > > It would be helpful to have this downported to jdk11, because it would make > > downporting changes easier (brings build settings of the releases closer > > together) . > > (I was already running into one issue because of the different build > > settings ) > > > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8221318 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8221318.0/ > > > > > > Thanks, Matthias From shade at redhat.com Fri Mar 22 15:42:43 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 22 Mar 2019 16:42:43 +0100 Subject: [12u] JDK-8218479 changeset? Message-ID: Look at this bug: https://bugs.openjdk.java.net/browse/JDK-8218479 JIRA mentions it has 12u backport that is "fixed in 12.0.2": https://bugs.openjdk.java.net/browse/JDK-8219134 Yet, there are *no* relevant changesets in jdk-updates/jdk12u: http://hg.openjdk.java.net/jdk-updates/jdk12u/log?rev=8218479 http://hg.openjdk.java.net/jdk-updates/jdk12u/log?rev=8219134 In fact, the backport applies well to jdk-updates/jdk12u and fixes the test! What gives? Rob, any ideas what happened here? There are other changesets like this. It seems that they are all in client-libs. -Aleksey From david.holmes at oracle.com Mon Mar 25 00:44:06 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Mar 2019 10:44:06 +1000 Subject: [12u] JDK-8218479 changeset? In-Reply-To: References: Message-ID: Hi Aleksey, On 23/03/2019 1:42 am, Aleksey Shipilev wrote: > Look at this bug: > https://bugs.openjdk.java.net/browse/JDK-8218479 > > JIRA mentions it has 12u backport that is "fixed in 12.0.2": > https://bugs.openjdk.java.net/browse/JDK-8219134 > > Yet, there are *no* relevant changesets in jdk-updates/jdk12u: > http://hg.openjdk.java.net/jdk-updates/jdk12u/log?rev=8218479 > http://hg.openjdk.java.net/jdk-updates/jdk12u/log?rev=8219134 That's now been fixed: http://hg.openjdk.java.net/jdk-updates/jdk12u/rev/b3572771e56a Have the others you saw? David ----- > In fact, the backport applies well to jdk-updates/jdk12u and fixes the test! What gives? > > Rob, any ideas what happened here? > > There are other changesets like this. It seems that they are all in client-libs. > > -Aleksey > From shade at redhat.com Mon Mar 25 08:34:13 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 25 Mar 2019 09:34:13 +0100 Subject: [12u] JDK-8218479 changeset? In-Reply-To: References: Message-ID: On 3/25/19 1:44 AM, David Holmes wrote: > On 23/03/2019 1:42 am, Aleksey Shipilev wrote: >> Look at this bug: >> ?? https://bugs.openjdk.java.net/browse/JDK-8218479 >> >> JIRA mentions it has 12u backport that is "fixed in 12.0.2": >> ?? https://bugs.openjdk.java.net/browse/JDK-8219134 >> >> Yet, there are *no* relevant changesets in jdk-updates/jdk12u: >> ?? http://hg.openjdk.java.net/jdk-updates/jdk12u/log?rev=8218479 >> ?? http://hg.openjdk.java.net/jdk-updates/jdk12u/log?rev=8219134 > > That's now been fixed: > > ?http://hg.openjdk.java.net/jdk-updates/jdk12u/rev/b3572771e56a Thanks! > Have the others you saw? These are also "missing" (have 12.0.2 in JBS, but no changesets): https://bugs.openjdk.java.net/browse/JDK-8218473 https://bugs.openjdk.java.net/browse/JDK-8218472 https://bugs.openjdk.java.net/browse/JDK-8218470 https://bugs.openjdk.java.net/browse/JDK-8218469 https://bugs.openjdk.java.net/browse/JDK-8203627 -Aleksey From rob.mckenna at oracle.com Mon Mar 25 15:50:23 2019 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 25 Mar 2019 15:50:23 +0000 Subject: [12u] JDK-8218479 changeset? In-Reply-To: References: Message-ID: <20190325155023.GA7638@vimes> This appears to be a case of engineers not following the correct process. Thanks for bringing it to our attention, these fixes should also be on their way to the open repo. -Rob On 25/03/19 09:34, Aleksey Shipilev wrote: > On 3/25/19 1:44 AM, David Holmes wrote: > > On 23/03/2019 1:42 am, Aleksey Shipilev wrote: > >> Look at this bug: > >> ?? https://bugs.openjdk.java.net/browse/JDK-8218479 > >> > >> JIRA mentions it has 12u backport that is "fixed in 12.0.2": > >> ?? https://bugs.openjdk.java.net/browse/JDK-8219134 > >> > >> Yet, there are *no* relevant changesets in jdk-updates/jdk12u: > >> ?? http://hg.openjdk.java.net/jdk-updates/jdk12u/log?rev=8218479 > >> ?? http://hg.openjdk.java.net/jdk-updates/jdk12u/log?rev=8219134 > > > > That's now been fixed: > > > > ?http://hg.openjdk.java.net/jdk-updates/jdk12u/rev/b3572771e56a > > Thanks! > > > Have the others you saw? > > These are also "missing" (have 12.0.2 in JBS, but no changesets): > https://bugs.openjdk.java.net/browse/JDK-8218473 > https://bugs.openjdk.java.net/browse/JDK-8218472 > https://bugs.openjdk.java.net/browse/JDK-8218470 > https://bugs.openjdk.java.net/browse/JDK-8218469 > https://bugs.openjdk.java.net/browse/JDK-8203627 > > -Aleksey > From aoqi at loongson.cn Wed Mar 27 10:00:10 2019 From: aoqi at loongson.cn (Ao Qi) Date: Wed, 27 Mar 2019 18:00:10 +0800 Subject: RFR: [11u, 12u] JDK-8170639: [Linux] jsig is limited to a maximum of 64 signals Message-ID: Hi, I'd like to backport this change to 11u and 12u: Original JBS: https://bugs.openjdk.java.net/browse/JDK-8170639 Original change: http://hg.openjdk.java.net/jdk/jdk/rev/3086f9259e97 (http://cr.openjdk.java.net/~aoqi/8170639/webrev.03/) Original review threads: https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-December/031839.html https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2019-March/032909.html Patch does not apply cleanly, because of minor changes in os::Posix::init_2(void) introduced by JDK-8194860. 12u change: http://cr.openjdk.java.net/~aoqi/8170639/webrev.12u.03/ Tested: linux-x86_64-{server, minimal, zero}-{release, fastdebug} build, solaris-x86_64-server-release build, linux-mips64el-zero-release build, linux-x86_64-server-release tier1 May I also request to backport this fix to 11u? http://cr.openjdk.java.net/~aoqi/8170639/webrev.12u.03 apply to jdk11u-dev cleanly. jdk11u-dev tested: linux-x86_64-{server, minimal, zero}-{release, fastdebug} build, solaris-x86_64-server-release build, linux-x86_64-server-release tier1 Thanks, Ao Qi From ali.ince at gmail.com Thu Mar 28 00:06:04 2019 From: ali.ince at gmail.com (Ali Ince) Date: Thu, 28 Mar 2019 00:06:04 +0000 Subject: [PATCH] [8u] Prevent MSDOS8.3 named DLL in built image Message-ID: 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 david.holmes at oracle.com Thu Mar 28 01:35:04 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 Mar 2019 11:35:04 +1000 Subject: [PATCH] [8u] Prevent MSDOS8.3 named DLL in built image In-Reply-To: References: Message-ID: <1d0d97fb-664f-b63a-841b-b25b87e694dc@oracle.com> Hi Ali, Please take this to jdk8u-dev at openjdk.java.net as 8u is not part of the jdk-updates project. Thanks, David On 28/03/2019 10:06 am, Ali Ince wrote: > 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 ali.ince at gmail.com Thu Mar 28 08:16:19 2019 From: ali.ince at gmail.com (Ali Ince) Date: Thu, 28 Mar 2019 08:16:19 +0000 Subject: [PATCH] [8u] Prevent MSDOS8.3 named DLL in built image In-Reply-To: <1d0d97fb-664f-b63a-841b-b25b87e694dc@oracle.com> References: <1d0d97fb-664f-b63a-841b-b25b87e694dc@oracle.com> Message-ID: <38E575B3-C7C6-45FB-B6CC-37D572C2745D@gmail.com> Thanks David, sorry for the noise. > On 28 Mar 2019, at 01:35, David Holmes wrote: > > Hi Ali, > > Please take this to jdk8u-dev at openjdk.java.net as 8u is not part of the jdk-updates project. > > Thanks, > David > > On 28/03/2019 10:06 am, Ali Ince wrote: >> 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 Thu Mar 28 23:33:32 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 28 Mar 2019 23:33:32 +0000 Subject: Tag a build in jdk8u and merge to jdk8u-dev? In-Reply-To: References: <21132b75-090b-ad6c-6c7b-1349a1488bde@redhat.com> Message-ID: On 28/03/2019 11:37, Langer, Christoph wrote: > Hi Andrew, > >>> I was wondering, whether we want to tag a new build in jdk8u and merge >>> back to jdk8u-dev, similar as Goetz is doing with jdk11u? >>> >>> >>> >>> JDK-8193764 and JDK-8220641 have been pushed to jdk8u and JDK-8189761 >> is >>> approved but I don't see a review thread... Do we maybe want to wait for >>> JDK-8189761? What's the outlook for that one? >>> >>> >> >> As you'll have seen, 8189761 was posted a few hours after your e-mail. >> My thinking was that we'd tag -b02 once these three pending ones were in. >> >> Given it's the 1st on Monday, I'd expect that to be the freeze point. I >> don't see any other critical fixes waiting for approval. There is a >> further update coming from Oracle with the final Japanese epoch, I >> believe, but I can bring that in with the security fixes if need be. > > Sounds fair. > > So, when I see that 8189761 has landed on or after next Monday, the 1st of April, shall I do tag -b02 and communicate the freeze? Or do you want to do it this time? > > Best regards > Christoph > I'll let you keep doing the tagging. I'll announce a freeze separately for both 8u and 11u on the 1st. Does that sound ok? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From goetz.lindenmaier at sap.com Fri Mar 29 06:40:26 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 29 Mar 2019 06:40:26 +0000 Subject: Tag a build in jdk8u and merge to jdk8u-dev? In-Reply-To: References: <21132b75-090b-ad6c-6c7b-1349a1488bde@redhat.com> Message-ID: Hi Andrew, > I'll announce a freeze separately for both 8u and 11u on the 1st. I would prefer to fix a tag, not a date. So I would propose to either state that you freeze on the existing tag jdk-11.0.3+5, or you announce on the 1st that you will freeze on tag jdk-11.0.3+6 which I will push on the 3rd. I think that the second is better because you announce in advance what you will freeze -- if the 3rd is still in time for you. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Andrew John Hughes > Sent: Friday, March 29, 2019 12:34 AM > To: Langer, Christoph ; jdk8u- > dev at openjdk.java.net; 'jdk-updates-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: Re: Tag a build in jdk8u and merge to jdk8u-dev? > > > > On 28/03/2019 11:37, Langer, Christoph wrote: > > Hi Andrew, > > > >>> I was wondering, whether we want to tag a new build in jdk8u and > merge > >>> back to jdk8u-dev, similar as Goetz is doing with jdk11u? > >>> > >>> > >>> > >>> JDK-8193764 and JDK-8220641 have been pushed to jdk8u and JDK- > 8189761 > >> is > >>> approved but I don't see a review thread... Do we maybe want to wait > for > >>> JDK-8189761? What's the outlook for that one? > >>> > >>> > >> > >> As you'll have seen, 8189761 was posted a few hours after your e-mail. > >> My thinking was that we'd tag -b02 once these three pending ones were > in. > >> > >> Given it's the 1st on Monday, I'd expect that to be the freeze point. I > >> don't see any other critical fixes waiting for approval. There is a > >> further update coming from Oracle with the final Japanese epoch, I > >> believe, but I can bring that in with the security fixes if need be. > > > > Sounds fair. > > > > So, when I see that 8189761 has landed on or after next Monday, the 1st of > April, shall I do tag -b02 and communicate the freeze? Or do you want to do it > this time? > > > > Best regards > > Christoph > > > > I'll let you keep doing the tagging. > > I'll announce a freeze separately for both 8u and 11u on the 1st. > > Does that sound ok? > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew From zanglin5 at jd.com Fri Mar 29 07:02:40 2019 From: zanglin5 at jd.com (=?gb2312?B?6rDB1Q==?=) Date: Fri, 29 Mar 2019 07:02:40 +0000 Subject: backport JEP 344-Abortable Mixed Collections for G1 to jdk11u References: Message-ID: Dear All This is CCed from hotspot-gc-dev. I am planing to port JEP344 back to JDK11u, it helps me to reduce the long pause MixedGC as discussed. What is your opinion? BRs, Lin > > > Dear Thomas and Charlie, > Thanks for your suggestions. > Let me describe more about my experiment. I am trying JDK11 on some sort of server node with huge heap at ~400GB. And it needs to keep the responsiveness so that long pause time of GC is not acceptable. > And for some reason, if the server node paused for a long time (say 60s), the whole process will be killed and hence cause disaster. > With JDK11 using G1? after some measurement I believe that keep MaxGCPauseMills at 200ms is reasonable and works well when there is no MixedGC - And also want to mention that the server node is super busy at allocation so there are usually 2~3 YGCs per minute. > The problems comes with Mixed GC, I observed mainly two issues about it: > a. There is super long pause time for MixedGC. Some times I found the whole process is killed because the MixedGC paused over 60s. > b. There is back-to-back long MixedGCs, for examples, there can be 2~3 mixedGC within one minutes, and every one of them tooks ~30s. so the process get killed. > For issue a, I think it seems that the collection set may be too large to be collected in low pause times. So I have tried to enlarge XX:G1MixedGCCountTarget to reduce the CSet for every MixedGC. But it seems this option could introduce more MixedGCs overall, which affected more or less of latency when normal MixedGCs happened. (Usually there is a batch of mixedGCs after concurrent marking, and seems the count of mixedGCs in a batch grows by enlarging XX:G1MixedGCCountTarget ), and this may cause issue b more severe. > I also tried the option of -XX:G1HeapWastePercent, and it could more or less help reduce the MixedGC pause, but it shows if I enlarge it too much , more MixedGCs are going to happened. > > I come to consider that those options are good but they takes effect to all mixedGC?s, even for the cases that MixedGC pause time are acceptable.I tried to find a way to control the Cset by pause times, and I found the JEP344, after trying it in my case the long pause mixedGC is reduced by only introducing more low pause mixedGCs in that specific batch. > > PS. for the issue b mentioned, I think JEP344 may not help a lot. My data shown it comes from the updateRS&scanRS time, the tuning guide mentioned that so I will try it. > And thanks for guiding me, I also cc this thread to jdk-updates-dev. > > > BRs, > Lin > > >> ? 2019?3?29????3:31?Thomas Schatzl ??? >> >> Hi Lin, >> >> On Wed, 2019-03-27 at 10:51 +0000, ?? wrote: >>> Dear All, >>> I have tried the JEP344 for a while and find it could help us to >>> avoid the long Mixed GCs when the heap is large. >> >> It is great to hear that it helps you in your case. >> >> I assume you tried some tuning with the options presented in the >> documentation at >> https://docs.oracle.com/en/java/javase/12/gctuning/garbage-first-garbage-collector-tuning.html#GUID-D2B6ADCE-6766-4FF8-AA9D-B7F4F3D0F469 >> ? >> >> Note that in some cases this still might not result in as nice behavior >> as with abortable mixed gc. >> >>> So I am planning to port it back to jdk11u as G1 is the default >>> GC, do you think it is reasonable? >> >> I believe it is okay if it is useful, but it is best to ask the >> maintainers of jdk11u directly in on the jdk-updates-dev mailing list. >> As this would be a bit bigger change/backport, so there might be some >> further concerns by the jdk11u maintainers. >> >> Code review seems to have to occur on the jdk-updates-dev mailing list >> (https://openjdk.java.net/projects/jdk-updates/codereview.html) - maybe >> cc hotspot-gc-dev though. >> >> Thanks, >> Thomas >> >> > > From christoph.langer at sap.com Fri Mar 29 08:50:53 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 29 Mar 2019 08:50:53 +0000 Subject: Tag a build in jdk8u and merge to jdk8u-dev? In-Reply-To: References: <21132b75-090b-ad6c-6c7b-1349a1488bde@redhat.com> Message-ID: Hi Andrew, > I'll let you keep doing the tagging. > > I'll announce a freeze separately for both 8u and 11u on the 1st. > > Does that sound ok? Sounds fine for the tagging. I agree to Goetz' point about announcing the freeze on a tag. So when we've done the tagging in both, jdk11u and jdk8u next week I guess this would be a good candidate for the freeze point. Best regards Christoph From shade at redhat.com Fri Mar 29 09:05:49 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 29 Mar 2019 10:05:49 +0100 Subject: backport JEP 344-Abortable Mixed Collections for G1 to jdk11u In-Reply-To: References: Message-ID: On 3/29/19 8:02 AM, ?? wrote: > This is CCed from hotspot-gc-dev. > I am planing to port JEP344 back to JDK11u, it helps me to reduce the long pause MixedGC as discussed. > What is your opinion? My immediate opinion is that the change is large, and probably too risky to backport for the GC enabled by default: http://hg.openjdk.java.net/jdk/jdk/rev/495c05ee2a9a For surviving large heaps, you can use Shenandoah or ZGC. -Aleksey From thomas.schatzl at oracle.com Fri Mar 29 10:19:33 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 29 Mar 2019 11:19:33 +0100 Subject: backport JEP 344-Abortable Mixed Collections for G1 to jdk11u In-Reply-To: References: <5488585513d74042af4ff3c9cb64d0b1@jd.com> <1d24e2b21cc12cbad28a987dc90be91089199923.camel@oracle.com> Message-ID: Hi, On Fri, 2019-03-29 at 06:38 +0000, ?? wrote: > Dear Thomas and Charlie, > > Thanks for your suggestions. > Let me describe more about my experiment. I am trying JDK11 on > some sort of server node with huge heap at ~400GB. And it needs to > keep the responsiveness so that long pause time of GC is not > acceptable. > And for some reason, if the server node paused for a long time > (say 60s), the whole process will be killed and hence cause > disaster. > With JDK11 using G1? after some measurement I believe that keep > MaxGCPauseMills at 200ms is reasonable and works well when there is > no MixedGC - And also want to mention that the server node is super > busy at allocation so there are usually 2~3 YGCs per minute. It would be really interesting to get a log file with both a few of the "good" and the "bad" cases with -Xlog:gc=debug,gc+start=debug,gc+heap=debug,gc+phases=debug,gc+ergo+cse t=trace logging output (and showing other VM options). This would help us to gauge live set size and allocation rates. Depending on these, both Shenandoah and ZGC might be an alternative, and/or other tunings. I suspect that for example, with such a large heap you will get remembered set coarsenings as described in the "High Update RS and Scan RS Times" in the tuning guide (see also there for how to diagnose them, but please read the gotcha for diagnosing this in production - via jcmd you could just add that logging temporarily though). If you can see those, I would try "-XX:G1RSetRegionEntries=30000" to remove the coarsenings and "-XX:G1RSetSparseRegionEntries=256" to fix remembered set memory consumption; I kind of recommend doing the latter anyway. There are also ways to decrease minimum pause time by bounding young generation size a bit (-XX:+MaxNewSize), but without logs that's just too much guessing. > The problems comes with Mixed GC, I observed mainly two issues > about it: > a. There is super long pause time for MixedGC. Some times > I found the whole process is killed because the MixedGC paused over > 60s. > b. There is back-to-back long MixedGCs, for examples, there > can be 2~3 mixedGC within one minutes, and every one of them tooks > ~30s. so the process get killed. > For issue a, I think it seems that the collection set may be too > large to be collected in low pause times. So I have tried to enlarge > XX:G1MixedGCCountTarget to reduce the CSet for every MixedGC. But it > seems this option could introduce more MixedGCs overall, which That's natural. During mixed phase G1 minimizes the young gen size (to allowed of course) which determines the frequency of collections. If you have a huge allocation rate, you burn through the available memory until next GC very quickly. They shouldn't take 30s though :) I suspect above remembered set coarsening to be the main cause here. > affected more or less of latency when normal MixedGCs happened. > (Usually there is a batch of mixedGCs after concurrent marking, and > seems the count of mixedGCs in a batch grows by enlarging > XX:G1MixedGCCountTarget ), and this may cause issue b more severe. Do not set G1MixedGCCountTarget too high. > I also tried the option of -XX:G1HeapWastePercent, and it could > more or less help reduce the MixedGC pause, but it shows if I enlarge > it too much , more MixedGCs are going to happened. That's natural too. The default settings for many of these options are geared for somewhat smaller applications as you may have noticed. We do not have many "real-world" applications of that size for developing better auto- tuning, apart from being a bit short in available time. Help in that area is always appreciated though :) > I come to consider that those options are good but they takes > effect to all mixedGC?s, even for the cases that MixedGC pause time > are acceptable.I tried to find a way to control the Cset by pause > times, and I found the JEP344, after trying it in my case the long > pause mixedGC is reduced by only introducing more low pause mixedGCs > in that specific batch. Within a given pause time there can only be so much object copying that can fit into. We are constantly trying to push these boundaries, e.g. from internal testing of a JDK-8213108 prototype you will likely be very positively surprised sometime in the future, but if your design is based on evacuation in distinct pauses, there is a point where the amount of data to be copied is just too large to fit a reasonable time; I do not know whether this is the case here. > PS. for the issue b mentioned, I think JEP344 may not help a > lot. My data shown it comes from the updateRS&scanRS time, the tuning > guide mentioned that so I will try it. > And thanks for guiding me, I also cc this thread to jdk-updates- > dev. Thanks, Thomas From zanglin5 at jd.com Fri Mar 29 11:02:07 2019 From: zanglin5 at jd.com (=?gb2312?B?6rDB1Q==?=) Date: Fri, 29 Mar 2019 11:02:07 +0000 Subject: backport JEP 344-Abortable Mixed Collections for G1 to jdk11u In-Reply-To: References: <5488585513d74042af4ff3c9cb64d0b1@jd.com> <1d24e2b21cc12cbad28a987dc90be91089199923.camel@oracle.com> Message-ID: <591A8421-6DED-4573-B19A-97AF483465D3@jd.com> Dear Thomas? Thanks for your suggestion? I will try to get those logs but that may take several days. And I will try ZGC and Shenandoah too. I may ask help with more data in future :) Another possibility I can see is to enlarge the 32MB limitation of region size, after searching the code I think it may also possible to have (maybe 64MB) large regions for large heap with some code change. So that the cross region reference became possibly smaller. And seems enlarge the region to 64MB may a little memory overhead in the sparse PRT, What do you think? BRs, Lin ? 2019?3?29????6:19?Thomas Schatzl > ??? Hi, On Fri, 2019-03-29 at 06:38 +0000, ?? wrote: Dear Thomas and Charlie, Thanks for your suggestions. Let me describe more about my experiment. I am trying JDK11 on some sort of server node with huge heap at ~400GB. And it needs to keep the responsiveness so that long pause time of GC is not acceptable. And for some reason, if the server node paused for a long time (say 60s), the whole process will be killed and hence cause disaster. With JDK11 using G1? after some measurement I believe that keep MaxGCPauseMills at 200ms is reasonable and works well when there is no MixedGC - And also want to mention that the server node is super busy at allocation so there are usually 2~3 YGCs per minute. It would be really interesting to get a log file with both a few of the "good" and the "bad" cases with -Xlog:gc=debug,gc+start=debug,gc+heap=debug,gc+phases=debug,gc+ergo+cse t=trace logging output (and showing other VM options). This would help us to gauge live set size and allocation rates. Depending on these, both Shenandoah and ZGC might be an alternative, and/or other tunings. I suspect that for example, with such a large heap you will get remembered set coarsenings as described in the "High Update RS and Scan RS Times" in the tuning guide (see also there for how to diagnose them, but please read the gotcha for diagnosing this in production - via jcmd you could just add that logging temporarily though). If you can see those, I would try "-XX:G1RSetRegionEntries=30000" to remove the coarsenings and "-XX:G1RSetSparseRegionEntries=256" to fix remembered set memory consumption; I kind of recommend doing the latter anyway. There are also ways to decrease minimum pause time by bounding young generation size a bit (-XX:+MaxNewSize), but without logs that's just too much guessing. The problems comes with Mixed GC, I observed mainly two issues about it: a. There is super long pause time for MixedGC. Some times I found the whole process is killed because the MixedGC paused over 60s. b. There is back-to-back long MixedGCs, for examples, there can be 2~3 mixedGC within one minutes, and every one of them tooks ~30s. so the process get killed. For issue a, I think it seems that the collection set may be too large to be collected in low pause times. So I have tried to enlarge XX:G1MixedGCCountTarget to reduce the CSet for every MixedGC. But it seems this option could introduce more MixedGCs overall, which That's natural. During mixed phase G1 minimizes the young gen size (to allowed of course) which determines the frequency of collections. If you have a huge allocation rate, you burn through the available memory until next GC very quickly. They shouldn't take 30s though :) I suspect above remembered set coarsening to be the main cause here. affected more or less of latency when normal MixedGCs happened. (Usually there is a batch of mixedGCs after concurrent marking, and seems the count of mixedGCs in a batch grows by enlarging XX:G1MixedGCCountTarget ), and this may cause issue b more severe. Do not set G1MixedGCCountTarget too high. I also tried the option of -XX:G1HeapWastePercent, and it could more or less help reduce the MixedGC pause, but it shows if I enlarge it too much , more MixedGCs are going to happened. That's natural too. The default settings for many of these options are geared for somewhat smaller applications as you may have noticed. We do not have many "real-world" applications of that size for developing better auto- tuning, apart from being a bit short in available time. Help in that area is always appreciated though :) I come to consider that those options are good but they takes effect to all mixedGC?s, even for the cases that MixedGC pause time are acceptable.I tried to find a way to control the Cset by pause times, and I found the JEP344, after trying it in my case the long pause mixedGC is reduced by only introducing more low pause mixedGCs in that specific batch. Within a given pause time there can only be so much object copying that can fit into. We are constantly trying to push these boundaries, e.g. from internal testing of a JDK-8213108 prototype you will likely be very positively surprised sometime in the future, but if your design is based on evacuation in distinct pauses, there is a point where the amount of data to be copied is just too large to fit a reasonable time; I do not know whether this is the case here. PS. for the issue b mentioned, I think JEP344 may not help a lot. My data shown it comes from the updateRS&scanRS time, the tuning guide mentioned that so I will try it. And thanks for guiding me, I also cc this thread to jdk-updates- dev. Thanks, Thomas From christoph.langer at sap.com Fri Mar 29 13:18:35 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 29 Mar 2019 13:18:35 +0000 Subject: jdk11u - getting ready for 11.0.3 freeze Message-ID: Hi Andrew, there are currently 3 open issues for jdk11u-critical approval [0]. I'd like to ask you to have a look at these in order to get them in prior to the (probably) last tag before freezing next week. Thank you Christoph [0] https://bugs.openjdk.java.net/browse/JDK-8221483?filter=36559 From gnu.andrew at redhat.com Fri Mar 29 14:15:52 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 29 Mar 2019 14:15:52 +0000 Subject: Tag a build in jdk8u and merge to jdk8u-dev? In-Reply-To: References: <21132b75-090b-ad6c-6c7b-1349a1488bde@redhat.com> Message-ID: <2f3ea620-a537-c10e-beec-772fe97e6890@redhat.com> On 29/03/2019 06:40, Lindenmaier, Goetz wrote: > Hi Andrew, > >> I'll announce a freeze separately for both 8u and 11u on the 1st. > > I would prefer to fix a tag, not a date. > > So I would propose to either state that you freeze on the existing > tag jdk-11.0.3+5, or you announce on the 1st that you will > freeze on tag jdk-11.0.3+6 which I will push on the 3rd. > > I think that the second is better because you announce in advance > what you will freeze -- if the 3rd is still in time for you. > > Best regards, > Goetz. > > My intent was a combination of both i.e. that the 1st is the deadline for changes and, at that time, I announce a freeze on a tag. In the event that there are changes after that tag, we can decide whether to re-tag to include them or they have to wait until the next release. But the idea of stating the deadline early is that there should ideally not be such changes. 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 Fri Mar 29 15:00:14 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 29 Mar 2019 15:00:14 +0000 Subject: Handling Backport Changesets Message-ID: 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, -- 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 volker.simonis at gmail.com Fri Mar 29 16:49:10 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 29 Mar 2019 17:49:10 +0100 Subject: Handling Backport Changesets In-Reply-To: References: Message-ID: Good idea! >From my naive understanding, this is merely a question of changing "jcheck" in such a way that it allows these sort of extra comments. As project owner you can disable "jcheck" altogether, in which case we could start using the new comments right away. I'd nevertheless vote for keeping "jcheck" but extend it to allow the new format. Regards, Volker On Fri, Mar 29, 2019 at 4:00 PM 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, > -- > 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 Mar 29 18:36:39 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 29 Mar 2019 18:36:39 +0000 Subject: Handling Backport Changesets In-Reply-To: References: Message-ID: <6e4e8d2d-8b96-676e-ca16-38666d421a5c@redhat.com> On 29/03/2019 16:49, Volker Simonis wrote: > Good idea! > > From my naive understanding, this is merely a question of changing > "jcheck" in such a way that it allows these sort of extra comments. As > project owner you can disable "jcheck" altogether, in which case we > could start using the new comments right away. I'd nevertheless vote > for keeping "jcheck" but extend it to allow the new format. > > Regards, > Volker > Well, I'm not project owner; that would be aph :) (TooManyAndrewsException) jcheck catches quite a lot of stuff, much as it annoys me sometimes, so I prefer to keep it enabled if possible. Also, this proposal would apply to Oracle-maintained repositories as well (e.g. jdk12). -- 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 Mar 29 22:02:13 2019 From: gil at azul.com (Gil Tene) Date: Fri, 29 Mar 2019 22:02:13 +0000 Subject: Coordinating the build number for 11.0.3 Message-ID: <115CADB7-03AE-4DC4-AFAB-C70047D7CCF8@azul.com> As we approach the April update and the release of 11.0.3 by the JDK11u project, I'd like to suggest a coordination of the eventual build number that we expect to use for the actual released build in the project (after integration of security fixes that are being worked on in the dark). Since the build number is a part of the versions string per JEP 322, and since this is the most specific part of the version string that is common across the various binary distributions (e.g. Azul Zulu, AdoptOpenJDK, Corretto, Liberica, Red Hat, etc.), it is useful for us all to use the same build number when we release the first build of a new update of 11u. This has been the practice in the past. E.g. for 11.0.2, we all aligned on the same "build 11.0.2+9" in the version string. Since the update itself is time sensitive, and it is useful to commence testing ahead of time, knowing the build number to use in the builds we test would be helpful in getting the builds ready to go ASAP once the release is finalized. So, I propose that we pre-choose a build number for the anticipated April release of 11.0.3. I have no strong opinions on what that number should be. It should probably not overlap with past or current builds of 11.0.3 in 11u, and "leaving room" (a gap of a few integer spaces between the current build numbers and the anticipated one) is probably a good idea. ? Gil. From gnu.andrew at redhat.com Sat Mar 30 02:18:50 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Sat, 30 Mar 2019 02:18:50 +0000 Subject: Coordinating the build number for 11.0.3 In-Reply-To: <115CADB7-03AE-4DC4-AFAB-C70047D7CCF8@azul.com> References: <115CADB7-03AE-4DC4-AFAB-C70047D7CCF8@azul.com> Message-ID: On 29/03/2019 22:02, Gil Tene wrote: > As we approach the April update and the release of 11.0.3 by the > JDK11u project, I'd like to suggest a coordination of the eventual > build number that we expect to use for the actual released build in > the project (after integration of security fixes that are being worked > on in the dark). > > Since the build number is a part of the versions string per JEP 322, > and since this is the most specific part of the version string that is > common across the various binary distributions (e.g. > Azul Zulu, AdoptOpenJDK, Corretto, Liberica, Red Hat, etc.), it > is useful for us all to use the same build number when we release > the first build of a new update of 11u. This has been the practice in > the past. E.g. for 11.0.2, we all aligned on the same "build 11.0.2+9" > in the version string. > > Since the update itself is time sensitive, and it is useful to commence > testing ahead of time, knowing the build number to use in the builds > we test would be helpful in getting the builds ready to go ASAP once > the release is finalized. > > So, I propose that we pre-choose a build number for the anticipated > April release of 11.0.3. I have no strong opinions on what that number > should be. It should probably not overlap with past or current builds of > 11.0.3 in 11u, and "leaving room" (a gap of a few integer spaces > between the current build numbers and the anticipated one) is probably > a good idea. > > ? Gil. > Well, it's already at 5: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/dd4470fa81fe So I would expect the CPU additions to make it 6, but it may have to go higher if issues arise. -- 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 Sat Mar 30 19:54:48 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Sat, 30 Mar 2019 19:54:48 +0000 Subject: Coordinating the build number for 11.0.3 In-Reply-To: References: <115CADB7-03AE-4DC4-AFAB-C70047D7CCF8@azul.com> Message-ID: Hi Gil, Andrew, I don't really like the idea to define the exact build number beforehand with leap space for additional builds. However, I can see that it would be helpful for distributions that want to release a binary right at the release day without waiting for the public release of the CPU changes, then picking them up, merging, triggering builds and do regression testing. Doing so will obviously delay the availability of the binaries and incurs some uncalculatable risk regarding merging and regressions. So, maybe we can agree that the final build number will always be the publicly visible build number + 1. Andrew, not knowing your exact processes regarding the handling of CPU changes, would you think you'd be able to commit to that? Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Andrew John Hughes > Sent: Samstag, 30. M?rz 2019 03:19 > To: jdk-updates-dev at openjdk.java.net > Subject: Re: Coordinating the build number for 11.0.3 > > > > On 29/03/2019 22:02, Gil Tene wrote: > > As we approach the April update and the release of 11.0.3 by the > > JDK11u project, I'd like to suggest a coordination of the eventual > > build number that we expect to use for the actual released build in > > the project (after integration of security fixes that are being worked > > on in the dark). > > > > Since the build number is a part of the versions string per JEP 322, > > and since this is the most specific part of the version string that is > > common across the various binary distributions (e.g. > > Azul Zulu, AdoptOpenJDK, Corretto, Liberica, Red Hat, etc.), it > > is useful for us all to use the same build number when we release > > the first build of a new update of 11u. This has been the practice in > > the past. E.g. for 11.0.2, we all aligned on the same "build 11.0.2+9" > > in the version string. > > > > Since the update itself is time sensitive, and it is useful to commence > > testing ahead of time, knowing the build number to use in the builds > > we test would be helpful in getting the builds ready to go ASAP once > > the release is finalized. > > > > So, I propose that we pre-choose a build number for the anticipated > > April release of 11.0.3. I have no strong opinions on what that number > > should be. It should probably not overlap with past or current builds of > > 11.0.3 in 11u, and "leaving room" (a gap of a few integer spaces > > between the current build numbers and the anticipated one) is probably > > a good idea. > > > > ? Gil. > > > > Well, it's already at 5: > > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/dd4470fa81fe > > So I would expect the CPU additions to make it 6, but it may have to go > higher if issues arise. > -- > 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 Fri Mar 22 08:50:47 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 22 Mar 2019 08:50:47 -0000 Subject: RFR [11u] : 8221318: [11u] do not disable c99 on Solaris Message-ID: Hello, please review this change. It is a downport of jdk13 change https://bugs.openjdk.java.net/browse/JDK-8215710 to 11u . JDK-8215710 removed the disabling of C99 on Solaris in jdk13. Reason was : "Currently we disable C99 in the Solaris build by setting -xc99=%none%. This differs from a lot of other build environments like gcc/Linux or VS2013/2017 on Windows where C99 features work. We should remove this difference on Solaris and remove or replace the setting. " It would be helpful to have this downported to jdk11, because it would make downporting changes easier (brings build settings of the releases closer together) . (I was already running into one issue because of the different build settings ) Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8221318 http://cr.openjdk.java.net/~mbaesken/webrevs/8221318.0/ Thanks, Matthias From matthias.baesken at sap.com Fri Mar 22 10:04:37 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 22 Mar 2019 10:04:37 -0000 Subject: RFR [11u] : 8221318: [11u] do not disable c99 on Solaris In-Reply-To: References: Message-ID: > I assume you have run it through our build/test infrastructure and see no > regressions... Yes it is in our build+test queue for jdk11u-dev . > For your case, I've set fix version of JDK-8221318 to 11-pool. Then hgupdater > will pick it up and resolve it for the right release. Maybe you ping me, when > you're going to push, then we can check things together Sure, good idea . Best regards, Matthias > -----Original Message----- > From: Langer, Christoph > Sent: Freitag, 22. M?rz 2019 10:32 > To: Baesken, Matthias ; 'build- > dev at openjdk.java.net' ; jdk-updates- > dev at openjdk.java.net > Subject: RE: RFR [11u] : 8221318: [11u] do not disable c99 on Solaris > > Hi Matthias, > > first of all: The change looks good to me, +1. > I assume you have run it through our build/test infrastructure and see no > regressions... > > As for the process: > In your case, you want to backport a change and the original patch does not > apply cleanly. For that scenario, you don't have to create a new bug (as JDK- > 8221318 in your case). You should just ask for review under the original bug id > (JDK-8215710). When you have reviews and push approval, you need to push > the change with the original patch message, referencing the original bug > (JDK-8215710). The hgupdater daemon will then create a new backport bug > and creates the according links. > > For your case, I've set fix version of JDK-8221318 to 11-pool. Then hgupdater > will pick it up and resolve it for the right release. Maybe you ping me, when > you're going to push, then we can check things together ?? > > Best regards > Christoph > > > -----Original Message----- > > From: build-dev On Behalf Of > > Baesken, Matthias > > Sent: Freitag, 22. M?rz 2019 09:50 > > To: 'build-dev at openjdk.java.net' ; jdk- > > updates-dev at openjdk.java.net > > Subject: [CAUTION] RFR [11u] : 8221318: [11u] do not disable c99 on Solaris > > > > Hello, please review this change. > > > > It is a downport of jdk13 change > > https://bugs.openjdk.java.net/browse/JDK-8215710 to 11u . > > > > JDK-8215710 removed the disabling of C99 on Solaris in jdk13. > > Reason was : > > "Currently we disable C99 in the Solaris build by setting -xc99=%none%. > > This differs from a lot of other build environments like gcc/Linux or > > VS2013/2017 on Windows where C99 features work. > > We should remove this difference on Solaris and remove or replace the > > setting. " > > > > > > It would be helpful to have this downported to jdk11, because it would > make > > downporting changes easier (brings build settings of the releases closer > > together) . > > (I was already running into one issue because of the different build > > settings ) > > > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8221318 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8221318.0/ > > > > > > Thanks, Matthias From matthias.baesken at sap.com Mon Mar 25 08:05:31 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 25 Mar 2019 08:05:31 -0000 Subject: RFR [11u] : 8221318: [11u] do not disable c99 on Solaris In-Reply-To: References: Message-ID: Hi Christoph / G?tz , thanks for the reviews ! Best Regards, Matthias > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Freitag, 22. M?rz 2019 11:08 > To: Langer, Christoph ; Baesken, Matthias > ; 'build-dev at openjdk.java.net' dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net > Subject: RE: RFR [11u] : 8221318: [11u] do not disable c99 on Solaris > > Looks good to me, thanks for downporting. > > Best regards, > Goetz. > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Langer, Christoph > > Sent: Freitag, 22. M?rz 2019 10:32 > > To: Baesken, Matthias ; 'build- > > dev at openjdk.java.net' ; jdk-updates- > > dev at openjdk.java.net > > Subject: [CAUTION] RE: RFR [11u] : 8221318: [11u] do not disable c99 on > > Solaris > > > > Hi Matthias, > > > > first of all: The change looks good to me, +1. > > I assume you have run it through our build/test infrastructure and see no > > regressions... > > > > As for the process: > > In your case, you want to backport a change and the original patch does not > > apply cleanly. For that scenario, you don't have to create a new bug (as > JDK- > > 8221318 in your case). You should just ask for review under the original bug > id > > (JDK-8215710). When you have reviews and push approval, you need to > push > > the change with the original patch message, referencing the original bug > (JDK- > > 8215710). The hgupdater daemon will then create a new backport bug and > > creates the according links. > > > > For your case, I've set fix version of JDK-8221318 to 11-pool. Then > hgupdater > > will pick it up and resolve it for the right release. Maybe you ping me, when > > you're going to push, then we can check things together ?? > > > > Best regards > > Christoph > > > > > -----Original Message----- > > > From: build-dev On Behalf Of > > > Baesken, Matthias > > > Sent: Freitag, 22. M?rz 2019 09:50 > > > To: 'build-dev at openjdk.java.net' ; jdk- > > > updates-dev at openjdk.java.net > > > Subject: [CAUTION] RFR [11u] : 8221318: [11u] do not disable c99 on > Solaris > > > > > > Hello, please review this change. > > > > > > It is a downport of jdk13 change > > > https://bugs.openjdk.java.net/browse/JDK-8215710 to 11u . > > > > > > JDK-8215710 removed the disabling of C99 on Solaris in jdk13. > > > Reason was : > > > "Currently we disable C99 in the Solaris build by setting -xc99=%none%. > > > This differs from a lot of other build environments like gcc/Linux or > > > VS2013/2017 on Windows where C99 features work. > > > We should remove this difference on Solaris and remove or replace the > > > setting. " > > > > > > > > > It would be helpful to have this downported to jdk11, because it would > make > > > downporting changes easier (brings build settings of the releases closer > > > together) . > > > (I was already running into one issue because of the different build > > > settings ) > > > > > > > > > > > > Bug/webrev : > > > > > > https://bugs.openjdk.java.net/browse/JDK-8221318 > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8221318.0/ > > > > > > > > > Thanks, Matthias