From OGATAK at jp.ibm.com Thu Aug 1 02:55:54 2019 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Thu, 1 Aug 2019 11:55:54 +0900 Subject: [Ping] Re: [8u-dev, ppc] RFR for (almost clean) backport of 8188868: PPC64: Support AES intrinsics on Big Endian In-Reply-To: <2d8d8d35-c781-cc0c-2673-c8f7eea057bd@redhat.com> References: <2d8d8d35-c781-cc0c-2673-c8f7eea057bd@redhat.com> Message-ID: Hi Andrew, Thank you for reviewing the webrev. Regards, Ogata Andrew John Hughes wrote on 2019/08/01 01:05:48: > From: Andrew John Hughes > To: Kazunori Ogata , hotspot-compiler- > dev at openjdk.java.net, jdk8u-dev at openjdk.java.net > Date: 2019/08/01 01:13 > Subject: [EXTERNAL] Re: [Ping] Re: [8u-dev, ppc] RFR for (almost clean) > backport of 8188868: PPC64: Support AES intrinsics on Big Endian > > > > On 31/07/2019 10:30, Kazunori Ogata wrote: > > Ping. > > > > May I get review for the almost clean backport? > > > > Regards, > > Ogata > > > > Kazunori Ogata/Japan/IBM wrote on 2019/07/24 17:48:23: > > > >> From: Kazunori Ogata/Japan/IBM > >> To: hotspot-compiler-dev at openjdk.java.net, jdk8u-dev at openjdk.java.net > >> Date: 2019/07/24 17:48 > >> Subject: [8u-dev, ppc] RFR for (almost clean) backport of 8188868: > > PPC64: > >> Support AES intrinsics on Big Endian > >> > >> Hi, > >> > >> May I get review for backport of 8188868: PPC64: Support AES intrinsics > > on > >> Big Endian? > >> > >> The original patch itself can be applied cleanly (besides difference of > >> the source directory structure). However, one chunk failed because the > >> code just after the patched code was modified, so I manually applied the > > > >> chunk and renewed the patch. > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8188868 > >> Webrev: > > http://cr.openjdk.java.net/~ogatak/jdk8u_aes_be/8188868/webrev.02/ > >> > >> This backport is low risk and affects only PPC64 only. I verified there > >> was no degradation in "make test" results and SPECjbb 2015 ran fine. The > > > >> intrinsics added in this changeset improved max jOPS by 5% and critical > > jOPS by 4%. > >> > >> Regards, > >> Ogata > > > > Sorry, I started looking at this yesterday, but didn't get chance to finish. > > It looks fine to me. The stubGenerator_ppc.cpp changes were a little > hard to follow, but comparing the patched version with the 11u version > looked ok. > > Good to go. > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew > > [attachment "signature.asc" deleted by Kazunori Ogata/Japan/IBM] From shade at redhat.com Fri Aug 2 08:42:54 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 2 Aug 2019 10:42:54 +0200 Subject: RFC: backport of JDK-8215756: Memory leaks in the AWT on macOS In-Reply-To: <7e5b8ed8-750e-58a6-ed12-d70d2d2a7171@redhat.com> References: <5fe51887-894b-af74-8b80-9770f8c4e78a@redhat.com> <54e7c8cb-8c20-1559-ce7d-80772960704c@redhat.com> <7e5b8ed8-750e-58a6-ed12-d70d2d2a7171@redhat.com> Message-ID: <76d8aadc-0842-1d55-d58a-7ec761bf68a3@redhat.com> On 7/31/19 7:12 PM, Simon Tooke wrote: > http://cr.openjdk.java.net/~stooke/webrevs/jdk8215756-jdk8u.01/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8215756 > Original patch: http://hg.openjdk.java.net/jdk/client/rev/64e7a73195c1 Looks okay. It seems webrev was generated in default mode that omits whitespace diffs. Try with -b. -- Thanks, -Aleksey From adinn at redhat.com Mon Aug 5 16:23:55 2019 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 5 Aug 2019 17:23:55 +0100 Subject: 8u: Backport 8163363: AArch64: Stack size in tools/launcher/Settings.java needs to be adjusted Message-ID: I would like permission to backport this fix to the jdk8u-aarch64-shenandoah repo. This fixes the minimum stack size used by jdk/test/tools/launcher/Settings.java so that it is large enough to allow the test to pass on AArch64 implementations where it previously failed. The backport requires a minor tweak to the original patch as per the following webrev: http://cr.openjdk.java.net/~adinn/8163363-jdk8u/webrev.00/ regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From mbalao at redhat.com Mon Aug 5 16:58:17 2019 From: mbalao at redhat.com (Martin Balao) Date: Mon, 5 Aug 2019 13:58:17 -0300 Subject: [8u] RFR 8200400: Allow Sasl mechanisms to be restricted Message-ID: <42222cb1-3643-0833-62d4-aa586e8a48c9@redhat.com> Hi, I'd like to request a review for the jdk8u backport of JDK-8200400 [1]: * https://cr.openjdk.java.net/~mbalao/webrevs/8200400/8200400.webrev.jdk8u.jdk.00/ Changes: * Paths * java.security change per OS file * Sasl.java * copyright date * documentation hooks did not apply cleanly * Test * @module jtreg tag removed * @library path changed * Asserts import changed Testing: * javax/security/sasl/Sasl/DisabledMechanisms.java passed Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8200400 From mbalao at redhat.com Mon Aug 5 22:25:47 2019 From: mbalao at redhat.com (Martin Balao) Date: Mon, 5 Aug 2019 19:25:47 -0300 Subject: [8u] RFR 8205507: jdk/javax/xml/crypto/dsig/GenerationTests.java timed out Message-ID: Hi, I'd like to have a review for the jdk8u backport of JDK-8205507 [1]: * http://cr.openjdk.java.net/~mbalao/webrevs/8205507/8205507.webrev.jdk8u.jdk.00/ Minor changes in GenerationTests::getCachedKeys function were required. Testing: javax/xml/crypto/dsig/GenerationTests.java passed. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8205507 From felix.yang at huawei.com Tue Aug 6 00:35:35 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 6 Aug 2019 00:35:35 +0000 Subject: [Ping] Re: Request for Approval: Backport of 8146792 : Predicate moved after partial peel may lead to broken graph Message-ID: Ping... This has passed jtreg test with a jdk8u fastdebug x86-64 build. Is it OK to backport this? Thanks, Felix Hi, Please approve the backport of 8146792 to 8u-dev. This issue can always be reproduced with jdk built from the latest jdk8u master repo: Test case reduced from one fuzz test: public class Test { public static void foo() { int iArr1[] = new int[10]; int iArr2[][] = new int[10][10]; for (long i = 0; i < 8; ++i) { iArr1[(int)i] = 10; for (int j = 0; j < 16; ++j) { iArr1 = iArr2[0]; } } } public static void main(String[] strArr) { for (int i = 0; i < 256; i++) { foo(); } } } Command line: java -XX:+UseSerialGC -XX:-TieredCompilation -XX:-RangeCheckElimination -XX:-BackgroundCompilation -XX:-UseOnStackReplacement -XX:LoopMaxUnroll=1 -XX:-UseCompressedClassPointers -XX:-UseCompressedOops -XX:CompileCommand=compileonly,Test::foo Test JVM crashed due to bad C2 graph. This issue will not trigger with -XX:-UseLoopPredicate. Bug: https://bugs.openjdk.java.net/browse/JDK-8146792 JDK9 Changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2748d975045f This backport is almost clean for the latest jdk8u master repo. Thanks, Felix From christoph.langer at sap.com Tue Aug 6 06:17:47 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 6 Aug 2019 06:17:47 +0000 Subject: CSR process for OpenJDK 11 and 8 Updates In-Reply-To: References: Message-ID: Hi Joe, thanks for getting back to this. As I?ve talked to both of you about this last week, my understanding is the same. I?ve also asked Andrew to make an explicit statement on the mailing list. Best regards Christoph From: Joe Darcy Sent: Dienstag, 6. August 2019 03:54 To: Langer, Christoph ; Andrew Haley Cc: jdk-updates-dev at openjdk.java.net; jdk8u-dev ; Hohensee, Paul Subject: Re: CSR process for OpenJDK 11 and 8 Updates Hi Christoph, Returning to this thread, from a side discussion at the OpenJDK Committers? Workshop last week, my understanding is that Andrew does want to use the CSR process for the update releases. Andrew, please confirm, and, if so, we can work on updating the CSR documentation accordingly. Thanks, -Joe On 6/21/2019 11:21 AM, Langer, Christoph wrote: Hi, thanks for that hint, Joe. I think you also said some time ago, that if there already existed a CSR for an Oracle JDK11 backport of a certain bug, we can also use it and link it to the OpenJDK backport item. Is that correct? Cheers Christoph From: Joe Darcy Sent: Freitag, 21. Juni 2019 18:46 To: Langer, Christoph ; Andrew Haley Cc: jdk-updates-dev at openjdk.java.net; jdk8u-dev ; Hohensee, Paul Subject: Re: CSR process for OpenJDK 11 and 8 Updates Hello, On 6/19/2019 12:26 AM, Langer, Christoph wrote: Hi Joe, Andrew, I?m currently wondering about the status of the CSR process for JDK updates. Do we use the CSR process or not? As per previous mailing list discussions [1], I read that that the project lead of 8u and 11u is under the assumption that we are using CSR. However, as per the latest CSRs in that area [2], [3], I understand that the CSR group lead is under the assumption that Open JDK updates doesn?t use this process and hence these CSRs were pended. Obviously there?s some disconnect here? ?? So, what is the current status? Did you already sort this out? My personal view is that a CSR process would be beneficial to the JDK updates projects, too. In any case, thanks in advance for some guidance on how to handle backports with attached CSRs! While discussion are on-going, the CSR FAQ does address a common situation of how to handle backports and CSRs: Q: How should I get CSR review for multiple release trains? A: Say you want to get an interface change into JDK N and later decide the change is also desirable and appropriate for the JDK (N-1) update release and that update release is using the CSR process. First a CSR should be created from the main bug targeted at JDK N. Afterward, if a backport of the main bug covering JDK (N-1) does not already exist, a backport of the main bug covering JDK (N-1) should be created. Then, a CSR can be created from that backport. https://wiki.openjdk.java.net/display/csr/CSR+FAQs HTH, -Joe From aph at redhat.com Tue Aug 6 13:46:56 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 6 Aug 2019 14:46:56 +0100 Subject: Changes to 8u and 11u process Message-ID: <51f754b2-a7c0-8157-76fb-6a5bd2d089c6@redhat.com> We've been running 8u and 11u for two quarters now, and it's time to adjust our processes. First, the easy one: Christoph Langer is now a maintainer of JDK 11u. Backports which have already been approved by Oracle for their proprietary fork will no longer need approval for 8u- and 11u-open. There are two reasons for this. Firstly, it's safe to assume that Oracle have done their due diligence with regard to suitability. Secondly, it's a waste of effort on the part of the maintainer. Backports of fixes to tests no longer need to be approved, but they should still be reviewed if there are any changes. We will use the CSR process, with the help of the CSR team, for any backports of patches which required CSRs in mainline. Hopefully this will be rare, and the CSR team will process review requests promptly. Finally, more of a recommendation. Rule #0: Do no harm. I know of no very strong reason why 8u- and 11u-open should in general have much more churn than the corresponding closed projects. If they have, there is a serious risk that they will be less stable. We must avoid, above all else, the open updates being (or being perceived as) less reliable than the closed. [That being said, we've already made the decision to backport some major items; it's a delicate balance.] Where it makes sense, please minimize the size of the patches. If you can adapt a backport patch to fit rather than also backporting a bunch of its dependencies, please consider doing so. Bear in mind that stability is the most important feature that these updates projects have. Simple history in backports is important: it's more important to reduce the volume of changes to 8u and 11u than it is to reduce the differences between the backports and head. Feature backports should be treated with a degree of skepticism. 8u and 11u are stable maintenance versions not development branches, so features shouldn't be backported without a compelling reason and a careful analysis of risk. Please discuss such backports on the list. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From goetz.lindenmaier at sap.com Tue Aug 6 15:34:25 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 6 Aug 2019 15:34:25 +0000 Subject: Changes to 8u and 11u process In-Reply-To: <51f754b2-a7c0-8157-76fb-6a5bd2d089c6@redhat.com> References: <51f754b2-a7c0-8157-76fb-6a5bd2d089c6@redhat.com> Message-ID: Hi Andrew, I appreciate these simplifications a lot! I also share your concerns wrt. feature backports. Thanks for appointing Christoph a maintainer! Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Andrew Haley > Sent: Tuesday, August 6, 2019 3:47 PM > To: jdk8u-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net > Subject: Changes to 8u and 11u process > > We've been running 8u and 11u for two quarters now, and it's time to > adjust our processes. > > First, the easy one: Christoph Langer is now a maintainer of JDK 11u. > > Backports which have already been approved by Oracle for their > proprietary fork will no longer need approval for 8u- and 11u-open. > There are two reasons for this. Firstly, it's safe to assume that > Oracle have done their due diligence with regard to suitability. > Secondly, it's a waste of effort on the part of the maintainer. > > Backports of fixes to tests no longer need to be approved, but they > should still be reviewed if there are any changes. > > We will use the CSR process, with the help of the CSR team, for any > backports of patches which required CSRs in mainline. Hopefully this > will be rare, and the CSR team will process review requests promptly. > > Finally, more of a recommendation. > > Rule #0: Do no harm. > > I know of no very strong reason why 8u- and 11u-open should in general > have much more churn than the corresponding closed projects. If they > have, there is a serious risk that they will be less stable. We must > avoid, above all else, the open updates being (or being perceived as) > less reliable than the closed. [That being said, we've already made > the decision to backport some major items; it's a delicate balance.] > > Where it makes sense, please minimize the size of the patches. If you > can adapt a backport patch to fit rather than also backporting a bunch > of its dependencies, please consider doing so. Bear in mind that > stability is the most important feature that these updates projects > have. Simple history in backports is important: it's more important to > reduce the volume of changes to 8u and 11u than it is to reduce the > differences between the backports and head. > > Feature backports should be treated with a degree of skepticism. 8u > and 11u are stable maintenance versions not development branches, so > features shouldn't be backported without a compelling reason and a > careful analysis of risk. Please discuss such backports on the list. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Aug 6 16:57:04 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 6 Aug 2019 17:57:04 +0100 Subject: Changes to 8u and 11u process In-Reply-To: <51f754b2-a7c0-8157-76fb-6a5bd2d089c6@redhat.com> References: <51f754b2-a7c0-8157-76fb-6a5bd2d089c6@redhat.com> Message-ID: <99dc4e1c-d25a-973e-7a88-035274dec1d5@redhat.com> On 8/6/19 2:46 PM, Andrew Haley wrote: > Backports which have already been approved by Oracle for their > proprietary fork will no longer need approval for 8u- and 11u-open. > There are two reasons for this. Firstly, it's safe to assume that > Oracle have done their due diligence with regard to suitability. > Secondly, it's a waste of effort on the part of the maintainer. ... also, we're trying to maintain parity with Oracle's closed releases. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sgehwolf at redhat.com Tue Aug 6 17:11:34 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 06 Aug 2019 19:11:34 +0200 Subject: Changes to 8u and 11u process In-Reply-To: <99dc4e1c-d25a-973e-7a88-035274dec1d5@redhat.com> References: <51f754b2-a7c0-8157-76fb-6a5bd2d089c6@redhat.com> <99dc4e1c-d25a-973e-7a88-035274dec1d5@redhat.com> Message-ID: On Tue, 2019-08-06 at 17:57 +0100, Andrew Haley wrote: > On 8/6/19 2:46 PM, Andrew Haley wrote: > > Backports which have already been approved by Oracle for their > > proprietary fork will no longer need approval for 8u- and 11u-open. > > There are two reasons for this. Firstly, it's safe to assume that > > Oracle have done their due diligence with regard to suitability. > > Secondly, it's a waste of effort on the part of the maintainer. > > ... also, we're trying to maintain parity with Oracle's closed > releases. Could you please clarify? Consider a bug with a backport to Oracle JDK 11 and "Fix version: 11.0.6-oracle". Does that mean a fix for OpenJDK 11u can only be pushed to jdk11u-dev once 11.0.6 opens? Same rationale for JDK 8 and 8u232 vs openjdk8u232? Thanks, Severin From shade at redhat.com Tue Aug 6 17:11:28 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 6 Aug 2019 19:11:28 +0200 Subject: Changes to 8u and 11u process In-Reply-To: <51f754b2-a7c0-8157-76fb-6a5bd2d089c6@redhat.com> References: <51f754b2-a7c0-8157-76fb-6a5bd2d089c6@redhat.com> Message-ID: <1462b721-29ce-8db5-6661-0fdd60dd1245@redhat.com> (was surprised why it was not discussed here before, because I have comments) On 8/6/19 3:46 PM, Andrew Haley wrote: > Backports which have already been approved by Oracle for their > proprietary fork will no longer need approval for 8u- and 11u-open. > There are two reasons for this. Firstly, it's safe to assume that > Oracle have done their due diligence with regard to suitability. > Secondly, it's a waste of effort on the part of the maintainer. I vehemently oppose this rule. First, this dismantles the consistency of the process ("every change should be approved, here is the checklist [1]") for the sake of less maintainer work (which can be alleviate by assigning more maintainers, as we did with Christoph). Having a single checklist for everything is simpler to remember, simpler to act upon, and it provides less cognitive load. We need to continue doing the same thing on all paths, and if on some of those paths it would reduce to mechanical rubber-stamping work, so be it. It is the same as with code reviews in trivial patches: we do not circumvent the review process by telling "trivial patches do not need review", we just say "trivial patches enjoy more mechanical rubber-stamping approach". Second, summarily accepting every Oracle-proprietary change dismantles the maintainers' responsibility over everything in JDK Updates projects. There are changes that could be rejected from JDK Updates, even if Oracle-internal repositories have it: platforms not supported, features not maintained, cleanups not needed. We have to reserve the opportunity to act upon this, if/when needed. It feels like this rule should just go to maintainer's rule book: once somebody requests the backport for something Oracle-proprietary fork has, rubber-stamp it. But do not summarily relinquish maintainer's power to veto. > Backports of fixes to tests no longer need to be approved, but they > should still be reviewed if there are any changes. Same thing as above. > Where it makes sense, please minimize the size of the patches. If you > can adapt a backport patch to fit rather than also backporting a bunch > of its dependencies, please consider doing so. Bear in mind that > stability is the most important feature that these updates projects > have. Simple history in backports is important: it's more important to > reduce the volume of changes to 8u and 11u than it is to reduce the > differences between the backports and head. Understanding that retrofitting the patch comes with the risks in itself, in many cases bringing up more code is better, if it minimizes the difference against other versions, applies mechanically, matches the history of the later code. So, I think we should default to bringing in the patches wholesale, and leave it to maintainers/reviewers to ask backporters to cut the patches shorter if maintainers/reviewers argue there is no reason to bring large change with it. It happened multiple times already, and I don't think it needs to be changed. -- Thanks, -Aleksey [1] https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix From aph at redhat.com Tue Aug 6 18:33:11 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 6 Aug 2019 19:33:11 +0100 Subject: Changes to 8u and 11u process In-Reply-To: <1462b721-29ce-8db5-6661-0fdd60dd1245@redhat.com> References: <51f754b2-a7c0-8157-76fb-6a5bd2d089c6@redhat.com> <1462b721-29ce-8db5-6661-0fdd60dd1245@redhat.com> Message-ID: <36e502d0-94c1-3985-4074-eccf7cd3b78f@redhat.com> On 8/6/19 6:11 PM, Aleksey Shipilev wrote: > (was surprised why it was not discussed here before, because I have comments) > > On 8/6/19 3:46 PM, Andrew Haley wrote: >> Backports which have already been approved by Oracle for their >> proprietary fork will no longer need approval for 8u- and 11u-open. >> There are two reasons for this. Firstly, it's safe to assume that >> Oracle have done their due diligence with regard to suitability. >> Secondly, it's a waste of effort on the part of the maintainer. > > I vehemently oppose this rule. Sorry, I didn't think this would be so controversial or it would have been clearly labeled as an RFC. > First, this dismantles the consistency of the process ("every change > should be approved, here is the checklist [1]") for the sake of less > maintainer work (which can be alleviate by assigning more > maintainers, as we did with Christoph). Having a single checklist > for everything is simpler to remember, simpler to act upon, and it > provides less cognitive load. We need to continue doing the same > thing on all paths, and if on some of those paths it would reduce to > mechanical rubber-stamping work, so be it. It is the same as with > code reviews in trivial patches: we do not circumvent the review > process by telling "trivial patches do not need review", we just say > "trivial patches enjoy more mechanical rubber-stamping approach". It's not about less maintainer work at all: there is little or no work for the maintainer to do. It's that the process adds very little information because approvals for clean test backports and backports to maintain parity with Oracle will very probably automatically go through. It does seem to me like process for process' sake in most cases, where the programmer pushes a button and the maintainer pushes a button in response. But OK, I'm not trying to dictate this. If people here want to carry on using this processI won't stand in your way. > Second, summarily accepting every Oracle-proprietary change > dismantles the maintainers' responsibility over everything in JDK > Updates projects. There are changes that could be rejected from JDK > Updates, even if Oracle-internal repositories have it: platforms not > supported, features not maintained, cleanups not needed. Maybe, but I'd be very surprised if such a patch survived review. > We have to reserve the opportunity to act upon this, if/when > needed. It feels like this rule should just go to maintainer's rule > book: once somebody requests the backport for something > Oracle-proprietary fork has, rubber-stamp it. But do not summarily > relinquish maintainer's power to veto. OK. As above, if people want to do so there's no very strong reason not to make this advice to maintainers instead of a process reduction. >> Backports of fixes to tests no longer need to be approved, but they >> should still be reviewed if there are any changes. > > Same thing as above. > >> Where it makes sense, please minimize the size of the patches. If you >> can adapt a backport patch to fit rather than also backporting a bunch >> of its dependencies, please consider doing so. Bear in mind that >> stability is the most important feature that these updates projects >> have. Simple history in backports is important: it's more important to >> reduce the volume of changes to 8u and 11u than it is to reduce the >> differences between the backports and head. > > Understanding that retrofitting the patch comes with the risks in > itself, in many cases bringing up more code is better, if it > minimizes the difference against other versions, applies > mechanically, matches the history of the later code. True, that can happen. This is a judgment call, that's why I said "Where it makes sense," and I mean *only* where it makes sense, please minimize the size of patches. If it clearly is better to backport a bigger chunk of code, fair enough, but it should not always be a reviewer's job to cut down patches. > So, I think we should default to bringing in the patches wholesale, > and leave it to maintainers/reviewers to ask backporters to cut the > patches shorter if maintainers/reviewers argue there is no reason to > bring large change with it. OK, so we disagree about the default. I don't think that bringing in extra code is less risky than adjusting patches, but it depends on the actual patch, as above. > It happened multiple times already, and I don't think it needs to be > changed. Yes, I know it has. It can go either way, but I don't want to see the updates projects with a great deal of churn. Our work is all about minimizing risk, and trying to keep the updates projects clean. When it's less risky to backport more code than edit the patch, that's a really good reason to do so. But both approaches carry some risk. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Tue Aug 6 21:37:54 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 6 Aug 2019 21:37:54 +0000 Subject: Changes to 8u and 11u process In-Reply-To: <36e502d0-94c1-3985-4074-eccf7cd3b78f@redhat.com> References: <51f754b2-a7c0-8157-76fb-6a5bd2d089c6@redhat.com> <1462b721-29ce-8db5-6661-0fdd60dd1245@redhat.com> <36e502d0-94c1-3985-4074-eccf7cd3b78f@redhat.com> Message-ID: Hi all, first of all, thanks for making me a maintainer of jdk11 updates. I feel very humbled and will try my best to do a decent job. ?? As for the discussion on whether items included by Oracle as well as test fixes shall undergo the approval labeling process or not: After some contemplation, I got to the conclusion to support Aleksey's position to keep the labelling for every item that's going to be backported. Here are my reasons: a) It gives the maintainer(s) some form of control, not only about what's going in to the project but also about when it'll be pushed. For instance it might be that a certain item can be considered too risky for pushing when only few time is left until the release date and should rather be pushed early in the next cycle to give it more time to bake in and be tested. b) What I find particularly helpful, also for Oracle induced items and tests, is the fix request comment. It mostly contains valuable information about the reasons, testing and other things like risk assessment and serves as a good documentation. I'd really like to have this on all backported patches and would consider this a task for the maintainer to make sure that some comment is there before approving. Other than that, obviously Oracle backports and testbugs are the no-brainers for maintainer decisions. So they should be approved quite fast and mechanically. Speaking for myself, I don't consider it a huge burden to look at every item coming up for 11u-dev. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Andrew Haley > Sent: Dienstag, 6. August 2019 20:33 > To: Aleksey Shipilev ; jdk8u-dev at openjdk.java.net; > jdk-updates-dev at openjdk.java.net > Subject: Re: Changes to 8u and 11u process > > On 8/6/19 6:11 PM, Aleksey Shipilev wrote: > > (was surprised why it was not discussed here before, because I have > comments) > > > > On 8/6/19 3:46 PM, Andrew Haley wrote: > >> Backports which have already been approved by Oracle for their > >> proprietary fork will no longer need approval for 8u- and 11u-open. > >> There are two reasons for this. Firstly, it's safe to assume that > >> Oracle have done their due diligence with regard to suitability. > >> Secondly, it's a waste of effort on the part of the maintainer. > > > > I vehemently oppose this rule. > > Sorry, I didn't think this would be so controversial or it would have > been clearly labeled as an RFC. > > > First, this dismantles the consistency of the process ("every change > > should be approved, here is the checklist [1]") for the sake of less > > maintainer work (which can be alleviate by assigning more > > maintainers, as we did with Christoph). Having a single checklist > > for everything is simpler to remember, simpler to act upon, and it > > provides less cognitive load. We need to continue doing the same > > thing on all paths, and if on some of those paths it would reduce to > > mechanical rubber-stamping work, so be it. It is the same as with > > code reviews in trivial patches: we do not circumvent the review > > process by telling "trivial patches do not need review", we just say > > "trivial patches enjoy more mechanical rubber-stamping approach". > > It's not about less maintainer work at all: there is little or no work > for the maintainer to do. It's that the process adds very little > information because approvals for clean test backports and backports > to maintain parity with Oracle will very probably automatically go > through. It does seem to me like process for process' sake in most > cases, where the programmer pushes a button and the maintainer pushes > a button in response. > > But OK, I'm not trying to dictate this. If people here want to carry > on using this processI won't stand in your way. > > > Second, summarily accepting every Oracle-proprietary change > > dismantles the maintainers' responsibility over everything in JDK > > Updates projects. There are changes that could be rejected from JDK > > Updates, even if Oracle-internal repositories have it: platforms not > > supported, features not maintained, cleanups not needed. > > Maybe, but I'd be very surprised if such a patch survived review. > > > We have to reserve the opportunity to act upon this, if/when > > needed. It feels like this rule should just go to maintainer's rule > > book: once somebody requests the backport for something > > Oracle-proprietary fork has, rubber-stamp it. But do not summarily > > relinquish maintainer's power to veto. > > OK. As above, if people want to do so there's no very strong reason > not to make this advice to maintainers instead of a process reduction. > > >> Backports of fixes to tests no longer need to be approved, but they > >> should still be reviewed if there are any changes. > > > > Same thing as above. > > > >> Where it makes sense, please minimize the size of the patches. If you > >> can adapt a backport patch to fit rather than also backporting a bunch > >> of its dependencies, please consider doing so. Bear in mind that > >> stability is the most important feature that these updates projects > >> have. Simple history in backports is important: it's more important to > >> reduce the volume of changes to 8u and 11u than it is to reduce the > >> differences between the backports and head. > > > > Understanding that retrofitting the patch comes with the risks in > > itself, in many cases bringing up more code is better, if it > > minimizes the difference against other versions, applies > > mechanically, matches the history of the later code. > > True, that can happen. This is a judgment call, that's why I said > "Where it makes sense," and I mean *only* where it makes sense, please > minimize the size of patches. If it clearly is better to backport a > bigger chunk of code, fair enough, but it should not always be a > reviewer's job to cut down patches. > > > So, I think we should default to bringing in the patches wholesale, > > and leave it to maintainers/reviewers to ask backporters to cut the > > patches shorter if maintainers/reviewers argue there is no reason to > > bring large change with it. > > OK, so we disagree about the default. I don't think that bringing in > extra code is less risky than adjusting patches, but it depends on the > actual patch, as above. > > > It happened multiple times already, and I don't think it needs to be > > changed. > > Yes, I know it has. It can go either way, but I don't want to see the > updates projects with a great deal of churn. Our work is all about > minimizing risk, and trying to keep the updates projects clean. When > it's less risky to backport more code than edit the patch, that's a > really good reason to do so. But both approaches carry some risk. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Tue Aug 6 21:48:39 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 6 Aug 2019 21:48:39 +0000 Subject: Changes to 8u and 11u process In-Reply-To: References: <51f754b2-a7c0-8157-76fb-6a5bd2d089c6@redhat.com> <99dc4e1c-d25a-973e-7a88-035274dec1d5@redhat.com> Message-ID: Hi Severin > Could you please clarify? > > Consider a bug with a backport to Oracle JDK 11 and "Fix version: > 11.0.6-oracle". Does that mean a fix for OpenJDK 11u can only be pushed > to jdk11u-dev once 11.0.6 opens? Same rationale for JDK 8 and 8u232 vs > openjdk8u232? In case we abolish labelling for Oracle induced items, I would strongly suggest to only allow it for patches of the current release (e.g. only 11.0.5-oracle at the moment in 11u). In case one wanted to pre-draw something from a later Oracle release, a maintainer should have a closer look whether the backport is suitable for the current OpenJDK release cycle already. Which will be true in most cases probably - but who knows. I consider this another argument to keep the unconditional labelling for all items. Otherwise this rule will be hard to enforce and people will do mistakes. Best regards Christoph From gnu.andrew at redhat.com Wed Aug 7 03:29:11 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 7 Aug 2019 04:29:11 +0100 Subject: [Ping] Re: Request for Approval: Backport of 8146792 : Predicate moved after partial peel may lead to broken graph In-Reply-To: References: Message-ID: <7243c1b4-f8a0-1a83-4423-db5f76946d82@redhat.com> On 06/08/2019 01:35, Yangfei (Felix) wrote: > Ping... > > This has passed jtreg test with a jdk8u fastdebug x86-64 build. Is it OK to backport this? > > Thanks, > Felix > > > > Hi, > > > > Please approve the backport of 8146792 to 8u-dev. > > > > This issue can always be reproduced with jdk built from the latest jdk8u master repo: > > > > Test case reduced from one fuzz test: > > public class Test { > > > > public static void foo() { > > int iArr1[] = new int[10]; > > int iArr2[][] = new int[10][10]; > > > > for (long i = 0; i < 8; ++i) { > > iArr1[(int)i] = 10; > > > > for (int j = 0; j < 16; ++j) { > > iArr1 = iArr2[0]; > > } > > } > > } > > > > public static void main(String[] strArr) { > > for (int i = 0; i < 256; i++) { > > foo(); > > } > > } > > > > } > > > > Command line: java -XX:+UseSerialGC -XX:-TieredCompilation -XX:-RangeCheckElimination -XX:-BackgroundCompilation -XX:-UseOnStackReplacement -XX:LoopMaxUnroll=1 -XX:-UseCompressedClassPointers -XX:-UseCompressedOops -XX:CompileCommand=compileonly,Test::foo Test > > > > JVM crashed due to bad C2 graph. This issue will not trigger with -XX:-UseLoopPredicate. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8146792 > > JDK9 Changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2748d975045f > > > > This backport is almost clean for the latest jdk8u master repo. > > > > Thanks, > > Felix > I saw your approval flag in the bug database, but there was no mention of whether the patch applied cleanly or not. I see no webrev link either there or in this e-mail. Can you clarify what you mean by "almost clean" or maybe just provide a webrev for review? 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 Aug 7 03:36:16 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 7 Aug 2019 04:36:16 +0100 Subject: Changes to 8u and 11u process In-Reply-To: <51f754b2-a7c0-8157-76fb-6a5bd2d089c6@redhat.com> References: <51f754b2-a7c0-8157-76fb-6a5bd2d089c6@redhat.com> Message-ID: <084f5815-6d39-f8a2-01a5-244a1a4c2905@redhat.com> On 06/08/2019 14:46, Andrew Haley wrote: > We've been running 8u and 11u for two quarters now, and it's time to > adjust our processes. > > First, the easy one: Christoph Langer is now a maintainer of JDK 11u. > I very much welcome this move as there have been delays in 11u approvals, not to mention that having only one maintainer inevitably means that there is no maintainer to approve the work of that person. Christoph's continued diligent work in handling the 11u release process makes him the obvious choice and I wish him well in the role. > Backports which have already been approved by Oracle for their > proprietary fork will no longer need approval for 8u- and 11u-open. > There are two reasons for this. Firstly, it's safe to assume that > Oracle have done their due diligence with regard to suitability. > Secondly, it's a waste of effort on the part of the maintainer. > > Backports of fixes to tests no longer need to be approved, but they > should still be reviewed if there are any changes. I strongly oppose this, for many of the reasons Aleksey has already outlined. To add further to that, I would point out that the decisions made by Oracle for their proprietary fork are opaque to us, and so to do as proposed would be to essentially hand control of the majority of our work to a black box. I am vehemently of the opinion that the OpenJDK projects should remain independent of such proprietary forks. Moreover, I find it extremely odd to make such a decision to waive approval based not on the change itself, but merely because it has been blessed by a certain group that is not even involved in this project. With reference to my experience as maintainer for 8u, I'll restate what I said previously on this topic, which is that 8u backports are far more likely to differ significantly from the originals than 11u backports (and absolutely nothing applies as is due to all the file movement between these versions). Far from my efforts being wasted, I think the work I've been doing in approving backports has been a good safety check, especially in these early days. It is one thing to review a patch in isolation, but another to approve it in the context of 8u as a whole; the concerns are different and it requires someone with a general knowledge of the entire body of changes being made. > > We will use the CSR process, with the help of the CSR team, for any > backports of patches which required CSRs in mainline. Hopefully this > will be rare, and the CSR team will process review requests promptly. > > Finally, more of a recommendation. > > Rule #0: Do no harm. > > I know of no very strong reason why 8u- and 11u-open should in general > have much more churn than the corresponding closed projects. If they > have, there is a serious risk that they will be less stable. We must > avoid, above all else, the open updates being (or being perceived as) > less reliable than the closed. [That being said, we've already made > the decision to backport some major items; it's a delicate balance.] I believe overseeing this is exactly the role of a maintainer and why we shouldn't cut them out of the picture for the majority of patches. > > Where it makes sense, please minimize the size of the patches. If you > can adapt a backport patch to fit rather than also backporting a bunch > of its dependencies, please consider doing so. Bear in mind that > stability is the most important feature that these updates projects > have. Simple history in backports is important: it's more important to > reduce the volume of changes to 8u and 11u than it is to reduce the > differences between the backports and head. > > Feature backports should be treated with a degree of skepticism. 8u > and 11u are stable maintenance versions not development branches, so > features shouldn't be backported without a compelling reason and a > careful analysis of risk. Please discuss such backports on the list. > Again, I concur with Aleksey here that the default should be to backport dependants where possible. The viability of this is something for the patch review process and concomitant approvals, which again brings in the maintainer as well to give their opinion on whether such a backport is necessary. The problem with creating a more divergent change is that you then create a burden for future backporters; if patch x is backported with major alterations to avoid bringing in dependants, then patch y, which applies on top of x, has to then also be altered, whereas it may instead have been close to a clean backport if the divergence of x had been minimised. In short, it seems to me that the two sections here contradict one another; rule #0 seems to scream out for someone to oversee the overall set of patches being allowed into the update releases, while the second proposal risks excluding that same person from overseeing the majority of changes being made. 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 Aug 7 03:37:38 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 7 Aug 2019 04:37:38 +0100 Subject: 8u: Backport 8163363: AArch64: Stack size in tools/launcher/Settings.java needs to be adjusted In-Reply-To: References: Message-ID: <30a6fc40-a0cc-3944-5bee-27e8acc65134@redhat.com> On 05/08/2019 17:23, Andrew Dinn wrote: > I would like permission to backport this fix to the > jdk8u-aarch64-shenandoah repo. This fixes the minimum stack size used by > jdk/test/tools/launcher/Settings.java so that it is large enough to > allow the test to pass on AArch64 implementations where it previously > failed. > > The backport requires a minor tweak to the original patch as per the > following webrev: > > http://cr.openjdk.java.net/~adinn/8163363-jdk8u/webrev.00/ > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > Then shouldn't this go to the aarch64-port-dev list? 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 Aug 7 04:19:58 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 7 Aug 2019 05:19:58 +0100 Subject: OpenJDK 8u232-b02 EA Released Message-ID: <75c35178-fa35-1e74-5261-362bbd77d3ba@redhat.com> I've made available an early access source bundle for 8u232, based on the tag jdk8u232-b02: https://openjdk-sources.osci.io/openjdk8/openjdk8u232-b02-ea.tar.xz The tarball is accompanied by a digital signature available at: https://openjdk-sources.osci.io/openjdk8/openjdk8u232-b02-ea.tar.xz.sig This is signed by our new Red Hat OpenJDK key (openjdk at redhat.com): PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) Fingerprint = CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F SHA256 checksums: 2db65980b3065d2e2bc9ac04027a72365f1282bfe6a9d4d50ca31992535453fc openjdk8u232-b02-ea.tar.xz 50f54948fc75d3f954a6a8d6494e589d816932735a3179cd6a6dbe3bac79d30f openjdk8u232-b02-ea.tar.xz.sig They are listed at https://openjdk-sources.osci.io/openjdk8/openjdk8u232-b02-ea.sha256 Changes in 8u232-b02: - S8075546: Add tiered testing definitions to the langtools repo - S8202252: (aio) Closed AsynchronousSocketChannel keeps completion handler alive - S8216597: SIGBUS in Java_sun_security_pkcs11_wrapper_PKCS11_getNativeKeyInfo after JDK-6913047 - S8220513: Wrapper Key may get deleted when closing sessions in SunPKCS11 crypto provider - S8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u - S8224580: Matcher can cause oop field/array element to be reloaded - S8226543: Reduce GC pressure during message digest calculations in password-based encryption -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From aph at redhat.com Wed Aug 7 08:06:33 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 7 Aug 2019 09:06:33 +0100 Subject: Changes to 8u and 11u process In-Reply-To: <084f5815-6d39-f8a2-01a5-244a1a4c2905@redhat.com> References: <51f754b2-a7c0-8157-76fb-6a5bd2d089c6@redhat.com> <084f5815-6d39-f8a2-01a5-244a1a4c2905@redhat.com> Message-ID: <8a1696b8-46b9-d8a9-adbf-c42601104d89@redhat.com> On 8/7/19 4:36 AM, Andrew John Hughes wrote: > On 06/08/2019 14:46, Andrew Haley wrote: >> We've been running 8u and 11u for two quarters now, and it's time to >> adjust our processes. > >> Backports which have already been approved by Oracle for their >> proprietary fork will no longer need approval for 8u- and 11u-open. >> There are two reasons for this. Firstly, it's safe to assume that >> Oracle have done their due diligence with regard to suitability. >> Secondly, it's a waste of effort on the part of the maintainer. >> >> Backports of fixes to tests no longer need to be approved, but they >> should still be reviewed if there are any changes. > > I strongly oppose this, for many of the reasons Aleksey has already > outlined. OK. As long as people are actually gaining some value from the process, I'm happy for it to continue. >> We will use the CSR process, with the help of the CSR team, for any >> backports of patches which required CSRs in mainline. Hopefully this >> will be rare, and the CSR team will process review requests promptly. >> >> Finally, more of a recommendation. >> >> Rule #0: Do no harm. >> >> I know of no very strong reason why 8u- and 11u-open should in general >> have much more churn than the corresponding closed projects. If they >> have, there is a serious risk that they will be less stable. We must >> avoid, above all else, the open updates being (or being perceived as) >> less reliable than the closed. [That being said, we've already made >> the decision to backport some major items; it's a delicate balance.] > > I believe overseeing this is exactly the role of a maintainer and why we > shouldn't cut them out of the picture for the majority of patches. Yes, but it is difficult for a maintainer to push back against an apparently reasonable patch at that stage in the process. The problem is not that the individual patches are inappropriate, but that there is a substantial volume of low-priority patches. >> Where it makes sense, please minimize the size of the patches. If you >> can adapt a backport patch to fit rather than also backporting a bunch >> of its dependencies, please consider doing so. Bear in mind that >> stability is the most important feature that these updates projects >> have. Simple history in backports is important: it's more important to >> reduce the volume of changes to 8u and 11u than it is to reduce the >> differences between the backports and head. >> >> Feature backports should be treated with a degree of skepticism. 8u >> and 11u are stable maintenance versions not development branches, so >> features shouldn't be backported without a compelling reason and a >> careful analysis of risk. Please discuss such backports on the list. > > Again, I concur with Aleksey here that the default should be to backport > dependants where possible. The viability of this is something for the > patch review process and concomitant approvals, which again brings in > the maintainer as well to give their opinion on whether such a backport > is necessary. > The problem with creating a more divergent change is that you then > create a burden for future backporters; if patch x is backported with > major alterations ... don't do that, then. I'm not talking about major rewrites of patches. If a patch does require substantial backporting of dependencies, we should look again at whether that patch is worth doing. > to avoid bringing in dependants, then patch y, which applies on top > of x, has to then also be altered, whereas it may instead have been > close to a clean backport if the divergence of x had been minimised. That can happen. Use your judgment, but please try to keep the volume of changes low. > In short, it seems to me that the two sections here contradict one > another; rule #0 seems to scream out for someone to oversee the > overall set of patches being allowed into the update releases, while > the second proposal risks excluding that same person from overseeing > the majority of changes being made. For this to work, everyone has to be part of the process, not just the maintainer on one side and the committers trying to get stuff in. Apart from anything else it's a terrible waste of effort once the work has been done. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Aug 7 08:11:14 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 7 Aug 2019 09:11:14 +0100 Subject: Changes to 8u and 11u process In-Reply-To: References: <51f754b2-a7c0-8157-76fb-6a5bd2d089c6@redhat.com> <1462b721-29ce-8db5-6661-0fdd60dd1245@redhat.com> <36e502d0-94c1-3985-4074-eccf7cd3b78f@redhat.com> Message-ID: <47dfe7e0-7745-b290-d5b4-f0697f3ef133@redhat.com> On 8/6/19 10:37 PM, Langer, Christoph wrote: > first of all, thanks for making me a maintainer of jdk11 updates. I > feel very humbled and will try my best to do a decent job. ?? I'm sure you will. > As for the discussion on whether items included by Oracle as well as > test fixes shall undergo the approval labeling process or not: > After some contemplation, I got to the conclusion to support > Aleksey's position to keep the labelling for every item that's going > to be backported. Here are my reasons: > a) It gives the maintainer(s) some form of control, not only about > what's going in to the project but also about when it'll be > pushed. For instance it might be that a certain item can be > considered too risky for pushing when only few time is left until > the release date and should rather be pushed early in the next cycle > to give it more time to bake in and be tested. That's a good reason. > b) What I find particularly helpful, also for Oracle induced items > and tests, is the fix request comment. It mostly contains valuable > information about the reasons, testing and other things like risk > assessment and serves as a good documentation. I'd really like to > have this on all backported patches and would consider this a task > for the maintainer to make sure that some comment is there before > approving. OK. Thanks for sharing your reasoning. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From neugens at redhat.com Wed Aug 7 08:39:30 2019 From: neugens at redhat.com (Mario Torre) Date: Wed, 7 Aug 2019 10:39:30 +0200 Subject: Backport proposal of the Marlin renderer in OpenJDK8 In-Reply-To: References: Message-ID: Hi Laurent, I would be supportive with this if we had help backporting fixes and solving problems that may happen in production systems in 8u. Cheers, Mario On Wed, Aug 7, 2019 at 10:05 AM Laurent Bourg?s wrote: > > Hi, > > I want to discuss the opportunity to provide the Marlin renderer in OpenJDK8 updates. > > FYI it is the java2d antialiasing renderer that replaced Pisces in OpenJDK9 (integrated in 2015) that provide both better quality and performance. > I am still maintaining the code on github, openjdk and openjfx. > FYI the Marlin renderer has a very efficient path clipper since v0.9 integrated in OpenJDK11 (2018.7). > Very few bugs (<5) were reported since 2015. > > Risks: azul zulu 8 and jetbrains jdk8 provide the Marlin renderer as their default renderer and it runs in production for years. > I am aware that amazon corretto would like to have it backported too. > AdoptOpenJDK already mentioned such possible backport on their web pages. > > Finally I propose to > - make a large patch (same marlin version as latest openjdk 14 ie 0.9.1.1) to easily backport fixes in the future > - leave it disabled by default. It will depend on the provider to enable it in its binary releases. > > Cheers, > Laurent -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From adinn at redhat.com Wed Aug 7 08:46:10 2019 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 7 Aug 2019 09:46:10 +0100 Subject: 8u: Backport 8163363: AArch64: Stack size in tools/launcher/Settings.java needs to be adjusted In-Reply-To: <30a6fc40-a0cc-3944-5bee-27e8acc65134@redhat.com> References: <30a6fc40-a0cc-3944-5bee-27e8acc65134@redhat.com> Message-ID: <2dfe2013-f222-e8e4-394f-5349f59ec1bc@redhat.com> On 07/08/2019 04:37, Andrew John Hughes wrote: > On 05/08/2019 17:23, Andrew Dinn wrote: >> I would like permission to backport this fix to the >> jdk8u-aarch64-shenandoah repo. This fixes the minimum stack size used by >> jdk/test/tools/launcher/Settings.java so that it is large enough to >> allow the test to pass on AArch64 implementations where it previously >> failed. >> >> The backport requires a minor tweak to the original patch as per the >> following webrev: >> >> http://cr.openjdk.java.net/~adinn/8163363-jdk8u/webrev.00/ >> >> regards, > > Then shouldn't this go to the aarch64-port-dev list? Yes, and it has. I blind copied the forward to this list but it got held up waiting for approval because of using bcc. Apologies for the noise. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From neugens at redhat.com Wed Aug 7 09:07:36 2019 From: neugens at redhat.com (Mario Torre) Date: Wed, 7 Aug 2019 11:07:36 +0200 Subject: RFC: backport of JDK-8210863: Remove Xrandr include files from JDK sources In-Reply-To: References: Message-ID: Hi Aleksey. I generated a new webrev for both patches: http://cr.openjdk.java.net/~neugens/JDK-8213944/ The second patch required some rework, so I would like some help testing this since I don't have an AIX system. Cheers, Mario On Tue, Jul 30, 2019 at 1:50 PM Mario Torre wrote: > > Make sense, I didn't realise this was needed as this seems specific to AIX. > > I'll send the patch shortly. > > Cheers, > Mario > > On Tue, Jul 30, 2019 at 1:40 PM Aleksey Shipilev wrote: > > > > On 7/30/19 12:22 PM, Mario Torre wrote: > > > I would like to backport the following bug into jdk8u-dev: > > > https://bugs.openjdk.java.net/browse/JDK-8210863 > > > > I believe we also need to backport the configure check as well then: > > https://bugs.openjdk.java.net/browse/JDK-8213944 > > > > -- > > Thanks, > > -Aleksey > > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From shade at redhat.com Wed Aug 7 10:53:02 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 7 Aug 2019 12:53:02 +0200 Subject: [8u] RFR (S) 8223177: Data race on JvmtiEnvBase::_tag_map in double-checked locking Message-ID: <798ff717-a966-2ca2-9f9d-56f8019f78a9@redhat.com> Original bug: https://bugs.openjdk.java.net/browse/JDK-8223177 https://hg.openjdk.java.net/jdk/jdk/rev/27c8a2e0b0e5 This patch applies to 8u, but does not compile, because regular OrderAccess methods do not accept pointers. We need to use the *_ptr_* versions of the same methods and do casts from void*. 8u webrev: http://cr.openjdk.java.net/~shade/8223177/webrev.8u.01/ Testing: tier1 -- Thanks, -Aleksey From felix.yang at huawei.com Wed Aug 7 11:42:10 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 7 Aug 2019 11:42:10 +0000 Subject: [Ping] Re: Request for Approval: Backport of 8146792 : Predicate moved after partial peel may lead to broken graph Message-ID: I saw your approval flag in the bug database, but there was no mention of whether the patch applied cleanly or not. I see no webrev link either there or in this e-mail. Can you clarify what you mean by "almost clean" or maybe just provide a webrev for review? Hi, Sorry, I should have sent the webrev in my first e-mail. http://cr.openjdk.java.net/~fyang/8146792-backport/webrev.00/ The only difference: the following change from the original patch is not needed as it is already there in the 8u repo. --- src/share/vm/opto/loopPredicate.cpp Tue Jan 12 10:44:41 2016 -1000 +++ src/share/vm/opto/loopPredicate.cpp Mon Jan 11 16:02:42 2016 +0100 @@ -665,6 +689,7 @@ if (scale != 1) { ConNode* con_scale = _igvn.intcon(scale); + set_ctrl(con_scale, C->root()); max_idx_expr = new MulINode(max_idx_expr, con_scale); register_new_node(max_idx_expr, ctrl); if (TraceLoopPredicate) predString->print("* %d ", scale); Thanks, Felix From sgehwolf at redhat.com Wed Aug 7 14:36:49 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 07 Aug 2019 16:36:49 +0200 Subject: PING? [8u] RFR: 8135318: CMS wrong max_eden_size for check_gc_overhead_limit In-Reply-To: References: Message-ID: <5a5800679e314ee3b5545323bb156eff5475b091.camel@redhat.com> On Tue, 2019-07-09 at 14:37 +0200, Severin Gehwolf wrote: > Hi, > > Could I please get a review for this OpenJDK 8u backport? It's > essentially the same patch as in JDK 9+, but it didn't apply cleanly > since the surrounding code is different and the files were moved > around. > > Adjustments I've done: > > JDK 8u uses a different file layout: > > src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp => > src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp > > JDK 8u doesn't have JDK-8065972 and JDK-8065992, which account for the > surrounding code changes. Note that JDK-8065992 makes the _young_gen > instance variable ParNewGEneration* from Generation*. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8135318 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8135318/01/webrev/ > JDK 9 change: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/dd0c55eac358 > > Testing: "tier1" testing of Linux x86_64 which showed no new regressions. > > Thoughts? Anyone? Thanks, Severin From stooke at redhat.com Wed Aug 7 14:52:46 2019 From: stooke at redhat.com (Simon Tooke) Date: Wed, 7 Aug 2019 10:52:46 -0400 Subject: [8u] RFR backport of JDK-8150432: java/util/Locale/LocaleProviders.sh failed on Win10. Message-ID: <9812fd37-cb6c-263e-fa6c-7766f439a287@redhat.com> Hi, I'd like to request a backport of JDK-8150432. The patch (from JDK9 pre repo merge) applies cleanly and fixes the issue encountered by some JDK 8 developers who run tests on a newer version of Cygwin than the test was written for.? If you look at LocaleProviders.sh, it has many hard-coded OS versions with differing behaviours and no explanation; but this fix (that I propose backporting) exists and addresses the current issue. Original bug: https://bugs.openjdk.java.net/browse/JDK-8150432 Original patch: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/91a26000bfb5 Thank you for your time, -Simon From shade at redhat.com Wed Aug 7 15:17:55 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 7 Aug 2019 17:17:55 +0200 Subject: [8u] RFR 8214687: Optimize Collections.nCopies().hashCode() and equals() In-Reply-To: <54ca6359-d827-aa9c-7d17-c480989675a0@redhat.com> References: <43caafb3-239a-0829-9665-71dcae9bea01@redhat.com> <1d7e6380-912e-126b-e09f-4a77e22af240@redhat.com> <41ee101b-ec08-5e17-a9cc-5fe4e646f9da@redhat.com> <54ca6359-d827-aa9c-7d17-c480989675a0@redhat.com> Message-ID: On 7/31/19 6:08 PM, Aleksey Shipilev wrote: > On 7/31/19 5:56 PM, Andrew John Hughes wrote: >> On 31/07/2019 10:02, Aleksey Shipilev wrote: >>> On 7/16/19 9:25 AM, Andrew John Hughes wrote: >>>> On 15/07/2019 09:27, Aleksey Shipilev wrote: >>> Getting back to this. Since we have moved Preconditions to private location in 8u, using it is >>> impossible for this patch. So, I would keep the webrev as is: >>> https://cr.openjdk.java.net/~shade/8214687/webrev.8u.01 >> >> We haven't moved anything as yet and my proposed patch leaves the class >> as public, so shouldn't be a blocker. The test in that patch uses >> Preconditions. > > Original patch needs Objects.checkIndex: > https://hg.openjdk.java.net/jdk/jdk/rev/cfceb4df2499#l2.32 > > What you are suggesting is changing that line to Preconditions (with new method!). What webrev > suggests is replacing it with the one-liner: > > 91 check(0 <= index && index < n, "Index is incorrect"); > > Given that we are changing the code anyway, I don't see why do we need to introduce another > dependency to the about-to-be-moved class, do more code that diverges 8u from later releases, > instead of doing the trivial one-liner. Thoughts? -- Thanks, -Aleksey From shade at redhat.com Wed Aug 7 15:47:41 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 7 Aug 2019 17:47:41 +0200 Subject: PING? [8u] RFR: 8135318: CMS wrong max_eden_size for check_gc_overhead_limit In-Reply-To: <5a5800679e314ee3b5545323bb156eff5475b091.camel@redhat.com> References: <5a5800679e314ee3b5545323bb156eff5475b091.camel@redhat.com> Message-ID: On 8/7/19 4:36 PM, Severin Gehwolf wrote: > On Tue, 2019-07-09 at 14:37 +0200, Severin Gehwolf wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8135318 >> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8135318/01/webrev/ >> JDK 9 change: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/dd0c55eac358 Backport looks good. Looks like a simple fix without any bug tail. So the code in 8u would now compute eden size as "max_young - 2*survivor", which makes sense: eden, plus from/to survivor spaces. Before it computed it as "max_young - 3*survivor", which is erroneous. (It is weird DefNewGeneration::max_capacity() discounts survivor space size, leading to this problem...) Right? -- Thanks, -Aleksey From gnu.andrew at redhat.com Wed Aug 7 16:30:00 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 7 Aug 2019 17:30:00 +0100 Subject: RFC: backport of JDK-8210863: Remove Xrandr include files from JDK sources In-Reply-To: References: Message-ID: On 07/08/2019 10:07, Mario Torre wrote: > Hi Aleksey. > > I generated a new webrev for both patches: > > http://cr.openjdk.java.net/~neugens/JDK-8213944/ > > The second patch required some rework, so I would like some help > testing this since I don't have an AIX system. > > Cheers, > Mario > I thought we already said no to this change? -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From neugens at redhat.com Wed Aug 7 16:36:36 2019 From: neugens at redhat.com (Mario Torre) Date: Wed, 7 Aug 2019 18:36:36 +0200 Subject: RFC: backport of JDK-8210863: Remove Xrandr include files from JDK sources In-Reply-To: References: Message-ID: On Wed, Aug 7, 2019 at 6:30 PM Andrew John Hughes wrote: > > > > On 07/08/2019 10:07, Mario Torre wrote: > > Hi Aleksey. > > > > I generated a new webrev for both patches: > > > > http://cr.openjdk.java.net/~neugens/JDK-8213944/ > > > > The second patch required some rework, so I would like some help > > testing this since I don't have an AIX system. > > > > Cheers, > > Mario > > > > I thought we already said no to this change? Well, you were the one expressing concern but it wasn't clear it's a final no, so should I drop this one for good? Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From serguei.spitsyn at oracle.com Wed Aug 7 20:57:34 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 7 Aug 2019 13:57:34 -0700 Subject: [8u] RFR (S) 8223177: Data race on JvmtiEnvBase::_tag_map in double-checked locking In-Reply-To: <798ff717-a966-2ca2-9f9d-56f8019f78a9@redhat.com> References: <798ff717-a966-2ca2-9f9d-56f8019f78a9@redhat.com> Message-ID: Hi Aleksey, The backport looks good. Thanks, Serguei On 8/7/19 03:53, Aleksey Shipilev wrote: > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8223177 > https://hg.openjdk.java.net/jdk/jdk/rev/27c8a2e0b0e5 > > This patch applies to 8u, but does not compile, because regular OrderAccess methods do not accept > pointers. We need to use the *_ptr_* versions of the same methods and do casts from void*. > > 8u webrev: > http://cr.openjdk.java.net/~shade/8223177/webrev.8u.01/ > > Testing: tier1 > From gil at azul.com Thu Aug 8 05:00:29 2019 From: gil at azul.com (Gil Tene) Date: Thu, 8 Aug 2019 05:00:29 +0000 Subject: Backport proposal of the Marlin renderer in OpenJDK8 In-Reply-To: References: Message-ID: <7539DA05-ACC0-4BB2-8ED5-BC2F32F99ABE@azul.com> Cross-posting to jdk8u-dev > On Aug 7, 2019, at 7:51 AM, Gil Tene wrote: > > As our all of our Zulu 8 builds already integrate Marlin as our default renderer, > test it with every build, and support a multitude of both free and commercial > customers using it, we (Azul) are wholeheartedly supportive of including Marlin > in 8u. We will actively participate in back-porting fixes, solving problems that may > happen in production systems in 8u, and (obviously) upstreaming any fixes we > end up doing to Marlin code in Zulu 8. > > Sent from my iPad > >> On Aug 7, 2019, at 2:33 AM, Laurent Bourg?s wrote: >> >> Dear Mario, >> >>> Le mer. 7 ao?t 2019 ? 10:40, Mario Torre a ?crit : >>> >>> Hi Laurent, >>> >>> I would be supportive with this if we had help backporting fixes and >>> solving problems that may happen in production systems in 8u. >>> >> >> As you probably know, I am the single maintainer of the Marlin renderer, >> all that FOSS work is done on my spare time with very low funding (gofundme >> campaign only). >> >> I can do the backporting work concerning the Marlin renderer as I do its >> main development on OpenJDK8 already. >> >> Anyway if any bug in the renderer is found, I already do the >> synchronization to fix all active branches: >> - my github: jdk8, jdk, jfx (8 branches) >> - jdk (14), jfx-dev (14) >> - jdk11u >> ... >> - jetbrains jdk8u_jdk PR on github >> >> I could maintain 1 more openjdk8 branch but like you, I would appreciate >> any help on backporting & testing. >> >> Cheers, >> Laurent >> >> >>> On Wed, Aug 7, 2019 at 10:05 AM Laurent Bourg?s >>> wrote: >>>> >>>> Hi, >>>> >>>> I want to discuss the opportunity to provide the Marlin renderer in >>> OpenJDK8 updates. >>>> >>>> FYI it is the java2d antialiasing renderer that replaced Pisces in >>> OpenJDK9 (integrated in 2015) that provide both better quality and >>> performance. >>>> I am still maintaining the code on github, openjdk and openjfx. >>>> FYI the Marlin renderer has a very efficient path clipper since v0.9 >>> integrated in OpenJDK11 (2018.7). >>>> Very few bugs (<5) were reported since 2015. >>>> >>>> Risks: azul zulu 8 and jetbrains jdk8 provide the Marlin renderer as >>> their default renderer and it runs in production for years. >>>> I am aware that amazon corretto would like to have it backported too. >>>> AdoptOpenJDK already mentioned such possible backport on their web pages. >>>> >>>> Finally I propose to >>>> - make a large patch (same marlin version as latest openjdk 14 ie >>> 0.9.1.1) to easily backport fixes in the future >>>> - leave it disabled by default. It will depend on the provider to enable >>> it in its binary releases. >>>> >>>> Cheers, >>>> Laurent >>> >>> >>> >>> -- >>> Mario Torre >>> Associate Manager, Software Engineering >>> Red Hat GmbH >>> 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 >>> From bourges.laurent at gmail.com Thu Aug 8 07:18:46 2019 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 8 Aug 2019 09:18:46 +0200 Subject: Backport proposal of the Marlin renderer in OpenJDK8 In-Reply-To: <7539DA05-ACC0-4BB2-8ED5-BC2F32F99ABE@azul.com> References: <7539DA05-ACC0-4BB2-8ED5-BC2F32F99ABE@azul.com> Message-ID: Hi, I am switching to jdk8u-dev too. Le jeu. 8 ao?t 2019 ? 07:00, Gil Tene a ?crit : > Cross-posting to jdk8u-dev > > > On Aug 7, 2019, at 7:51 AM, Gil Tene wrote: > > > > As our all of our Zulu 8 builds already integrate Marlin as our default > renderer, > > test it with every build, and support a multitude of both free and > commercial > > customers using it, we (Azul) are wholeheartedly supportive of including > Marlin > > in 8u. We will actively participate in back-porting fixes, solving > problems that may > > happen in production systems in 8u, and (obviously) upstreaming any > fixes we > > end up doing to Marlin code in Zulu 8. > Thank you Gil and the Azul team for your feedback & help offer, I wonder who in your zulu team could join the discussion and work with me on this topic ? In particular, you already listed and backported all jdk9->11 patches into your jdk8 repository. For me, the only needed change between jdk & jdk8u concerns the RenderingEngine class: - jdk8 uses ServiceLoader and its property file - changing or not the default engine: pisces -> double-precision marlin rendering engine > This class change must stay specific to jdk8u, as a different patch. Finally I wonder if we should backport each individual jdk9, 10, 11, 14 patches into jdk8u as a long train or you would accept 1 large patch gathering all patches. Of course, the latter approach seems simpler to me, but it requires a careful review to ascertain the code is the same with the current jdk repository (jdk 14). Once jdk8u & jdk14 have Marlin renderer 0.9.1.2, we will simply backport future changes. PS: I compared the performance on OpenJDK 8 (jdk8u latest) between Pisces & Marlin renderers = 3.5 times faster at 95% percentiles (MapBench): https://github.com/bourgesl/bourgesl.github.io/blob/master/openjdk8/ojdk8u_pisces.log https://github.com/bourgesl/bourgesl.github.io/blob/master/openjdk8/ojdk8u_marlin_0941.log Cheers, Laurent > >> On Aug 7, 2019, at 2:33 AM, Laurent Bourg?s > wrote: > >> > >> Dear Mario, > >> > >>> Le mer. 7 ao?t 2019 ? 10:40, Mario Torre a ?crit > : > >>> > >>> Hi Laurent, > >>> > >>> I would be supportive with this if we had help backporting fixes and > >>> solving problems that may happen in production systems in 8u. > >>> > >> > >> As you probably know, I am the single maintainer of the Marlin renderer, > >> all that FOSS work is done on my spare time with very low funding > (gofundme > >> campaign only). > >> > >> I can do the backporting work concerning the Marlin renderer as I do its > >> main development on OpenJDK8 already. > >> > >> Anyway if any bug in the renderer is found, I already do the > >> synchronization to fix all active branches: > >> - my github: jdk8, jdk, jfx (8 branches) > >> - jdk (14), jfx-dev (14) > >> - jdk11u > >> ... > >> - jetbrains jdk8u_jdk PR on github > >> > >> I could maintain 1 more openjdk8 branch but like you, I would appreciate > >> any help on backporting & testing. > >> > >> Cheers, > >> Laurent > >> > >> > >>> On Wed, Aug 7, 2019 at 10:05 AM Laurent Bourg?s > >>> wrote: > >>>> > >>>> Hi, > >>>> > >>>> I want to discuss the opportunity to provide the Marlin renderer in > >>> OpenJDK8 updates. > >>>> > >>>> FYI it is the java2d antialiasing renderer that replaced Pisces in > >>> OpenJDK9 (integrated in 2015) that provide both better quality and > >>> performance. > >>>> I am still maintaining the code on github, openjdk and openjfx. > >>>> FYI the Marlin renderer has a very efficient path clipper since v0.9 > >>> integrated in OpenJDK11 (2018.7). > >>>> Very few bugs (<5) were reported since 2015. > >>>> > >>>> Risks: azul zulu 8 and jetbrains jdk8 provide the Marlin renderer as > >>> their default renderer and it runs in production for years. > >>>> I am aware that amazon corretto would like to have it backported too. > >>>> AdoptOpenJDK already mentioned such possible backport on their web > pages. > >>>> > >>>> Finally I propose to > >>>> - make a large patch (same marlin version as latest openjdk 14 ie > >>> 0.9.1.1) to easily backport fixes in the future > >>>> - leave it disabled by default. It will depend on the provider to > enable > >>> it in its binary releases. > >>>> > >>>> Cheers, > >>>> Laurent > >>> > >>> > >>> > >>> -- > >>> Mario Torre > >>> Associate Manager, Software Engineering > >>> Red Hat GmbH > >>> 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > >>> > > From neugens at redhat.com Thu Aug 8 10:19:21 2019 From: neugens at redhat.com (Mario Torre) Date: Thu, 8 Aug 2019 12:19:21 +0200 Subject: [JFR] Port Status Message-ID: Hi all, I just updated the staging repository with the latest code from the jdk8u repository. I also added a new label on Jira: jfr-jdk8u-backport This can be used to track down all the patches we are backporting in the staging repository and later on into mainline 8u. This should make it easier to track things around. I think one label is enough, if we want to mark a distinction on patches we "want" to backport as opposed to the one we "did" backport we can add another label, i.e. jfr-jdk8u-backport-staging, but I don't see much reason to do this, any suggestions? Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From goetz.lindenmaier at sap.com Thu Aug 8 10:34:59 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 8 Aug 2019 10:34:59 +0000 Subject: Changes to 8u and 11u process In-Reply-To: <1462b721-29ce-8db5-6661-0fdd60dd1245@redhat.com> References: <51f754b2-a7c0-8157-76fb-6a5bd2d089c6@redhat.com> <1462b721-29ce-8db5-6661-0fdd60dd1245@redhat.com> Message-ID: Hi Aleksey, > On 8/6/19 3:46 PM, Andrew Haley wrote: > > Backports which have already been approved by Oracle for their > > proprietary fork will no longer need approval for 8u- and 11u-open. > > There are two reasons for this. Firstly, it's safe to assume that > > Oracle have done their due diligence with regard to suitability. > > Secondly, it's a waste of effort on the part of the maintainer. > > I vehemently oppose this rule. > > First, this dismantles the consistency of the process ("every change should be > approved, here is the > checklist [1]") for the sake of less maintainer work (which can be alleviate by > assigning more > maintainers, as we did with Christoph). Having a single checklist for everything > is simpler to > remember, simpler to act upon, and it provides less cognitive load. We need to > continue doing the > same thing on all paths, and if on some of those paths it would reduce to > mechanical rubber-stamping > work, so be it. It is the same as with code reviews in trivial patches: we do not > circumvent the > review process by telling "trivial patches do not need review", we just say > "trivial patches enjoy > more mechanical rubber-stamping approach". You can as well argue that the need to get an approval for a change increases the work and thus the possibility to make errors. You can not expect the maintainer to approve changes on a daily basis. Thus, you get quite some delays with the work on the changes. You downport them, test them, ask for approval, and once you get it you need to rebase the change and retest them. This rebasing and retesting is overhead that could be avoided. Also, personally, I don't like working on too much changes in parallel. If getting the approval takes a week, this limits efficiency. From my work on our internal JVMs, I know that you can move quite a lot of changes on a single day without breaking anything. > Second, summarily accepting every Oracle-proprietary change dismantles the > maintainers' > responsibility over everything in JDK Updates projects. There are changes that > could be rejected > from JDK Updates, even if Oracle-internal repositories have it: platforms not > supported, features > not maintained, cleanups not needed. We have to reserve the opportunity to > act upon this, if/when > needed. It feels like this rule should just go to maintainer's rule book: once > somebody requests the > backport for something Oracle-proprietary fork has, rubber-stamp it. But do > not summarily relinquish > maintainer's power to veto. Why should we reject changes to a platform supported by Oracle but not by OpenJDK? Has there ever been a change downported by Oracle that was not taken into OpenJDK 11? And if the two projects OpenJDK 11 and OracleJDK 11 would diverge so that this happens, we still could change the policy again. I would appreciate if the "Fix Request" comment would still be mandatory, simply to indicate someone is working on a change. But I really think the tagging is unnecessary overhead for the Oracle changes. And anybody who misunderstands this and puts a jdk11u-fix-request tag there, will get an approval and no harm is done. And well, yes, it would be bad if it happened the other way around. But people being less involved in the updates project probably come up with changes of their own for which the established process holds and thus never get in touch with this "shortcut rule". For testbug fixes not downported by Oracle we should maybe request tagging, but for changes downported by Oracle we should relax this rule I think. Best regards, Goetz. > > Backports of fixes to tests no longer need to be approved, but they > > should still be reviewed if there are any changes. > > Same thing as above. > > > Where it makes sense, please minimize the size of the patches. If you > > can adapt a backport patch to fit rather than also backporting a bunch > > of its dependencies, please consider doing so. Bear in mind that > > stability is the most important feature that these updates projects > > have. Simple history in backports is important: it's more important to > > reduce the volume of changes to 8u and 11u than it is to reduce the > > differences between the backports and head. > > Understanding that retrofitting the patch comes with the risks in itself, in many > cases bringing up > more code is better, if it minimizes the difference against other versions, > applies mechanically, > matches the history of the later code. So, I think we should default to bringing > in the patches > wholesale, and leave it to maintainers/reviewers to ask backporters to cut the > patches shorter if > maintainers/reviewers argue there is no reason to bring large change with it. It > happened multiple > times already, and I don't think it needs to be changed. > > -- > Thanks, > -Aleksey > > [1] > https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix From aph at redhat.com Thu Aug 8 10:50:37 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 8 Aug 2019 11:50:37 +0100 Subject: Changes to 8u and 11u process In-Reply-To: <084f5815-6d39-f8a2-01a5-244a1a4c2905@redhat.com> References: <51f754b2-a7c0-8157-76fb-6a5bd2d089c6@redhat.com> <084f5815-6d39-f8a2-01a5-244a1a4c2905@redhat.com> Message-ID: On 8/7/19 4:36 AM, Andrew John Hughes wrote: > I would point out that the decisions made by Oracle for their > proprietary fork are opaque to us, and so to do as proposed would be > to essentially hand control of the majority of our work to a black > box. I am vehemently of the opinion that the OpenJDK projects should > remain independent of such proprietary forks. Everybody's vehement today. :-) It's not in the best interests of Free Software that we diverge significantly from Oracle because we must maintain an easy path from closed to open. Sure, we can add features like, say, Shenandoah, but we shouldn't miss any. So, decisions about whether to accept a backport that Oracle has already accepted are going to be pretty much automatic. While it'd be nice if we were the masters of all we survey, it's not going to happen: better that we accept or place in all of this, which is to do our part to help the masses reach the sunlit uplands of freedom. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From peter.levart at gmail.com Thu Aug 8 11:12:16 2019 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 8 Aug 2019 13:12:16 +0200 Subject: Changes to 8u and 11u process In-Reply-To: References: <51f754b2-a7c0-8157-76fb-6a5bd2d089c6@redhat.com> <1462b721-29ce-8db5-6661-0fdd60dd1245@redhat.com> Message-ID: Hi, On 8/8/19 12:34 PM, Lindenmaier, Goetz wrote: > Hi Aleksey, > >> On 8/6/19 3:46 PM, Andrew Haley wrote: >>> Backports which have already been approved by Oracle for their >>> proprietary fork will no longer need approval for 8u- and 11u-open. >>> There are two reasons for this. Firstly, it's safe to assume that >>> Oracle have done their due diligence with regard to suitability. >>> Secondly, it's a waste of effort on the part of the maintainer. >> I vehemently oppose this rule. >> >> First, this dismantles the consistency of the process ("every change should be >> approved, here is the >> checklist [1]") for the sake of less maintainer work (which can be alleviate by >> assigning more >> maintainers, as we did with Christoph). Having a single checklist for everything >> is simpler to >> remember, simpler to act upon, and it provides less cognitive load. We need to >> continue doing the >> same thing on all paths, and if on some of those paths it would reduce to >> mechanical rubber-stamping >> work, so be it. It is the same as with code reviews in trivial patches: we do not >> circumvent the >> review process by telling "trivial patches do not need review", we just say >> "trivial patches enjoy >> more mechanical rubber-stamping approach". > You can as well argue that the need to get an approval for a change > increases the work and thus the possibility to make errors. > You can not expect the maintainer to approve changes on a daily > basis. Thus, you get quite some delays with the work on the changes. > You downport them, test them, ask for approval, and once you get > it you need to rebase the change and retest them. This rebasing and retesting > is overhead that could be avoided. Also, personally, I don't like working > on too much changes in parallel. If getting the approval takes a week, > this limits efficiency. From my work on our internal JVMs, I know that > you can move quite a lot of changes on a single day without breaking > anything. What about allowing for such changes to be pushed "optimistically" immediately after posting the request for approval (jdk11u-fix-request). If such change gets rejected, it would be backed-out and then possibly further worked on as a normal change that needs to be pre-approved before being pushed again. Regards, Peter From shade at redhat.com Thu Aug 8 11:26:47 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 8 Aug 2019 13:26:47 +0200 Subject: Changes to 8u and 11u process In-Reply-To: References: <51f754b2-a7c0-8157-76fb-6a5bd2d089c6@redhat.com> <1462b721-29ce-8db5-6661-0fdd60dd1245@redhat.com> Message-ID: Hi, On 8/8/19 12:34 PM, Lindenmaier, Goetz wrote: > You can as well argue that the need to get an approval for a change > increases the work and thus the possibility to make errors. Hm, I reject the premise that more work means more errors, especially when "work" is (re)testing, reviews, checks, approvals. > You can not expect the maintainer to approve changes on a daily > basis. Thus, you get quite some delays with the work on the changes. > You downport them, test them, ask for approval, and once you get > it you need to rebase the change and retest them. This rebasing and retesting > is overhead that could be avoided. Also, personally, I don't like working > on too much changes in parallel. If getting the approval takes a week, > this limits efficiency. From my work on our internal JVMs, I know that > you can move quite a lot of changes on a single day without breaking > anything. Yes, I understand that is more overhead. That is a feature, not a bug though: the fact that maintainers have to ack the pushes makes them responsible gatekeepers. So, they can actually control what goes in, when it does, how much due diligence is done for it (testing, related/follow-up fixes), etc. It is my hard opinion that maintainers have to "co-own" every push that happens, by the applying approvals/rejects unconditionally. I am also doing lots of backports, and yes, my patch queue is usually full with simple patches. At the same time, I do believe waiting for someone responsible to cross-check my work, no matter how trivial it looks to me, is a major process feature. Granted, the larger gap between fix-request and the subsequent approval does make it a bit harder. I believe this would be improved by having more maintainers, like adding Christoph. I do not see the reason to both add maintainers and relax the requirements at the same time. > Why should we reject changes to a platform supported by Oracle but not > by OpenJDK? Has there ever been a change downported by Oracle that > was not taken into OpenJDK 11? Not yet, but it does not mean there would not be. Process planning should see and plan for the exceptional possibilities before those exceptions arise. I do not also believe Oracle should be treated preferentially here. The changes Oracle backports should be scrutinized as well, and maybe rejected when they do not hold to the scrutiny. The fact they mostly do today does not mean it would be the same tomorrow. It does give maintainers themselves some adjustments to their perception of risk/benefit when approving/rejecting those backports, but that's the decision the maintainer should make, not everyone with push privileges. > And if the two projects OpenJDK 11 and OracleJDK 11 would diverge so > that this happens, we still could change the policy again. Changing policy again would be even more confusing. Human-facing policies are not computer code, there is so much hysteresis between changing the policy and its proliferation. From my observations how people learn and apply the rules, having the overheady but steady ruleset is much, much, much better than having the "optimized" branchy ruleset. Let people use the single checklist they learned already, and fly with that. > But people being less involved in > the updates project probably come up with changes of their own for which > the established process holds and thus never get in touch with this > "shortcut rule". I suspect what would really happen is this: non-involved people would look into JIRA, discover issues that are pushed without approval (oblivious of the shortcut rule), assume no approval is needed for their issue at hand, push their non-Oracle-existing backport without approvals. That's what you would get for having exceptions in the ruleset. Please do not shortcut. -Aleksey From shade at redhat.com Thu Aug 8 15:33:53 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 8 Aug 2019 17:33:53 +0200 Subject: [8u] RFR (S) 8218201: Failures when vmIntrinsics::_getClass is not inlined Message-ID: <1b899228-d9c0-0f8e-f86c-803c384a24bc@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8218201 https://hg.openjdk.java.net/jdk/jdk/rev/a2d3ca8062b9 8u version needs a few adjustments, because context is a bit different. The new change should be functionally equivalent to what we have in jdk/jdk. 8u webrev: https://cr.openjdk.java.net/~shade/8218201/webrev.8u.01/ Testing: affected test (fails without the patch, passes with it); tier1 -- Thanks, -Aleksey From martijnverburg at gmail.com Thu Aug 8 15:35:02 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 8 Aug 2019 16:35:02 +0100 Subject: Backport proposal of the Marlin renderer in OpenJDK8 In-Reply-To: References: <7539DA05-ACC0-4BB2-8ED5-BC2F32F99ABE@azul.com> Message-ID: +1 to this, we'll (Adopt) happily help with the backport and testing as well. Let us know if/when there's a forest we can contribute to, build and test from. Cheers, Martijn On Thu, 8 Aug 2019 at 08:19, Laurent Bourg?s wrote: > Hi, > I am switching to jdk8u-dev too. > > Le jeu. 8 ao?t 2019 ? 07:00, Gil Tene a ?crit : > > > Cross-posting to jdk8u-dev > > > > > On Aug 7, 2019, at 7:51 AM, Gil Tene wrote: > > > > > > As our all of our Zulu 8 builds already integrate Marlin as our default > > renderer, > > > test it with every build, and support a multitude of both free and > > commercial > > > customers using it, we (Azul) are wholeheartedly supportive of > including > > Marlin > > > in 8u. We will actively participate in back-porting fixes, solving > > problems that may > > > happen in production systems in 8u, and (obviously) upstreaming any > > fixes we > > > end up doing to Marlin code in Zulu 8. > > > > Thank you Gil and the Azul team for your feedback & help offer, I wonder > who in your zulu team could join the discussion and work with me on this > topic ? > > In particular, you already listed and backported all jdk9->11 patches into > your jdk8 repository. > > For me, the only needed change between jdk & jdk8u concerns the > RenderingEngine class: > - jdk8 uses ServiceLoader and its property file > - changing or not the default engine: pisces -> double-precision marlin > rendering engine > > > > This class change must stay specific to jdk8u, as a different patch. > > Finally I wonder if we should backport each individual jdk9, 10, 11, 14 > patches into jdk8u as a long train or you would accept 1 large patch > gathering all patches. > Of course, the latter approach seems simpler to me, but it requires a > careful review to ascertain the code is the same with the current jdk > repository (jdk 14). > Once jdk8u & jdk14 have Marlin renderer 0.9.1.2, we will simply backport > future changes. > > PS: I compared the performance on OpenJDK 8 (jdk8u latest) between Pisces & > Marlin renderers = 3.5 times faster at 95% percentiles (MapBench): > > https://github.com/bourgesl/bourgesl.github.io/blob/master/openjdk8/ojdk8u_pisces.log > > https://github.com/bourgesl/bourgesl.github.io/blob/master/openjdk8/ojdk8u_marlin_0941.log > > Cheers, > Laurent > > > > >> On Aug 7, 2019, at 2:33 AM, Laurent Bourg?s < > bourges.laurent at gmail.com> > > wrote: > > >> > > >> Dear Mario, > > >> > > >>> Le mer. 7 ao?t 2019 ? 10:40, Mario Torre a > ?crit > > : > > >>> > > >>> Hi Laurent, > > >>> > > >>> I would be supportive with this if we had help backporting fixes and > > >>> solving problems that may happen in production systems in 8u. > > >>> > > >> > > >> As you probably know, I am the single maintainer of the Marlin > renderer, > > >> all that FOSS work is done on my spare time with very low funding > > (gofundme > > >> campaign only). > > >> > > >> I can do the backporting work concerning the Marlin renderer as I do > its > > >> main development on OpenJDK8 already. > > >> > > >> Anyway if any bug in the renderer is found, I already do the > > >> synchronization to fix all active branches: > > >> - my github: jdk8, jdk, jfx (8 branches) > > >> - jdk (14), jfx-dev (14) > > >> - jdk11u > > >> ... > > >> - jetbrains jdk8u_jdk PR on github > > >> > > >> I could maintain 1 more openjdk8 branch but like you, I would > appreciate > > >> any help on backporting & testing. > > >> > > >> Cheers, > > >> Laurent > > >> > > >> > > >>> On Wed, Aug 7, 2019 at 10:05 AM Laurent Bourg?s > > >>> wrote: > > >>>> > > >>>> Hi, > > >>>> > > >>>> I want to discuss the opportunity to provide the Marlin renderer in > > >>> OpenJDK8 updates. > > >>>> > > >>>> FYI it is the java2d antialiasing renderer that replaced Pisces in > > >>> OpenJDK9 (integrated in 2015) that provide both better quality and > > >>> performance. > > >>>> I am still maintaining the code on github, openjdk and openjfx. > > >>>> FYI the Marlin renderer has a very efficient path clipper since v0.9 > > >>> integrated in OpenJDK11 (2018.7). > > >>>> Very few bugs (<5) were reported since 2015. > > >>>> > > >>>> Risks: azul zulu 8 and jetbrains jdk8 provide the Marlin renderer as > > >>> their default renderer and it runs in production for years. > > >>>> I am aware that amazon corretto would like to have it backported > too. > > >>>> AdoptOpenJDK already mentioned such possible backport on their web > > pages. > > >>>> > > >>>> Finally I propose to > > >>>> - make a large patch (same marlin version as latest openjdk 14 ie > > >>> 0.9.1.1) to easily backport fixes in the future > > >>>> - leave it disabled by default. It will depend on the provider to > > enable > > >>> it in its binary releases. > > >>>> > > >>>> Cheers, > > >>>> Laurent > > >>> > > >>> > > >>> > > >>> -- > > >>> Mario Torre > > >>> Associate Manager, Software Engineering > > >>> Red Hat GmbH > > >>> 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > >>> > > > > > From mathiske at amazon.com Thu Aug 8 15:40:51 2019 From: mathiske at amazon.com (Mathiske, Bernd) Date: Thu, 8 Aug 2019 15:40:51 +0000 Subject: Backport proposal of the Marlin renderer in OpenJDK8 In-Reply-To: References: <7539DA05-ACC0-4BB2-8ED5-BC2F32F99ABE@azul.com> Message-ID: <79D99890-6D84-421C-B84A-7F4420AA23AD@amazon.com> +1 from Amazon. Looking forward to having Marlin in the fold. ?On 8/8/19, 8:36 AM, "jdk8u-dev on behalf of Martijn Verburg" wrote: +1 to this, we'll (Adopt) happily help with the backport and testing as well. Let us know if/when there's a forest we can contribute to, build and test from. Cheers, Martijn On Thu, 8 Aug 2019 at 08:19, Laurent Bourg?s wrote: > Hi, > I am switching to jdk8u-dev too. > > Le jeu. 8 ao?t 2019 ? 07:00, Gil Tene a ?crit : > > > Cross-posting to jdk8u-dev > > > > > On Aug 7, 2019, at 7:51 AM, Gil Tene wrote: > > > > > > As our all of our Zulu 8 builds already integrate Marlin as our default > > renderer, > > > test it with every build, and support a multitude of both free and > > commercial > > > customers using it, we (Azul) are wholeheartedly supportive of > including > > Marlin > > > in 8u. We will actively participate in back-porting fixes, solving > > problems that may > > > happen in production systems in 8u, and (obviously) upstreaming any > > fixes we > > > end up doing to Marlin code in Zulu 8. > > > > Thank you Gil and the Azul team for your feedback & help offer, I wonder > who in your zulu team could join the discussion and work with me on this > topic ? > > In particular, you already listed and backported all jdk9->11 patches into > your jdk8 repository. > > For me, the only needed change between jdk & jdk8u concerns the > RenderingEngine class: > - jdk8 uses ServiceLoader and its property file > - changing or not the default engine: pisces -> double-precision marlin > rendering engine > > > > This class change must stay specific to jdk8u, as a different patch. > > Finally I wonder if we should backport each individual jdk9, 10, 11, 14 > patches into jdk8u as a long train or you would accept 1 large patch > gathering all patches. > Of course, the latter approach seems simpler to me, but it requires a > careful review to ascertain the code is the same with the current jdk > repository (jdk 14). > Once jdk8u & jdk14 have Marlin renderer 0.9.1.2, we will simply backport > future changes. > > PS: I compared the performance on OpenJDK 8 (jdk8u latest) between Pisces & > Marlin renderers = 3.5 times faster at 95% percentiles (MapBench): > > https://github.com/bourgesl/bourgesl.github.io/blob/master/openjdk8/ojdk8u_pisces.log > > https://github.com/bourgesl/bourgesl.github.io/blob/master/openjdk8/ojdk8u_marlin_0941.log > > Cheers, > Laurent > > > > >> On Aug 7, 2019, at 2:33 AM, Laurent Bourg?s < > bourges.laurent at gmail.com> > > wrote: > > >> > > >> Dear Mario, > > >> > > >>> Le mer. 7 ao?t 2019 ? 10:40, Mario Torre a > ?crit > > : > > >>> > > >>> Hi Laurent, > > >>> > > >>> I would be supportive with this if we had help backporting fixes and > > >>> solving problems that may happen in production systems in 8u. > > >>> > > >> > > >> As you probably know, I am the single maintainer of the Marlin > renderer, > > >> all that FOSS work is done on my spare time with very low funding > > (gofundme > > >> campaign only). > > >> > > >> I can do the backporting work concerning the Marlin renderer as I do > its > > >> main development on OpenJDK8 already. > > >> > > >> Anyway if any bug in the renderer is found, I already do the > > >> synchronization to fix all active branches: > > >> - my github: jdk8, jdk, jfx (8 branches) > > >> - jdk (14), jfx-dev (14) > > >> - jdk11u > > >> ... > > >> - jetbrains jdk8u_jdk PR on github > > >> > > >> I could maintain 1 more openjdk8 branch but like you, I would > appreciate > > >> any help on backporting & testing. > > >> > > >> Cheers, > > >> Laurent > > >> > > >> > > >>> On Wed, Aug 7, 2019 at 10:05 AM Laurent Bourg?s > > >>> wrote: > > >>>> > > >>>> Hi, > > >>>> > > >>>> I want to discuss the opportunity to provide the Marlin renderer in > > >>> OpenJDK8 updates. > > >>>> > > >>>> FYI it is the java2d antialiasing renderer that replaced Pisces in > > >>> OpenJDK9 (integrated in 2015) that provide both better quality and > > >>> performance. > > >>>> I am still maintaining the code on github, openjdk and openjfx. > > >>>> FYI the Marlin renderer has a very efficient path clipper since v0.9 > > >>> integrated in OpenJDK11 (2018.7). > > >>>> Very few bugs (<5) were reported since 2015. > > >>>> > > >>>> Risks: azul zulu 8 and jetbrains jdk8 provide the Marlin renderer as > > >>> their default renderer and it runs in production for years. > > >>>> I am aware that amazon corretto would like to have it backported > too. > > >>>> AdoptOpenJDK already mentioned such possible backport on their web > > pages. > > >>>> > > >>>> Finally I propose to > > >>>> - make a large patch (same marlin version as latest openjdk 14 ie > > >>> 0.9.1.1) to easily backport fixes in the future > > >>>> - leave it disabled by default. It will depend on the provider to > > enable > > >>> it in its binary releases. > > >>>> > > >>>> Cheers, > > >>>> Laurent > > >>> > > >>> > > >>> > > >>> -- > > >>> Mario Torre > > >>> Associate Manager, Software Engineering > > >>> Red Hat GmbH > > >>> 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > >>> > > > > > From gnu.andrew at redhat.com Thu Aug 8 18:51:30 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 8 Aug 2019 19:51:30 +0100 Subject: Backport proposal of the Marlin renderer in OpenJDK8 In-Reply-To: References: <7539DA05-ACC0-4BB2-8ED5-BC2F32F99ABE@azul.com> Message-ID: On 08/08/2019 08:18, Laurent Bourg?s wrote: snip... >> > This class change must stay specific to jdk8u, as a different patch. > > Finally I wonder if we should backport each individual jdk9, 10, 11, 14 > patches into jdk8u as a long train or you would accept 1 large patch > gathering all patches. > Of course, the latter approach seems simpler to me, but it requires a > careful review to ascertain the code is the same with the current jdk > repository (jdk 14). > Once jdk8u & jdk14 have Marlin renderer 0.9.1.2, we will simply backport > future changes. > The individual changes should be backported. This assures that there is a record that these bugs are fixed in 8u, which is important for long-term maintainability. I would suspect the original JDK9 patch would be an easier backport too, given how much the build system has changed and the files have moved around in JDK head. A halfway option between the two would be to build up the required changes in a staging repository and then ask for a bulk review before integration into 8u. I believe this is how JFR is being backported. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Thu Aug 8 18:56:18 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 8 Aug 2019 19:56:18 +0100 Subject: [JFR] Port Status In-Reply-To: References: Message-ID: <90ce3c16-ce51-d116-532c-855761f8e3bc@redhat.com> On 08/08/2019 11:19, Mario Torre wrote: > Hi all, > > I just updated the staging repository with the latest code from the > jdk8u repository. I also added a new label on Jira: > > jfr-jdk8u-backport > > This can be used to track down all the patches we are backporting in > the staging repository and later on into mainline 8u. > > This should make it easier to track things around. > > I think one label is enough, if we want to mark a distinction on > patches we "want" to backport as opposed to the one we "did" backport > we can add another label, i.e. jfr-jdk8u-backport-staging, but I don't > see much reason to do this, any suggestions? > > Cheers, > Mario > One thing to consider is JDK-8202353: https://bugs.openjdk.java.net/browse/JDK-8202353 When I backported this, I had to drop JFR code changes. Compare: https://hg.openjdk.java.net/jdk/jdk/rev/f605c91e5219 and https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/0f2fe7d37d8c The bug: https://bugs.openjdk.java.net/browse/JDK-8202835 would be ideal to use to backport the remaining changes. The original changeset used both bug IDs, but the 8u one only used 8202353. 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 mbalao at redhat.com Thu Aug 8 19:40:07 2019 From: mbalao at redhat.com (Martin Balao) Date: Thu, 8 Aug 2019 16:40:07 -0300 Subject: [8u] RFR 8147502: Digest is incorrectly truncated for ECDSA signatures when the bit length of n is less than the field size Message-ID: Hi, I'd like to request a review for the jdk8u backport of 8147502 [1]: * http://cr.openjdk.java.net/~mbalao/webrevs/8147502/8147502.webrev.jdk8u.jdk.00/ Changes: * SignatureDigestTruncate.java * Import of jdk.testlibrary.Convert * @library and @build jtreg tags * Backport of Convert.java * Test algorithm (changes to one with jdk8u support) * I've verified that the signature gets truncated with this algorithm debugging the libsunec.so code * Test expected value * Verified with BouncyCastle * The curve is unsupported in NSS since 2006 (NSS 3.10) * I've also compared the patch against the NSS library Patch and copyright changes were also needed. SignatureDigestTruncate test passed. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8147502 From gnu.andrew at redhat.com Thu Aug 8 21:44:00 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 8 Aug 2019 22:44:00 +0100 Subject: Changes to 8u and 11u process In-Reply-To: References: <51f754b2-a7c0-8157-76fb-6a5bd2d089c6@redhat.com> <084f5815-6d39-f8a2-01a5-244a1a4c2905@redhat.com> Message-ID: <30ee8310-42a3-0d63-7985-61000be5e32a@redhat.com> On 08/08/2019 11:50, Andrew Haley wrote: > On 8/7/19 4:36 AM, Andrew John Hughes wrote: > >> I would point out that the decisions made by Oracle for their >> proprietary fork are opaque to us, and so to do as proposed would be >> to essentially hand control of the majority of our work to a black >> box. I am vehemently of the opinion that the OpenJDK projects should >> remain independent of such proprietary forks. > > Everybody's vehement today. :-) > > It's not in the best interests of Free Software that we diverge > significantly from Oracle because we must maintain an easy path from > closed to open. Sure, we can add features like, say, Shenandoah, but > we shouldn't miss any. So, decisions about whether to accept a > backport that Oracle has already accepted are going to be pretty much > automatic. > > While it'd be nice if we were the masters of all we survey, it's not > going to happen: better that we accept or place in all of this, which > is to do our part to help the masses reach the sunlit uplands of freedom. > Indeed. I'm familiar with these realities from our days on GNU Classpath and GCJ. However, it is worth acknowledging another reality; we only have a window into their JDK, not the whole picture. While the shared bug database means we can see some of the changes being made to the proprietary forks, there are enough private bugs to mean that we can never claim to not miss any. For example, in the last CPU, Oracle added the option to toggle the ECC implementation used, which I haven't seen referenced anywhere in the bug database. Although it may be used sparingly, if at all, I think we should retain the right to approve all bugs, especially as these legacy versions continue to diverge further from the main development tree. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Thu Aug 8 23:24:13 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 9 Aug 2019 00:24:13 +0100 Subject: Changes to 8u and 11u process In-Reply-To: References: <51f754b2-a7c0-8157-76fb-6a5bd2d089c6@redhat.com> <1462b721-29ce-8db5-6661-0fdd60dd1245@redhat.com> Message-ID: On 08/08/2019 12:26, Aleksey Shipilev wrote: snip... > >> But people being less involved in >> the updates project probably come up with changes of their own for which >> the established process holds and thus never get in touch with this >> "shortcut rule". > > I suspect what would really happen is this: non-involved people would look into JIRA, discover > issues that are pushed without approval (oblivious of the shortcut rule), assume no approval is > needed for their issue at hand, push their non-Oracle-existing backport without approvals. That's > what you would get for having exceptions in the ruleset. Please do not shortcut. > > -Aleksey > That's a good point. We already have confusion over when reviews are required, without adding further complication. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Thu Aug 8 23:30:43 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 9 Aug 2019 00:30:43 +0100 Subject: Changes to 8u and 11u process In-Reply-To: References: <51f754b2-a7c0-8157-76fb-6a5bd2d089c6@redhat.com> <1462b721-29ce-8db5-6661-0fdd60dd1245@redhat.com> Message-ID: On 08/08/2019 11:34, Lindenmaier, Goetz wrote: > Hi Aleksey, > >> On 8/6/19 3:46 PM, Andrew Haley wrote: >>> Backports which have already been approved by Oracle for their >>> proprietary fork will no longer need approval for 8u- and 11u-open. >>> There are two reasons for this. Firstly, it's safe to assume that >>> Oracle have done their due diligence with regard to suitability. >>> Secondly, it's a waste of effort on the part of the maintainer. >> >> I vehemently oppose this rule. >> >> First, this dismantles the consistency of the process ("every change should be >> approved, here is the >> checklist [1]") for the sake of less maintainer work (which can be alleviate by >> assigning more >> maintainers, as we did with Christoph). Having a single checklist for everything >> is simpler to >> remember, simpler to act upon, and it provides less cognitive load. We need to >> continue doing the >> same thing on all paths, and if on some of those paths it would reduce to >> mechanical rubber-stamping >> work, so be it. It is the same as with code reviews in trivial patches: we do not >> circumvent the >> review process by telling "trivial patches do not need review", we just say >> "trivial patches enjoy >> more mechanical rubber-stamping approach". > > You can as well argue that the need to get an approval for a change > increases the work and thus the possibility to make errors. > You can not expect the maintainer to approve changes on a daily > basis. Thus, you get quite some delays with the work on the changes. > You downport them, test them, ask for approval, and once you get > it you need to rebase the change and retest them. This rebasing and retesting > is overhead that could be avoided. Also, personally, I don't like working > on too much changes in parallel. If getting the approval takes a week, > this limits efficiency. From my work on our internal JVMs, I know that > you can move quite a lot of changes on a single day without breaking > anything. > It shouldn't take a week. That's a case for adding more maintainers to share the workload, not a reason to abandon the process altogether. I think ideally we should have at least three on each project, as currently a maintainer wanting a patch approved has to rely on a single individual for that approval. Working on a public project is fundamentally different to an internal project, as the impact of any change is much wider and others have to integrate your changes into their workflow (including those who may interact on the mailing lists little, if at all). I would rather things were done slowly and carefully than to wake up to a dozen new changes every morning. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From neugens at redhat.com Fri Aug 9 09:49:49 2019 From: neugens at redhat.com (Mario Torre) Date: Fri, 9 Aug 2019 11:49:49 +0200 Subject: [JFR] Port Status In-Reply-To: <90ce3c16-ce51-d116-532c-855761f8e3bc@redhat.com> References: <90ce3c16-ce51-d116-532c-855761f8e3bc@redhat.com> Message-ID: On Thu, Aug 8, 2019 at 8:56 PM Andrew John Hughes wrote: > > > On 08/08/2019 11:19, Mario Torre wrote: > > Hi all, > > > > I just updated the staging repository with the latest code from the > > jdk8u repository. I also added a new label on Jira: > > > > jfr-jdk8u-backport > > > > This can be used to track down all the patches we are backporting in > > the staging repository and later on into mainline 8u. > > > > This should make it easier to track things around. > > > > I think one label is enough, if we want to mark a distinction on > > patches we "want" to backport as opposed to the one we "did" backport > > we can add another label, i.e. jfr-jdk8u-backport-staging, but I don't > > see much reason to do this, any suggestions? > > > > Cheers, > > Mario > > > > One thing to consider is JDK-8202353: > > https://bugs.openjdk.java.net/browse/JDK-8202353 > > When I backported this, I had to drop JFR code changes. Compare: > > https://hg.openjdk.java.net/jdk/jdk/rev/f605c91e5219 > > and > > https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/0f2fe7d37d8c > > The bug: > > https://bugs.openjdk.java.net/browse/JDK-8202835 > > would be ideal to use to backport the remaining changes. The original > changeset used both bug IDs, but the 8u one only used 8202353. > Thanks Andrew! I'll add this to the list. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From sgehwolf at redhat.com Fri Aug 9 09:57:36 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 09 Aug 2019 11:57:36 +0200 Subject: PING? [8u] RFR: 8135318: CMS wrong max_eden_size for check_gc_overhead_limit In-Reply-To: References: <5a5800679e314ee3b5545323bb156eff5475b091.camel@redhat.com> Message-ID: On Wed, 2019-08-07 at 17:47 +0200, Aleksey Shipilev wrote: > On 8/7/19 4:36 PM, Severin Gehwolf wrote: > > On Tue, 2019-07-09 at 14:37 +0200, Severin Gehwolf wrote: > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8135318 > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8135318/01/webrev/ > > > JDK 9 change: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/dd0c55eac358 > > Backport looks good. Thanks for the review! > Looks like a simple fix without any bug tail. So the code in 8u would now compute eden size as > "max_young - 2*survivor", which makes sense: eden, plus from/to survivor spaces. Before it computed > it as "max_young - 3*survivor", which is erroneous. (It is weird DefNewGeneration::max_capacity() > discounts survivor space size, leading to this problem...) Right? That's my understanding. It's been there since 2007 "Initial load" :) Thanks, Severin From shade at redhat.com Fri Aug 9 10:08:35 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 9 Aug 2019 12:08:35 +0200 Subject: [8u] RFR 8147502: Digest is incorrectly truncated for ECDSA signatures when the bit length of n is less than the field size In-Reply-To: References: Message-ID: <2d9d5225-bef5-667d-1e6d-74589ac97231@redhat.com> On 8/8/19 9:40 PM, Martin Balao wrote: > http://cr.openjdk.java.net/~mbalao/webrevs/8147502/8147502.webrev.jdk8u.jdk.00/ Product change backport looks good. So the difference in SignatureDigestTruncate.java is: --- orig 2019-08-09 12:03:20.976137087 +0200 +++ new 2019-08-08 21:15:19.000000000 +0200 @@ -21,7 +21,7 @@ * questions. */ -import jdk.test.lib.Convert; +import jdk.testlibrary.Convert; import java.security.*; import java.security.spec.*; @@ -34,8 +34,8 @@ * @summary Test that digests are properly truncated before the signature * is applied. The digest should be truncated to the bit length of the * group order. - * @library /test/lib - * @build jdk.test.lib.Convert + * @library /lib/testlibrary + * @build jdk.testlibrary.Convert * @run main SignatureDigestTruncate */ public class SignatureDigestTruncate { @@ -114,12 +114,12 @@ } public static void main(String[] args) throws Exception { - runTest("SHA384withECDSAinP1363Format", "sect283r1", + runTest("SHA384withECDSA", "sect283r1", "abcdef10234567", "010203040506070809", "000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d" + "1e1f20212223", - "01d7544b5d3935216bd45e2f8042537e1e0296a11e0eb96666199281b409" + - "42abccd5358a035de8a314d3e6c2a97614daebf5fb1313540eec3f9a3272" + - "068aa10922ccae87d255c84c"); + "304c022401d7544b5d3935216bd45e2f8042537e1e0296a11e0eb9666619" + + "9281b40942abccd5358a0224035de8a314d3e6c2a97614daebf5fb131354" + + "0eec3f9a3272068aa10922ccae87d255c84c"); } } We don't have SHA384withECDSAinP1363Format in 8u, that's why it was changed? The difference in Convert.java is the absence of trailing newline, apparently: $ diff -uwb ~/trunks/jdk-jdk/test/lib/jdk/test/lib/Convert.java new --- /home/shade/trunks/jdk-jdk/test/lib/jdk/test/lib/Convert.java 2019-07-25 07:50:18.361190854 +0200 +++ new 2019-08-08 21:15:39.000000000 +0200 @@ -21,7 +21,7 @@ * questions. */ -package jdk.test.lib; +package jdk.testlibrary; import java.math.BigInteger; @@ -82,4 +82,3 @@ } } - -- Thanks, -Aleksey From aph at redhat.com Fri Aug 9 13:19:33 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 9 Aug 2019 14:19:33 +0100 Subject: Changes to 8u and 11u process In-Reply-To: References: <51f754b2-a7c0-8157-76fb-6a5bd2d089c6@redhat.com> <1462b721-29ce-8db5-6661-0fdd60dd1245@redhat.com> Message-ID: <3b7d12a4-3b78-6b71-0690-9debae9c69e3@redhat.com> On 8/9/19 12:30 AM, Andrew John Hughes wrote: > It shouldn't take a week. That's a case for adding more maintainers to > share the workload, not a reason to abandon the process altogether. I > think ideally we should have at least three on each project, as > currently a maintainer wanting a patch approved has to rely on a single > individual for that approval. True, but people with the necessary understanding and good taste are not in great supply. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Fri Aug 9 13:20:50 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 9 Aug 2019 14:20:50 +0100 Subject: Changes to 8u and 11u process In-Reply-To: <30ee8310-42a3-0d63-7985-61000be5e32a@redhat.com> References: <51f754b2-a7c0-8157-76fb-6a5bd2d089c6@redhat.com> <084f5815-6d39-f8a2-01a5-244a1a4c2905@redhat.com> <30ee8310-42a3-0d63-7985-61000be5e32a@redhat.com> Message-ID: <9720431f-25b8-ba66-d5e7-f9df884ca292@redhat.com> On 8/8/19 10:44 PM, Andrew John Hughes wrote: > Although it may be used sparingly, if at all, I think we should retain > the right to approve all bugs, especially as these legacy versions > continue to diverge further from the main development tree. Sure, of course. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From mbalao at redhat.com Fri Aug 9 14:40:50 2019 From: mbalao at redhat.com (Martin Balao) Date: Fri, 9 Aug 2019 11:40:50 -0300 Subject: [8u] RFR 8147502: Digest is incorrectly truncated for ECDSA signatures when the bit length of n is less than the field size In-Reply-To: <2d9d5225-bef5-667d-1e6d-74589ac97231@redhat.com> References: <2d9d5225-bef5-667d-1e6d-74589ac97231@redhat.com> Message-ID: <2a6ecbc0-d97f-da9c-484f-d88415927512@redhat.com> Hi Aleksey, Thanks for having a look at this. On 8/9/19 7:08 AM, Aleksey Shipilev wrote: > On 8/8/19 9:40 PM, Martin Balao wrote: > > We don't have SHA384withECDSAinP1363Format in 8u, that's why it was changed? > That's right. I verified that the signature is still truncated with the new algorithm (otherwise the test would render useless) and obtained the new expected result from the BouncyCastle crypto provider. Regards, Martin.- From andrew_m_leonard at uk.ibm.com Fri Aug 9 15:16:25 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Fri, 9 Aug 2019 16:16:25 +0100 Subject: [8u] RFR Backport of 8217896: Make better use of LCPUs when building on AIX Message-ID: Hi, Please can I request a review of this updated patch for 8217896 to backport to jdk8u. The patch is essentially the same, but jdk8 the build-performance.m4 is in a different location, with a different copyright year, and the generated-configure.sh generation.. I have built and tested this on our AIX machines. http://cr.openjdk.java.net/~aleonard/8217896/webrev.03/ Once reviewed I will add the jdk8u-fix-request. Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From sgehwolf at redhat.com Fri Aug 9 15:45:48 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 09 Aug 2019 17:45:48 +0200 Subject: [8u] RFR Backport of 8217896: Make better use of LCPUs when building on AIX In-Reply-To: References: Message-ID: <3b7c1296347cd25805da7960261d819cf0b5cd57.camel@redhat.com> Hi Andrew, On Fri, 2019-08-09 at 16:16 +0100, Andrew Leonard wrote: > Hi, > Please can I request a review of this updated patch for 8217896 to > backport to jdk8u. The patch is essentially the same, but jdk8 the > build-performance.m4 is in a different location, with a different > copyright year, and the generated-configure.sh generation.. I have > built > and tested this on our AIX machines. > http://cr.openjdk.java.net/~aleonard/8217896/webrev.03/ This looks fine to me. Matches the JDK 13 patch. It's AIX only. Thumbs up. Thanks, Severin From alvdavi at amazon.com Fri Aug 9 19:52:15 2019 From: alvdavi at amazon.com (Alvarez, David) Date: Fri, 9 Aug 2019 19:52:15 +0000 Subject: JDK-8129988 introduces a new behavior when reading the javax.net.ssl.trustStore property. Message-ID: <3EDF161E-62AC-4C05-BF1C-DD81126F4C62@amazon.com> Hello, We have detected that JDK-8219988 [1], that has been included in OpenJDK 8u222 included a non-documented change in the behavior of the javax.net.ssl.trustStore property. In previous versions, should this property point to a non-existent file, an empty KeyStore would be used instead. [2] In newer versions, if the value of the property contains an invalid URL, the code will instead fall back and use the lib/security/cacerts file. [3] However, there are two things about that change that caught our attention: - Whenever there is no javax.net.ssl.trustStore property set, the code will first look for lib/security/jssecacerts. If that file does not exist, then it will look for lib/security/cacerts. However, when the property is set to an invalid file, the fallback mechanism jumps directly to lib/security/cacerts, never checking lib/security/jssecacerts. - This fallback mechanism for invalid javax.net.ssl.trustStore values reuses the value of javax.net.ssl.trustStorePassword. If that property is set in conjunction with an invalid value in javax.net.ssl.trustStore the specified password will be used when attempting to read the lib/security/cacerts store. It seems unclear why this path of action is chosen here. If the lib/security/cacerts has no password (and as far as I'm aware, that is the case in the majority of OpenJDK distributions, if not all), the operation will raise an exception. This exception mentions that 'Password verification failed', hiding the underlying cause (the property pointing to a bad store).[4] Although the new behavior isn't necessarily wrong, I think there is room for Improvement. Suggestions: - Make sure lib/security/jssecacerts is checked during the fallback process. - Ignore the value of javax.net.ssl.trustStorePassword when we fallback to use the bundled jssecacerts or cacerts file. - Change the exception message to avoid confusion. I would like to have your opinion on this. Thanks, David -- [1] https://bugs.openjdk.java.net/browse/JDK-8129988 [2] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/ac2ef877d3e8/src/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java#l132 [3] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/2a9bea6e5e03/src/share/classes/sun/security/ssl/TrustStoreManager.java#l128 [4] Here is a copy of the exception: Caused by: java.io.IOException: Keystore was tampered with, or password was incorrect at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:785) at sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:56) at sun.security.provider.KeyStoreDelegator.engineLoad(KeyStoreDelegator.java:224) at sun.security.provider.JavaKeyStore$DualFormatJKS.engineLoad(JavaKeyStore.java:70) at java.security.KeyStore.load(KeyStore.java:1445) at sun.security.ssl.TrustStoreManager$TrustAnchorManager.loadKeyStore(TrustStoreManager.java:367) at sun.security.ssl.TrustStoreManager$TrustAnchorManager.getTrustedCerts(TrustStoreManager.java:315) at sun.security.ssl.TrustStoreManager.getTrustedCerts(TrustStoreManager.java:59) at sun.security.ssl.TrustManagerFactoryImpl.engineInit(TrustManagerFactoryImpl.java:51) Caused by: java.security.UnrecoverableKeyException: Password verification failed at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:783) From bourges.laurent at gmail.com Sat Aug 10 12:27:58 2019 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Sat, 10 Aug 2019 14:27:58 +0200 Subject: How to import patch from jdk/jdk Message-ID: Hi, I tried to use hg qimport to backport the following jdk9 patch (png encoder performance issue) on my local jdk8u: https://bugs.openjdk.java.net/ browse/JDK-6488522 hg qpush fails as the patch class is in java.desktop module but jdk8 has no module. It mentions the --prefix option. What is the option or wiki page explaining how to use different prefixes ? Thanks in advance, Laurent From aph at redhat.com Sat Aug 10 14:34:22 2019 From: aph at redhat.com (Andrew Haley) Date: Sat, 10 Aug 2019 15:34:22 +0100 Subject: How to import patch from jdk/jdk In-Reply-To: References: Message-ID: On 8/10/19 1:27 PM, Laurent Bourg?s wrote: > I tried to use hg qimport to backport the following jdk9 patch (png encoder > performance issue) on my local jdk8u: > > https://bugs.openjdk.java.net/ > > browse/JDK-6488522 > > hg qpush fails as the patch class is in java.desktop module but jdk8 has no > module. It mentions the --prefix option. > > What is the option or wiki page explaining how to use different prefixes ? You're going to actually have to backport it. Check out the patch, edit it, then push it locally. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From bourges.laurent at gmail.com Sat Aug 10 14:58:57 2019 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Sat, 10 Aug 2019 16:58:57 +0200 Subject: How to import patch from jdk/jdk In-Reply-To: References: Message-ID: Ok, I will use sed on the patch file to fix paths, then I will import it. I thought such sed script already exist or mercurial or linux patch command already manage that. Thank you, Laurent Le sam. 10 ao?t 2019 ? 16:34, Andrew Haley a ?crit : > On 8/10/19 1:27 PM, Laurent Bourg?s wrote: > > I tried to use hg qimport to backport the following jdk9 patch (png > encoder > > performance issue) on my local jdk8u: > > > > https://bugs.openjdk.java.net/ > > > > browse/JDK-6488522 > > > > hg qpush fails as the patch class is in java.desktop module but jdk8 has > no > > module. It mentions the --prefix option. > > > > What is the option or wiki page explaining how to use different prefixes > ? > > You're going to actually have to backport it. Check out the patch, edit it, > then push it locally. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From gromero at linux.vnet.ibm.com Sun Aug 11 23:34:35 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Sun, 11 Aug 2019 20:34:35 -0300 Subject: [Ping] Re: [8u-dev, ppc] RFR for (almost clean) backport of 8188868: PPC64: Support AES intrinsics on Big Endian In-Reply-To: References: <2d8d8d35-c781-cc0c-2673-c8f7eea057bd@redhat.com> Message-ID: <163f9fd2-95ed-512f-c67e-55de4c4f51d1@linux.vnet.ibm.com> Hi, Thanks Ogata for adjusting the change and evaluating performance on 8u + Power BE. Thanks Andrew for reviewing and approving it. Pushed to jdk8u-dev: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/42118db355f5 Best regards, Gustavo On 07/31/2019 11:55 PM, Kazunori Ogata wrote: > Hi Andrew, > > Thank you for reviewing the webrev. > > Regards, > Ogata > > Andrew John Hughes wrote on 2019/08/01 01:05:48: > >> From: Andrew John Hughes >> To: Kazunori Ogata , hotspot-compiler- >> dev at openjdk.java.net, jdk8u-dev at openjdk.java.net >> Date: 2019/08/01 01:13 >> Subject: [EXTERNAL] Re: [Ping] Re: [8u-dev, ppc] RFR for (almost clean) >> backport of 8188868: PPC64: Support AES intrinsics on Big Endian >> >> >> >> On 31/07/2019 10:30, Kazunori Ogata wrote: >>> Ping. >>> >>> May I get review for the almost clean backport? >>> >>> Regards, >>> Ogata >>> >>> Kazunori Ogata/Japan/IBM wrote on 2019/07/24 17:48:23: >>> >>>> From: Kazunori Ogata/Japan/IBM >>>> To: hotspot-compiler-dev at openjdk.java.net, jdk8u-dev at openjdk.java.net >>>> Date: 2019/07/24 17:48 >>>> Subject: [8u-dev, ppc] RFR for (almost clean) backport of 8188868: >>> PPC64: >>>> Support AES intrinsics on Big Endian >>>> >>>> Hi, >>>> >>>> May I get review for backport of 8188868: PPC64: Support AES > intrinsics >>> on >>>> Big Endian? >>>> >>>> The original patch itself can be applied cleanly (besides difference > of >>>> the source directory structure). However, one chunk failed because > the >>>> code just after the patched code was modified, so I manually applied > the >>> >>>> chunk and renewed the patch. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8188868 >>>> Webrev: >>> http://cr.openjdk.java.net/~ogatak/jdk8u_aes_be/8188868/webrev.02/ >>>> >>>> This backport is low risk and affects only PPC64 only. I verified > there >>>> was no degradation in "make test" results and SPECjbb 2015 ran fine. > The >>> >>>> intrinsics added in this changeset improved max jOPS by 5% and > critical >>> jOPS by 4%. >>>> >>>> Regards, >>>> Ogata >>> >> >> Sorry, I started looking at this yesterday, but didn't get chance to > finish. >> >> It looks fine to me. The stubGenerator_ppc.cpp changes were a little >> hard to follow, but comparing the patched version with the 11u version >> looked ok. >> >> Good to go. >> -- >> Andrew :) >> >> Senior Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) >> Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 >> https://keybase.io/gnu_andrew >> >> [attachment "signature.asc" deleted by Kazunori Ogata/Japan/IBM] > From sgehwolf at redhat.com Mon Aug 12 08:05:26 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 12 Aug 2019 10:05:26 +0200 Subject: How to import patch from jdk/jdk In-Reply-To: References: Message-ID: Hi, On Sat, 2019-08-10 at 16:58 +0200, Laurent Bourg?s wrote: > Ok, > I will use sed on the patch file to fix paths, then I will import it. I > thought such sed script already exist or mercurial or linux patch command > already manage that. You could try common/bin/unshuffle_patch.sh from JDK 9[1]. Thanks, Severin [1] http://hg.openjdk.java.net/jdk-updates/jdk9u/file/1b1226687b89/common/bin/unshuffle_patch.sh > Thank you, > Laurent > > Le sam. 10 ao?t 2019 ? 16:34, Andrew Haley a ?crit : > > > On 8/10/19 1:27 PM, Laurent Bourg?s wrote: > > > I tried to use hg qimport to backport the following jdk9 patch > > > (png > > encoder > > > performance issue) on my local jdk8u: > > > > > > https://bugs.openjdk.java.net/ > > > > > > browse/JDK-6488522 < > > > https://bugs.openjdk.java.net/browse/JDK-6488522> > > > > > > hg qpush fails as the patch class is in java.desktop module but > > > jdk8 has > > no > > > module. It mentions the --prefix option. > > > > > > What is the option or wiki page explaining how to use different > > > prefixes > > ? > > > > You're going to actually have to backport it. Check out the patch, > > edit it, > > then push it locally. > > > > -- > > Andrew Haley (he/him) > > Java Platform Lead Engineer > > Red Hat UK Ltd. > > https://keybase.io/andrewhaley > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > From denghui.ddh at alibaba-inc.com Mon Aug 12 08:32:34 2019 From: denghui.ddh at alibaba-inc.com (DDH) Date: Mon, 12 Aug 2019 16:32:34 +0800 Subject: =?UTF-8?B?UkZSOiA4MjIzMTQ3OiBKRlIgQmFja3BvcnQgKHRvIGpkazh1KQ==?= Message-ID: Hi Mario?Andrey, We(Alibaba) recently fixed some test failures about JFR CodeCache events, which are incremental changes based on Azul' patchset. 8229401: Fix JFR code cache test failures http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_8229401_hs/ http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_8229401_jdk/ The other patchset we provided earlier is as follows: 8223689: Add JFR Thread Sampling Support http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_thread_samp_20190326/ 8223690: Add JFR BiasedLock Event Support http://cr.openjdk.java.net/~luchsh/hs_biasedlock/ http://cr.openjdk.java.net/~luchsh/jdk_biasedlock/ 8223691: Add JFR G1 Region Type Change Event Support http://cr.openjdk.java.net/~luchsh/g1region_type_change_event 8223692: Add JFR G1 Heap Summary Event Support http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_g1heapsum_hs_20190326/ http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_g1heapsum_jdk_20190326/ Thanks, Denghui From neugens at redhat.com Mon Aug 12 08:50:46 2019 From: neugens at redhat.com (Mario Torre) Date: Mon, 12 Aug 2019 10:50:46 +0200 Subject: RFR: 8223147: JFR Backport (to jdk8u) In-Reply-To: References: Message-ID: Hi Denghui, I'm a bit confused because none of those seems to be a backport bug. For example, the 8223689 isn't in 11. As such, we should first port changes to the topmost upstream release and than carry them down one by one until it reaches 8, in other words we should request the changes to go first in 14, then 13, then 11 then 8. We can of course apply single fixes in 8 that do not qualify for the other releases, for example (I have yet to try) if 8229401 is only valid because of the backport to 8 then it's fine to only fix this problem in 8, otherwise we need to go the full route. Cheers, Mario Cheers, Mario On Mon, Aug 12, 2019 at 10:32 AM DDH wrote: > > Hi Mario?Andrey, > > We(Alibaba) recently fixed some test failures about JFR CodeCache events, which are incremental changes based on Azul' patchset. > 8229401: Fix JFR code cache test failures > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_8229401_hs/ > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_8229401_jdk/ > > > The other patchset we provided earlier is as follows: > 8223689: Add JFR Thread Sampling Support > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_thread_samp_20190326/ > > 8223690: Add JFR BiasedLock Event Support > http://cr.openjdk.java.net/~luchsh/hs_biasedlock/ > http://cr.openjdk.java.net/~luchsh/jdk_biasedlock/ > > 8223691: Add JFR G1 Region Type Change Event Support > http://cr.openjdk.java.net/~luchsh/g1region_type_change_event > > 8223692: Add JFR G1 Heap Summary Event Support > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_g1heapsum_hs_20190326/ > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_g1heapsum_jdk_20190326/ > > Thanks, > Denghui -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From denghui.ddh at alibaba-inc.com Mon Aug 12 09:38:09 2019 From: denghui.ddh at alibaba-inc.com (DDH) Date: Mon, 12 Aug 2019 17:38:09 +0800 Subject: =?UTF-8?B?UkZSOiA4MjIzMTQ3OiBKRlIgQmFja3BvcnQgKHRvIGpkazh1KQ==?= Message-ID: Hi Mario: All patch sets we provided are incremental changes based on Azul' patch set, are only for 8, and the features in these patches are available in 11. For example: Thread Sampling Support can be found in http://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/hotspot/share/jfr/periodic/sampling The description of our issues may be not clear, we will update the description later. Sorry for the misunderstanding. Thanks, Denghui From andrey at azul.com Mon Aug 12 11:36:50 2019 From: andrey at azul.com (Andrey Petushkov) Date: Mon, 12 Aug 2019 11:36:50 +0000 Subject: RFR: 8223147: JFR Backport (to jdk8u) In-Reply-To: References: Message-ID: <63EEFC65-A823-48F1-B877-D4FE4EBE5E8E@azul.com> Hi Mario, My understanding is that these changes are to compliment the work/fix the bugs I've done under 8223147 (main backport issue). These do not have openjdk bug numbers because correspond to changes made by Oracle privately, before JFR was open-sourced. In other words - the functionality they bring is already part of openjdk jdk11, however expressed in some different code (since otherwise I would just brought it under 8223147). So it required jdk8-specific way to make it happen in jdk8, which was generously done by Alibaba team Hope this clarifies Regards, Andrey > On 12 Aug 2019, at 11:50, Mario Torre wrote: > > Hi Denghui, > > I'm a bit confused because none of those seems to be a backport bug. > > For example, the 8223689 isn't in 11. As such, we should first port > changes to the topmost upstream release and than carry them down one > by one until it reaches 8, in other words we should request the > changes to go first in 14, then 13, then 11 then 8. > > We can of course apply single fixes in 8 that do not qualify for the > other releases, for example (I have yet to try) if 8229401 is only > valid because of the backport to 8 then it's fine to only fix this > problem in 8, otherwise we need to go the full route. > > Cheers, > Mario > > Cheers, > Mario > > > On Mon, Aug 12, 2019 at 10:32 AM DDH wrote: >> >> Hi Mario?Andrey, >> >> We(Alibaba) recently fixed some test failures about JFR CodeCache events, which are incremental changes based on Azul' patchset. >> 8229401: Fix JFR code cache test failures >> http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_8229401_hs/ >> http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_8229401_jdk/ >> >> >> The other patchset we provided earlier is as follows: >> 8223689: Add JFR Thread Sampling Support >> http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_thread_samp_20190326/ >> >> 8223690: Add JFR BiasedLock Event Support >> http://cr.openjdk.java.net/~luchsh/hs_biasedlock/ >> http://cr.openjdk.java.net/~luchsh/jdk_biasedlock/ >> >> 8223691: Add JFR G1 Region Type Change Event Support >> http://cr.openjdk.java.net/~luchsh/g1region_type_change_event >> >> 8223692: Add JFR G1 Heap Summary Event Support >> http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_g1heapsum_hs_20190326/ >> http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_g1heapsum_jdk_20190326/ >> >> Thanks, >> Denghui > > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From andrey at azul.com Mon Aug 12 11:36:51 2019 From: andrey at azul.com (Andrey Petushkov) Date: Mon, 12 Aug 2019 11:36:51 +0000 Subject: RFR: 8223147: JFR Backport (to jdk8u) In-Reply-To: References: Message-ID: Hi Mario, My understanding is that these changes are to compliment the work/fix the bugs I've done under 8223147 (main backport issue). These do not have openjdk bug numbers because correspond to changes made by Oracle privately, before JFR was open-sourced. In other words - the functionality they bring is already part of openjdk jdk11, however expressed in some different code (since otherwise I would just brought it under 8223147). So it required jdk8-specific way to make it happen in jdk8, which was generously done by Alibaba team Hope this clarifies Regards, Andrey > On 12 Aug 2019, at 11:50, Mario Torre wrote: > > Hi Denghui, > > I'm a bit confused because none of those seems to be a backport bug. > > For example, the 8223689 isn't in 11. As such, we should first port > changes to the topmost upstream release and than carry them down one > by one until it reaches 8, in other words we should request the > changes to go first in 14, then 13, then 11 then 8. > > We can of course apply single fixes in 8 that do not qualify for the > other releases, for example (I have yet to try) if 8229401 is only > valid because of the backport to 8 then it's fine to only fix this > problem in 8, otherwise we need to go the full route. > > Cheers, > Mario > > Cheers, > Mario > > > On Mon, Aug 12, 2019 at 10:32 AM DDH wrote: >> >> Hi Mario?Andrey, >> >> We(Alibaba) recently fixed some test failures about JFR CodeCache events, which are incremental changes based on Azul' patchset. >> 8229401: Fix JFR code cache test failures >> http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_8229401_hs/ >> http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_8229401_jdk/ >> >> >> The other patchset we provided earlier is as follows: >> 8223689: Add JFR Thread Sampling Support >> http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_thread_samp_20190326/ >> >> 8223690: Add JFR BiasedLock Event Support >> http://cr.openjdk.java.net/~luchsh/hs_biasedlock/ >> http://cr.openjdk.java.net/~luchsh/jdk_biasedlock/ >> >> 8223691: Add JFR G1 Region Type Change Event Support >> http://cr.openjdk.java.net/~luchsh/g1region_type_change_event >> >> 8223692: Add JFR G1 Heap Summary Event Support >> http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_g1heapsum_hs_20190326/ >> http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_g1heapsum_jdk_20190326/ >> >> Thanks, >> Denghui > > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From neugens at redhat.com Mon Aug 12 11:38:02 2019 From: neugens at redhat.com (Mario Torre) Date: Mon, 12 Aug 2019 13:38:02 +0200 Subject: RFR: 8223147: JFR Backport (to jdk8u) In-Reply-To: References: Message-ID: Don't they have an existing bugid that can be used? I would rather like to reuse an existing id then to create separate ones for the backports. Cheers, Mario On Mon, Aug 12, 2019 at 11:38 AM DDH wrote: > > Hi Mario: > > All patch sets we provided are incremental changes based on Azul' patch set, > are only for 8, and the features in these patches are available in 11. > > For example: > Thread Sampling Support can be found in > http://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/hotspot/share/jfr/periodic/sampling > > The description of our issues may be not clear, we will update the description later. > Sorry for the misunderstanding. > > Thanks, > Denghui -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From neugens at redhat.com Mon Aug 12 11:41:24 2019 From: neugens at redhat.com (Mario Torre) Date: Mon, 12 Aug 2019 13:41:24 +0200 Subject: RFR: 8223147: JFR Backport (to jdk8u) In-Reply-To: <63EEFC65-A823-48F1-B877-D4FE4EBE5E8E@azul.com> References: <63EEFC65-A823-48F1-B877-D4FE4EBE5E8E@azul.com> Message-ID: On Mon, Aug 12, 2019 at 1:36 PM Andrey Petushkov wrote: > > Hi Mario, > > My understanding is that these changes are to compliment the work/fix the bugs I've done under 8223147 (main backport issue). > These do not have openjdk bug numbers because correspond to changes made by Oracle privately, before JFR was open-sourced. > In other words - the functionality they bring is already part of openjdk jdk11, however expressed in some different code (since otherwise I > would just brought it under 8223147). So it required jdk8-specific way to make it happen in jdk8, which was generously done by Alibaba team Oh, I see, thanks for the explanation. I think I was thrown off by the define of DEFINE_TRACE_SUSPEND_FLAG_METHODS which is nowhere on 11. and later. The patches are ok to commit for me. Cheers. Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From gnu.andrew at redhat.com Mon Aug 12 13:46:52 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 12 Aug 2019 14:46:52 +0100 Subject: [JFR] Port Status In-Reply-To: References: <90ce3c16-ce51-d116-532c-855761f8e3bc@redhat.com> Message-ID: <5c46ce8b-bf5a-8305-93c6-9b1190db4154@redhat.com> On 09/08/2019 10:49, Mario Torre wrote: > > > On Thu, Aug 8, 2019 at 8:56 PM Andrew John Hughes > wrote: > > > > On 08/08/2019 11:19, Mario Torre wrote: > > Hi all, > > > > I just updated the staging repository with the latest code from the > > jdk8u repository. I also added a new label on Jira: > > > > jfr-jdk8u-backport > > > > This can be used to track down all the patches we are backporting in > > the staging repository and later on into mainline 8u. > > > > This should make it easier to track things around. > > > > I think one label is enough, if we want to mark a distinction on > > patches we "want" to backport as opposed to the one we "did" backport > > we can add another label, i.e. jfr-jdk8u-backport-staging, but I don't > > see much reason to do this, any suggestions? > > > > Cheers, > > Mario > > > > One thing to consider is JDK-8202353: > > https://bugs.openjdk.java.net/browse/JDK-8202353 > > When I backported this, I had to drop JFR code changes. Compare: > > https://hg.openjdk.java.net/jdk/jdk/rev/f605c91e5219 > > and > > https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/0f2fe7d37d8c > > The bug: > > https://bugs.openjdk.java.net/browse/JDK-8202835 > > would be ideal to use to backport the remaining changes. The original > changeset used both bug IDs, but the 8u one only used 8202353. > > > Thanks Andrew! > > I'll add this to the list. > > Cheers, > Mario > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 ?9205 5D7E 4952 3F65 7898 Right. You tagged the wrong bug though. I moved it to https://bugs.openjdk.java.net/browse/JDK-8202835 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 andrey at azul.com Mon Aug 12 13:58:43 2019 From: andrey at azul.com (Andrey Petushkov) Date: Mon, 12 Aug 2019 13:58:43 +0000 Subject: [JFR] Port Status In-Reply-To: <5c46ce8b-bf5a-8305-93c6-9b1190db4154@redhat.com> References: <90ce3c16-ce51-d116-532c-855761f8e3bc@redhat.com> <5c46ce8b-bf5a-8305-93c6-9b1190db4154@redhat.com> Message-ID: Hi guys, These changes were already part of initial JFR backport diff. My bad, for some reason I lost these two bugs in the list of changes backported. I believe the right way is to add 8202835 into commit message. Please confirm Andrey > On 12 Aug 2019, at 16:46, Andrew John Hughes wrote: > > > > On 09/08/2019 10:49, Mario Torre wrote: >> >> >> On Thu, Aug 8, 2019 at 8:56 PM Andrew John Hughes > > wrote: >> >> >> >> On 08/08/2019 11:19, Mario Torre wrote: >>> Hi all, >>> >>> I just updated the staging repository with the latest code from the >>> jdk8u repository. I also added a new label on Jira: >>> >>> jfr-jdk8u-backport >>> >>> This can be used to track down all the patches we are backporting in >>> the staging repository and later on into mainline 8u. >>> >>> This should make it easier to track things around. >>> >>> I think one label is enough, if we want to mark a distinction on >>> patches we "want" to backport as opposed to the one we "did" backport >>> we can add another label, i.e. jfr-jdk8u-backport-staging, but I don't >>> see much reason to do this, any suggestions? >>> >>> Cheers, >>> Mario >>> >> >> One thing to consider is JDK-8202353: >> >> https://bugs.openjdk.java.net/browse/JDK-8202353 >> >> When I backported this, I had to drop JFR code changes. Compare: >> >> https://hg.openjdk.java.net/jdk/jdk/rev/f605c91e5219 >> >> and >> >> https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/0f2fe7d37d8c >> >> The bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8202835 >> >> would be ideal to use to backport the remaining changes. The original >> changeset used both bug IDs, but the 8u one only used 8202353. >> >> >> Thanks Andrew! >> >> I'll add this to the list. >> >> Cheers, >> Mario >> >> -- >> Mario Torre >> Associate Manager, Software Engineering >> Red Hat GmbH >> 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > Right. You tagged the wrong bug though. I moved it to > > https://bugs.openjdk.java.net/browse/JDK-8202835 > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Mon Aug 12 14:09:22 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 12 Aug 2019 15:09:22 +0100 Subject: JDK-8129988 introduces a new behavior when reading the javax.net.ssl.trustStore property. In-Reply-To: <3EDF161E-62AC-4C05-BF1C-DD81126F4C62@amazon.com> References: <3EDF161E-62AC-4C05-BF1C-DD81126F4C62@amazon.com> Message-ID: Forwarding to security-dev as this was backported from later JDK versions: On 09/08/2019 20:52, Alvarez, David wrote: > Hello, > > We have detected that JDK-8219988 [1], that has been included in OpenJDK 8u222 > included a non-documented change in the behavior of the > javax.net.ssl.trustStore property. In previous versions, should this property > point to a non-existent file, an empty KeyStore would be used instead. [2] > > In newer versions, if the value of the property contains an invalid URL, the > code will instead fall back and use the lib/security/cacerts file. [3] > > However, there are two things about that change that caught our attention: > - Whenever there is no javax.net.ssl.trustStore property set, the code will > first look for lib/security/jssecacerts. If that file does not exist, then it > will look for lib/security/cacerts. However, when the property is set to an > invalid file, the fallback mechanism jumps directly to lib/security/cacerts, > never checking lib/security/jssecacerts. > > - This fallback mechanism for invalid javax.net.ssl.trustStore values reuses the > value of javax.net.ssl.trustStorePassword. If that property is set in > conjunction with an invalid value in javax.net.ssl.trustStore the specified > password will be used when attempting to read the lib/security/cacerts store. > It seems unclear why this path of action is chosen here. > > If the lib/security/cacerts has no password (and as far as I'm aware, that is > the case in the majority of OpenJDK distributions, if not all), the operation > will raise an exception. This exception mentions that 'Password verification > failed', hiding the underlying cause (the property pointing to a bad store).[4] > > Although the new behavior isn't necessarily wrong, I think there is room for > Improvement. Suggestions: > > - Make sure lib/security/jssecacerts is checked during the fallback process. > - Ignore the value of javax.net.ssl.trustStorePassword when we fallback to use > the bundled jssecacerts or cacerts file. > - Change the exception message to avoid confusion. > > I would like to have your opinion on this. > > Thanks, > > David > > -- > [1] https://bugs.openjdk.java.net/browse/JDK-8129988 > [2] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/ac2ef877d3e8/src/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java#l132 > [3] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/2a9bea6e5e03/src/share/classes/sun/security/ssl/TrustStoreManager.java#l128 > [4] Here is a copy of the exception: > Caused by: java.io.IOException: Keystore was tampered with, or password was incorrect > at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:785) > at sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:56) > at sun.security.provider.KeyStoreDelegator.engineLoad(KeyStoreDelegator.java:224) > at sun.security.provider.JavaKeyStore$DualFormatJKS.engineLoad(JavaKeyStore.java:70) > at java.security.KeyStore.load(KeyStore.java:1445) > at sun.security.ssl.TrustStoreManager$TrustAnchorManager.loadKeyStore(TrustStoreManager.java:367) > at sun.security.ssl.TrustStoreManager$TrustAnchorManager.getTrustedCerts(TrustStoreManager.java:315) > at sun.security.ssl.TrustStoreManager.getTrustedCerts(TrustStoreManager.java:59) > at sun.security.ssl.TrustManagerFactoryImpl.engineInit(TrustManagerFactoryImpl.java:51) > Caused by: java.security.UnrecoverableKeyException: Password verification failed > at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:783) > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From neugens at redhat.com Mon Aug 12 14:19:33 2019 From: neugens at redhat.com (Mario Torre) Date: Mon, 12 Aug 2019 16:19:33 +0200 Subject: [JFR] Port Status In-Reply-To: References: <90ce3c16-ce51-d116-532c-855761f8e3bc@redhat.com> <5c46ce8b-bf5a-8305-93c6-9b1190db4154@redhat.com> Message-ID: Hi Andrey, Yes, if they are part of the patch you are about to push I think it's fine to just add the 8202835 to the ids. It's starting to be tricky to follow any bug that that belongs to any line of code change so this is probably the best :) Cheers, Mario On Mon, Aug 12, 2019 at 3:58 PM Andrey Petushkov wrote: > > Hi guys, > > These changes were already part of initial JFR backport diff. My bad, for some reason I lost these two bugs in the list of changes backported. > I believe the right way is to add 8202835 into commit message. Please confirm > > Andrey > > > On 12 Aug 2019, at 16:46, Andrew John Hughes wrote: > > > > > > > > On 09/08/2019 10:49, Mario Torre wrote: > >> > >> > >> On Thu, Aug 8, 2019 at 8:56 PM Andrew John Hughes >> > wrote: > >> > >> > >> > >> On 08/08/2019 11:19, Mario Torre wrote: > >>> Hi all, > >>> > >>> I just updated the staging repository with the latest code from the > >>> jdk8u repository. I also added a new label on Jira: > >>> > >>> jfr-jdk8u-backport > >>> > >>> This can be used to track down all the patches we are backporting in > >>> the staging repository and later on into mainline 8u. > >>> > >>> This should make it easier to track things around. > >>> > >>> I think one label is enough, if we want to mark a distinction on > >>> patches we "want" to backport as opposed to the one we "did" backport > >>> we can add another label, i.e. jfr-jdk8u-backport-staging, but I don't > >>> see much reason to do this, any suggestions? > >>> > >>> Cheers, > >>> Mario > >>> > >> > >> One thing to consider is JDK-8202353: > >> > >> https://bugs.openjdk.java.net/browse/JDK-8202353 > >> > >> When I backported this, I had to drop JFR code changes. Compare: > >> > >> https://hg.openjdk.java.net/jdk/jdk/rev/f605c91e5219 > >> > >> and > >> > >> https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/0f2fe7d37d8c > >> > >> The bug: > >> > >> https://bugs.openjdk.java.net/browse/JDK-8202835 > >> > >> would be ideal to use to backport the remaining changes. The original > >> changeset used both bug IDs, but the 8u one only used 8202353. > >> > >> > >> Thanks Andrew! > >> > >> I'll add this to the list. > >> > >> Cheers, > >> Mario > >> > >> -- > >> Mario Torre > >> Associate Manager, Software Engineering > >> Red Hat GmbH > >> 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > > > Right. You tagged the wrong bug though. I moved it to > > > > https://bugs.openjdk.java.net/browse/JDK-8202835 > > > > 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 > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From andrey at azul.com Mon Aug 12 15:10:16 2019 From: andrey at azul.com (Andrey Petushkov) Date: Mon, 12 Aug 2019 15:10:16 +0000 Subject: RFR: 8223147: JFR Backport (to jdk8u) In-Reply-To: References: <3E224264-DA96-48B8-8270-2B77B09E190F@azul.com> <771B3281-FB26-4673-B19C-6282BE1D9D86@azul.com> Message-ID: <0AD1FBFB-F7BE-4F57-B9CF-868ABAC308A7@azul.com> Hi Mario, All, I've merged the initial patch with current state of incubator repo (i.e. 8u222). Root repo and jdk patches applied cleanly. hotspot is not. The reasons are: - 8202353. It is already applied in upstream (see discussion in parallel thread [1]). I did not apply respective part of the JFR patch - 8151539. jdk8u have no WeakProcessor (8189359 is not backported to jdk8u) so in order to align the interfaces I've added overloaded version of Jfr::weak_oops_do. The diff is as follows: ==== diff -U 3 ../jdk8u-jfr-incubator.1/hotspot/src/share/vm/jfr/jfr.cpp hotspot/src/share/vm/jfr/jfr.cpp --- ../jdk8u-jfr-incubator.1/hotspot/src/share/vm/jfr/jfr.cpp 2019-04-30 17:54:17.529600930 +0300 +++ hotspot/src/share/vm/jfr/jfr.cpp 2019-08-12 17:38:46.842897757 +0300 @@ -84,6 +84,11 @@ LeakProfiler::oops_do(is_alive, f); } +void Jfr::weak_oops_do(OopClosure* f) { + AlwaysTrueClosure always_true; + LeakProfiler::oops_do(&always_true, f); +} + bool Jfr::on_flight_recorder_option(const JavaVMOption** option, char* delimiter) { return JfrOptionSet::parse_flight_recorder_option(option, delimiter); } diff -U 3 ../jdk8u-jfr-incubator.1/hotspot/src/share/vm/jfr/jfr.hpp hotspot/src/share/vm/jfr/jfr.hpp --- ../jdk8u-jfr-incubator.1/hotspot/src/share/vm/jfr/jfr.hpp 2019-04-30 17:54:17.529600930 +0300 +++ hotspot/src/share/vm/jfr/jfr.hpp 2019-08-12 17:06:22.466382473 +0300 @@ -52,6 +52,7 @@ static bool on_flight_recorder_option(const JavaVMOption** option, char* delimiter); static bool on_start_flight_recording_option(const JavaVMOption** option, char* delimiter); static void weak_oops_do(BoolObjectClosure* is_alive, OopClosure* f); + static void weak_oops_do(OopClosure* f); static Thread* sampler_thread(); }; ==== The invocations of Jfr::weak_oops_do have their first argument elided so end up calling the newly added method, hence the functionality is not affected The rest of the patch applied cleanly. The same subset of jfr jtreg passed on x86_64 as the one was passing with original patch. Ok to push? Thanks, Andrey [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/009986.html > On 3 Jun 2019, at 19:21, Mario Torre wrote: > > On Mon, May 13, 2019 at 7:04 PM Andrey Petushkov wrote: >> >> Hi Mario, >> >> Apparently the situation is not that bad, just a few things went wrong on our sides. >> My fault I did not switch --enable-jfr to false. Fixed now >> And you seem did not make clean after changing configure options :) With proper clean build the only wrong behavior I get from >> your list is the presence of jfc/template files in the distribution. I've fixed that as well. I don't see any other JFR artefacts in the images >> directory when building with JFR disabled (there are few intermediate files generated but these do not get into final image) >> Your test passes >> The webrevs are updated, please could you check again > > Hi Andrey, > > Thanks again for the patch. I did perform a bunch of tests and > although there is still work necessary, I think this part of the patch > is good to go, so please do commit it. > > As for the next steps, I'm going to see each of the patches that both > Azul and Alibaba submitted for review, I think we should create > subsequent umbrella bugs as we did with this first step so they are > easier to track. > > There is a number of fixes that is necessary once all of this has been > merged, for instance when running jtreg tests for the JFR directory I > noticed that many tests (about 30 at this first count) don't seem to > complete properly (one such example TestBiasedLockRevocationEvents). > > I didn't yet look at the specific of each test that fails but I think > we should be able to execute every test (or exclude the ones that fail > for obvious reason if necessary). > > Also, there's a number of differences between the jdk11 and onward > metadata.xml with what's in this backport patch. Denghui already > mentioned some unsupported events, but also the event definition in > some case is a mismatch. I'm going through each one of those and see > where this is part of the natural evolution of the events and what > should be instead changed to reflect the final definition. > > Nevertheless, I think it makes sense to start from here rather than > wait more to have one perfect patch, this will also give us a little > bit more exposure for doing performance test and the likes. > > So, bottom line, thanks for your patch, please go ahead and push to > the incubator repository! > > Cheers, > Mario > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From zgu at redhat.com Mon Aug 12 15:12:45 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 12 Aug 2019 11:12:45 -0400 Subject: [8u] 8217676: Upgrade libpng to 1.6.37 Message-ID: Hi, I would like to backport this CR to 8u, as it is on Oracle 8u backport list. The changeset from jdk13 (https://hg.openjdk.java.net/jdk/jdk13/rev/53154e45385a) did not apply cleanly. 1) No libpng.md in 8u, so ignore all diffs for libpng.md 2) -DPNG_ARM_NEON_OP and DPNG_ARM_NEON_IMPLEMENTATION in Awt2dLibraries.gmk, are arm only flags, but we decided to include them in this backport, given upstreaming aarch64 in progress and they are harmless to other platforms. Bug: https://bugs.openjdk.java.net/browse/JDK-8217676 JDK13 webrev: http://cr.openjdk.java.net/~serb/8217676/webrev.01/ JDK13 code review thread: http://mail.openjdk.java.net/pipermail/awt-dev/2019-July/015331.html 8u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8217676-8u/webrev.00/ Test: jdk_imageio on Linux 86_64 Thanks, -Zhengyu From neugens at redhat.com Mon Aug 12 15:55:01 2019 From: neugens at redhat.com (Mario Torre) Date: Mon, 12 Aug 2019 17:55:01 +0200 Subject: RFR: 8223147: JFR Backport (to jdk8u) In-Reply-To: <0AD1FBFB-F7BE-4F57-B9CF-868ABAC308A7@azul.com> References: <3E224264-DA96-48B8-8270-2B77B09E190F@azul.com> <771B3281-FB26-4673-B19C-6282BE1D9D86@azul.com> <0AD1FBFB-F7BE-4F57-B9CF-868ABAC308A7@azul.com> Message-ID: On Mon, Aug 12, 2019 at 5:10 PM Andrey Petushkov wrote: > > Hi Mario, All, > > I've merged the initial patch with current state of incubator repo (i.e. 8u222). Root repo and jdk patches applied cleanly. > hotspot is not. The reasons are: > - 8202353. It is already applied in upstream (see discussion in parallel thread [1]). I did not apply respective part of the JFR patch That's fine, I understood you wanted to merge the jfr part as part of the original request, if the code is not being backported we can just backport 8202835 later. > - 8151539. jdk8u have no WeakProcessor (8189359 is not backported to jdk8u) so in order to align the interfaces I've added overloaded > version of Jfr::weak_oops_do. The diff is as follows: This https://bugs.openjdk.java.net/browse/JDK-8151539 was backported by Alexey. Unfortunately at this moment the mercurial repo seems to be undergoing a trantrum so it's a bit difficult to see what's in and what's no, but I don't see the WeakProcessor code in my local copy, perhaps this was not part of the backport as it's not in 8. The patches should be ok to push however. Cheers, Mario > ==== > diff -U 3 ../jdk8u-jfr-incubator.1/hotspot/src/share/vm/jfr/jfr.cpp hotspot/src/share/vm/jfr/jfr.cpp > --- ../jdk8u-jfr-incubator.1/hotspot/src/share/vm/jfr/jfr.cpp 2019-04-30 17:54:17.529600930 +0300 > +++ hotspot/src/share/vm/jfr/jfr.cpp 2019-08-12 17:38:46.842897757 +0300 > @@ -84,6 +84,11 @@ > LeakProfiler::oops_do(is_alive, f); > } > > +void Jfr::weak_oops_do(OopClosure* f) { > + AlwaysTrueClosure always_true; > + LeakProfiler::oops_do(&always_true, f); > +} > + > bool Jfr::on_flight_recorder_option(const JavaVMOption** option, char* delimiter) { > return JfrOptionSet::parse_flight_recorder_option(option, delimiter); > } > diff -U 3 ../jdk8u-jfr-incubator.1/hotspot/src/share/vm/jfr/jfr.hpp hotspot/src/share/vm/jfr/jfr.hpp > --- ../jdk8u-jfr-incubator.1/hotspot/src/share/vm/jfr/jfr.hpp 2019-04-30 17:54:17.529600930 +0300 > +++ hotspot/src/share/vm/jfr/jfr.hpp 2019-08-12 17:06:22.466382473 +0300 > @@ -52,6 +52,7 @@ > static bool on_flight_recorder_option(const JavaVMOption** option, char* delimiter); > static bool on_start_flight_recording_option(const JavaVMOption** option, char* delimiter); > static void weak_oops_do(BoolObjectClosure* is_alive, OopClosure* f); > + static void weak_oops_do(OopClosure* f); > static Thread* sampler_thread(); > }; > ==== > > The invocations of Jfr::weak_oops_do have their first argument elided so end up calling the newly added method, > hence the functionality is not affected > > The rest of the patch applied cleanly. The same subset of jfr jtreg passed on x86_64 as the one was passing with original patch. Ok to push? > > Thanks, > Andrey > > [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/009986.html > > > On 3 Jun 2019, at 19:21, Mario Torre wrote: > > > > On Mon, May 13, 2019 at 7:04 PM Andrey Petushkov wrote: > >> > >> Hi Mario, > >> > >> Apparently the situation is not that bad, just a few things went wrong on our sides. > >> My fault I did not switch --enable-jfr to false. Fixed now > >> And you seem did not make clean after changing configure options :) With proper clean build the only wrong behavior I get from > >> your list is the presence of jfc/template files in the distribution. I've fixed that as well. I don't see any other JFR artefacts in the images > >> directory when building with JFR disabled (there are few intermediate files generated but these do not get into final image) > >> Your test passes > >> The webrevs are updated, please could you check again > > > > Hi Andrey, > > > > Thanks again for the patch. I did perform a bunch of tests and > > although there is still work necessary, I think this part of the patch > > is good to go, so please do commit it. > > > > As for the next steps, I'm going to see each of the patches that both > > Azul and Alibaba submitted for review, I think we should create > > subsequent umbrella bugs as we did with this first step so they are > > easier to track. > > > > There is a number of fixes that is necessary once all of this has been > > merged, for instance when running jtreg tests for the JFR directory I > > noticed that many tests (about 30 at this first count) don't seem to > > complete properly (one such example TestBiasedLockRevocationEvents). > > > > I didn't yet look at the specific of each test that fails but I think > > we should be able to execute every test (or exclude the ones that fail > > for obvious reason if necessary). > > > > Also, there's a number of differences between the jdk11 and onward > > metadata.xml with what's in this backport patch. Denghui already > > mentioned some unsupported events, but also the event definition in > > some case is a mismatch. I'm going through each one of those and see > > where this is part of the natural evolution of the events and what > > should be instead changed to reflect the final definition. > > > > Nevertheless, I think it makes sense to start from here rather than > > wait more to have one perfect patch, this will also give us a little > > bit more exposure for doing performance test and the likes. > > > > So, bottom line, thanks for your patch, please go ahead and push to > > the incubator repository! > > > > Cheers, > > Mario > > > > -- > > Mario Torre > > Associate Manager, Software Engineering > > Red Hat GmbH > > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From andrew_m_leonard at uk.ibm.com Mon Aug 12 16:15:47 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Mon, 12 Aug 2019 17:15:47 +0100 Subject: [8u] RFR Backport of 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target Message-ID: Hi, Please can I request a review of this updated patch for 8067429 to backport to jdk8u/langtools. We have seen problem reports from clients seeing this issue with jdk8 and would like to request a backport please. The patch is essentially the same as published to jdk9+, but jdk8 the file paths are in a different location. I have built and tested all "tier1" and "langtools_all" successfully, and the patch new testcase passes. http://cr.openjdk.java.net/~aleonard/8067429/webrev.00 Once reviewed I will add the jdk8u-fix-request. Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From andrew_m_leonard at uk.ibm.com Mon Aug 12 16:26:37 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Mon, 12 Aug 2019 17:26:37 +0100 Subject: [8u] RFR Backport of 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target In-Reply-To: References: Message-ID: cc original maillist, see below.. Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Andrew Leonard/UK/IBM To: jdk8u-dev at openjdk.java.net Date: 12/08/2019 17:15 Subject: [8u] RFR Backport of 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target Hi, Please can I request a review of this updated patch for 8067429 to backport to jdk8u/langtools. We have seen problem reports from clients seeing this issue with jdk8 and would like to request a backport please. The patch is essentially the same as published to jdk9+, but jdk8 the file paths are in a different location. I have built and tested all "tier1" and "langtools_all" successfully, and the patch new testcase passes. http://cr.openjdk.java.net/~aleonard/8067429/webrev.00 Once reviewed I will add the jdk8u-fix-request. Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From andrew_m_leonard at uk.ibm.com Mon Aug 12 16:31:15 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Mon, 12 Aug 2019 17:31:15 +0100 Subject: [8u] RFR Backport of 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target In-Reply-To: References: Message-ID: (try again!) cc original maillist, see below.. Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Andrew Leonard/UK/IBM To: jdk8u-dev at openjdk.java.net Date: 12/08/2019 17:15 Subject: [8u] RFR Backport of 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target Hi, Please can I request a review of this updated patch for 8067429 to backport to jdk8u/langtools. We have seen problem reports from clients seeing this issue with jdk8 and would like to request a backport please. The patch is essentially the same as published to jdk9+, but jdk8 the file paths are in a different location. I have built and tested all "tier1" and "langtools_all" successfully, and the patch new testcase passes. http://cr.openjdk.java.net/~aleonard/8067429/webrev.00 Once reviewed I will add the jdk8u-fix-request. Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From OGATAK at jp.ibm.com Mon Aug 12 17:45:28 2019 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Tue, 13 Aug 2019 02:45:28 +0900 Subject: [Ping] Re: [8u-dev, ppc] RFR for (almost clean) backport of 8188868: PPC64: Support AES intrinsics on Big Endian In-Reply-To: <163f9fd2-95ed-512f-c67e-55de4c4f51d1@linux.vnet.ibm.com> References: <2d8d8d35-c781-cc0c-2673-c8f7eea057bd@redhat.com> <163f9fd2-95ed-512f-c67e-55de4c4f51d1@linux.vnet.ibm.com> Message-ID: Hi Gustavo, Thank you for pushing the code. Regards, Ogata "Gustavo Romero" wrote on 2019/08/12 08:34:35: > From: "Gustavo Romero" > To: Kazunori Ogata/Japan/IBM at IBMJP, "Andrew John Hughes" > Cc: hotspot-compiler-dev at openjdk.java.net, jdk8u-dev at openjdk.java.net > Date: 2019/08/12 08:34 > Subject: Re: [Ping] Re: [8u-dev, ppc] RFR for (almost clean) backport of > 8188868: PPC64: Support AES intrinsics on Big Endian > > Hi, > > Thanks Ogata for adjusting the change and evaluating performance on 8u + Power BE. > > Thanks Andrew for reviewing and approving it. > > Pushed to jdk8u-dev: > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/42118db355f5 > > Best regards, > Gustavo > > On 07/31/2019 11:55 PM, Kazunori Ogata wrote: > > Hi Andrew, > > > > Thank you for reviewing the webrev. > > > > Regards, > > Ogata > > > > Andrew John Hughes wrote on 2019/08/01 01:05:48: > > > >> From: Andrew John Hughes > >> To: Kazunori Ogata , hotspot-compiler- > >> dev at openjdk.java.net, jdk8u-dev at openjdk.java.net > >> Date: 2019/08/01 01:13 > >> Subject: [EXTERNAL] Re: [Ping] Re: [8u-dev, ppc] RFR for (almost clean) > >> backport of 8188868: PPC64: Support AES intrinsics on Big Endian > >> > >> > >> > >> On 31/07/2019 10:30, Kazunori Ogata wrote: > >>> Ping. > >>> > >>> May I get review for the almost clean backport? > >>> > >>> Regards, > >>> Ogata > >>> > >>> Kazunori Ogata/Japan/IBM wrote on 2019/07/24 17:48:23: > >>> > >>>> From: Kazunori Ogata/Japan/IBM > >>>> To: hotspot-compiler-dev at openjdk.java.net, jdk8u-dev at openjdk.java.net > >>>> Date: 2019/07/24 17:48 > >>>> Subject: [8u-dev, ppc] RFR for (almost clean) backport of 8188868: > >>> PPC64: > >>>> Support AES intrinsics on Big Endian > >>>> > >>>> Hi, > >>>> > >>>> May I get review for backport of 8188868: PPC64: Support AES > > intrinsics > >>> on > >>>> Big Endian? > >>>> > >>>> The original patch itself can be applied cleanly (besides difference > > of > >>>> the source directory structure). However, one chunk failed because > > the > >>>> code just after the patched code was modified, so I manually applied > > the > >>> > >>>> chunk and renewed the patch. > >>>> > >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8188868 > >>>> Webrev: > >>> http://cr.openjdk.java.net/~ogatak/jdk8u_aes_be/8188868/webrev.02/ > >>>> > >>>> This backport is low risk and affects only PPC64 only. I verified > > there > >>>> was no degradation in "make test" results and SPECjbb 2015 ran fine. > > The > >>> > >>>> intrinsics added in this changeset improved max jOPS by 5% and > > critical > >>> jOPS by 4%. > >>>> > >>>> Regards, > >>>> Ogata > >>> > >> > >> Sorry, I started looking at this yesterday, but didn't get chance to > > finish. > >> > >> It looks fine to me. The stubGenerator_ppc.cpp changes were a little > >> hard to follow, but comparing the patched version with the 11u version > >> looked ok. > >> > >> Good to go. > >> -- > >> Andrew :) > >> > >> Senior Free Java Software Engineer > >> Red Hat, Inc. (http://www.redhat.com) > >> > >> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > >> Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > >> https://keybase.io/gnu_andrew > >> > >> [attachment "signature.asc" deleted by Kazunori Ogata/Japan/IBM] > > From zgu at redhat.com Mon Aug 12 18:36:43 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 12 Aug 2019 14:36:43 -0400 Subject: [8u] RFR 8216401: Allow "file:" URLs in Class-Path of local JARs Message-ID: <53f863a8-0a6e-2f13-4c23-fcb2cfc5053a@redhat.com> Please review 8u backport of above CR. JDK13 patch does not apply cleanly. However, the fix itself applies cleanly, just not the test. 8u ClassFileInstaller does not have some APIs that exist in JDK13. Therefore, I copied/pasted corresponding code from JDK13's ClassFileInstaller into the test (writeClassToDisk and writeToDisk). Original bug: https://bugs.openjdk.java.net/browse/JDK-8216401 Original Webrev: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057868.html Original review thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057868.html 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8216401-8u/webrev.00/ Test: Run attached test case (before and after fix) on Linux 86_64. Thanks, -Zhengyu From zgu at redhat.com Tue Aug 13 18:13:12 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 13 Aug 2019 14:13:12 -0400 Subject: [8u] RFR 8155951 & 8151066 Message-ID: Please review following backports: 8155951: VM crash in nsk/jvmti/RedefineClasses/StressRedefine: assert failed: Corrupted constant pool https://bugs.openjdk.java.net/browse/JDK-8155951 8151066: assert(0 <= i && i < length()) failed: index out of bounds https://bugs.openjdk.java.net/browse/JDK-8151066 Original jdk9 patch contains both fixes and they are all on Oracle 8u backport list. The patch does not apply cleanly. Other than a few minor conflicts, e.g. copyright years, breaking single line long parameter list to multi-lines and line shifts, jdk8u lock declaration (def macro in mutexLocker.cpp) does not take 5th argument. JDK9 code review thread: https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-May/019476.html 8u backport: http://cr.openjdk.java.net/~zgu/JDK-8155951-8u/webrev.00/index.html Thanks, -Zhengyu From verghese at amazon.com Tue Aug 13 18:59:45 2019 From: verghese at amazon.com (Verghese, Clive) Date: Tue, 13 Aug 2019 18:59:45 +0000 Subject: [8u] RFR 8216401: Allow "file:" URLs in Class-Path of local JARs In-Reply-To: <53f863a8-0a6e-2f13-4c23-fcb2cfc5053a@redhat.com> References: <53f863a8-0a6e-2f13-4c23-fcb2cfc5053a@redhat.com> Message-ID: <3C921A78-DEF8-4784-930E-BDE6CFA13EB2@amazon.com> Hi Zhengyu, Instead of importing the writeToDisk function to the test, We could update the ClassFileInstaller to be similar to the one in tip. [1] http://cr.openjdk.java.net/~phh/8216401/webrev.8u0.00/ Regards, Clive Verghese [1] : https://hg.openjdk.java.net/jdk/jdk/file/be8c11fc16bb/test/lib/ClassFileInstaller.java ?On 8/12/19, 11:38 AM, "jdk8u-dev on behalf of Zhengyu Gu" wrote: Please review 8u backport of above CR. JDK13 patch does not apply cleanly. However, the fix itself applies cleanly, just not the test. 8u ClassFileInstaller does not have some APIs that exist in JDK13. Therefore, I copied/pasted corresponding code from JDK13's ClassFileInstaller into the test (writeClassToDisk and writeToDisk). Original bug: https://bugs.openjdk.java.net/browse/JDK-8216401 Original Webrev: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057868.html Original review thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057868.html 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8216401-8u/webrev.00/ Test: Run attached test case (before and after fix) on Linux 86_64. Thanks, -Zhengyu From zgu at redhat.com Tue Aug 13 19:34:28 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 13 Aug 2019 15:34:28 -0400 Subject: [8u] RFR 8216401: Allow "file:" URLs in Class-Path of local JARs In-Reply-To: <3C921A78-DEF8-4784-930E-BDE6CFA13EB2@amazon.com> References: <53f863a8-0a6e-2f13-4c23-fcb2cfc5053a@redhat.com> <3C921A78-DEF8-4784-930E-BDE6CFA13EB2@amazon.com> Message-ID: Hi Clive, On 8/13/19 2:59 PM, Verghese, Clive wrote: > Hi Zhengyu, > > Instead of importing the writeToDisk function to the test, We could update the ClassFileInstaller to be similar to the one in tip. [1] > > http://cr.openjdk.java.net/~phh/8216401/webrev.8u0.00/ I think the principal of 8u backport, is to minimize the scope to absolutely needed. I imported some of ClassFileInstaller code to the test, because I have not seen they are used by others. If that's the case, I think we should arrange partial backport for test library changes. I don't like the idea to sneak in test infrastructure changes via unrelated backports. Thanks, -Zhengyu > > Regards, > Clive Verghese > > [1] : https://hg.openjdk.java.net/jdk/jdk/file/be8c11fc16bb/test/lib/ClassFileInstaller.java > > > > ?On 8/12/19, 11:38 AM, "jdk8u-dev on behalf of Zhengyu Gu" wrote: > > Please review 8u backport of above CR. > JDK13 patch does not apply cleanly. However, the fix itself applies > cleanly, just not the test. > > 8u ClassFileInstaller does not have some APIs that exist in JDK13. > Therefore, I copied/pasted corresponding code from JDK13's > ClassFileInstaller into the test (writeClassToDisk and writeToDisk). > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8216401 > Original Webrev: > https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057868.html > Original review thread: > https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057868.html > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8216401-8u/webrev.00/ > > Test: > Run attached test case (before and after fix) on Linux 86_64. > > Thanks, > > -Zhengyu > > From hohensee at amazon.com Tue Aug 13 20:02:16 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 13 Aug 2019 20:02:16 +0000 Subject: [8u] RFR 8216401: Allow "file:" URLs in Class-Path of local JARs In-Reply-To: References: <53f863a8-0a6e-2f13-4c23-fcb2cfc5053a@redhat.com> <3C921A78-DEF8-4784-930E-BDE6CFA13EB2@amazon.com> Message-ID: <934D8BCF-E52F-4E38-AB0C-38552083AE6F@amazon.com> In this case, we'd be updating ClassFileInstaller.java to match the one in jdk/test/lib/testlibrary. In 11, these are merged into a single version in test/lib/ClassFileInstaller.java, but we can't do that in 8u because there are two different test directories. I expect there may be more instances of the two 8u versions not matching causing problems, so imo the right thing to do is file a bug against 8u to update Hotspot's ClassFileInstaller.java to match the jdk's, and then do this backport. I'd be happy to file the bug and sponsor Clive's fix. Thanks, Paul ?On 8/13/19, 12:36 PM, "jdk8u-dev on behalf of Zhengyu Gu" wrote: Hi Clive, On 8/13/19 2:59 PM, Verghese, Clive wrote: > Hi Zhengyu, > > Instead of importing the writeToDisk function to the test, We could update the ClassFileInstaller to be similar to the one in tip. [1] > > http://cr.openjdk.java.net/~phh/8216401/webrev.8u0.00/ I think the principal of 8u backport, is to minimize the scope to absolutely needed. I imported some of ClassFileInstaller code to the test, because I have not seen they are used by others. If that's the case, I think we should arrange partial backport for test library changes. I don't like the idea to sneak in test infrastructure changes via unrelated backports. Thanks, -Zhengyu > > Regards, > Clive Verghese > > [1] : https://hg.openjdk.java.net/jdk/jdk/file/be8c11fc16bb/test/lib/ClassFileInstaller.java > > > > On 8/12/19, 11:38 AM, "jdk8u-dev on behalf of Zhengyu Gu" wrote: > > Please review 8u backport of above CR. > JDK13 patch does not apply cleanly. However, the fix itself applies > cleanly, just not the test. > > 8u ClassFileInstaller does not have some APIs that exist in JDK13. > Therefore, I copied/pasted corresponding code from JDK13's > ClassFileInstaller into the test (writeClassToDisk and writeToDisk). > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8216401 > Original Webrev: > https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057868.html > Original review thread: > https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057868.html > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8216401-8u/webrev.00/ > > Test: > Run attached test case (before and after fix) on Linux 86_64. > > Thanks, > > -Zhengyu > > From zgu at redhat.com Tue Aug 13 20:09:43 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 13 Aug 2019 16:09:43 -0400 Subject: [8u] RFR 8216401: Allow "file:" URLs in Class-Path of local JARs In-Reply-To: <934D8BCF-E52F-4E38-AB0C-38552083AE6F@amazon.com> References: <53f863a8-0a6e-2f13-4c23-fcb2cfc5053a@redhat.com> <3C921A78-DEF8-4784-930E-BDE6CFA13EB2@amazon.com> <934D8BCF-E52F-4E38-AB0C-38552083AE6F@amazon.com> Message-ID: <33a80c36-82aa-aa53-c06e-e70b62611593@redhat.com> On 8/13/19 4:02 PM, Hohensee, Paul wrote: > In this case, we'd be updating ClassFileInstaller.java to match the one in jdk/test/lib/testlibrary. In 11, these are merged into a single version in test/lib/ClassFileInstaller.java, but we can't do that in 8u because there are two different test directories. I expect there may be more instances of the two 8u versions not matching causing problems, so imo the right thing to do is file a bug against 8u to update Hotspot's ClassFileInstaller.java to match the jdk's, and then do this backport. I'd be happy to file the bug and sponsor Clive's fix. Sounds good to me. I can hold off this patch till then. Thanks, -Zhengyu > > Thanks, > > Paul > > ?On 8/13/19, 12:36 PM, "jdk8u-dev on behalf of Zhengyu Gu" wrote: > > Hi Clive, > > On 8/13/19 2:59 PM, Verghese, Clive wrote: > > Hi Zhengyu, > > > > Instead of importing the writeToDisk function to the test, We could update the ClassFileInstaller to be similar to the one in tip. [1] > > > > http://cr.openjdk.java.net/~phh/8216401/webrev.8u0.00/ > > I think the principal of 8u backport, is to minimize the scope to > absolutely needed. I imported some of ClassFileInstaller code to the > test, because I have not seen they are used by others. If that's the > case, I think we should arrange partial backport for test library > changes. I don't like the idea to sneak in test infrastructure changes > via unrelated backports. > > Thanks, > > -Zhengyu > > > > > Regards, > > Clive Verghese > > > > [1] : https://hg.openjdk.java.net/jdk/jdk/file/be8c11fc16bb/test/lib/ClassFileInstaller.java > > > > > > > > On 8/12/19, 11:38 AM, "jdk8u-dev on behalf of Zhengyu Gu" wrote: > > > > Please review 8u backport of above CR. > > JDK13 patch does not apply cleanly. However, the fix itself applies > > cleanly, just not the test. > > > > 8u ClassFileInstaller does not have some APIs that exist in JDK13. > > Therefore, I copied/pasted corresponding code from JDK13's > > ClassFileInstaller into the test (writeClassToDisk and writeToDisk). > > > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8216401 > > Original Webrev: > > https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057868.html > > Original review thread: > > https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057868.html > > > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8216401-8u/webrev.00/ > > > > Test: > > Run attached test case (before and after fix) on Linux 86_64. > > > > Thanks, > > > > -Zhengyu > > > > > > From hohensee at amazon.com Tue Aug 13 21:39:42 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 13 Aug 2019 21:39:42 +0000 Subject: [8u] RFR 8216401: Allow "file:" URLs in Class-Path of local JARs In-Reply-To: <33a80c36-82aa-aa53-c06e-e70b62611593@redhat.com> References: <53f863a8-0a6e-2f13-4c23-fcb2cfc5053a@redhat.com> <3C921A78-DEF8-4784-930E-BDE6CFA13EB2@amazon.com> <934D8BCF-E52F-4E38-AB0C-38552083AE6F@amazon.com> <33a80c36-82aa-aa53-c06e-e70b62611593@redhat.com> Message-ID: <4AEB880B-B637-4AF5-9B8F-0A20DCCF4FEF@amazon.com> Thanks, Zhengyu. I've filed https://bugs.openjdk.java.net/browse/JDK-8229501. Also, I got it backward. It's the JDK version that needs updating, not the Hotspot version. The above JBS issue gets it right. ?On 8/13/19, 1:10 PM, "Zhengyu Gu" wrote: On 8/13/19 4:02 PM, Hohensee, Paul wrote: > In this case, we'd be updating ClassFileInstaller.java to match the one in jdk/test/lib/testlibrary. In 11, these are merged into a single version in test/lib/ClassFileInstaller.java, but we can't do that in 8u because there are two different test directories. I expect there may be more instances of the two 8u versions not matching causing problems, so imo the right thing to do is file a bug against 8u to update Hotspot's ClassFileInstaller.java to match the jdk's, and then do this backport. I'd be happy to file the bug and sponsor Clive's fix. Sounds good to me. I can hold off this patch till then. Thanks, -Zhengyu > > Thanks, > > Paul > > On 8/13/19, 12:36 PM, "jdk8u-dev on behalf of Zhengyu Gu" wrote: > > Hi Clive, > > On 8/13/19 2:59 PM, Verghese, Clive wrote: > > Hi Zhengyu, > > > > Instead of importing the writeToDisk function to the test, We could update the ClassFileInstaller to be similar to the one in tip. [1] > > > > http://cr.openjdk.java.net/~phh/8216401/webrev.8u0.00/ > > I think the principal of 8u backport, is to minimize the scope to > absolutely needed. I imported some of ClassFileInstaller code to the > test, because I have not seen they are used by others. If that's the > case, I think we should arrange partial backport for test library > changes. I don't like the idea to sneak in test infrastructure changes > via unrelated backports. > > Thanks, > > -Zhengyu > > > > > Regards, > > Clive Verghese > > > > [1] : https://hg.openjdk.java.net/jdk/jdk/file/be8c11fc16bb/test/lib/ClassFileInstaller.java > > > > > > > > On 8/12/19, 11:38 AM, "jdk8u-dev on behalf of Zhengyu Gu" wrote: > > > > Please review 8u backport of above CR. > > JDK13 patch does not apply cleanly. However, the fix itself applies > > cleanly, just not the test. > > > > 8u ClassFileInstaller does not have some APIs that exist in JDK13. > > Therefore, I copied/pasted corresponding code from JDK13's > > ClassFileInstaller into the test (writeClassToDisk and writeToDisk). > > > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8216401 > > Original Webrev: > > https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057868.html > > Original review thread: > > https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057868.html > > > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8216401-8u/webrev.00/ > > > > Test: > > Run attached test case (before and after fix) on Linux 86_64. > > > > Thanks, > > > > -Zhengyu > > > > > > From verghese at amazon.com Tue Aug 13 22:12:46 2019 From: verghese at amazon.com (Verghese, Clive) Date: Tue, 13 Aug 2019 22:12:46 +0000 Subject: [8u] RFR 8229501: jdk/test/lib/testlibrary/ClassFileInstaller.java should match hotspot//test/testlibrary version Message-ID: <0E64BD39-BFDA-4506-BD8B-7B63A7BBD0C8@amazon.com> Hi, Requesting review for webrev : http://cr.openjdk.java.net/~phh/8229501/webrev.8u.00/ JBS Issue : https://bugs.openjdk.java.net/browse/JDK-8229501 Email discussion : https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010029.html hotspot/test/testlibrary/ClassFileInstaller.java and jdk/test/lib/testlibrary/ClassFileInstaller were merged as part of the JDK10 repo merge. For 8u, we should sync the JDK version with the Hotspot version in order to facilitate backports of patches such as the one for JDK-8216401 that assume the merged version. Testing Validated that the test depending on ClassFileInstaller pass. Regards, Clive Verghese From neugens at redhat.com Wed Aug 14 12:24:42 2019 From: neugens at redhat.com (Mario Torre) Date: Wed, 14 Aug 2019 14:24:42 +0200 Subject: RFR: 8223147: JFR Backport (to jdk8u) In-Reply-To: References: Message-ID: Hi Dengui, Azul has pushed their patches now, so those are ok to push. Do you need assistance for this, or do you have already a jdk8u committer? Cheers, Mario On Mon, Aug 12, 2019 at 10:32 AM DDH wrote: > > Hi Mario?Andrey, > > We(Alibaba) recently fixed some test failures about JFR CodeCache events, which are incremental changes based on Azul' patchset. > 8229401: Fix JFR code cache test failures > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_8229401_hs/ > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_8229401_jdk/ > > > The other patchset we provided earlier is as follows: > 8223689: Add JFR Thread Sampling Support > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_thread_samp_20190326/ > > 8223690: Add JFR BiasedLock Event Support > http://cr.openjdk.java.net/~luchsh/hs_biasedlock/ > http://cr.openjdk.java.net/~luchsh/jdk_biasedlock/ > > 8223691: Add JFR G1 Region Type Change Event Support > http://cr.openjdk.java.net/~luchsh/g1region_type_change_event > > 8223692: Add JFR G1 Heap Summary Event Support > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_g1heapsum_hs_20190326/ > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_g1heapsum_jdk_20190326/ > > Thanks, > Denghui -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From zgu at redhat.com Wed Aug 14 14:06:31 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 14 Aug 2019 10:06:31 -0400 Subject: [8u] RFR 8229501: jdk/test/lib/testlibrary/ClassFileInstaller.java should match hotspot//test/testlibrary version In-Reply-To: <0E64BD39-BFDA-4506-BD8B-7B63A7BBD0C8@amazon.com> References: <0E64BD39-BFDA-4506-BD8B-7B63A7BBD0C8@amazon.com> Message-ID: <8b17dd4b-bf60-fd00-bcb5-6709b602b81e@redhat.com> Hi Clive, Looks good to me. I think you need permission to push. Thanks, -Zhengyu On 8/13/19 6:12 PM, Verghese, Clive wrote: > Hi, > > Requesting review for webrev : http://cr.openjdk.java.net/~phh/8229501/webrev.8u.00/ > JBS Issue : https://bugs.openjdk.java.net/browse/JDK-8229501 > Email discussion : https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010029.html > > hotspot/test/testlibrary/ClassFileInstaller.java and jdk/test/lib/testlibrary/ClassFileInstaller were merged as part of the JDK10 repo merge. For 8u, we should sync the JDK version with the Hotspot version in order to facilitate backports of patches such as the one for JDK-8216401 that assume the merged version. > > Testing > Validated that the test depending on ClassFileInstaller pass. > > > Regards, > Clive Verghese > From andrey at azul.com Wed Aug 14 14:27:15 2019 From: andrey at azul.com (Andrey Petushkov) Date: Wed, 14 Aug 2019 14:27:15 +0000 Subject: RFR(xxs): 8229708 JFR backport code does not initialize Message-ID: <00AB5C30-8F7A-400C-9A45-53780C7198DB@azul.com> Dear All, During integration of initial commit for JFR backport one line of code was occasionally forgotten. So here is the change to bring it back. The diff is the following: diff -r b985cbb00e68 src/share/vm/classfile/classFileParser.cpp --- a/src/share/vm/classfile/classFileParser.cpp Mon Aug 12 18:30:40 2019 +0300 +++ b/src/share/vm/classfile/classFileParser.cpp Wed Aug 14 16:15:34 2019 +0300 @@ -4262,6 +4262,8 @@ preserve_this_klass = this_klass(); } + JFR_ONLY(INIT_ID(preserve_this_klass);) + // Create new handle outside HandleMark (might be needed for // Extended Class Redefinition) instanceKlassHandle this_klass (THREAD, preserve_this_klass); as you can easily see this code is part of the required change [1] while not part of commit [2] Naturally without this code the loaded classes are missing their JFR ids and none of the JFR magic happens (at first no class transform so Event classes are missing their eventHandler field, added by transformer, the cause of the error reported) Please approve the fix Thanks, Andrey [1] http://cr.openjdk.java.net/~apetushkov/jfr8/hotspot/src/share/vm/classfile/classFileParser.cpp.udiff.html [2] http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/hotspot/rev/b985cbb00e68#l74.2 From mbalao at redhat.com Wed Aug 14 14:27:24 2019 From: mbalao at redhat.com (Martin Balao) Date: Wed, 14 Aug 2019 11:27:24 -0300 Subject: [8u] RFR 8200400: Allow Sasl mechanisms to be restricted In-Reply-To: <42222cb1-3643-0833-62d4-aa586e8a48c9@redhat.com> References: <42222cb1-3643-0833-62d4-aa586e8a48c9@redhat.com> Message-ID: Hi, On 8/5/19 1:58 PM, Martin Balao wrote: > > I'd like to request a review for the jdk8u backport of JDK-8200400 [1]: > > * > https://cr.openjdk.java.net/~mbalao/webrevs/8200400/8200400.webrev.jdk8u.jdk.00/ > > Changes: > > * Paths > > * java.security change per OS file > > * Sasl.java > * copyright date > * documentation hooks did not apply cleanly > > * Test > * @module jtreg tag removed > * @library path changed > * Asserts import changed > > Testing: > > * javax/security/sasl/Sasl/DisabledMechanisms.java passed > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8200400 > Can someone please have a look at this? JDK-8 backport of this bug has been approved, only the review missing. Thanks, Martin.- From mbalao at redhat.com Wed Aug 14 14:34:35 2019 From: mbalao at redhat.com (Martin Balao) Date: Wed, 14 Aug 2019 11:34:35 -0300 Subject: [8u] RFR 8205507: jdk/javax/xml/crypto/dsig/GenerationTests.java timed out In-Reply-To: References: Message-ID: <482e0be5-8cdd-ac0a-7e35-a7191fc340c0@redhat.com> Hi, On 8/5/19 7:25 PM, Martin Balao wrote: > Hi, > > I'd like to have a review for the jdk8u backport of JDK-8205507 [1]: > > * > http://cr.openjdk.java.net/~mbalao/webrevs/8205507/8205507.webrev.jdk8u.jdk.00/ > > Minor changes in GenerationTests::getCachedKeys function were required. > > Testing: javax/xml/crypto/dsig/GenerationTests.java passed. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8205507 > Can someone please have a look at this? Thanks, Martin.- From hohensee at amazon.com Wed Aug 14 17:40:26 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 14 Aug 2019 17:40:26 +0000 Subject: [8u] RFR 8229501: jdk/test/lib/testlibrary/ClassFileInstaller.java should match hotspot//test/testlibrary version In-Reply-To: <8b17dd4b-bf60-fd00-bcb5-6709b602b81e@redhat.com> References: <0E64BD39-BFDA-4506-BD8B-7B63A7BBD0C8@amazon.com> <8b17dd4b-bf60-fd00-bcb5-6709b602b81e@redhat.com> Message-ID: Thanks, Zhengyu. I've tagged the JBS issue with jdk8u-fix-request, will push on Clive's behalf when I see jdk8u-fix-yes. Paul ?On 8/14/19, 7:08 AM, "jdk8u-dev on behalf of Zhengyu Gu" wrote: Hi Clive, Looks good to me. I think you need permission to push. Thanks, -Zhengyu On 8/13/19 6:12 PM, Verghese, Clive wrote: > Hi, > > Requesting review for webrev : http://cr.openjdk.java.net/~phh/8229501/webrev.8u.00/ > JBS Issue : https://bugs.openjdk.java.net/browse/JDK-8229501 > Email discussion : https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010029.html > > hotspot/test/testlibrary/ClassFileInstaller.java and jdk/test/lib/testlibrary/ClassFileInstaller were merged as part of the JDK10 repo merge. For 8u, we should sync the JDK version with the Hotspot version in order to facilitate backports of patches such as the one for JDK-8216401 that assume the merged version. > > Testing > Validated that the test depending on ClassFileInstaller pass. > > > Regards, > Clive Verghese > From verghese at amazon.com Wed Aug 14 17:45:28 2019 From: verghese at amazon.com (Verghese, Clive) Date: Wed, 14 Aug 2019 17:45:28 +0000 Subject: [8u] RFR 8229501: jdk/test/lib/testlibrary/ClassFileInstaller.java should match hotspot//test/testlibrary version In-Reply-To: References: <0E64BD39-BFDA-4506-BD8B-7B63A7BBD0C8@amazon.com> <8b17dd4b-bf60-fd00-bcb5-6709b602b81e@redhat.com> Message-ID: <9A663630-FACB-4058-8557-238083BC7389@amazon.com> Hi Zhengyu, Thank you for reviewing the change. Regards, Clive Verghese ?On 8/14/19, 10:40 AM, "Hohensee, Paul" wrote: Thanks, Zhengyu. I've tagged the JBS issue with jdk8u-fix-request, will push on Clive's behalf when I see jdk8u-fix-yes. Paul On 8/14/19, 7:08 AM, "jdk8u-dev on behalf of Zhengyu Gu" wrote: Hi Clive, Looks good to me. I think you need permission to push. Thanks, -Zhengyu On 8/13/19 6:12 PM, Verghese, Clive wrote: > Hi, > > Requesting review for webrev : http://cr.openjdk.java.net/~phh/8229501/webrev.8u.00/ > JBS Issue : https://bugs.openjdk.java.net/browse/JDK-8229501 > Email discussion : https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010029.html > > hotspot/test/testlibrary/ClassFileInstaller.java and jdk/test/lib/testlibrary/ClassFileInstaller were merged as part of the JDK10 repo merge. For 8u, we should sync the JDK version with the Hotspot version in order to facilitate backports of patches such as the one for JDK-8216401 that assume the merged version. > > Testing > Validated that the test depending on ClassFileInstaller pass. > > > Regards, > Clive Verghese > From weijun.wang at oracle.com Thu Aug 15 01:56:16 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 15 Aug 2019 09:56:16 +0800 Subject: [8u] RFR 8200400: Allow Sasl mechanisms to be restricted In-Reply-To: References: <42222cb1-3643-0833-62d4-aa586e8a48c9@redhat.com> Message-ID: <7EEE0914-6301-4452-963B-F6A57C7F265B@oracle.com> Oops, I take a look at your fix and realized I had a typo in java.security in my original fix. You might want to use the correct names from the beginning. I filed a bug at https://bugs.openjdk.java.net/browse/JDK-8229767. Typo in java.security: Sasl.createClient and Sasl.createServer "The 2 method names appear in the description of the security property "jdk.sasl.disabledMechanisms". The names should be `Sasl.createSaslClient` and `Sasl.createSaslSever`". This is not a code review. I don't know the policy of jdk8u repos. Thanks, Max > On Aug 14, 2019, at 10:27 PM, Martin Balao wrote: > > Hi, > > On 8/5/19 1:58 PM, Martin Balao wrote: >> >> I'd like to request a review for the jdk8u backport of JDK-8200400 [1]: >> >> * >> https://cr.openjdk.java.net/~mbalao/webrevs/8200400/8200400.webrev.jdk8u.jdk.00/ >> >> Changes: >> >> * Paths >> >> * java.security change per OS file >> >> * Sasl.java >> * copyright date >> * documentation hooks did not apply cleanly >> >> * Test >> * @module jtreg tag removed >> * @library path changed >> * Asserts import changed >> >> Testing: >> >> * javax/security/sasl/Sasl/DisabledMechanisms.java passed >> >> Thanks, >> Martin.- >> >> -- >> [1] - https://bugs.openjdk.java.net/browse/JDK-8200400 >> > > Can someone please have a look at this? > > JDK-8 backport of this bug has been approved, only the review missing. > > Thanks, > Martin.- From denghui.ddh at alibaba-inc.com Thu Aug 15 06:40:29 2019 From: denghui.ddh at alibaba-inc.com (DDH) Date: Thu, 15 Aug 2019 14:40:29 +0800 Subject: =?UTF-8?B?UmU6IFJGUjogODIyMzE0NzogSkZSIEJhY2twb3J0ICh0byBqZGs4dSk=?= In-Reply-To: References: , Message-ID: <3709c0fa-85e0-43a5-ac64-d7467435d69c.denghui.ddh@alibaba-inc.com> Hi mario, We don't have any jdk8u committer, can you help us ? Thanks, denghui ------------------------------------------------------------------ From:Mario Torre Send Time:2019?8?14?(???) 20:25 To:???(??) Cc:jdk8u-dev Subject:Re: RFR: 8223147: JFR Backport (to jdk8u) Hi Dengui, Azul has pushed their patches now, so those are ok to push. Do you need assistance for this, or do you have already a jdk8u committer? Cheers, Mario On Mon, Aug 12, 2019 at 10:32 AM DDH wrote: > > Hi Mario?Andrey, > > We(Alibaba) recently fixed some test failures about JFR CodeCache events, which are incremental changes based on Azul' patchset. > 8229401: Fix JFR code cache test failures > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_8229401_hs/ > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_8229401_jdk/ > > > The other patchset we provided earlier is as follows: > 8223689: Add JFR Thread Sampling Support > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_thread_samp_20190326/ > > 8223690: Add JFR BiasedLock Event Support > http://cr.openjdk.java.net/~luchsh/hs_biasedlock/ > http://cr.openjdk.java.net/~luchsh/jdk_biasedlock/ > > 8223691: Add JFR G1 Region Type Change Event Support > http://cr.openjdk.java.net/~luchsh/g1region_type_change_event > > 8223692: Add JFR G1 Heap Summary Event Support > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_g1heapsum_hs_20190326/ > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_g1heapsum_jdk_20190326/ > > Thanks, > Denghui -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From andrew_m_leonard at uk.ibm.com Thu Aug 15 08:38:23 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Thu, 15 Aug 2019 09:38:23 +0100 Subject: [8u] RFR Backport of 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target In-Reply-To: References: Message-ID: Any offers to review this please? Thanks Andrew From: Andrew Leonard/UK/IBM To: jdk8u-dev at openjdk.java.net Date: 12/08/2019 17:15 Subject: [8u] RFR Backport of 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target Hi, Please can I request a review of this updated patch for 8067429 to backport to jdk8u/langtools. We have seen problem reports from clients seeing this issue with jdk8 and would like to request a backport please. The patch is essentially the same as published to jdk9+, but jdk8 the file paths are in a different location. I have built and tested all "tier1" and "langtools_all" successfully, and the patch new testcase passes. http://cr.openjdk.java.net/~aleonard/8067429/webrev.00 Once reviewed I will add the jdk8u-fix-request. Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From neugens at redhat.com Thu Aug 15 08:45:49 2019 From: neugens at redhat.com (Mario Torre) Date: Thu, 15 Aug 2019 10:45:49 +0200 Subject: RFR: 8223147: JFR Backport (to jdk8u) In-Reply-To: <3709c0fa-85e0-43a5-ac64-d7467435d69c.denghui.ddh@alibaba-inc.com> References: <3709c0fa-85e0-43a5-ac64-d7467435d69c.denghui.ddh@alibaba-inc.com> Message-ID: Yes, Can you please export one patch with all the changesets that applies cleanly to the latest repository? Thanks, Mario On Thu, Aug 15, 2019 at 8:40 AM DDH wrote: > > Hi mario, > > We don't have any jdk8u committer, can you help us ? > > Thanks, > denghui > > ------------------------------------------------------------------ > From:Mario Torre > Send Time:2019?8?14?(???) 20:25 > To:???(??) > Cc:jdk8u-dev > Subject:Re: RFR: 8223147: JFR Backport (to jdk8u) > > Hi Dengui, > > Azul has pushed their patches now, so those are ok to push. > > Do you need assistance for this, or do you have already a jdk8u committer? > > Cheers, > Mario > > On Mon, Aug 12, 2019 at 10:32 AM DDH wrote: > > > > Hi Mario?Andrey, > > > > We(Alibaba) recently fixed some test failures about JFR CodeCache events, which are incremental changes based on Azul' patchset. > > 8229401: Fix JFR code cache test failures > > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_8229401_hs/ > > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_8229401_jdk/ > > > > > > The other patchset we provided earlier is as follows: > > 8223689: Add JFR Thread Sampling Support > > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_thread_samp_20190326/ > > > > 8223690: Add JFR BiasedLock Event Support > > http://cr.openjdk.java.net/~luchsh/hs_biasedlock/ > > http://cr.openjdk.java.net/~luchsh/jdk_biasedlock/ > > > > 8223691: Add JFR G1 Region Type Change Event Support > > http://cr.openjdk.java.net/~luchsh/g1region_type_change_event > > > > 8223692: Add JFR G1 Heap Summary Event Support > > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_g1heapsum_hs_20190326/ > > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_g1heapsum_jdk_20190326/ > > > > Thanks, > > Denghui > > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From neugens at redhat.com Thu Aug 15 08:50:35 2019 From: neugens at redhat.com (Mario Torre) Date: Thu, 15 Aug 2019 10:50:35 +0200 Subject: RFR(xxs): 8229708 JFR backport code does not initialize In-Reply-To: <00AB5C30-8F7A-400C-9A45-53780C7198DB@azul.com> References: <00AB5C30-8F7A-400C-9A45-53780C7198DB@azul.com> Message-ID: Approved. Cheers, Mario On Wed, Aug 14, 2019 at 4:28 PM Andrey Petushkov wrote: > > Dear All, > > During integration of initial commit for JFR backport one line of code was occasionally forgotten. So here is the change to bring it back. > The diff is the following: > > diff -r b985cbb00e68 src/share/vm/classfile/classFileParser.cpp > --- a/src/share/vm/classfile/classFileParser.cpp Mon Aug 12 18:30:40 2019 +0300 > +++ b/src/share/vm/classfile/classFileParser.cpp Wed Aug 14 16:15:34 2019 +0300 > @@ -4262,6 +4262,8 @@ > preserve_this_klass = this_klass(); > } > > + JFR_ONLY(INIT_ID(preserve_this_klass);) > + > // Create new handle outside HandleMark (might be needed for > // Extended Class Redefinition) > instanceKlassHandle this_klass (THREAD, preserve_this_klass); > > as you can easily see this code is part of the required change [1] > while not part of commit [2] > Naturally without this code the loaded classes are missing their JFR ids and none of the JFR magic happens > (at first no class transform so Event classes are missing their eventHandler field, added by transformer, > the cause of the error reported) > > Please approve the fix > > Thanks, > Andrey > > [1] http://cr.openjdk.java.net/~apetushkov/jfr8/hotspot/src/share/vm/classfile/classFileParser.cpp.udiff.html > [2] http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/hotspot/rev/b985cbb00e68#l74.2 -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From denghui.ddh at alibaba-inc.com Fri Aug 16 05:47:23 2019 From: denghui.ddh at alibaba-inc.com (DDH) Date: Fri, 16 Aug 2019 13:47:23 +0800 Subject: =?UTF-8?B?UmU6IFJGUjogODIyMzE0NzogSkZSIEJhY2twb3J0ICh0byBqZGs4dSk=?= In-Reply-To: References: <3709c0fa-85e0-43a5-ac64-d7467435d69c.denghui.ddh@alibaba-inc.com>, Message-ID: Wonderful, I put our patcheset at: http://cr.openjdk.java.net/~luchsh/jfr_cr/patchset_1_hs/ http://cr.openjdk.java.net/~luchsh/jfr_cr/patchset_1_jdk/ Please review them, and let me know if you have any question. Thanks, Denghui ------------------------------------------------------------------ From:Mario Torre Send Time:2019?8?15?(???) 16:46 To:???(??) Cc:jdk8u-dev Subject:Re: RFR: 8223147: JFR Backport (to jdk8u) Yes, Can you please export one patch with all the changesets that applies cleanly to the latest repository? Thanks, Mario On Thu, Aug 15, 2019 at 8:40 AM DDH wrote: > > Hi mario, > > We don't have any jdk8u committer, can you help us ? > > Thanks, > denghui > > ------------------------------------------------------------------ > From:Mario Torre > Send Time:2019?8?14?(???) 20:25 > To:???(??) > Cc:jdk8u-dev > Subject:Re: RFR: 8223147: JFR Backport (to jdk8u) > > Hi Dengui, > > Azul has pushed their patches now, so those are ok to push. > > Do you need assistance for this, or do you have already a jdk8u committer? > > Cheers, > Mario > > On Mon, Aug 12, 2019 at 10:32 AM DDH wrote: > > > > Hi Mario?Andrey, > > > > We(Alibaba) recently fixed some test failures about JFR CodeCache events, which are incremental changes based on Azul' patchset. > > 8229401: Fix JFR code cache test failures > > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_8229401_hs/ > > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_8229401_jdk/ > > > > > > The other patchset we provided earlier is as follows: > > 8223689: Add JFR Thread Sampling Support > > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_thread_samp_20190326/ > > > > 8223690: Add JFR BiasedLock Event Support > > http://cr.openjdk.java.net/~luchsh/hs_biasedlock/ > > http://cr.openjdk.java.net/~luchsh/jdk_biasedlock/ > > > > 8223691: Add JFR G1 Region Type Change Event Support > > http://cr.openjdk.java.net/~luchsh/g1region_type_change_event > > > > 8223692: Add JFR G1 Heap Summary Event Support > > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_g1heapsum_hs_20190326/ > > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_g1heapsum_jdk_20190326/ > > > > Thanks, > > Denghui > > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From shade at redhat.com Fri Aug 16 09:12:49 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 16 Aug 2019 11:12:49 +0200 Subject: [8u-jfr] RFR (S) 8203287: Zero fails to build after JDK-8199712 (Flight Recorder) Message-ID: Missing backport: https://bugs.openjdk.java.net/browse/JDK-8203287 Zero fails to build, because files are missing and some defines are wrong. Most of that is fixed in the original backport, so I just needed to adapt it for jfr-8u-incubator. vm_version_ext_zero required dropping cpu_description support -- it is not available in 8u. Changes in jfrTime.cpp are already present in 8u backport. Webrev for jdk8u-jfr-incubator/hotspot: https://cr.openjdk.java.net/~shade/8203287/webrev.8u-jfr.01/ I don't think I have push privileges for that repository, so would appreciate sponsorship. Testing: x86_64 zero build -- Thanks, -Aleksey From neugens at redhat.com Fri Aug 16 11:51:40 2019 From: neugens at redhat.com (Mario Torre) Date: Fri, 16 Aug 2019 13:51:40 +0200 Subject: [8u-jfr] RFR (S) 8203287: Zero fails to build after JDK-8199712 (Flight Recorder) In-Reply-To: References: Message-ID: Hi Aleksey, Patch looks good, I have only one question to what happens if someone does indeed call this: + bool pd_get_top_frame_for_profiling(frame* fr_addr, + void* ucontext, + bool isInJava) { + ShouldNotCallThis(); + return false; // silence compile warning + } + This is done by src/share/vm/jfr/periodic/sampling/jfrCallTrace.cpp as far as I can see. You have commit right afaik, the repository is open to anyone who has privileges for 8u-dev. Cheers, Mario On Fri, Aug 16, 2019 at 11:14 AM Aleksey Shipilev wrote: > > Missing backport: > https://bugs.openjdk.java.net/browse/JDK-8203287 > > Zero fails to build, because files are missing and some defines are wrong. Most of that is fixed in > the original backport, so I just needed to adapt it for jfr-8u-incubator. vm_version_ext_zero > required dropping cpu_description support -- it is not available in 8u. Changes in jfrTime.cpp are > already present in 8u backport. > > Webrev for jdk8u-jfr-incubator/hotspot: > https://cr.openjdk.java.net/~shade/8203287/webrev.8u-jfr.01/ > > I don't think I have push privileges for that repository, so would appreciate sponsorship. > > Testing: x86_64 zero build > > -- > Thanks, > -Aleksey > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From shade at redhat.com Fri Aug 16 12:41:03 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 16 Aug 2019 14:41:03 +0200 Subject: [8u-jfr] RFR (S) 8203287: Zero fails to build after JDK-8199712 (Flight Recorder) In-Reply-To: References: Message-ID: On 8/16/19 1:51 PM, Mario Torre wrote: > Hi Aleksey, > > Patch looks good, I have only one question to what happens if someone > does indeed call this: > > + bool pd_get_top_frame_for_profiling(frame* fr_addr, > + void* ucontext, > + bool isInJava) { > + ShouldNotCallThis(); > + return false; // silence compile warning > + } > + VM would abort with hs_err saying so. I believe JFR would be disabled at build-time when building Zero, so this should be unreachable at runtime. I believe that hunk was to plug the build/linkage failure. -Aleksey From sgehwolf at redhat.com Fri Aug 16 12:45:09 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 16 Aug 2019 14:45:09 +0200 Subject: [8u-jfr] RFR (S) 8203287: Zero fails to build after JDK-8199712 (Flight Recorder) In-Reply-To: References: Message-ID: <372e0988056906dd50cb5844d238a3354fed3cf5.camel@redhat.com> Hi Mario, On Fri, 2019-08-16 at 13:51 +0200, Mario Torre wrote: > Hi Aleksey, > > Patch looks good, I have only one question to what happens if someone > does indeed call this: > > + bool pd_get_top_frame_for_profiling(frame* fr_addr, > + void* ucontext, > + bool isInJava) { > + ShouldNotCallThis(); > + return false; // silence compile warning > + } > + > > This is done by src/share/vm/jfr/periodic/sampling/jfrCallTrace.cpp as > far as I can see. Then somebody is trying to do JFR profiling on a Zero JVM which isn't supported. The patch proposed is just enough to get Zero building again with the JFR port so it seems reasonable. Thanks, Severin > You have commit right afaik, the repository is open to anyone who has > privileges for 8u-dev. > > Cheers, > Mario > > On Fri, Aug 16, 2019 at 11:14 AM Aleksey Shipilev wrote: > > Missing backport: > > https://bugs.openjdk.java.net/browse/JDK-8203287 > > > > Zero fails to build, because files are missing and some defines are wrong. Most of that is fixed in > > the original backport, so I just needed to adapt it for jfr-8u-incubator. vm_version_ext_zero > > required dropping cpu_description support -- it is not available in 8u. Changes in jfrTime.cpp are > > already present in 8u backport. > > > > Webrev for jdk8u-jfr-incubator/hotspot: > > https://cr.openjdk.java.net/~shade/8203287/webrev.8u-jfr.01/ > > > > I don't think I have push privileges for that repository, so would appreciate sponsorship. > > > > Testing: x86_64 zero build > > > > -- > > Thanks, > > -Aleksey > > > > From neugens at redhat.com Fri Aug 16 13:26:44 2019 From: neugens at redhat.com (Mario Torre) Date: Fri, 16 Aug 2019 15:26:44 +0200 Subject: [8u-jfr] RFR (S) 8203287: Zero fails to build after JDK-8199712 (Flight Recorder) In-Reply-To: <372e0988056906dd50cb5844d238a3354fed3cf5.camel@redhat.com> References: <372e0988056906dd50cb5844d238a3354fed3cf5.camel@redhat.com> Message-ID: On Fri, Aug 16, 2019 at 2:45 PM Severin Gehwolf wrote: > > Hi Mario, > > On Fri, 2019-08-16 at 13:51 +0200, Mario Torre wrote: > > Hi Aleksey, > > > > Patch looks good, I have only one question to what happens if someone > > does indeed call this: > > > > + bool pd_get_top_frame_for_profiling(frame* fr_addr, > > + void* ucontext, > > + bool isInJava) { > > + ShouldNotCallThis(); > > + return false; // silence compile warning > > + } > > + > > > > This is done by src/share/vm/jfr/periodic/sampling/jfrCallTrace.cpp as > > far as I can see. > > Then somebody is trying to do JFR profiling on a Zero JVM which isn't > supported. The patch proposed is just enough to get Zero building again > with the JFR port so it seems reasonable. Yeah, I guess that trying to profile with zero would be a stretch. Maybe we should have a patch that disables the option to run with JFR in the first place. Nonetheless this would be a separate call, the patch is good to go. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From shade at redhat.com Fri Aug 16 13:49:37 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 16 Aug 2019 15:49:37 +0200 Subject: [8u-jfr] RFR (S) 8203287: Zero fails to build after JDK-8199712 (Flight Recorder) In-Reply-To: References: <372e0988056906dd50cb5844d238a3354fed3cf5.camel@redhat.com> Message-ID: <180e4f40-b03a-a78d-73aa-6f3e2eac30dd@redhat.com> On 8/16/19 3:26 PM, Mario Torre wrote: > Yeah, I guess that trying to profile with zero would be a stretch. > Maybe we should have a patch that disables the option to run with JFR > in the first place. Nonetheless this would be a separate call, the > patch is good to go. I believe build system should take care of that. Anyway, I pushed the fix. -- Thanks, -Aleksey From shade at redhat.com Fri Aug 16 14:03:36 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 16 Aug 2019 16:03:36 +0200 Subject: [8u] RFR (S) 8223177: Data race on JvmtiEnvBase::_tag_map in double-checked locking In-Reply-To: References: <798ff717-a966-2ca2-9f9d-56f8019f78a9@redhat.com> Message-ID: Thanks folks. Awaiting 8u maintainer ack. On 8/7/19 10:57 PM, serguei.spitsyn at oracle.com wrote: > Hi Aleksey, > > The backport looks good. > > Thanks, > Serguei > > > On 8/7/19 03:53, Aleksey Shipilev wrote: >> Original bug: >> ?? https://bugs.openjdk.java.net/browse/JDK-8223177 >> ?? https://hg.openjdk.java.net/jdk/jdk/rev/27c8a2e0b0e5 >> >> This patch applies to 8u, but does not compile, because regular OrderAccess methods do not accept >> pointers. We need to use the *_ptr_* versions of the same methods and do casts from void*. >> >> 8u webrev: >> ?? http://cr.openjdk.java.net/~shade/8223177/webrev.8u.01/ >> >> Testing: tier1 >> > -- Thanks, -Aleksey From stooke at redhat.com Fri Aug 16 14:04:21 2019 From: stooke at redhat.com (Simon Tooke) Date: Fri, 16 Aug 2019 10:04:21 -0400 Subject: [8u] RFR backport of JDK-8150432: java/util/Locale/LocaleProviders.sh failed on Win10. In-Reply-To: <9812fd37-cb6c-263e-fa6c-7766f439a287@redhat.com> References: <9812fd37-cb6c-263e-fa6c-7766f439a287@redhat.com> Message-ID: <7a30e701-8064-7ef4-7b26-be09a5849b4c@redhat.com> (reposting with a correction; the backport did not apply cleanly so I have a webrev) Hi, I'd like to request a backport of JDK-8150432. The patch (from JDK9 pre repo merge) applies with only a change to a comment, and fixes the issue encountered by some JDK 8 developers who run tests on a newer version of Cygwin than the test was written for.? If you look at LocaleProviders.sh, it has many hard-coded OS versions with differing behaviours and no explanation; but this fix (that I propose backporting) exists and addresses the current issue. Original bug: https://bugs.openjdk.java.net/browse/JDK-8150432 Proposed patch: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8150432-jdk8u/webrev.00/webrev.jdk.00/ Original patch: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/91a26000bfb5 Thank you for your time, -Simon From shade at redhat.com Fri Aug 16 14:08:54 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 16 Aug 2019 16:08:54 +0200 Subject: [8u] RFR backport of JDK-8150432: java/util/Locale/LocaleProviders.sh failed on Win10. In-Reply-To: <7a30e701-8064-7ef4-7b26-be09a5849b4c@redhat.com> References: <9812fd37-cb6c-263e-fa6c-7766f439a287@redhat.com> <7a30e701-8064-7ef4-7b26-be09a5849b4c@redhat.com> Message-ID: <25fc8871-f02d-1306-42e5-ee18ad8fb647@redhat.com> On 8/16/19 4:04 PM, Simon Tooke wrote: > Proposed patch: > http://cr.openjdk.java.net/~stooke/webrevs/jdk-8150432-jdk8u/webrev.00/webrev.jdk.00/ Backport looks okay. -- Thanks, -Aleksey From sgehwolf at redhat.com Fri Aug 16 14:37:58 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 16 Aug 2019 16:37:58 +0200 Subject: [8u] RFR backport of JDK-8150432: java/util/Locale/LocaleProviders.sh failed on Win10. In-Reply-To: <25fc8871-f02d-1306-42e5-ee18ad8fb647@redhat.com> References: <9812fd37-cb6c-263e-fa6c-7766f439a287@redhat.com> <7a30e701-8064-7ef4-7b26-be09a5849b4c@redhat.com> <25fc8871-f02d-1306-42e5-ee18ad8fb647@redhat.com> Message-ID: On Fri, 2019-08-16 at 16:08 +0200, Aleksey Shipilev wrote: > On 8/16/19 4:04 PM, Simon Tooke wrote: > > Proposed patch: > > http://cr.openjdk.java.net/~stooke/webrevs/jdk-8150432-jdk8u/webrev.00/webrev.jdk.00/ > > Backport looks okay. +1 Thanks, Severin From rkennke at redhat.com Fri Aug 16 16:08:52 2019 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 16 Aug 2019 18:08:52 +0200 Subject: RFR: 8213325: (props) Properties.loadFromXML does not fully comply with the spec Message-ID: <1d0a8a5d-3467-99ed-3dff-187b70ea95fa@redhat.com> This is a backport of: https://bugs.openjdk.java.net/browse/JDK-8227274 which is a backport of the original: https://bugs.openjdk.java.net/browse/JDK-8213325 It's mostly the original change with a few significant extra modifications: - src/share/classes/sun/util/xml/META-INF/services/sun.util.spi.XmlPropertiesProvider is changed from: sun.util.xml.PlatformXmlPropertiesProvider to: jdk.internal.util.xml.BasicXmlPropertiesProvider The reason is that the fix is for the latter, but 8u uses the former by default. As far as I understand, the latter uses the new slimmer parser, while the former uses the fullblown XML parser, but I am not sure about that. However, we need to consider this, because it might be a very significant change. The alternative would be to port over the fixes to the other XML parser, which I have no desire to do. - The (test) JAR file: test/java/util/spi/ResourceBundleControlProvider/rbcontrolprovider.jar has been regenerated from the modified sources XmlRB.xml and XmlRB_ja.xml. This is not present in jdk11 and later. I think it's generated on the fly and not checked-in. Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8213325/webrev.00/ Testing: New testcases are passing. No regressions in tier1 tests. Opinions? Can I get reviews? Thanks, Roman From neugens at redhat.com Mon Aug 19 08:13:42 2019 From: neugens at redhat.com (Mario Torre) Date: Mon, 19 Aug 2019 10:13:42 +0200 Subject: RFR: 8223147: JFR Backport (to jdk8u) In-Reply-To: References: <3709c0fa-85e0-43a5-ac64-d7467435d69c.denghui.ddh@alibaba-inc.com> Message-ID: Pushed. Cheers, Mario On Fri, Aug 16, 2019 at 7:47 AM DDH wrote: > > Wonderful, I put our patcheset at: > http://cr.openjdk.java.net/~luchsh/jfr_cr/patchset_1_hs/ > http://cr.openjdk.java.net/~luchsh/jfr_cr/patchset_1_jdk/ > > Please review them, and let me know if you have any question. > > > Thanks, > Denghui > > ------------------------------------------------------------------ > From:Mario Torre > Send Time:2019?8?15?(???) 16:46 > To:???(??) > Cc:jdk8u-dev > Subject:Re: RFR: 8223147: JFR Backport (to jdk8u) > > Yes, > > Can you please export one patch with all the changesets that applies > cleanly to the latest repository? > > Thanks, > Mario > > On Thu, Aug 15, 2019 at 8:40 AM DDH wrote: > > > > Hi mario, > > > > We don't have any jdk8u committer, can you help us ? > > > > Thanks, > > denghui > > > > ------------------------------------------------------------------ > > From:Mario Torre > > Send Time:2019?8?14?(???) 20:25 > > To:???(??) > > Cc:jdk8u-dev > > Subject:Re: RFR: 8223147: JFR Backport (to jdk8u) > > > > Hi Dengui, > > > > Azul has pushed their patches now, so those are ok to push. > > > > Do you need assistance for this, or do you have already a jdk8u committer? > > > > Cheers, > > Mario > > > > On Mon, Aug 12, 2019 at 10:32 AM DDH wrote: > > > > > > Hi Mario?Andrey, > > > > > > We(Alibaba) recently fixed some test failures about JFR CodeCache events, which are incremental changes based on Azul' patchset. > > > 8229401: Fix JFR code cache test failures > > > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_8229401_hs/ > > > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_8229401_jdk/ > > > > > > > > > The other patchset we provided earlier is as follows: > > > 8223689: Add JFR Thread Sampling Support > > > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_thread_samp_20190326/ > > > > > > 8223690: Add JFR BiasedLock Event Support > > > http://cr.openjdk.java.net/~luchsh/hs_biasedlock/ > > > http://cr.openjdk.java.net/~luchsh/jdk_biasedlock/ > > > > > > 8223691: Add JFR G1 Region Type Change Event Support > > > http://cr.openjdk.java.net/~luchsh/g1region_type_change_event > > > > > > 8223692: Add JFR G1 Heap Summary Event Support > > > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_g1heapsum_hs_20190326/ > > > http://cr.openjdk.java.net/~luchsh/jfr_cr/cr_g1heapsum_jdk_20190326/ > > > > > > Thanks, > > > Denghui > > > > > > > > -- > > Mario Torre > > Associate Manager, Software Engineering > > Red Hat GmbH > > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From shade at redhat.com Mon Aug 19 10:18:26 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 19 Aug 2019 12:18:26 +0200 Subject: RFR: 8223147: JFR Backport (to jdk8u) In-Reply-To: References: <3709c0fa-85e0-43a5-ac64-d7467435d69c.denghui.ddh@alibaba-inc.com> Message-ID: This push broke jdk8u/jdk8u-jfr-incubator build, need to add this: diff -r a248d0be1309 src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp --- a/src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Mon Aug 19 10:11:31 2019 +0200 +++ b/src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Mon Aug 19 12:16:41 2019 +0200 @@ -39,4 +39,5 @@ #include "gc_implementation/g1/heapRegionManager.hpp" #include "gc_implementation/g1/heapRegionSet.hpp" +#include "gc_implementation/shared/gcHeapSummary.hpp" #include "gc_implementation/shared/hSpaceCounters.hpp" #include "gc_implementation/shared/parGCAllocBuffer.hpp" diff -r a248d0be1309 src/share/vm/jfr/recorder/checkpoint/types/jfrType.cpp --- a/src/share/vm/jfr/recorder/checkpoint/types/jfrType.cpp Mon Aug 19 10:11:31 2019 +0200 +++ b/src/share/vm/jfr/recorder/checkpoint/types/jfrType.cpp Mon Aug 19 12:16:41 2019 +0200 @@ -56,5 +56,5 @@ #endif #if INCLUDE_ALL_GCS -//#include "gc_implementation/g1/g1HeapRegionTraceType.hpp" +#include "gc_implementation/g1/g1HeapRegionTraceType.hpp" #include "gc_implementation/g1/g1YCTypes.hpp" #endif Please submit the bug and push this? On 8/19/19 10:13 AM, Mario Torre wrote: > Pushed. > > On Fri, Aug 16, 2019 at 7:47 AM DDH wrote: >> >> Wonderful, I put our patcheset at: >> http://cr.openjdk.java.net/~luchsh/jfr_cr/patchset_1_hs/ >> http://cr.openjdk.java.net/~luchsh/jfr_cr/patchset_1_jdk/ -- Thanks, -Aleksey From neugens at redhat.com Mon Aug 19 10:38:26 2019 From: neugens at redhat.com (Mario Torre) Date: Mon, 19 Aug 2019 12:38:26 +0200 Subject: RFR: 8223147: JFR Backport (to jdk8u) In-Reply-To: References: <3709c0fa-85e0-43a5-ac64-d7467435d69c.denghui.ddh@alibaba-inc.com> Message-ID: On Mon, Aug 19, 2019 at 12:18 PM Aleksey Shipilev wrote: > > This push broke jdk8u/jdk8u-jfr-incubator build, need to add this: > > diff -r a248d0be1309 src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp > --- a/src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Mon Aug 19 10:11:31 2019 +0200 > +++ b/src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Mon Aug 19 12:16:41 2019 +0200 > @@ -39,4 +39,5 @@ > #include "gc_implementation/g1/heapRegionManager.hpp" > #include "gc_implementation/g1/heapRegionSet.hpp" > +#include "gc_implementation/shared/gcHeapSummary.hpp" > #include "gc_implementation/shared/hSpaceCounters.hpp" > #include "gc_implementation/shared/parGCAllocBuffer.hpp" > diff -r a248d0be1309 src/share/vm/jfr/recorder/checkpoint/types/jfrType.cpp > --- a/src/share/vm/jfr/recorder/checkpoint/types/jfrType.cpp Mon Aug 19 10:11:31 2019 +0200 > +++ b/src/share/vm/jfr/recorder/checkpoint/types/jfrType.cpp Mon Aug 19 12:16:41 2019 +0200 > @@ -56,5 +56,5 @@ > #endif > #if INCLUDE_ALL_GCS > -//#include "gc_implementation/g1/g1HeapRegionTraceType.hpp" > +#include "gc_implementation/g1/g1HeapRegionTraceType.hpp" > #include "gc_implementation/g1/g1YCTypes.hpp" > #endif > > Please submit the bug and push this? Hmm, weird, I did a full build before pushing and didn't see anything wrong. I'll push the fix asap. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From shade at redhat.com Mon Aug 19 10:40:13 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 19 Aug 2019 12:40:13 +0200 Subject: RFR: 8223147: JFR Backport (to jdk8u) In-Reply-To: References: <3709c0fa-85e0-43a5-ac64-d7467435d69c.denghui.ddh@alibaba-inc.com> Message-ID: <5414e7b9-fc4d-bb10-da94-0e858c966a41@redhat.com> On 8/19/19 12:38 PM, Mario Torre wrote: > On Mon, Aug 19, 2019 at 12:18 PM Aleksey Shipilev wrote: >> Please submit the bug and push this? > > Hmm, weird, I did a full build before pushing and didn't see anything > wrong. I'll push the fix asap. Try with --disable-precompiled-headers. It catches #include problems early. -- Thanks, -Aleksey From shade at redhat.com Mon Aug 19 16:51:26 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 19 Aug 2019 18:51:26 +0200 Subject: RFR(xxs): 8229708 JFR backport code does not initialize In-Reply-To: References: <00AB5C30-8F7A-400C-9A45-53780C7198DB@azul.com> Message-ID: <3630ca0f-b150-500a-890a-4e319432eff1@redhat.com> Hey Andrey, Could you please push it? This would allow us to test 8u JFR, finally :) -Aleksey On 8/15/19 10:50 AM, Mario Torre wrote: > Approved. > > Cheers, > Mario > > On Wed, Aug 14, 2019 at 4:28 PM Andrey Petushkov wrote: >> >> Dear All, >> >> During integration of initial commit for JFR backport one line of code was occasionally forgotten. So here is the change to bring it back. >> The diff is the following: >> >> diff -r b985cbb00e68 src/share/vm/classfile/classFileParser.cpp >> --- a/src/share/vm/classfile/classFileParser.cpp Mon Aug 12 18:30:40 2019 +0300 >> +++ b/src/share/vm/classfile/classFileParser.cpp Wed Aug 14 16:15:34 2019 +0300 >> @@ -4262,6 +4262,8 @@ >> preserve_this_klass = this_klass(); >> } >> >> + JFR_ONLY(INIT_ID(preserve_this_klass);) >> + >> // Create new handle outside HandleMark (might be needed for >> // Extended Class Redefinition) >> instanceKlassHandle this_klass (THREAD, preserve_this_klass); >> >> as you can easily see this code is part of the required change [1] >> while not part of commit [2] >> Naturally without this code the loaded classes are missing their JFR ids and none of the JFR magic happens >> (at first no class transform so Event classes are missing their eventHandler field, added by transformer, >> the cause of the error reported) >> >> Please approve the fix >> >> Thanks, >> Andrey >> >> [1] http://cr.openjdk.java.net/~apetushkov/jfr8/hotspot/src/share/vm/classfile/classFileParser.cpp.udiff.html >> [2] http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/hotspot/rev/b985cbb00e68#l74.2 > > > -- Thanks, -Aleksey From shade at redhat.com Mon Aug 19 16:55:18 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 19 Aug 2019 18:55:18 +0200 Subject: RFR(xxs): 8229708 JFR backport code does not initialize In-Reply-To: <3630ca0f-b150-500a-890a-4e319432eff1@redhat.com> References: <00AB5C30-8F7A-400C-9A45-53780C7198DB@azul.com> <3630ca0f-b150-500a-890a-4e319432eff1@redhat.com> Message-ID: On 8/19/19 6:51 PM, Aleksey Shipilev wrote: > Could you please push it? This would allow us to test 8u JFR, finally :) Don't mind me, it was already pushed: http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/hotspot/rev/7d05a422d710 -Aleksey From vicente.romero at oracle.com Mon Aug 19 18:59:57 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 19 Aug 2019 14:59:57 -0400 Subject: [8u] RFR Backport of 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target In-Reply-To: References: Message-ID: <16723387-7f3e-bc37-c533-9c63700d897a@oracle.com> the backport looks good to me, Vicente On 8/15/19 4:38 AM, Andrew Leonard wrote: > Any offers to review this please? > Thanks > Andrew > > > > > From: Andrew Leonard/UK/IBM > To: jdk8u-dev at openjdk.java.net > Date: 12/08/2019 17:15 > Subject: [8u] RFR Backport of 8067429: java.lang.VerifyError: > Inconsistent stackmap frames at branch target > > > Hi, > Please can I request a review of this updated patch for 8067429 to > backport to jdk8u/langtools. We have seen problem reports from clients > seeing this issue with jdk8 and would like to request a backport please. > The patch is essentially the same as published to jdk9+, but jdk8 the file > paths are in a different location. I have built and tested all "tier1" and > "langtools_all" successfully, and the patch new testcase passes. > http://cr.openjdk.java.net/~aleonard/8067429/webrev.00 > Once reviewed I will add the jdk8u-fix-request. > > Many thanks > Andrew > > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From shade at redhat.com Mon Aug 19 19:03:58 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 19 Aug 2019 21:03:58 +0200 Subject: 8u-jfr-incubator: binary builds, webrevs Message-ID: Hi there, My CI finally builds 8u-jfr-incubator binaries: https://builds.shipilev.net/openjdk-jdk8-jfr/ Also, webrevs against 8u upstream are available here: https://builds.shipilev.net/patch-openjdk-jdk8-jfr/ Both are automatically updated nightly/weekly. Vanilla JMC is not able to connect to those builds yet, unless you hack out the version detection paths a bit. The JMC binaries linked below contain that hack, and thus are able to connect: https://bugs.openjdk.java.net/browse/JMC-6554 https://builds.shipilev.net/jmc/ -- Thanks, -Aleksey From zgu at redhat.com Mon Aug 19 19:14:21 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 19 Aug 2019 15:14:21 -0400 Subject: [8u] 8178870: instrumentation.retransformClasses cause coredump Message-ID: I would like to backport this patch to 8u, as it is on Oracle 8u backport list. The original patch does not apply cleanly. 1) Missing get_ik() function in jvmtiRedefineClasses.cpp in 8u code base. I imported get_ik() into 8u code base. 2) _scratch_classes was declared as Klass** in 8u, but InstanceKlass** in 10. Added casting in 8u code. 3) Missing test infrastructure in 8u, converted test to shell script. Original bug: https://bugs.openjdk.java.net/browse/JDK-8178870 Original code review: https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-October/024727.html 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8178870-8u/webrev.00/ Thanks, -Zhengyu From mbalao at redhat.com Mon Aug 19 22:21:10 2019 From: mbalao at redhat.com (Martin Balao) Date: Mon, 19 Aug 2019 19:21:10 -0300 Subject: [8u] RFR 8200400: Allow Sasl mechanisms to be restricted In-Reply-To: <7EEE0914-6301-4452-963B-F6A57C7F265B@oracle.com> References: <42222cb1-3643-0833-62d4-aa586e8a48c9@redhat.com> <7EEE0914-6301-4452-963B-F6A57C7F265B@oracle.com> Message-ID: <7e2399fd-607b-ace0-0c00-34a72adbbb1a@redhat.com> Hi Max, Thanks for this followup. I've requested the JDK-11 and JDK-8 backports of 8229767 [1]. Can any JDK-11/JDK-8 maintainer please approve both 8229767 [1] and 8200400 [2] backports? Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8229767 [2] - https://bugs.openjdk.java.net/browse/JDK-8200400 On 8/14/19 10:56 PM, Weijun Wang wrote: > Oops, I take a look at your fix and realized I had a typo in java.security in my original fix. You might want to use the correct names from the beginning. > > I filed a bug at > > https://bugs.openjdk.java.net/browse/JDK-8229767. > Typo in java.security: Sasl.createClient and Sasl.createServer > > "The 2 method names appear in the description of the security property "jdk.sasl.disabledMechanisms". The names should be `Sasl.createSaslClient` and `Sasl.createSaslSever`". > > This is not a code review. I don't know the policy of jdk8u repos. From felix.yang at huawei.com Tue Aug 20 02:43:08 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 20 Aug 2019 02:43:08 +0000 Subject: Request for Approval: Backport of 8047212 : runtime/ParallelClassLoading/bootstrap/random/inner-complex assert(ObjectSynchronizer::verify_objmon_isinpool(inf)) failed: monitor is invalid Message-ID: Hi, May I got review for the backport of 8146792 to 8u master repo please? Webrev: http://cr.openjdk.java.net/~fyang/8047212-8u-backport/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8047212 JDK9 Changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/a0c7a69277da This bug can always be reproduced by running jcstress test on our 64/128-core aarch64 server platform with 8u aarch64 fastdebug build. Error messge: # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/yangfei/openjdk8u-aarch64/hotspot/src/share/vm/runtime/synchronizer.cpp:1252), pid=16581, tid=0x0000ffff23c7f200 # assert(ObjectSynchronizer::verify_objmon_isinpool(inf)) failed: monitor is invalid # # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-fastdebug-yangfei_2019_08_18_14_24-b00) # Java VM: OpenJDK 64-Bit Server VM (25.71-b00-fastdebug mixed mode linux-aarch64 compressed oops) # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x0000ffff24123000): JavaThread "worker1" daemon [_thread_in_Java, id=16798, stack(0x0000ffff23a7f000,0x0000ffff23c80000)] Stack: [0x0000ffff23a7f000,0x0000ffff23c80000], sp=0x0000ffff23c7dac0, free space=2042k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x1117444] VMError::report_and_die()+0x144 V [libjvm.so+0x703ba4] report_vm_error(char const*, int, char const*, char const*)+0x7c V [libjvm.so+0x1032a78] ObjectSynchronizer::inflate(Thread*, oop)+0xbc8 V [libjvm.so+0x1036b40] ObjectSynchronizer::slow_exit(oop, BasicLock*, Thread*)+0x110 V [libjvm.so+0xeeb340] SharedRuntime::complete_monitor_unlocking_C(oopDesc*, BasicLock*)+0x130 J 73% C2 org.openjdk.jcstress.tests.seqcst.sync.L1_S1__S1__S1__S2_L2__Test_jcstress.actor3()Ljava/lang/Void; (166 bytes) @ 0x0000ffff782c4318 [0x0000ffff782c2 f80+0x1398] C 0x0000ffff2e872650 As the patch changes shared code, it has to be backported to 8u master repo before it goes to 8u-aarch64 repo. Due to the use of 'PaddedEnd' in jdk9 or higher version, some trivial tweaks are necessary for the backport. As we changed to use ordered access for global `gBlockList`, risk should be low. Jtreg tested with 8u x86_64 fastdebug build. Also passed two round of jcstress test with 8u aarch64 fastdebug build. Thanks for your help, Felix From serguei.spitsyn at oracle.com Tue Aug 20 04:59:58 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 19 Aug 2019 21:59:58 -0700 Subject: [8u] 8178870: instrumentation.retransformClasses cause coredump In-Reply-To: References: Message-ID: Hi Zhengyu, The backport looks good to me. Thanks, Serguei On 8/19/19 12:14, Zhengyu Gu wrote: > > I would like to backport this patch to 8u, as it is on Oracle 8u > backport list. > > The original patch does not apply cleanly. > > 1) Missing get_ik() function in jvmtiRedefineClasses.cpp in 8u code > base. I imported get_ik() into 8u code base. > 2) _scratch_classes was declared as Klass** in 8u, but InstanceKlass** > in 10. Added casting in 8u code. > 3) Missing test infrastructure in 8u, converted test to shell script. > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8178870 > Original code review: > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-October/024727.html > > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8178870-8u/webrev.00/ > > Thanks, > > -Zhengyu > > > From neugens at redhat.com Tue Aug 20 06:29:56 2019 From: neugens at redhat.com (Mario Torre) Date: Tue, 20 Aug 2019 08:29:56 +0200 Subject: 8u-jfr-incubator: binary builds, webrevs In-Reply-To: References: Message-ID: <8012a548-f256-17eb-8560-24ef5939f359@redhat.com> On 19/08/2019 21:03, Aleksey Shipilev wrote: > Hi there, > > My CI finally builds 8u-jfr-incubator binaries: > https://builds.shipilev.net/openjdk-jdk8-jfr/ > > Also, webrevs against 8u upstream are available here: > https://builds.shipilev.net/patch-openjdk-jdk8-jfr/ > > Both are automatically updated nightly/weekly. Thanks Aleksey! > Vanilla JMC is not able to connect to those builds yet, unless you hack out the version detection > paths a bit. The JMC binaries linked below contain that hack, and thus are able to connect: > https://bugs.openjdk.java.net/browse/JMC-6554 > https://builds.shipilev.net/jmc/ Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From andrew_m_leonard at uk.ibm.com Tue Aug 20 08:45:34 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Tue, 20 Aug 2019 09:45:34 +0100 Subject: [8u] RFR Backport of 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target In-Reply-To: <16723387-7f3e-bc37-c533-9c63700d897a@oracle.com> References: <16723387-7f3e-bc37-c533-9c63700d897a@oracle.com> Message-ID: Thank you Vincente, i'll request approval.. Cheers Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Vicente Romero To: Andrew Leonard , jdk8u-dev at openjdk.java.net Cc: compiler-dev at openjdk.java.net Date: 19/08/2019 20:00 Subject: Re: [8u] RFR Backport of 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target the backport looks good to me, Vicente On 8/15/19 4:38 AM, Andrew Leonard wrote: > Any offers to review this please? > Thanks > Andrew > > > > > From: Andrew Leonard/UK/IBM > To: jdk8u-dev at openjdk.java.net > Date: 12/08/2019 17:15 > Subject: [8u] RFR Backport of 8067429: java.lang.VerifyError: > Inconsistent stackmap frames at branch target > > > Hi, > Please can I request a review of this updated patch for 8067429 to > backport to jdk8u/langtools. We have seen problem reports from clients > seeing this issue with jdk8 and would like to request a backport please. > The patch is essentially the same as published to jdk9+, but jdk8 the file > paths are in a different location. I have built and tested all "tier1" and > "langtools_all" successfully, and the patch new testcase passes. > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Ealeonard_8067429_webrev.00&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=1jq899yhiTZEKwvfBlQDLl4IJLHPNwrWr9Ee9y-TSek&s=OxsfFEnFwWH4k-vJMXXgjYaUISo-OM0CpI8bn_PRNoY&e= > Once reviewed I will add the jdk8u-fix-request. > > Many thanks > Andrew > > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From andrew_m_leonard at uk.ibm.com Tue Aug 20 09:19:27 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Tue, 20 Aug 2019 10:19:27 +0100 Subject: jdk8u-fix-request's label processing? Message-ID: Hi, i'm following the backport contribution process as a non-committer, https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix and i've labelled my bug jdk8u-fix-request, but no label update to add yes/no... has occurred yet. Is there a periodic review or notification by whoever processes these? or do I need to tell someone? bug in question: https://bugs.openjdk.java.net/browse/JDK-8217896 Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From shade at redhat.com Tue Aug 20 09:55:39 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 20 Aug 2019 11:55:39 +0200 Subject: jdk8u-fix-request's label processing? In-Reply-To: References: Message-ID: <5ffc054b-ecde-bcad-9c1e-803145da30c2@redhat.com> On 8/20/19 11:19 AM, Andrew Leonard wrote: > i'm following the backport contribution process as a non-committer, > https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix > and i've labelled my bug jdk8u-fix-request, but no label update to add > yes/no... has occurred yet. Is there a periodic review or notification by > whoever processes these? or do I need to tell someone? You don't need to tell. Maintainers are periodically scanning the pending approvals queue. It might take a while, especially when maintainers (for 8u it is Andrew Hughes) are all busy at the moment. -- Thanks, -Aleksey From zgu at redhat.com Tue Aug 20 11:13:30 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 20 Aug 2019 07:13:30 -0400 Subject: [8u] 8178870: instrumentation.retransformClasses cause coredump In-Reply-To: References: Message-ID: <08e5b419-e685-2157-3524-b21db6de7c34@redhat.com> Thanks, Serguei -Zhengyu On 8/20/19 12:59 AM, serguei.spitsyn at oracle.com wrote: > Hi Zhengyu, > > The backport looks good to me. > > Thanks, > Serguei > > > On 8/19/19 12:14, Zhengyu Gu wrote: >> >> I would like to backport this patch to 8u, as it is on Oracle 8u >> backport list. >> >> The original patch does not apply cleanly. >> >> 1) Missing get_ik() function in jvmtiRedefineClasses.cpp in 8u code >> base. I imported get_ik() into 8u code base. >> 2) _scratch_classes was declared as Klass** in 8u, but InstanceKlass** >> in 10. Added casting in 8u code. >> 3) Missing test infrastructure in 8u, converted test to shell script. >> >> Original bug: https://bugs.openjdk.java.net/browse/JDK-8178870 >> Original code review: >> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-October/024727.html >> >> >> >> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8178870-8u/webrev.00/ >> >> Thanks, >> >> -Zhengyu >> >> >> > From zgu at redhat.com Tue Aug 20 11:48:25 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 20 Aug 2019 07:48:25 -0400 Subject: [8u] RFR 8219370: NMT: Move synchronization primitives from mtInternal to mtSynchronizer Message-ID: <75fa817d-e003-13b3-146b-ad88e6a23a3e@redhat.com> I would like to backport this patch to 8u. This patch aggregated synchronization primitives under a new memory category, which improves NMT usability. The patch does not apply cleanly, due to: 1) PlatformMonitor is not in 8u code base 2) PlatformEvent and PlatformParker have yet been factored out to Posix for compliant OSs 3) semaphore is defined as StackObj in 8u 4) Memory type declaration is not compatible Original bug: https://bugs.openjdk.java.net/browse/JDK-8219370 original code review: https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2019-February/032684.html 8u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8219370-8u/webrev.00/index.html Thanks, -Zhengyu From stooke at redhat.com Tue Aug 20 13:49:47 2019 From: stooke at redhat.com (Simon Tooke) Date: Tue, 20 Aug 2019 09:49:47 -0400 Subject: [8u] RFR Backport of 8203324: Use out of scope in getMacOSXLocale of java_props_macosx.c:120 Message-ID: Backport request I would like to request a backport of 8203324: (Use out of scope in getMacOSXLocale of java_props_macosx.c:120). This backport would increase buildability with newer toolchains on macOS platforms. The original patch does not import cleanly, because another issue [1] partially addressed the problem.? There are two buffers that have the same use-out-of-scope issue.? My patch addresses both buffers.? I am not suggesting backporting the entire fix for 8160199, as it could involve a change in behaviour to user code. Thank you for your time, -Simon bug: https://bugs.openjdk.java.net/browse/JDK-8203324 original patch: http://hg.openjdk.java.net/jdk/jdk/rev/01e4ddc3c23f modified webrev:? http://cr.openjdk.java.net/~stooke/webrevs/jdk-8203324-jdk8u/webrev.01/webrev.jdk.01/ [1] https://bugs.openjdk.java.net/browse/JDK-8160199 From shade at redhat.com Tue Aug 20 14:23:22 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 20 Aug 2019 16:23:22 +0200 Subject: [8u] 8178870: instrumentation.retransformClasses cause coredump In-Reply-To: References: Message-ID: <6d646175-68e2-b280-6475-cd97f2e5d438@redhat.com> On 8/19/19 9:14 PM, Zhengyu Gu wrote: > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8178870-8u/webrev.00/ Backport looks good. I believe you do not need jtreg annotations in RedefineDoubleDelete.java, as the shell script is the entry point for jtreg. -- Thanks, -Aleksey From shade at redhat.com Tue Aug 20 15:01:50 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 20 Aug 2019 17:01:50 +0200 Subject: [8u] RFR Backport of 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target In-Reply-To: References: Message-ID: <99b62075-2fa3-5079-ce68-d265ea9452b9@redhat.com> On 8/12/19 6:15 PM, Andrew Leonard wrote: > http://cr.openjdk.java.net/~aleonard/8067429/webrev.00 The backport looks good. Although I have reservations about risks of backporting javac bugfixes, when javac from later JDKs are still able to produce the bytecode for previous releases. For this particular bug it probably is not that risky... -- Thanks, -Aleksey From shade at redhat.com Tue Aug 20 15:08:23 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 20 Aug 2019 17:08:23 +0200 Subject: [8u] RFR Backport of 8203324: Use out of scope in getMacOSXLocale of java_props_macosx.c:120 In-Reply-To: References: Message-ID: <6cb8c039-ccc9-8d9c-6c36-43a9d934ddc2@redhat.com> On 8/20/19 3:49 PM, Simon Tooke wrote: > The original patch does not import cleanly, because another issue [1] > partially addressed the problem.? There are two buffers that have the > same use-out-of-scope issue.? My patch addresses both buffers.? I am not > suggesting backporting the entire fix for 8160199, as it could involve a > change in behaviour to user code. True, that makes sense. > modified webrev:? > http://cr.openjdk.java.net/~stooke/webrevs/jdk-8203324-jdk8u/webrev.01/webrev.jdk.01/ Backport looks good to me. -- Thanks, -Aleksey From shade at redhat.com Tue Aug 20 15:10:50 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 20 Aug 2019 17:10:50 +0200 Subject: [8u] RFR 8219370: NMT: Move synchronization primitives from mtInternal to mtSynchronizer In-Reply-To: <75fa817d-e003-13b3-146b-ad88e6a23a3e@redhat.com> References: <75fa817d-e003-13b3-146b-ad88e6a23a3e@redhat.com> Message-ID: <8837e932-22f8-fc56-7c27-2e780e7be0af@redhat.com> On 8/20/19 1:48 PM, Zhengyu Gu wrote: > 8u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8219370-8u/webrev.00/index.html Backport looks fine to me. -- Thanks, -Aleksey From zgu at redhat.com Tue Aug 20 15:44:20 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 20 Aug 2019 11:44:20 -0400 Subject: [8u] 8178870: instrumentation.retransformClasses cause coredump In-Reply-To: <6d646175-68e2-b280-6475-cd97f2e5d438@redhat.com> References: <6d646175-68e2-b280-6475-cd97f2e5d438@redhat.com> Message-ID: <7003c233-d891-b11b-3426-f9b6f7de2d8f@redhat.com> Hi Aleksey, Thanks for reviewing. On 8/20/19 10:23 AM, Aleksey Shipilev wrote: > On 8/19/19 9:14 PM, Zhengyu Gu wrote: >> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8178870-8u/webrev.00/ > > Backport looks good. > > I believe you do not need jtreg annotations in RedefineDoubleDelete.java, as the shell script is the > entry point for jtreg. Right, I will remove that before push. -Zhengyu > From shade at redhat.com Tue Aug 20 15:57:41 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 20 Aug 2019 17:57:41 +0200 Subject: [8u] 8178870: instrumentation.retransformClasses cause coredump In-Reply-To: <7003c233-d891-b11b-3426-f9b6f7de2d8f@redhat.com> References: <6d646175-68e2-b280-6475-cd97f2e5d438@redhat.com> <7003c233-d891-b11b-3426-f9b6f7de2d8f@redhat.com> Message-ID: <0bfedafb-f31c-6278-31da-56cb4abc1d34@redhat.com> On 8/20/19 5:44 PM, Zhengyu Gu wrote: > On 8/20/19 10:23 AM, Aleksey Shipilev wrote: >> On 8/19/19 9:14 PM, Zhengyu Gu wrote: >>> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8178870-8u/webrev.00/ >> >> Backport looks good. I just noticed your other backport has the new definition of get_ik here: http://cr.openjdk.java.net/~zgu/JDK-8155951-8u/webrev.00/src/share/vm/prims/jvmtiRedefineClasses.cpp.sdiff.html Maybe you want to commit them in more convenient order to get the definition in for this backport. -- Thanks, -Aleksey From shade at redhat.com Tue Aug 20 16:10:13 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 20 Aug 2019 18:10:13 +0200 Subject: [8u] RFR 8155951 & 8151066 In-Reply-To: References: Message-ID: <9df3b24b-23d7-ece3-649d-ba7309e8440e@redhat.com> On 8/13/19 8:13 PM, Zhengyu Gu wrote: > The patch does not apply cleanly. Other than a few minor conflicts, e.g. copyright years, breaking > single line long parameter list to multi-lines and line shifts, jdk8u lock declaration? (def macro > in mutexLocker.cpp) does not take 5th argument. So, now that we acquire the lock with MutexLocker, it always checks for safepoint? Wanted to understand what makes dropping the 5th argument safe. > 8u backport: http://cr.openjdk.java.net/~zgu/JDK-8155951-8u/webrev.00/index.html Otherwise backport looks good to me. -- Thanks, -Aleksey From rkennke at redhat.com Tue Aug 20 16:37:30 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 20 Aug 2019 18:37:30 +0200 Subject: RFR: 8213325: (props) Properties.loadFromXML does not fully comply with the spec In-Reply-To: <1d0a8a5d-3467-99ed-3dff-187b70ea95fa@redhat.com> References: <1d0a8a5d-3467-99ed-3dff-187b70ea95fa@redhat.com> Message-ID: I added one extra verification to the JAXP based properties parser to verify that no extra internal DTD is being supplied. As far as I can tell, the other checks that have been added to the ukit parser for this bug are already done by the JAXP parser, by validating the XML against the built-in DTD. Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8213325/webrev.01/ This passes all relevant tests, and I also run tier1 w/o regressions. What do you think? Roman > This is a backport of: > > https://bugs.openjdk.java.net/browse/JDK-8227274 > > which is a backport of the original: > > https://bugs.openjdk.java.net/browse/JDK-8213325 > > It's mostly the original change with a few significant extra modifications: > > - > src/share/classes/sun/util/xml/META-INF/services/sun.util.spi.XmlPropertiesProvider > > is changed from: > sun.util.xml.PlatformXmlPropertiesProvider > > to: > jdk.internal.util.xml.BasicXmlPropertiesProvider > > The reason is that the fix is for the latter, but 8u uses the former by > default. As far as I understand, the latter uses the new slimmer parser, > while the former uses the fullblown XML parser, but I am not sure about > that. However, we need to consider this, because it might be a very > significant change. > > The alternative would be to port over the fixes to the other XML parser, > which I have no desire to do. > > - The (test) JAR file: > test/java/util/spi/ResourceBundleControlProvider/rbcontrolprovider.jar > > has been regenerated from the modified sources XmlRB.xml and XmlRB_ja.xml. > > This is not present in jdk11 and later. I think it's generated on the > fly and not checked-in. > > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8213325/webrev.00/ > > Testing: New testcases are passing. No regressions in tier1 tests. > > Opinions? Can I get reviews? > > Thanks, > Roman > From zgu at redhat.com Tue Aug 20 16:43:58 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 20 Aug 2019 12:43:58 -0400 Subject: [8u] RFR 8155951 & 8151066 In-Reply-To: <9df3b24b-23d7-ece3-649d-ba7309e8440e@redhat.com> References: <9df3b24b-23d7-ece3-649d-ba7309e8440e@redhat.com> Message-ID: <8414c4a6-01cb-8b4d-ae07-0000ac9c9fd0@redhat.com> Hi Aleksey, On 8/20/19 12:10 PM, Aleksey Shipilev wrote: > On 8/13/19 8:13 PM, Zhengyu Gu wrote: >> The patch does not apply cleanly. Other than a few minor conflicts, e.g. copyright years, breaking >> single line long parameter list to multi-lines and line shifts, jdk8u lock declaration? (def macro >> in mutexLocker.cpp) does not take 5th argument. > > So, now that we acquire the lock with MutexLocker, it always checks for safepoint? Wanted to > understand what makes dropping the 5th argument safe. The 5th parameter is Monitor::_safepoint_check_always, so I think it is safe to drop it. Thanks, -Zhengyu > >> 8u backport: http://cr.openjdk.java.net/~zgu/JDK-8155951-8u/webrev.00/index.html > > Otherwise backport looks good to me. > From shade at redhat.com Tue Aug 20 16:55:45 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 20 Aug 2019 18:55:45 +0200 Subject: [8u] RFR 8155951 & 8151066 In-Reply-To: <8414c4a6-01cb-8b4d-ae07-0000ac9c9fd0@redhat.com> References: <9df3b24b-23d7-ece3-649d-ba7309e8440e@redhat.com> <8414c4a6-01cb-8b4d-ae07-0000ac9c9fd0@redhat.com> Message-ID: On 8/20/19 6:43 PM, Zhengyu Gu wrote: > Hi Aleksey, > > On 8/20/19 12:10 PM, Aleksey Shipilev wrote: >> On 8/13/19 8:13 PM, Zhengyu Gu wrote: >>> The patch does not apply cleanly. Other than a few minor conflicts, e.g. copyright years, breaking >>> single line long parameter list to multi-lines and line shifts, jdk8u lock declaration? (def macro >>> in mutexLocker.cpp) does not take 5th argument. >> >> So, now that we acquire the lock with MutexLocker, it always checks for safepoint? Wanted to >> understand what makes dropping the 5th argument safe. > > The 5th parameter is Monitor::_safepoint_check_always, so I think it is safe to drop it. Okay then. -- Thanks, -Aleksey From mbalao at redhat.com Tue Aug 20 20:21:19 2019 From: mbalao at redhat.com (Martin Balao) Date: Tue, 20 Aug 2019 17:21:19 -0300 Subject: CSR process for OpenJDK 11 and 8 Updates In-Reply-To: References: Message-ID: <7f388c01-ddb7-0a74-2217-d5a4d990ae8c@redhat.com> Hi all, In my personal view, a new CSR process for each backport where the original enhancement/bug has a CSR will add unnecessary overhead. Particularly when there are no release-specific modifications. I.e.: backporting a change that introduces exactly the same system property to a previous release. The maintainer has control over what goes in, and can take the existing CSR documentation as an input to make a decision on the approval request. I suggest that we only start a new CSR process when there are release-specific changes introduced. That can be informed as part of the "Fix Request" comment. Thoughts? Thanks, Martin.- From rkennke at redhat.com Tue Aug 20 21:23:55 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 20 Aug 2019 23:23:55 +0200 Subject: RFR: Backport JDK-8215265: C2: range check elimination may allow illegal out of bound access Message-ID: This is a backport of the original jdk12 fix: https://bugs.openjdk.java.net/browse/JDK-8215265 Which has been backported to 11 already: http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/2815d9d11969 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8215265/webrev.00/ The only differs is relatively minor details: paths adjusted, new AddINode() -> new (C) AddINode(). Testing: new testcase fails without fix, passes with fix. No tier1 regressions. Can I please get a review? Thanks, Roman From rkennke at redhat.com Tue Aug 20 22:28:19 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 21 Aug 2019 00:28:19 +0200 Subject: RFR: Backport JDK-8217359: C2 compiler triggers SIGSEGV after transformation in ConvI2LNode::Ideal Message-ID: This backports to 8u: https://bugs.openjdk.java.net/browse/JDK-8217359 The fix applies after fixing paths and putting the patch into the right place in connode.cpp instead of convertnode.cpp. Testing: passes new testcase (fails without fix), passes tier1, tier2 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8217359/webrev.00/ Can I please get a review? Roman From adinn at redhat.com Wed Aug 21 07:48:52 2019 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 21 Aug 2019 08:48:52 +0100 Subject: RFR: Backport JDK-8215265: C2: range check elimination may allow illegal out of bound access In-Reply-To: References: Message-ID: <080f6013-2cb3-7f64-03d8-821d63264008@redhat.com> On 20/08/2019 22:23, Roman Kennke wrote: > This is a backport of the original jdk12 fix: > > https://bugs.openjdk.java.net/browse/JDK-8215265 > > Which has been backported to 11 already: > http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/2815d9d11969 > > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8215265/webrev.00/ > > The only differs is relatively minor details: paths adjusted, new > AddINode() -> new (C) AddINode(). > > Testing: new testcase fails without fix, passes with fix. No tier1 > regressions. > > Can I please get a review? Looks good. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Wed Aug 21 07:53:13 2019 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 21 Aug 2019 08:53:13 +0100 Subject: RFR: Backport JDK-8217359: C2 compiler triggers SIGSEGV after transformation in ConvI2LNode::Ideal In-Reply-To: References: Message-ID: On 20/08/2019 23:28, Roman Kennke wrote: > This backports to 8u: > > https://bugs.openjdk.java.net/browse/JDK-8217359 > > The fix applies after fixing paths and putting the patch into the right > place in connode.cpp instead of convertnode.cpp. > > Testing: passes new testcase (fails without fix), passes tier1, tier2 > > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8217359/webrev.00/ > > Can I please get a review? Looks good. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From aph at redhat.com Wed Aug 21 08:20:26 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 21 Aug 2019 09:20:26 +0100 Subject: CSR process for OpenJDK 11 and 8 Updates In-Reply-To: <7f388c01-ddb7-0a74-2217-d5a4d990ae8c@redhat.com> References: <7f388c01-ddb7-0a74-2217-d5a4d990ae8c@redhat.com> Message-ID: <796e24d9-1445-c6f5-8f4c-8d65f3bfc605@redhat.com> On 8/20/19 9:21 PM, Martin Balao wrote: > In my personal view, a new CSR process for each backport where the > original enhancement/bug has a CSR will add unnecessary overhead. > Particularly when there are no release-specific modifications. I.e.: > backporting a change that introduces exactly the same system > property to a previous release. The maintainer has control over what > goes in, and can take the existing CSR documentation as an input to > make a decision on the approval request. Sure. > I suggest that we only start a new CSR process when there are > release-specific changes introduced. That can be informed as part of > the "Fix Request" comment. It depends on what the change does. It is not particularly unlikely that a change which was appropriate for head might break jdk 11. In that case a CSR is necessary. The CSR process is for us to use, not a nuisance. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Wed Aug 21 13:18:12 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 21 Aug 2019 14:18:12 +0100 Subject: [8u] RFR (S) 8223177: Data race on JvmtiEnvBase::_tag_map in double-checked locking In-Reply-To: <798ff717-a966-2ca2-9f9d-56f8019f78a9@redhat.com> References: <798ff717-a966-2ca2-9f9d-56f8019f78a9@redhat.com> Message-ID: <70a82191-32f0-4452-b53a-55c42726d44c@redhat.com> On 07/08/2019 11:53, Aleksey Shipilev wrote: > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8223177 > https://hg.openjdk.java.net/jdk/jdk/rev/27c8a2e0b0e5 > > This patch applies to 8u, but does not compile, because regular OrderAccess methods do not accept > pointers. We need to use the *_ptr_* versions of the same methods and do casts from void*. > > 8u webrev: > http://cr.openjdk.java.net/~shade/8223177/webrev.8u.01/ > > Testing: tier1 > Looks good to me. The OrderAccess method change is necessary because 8u lacks JDK-8188813: https://bugs.openjdk.java.net/browse/JDK-8188813 https://hg.openjdk.java.net/jdk10/master/rev/a1f68e415b48 You're missing "that full template experience" ;-) Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Wed Aug 21 13:42:21 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 21 Aug 2019 15:42:21 +0200 Subject: RFR: Backport JDK-8215265: C2: range check elimination may allow illegal out of bound access In-Reply-To: References: Message-ID: <515bb36b-1996-8a8f-5e9d-3e3f68efa8fc@redhat.com> On 8/20/19 11:23 PM, Roman Kennke wrote: > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8215265/webrev.00/ Backport looks good. -- Thanks, -Aleksey From shade at redhat.com Wed Aug 21 13:44:13 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 21 Aug 2019 15:44:13 +0200 Subject: RFR: Backport JDK-8217359: C2 compiler triggers SIGSEGV after transformation in ConvI2LNode::Ideal In-Reply-To: References: Message-ID: On 8/21/19 12:28 AM, Roman Kennke wrote: > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8217359/webrev.00/ Backport looks good. -- Thanks, -Aleksey From gnu.andrew at redhat.com Wed Aug 21 15:58:00 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 21 Aug 2019 16:58:00 +0100 Subject: [8u] RFR 8229501: jdk/test/lib/testlibrary/ClassFileInstaller.java should match hotspot//test/testlibrary version In-Reply-To: <0E64BD39-BFDA-4506-BD8B-7B63A7BBD0C8@amazon.com> References: <0E64BD39-BFDA-4506-BD8B-7B63A7BBD0C8@amazon.com> Message-ID: <01cc5f7a-01ed-d712-883e-0cec87c09e8b@redhat.com> On 13/08/2019 23:12, Verghese, Clive wrote: > Hi, > > Requesting review for webrev : http://cr.openjdk.java.net/~phh/8229501/webrev.8u.00/ > JBS Issue : https://bugs.openjdk.java.net/browse/JDK-8229501 > Email discussion : https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010029.html > > hotspot/test/testlibrary/ClassFileInstaller.java and jdk/test/lib/testlibrary/ClassFileInstaller were merged as part of the JDK10 repo merge. For 8u, we should sync the JDK version with the Hotspot version in order to facilitate backports of patches such as the one for JDK-8216401 that assume the merged version. > > Testing > Validated that the test depending on ClassFileInstaller pass. > > > Regards, > Clive Verghese > This appears to just be the result of: $ diff -u hotspot/test/testlibrary/ClassFileInstaller.java jdk/test/lib/testlibrary/ClassFileInstaller.java I don't think a code dump with a unique bug ID is the correct way to fix this. The actual changes come from two HotSpot changes: changeset: 8710:4141ef4c8ba8 user: vaibhav date: Thu Jul 26 06:16:09 2018 -0400 summary: 8189762: [TESTBUG] Create tests for JDK-8146115 container awareness and resource configuration changeset: 4665:43083e670adf user: coleenp date: Mon May 13 15:37:08 2013 -0400 summary: 8005056: NPG: Crash after redefining java.lang.Object The appropriate course of action here is to apply the test/testlibrary/ClassFileInstaller.java changes from these changesets to the copy under test/lib/testlibrary/ClassFileInstaller.java under their appropriate bug IDs, as should have been done to begin with and, I presume, is intended for future changes to keep these in sync. This then associates the changes with their original review and motivation. I just tried this with 8189762 and it applies cleanly, leaving just the changes in 8005056 as the diff. I'd prefer they were separate changesets, but the current webrev could be used with these two bug IDs rather than 8229501. -- 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 Aug 21 16:07:51 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 21 Aug 2019 17:07:51 +0100 Subject: How to import patch from jdk/jdk In-Reply-To: References: Message-ID: <5d12f77e-a674-f989-39f0-e8fa57b6a0b0@redhat.com> On 12/08/2019 09:05, Severin Gehwolf wrote: > Hi, > > On Sat, 2019-08-10 at 16:58 +0200, Laurent Bourg?s wrote: >> Ok, >> I will use sed on the patch file to fix paths, then I will import it. I >> thought such sed script already exist or mercurial or linux patch command >> already manage that. > > You could try common/bin/unshuffle_patch.sh from JDK 9[1]. > > Thanks, > Severin > > [1] http://hg.openjdk.java.net/jdk-updates/jdk9u/file/1b1226687b89/common/bin/unshuffle_patch.sh > If the patch was committed to jdk/jdk or jdk-updates/jdk11 (as opposed to being an older jdk9 patch), it usually needs both the jdk11 script [0] (to move the files back into their subrepos, jdk11->jdk9) and the jdk9 script [1] (to get rid of the modules, jdk9->jdk8). Both scripts need data files from the same directory, so checking out the repos is probably the easiest option. All this file movement is a major PITA. [0] https://hg.openjdk.java.net/jdk-updates/jdk11u/file/tip/bin/unshuffle_patch.sh [1] https://hg.openjdk.java.net/jdk-updates/jdk9u/file/tip/common/bin/unshuffle_patch.sh -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From rkennke at redhat.com Wed Aug 21 16:12:47 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 21 Aug 2019 18:12:47 +0200 Subject: How to import patch from jdk/jdk In-Reply-To: <5d12f77e-a674-f989-39f0-e8fa57b6a0b0@redhat.com> References: <5d12f77e-a674-f989-39f0-e8fa57b6a0b0@redhat.com> Message-ID: <6bb2170e-0390-20c5-30c4-69b0085a9924@redhat.com> > On 12/08/2019 09:05, Severin Gehwolf wrote: >> Hi, >> >> On Sat, 2019-08-10 at 16:58 +0200, Laurent Bourg?s wrote: >>> Ok, >>> I will use sed on the patch file to fix paths, then I will import it. I >>> thought such sed script already exist or mercurial or linux patch command >>> already manage that. >> >> You could try common/bin/unshuffle_patch.sh from JDK 9[1]. >> >> Thanks, >> Severin >> >> [1] http://hg.openjdk.java.net/jdk-updates/jdk9u/file/1b1226687b89/common/bin/unshuffle_patch.sh >> > > If the patch was committed to jdk/jdk or jdk-updates/jdk11 (as opposed > to being an older jdk9 patch), it usually needs both the jdk11 script > [0] (to move the files back into their subrepos, jdk11->jdk9) and the > jdk9 script [1] (to get rid of the modules, jdk9->jdk8). Both scripts > need data files from the same directory, so checking out the repos is > probably the easiest option. > > All this file movement is a major PITA. > > [0] > https://hg.openjdk.java.net/jdk-updates/jdk11u/file/tip/bin/unshuffle_patch.sh > [1] > https://hg.openjdk.java.net/jdk-updates/jdk9u/file/tip/common/bin/unshuffle_patch.sh > It looks like it should be possible to use this in conjunction with hg transplant --filter to transplant patches between versions. https://www.mercurial-scm.org/wiki/TransplantExtension Roman From gnu.andrew at redhat.com Wed Aug 21 16:17:03 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 21 Aug 2019 17:17:03 +0100 Subject: jdk8u-fix-request's label processing? In-Reply-To: <5ffc054b-ecde-bcad-9c1e-803145da30c2@redhat.com> References: <5ffc054b-ecde-bcad-9c1e-803145da30c2@redhat.com> Message-ID: <8ce598b7-07e7-750f-8b96-167c0947947e@redhat.com> On 20/08/2019 10:55, Aleksey Shipilev wrote: > On 8/20/19 11:19 AM, Andrew Leonard wrote: >> i'm following the backport contribution process as a non-committer, >> https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix >> and i've labelled my bug jdk8u-fix-request, but no label update to add >> yes/no... has occurred yet. Is there a periodic review or notification by >> whoever processes these? or do I need to tell someone? > > You don't need to tell. Maintainers are periodically scanning the pending approvals queue. It might > take a while, especially when maintainers (for 8u it is Andrew Hughes) are all busy at the moment. > I'm working through them now. It's worth reminding people of: https://openjdk.java.net/projects/jdk-updates/approval.html specifically, rule 1 which states that fix requests should have a comment describing the motivation for the request and pointing to the review thread. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Wed Aug 21 17:16:12 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 21 Aug 2019 19:16:12 +0200 Subject: [8u] java/util/{Calendar, TimeZone} test failures Message-ID: <0d7280cc-4cf7-499d-2583-1a124ae0204e@redhat.com> Hi, I am running tier1 in jdk8u-dev, and these tests fail: FAILED: java/util/Calendar/CalendarRegression.java FAILED: java/util/Calendar/JapanEraNameCompatTest.java FAILED: java/util/TimeZone/HongKong.java They seem to fail since 8u222. There seems to be a gap in locale data somewhere? Is anyone looking into that? -- Thanks, -Aleksey From jvanek at redhat.com Wed Aug 21 17:32:51 2019 From: jvanek at redhat.com (Jiri Vanek) Date: Wed, 21 Aug 2019 19:32:51 +0200 Subject: [8u] RFR Backport JDK-8154313, Generated javadoc scattered all over the place Message-ID: Hello! http://cr.openjdk.java.net/~jvanek/8154313/ (https://bugs.openjdk.java.net/browse/JDK-8154313) This is patch which was pushed (in slightly different form) to jdk9, and then was changing through every jdk until its form in jdk11 ad up. This is backport of the jdk11 and up shape in jdk8 way: jdk11: sh configure && make docs-zip silently leads to: ./linux-x86_64-normal-server-release/bundles/jdk-11.0.5-internal+0-adhoc.jvanek.jdk11u-docs.zip jdk8: sh configure && make docs-zip leave single trace which leads to: build/linux-x86_64-normal-server-release/bundles/jdk-1.8.0-internal-jvanek_2019_08_21_18_10-b00-docs.zip The patch is in jdk8 rpms for long time, and I have seen adapted it by other distros since jdk9 made it visible. Is it possible to backport it please? Thanx J. -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek at redhat.com M: +420775390109 From shade at redhat.com Wed Aug 21 18:29:46 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 21 Aug 2019 20:29:46 +0200 Subject: [8u] RFR 8214687: Optimize Collections.nCopies().hashCode() and equals() In-Reply-To: References: <43caafb3-239a-0829-9665-71dcae9bea01@redhat.com> <1d7e6380-912e-126b-e09f-4a77e22af240@redhat.com> <41ee101b-ec08-5e17-a9cc-5fe4e646f9da@redhat.com> <54ca6359-d827-aa9c-7d17-c480989675a0@redhat.com> Message-ID: <9b4819ef-6380-12e2-be6a-d1bb9e71514c@redhat.com> On 8/7/19 5:17 PM, Aleksey Shipilev wrote: > On 7/31/19 6:08 PM, Aleksey Shipilev wrote: >> On 7/31/19 5:56 PM, Andrew John Hughes wrote: >>> On 31/07/2019 10:02, Aleksey Shipilev wrote: >>>> On 7/16/19 9:25 AM, Andrew John Hughes wrote: >>>>> On 15/07/2019 09:27, Aleksey Shipilev wrote: >>>> Getting back to this. Since we have moved Preconditions to private location in 8u, using it is >>>> impossible for this patch. So, I would keep the webrev as is: >>>> https://cr.openjdk.java.net/~shade/8214687/webrev.8u.01 >>> >>> We haven't moved anything as yet and my proposed patch leaves the class >>> as public, so shouldn't be a blocker. The test in that patch uses >>> Preconditions. >> >> Original patch needs Objects.checkIndex: >> https://hg.openjdk.java.net/jdk/jdk/rev/cfceb4df2499#l2.32 >> >> What you are suggesting is changing that line to Preconditions (with new method!). What webrev >> suggests is replacing it with the one-liner: >> >> 91 check(0 <= index && index < n, "Index is incorrect"); >> >> Given that we are changing the code anyway, I don't see why do we need to introduce another >> dependency to the about-to-be-moved class, do more code that diverges 8u from later releases, >> instead of doing the trivial one-liner. > > Thoughts? Friendly reminder. -- Thanks, -Aleksey From gnu.andrew at redhat.com Wed Aug 21 19:33:32 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 21 Aug 2019 20:33:32 +0100 Subject: RFR: [8u] 8141570: Fix Zero interpreter build for --disable-precompiled-headers Message-ID: This is the first of a series of four changes to support -Wreturn-type in OpenJDK 8u. The -Wreturn-type warning catches instances where control flow exits a non-void function without returning a value. This can combine with compiler optimisations in some cases to cause runtime crashes. The warning is turned on by default in GCC 8 [0], causing the build to fail if it is not explicitly disabled. The subsequent changes are JDK-8062808 to apply the warning and fix issues in the default build, JDK-8143245 to fix issues in the Zero build and JDK-8197981 to fix one remaining Zero issue on 32-bit platforms only. This change ensures the Zero build is not broken by 8062808 by disabling -Wreturn-type in the Zero makefile. Changes in the backport process: * The G1 changes are dropped as 8u does not contain JDK-8073013, which introduces g1EvacStats.* * I've changed the ifeq ($(USE_CLANG), true) to ifeq ($(JVM_VARIANT_ZEROSHARK), true). There seems to have been a mistake in the original patch which equated LLVM with clang. What is actually referred to by "some version of llvm do not like -Wundef" is the LLVM headers that Shark is built against, not the clang compiler which also uses LLVM. This made its way through to the new HotSpot build in OpenJDK 9 & 10, but is gone as of JDK-8198724 in OpenJDK 11 and later. This backport has been in IcedTea since 3.8.0 (2018-05-29) [1] and our RHEL RPMs since 2018-06-16 without issue. Builds of current 8u-dev on x86_64 with Zero release and Zero slowdebug succeeded. [0] https://gcc.gnu.org/gcc-8/changes.html [1] https://icedtea.classpath.org/bugzilla/show_bug.cgi?id=3548 -- 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 Aug 21 20:49:36 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 21 Aug 2019 21:49:36 +0100 Subject: [8u] RFR 8219370: NMT: Move synchronization primitives from mtInternal to mtSynchronizer In-Reply-To: <75fa817d-e003-13b3-146b-ad88e6a23a3e@redhat.com> References: <75fa817d-e003-13b3-146b-ad88e6a23a3e@redhat.com> Message-ID: <8429ad89-843a-c0e7-e000-7ca192610dd3@redhat.com> On 20/08/2019 12:48, Zhengyu Gu wrote: > I would like to backport this patch to 8u. > > This patch aggregated synchronization primitives under a new memory > category, which improves NMT usability. > > The patch does not apply cleanly, due to: > 1) PlatformMonitor is not in 8u code base > 2) PlatformEvent and PlatformParker have yet been factored out to Posix > for compliant OSs > 3) semaphore is defined as StackObj in 8u > 4) Memory type declaration is not compatible > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8219370 > original code review: > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2019-February/032684.html > > > > 8u Webrev: > http://cr.openjdk.java.net/~zgu/JDK-8219370-8u/webrev.00/index.html > > Thanks, > > -Zhengyu Patch mostly looks good. With regard to the memory type declaration, I would if it would be simpler to just make a similar change as JDK-8208499 [0] (which I see you already backported to 11u) as part of this and cleanup that enum, removing the explicit values? The changes to allocation.hpp and memTracker.cpp look pretty independent of the rest and could be incorporated into this backport. JDK-8174231 [1] may also be worth a backport long term, to factor out the common POSIX PlatformEvent code. [0] https://hg.openjdk.java.net/jdk/jdk/rev/cf34c71ca27c [1] https://bugs.openjdk.java.net/browse/JDK-8174231 -- 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 amaembo at gmail.com Thu Aug 22 04:34:49 2019 From: amaembo at gmail.com (Tagir Valeev) Date: Thu, 22 Aug 2019 11:34:49 +0700 Subject: [8u] RFR 8214687: Optimize Collections.nCopies().hashCode() and equals() In-Reply-To: References: <43caafb3-239a-0829-9665-71dcae9bea01@redhat.com> <1d7e6380-912e-126b-e09f-4a77e22af240@redhat.com> <41ee101b-ec08-5e17-a9cc-5fe4e646f9da@redhat.com> <54ca6359-d827-aa9c-7d17-c480989675a0@redhat.com> Message-ID: To me, this change looks perfectly ok. I agree with Aleksey that adding a dependency to Preconditions would be a worse solution. Yes, the proposed solution violates the List::get contract, in particular, because AssertionError is thrown instead of IndexOutOfBoundsException. However, it's a test-case code and this check normally never fails. It can fail due to a bug, and I find it quite ok if the test-case fails with an AssertionError as a reaction to the bug. In any case, I don't think that we should spend too much time polishing this particular line. With best regards, Tagir Valeev. On Wed, Aug 7, 2019 at 10:17 PM Aleksey Shipilev wrote: > On 7/31/19 6:08 PM, Aleksey Shipilev wrote: > > On 7/31/19 5:56 PM, Andrew John Hughes wrote: > >> On 31/07/2019 10:02, Aleksey Shipilev wrote: > >>> On 7/16/19 9:25 AM, Andrew John Hughes wrote: > >>>> On 15/07/2019 09:27, Aleksey Shipilev wrote: > >>> Getting back to this. Since we have moved Preconditions to private > location in 8u, using it is > >>> impossible for this patch. So, I would keep the webrev as is: > >>> https://cr.openjdk.java.net/~shade/8214687/webrev.8u.01 > >> > >> We haven't moved anything as yet and my proposed patch leaves the class > >> as public, so shouldn't be a blocker. The test in that patch uses > >> Preconditions. > > > > Original patch needs Objects.checkIndex: > > https://hg.openjdk.java.net/jdk/jdk/rev/cfceb4df2499#l2.32 > > > > What you are suggesting is changing that line to Preconditions (with new > method!). What webrev > > suggests is replacing it with the one-liner: > > > > 91 check(0 <= index && index < n, "Index is incorrect"); > > > > Given that we are changing the code anyway, I don't see why do we need > to introduce another > > dependency to the about-to-be-moved class, do more code that diverges 8u > from later releases, > > instead of doing the trivial one-liner. > > Thoughts? > > -- > Thanks, > -Aleksey > > From sgehwolf at redhat.com Thu Aug 22 08:47:34 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 22 Aug 2019 10:47:34 +0200 Subject: [8u] RFR Backport JDK-8154313, Generated javadoc scattered all over the place In-Reply-To: References: Message-ID: <26c825e0e54df08018dff414850ae7d418818433.camel@redhat.com> Hi Jiri, On Wed, 2019-08-21 at 19:32 +0200, Jiri Vanek wrote: > Hello! > > http://cr.openjdk.java.net/~jvanek/8154313/ (https://bugs.openjdk.java.net/browse/JDK-8154313) > > This is patch which was pushed (in slightly different form) to jdk9, and then was changing through > every jdk until its form in jdk11 ad up. Next time, please mention the modifications you had to make and why. Makes a reviewer's life easier :) make/Javadoc.gmk ---------------- FULL_VERSION changed to VERSION_STRING in JDK 9+, hence the change in JAVADOC_ARCHIVE_NAME. Ok. 222 PLATFORM_DOCSDIR = $(DOCSDIR)/platform 223 224 225 JAVADOC_ARCHIVE_NAME := jdk-$(FULL_VERSION)-docs.zip 226 JAVADOC_ARCHIVE_ASSEMBLY_DIR := $(DOCSTMPDIR)/zip-docs 227 JAVADOC_ARCHIVE_DIR := $(OUTPUT_ROOT)/bundles 228 JAVADOC_ARCHIVE := $(JAVADOC_ARCHIVE_DIR)/$(JAVADOC_ARCHIVE_NAME) Please remove the extra empty line on line 224. 352 # 353 354 $(JAVADOC_ARCHIVE): $(COREAPI_INDEX_FILE) 355 @$(ECHO) "Compressing javadoc to single $(JAVADOC_ARCHIVE_NAME)" ; Shouldn't this be something like this? The JDK 9 patch logs this to log info: http://hg.openjdk.java.net/jdk9/jdk9/rev/ec69c5bf68a6#l1.41 @$(ECHO) $(LOG_INFO) "Compressing javadoc to single $(JAVADOC_ARCHIVE_NAME)" 356 $(MKDIR) -p $(JAVADOC_ARCHIVE_DIR) ; 357 $(RM) -r $(JAVADOC_ARCHIVE_ASSEMBLY_DIR) ; 358 $(MKDIR) -p $(JAVADOC_ARCHIVE_ASSEMBLY_DIR); 359 all_roots=`$(FIND) $(DOCSDIR) | $(GREP) index.html `; \ Why is "grep -v old/doclet" missing from the JDK 8 patch? http://hg.openjdk.java.net/jdk9/jdk9/rev/ec69c5bf68a6#l1.45 Are extra semicolons on lines 355-358 needed? It makes the patch diverge from the JDK 9 version for no good reason... 360 pushd $(JAVADOC_ARCHIVE_ASSEMBLY_DIR); \ 361 for index_file in $${all_roots} ; do \ 362 target_dir=`dirname $${index_file}`; \ 363 name=`$(ECHO) $${target_dir} | $(SED) "s;/spec;;" | $(SED) "s;.*/;;"`; \ 364 $(LN) -s $${target_dir} $${name}; \ 365 done; \ 366 $(ZIP) -q -r $(JAVADOC_ARCHIVE) * ; \ 367 popd ; 368 Adding new "zip-docs" target is missing from .PHONY in this patch. Please add it. http://hg.openjdk.java.net/jdk9/jdk9/rev/ec69c5bf68a6#l1.58 make/Main.gmk ------------- No comments. Does "make clean-docs" work as expected? It appears it'll leave bundles/jdk-*-docs.zip behind. Perhaps add a condition for "docs" component in CleanComponent here? http://hg.openjdk.java.net/jdk8u/jdk8u-dev/file/cd2e5f820a0d/make/MakeHelpers.gmk#l299 Then it would work similar to what the JDK 9 patch did with: http://hg.openjdk.java.net/jdk9/jdk9/rev/ec69c5bf68a6#l3.7 Thanks, Severin From sgehwolf at redhat.com Thu Aug 22 08:52:38 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 22 Aug 2019 10:52:38 +0200 Subject: RFR: [8u] 8141570: Fix Zero interpreter build for --disable-precompiled-headers In-Reply-To: References: Message-ID: <5935ba25ce64cfc747e9717ca1a742d7f35c0ec7.camel@redhat.com> Hi Andrew, On Wed, 2019-08-21 at 20:33 +0100, Andrew John Hughes wrote: > This is the first of a series of four changes to support -Wreturn-type > in OpenJDK 8u. The -Wreturn-type warning catches instances where control > flow exits a non-void function without returning a value. This can > combine with compiler optimisations in some cases to cause runtime > crashes. The warning is turned on by default in GCC 8 [0], causing the > build to fail if it is not explicitly disabled. > > The subsequent changes are JDK-8062808 to apply the warning and fix > issues in the default build, JDK-8143245 to fix issues in the Zero build > and JDK-8197981 to fix one remaining Zero issue on 32-bit platforms only. > > This change ensures the Zero build is not broken by 8062808 by disabling > -Wreturn-type in the Zero makefile. > > Changes in the backport process: > > * The G1 changes are dropped as 8u does not contain JDK-8073013, which > introduces g1EvacStats.* > * I've changed the ifeq ($(USE_CLANG), true) to ifeq > ($(JVM_VARIANT_ZEROSHARK), true). There seems to have been a mistake in > the original patch which equated LLVM with clang. What is actually > referred to by "some version of llvm do not like -Wundef" is the LLVM > headers that Shark is built against, not the clang compiler which also > uses LLVM. This made its way through to the new HotSpot build in OpenJDK > 9 & 10, but is gone as of JDK-8198724 in OpenJDK 11 and later. > > This backport has been in IcedTea since 3.8.0 (2018-05-29) [1] and our > RHEL RPMs since 2018-06-16 without issue. Builds of current 8u-dev on > x86_64 with Zero release and Zero slowdebug succeeded. > > [0] https://gcc.gnu.org/gcc-8/changes.html > [1] https://icedtea.classpath.org/bugzilla/show_bug.cgi?id=3548 I don't see any webrev. Did you forget to link to it? Thanks, Severin From gnu.andrew at redhat.com Thu Aug 22 09:12:51 2019 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 22 Aug 2019 10:12:51 +0100 Subject: [8u] RFR 8214687: Optimize Collections.nCopies().hashCode() and equals() In-Reply-To: <54ca6359-d827-aa9c-7d17-c480989675a0@redhat.com> References: <43caafb3-239a-0829-9665-71dcae9bea01@redhat.com> <1d7e6380-912e-126b-e09f-4a77e22af240@redhat.com> <41ee101b-ec08-5e17-a9cc-5fe4e646f9da@redhat.com> <54ca6359-d827-aa9c-7d17-c480989675a0@redhat.com> Message-ID: On Wed, 31 Jul 2019 at 17:09, Aleksey Shipilev wrote: > > On 7/31/19 5:56 PM, Andrew John Hughes wrote: > > On 31/07/2019 10:02, Aleksey Shipilev wrote: > >> On 7/16/19 9:25 AM, Andrew John Hughes wrote: > >>> On 15/07/2019 09:27, Aleksey Shipilev wrote: > >>>> On 7/2/19 9:53 PM, Aleksey Shipilev wrote: > >>>>> Original RFE: > >>>>> https://bugs.openjdk.java.net/browse/JDK-8214687 > >>>>> https://hg.openjdk.java.net/jdk/jdk/rev/cfceb4df2499 > >>>>> > >>>>> Patch applies with usual reshufflings. But the test parts require touchups to compile and run on 8u: > >>>>> type inference is not that rich, and there is no Objects.checkIndex. 8u webrev: > >>>>> https://cr.openjdk.java.net/~shade/8214687/webrev.8u.01/ > >>> > >>> Objects.checkIndex is simply a wrapper around Preconditions.checkIndex: > >>> > >>> public static > >>> int checkIndex(int index, int length) { > >>> return Preconditions.checkIndex(index, length, null); > >>> } > >>> > >>> which is in 8u. Probably worth adding the 2-argument version to > >>> Preconditions. > >> > >> Getting back to this. Since we have moved Preconditions to private location in 8u, using it is > >> impossible for this patch. So, I would keep the webrev as is: > >> https://cr.openjdk.java.net/~shade/8214687/webrev.8u.01 > > > > We haven't moved anything as yet and my proposed patch leaves the class > > as public, so shouldn't be a blocker. The test in that patch uses > > Preconditions. > > Original patch needs Objects.checkIndex: > https://hg.openjdk.java.net/jdk/jdk/rev/cfceb4df2499#l2.32 > > What you are suggesting is changing that line to Preconditions (with new method!). What webrev > suggests is replacing it with the one-liner: > > 91 check(0 <= index && index < n, "Index is incorrect"); I thought I said everything here worth saying. To repeat, if you look at Objects.checkIndex in 9+, you'll see it just calls Preconditions.checkIndex. So what I'm suggesting is to do the same as the original code, without one level of indirection. What you're suggesting is a completely new line of code, > > Given that we are changing the code anyway, I don't see why do we need to introduce another > dependency to the about-to-be-moved class, do more code that diverges 8u from later releases, > instead of doing the trivial one-liner. The very point of my suggestion was about avoiding divergence. I can see your argument about an additional dependency, but I didn't write the original test code, and your argument applies equally to that as well. Objects.checkIndex(index, n)->Preconditions.checkIndex(index,n,null) or a direct Preconditoins.checkIndex(index,n,null); it's the same thing. If you're happy maintaining that divergence, then I have no problem with the patch, but it's a fallacy to pretend what I'm suggesting is more divergent. -- 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 gnu.andrew at redhat.com Thu Aug 22 09:15:54 2019 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 22 Aug 2019 10:15:54 +0100 Subject: RFR: [8u] 8141570: Fix Zero interpreter build for --disable-precompiled-headers In-Reply-To: <5935ba25ce64cfc747e9717ca1a742d7f35c0ec7.camel@redhat.com> References: <5935ba25ce64cfc747e9717ca1a742d7f35c0ec7.camel@redhat.com> Message-ID: On Thu, 22 Aug 2019 at 09:52, Severin Gehwolf wrote: > > Hi Andrew, > > On Wed, 2019-08-21 at 20:33 +0100, Andrew John Hughes wrote: > > This is the first of a series of four changes to support -Wreturn-type > > in OpenJDK 8u. The -Wreturn-type warning catches instances where control > > flow exits a non-void function without returning a value. This can > > combine with compiler optimisations in some cases to cause runtime > > crashes. The warning is turned on by default in GCC 8 [0], causing the > > build to fail if it is not explicitly disabled. > > > > The subsequent changes are JDK-8062808 to apply the warning and fix > > issues in the default build, JDK-8143245 to fix issues in the Zero build > > and JDK-8197981 to fix one remaining Zero issue on 32-bit platforms only. > > > > This change ensures the Zero build is not broken by 8062808 by disabling > > -Wreturn-type in the Zero makefile. > > > > Changes in the backport process: > > > > * The G1 changes are dropped as 8u does not contain JDK-8073013, which > > introduces g1EvacStats.* > > * I've changed the ifeq ($(USE_CLANG), true) to ifeq > > ($(JVM_VARIANT_ZEROSHARK), true). There seems to have been a mistake in > > the original patch which equated LLVM with clang. What is actually > > referred to by "some version of llvm do not like -Wundef" is the LLVM > > headers that Shark is built against, not the clang compiler which also > > uses LLVM. This made its way through to the new HotSpot build in OpenJDK > > 9 & 10, but is gone as of JDK-8198724 in OpenJDK 11 and later. > > > > This backport has been in IcedTea since 3.8.0 (2018-05-29) [1] and our > > RHEL RPMs since 2018-06-16 without issue. Builds of current 8u-dev on > > x86_64 with Zero release and Zero slowdebug succeeded. > > > > [0] https://gcc.gnu.org/gcc-8/changes.html > > [1] https://icedtea.classpath.org/bugzilla/show_bug.cgi?id=3548 > > I don't see any webrev. Did you forget to link to it? > > Thanks, > Severin > Ha, got so caught up in explaining all the other stuff, I forgot the meat of the matter. Here it is: https://cr.openjdk.java.net/~andrew/openjdk8/8141570/ -- 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 shade at redhat.com Thu Aug 22 09:20:19 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 22 Aug 2019 11:20:19 +0200 Subject: [8u] RFR 8214687: Optimize Collections.nCopies().hashCode() and equals() In-Reply-To: References: <43caafb3-239a-0829-9665-71dcae9bea01@redhat.com> <1d7e6380-912e-126b-e09f-4a77e22af240@redhat.com> <41ee101b-ec08-5e17-a9cc-5fe4e646f9da@redhat.com> <54ca6359-d827-aa9c-7d17-c480989675a0@redhat.com> Message-ID: <80276fa9-b2a1-e8c8-8d96-11b251c6b1d0@redhat.com> On 8/22/19 11:12 AM, Andrew Hughes wrote: > If you're happy maintaining that divergence, then I have no problem > with the patch, but it's a fallacy to pretend what I'm suggesting is > more divergent. I am happy with maintaining the inline one-liner. I shall be pushing the patch shortly then. -- Thanks, -Aleksey From sgehwolf at redhat.com Thu Aug 22 09:33:29 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 22 Aug 2019 11:33:29 +0200 Subject: RFR: [8u] 8141570: Fix Zero interpreter build for --disable-precompiled-headers In-Reply-To: References: <5935ba25ce64cfc747e9717ca1a742d7f35c0ec7.camel@redhat.com> Message-ID: <2044ef60ff55d039e0dd1195f17d5383d252926f.camel@redhat.com> On Thu, 2019-08-22 at 10:15 +0100, Andrew Hughes wrote: > Here it is: https://cr.openjdk.java.net/~andrew/openjdk8/8141570/ Looks good. Thanks, Severin From gnu.andrew at redhat.com Thu Aug 22 11:17:35 2019 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 22 Aug 2019 12:17:35 +0100 Subject: [8u] RFR (S) 8218201: Failures when vmIntrinsics::_getClass is not inlined In-Reply-To: <1b899228-d9c0-0f8e-f86c-803c384a24bc@redhat.com> References: <1b899228-d9c0-0f8e-f86c-803c384a24bc@redhat.com> Message-ID: On Thu, 8 Aug 2019 at 16:35, Aleksey Shipilev wrote: > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8218201 > https://hg.openjdk.java.net/jdk/jdk/rev/a2d3ca8062b9 > > 8u version needs a few adjustments, because context is a bit different. The new change should be > functionally equivalent to what we have in jdk/jdk. 8u webrev: > https://cr.openjdk.java.net/~shade/8218201/webrev.8u.01/ > > Testing: affected test (fails without the patch, passes with it); tier1 > > -- > Thanks, > -Aleksey > Patch looks good. FWIW, the fillInStackTrace case is removed in OpenJDK 9 by JDK-8076112 [0] (which adds HotSpotIntrinsicCandidate), but I can't see anything in that change which warrants its removal. I suspect it may be more related to the stack walking changes in 9. Elements of JDK-8076112 were backported for the recent security fix, JDK-8223511. I wonder if backporting the rest may be a worthwhile debugging aid for intrinsics on 8u, especially with regard to the varying support on different architectures. 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 gnu.andrew at redhat.com Thu Aug 22 11:27:20 2019 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 22 Aug 2019 12:27:20 +0100 Subject: [8u] RFR Backport of 8217896: Make better use of LCPUs when building on AIX In-Reply-To: References: Message-ID: On Fri, 9 Aug 2019 at 16:17, Andrew Leonard wrote: > > Hi, > Please can I request a review of this updated patch for 8217896 to > backport to jdk8u. The patch is essentially the same, but jdk8 the > build-performance.m4 is in a different location, with a different > copyright year, and the generated-configure.sh generation.. I have built > and tested this on our AIX machines. > http://cr.openjdk.java.net/~aleonard/8217896/webrev.03/ > Once reviewed I will add the jdk8u-fix-request. > Thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Patch looks fine to me. Out of interest, I presume the lcpu field is present with the same value as prtconf on non-SMT machines, but has a higher value than that returned by prtconf on SMT machines? 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 zgu at redhat.com Thu Aug 22 11:40:55 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 22 Aug 2019 07:40:55 -0400 Subject: [8u] 8218558: NMT stack traces in output should show mt component for virtual memory allocations Message-ID: Hi, I would like to backport this patch to 8u. It is the counterpart of JDK-8139673, that improves usability of NMT detail tracking, by associating every virtual memory allocation site with its memory type. 11u patch does not apply cleanly, but conflicts are minors. There are a couple of conflicts with copyright years, also a new include file in 11u patch that already added in 8u, and indents. Original bug: https://bugs.openjdk.java.net/browse/JDK-8218558 Original code review thread: https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2019-February/032428.html 8u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8218558-8u/webrev.00/index.html Thanks, -Zhengyu From zgu at redhat.com Thu Aug 22 11:48:33 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 22 Aug 2019 07:48:33 -0400 Subject: [8u] RFR 8219244: NMT: Change ThreadSafepointState's allocation type from mtInternal to mtThread Message-ID: Hi, I would like to backport this patch to 8u. This patch is trivial, it corrects mis-categorized allocation type. This one-line patch does not apply cleanly, due to line shifts. Original bug: https://bugs.openjdk.java.net/browse/JDK-8219244 Original code review thread: https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2019-February/032664.html 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8219244-8u/webrev.00/ Thanks, -Zhengyu From andrew_m_leonard at uk.ibm.com Thu Aug 22 12:33:09 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Thu, 22 Aug 2019 13:33:09 +0100 Subject: jdk8u-fix-request's label processing? In-Reply-To: <8ce598b7-07e7-750f-8b96-167c0947947e@redhat.com> References: <5ffc054b-ecde-bcad-9c1e-803145da30c2@redhat.com> <8ce598b7-07e7-750f-8b96-167c0947947e@redhat.com> Message-ID: Thank you Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Andrew John Hughes To: Aleksey Shipilev , Andrew Leonard , jdk8u-dev at openjdk.java.net Date: 21/08/2019 17:17 Subject: Re: jdk8u-fix-request's label processing? On 20/08/2019 10:55, Aleksey Shipilev wrote: > On 8/20/19 11:19 AM, Andrew Leonard wrote: >> i'm following the backport contribution process as a non-committer, >> https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix >> and i've labelled my bug jdk8u-fix-request, but no label update to add >> yes/no... has occurred yet. Is there a periodic review or notification by >> whoever processes these? or do I need to tell someone? > > You don't need to tell. Maintainers are periodically scanning the pending approvals queue. It might > take a while, especially when maintainers (for 8u it is Andrew Hughes) are all busy at the moment. > I'm working through them now. It's worth reminding people of: https://openjdk.java.net/projects/jdk-updates/approval.html specifically, rule 1 which states that fix requests should have a comment describing the motivation for the request and pointing to the review thread. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew [attachment "signature.asc" deleted by Andrew Leonard/UK/IBM] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From andrew_m_leonard at uk.ibm.com Thu Aug 22 12:49:09 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Thu, 22 Aug 2019 13:49:09 +0100 Subject: [8u] RFR Backport of 8217896: Make better use of LCPUs when building on AIX In-Reply-To: References: Message-ID: Thanks Andrew, and correct on non-SMT it produces the same value as the previous code did. Cheers Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Andrew Hughes To: Andrew Leonard Cc: jdk8u-dev Date: 22/08/2019 12:27 Subject: Re: [8u] RFR Backport of 8217896: Make better use of LCPUs when building on AIX On Fri, 9 Aug 2019 at 16:17, Andrew Leonard wrote: > > Hi, > Please can I request a review of this updated patch for 8217896 to > backport to jdk8u. The patch is essentially the same, but jdk8 the > build-performance.m4 is in a different location, with a different > copyright year, and the generated-configure.sh generation.. I have built > and tested this on our AIX machines. > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Ealeonard_8217896_webrev.03_&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=OF7K7wDyJgoEtbIWjBLRSOfAeIWJ69BzD5Oq9oZXc9Y&s=o1xgiBpcvP4vNaO9ISQgB0t2NhTZmvemuNEMeu877Mk&e= > Once reviewed I will add the jdk8u-fix-request. > Thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Patch looks fine to me. Out of interest, I presume the lcpu field is present with the same value as prtconf on non-SMT machines, but has a higher value than that returned by prtconf on SMT machines? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. ( https://urldefense.proofpoint.com/v2/url?u=http-3A__www.redhat.com&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=OF7K7wDyJgoEtbIWjBLRSOfAeIWJ69BzD5Oq9oZXc9Y&s=O7Hbx7ZOoqxbw3HlTn1-ZIEhstpREhwZXqhBVMaYkw8&e= ) Web Site: https://urldefense.proofpoint.com/v2/url?u=http-3A__fuseyism.com&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=OF7K7wDyJgoEtbIWjBLRSOfAeIWJ69BzD5Oq9oZXc9Y&s=SD-EIg_jAFwnMRpJ9Tc5WaoLJ_pBSu57qkTqu8cagkc&e= Twitter: https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_gnu-5Fandrew-5Fjava&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=OF7K7wDyJgoEtbIWjBLRSOfAeIWJ69BzD5Oq9oZXc9Y&s=ZQ187McgzebuBVJg0H2OA0DhYtvIkMiXPmE1ERYzfQ0&e= PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From neugens at redhat.com Thu Aug 22 13:01:30 2019 From: neugens at redhat.com (Mario Torre) Date: Thu, 22 Aug 2019 15:01:30 +0200 Subject: RFC: backport of JDK-8222980: Upgrade IANA Language Subtag Registry to Version 2019-04-03 Message-ID: Hi all, I would like to backport the following bug: https://bugs.openjdk.java.net/browse/JDK-8222980 To jdk8u-dev. Patch applies cleanly, compiles and passes its test. The backport for 11 was also already pushed: http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/6bd2a0d34f0e The patch is mostly for consistency of both the Iana Subtag Registry and the incoming Oracle JDK8 release. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From gnu.andrew at redhat.com Thu Aug 22 13:14:09 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 22 Aug 2019 14:14:09 +0100 Subject: [8u] 8217676: Upgrade libpng to 1.6.37 In-Reply-To: References: Message-ID: <42cc1803-6f71-ba9d-d262-f79522071f10@redhat.com> On 12/08/2019 16:12, Zhengyu Gu wrote: > Hi, > > I would like to backport this CR to 8u, as it is on Oracle 8u backport > list. > > The changeset from jdk13 > (https://hg.openjdk.java.net/jdk/jdk13/rev/53154e45385a) did not apply > cleanly. > > 1) No libpng.md in 8u, so ignore all diffs for libpng.md > 2) -DPNG_ARM_NEON_OP and DPNG_ARM_NEON_IMPLEMENTATION in > Awt2dLibraries.gmk, are arm only flags, but we decided to include them > in this backport, given upstreaming aarch64 in progress and they are > harmless to other platforms. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217676 > JDK13 webrev: http://cr.openjdk.java.net/~serb/8217676/webrev.01/ > JDK13 code review thread: > http://mail.openjdk.java.net/pipermail/awt-dev/2019-July/015331.html > > 8u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8217676-8u/webrev.00/ > > Test: > ? jdk_imageio on Linux 86_64 > > Thanks, > > -Zhengyu The changes to libpng.md should not simply be discarded. The same license information exists in 8u in the THIRD_PARTY_README file found in all repos. I'd say use previous libpng updates as a template, but they all seem to have made the same mistake of missing this, resulting in bugs like JDK-8210431 [0]. Instead, look at the JDK-8220495 giflib update backport from the last update [1]: Checking . changeset: 2386:7854afda0cd9 user: serb date: Sun Mar 31 16:57:21 2019 -0700 summary: 8220495: Update GIFlib library to the 5.1.8 Checking corba changeset: 1887:37bfb5bd2e68 user: serb date: Sun Mar 31 16:57:21 2019 -0700 summary: 8220495: Update GIFlib library to the 5.1.8 Checking jaxp changeset: 1974:18619019e028 user: serb date: Sun Mar 31 16:57:21 2019 -0700 summary: 8220495: Update GIFlib library to the 5.1.8 Checking jaxws changeset: 1778:937fcb3b28d7 user: serb date: Sun Mar 31 16:57:21 2019 -0700 summary: 8220495: Update GIFlib library to the 5.1.8 Checking langtools changeset: 3787:585c9a1ce7eb user: serb date: Sun Mar 31 16:57:21 2019 -0700 summary: 8220495: Update GIFlib library to the 5.1.8 Checking hotspot changeset: 8992:54e5e3c816d4 user: serb date: Sun Mar 31 16:57:21 2019 -0700 summary: 8220495: Update GIFlib library to the 5.1.8 Checking jdk changeset: 13557:5e4b7ed6e904 user: serb date: Sun Mar 31 16:57:21 2019 -0700 summary: 8220495: Update GIFlib library to the 5.1.8 Checking nashorn changeset: 2454:a526f3dd4be8 user: serb date: Sun Mar 31 16:57:21 2019 -0700 summary: 8220495: Update GIFlib library to the 5.1.8 [0] https://hg.openjdk.java.net/jdk8u/jdk8u/rev/7d04f40e401d [1] https://bugs.openjdk.java.net/browse/JDK-8220495 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 andrew_m_leonard at uk.ibm.com Thu Aug 22 13:27:01 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Thu, 22 Aug 2019 14:27:01 +0100 Subject: [8u] Request for approved backport push: 8217896: Make better use of LCPUs when building on AIX Message-ID: Hi, As per step 8 of https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix and as a non-committer, please can I request a jdk8u committer to push the 8u patch for the "approved" backport of https://bugs.openjdk.java.net/browse/JDK-8217896 . I have built and tested this jdk8u updated patch on our AIX machines: http://cr.openjdk.java.net/~aleonard/8217896/webrev.03/ RFR reviews: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/009998.html Thank you Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From gnu.andrew at redhat.com Thu Aug 22 13:35:59 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 22 Aug 2019 14:35:59 +0100 Subject: RFR: Backport JDK-8217359: C2 compiler triggers SIGSEGV after transformation in ConvI2LNode::Ideal In-Reply-To: References: Message-ID: On 20/08/2019 23:28, Roman Kennke wrote: > This backports to 8u: > > https://bugs.openjdk.java.net/browse/JDK-8217359 > > The fix applies after fixing paths and putting the patch into the right > place in connode.cpp instead of convertnode.cpp. > > Testing: passes new testcase (fails without fix), passes tier1, tier2 > > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8217359/webrev.00/ > > Can I please get a review? > > Roman > The connode.cpp copyright header needs to be bumped in the same way as convertnode.cpp's was in the original patch (currently it says 2013). Otherwise looks good. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From sgehwolf at redhat.com Thu Aug 22 13:51:25 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 22 Aug 2019 15:51:25 +0200 Subject: [8u] Request for approved backport push: 8217896: Make better use of LCPUs when building on AIX In-Reply-To: References: Message-ID: <69381344ea655a36d71f6dd6a6b868461df78b72.camel@redhat.com> Hi Andrew, On Thu, 2019-08-22 at 14:27 +0100, Andrew Leonard wrote: > Hi, > As per step 8 of > https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix > and as a non-committer, please can I request a jdk8u committer to push the > 8u patch for the "approved" backport of > https://bugs.openjdk.java.net/browse/JDK-8217896 . > > I have built and tested this jdk8u updated patch on our AIX machines: > http://cr.openjdk.java.net/~aleonard/8217896/webrev.03/ > > RFR reviews: > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/009998.html Please send me an HG exported patch which passes jcheck and I'll push it for you. Thanks, Severin > Thank you > Andrew > > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From gnu.andrew at redhat.com Thu Aug 22 13:51:46 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 22 Aug 2019 14:51:46 +0100 Subject: [8u] Request for approved backport push: 8217896: Make better use of LCPUs when building on AIX In-Reply-To: References: Message-ID: <00664c2c-7a9e-91b4-06aa-31cbaf4fca0c@redhat.com> On 22/08/2019 14:27, Andrew Leonard wrote: > Hi, > As per step 8 of > https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix > and as a non-committer, please can I request a jdk8u committer to push the > 8u patch for the "approved" backport of > https://bugs.openjdk.java.net/browse/JDK-8217896 . > > I have built and tested this jdk8u updated patch on our AIX machines: > http://cr.openjdk.java.net/~aleonard/8217896/webrev.03/ > > RFR reviews: > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/009998.html > > Thank you > Andrew > > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > There's no need to e-mail for approval. Setting the jdk8u-fix-request flag on the bug is sufficient. See [0]. This bug is already approved and is on the 'approved but not pushed' list [1]. If you don't have push access to the repositories, let me know and I can push it on your behalf. [0] https://wiki.openjdk.java.net/display/jdk8u [1] https://bugs.openjdk.java.net/browse/JDK-8218201?filter=36427 Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From rkennke at redhat.com Thu Aug 22 13:59:09 2019 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 22 Aug 2019 15:59:09 +0200 Subject: RFR: Backport JDK-8217359: C2 compiler triggers SIGSEGV after transformation in ConvI2LNode::Ideal In-Reply-To: References: Message-ID: <694be96a-4f58-b4ce-f1a9-06bc82641b25@redhat.com> Am 22.08.19 um 15:35 schrieb Andrew John Hughes: > > > On 20/08/2019 23:28, Roman Kennke wrote: >> This backports to 8u: >> >> https://bugs.openjdk.java.net/browse/JDK-8217359 >> >> The fix applies after fixing paths and putting the patch into the right >> place in connode.cpp instead of convertnode.cpp. >> >> Testing: passes new testcase (fails without fix), passes tier1, tier2 >> >> Webrev: >> http://cr.openjdk.java.net/~rkennke/JDK-8217359/webrev.00/ >> >> Can I please get a review? >> >> Roman >> > > The connode.cpp copyright header needs to be bumped in the same way as > convertnode.cpp's was in the original patch (currently it says 2013). > > Otherwise looks good. Ok, thank you! I'll update this before pushing without posting another webrev. Waiting for maintainer approval. Thanks, Roman From gnu.andrew at redhat.com Thu Aug 22 14:08:31 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 22 Aug 2019 15:08:31 +0100 Subject: [8u] RFR 8216401: Allow "file:" URLs in Class-Path of local JARs In-Reply-To: References: <53f863a8-0a6e-2f13-4c23-fcb2cfc5053a@redhat.com> <3C921A78-DEF8-4784-930E-BDE6CFA13EB2@amazon.com> Message-ID: <7895b21c-e191-8d98-7734-50fa5b56ea4b@redhat.com> On 13/08/2019 20:34, Zhengyu Gu wrote: > Hi Clive, > > On 8/13/19 2:59 PM, Verghese, Clive wrote: >> Hi Zhengyu, >> >> Instead of importing the writeToDisk function to the test, We could >> update the ClassFileInstaller to be similar to the one in tip. [1] >> >> http://cr.openjdk.java.net/~phh/8216401/webrev.8u0.00/ > > I think the principal of 8u backport, is to minimize the scope to > absolutely needed. Not necessarily. It varies on a case-by-case basis and it's usually worth doing a little repository archaeology to determine why differences exist. It's less about the most expedient way to do a single backport as to the long term maintainability of the source code base. If there's an earlier change that will make the original patch apply more easily, the advantages of doing so, and the benefits of that to later backports, needs to be weighed against the risks of backporting that dependency. The refactoring we backported with the printing implementation last time is a good example. The risk of renaming those internal classes is minimal - especially as the new names are already in use in later JDKs - and future backports in that area are now more likely to apply cleanly. I imported some of ClassFileInstaller code to the > test, because I have not seen they are used by others. If that's the > case, I think we should arrange partial backport for test library > changes. I don't like the idea to sneak in test infrastructure changes > via unrelated backports. I agree, though it should be done under the original changes as much as possible. See my comments on JDK-8229501. > > Thanks, > > -Zhengyu > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Thu Aug 22 15:23:30 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 22 Aug 2019 16:23:30 +0100 Subject: RFR: Backport JDK-8215265: C2: range check elimination may allow illegal out of bound access In-Reply-To: References: Message-ID: On 20/08/2019 22:23, Roman Kennke wrote: > This is a backport of the original jdk12 fix: > > https://bugs.openjdk.java.net/browse/JDK-8215265 > > Which has been backported to 11 already: > http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/2815d9d11969 > > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8215265/webrev.00/ > > The only differs is relatively minor details: paths adjusted, new > AddINode() -> new (C) AddINode(). > > Testing: new testcase fails without fix, passes with fix. No tier1 > regressions. > > Can I please get a review? > > Thanks, > Roman > Looks good to me. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Thu Aug 22 15:25:35 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 22 Aug 2019 16:25:35 +0100 Subject: [8u] java/util/{Calendar, TimeZone} test failures In-Reply-To: <0d7280cc-4cf7-499d-2583-1a124ae0204e@redhat.com> References: <0d7280cc-4cf7-499d-2583-1a124ae0204e@redhat.com> Message-ID: <1408e54d-f76a-9b59-26fe-47fe4cf6d43b@redhat.com> On 21/08/2019 18:16, Aleksey Shipilev wrote: > Hi, > > I am running tier1 in jdk8u-dev, and these tests fail: > > FAILED: java/util/Calendar/CalendarRegression.java > FAILED: java/util/Calendar/JapanEraNameCompatTest.java > FAILED: java/util/TimeZone/HongKong.java > > They seem to fail since 8u222. There seems to be a gap in locale data somewhere? Is anyone looking > into that? > Not right now, but I'm aware of it. I'll try and find some time once we fork for 8u232. It's going to mean cherry-picking some locale changes from 9+. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Thu Aug 22 15:29:24 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 22 Aug 2019 16:29:24 +0100 Subject: RFR: Backport JDK-8217359: C2 compiler triggers SIGSEGV after transformation in ConvI2LNode::Ideal In-Reply-To: <694be96a-4f58-b4ce-f1a9-06bc82641b25@redhat.com> References: <694be96a-4f58-b4ce-f1a9-06bc82641b25@redhat.com> Message-ID: <8bef8d74-bbd7-d887-b6d4-60cca55cc187@redhat.com> On 22/08/2019 14:59, Roman Kennke wrote: > > > Am 22.08.19 um 15:35 schrieb Andrew John Hughes: >> >> >> On 20/08/2019 23:28, Roman Kennke wrote: >>> This backports to 8u: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8217359 >>> >>> The fix applies after fixing paths and putting the patch into the right >>> place in connode.cpp instead of convertnode.cpp. >>> >>> Testing: passes new testcase (fails without fix), passes tier1, tier2 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rkennke/JDK-8217359/webrev.00/ >>> >>> Can I please get a review? >>> >>> Roman >>> >> >> The connode.cpp copyright header needs to be bumped in the same way as >> convertnode.cpp's was in the original patch (currently it says 2013). >> >> Otherwise looks good. > > Ok, thank you! I'll update this before pushing without posting another > webrev. Waiting for maintainer approval. > > Thanks, > Roman > And I'm the maintainer approving it ;-) I'm happy to trust you to fix that without another webrev. Thumbs up. 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 mbalao at redhat.com Thu Aug 22 15:59:10 2019 From: mbalao at redhat.com (Martin Balao) Date: Thu, 22 Aug 2019 12:59:10 -0300 Subject: [8u] RFR 8218553: Enhance keystore load debug output Message-ID: Hi, I'd like to request a review for the jdk8u backport of 8218553 [1], as requested in [2]. Webrev.00: * http://cr.openjdk.java.net/~mbalao/webrevs/8218553/webrev.8218553.jdk8u.jdk.00/ Changes to the original patch: * Copyright dates * Paths * In JavaKeyStore.java, the hook does not apply cleanly because of a different context. In the original patch, there are a couple of import below the line added. In the backport patch, there is a comment. Please note that the line added is exactly the same and there are no code changes. Testing * No regressions found in sun/security/pkcs11 and sun/security/pkcs12 Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8218553 [2] - https://bugs.openjdk.java.net/browse/JDK-8218553?focusedCommentId=14285701&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14285701 From gnu.andrew at redhat.com Thu Aug 22 16:19:04 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 22 Aug 2019 17:19:04 +0100 Subject: RFC: backport of JDK-8210863: Remove Xrandr include files from JDK sources In-Reply-To: <45afd1d4-c340-f6d3-7537-7dfecff6fd51@redhat.com> References: <53aa9481-9134-700b-22cd-6526725015af@redhat.com> <45afd1d4-c340-f6d3-7537-7dfecff6fd51@redhat.com> Message-ID: On 30/07/2019 15:52, Aleksey Shipilev wrote: > On 7/30/19 3:02 PM, Andrew John Hughes wrote: >> What is the motivation for this? JDK-8213944 would seem to be evidence >> that the removal risks breakage and OpenJDK 8u is an older JDK which may >> still need to be built on systems without Xrandr. > > Do we know such the system? Given this is already done in 11u, this would mean such a system could > not build 11u already, and so would require updates. I don't know every system on which OpenJDK 8 is being built. Given that the change is to remove the header, rather than add it, the burden of proof is on the person proposing the change to show it won't cause breakage. The AIX issue, JDK-8213944, demonstrates that it is perfectly possible for there to be systems already happily building 8u, only to break when this header is removed. I'm not sure what 11u has to do with anything. 8u is significantly older than 11u and there will be older platforms where 8u is deployed, but 11u never will be. Our own RHEL 6 is an example. FWIW, I wouldn't have supported adding this to 11u either. Changes to the build requirements should only be made to a legacy release when really necessary. I see no such motivation here. > > Also, the issue itself has "8-bp" label, which suggests Oracle would consider it for backports too. > We can, of course, wait for that to happen. I don't see how it makes any difference. This is one area where comparisons with Oracle's trees don't make any sense. Oracle are performing proprietary builds in a known build environment. If they have these headers in all their build environments for JDK 8, they can drop them from the source tree. As an open source project, we do not know all the build environments used to build OpenJDK 8, so removing such a header has a greater risk. Not only does this include a wider variety of compilers and operating system versions, but it also includes a wider range of architectures. On the flipside, this is why Oracle don't tend to backport build changes unless they are needed for their build environments, so backporting changes to build with newer versions of GCC or work around a deprecated readdir_r is pretty much left to the rest of us. They do make alterations on occasion e.g. there was a flurry of build changes not long before 8u changed ownership, to support building on a newer Windows environment. > > -Aleksey > -- 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 andrew_m_leonard at uk.ibm.com Thu Aug 22 16:59:33 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Thu, 22 Aug 2019 17:59:33 +0100 Subject: [8u] Request for approved backport push: 8217896: Make better use of LCPUs when building on AIX In-Reply-To: <69381344ea655a36d71f6dd6a6b868461df78b72.camel@redhat.com> References: <69381344ea655a36d71f6dd6a6b868461df78b72.camel@redhat.com> Message-ID: Hi Severin, I've put a jcheck'd hg export patch here: http://cr.openjdk.java.net/~aleonard/8217896/jdk-8217896.patch Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Severin Gehwolf To: Andrew Leonard , jdk8u-dev at openjdk.java.net Date: 22/08/2019 14:51 Subject: Re: [8u] Request for approved backport push: 8217896: Make better use of LCPUs when building on AIX Hi Andrew, On Thu, 2019-08-22 at 14:27 +0100, Andrew Leonard wrote: > Hi, > As per step 8 of > https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.openjdk.java.net_display_JDKUpdates_How-2Bto-2Bcontribute-2Ba-2Bfix&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=c63WSV0geb4TWqvRM9iYF9AhOddnxbaSNfT9MMG30cs&s=jYQp_KgKi62N2RMRmAhsxQ3LGa0HtH4SoroEgpd7bbQ&e= > and as a non-committer, please can I request a jdk8u committer to push the > 8u patch for the "approved" backport of > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8217896&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=c63WSV0geb4TWqvRM9iYF9AhOddnxbaSNfT9MMG30cs&s=6ZvsVWUq5OpUsBUVRUeKtZT0Sh9nrcfr9eV3klPmMjs&e= . > > I have built and tested this jdk8u updated patch on our AIX machines: > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Ealeonard_8217896_webrev.03_&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=c63WSV0geb4TWqvRM9iYF9AhOddnxbaSNfT9MMG30cs&s=GpMklYNyRdRdrTvjixzQrp5funRKTSF7QOaRPQ5Ebow&e= > > RFR reviews: > https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openjdk.java.net_pipermail_jdk8u-2Ddev_2019-2DAugust_009998.html&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=c63WSV0geb4TWqvRM9iYF9AhOddnxbaSNfT9MMG30cs&s=LN4b2pRsF2-nSDfg2Ia7JFZyHAtT0LEWH-f5mqJsDTA&e= Please send me an HG exported patch which passes jcheck and I'll push it for you. Thanks, Severin > Thank you > Andrew > > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From andrew_m_leonard at uk.ibm.com Thu Aug 22 17:01:24 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Thu, 22 Aug 2019 18:01:24 +0100 Subject: [8u] Request for approved backport push: 8217896: Make better use of LCPUs when building on AIX In-Reply-To: <00664c2c-7a9e-91b4-06aa-31cbaf4fca0c@redhat.com> References: <00664c2c-7a9e-91b4-06aa-31cbaf4fca0c@redhat.com> Message-ID: Ah thanks Andrew, Yes, I don't have committer rights, so was requesting someone who did, Severin kindly offered, so i've just sent him the patch. Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Andrew John Hughes To: Andrew Leonard , jdk8u-dev at openjdk.java.net Date: 22/08/2019 14:52 Subject: Re: [8u] Request for approved backport push: 8217896: Make better use of LCPUs when building on AIX On 22/08/2019 14:27, Andrew Leonard wrote: > Hi, > As per step 8 of > https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix > and as a non-committer, please can I request a jdk8u committer to push the > 8u patch for the "approved" backport of > https://bugs.openjdk.java.net/browse/JDK-8217896 . > > I have built and tested this jdk8u updated patch on our AIX machines: > http://cr.openjdk.java.net/~aleonard/8217896/webrev.03/ > > RFR reviews: > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/009998.html > > Thank you > Andrew > > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > There's no need to e-mail for approval. Setting the jdk8u-fix-request flag on the bug is sufficient. See [0]. This bug is already approved and is on the 'approved but not pushed' list [1]. If you don't have push access to the repositories, let me know and I can push it on your behalf. [0] https://wiki.openjdk.java.net/display/jdk8u [1] https://bugs.openjdk.java.net/browse/JDK-8218201?filter=36427 Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew [attachment "signature.asc" deleted by Andrew Leonard/UK/IBM] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From gnu.andrew at redhat.com Thu Aug 22 17:39:09 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 22 Aug 2019 18:39:09 +0100 Subject: RFC: backport of JDK-8210863: Remove Xrandr include files from JDK sources In-Reply-To: References: <53aa9481-9134-700b-22cd-6526725015af@redhat.com> Message-ID: <22a8d7ef-e394-1728-ecf8-6a765c8fc67a@redhat.com> On 30/07/2019 15:59, Mario Torre wrote: snip... >>>> >>> >>> What is the motivation for this? JDK-8213944 would seem to be evidence >>> that the removal risks breakage and OpenJDK 8u is an older JDK which may >>> still need to be built on systems without Xrandr. >> >> If an older distribution doesn't support xrandr (which I doubt since >> this extensions is quite old) then it would not work anyway, as >> there's no implementation in this patch, just the header files. >> True, but it will build. There are a multitude of areas in the code which will happily compile, but not actually work at runtime due to missing libraries. It's not something I'm particularly keen on either, but that's the way it is. I've spent time, mainly in IcedTea, looking into these and providing the option of building against them instead. Whether they'd ever be accepted upstream, I don't know. For example, the codebase doesn't check for Gtk+, but instead has chunks of its headers, which in this case, are mixed in with the JDK code rather than being cleanly separated like this Xrandr case. PCSC is another example. Generally, the whole codebase is designed around keeping the binary dependencies minimal to increase system compatibility, so anything optional is searched for at runtime. You may remember that your Xcomposite patch was altered to do a runtime lookup before it was approved. On the OpenJDK side, new build requirements mean new dependencies. I've had complaints in the past from Gentoo users that they have to install cups to build OpenJDK, because those headers *aren't* included. So changing this kind of thing has quite a wide impact. >> I think such cases would be covered by JDK-8213944 more appropriately, >> rather than fallback at runtime. I'm not sure what you mean here. 8213944 adds #ifdefs to the code so that AIX doesn't need the header. If AIX does ever gain Xrandr, that will need to be changed again. 8u builds will just start working. That works for AIX because AIX has never had Xrandr, so AIX = no Xrandr can currently assumed. To do this generally, you'd have to change the Xrandr detection in configure to add a define, that can then be used in the code rather than AIX. Having Xrandr.h would then again be optional. That's something that would need to be pursued in jdk/jdk first, then backported. The obvious issue that comes to mind is that you then assume that no Xrandr on the build machine means no Xrandr on the target machine, which may not be true. Just as now, it also means that Xrandr on the build machine doesn't mean the code will run on the target. > > I didn't answer your question. I don't mind not pushing this patch or > holding it, the only reason why I did the backport is that is for > consistency with the Oracle JDK and because it has the redhat-interest > label, if the patch isn't necessary I suggest to remove the label. I didn't add it to begin with, not sure who did. I assume it was just out of a desire to sync with 11u. > > Cheers, > Mario > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From sgehwolf at redhat.com Thu Aug 22 17:57:16 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 22 Aug 2019 19:57:16 +0200 Subject: [8u] Request for approved backport push: 8217896: Make better use of LCPUs when building on AIX In-Reply-To: References: <69381344ea655a36d71f6dd6a6b868461df78b72.camel@redhat.com> Message-ID: <435b5a77bef19e6b74a08bbc497050097f0529ff.camel@redhat.com> On Thu, 2019-08-22 at 17:59 +0100, Andrew Leonard wrote: > Hi Severin, > I've put a jcheck'd hg export patch here: > http://cr.openjdk.java.net/~aleonard/8217896/jdk-8217896.patch Thanks, pushed: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/rev/2cd484c5b7f8 Cheers, Severin From shade at redhat.com Thu Aug 22 18:25:40 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 22 Aug 2019 20:25:40 +0200 Subject: [8u] RFR 8219244: NMT: Change ThreadSafepointState's allocation type from mtInternal to mtThread In-Reply-To: References: Message-ID: On 8/22/19 1:48 PM, Zhengyu Gu wrote: > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8219244-8u/webrev.00/ Backport looks good. -- Thanks, -Aleksey From shade at redhat.com Thu Aug 22 18:56:11 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 22 Aug 2019 20:56:11 +0200 Subject: RFC: backport of JDK-8222980: Upgrade IANA Language Subtag Registry to Version 2019-04-03 In-Reply-To: References: Message-ID: On 8/22/19 3:01 PM, Mario Torre wrote: > I would like to backport the following bug: > https://bugs.openjdk.java.net/browse/JDK-8222980 > > To jdk8u-dev. > > Patch applies cleanly, compiles and passes its test. I am confused, why are you asking here? You can proceed to label the issue and put "Fix Request", as per step 6 in checklist: https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix There is apparently jdk8u-fix-request, but no "Fix request" comment. -- Thanks, -Aleksey From zgu at redhat.com Thu Aug 22 19:00:04 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 22 Aug 2019 15:00:04 -0400 Subject: [8u] RFR 8219244: NMT: Change ThreadSafepointState's allocation type from mtInternal to mtThread In-Reply-To: References: Message-ID: <66073e89-6566-6790-35e3-4e4e036f1ed2@redhat.com> Thanks, Aleksey. -Zhengyu On 8/22/19 2:25 PM, Aleksey Shipilev wrote: > On 8/22/19 1:48 PM, Zhengyu Gu wrote: >> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8219244-8u/webrev.00/ > > Backport looks good. > From shade at redhat.com Thu Aug 22 19:11:27 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 22 Aug 2019 21:11:27 +0200 Subject: [8u] RFR (S) 8218201: Failures when vmIntrinsics::_getClass is not inlined In-Reply-To: References: <1b899228-d9c0-0f8e-f86c-803c384a24bc@redhat.com> Message-ID: <17fb2495-c854-0df7-1ea5-912a5633a508@redhat.com> On 8/22/19 1:17 PM, Andrew Hughes wrote: > Patch looks good. Thanks, going to push it soon. > FWIW, the fillInStackTrace case is removed in OpenJDK 9 by JDK-8076112 > [0] (which adds HotSpotIntrinsicCandidate), but I can't see anything > in that change which warrants its removal. I suspect it may be more > related to the stack walking changes in 9. Yeah. > Elements of JDK-8076112 were backported for the recent security fix, > JDK-8223511. I wonder if backporting the rest may be a worthwhile > debugging aid for intrinsics on 8u, especially with regard to the > varying support on different architectures. Maybe? I don't see any code for JDK-8223511 yet, so cannot really judge. If it backported quite a bit already, we can indeed consider backporting the rest. On the other hand, that diagnostics is mostly useful when adding/modifying JDK-JVM intrinsics list, which is rare (and certainly very rare for backports). I can tell when all the bits and pieces are in public repo. -- Thanks, -Aleksey From zgu at redhat.com Thu Aug 22 20:00:13 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 22 Aug 2019 16:00:13 -0400 Subject: [8u] 8217676: Upgrade libpng to 1.6.37 In-Reply-To: <42cc1803-6f71-ba9d-d262-f79522071f10@redhat.com> References: <42cc1803-6f71-ba9d-d262-f79522071f10@redhat.com> Message-ID: On 8/22/19 9:14 AM, Andrew John Hughes wrote: > On 12/08/2019 16:12, Zhengyu Gu wrote: >> Hi, >> >> I would like to backport this CR to 8u, as it is on Oracle 8u backport >> list. >> >> The changeset from jdk13 >> (https://hg.openjdk.java.net/jdk/jdk13/rev/53154e45385a) did not apply >> cleanly. >> >> 1) No libpng.md in 8u, so ignore all diffs for libpng.md >> 2) -DPNG_ARM_NEON_OP and DPNG_ARM_NEON_IMPLEMENTATION in >> Awt2dLibraries.gmk, are arm only flags, but we decided to include them >> in this backport, given upstreaming aarch64 in progress and they are >> harmless to other platforms. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217676 >> JDK13 webrev: http://cr.openjdk.java.net/~serb/8217676/webrev.01/ >> JDK13 code review thread: >> http://mail.openjdk.java.net/pipermail/awt-dev/2019-July/015331.html >> >> 8u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8217676-8u/webrev.00/ >> >> Test: >> ? jdk_imageio on Linux 86_64 >> >> Thanks, >> >> -Zhengyu > > The changes to libpng.md should not simply be discarded. The same > license information exists in 8u in the THIRD_PARTY_README file found in > all repos. Updated webrev: root: http://cr.openjdk.java.net/~zgu/JDK-8217676-8u/root/webrev.00/ corba: http://cr.openjdk.java.net/~zgu/JDK-8217676-8u/corba/webrev.00 hotspot: http://cr.openjdk.java.net/~zgu/JDK-8217676-8u/hotspot/webrev.00 jaxp: http://cr.openjdk.java.net/~zgu/JDK-8217676-8u/jaxp/webrev.00 jaxws: http://cr.openjdk.java.net/~zgu/JDK-8217676-8u/jaxws/webrev.00/ jdk: http://cr.openjdk.java.net/~zgu/JDK-8217676-8u/jdk/webrev.00/ langtools: http://cr.openjdk.java.net/~zgu/JDK-8217676-8u/langtools/webrev.00/ nashorn: http://cr.openjdk.java.net/~zgu/JDK-8217676-8u/nashorn/webrev.00/ Thanks, -Zhengyu > > I'd say use previous libpng updates as a template, but they all seem to > have made the same mistake of missing this, resulting in bugs like > JDK-8210431 [0]. > > Instead, look at the JDK-8220495 giflib update backport from the last > update [1]: > > Checking . > changeset: 2386:7854afda0cd9 > user: serb > date: Sun Mar 31 16:57:21 2019 -0700 > summary: 8220495: Update GIFlib library to the 5.1.8 > > Checking corba > changeset: 1887:37bfb5bd2e68 > user: serb > date: Sun Mar 31 16:57:21 2019 -0700 > summary: 8220495: Update GIFlib library to the 5.1.8 > > Checking jaxp > changeset: 1974:18619019e028 > user: serb > date: Sun Mar 31 16:57:21 2019 -0700 > summary: 8220495: Update GIFlib library to the 5.1.8 > > Checking jaxws > changeset: 1778:937fcb3b28d7 > user: serb > date: Sun Mar 31 16:57:21 2019 -0700 > summary: 8220495: Update GIFlib library to the 5.1.8 > > Checking langtools > changeset: 3787:585c9a1ce7eb > user: serb > date: Sun Mar 31 16:57:21 2019 -0700 > summary: 8220495: Update GIFlib library to the 5.1.8 > > Checking hotspot > changeset: 8992:54e5e3c816d4 > user: serb > date: Sun Mar 31 16:57:21 2019 -0700 > summary: 8220495: Update GIFlib library to the 5.1.8 > > Checking jdk > changeset: 13557:5e4b7ed6e904 > user: serb > date: Sun Mar 31 16:57:21 2019 -0700 > summary: 8220495: Update GIFlib library to the 5.1.8 > > Checking nashorn > changeset: 2454:a526f3dd4be8 > user: serb > date: Sun Mar 31 16:57:21 2019 -0700 > summary: 8220495: Update GIFlib library to the 5.1.8 > > [0] https://hg.openjdk.java.net/jdk8u/jdk8u/rev/7d04f40e401d > [1] https://bugs.openjdk.java.net/browse/JDK-8220495 > > Thanks, > From joe.darcy at oracle.com Tue Aug 6 01:54:38 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 06 Aug 2019 01:54:38 -0000 Subject: CSR process for OpenJDK 11 and 8 Updates In-Reply-To: References: Message-ID: Hi Christoph, Returning to this thread, from a side discussion at the OpenJDK Committers? Workshop last week, my understanding is that Andrew does want to use the CSR process for the update releases. Andrew, please confirm, and, if so, we can work on updating the CSR documentation accordingly. Thanks, -Joe On 6/21/2019 11:21 AM, Langer, Christoph wrote: > > Hi, > > thanks for that hint, Joe. > > I think you also said some time ago, that if there already existed a > CSR for an Oracle JDK11 backport of a certain bug, we can also use it > and link it to the OpenJDK backport item. Is that correct? > > Cheers > > Christoph > > *From:*Joe Darcy > *Sent:* Freitag, 21. Juni 2019 18:46 > *To:* Langer, Christoph ; Andrew Haley > > *Cc:* jdk-updates-dev at openjdk.java.net; jdk8u-dev > ; Hohensee, Paul > *Subject:* Re: CSR process for OpenJDK 11 and 8 Updates > > Hello, > > On 6/19/2019 12:26 AM, Langer, Christoph wrote: > > Hi Joe, Andrew, > > I?m currently wondering about the status of the CSR process for > JDK updates. Do we use the CSR process or not? > > As per previous mailing list discussions [1], I read that that the > project lead of 8u and 11u is under the assumption that we are > using CSR. However, as per the latest CSRs in that area [2], [3], > ?I understand that the CSR group lead is under the assumption that > Open JDK updates doesn?t use this process and hence these CSRs > were pended. Obviously there?s some disconnect here? ??So, what is > the current status? Did you already sort this out? > > My personal view is that a CSR process would be beneficial to the > JDK updates projects, too. > > In any case, thanks in advance for some guidance on how to handle > backports with attached CSRs! > > While discussion are on-going, the CSR FAQ does address a common > situation of how to handle backports and CSRs: > > Q: How should I get CSR review for multiple release trains? > A: Say you want to get an interface change into JDK N and later > decide the change is also desirable and appropriate for the JDK > (N-1) update release and that update release is using the CSR > process. First a CSR should be created from the main bug targeted > at JDK N. Afterward, if a backport of the main bug covering JDK > (N-1) does not already exist, a backport of the main bug covering > JDK (N-1) should be created. Then, a CSR can be created from that > backport. > > https://wiki.openjdk.java.net/display/csr/CSR+FAQs > > HTH, > > -Joe > From manc at google.com Wed Aug 7 19:55:58 2019 From: manc at google.com (Man Cao) Date: Wed, 07 Aug 2019 19:55:58 -0000 Subject: [8u] RFR (S) 8223177: Data race on JvmtiEnvBase::_tag_map in double-checked locking In-Reply-To: <798ff717-a966-2ca2-9f9d-56f8019f78a9@redhat.com> References: <798ff717-a966-2ca2-9f9d-56f8019f78a9@redhat.com> Message-ID: Looks good. Thanks for doing the backport! -Man On Wed, Aug 7, 2019 at 3:53 AM Aleksey Shipilev wrote: > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8223177 > https://hg.openjdk.java.net/jdk/jdk/rev/27c8a2e0b0e5 > > This patch applies to 8u, but does not compile, because regular > OrderAccess methods do not accept > pointers. We need to use the *_ptr_* versions of the same methods and do > casts from void*. > > 8u webrev: > http://cr.openjdk.java.net/~shade/8223177/webrev.8u.01/ > > Testing: tier1 > > -- > Thanks, > -Aleksey > > From halekote at maybank.com.sg Thu Aug 15 09:17:39 2019 From: halekote at maybank.com.sg (HALEKOTE PRABHUKUMAR) Date: Thu, 15 Aug 2019 09:17:39 +0000 Subject: Unable to download OpenJDK 8 Message-ID: <2B5EB13F9EA8134FA3538FFD2518DABB0165DABF6B@SGPWVEXC01MR.mbb.com.sg> Hi Team, Pls assist to provide the link to download OpenJDK 8 or 9 for Windows version (2012). I couldn?t find the exact link to download theOpenJDK. Pls assist. Thanks & regards, Prabhu [cid:image04148f.JPG at 2268fbd0.459825e2][cid:image1ed7c8.JPG at 6aec2db5.4da6c34e] *********************************************************************************************************************************** This email is confidential and may also be legally privileged. If you are not the intended recipient, you should delete it and any record or copy from your system. You should not use, disclose, copy, distribute the message or retain the contents and information for any purpose. Please notify the sender immediately by return e-mail. Opinions, conclusions and other information in this message that do not relate to the official business of Malayan Banking Berhad (incorporated in Malaysia) (UEN: S60FC1376L) or Maybank Singapore Limited (UEN: 201804195C) shall be understood as neither given nor endorsed by it. *********************************************************************************************************************************** From adinn at redhat.com Mon Aug 5 16:29:45 2019 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 05 Aug 2019 16:29:45 -0000 Subject: 8u-aarch64: Backport 8163363: AArch64: Stack size in tools/launcher/Settings.java needs to be adjusted In-Reply-To: References: Message-ID: Apologies: the original note should have been sent to aarch64-port-dev. I have directed this follow up there and bcced 8u-dev to explain why it is disappearing. Also, note changed subject line . On 05/08/2019 17:23, Andrew Dinn wrote: > I would like permission to backport this fix to the > jdk8u-aarch64-shenandoah repo. This fixes the minimum stack size used by > jdk/test/tools/launcher/Settings.java so that it is large enough to > allow the test to pass on AArch64 implementations where it previously > failed. > > The backport requires a minor tweak to the original patch as per the > following webrev: > > http://cr.openjdk.java.net/~adinn/8163363-jdk8u/webrev.00/ > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > -- regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From dheeraj.madhu at gmail.com Fri Aug 23 04:48:14 2019 From: dheeraj.madhu at gmail.com (Dheeraj Joshi) Date: Fri, 23 Aug 2019 10:18:14 +0530 Subject: No subject Message-ID: How long Open JDK 8 is supported by https://openjdk.java.net/ We are currently analyzing impact of upgrading from Java 8 to Java 11. We need to know for how long JDK 8 will get periodic security upgrades and general patches for JDK 8 from https://openjdk.java.net/? RedHat OpenJDK 8 is supported till June 2023 https://access.redhat.com/articles/1299013 AdoptOpenJDK8 is support till September 2023 https://adoptopenjdk.net/support.html We see these different support end dates for OpenJDK from different vendors. We are using open JDK from https://openjdk.java.net/ So we want to know for how long we would receive updates for JDK 8 from OpenJDK community Is there a Road map available for public viewing? Kind Regards Dheeraj Joshi From dheeraj.madhu at gmail.com Fri Aug 23 04:52:21 2019 From: dheeraj.madhu at gmail.com (Dheeraj Joshi) Date: Fri, 23 Aug 2019 10:22:21 +0530 Subject: JDK 8 Updates from OpenJDK community Message-ID: How long Open JDK 8 is supported by https://openjdk.java.net/ We are currently analyzing impact of upgrading from Java 8 to Java 11. We need to know for how long JDK 8 will get periodic security upgrades and general patches for JDK 8 from https://openjdk.java.net/? RedHat OpenJDK 8 is supported till June 2023 https://access.redhat.com/articles/1299013 AdoptOpenJDK8 is support till September 2023 https://adoptopenjdk.net/support.html We see these different support end dates for OpenJDK from different vendors. We are using open JDK from https://openjdk.java.net/ So we want to know for how long we would receive updates for JDK 8 from OpenJDK community Is there a Road map available for public viewing? Kind Regards Dheeraj Joshi From aph at redhat.com Fri Aug 23 08:09:31 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 23 Aug 2019 09:09:31 +0100 Subject: Unable to download OpenJDK 8 In-Reply-To: <2B5EB13F9EA8134FA3538FFD2518DABB0165DABF6B@SGPWVEXC01MR.mbb.com.sg> References: <2B5EB13F9EA8134FA3538FFD2518DABB0165DABF6B@SGPWVEXC01MR.mbb.com.sg> Message-ID: On 8/15/19 10:17 AM, HALEKOTE PRABHUKUMAR wrote: > Pls assist to provide the link to download OpenJDK 8 or 9 for Windows version (2012). > I couldn?t find the exact link to download theOpenJDK. Pls assist. OpenJDK Project Builds are at https://adoptopenjdk.net/upstream.html -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dalibor.topic at oracle.com Fri Aug 23 08:14:23 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 23 Aug 2019 10:14:23 +0200 Subject: Unable to download OpenJDK 8 In-Reply-To: <2B5EB13F9EA8134FA3538FFD2518DABB0165DABF6B@SGPWVEXC01MR.mbb.com.sg> References: <2B5EB13F9EA8134FA3538FFD2518DABB0165DABF6B@SGPWVEXC01MR.mbb.com.sg> Message-ID: <539a2c16-0aec-4baa-9ae6-641e496b0eae@oracle.com> On 15.08.2019 11:17, HALEKOTE PRABHUKUMAR wrote: > Hi Team, > > Pls assist to provide the link to download OpenJDK 8 or 9 for Windows version (2012). Archived Oracle OpenJDK GA releases can be found at https://jdk.java.net/archive/ . cheers, dalibor topic -- Dalibor Topic | Consulting Product Manager Phone: +494089091214 | Mobile: +491737185961 | Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann Oracle is committed to developing practices and products that help protect the environment From aph at redhat.com Fri Aug 23 08:17:57 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 23 Aug 2019 09:17:57 +0100 Subject: JDK 8 Updates from OpenJDK community In-Reply-To: References: Message-ID: <2dc4a25c-a2ed-f243-2ddc-9ef2d8e4cc87@redhat.com> On 8/23/19 5:52 AM, Dheeraj Joshi wrote: > How long Open JDK 8 is supported by https://openjdk.java.net/ We are > currently analyzing impact of upgrading from Java 8 to Java 11. We > need to know for how long JDK 8 will get periodic security upgrades > and general patches for JDK 8 from https://openjdk.java.net/? > > RedHat OpenJDK 8 is supported till June 2023 > https://access.redhat.com/articles/1299013 AdoptOpenJDK8 is support > till September 2023 https://adoptopenjdk.net/support.html That sounds about right. It means that public updates will be available for at least that long. It may well be that some organization will volunteer to support it for longer. > We see these different support end dates for OpenJDK from different > vendors. We are using open JDK from https://openjdk.java.net/ So we > want to know for how long we would receive updates for JDK 8 from > OpenJDK community > > Is there a Road map available for public viewing? That is the road map! JDK 8 is the legacy version. I would advise all individuals and organizations to have a transition plan to a later JDK version in place well before 2023. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Fri Aug 23 08:18:54 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 23 Aug 2019 09:18:54 +0100 Subject: Unable to download OpenJDK 8 In-Reply-To: <539a2c16-0aec-4baa-9ae6-641e496b0eae@oracle.com> References: <2B5EB13F9EA8134FA3538FFD2518DABB0165DABF6B@SGPWVEXC01MR.mbb.com.sg> <539a2c16-0aec-4baa-9ae6-641e496b0eae@oracle.com> Message-ID: On 8/23/19 9:14 AM, Dalibor Topic wrote: > Archived Oracle OpenJDK GA releases can be found at > https://jdk.java.net/archive/ . Please do not post messages like this. The GA release does not have security fixes. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dalibor.topic at oracle.com Fri Aug 23 08:26:21 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 23 Aug 2019 10:26:21 +0200 Subject: Unable to download OpenJDK 8 In-Reply-To: References: <2B5EB13F9EA8134FA3538FFD2518DABB0165DABF6B@SGPWVEXC01MR.mbb.com.sg> <539a2c16-0aec-4baa-9ae6-641e496b0eae@oracle.com> Message-ID: <7fe960da-a131-65eb-9df3-d6614ad55c4c@oracle.com> On 23.08.2019 10:18, Andrew Haley wrote: > On 8/23/19 9:14 AM, Dalibor Topic wrote: >> Archived Oracle OpenJDK GA releases can be found at >> https://jdk.java.net/archive/ . > > Please do not post messages like this. The GA release does not have > security fixes. > I would kindly suggest reading the site in question, prior to replying back based on some assumption of its content. ;) https://jdk.java.net/archive/ includes both the archived Oracle OpenJDK 9.0.1 and 9.0.4 update releases as well as a clear warning message on top saying that "WARNING: These older versions of the JDK are provided to help developers debug issues in older systems. They are not updated with the latest security patches and are not recommended for use in production." with the last sentence colorfully distinguished from the rest of the paragraph. Why someone would ask for OpenJDK 9 at this time, I can't really tell, but I believe it's perfectly fine to point them to where they can download it with appropriate warnings attached. cheers, dalibor topic -- Dalibor Topic | Consulting Product Manager Phone: +494089091214 | Mobile: +491737185961 | Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann Oracle is committed to developing practices and products that help protect the environment From aph at redhat.com Fri Aug 23 08:59:38 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 23 Aug 2019 09:59:38 +0100 Subject: Unable to download OpenJDK 8 In-Reply-To: <7fe960da-a131-65eb-9df3-d6614ad55c4c@oracle.com> References: <2B5EB13F9EA8134FA3538FFD2518DABB0165DABF6B@SGPWVEXC01MR.mbb.com.sg> <539a2c16-0aec-4baa-9ae6-641e496b0eae@oracle.com> <7fe960da-a131-65eb-9df3-d6614ad55c4c@oracle.com> Message-ID: On 8/23/19 9:26 AM, Dalibor Topic wrote: > > On 23.08.2019 10:18, Andrew Haley wrote: >> On 8/23/19 9:14 AM, Dalibor Topic wrote: >>> Archived Oracle OpenJDK GA releases can be found at >>> https://jdk.java.net/archive/ . >> >> Please do not post messages like this. The GA release does not have >> security fixes. > > I would kindly suggest reading the site in question, prior to replying > back based on some assumption of its content. ; Kindly suggest what you will, but I will reply that it's terrible advice for anyone who wants an OpenJDK to actually use. It is clear from the OP's message that use, as opposed to mere curiosity, is what they had in mind. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dalibor.topic at oracle.com Fri Aug 23 09:29:14 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 23 Aug 2019 11:29:14 +0200 Subject: JDK 8 Updates from OpenJDK community In-Reply-To: <2dc4a25c-a2ed-f243-2ddc-9ef2d8e4cc87@redhat.com> References: <2dc4a25c-a2ed-f243-2ddc-9ef2d8e4cc87@redhat.com> Message-ID: <7088b718-46ab-f97f-621f-1bfd7fb31f9f@oracle.com> On 23.08.2019 10:17, Andrew Haley wrote: > That is the road map! JDK 8 is the legacy version. I would advise all > individuals and organizations to have a transition plan to a later JDK > version in place well before 2023. As part of making such transition plans, I'd also suggest starting to regularly test with current feature releases, even if one doesn't intend to run their code on JDK 12 or later for now, in order to get a sense of the scope and effect of changes after JDK 11. cheers, dalibor topic -- Dalibor Topic | Consulting Product Manager Phone: +494089091214 | Mobile: +491737185961 | Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann Oracle is committed to developing practices and products that help protect the environment From neugens at redhat.com Fri Aug 23 09:41:44 2019 From: neugens at redhat.com (Mario Torre) Date: Fri, 23 Aug 2019 11:41:44 +0200 Subject: RFC: backport of JDK-8222980: Upgrade IANA Language Subtag Registry to Version 2019-04-03 In-Reply-To: References: Message-ID: On Thu, Aug 22, 2019 at 8:56 PM Aleksey Shipilev wrote: > > On 8/22/19 3:01 PM, Mario Torre wrote: > > I would like to backport the following bug: > > https://bugs.openjdk.java.net/browse/JDK-8222980 > > > > To jdk8u-dev. > > > > Patch applies cleanly, compiles and passes its test. > > I am confused, why are you asking here? You can proceed to label the issue and put "Fix Request", as > per step 6 in checklist: > https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix Merely CC'ing in triple copy to keep bureaucracy happy ;) > There is apparently jdk8u-fix-request, but no "Fix request" comment. Added. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From aph at redhat.com Fri Aug 23 09:46:26 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 23 Aug 2019 10:46:26 +0100 Subject: JDK 8 Updates from OpenJDK community In-Reply-To: <7088b718-46ab-f97f-621f-1bfd7fb31f9f@oracle.com> References: <2dc4a25c-a2ed-f243-2ddc-9ef2d8e4cc87@redhat.com> <7088b718-46ab-f97f-621f-1bfd7fb31f9f@oracle.com> Message-ID: <88e0b88f-cb01-4dd6-0751-b825e4a91cc4@redhat.com> On 8/23/19 10:29 AM, Dalibor Topic wrote: > > On 23.08.2019 10:17, Andrew Haley wrote: > >> That is the road map! JDK 8 is the legacy version. I would advise all >> individuals and organizations to have a transition plan to a later JDK >> version in place well before 2023. > > As part of making such transition plans, I'd also suggest starting to > regularly test with current feature releases, even if one doesn't intend > to run their code on JDK 12 or later for now, in order to get a sense of > the scope and effect of changes after JDK 11. I fully and enthusiastically second this suggestion. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Fri Aug 23 11:36:25 2019 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 23 Aug 2019 12:36:25 +0100 Subject: [8u] RFR 8205507: jdk/javax/xml/crypto/dsig/GenerationTests.java timed out In-Reply-To: References: Message-ID: On Mon, 5 Aug 2019 at 23:26, Martin Balao wrote: > > Hi, > > I'd like to have a review for the jdk8u backport of JDK-8205507 [1]: > > * > http://cr.openjdk.java.net/~mbalao/webrevs/8205507/8205507.webrev.jdk8u.jdk.00/ > > Minor changes in GenerationTests::getCachedKeys function were required. > > Testing: javax/xml/crypto/dsig/GenerationTests.java passed. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8205507 It would help the review process,in such cases,if you could elaborate on the 'minor changes' required and why. Comparing the two changesets, it seems the case statement gets removed in 11u by JDK-8177334. As that change is also marked for Oracle 8u231, it doesn't make sense to me to backport this change first and create more work for the backporting of 8177334. Once 8177334 is in, this should become close to a clean backport. -- 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 bourges.laurent at gmail.com Fri Aug 23 12:12:55 2019 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 23 Aug 2019 14:12:55 +0200 Subject: How to import patch from jdk/jdk In-Reply-To: <6bb2170e-0390-20c5-30c4-69b0085a9924@redhat.com> References: <5d12f77e-a674-f989-39f0-e8fa57b6a0b0@redhat.com> <6bb2170e-0390-20c5-30c4-69b0085a9924@redhat.com> Message-ID: Thanks you all for your suggestions, I will practice first with my simple patch on the png image writer (9 -> 8), then try backporting the long patch queue for the Marlin renderer (9, 10, 12, 14 -> 8)... Cheers, Laurent Le mer. 21 ao?t 2019 ? 18:12, Roman Kennke a ?crit : > > On 12/08/2019 09:05, Severin Gehwolf wrote: > >> Hi, > >> > >> On Sat, 2019-08-10 at 16:58 +0200, Laurent Bourg?s wrote: > >>> Ok, > >>> I will use sed on the patch file to fix paths, then I will import it. I > >>> thought such sed script already exist or mercurial or linux patch > command > >>> already manage that. > >> > >> You could try common/bin/unshuffle_patch.sh from JDK 9[1]. > >> > >> Thanks, > >> Severin > >> > >> [1] > http://hg.openjdk.java.net/jdk-updates/jdk9u/file/1b1226687b89/common/bin/unshuffle_patch.sh > >> > > > > If the patch was committed to jdk/jdk or jdk-updates/jdk11 (as opposed > > to being an older jdk9 patch), it usually needs both the jdk11 script > > [0] (to move the files back into their subrepos, jdk11->jdk9) and the > > jdk9 script [1] (to get rid of the modules, jdk9->jdk8). Both scripts > > need data files from the same directory, so checking out the repos is > > probably the easiest option. > > > > All this file movement is a major PITA. > > > > [0] > > > https://hg.openjdk.java.net/jdk-updates/jdk11u/file/tip/bin/unshuffle_patch.sh > > [1] > > > https://hg.openjdk.java.net/jdk-updates/jdk9u/file/tip/common/bin/unshuffle_patch.sh > > > > It looks like it should be possible to use this in conjunction with hg > transplant --filter to transplant patches between versions. > > https://www.mercurial-scm.org/wiki/TransplantExtension > > Roman > > From zgu at redhat.com Fri Aug 23 12:13:59 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 23 Aug 2019 08:13:59 -0400 Subject: [8u] 8178870: instrumentation.retransformClasses cause coredump In-Reply-To: <0bfedafb-f31c-6278-31da-56cb4abc1d34@redhat.com> References: <6d646175-68e2-b280-6475-cd97f2e5d438@redhat.com> <7003c233-d891-b11b-3426-f9b6f7de2d8f@redhat.com> <0bfedafb-f31c-6278-31da-56cb4abc1d34@redhat.com> Message-ID: Hi Aleksey, On 8/20/19 11:57 AM, Aleksey Shipilev wrote: > On 8/20/19 5:44 PM, Zhengyu Gu wrote: >> On 8/20/19 10:23 AM, Aleksey Shipilev wrote: >>> On 8/19/19 9:14 PM, Zhengyu Gu wrote: >>>> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8178870-8u/webrev.00/ >>> >>> Backport looks good. > > I just noticed your other backport has the new definition of get_ik here: > > http://cr.openjdk.java.net/~zgu/JDK-8155951-8u/webrev.00/src/share/vm/prims/jvmtiRedefineClasses.cpp.sdiff.html > > Maybe you want to commit them in more convenient order to get the definition in for this backport. Nice catch! Updated webrev to reflect the order and eliminate the extra get_ik(). Webrev: http://cr.openjdk.java.net/~zgu/JDK-8178870-8u/webrev.01/ Thanks, -Zhengyu > From rkennke at redhat.com Fri Aug 23 12:33:47 2019 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 23 Aug 2019 14:33:47 +0200 Subject: RFR: Backport: 8216549: Mismatched unsafe access to non escaping object fails Message-ID: <294433c3-a28e-7c49-24d0-40294e1d55be@redhat.com> This backports: https://bugs.openjdk.java.net/browse/JDK-8216549 Original change: hg.openjdk.java.net/jdk/jdk12/rev/f0490430ef7a JDK11u backport: http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/d5fb6ad4203b In order to make it work on 8u, I needed the extra change in library_call.cpp. Thanks Roland who helped with this. Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8216549-8u/webrev.00/ Testing: The new testcase fails without the fix, and passes with the fix. tier1 & tier2 show no regressions. Can I please get a review? Thanks, Roman From dheeraj.madhu at gmail.com Fri Aug 23 12:23:28 2019 From: dheeraj.madhu at gmail.com (Dheeraj Joshi) Date: Fri, 23 Aug 2019 17:53:28 +0530 Subject: JDK 8 Updates from OpenJDK community In-Reply-To: <2dc4a25c-a2ed-f243-2ddc-9ef2d8e4cc87@redhat.com> References: <2dc4a25c-a2ed-f243-2ddc-9ef2d8e4cc87@redhat.com> Message-ID: Thanks Andrew, That means as community openjdk doesn't have road map and as long as some org like jboss or adoptopenjdk provides fix to JDK 8 it will be available. Kind Regards Dheeraj Joshi On Fri, Aug 23, 2019 at 1:48 PM Andrew Haley wrote: > On 8/23/19 5:52 AM, Dheeraj Joshi wrote: > > > How long Open JDK 8 is supported by https://openjdk.java.net/ We are > > currently analyzing impact of upgrading from Java 8 to Java 11. We > > need to know for how long JDK 8 will get periodic security upgrades > > and general patches for JDK 8 from https://openjdk.java.net/? > > > > RedHat OpenJDK 8 is supported till June 2023 > > https://access.redhat.com/articles/1299013 AdoptOpenJDK8 is support > > till September 2023 https://adoptopenjdk.net/support.html > > That sounds about right. It means that public updates will be > available for at least that long. It may well be that some > organization will volunteer to support it for longer. > > > We see these different support end dates for OpenJDK from different > > vendors. We are using open JDK from https://openjdk.java.net/ So we > > want to know for how long we would receive updates for JDK 8 from > > OpenJDK community > > > > Is there a Road map available for public viewing? > > That is the road map! JDK 8 is the legacy version. I would advise all > individuals and organizations to have a transition plan to a later JDK > version in place well before 2023. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From aph at redhat.com Fri Aug 23 13:53:45 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 23 Aug 2019 14:53:45 +0100 Subject: JDK 8 Updates from OpenJDK community In-Reply-To: References: <2dc4a25c-a2ed-f243-2ddc-9ef2d8e4cc87@redhat.com> Message-ID: <94ecd35c-fa09-17d4-b270-04c3731292be@redhat.com> On 8/23/19 1:23 PM, Dheeraj Joshi wrote: > That means as community openjdk doesn't have road map Absolutely not. It means no such thing, and there is no way you can place such an implication on what I wrote. The current road map is that I will continue to lead this project until 2023. > and as long as some org like jboss or adoptopenjdk provides fix to > JDK 8 it will be available. Well, yes, as long as someone maintains JDK8 it will be maintained. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From verghese at amazon.com Fri Aug 23 17:43:13 2019 From: verghese at amazon.com (Verghese, Clive) Date: Fri, 23 Aug 2019 17:43:13 +0000 Subject: [8u] RFR 8229501: jdk/test/lib/testlibrary/ClassFileInstaller.java should match hotspot//test/testlibrary version In-Reply-To: <01cc5f7a-01ed-d712-883e-0cec87c09e8b@redhat.com> References: <0E64BD39-BFDA-4506-BD8B-7B63A7BBD0C8@amazon.com> <01cc5f7a-01ed-d712-883e-0cec87c09e8b@redhat.com> Message-ID: Hi Andrew Hughes, Thank you for the detailed feedback, I will update the webrev with the bug id's. Regards, Clive Verghese ?On 8/21/19, 8:58 AM, "Andrew John Hughes" wrote: On 13/08/2019 23:12, Verghese, Clive wrote: > Hi, > > Requesting review for webrev : http://cr.openjdk.java.net/~phh/8229501/webrev.8u.00/ > JBS Issue : https://bugs.openjdk.java.net/browse/JDK-8229501 > Email discussion : https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010029.html > > hotspot/test/testlibrary/ClassFileInstaller.java and jdk/test/lib/testlibrary/ClassFileInstaller were merged as part of the JDK10 repo merge. For 8u, we should sync the JDK version with the Hotspot version in order to facilitate backports of patches such as the one for JDK-8216401 that assume the merged version. > > Testing > Validated that the test depending on ClassFileInstaller pass. > > > Regards, > Clive Verghese > This appears to just be the result of: $ diff -u hotspot/test/testlibrary/ClassFileInstaller.java jdk/test/lib/testlibrary/ClassFileInstaller.java I don't think a code dump with a unique bug ID is the correct way to fix this. The actual changes come from two HotSpot changes: changeset: 8710:4141ef4c8ba8 user: vaibhav date: Thu Jul 26 06:16:09 2018 -0400 summary: 8189762: [TESTBUG] Create tests for JDK-8146115 container awareness and resource configuration changeset: 4665:43083e670adf user: coleenp date: Mon May 13 15:37:08 2013 -0400 summary: 8005056: NPG: Crash after redefining java.lang.Object The appropriate course of action here is to apply the test/testlibrary/ClassFileInstaller.java changes from these changesets to the copy under test/lib/testlibrary/ClassFileInstaller.java under their appropriate bug IDs, as should have been done to begin with and, I presume, is intended for future changes to keep these in sync. This then associates the changes with their original review and motivation. I just tried this with 8189762 and it applies cleanly, leaving just the changes in 8005056 as the diff. I'd prefer they were separate changesets, but the current webrev could be used with these two bug IDs rather than 8229501. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From zgu at redhat.com Fri Aug 23 20:32:13 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 23 Aug 2019 16:32:13 -0400 Subject: [8u] RFR 8225141: Better handling of classes in error state by fast class initialization checks Message-ID: I would like to backport this patch to 8u, as it is in Oracle's 8u. The patch does not apply cleanly, due to line shifts and different implementation of set_initialization_state_and_notify() in 8u. Original bug: https://bugs.openjdk.java.net/browse/JDK-8225141 Original webrev: http://cr.openjdk.java.net/~vlivanov/8225141/webrev.00/ Original code review thread: https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-May/034062.html 8u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8225141-8u/webrev.00/index.html Thanks, -Zhengyu From sgehwolf at redhat.com Mon Aug 26 13:23:40 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 26 Aug 2019 15:23:40 +0200 Subject: [8u] RFR: 8218780: Update MUSCLE PCSC-Lite header files Message-ID: Hi, Could I please get a review of this MUSCLE header files update in OpenJDK 8u? I'd like to backport this bug as it's also going to be in Oracle JDK 8u231 (equiv to OpenJDK 8u232) as well. The OpenJDK 11 patch applies almost cleanly post path-unshuffelling. Changes which didn't apply were a copyright header update in pcsc.c. I've omitted these. Bug: https://bugs.openjdk.java.net/browse/JDK-8218780 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8218780/jdk8/01/webrev/ JDK 11u changeset: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/0bcc59a50c88 There is going to be a follow-up fix adding back COPYING via JDK-8226607 which I propose for backport to OpenJDK 8u as well. Testing: smartcardio sanity and build on Linux x86_64 (Fedora 30 and RHEL 6) Thanks to Aleksey Shipilev who helped test this patch. Thoughts? Thanks, Severin From sgehwolf at redhat.com Mon Aug 26 13:24:11 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 26 Aug 2019 15:24:11 +0200 Subject: [8u] RFR: 8226607: Inconsistent info between pcsclite.md and MUSCLE headers Message-ID: Hi, Could I get a review of this follow-up fix for an 8u backport (JDK- 8218780)? This follow-up re-adds a COPYING file to the MUSCLE pcsc library header files removed by the JDK-8218780 backport. The patch differs from the version in JDK 11 since there is no pcsclite.md file in OpenJDK 8u. Bug: https://bugs.openjdk.java.net/browse/JDK-8226607 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226607/jdk8/01/webrev/ JDK 11u changeset: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/9e304e99cbb2 I intend to push this fix together with JDK-8218780 once it passed review and got approved. Thoughts? Thanks, Severin From stooke at redhat.com Mon Aug 26 13:48:38 2019 From: stooke at redhat.com (Simon Tooke) Date: Mon, 26 Aug 2019 09:48:38 -0400 Subject: RFC: backport of JDK-8215756: Memory leaks in the AWT on macOS In-Reply-To: <76d8aadc-0842-1d55-d58a-7ec761bf68a3@redhat.com> References: <5fe51887-894b-af74-8b80-9770f8c4e78a@redhat.com> <54e7c8cb-8c20-1559-ce7d-80772960704c@redhat.com> <7e5b8ed8-750e-58a6-ed12-d70d2d2a7171@redhat.com> <76d8aadc-0842-1d55-d58a-7ec761bf68a3@redhat.com> Message-ID: <0225660f-ef04-2b2b-342c-affc09e43064@redhat.com> On 8/2/2019 4:42 AM, Aleksey Shipilev wrote: > On 7/31/19 7:12 PM, Simon Tooke wrote: >> http://cr.openjdk.java.net/~stooke/webrevs/jdk8215756-jdk8u.01/ >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8215756 >> Original patch: http://hg.openjdk.java.net/jdk/client/rev/64e7a73195c1 > Looks okay. It seems webrev was generated in default mode that omits whitespace diffs. Try with -b. I've redone the webrev with -b, but it didn't make much difference.? Also, I updated the copyright one one of the files. new webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8215756-jdk8u/02/jdk.02/ Thanks, -Simon From shade at redhat.com Mon Aug 26 13:51:54 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 26 Aug 2019 15:51:54 +0200 Subject: RFC: backport of JDK-8215756: Memory leaks in the AWT on macOS In-Reply-To: <0225660f-ef04-2b2b-342c-affc09e43064@redhat.com> References: <5fe51887-894b-af74-8b80-9770f8c4e78a@redhat.com> <54e7c8cb-8c20-1559-ce7d-80772960704c@redhat.com> <7e5b8ed8-750e-58a6-ed12-d70d2d2a7171@redhat.com> <76d8aadc-0842-1d55-d58a-7ec761bf68a3@redhat.com> <0225660f-ef04-2b2b-342c-affc09e43064@redhat.com> Message-ID: On 8/26/19 3:48 PM, Simon Tooke wrote: > new webrev: > http://cr.openjdk.java.net/~stooke/webrevs/jdk-8215756-jdk8u/02/jdk.02/ Looks fine to me. -- Thanks, -Aleksey From sgehwolf at redhat.com Mon Aug 26 15:54:04 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 26 Aug 2019 17:54:04 +0200 Subject: [8u] RFR: 8213734: SAXParser.parse(File, ..) does not close resources when Exception occurs. Message-ID: <0a64931ab640afd557f4bd46aa7bb05512bc79d6.camel@redhat.com> Hi, Please review this 8u backport. The OpenJDK 11u patch does not apply cleanly after path-reshuffeling due to a) test and code for jaxp are split in JDK 8 b) Some rejects in comments - copyright and last modified date. I've omitted rejected comments. I can manually add them if that's preferred. See below. Bug: https://bugs.openjdk.java.net/browse/JDK-8213734 webrevs: jdk: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8213734/jdk8/jdk/01/webrev/ jaxp: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8213734/jdk8/jaxp/01/webrev/ Testing: tier1 on Linux x86_64. javax/xml/jaxp tests. New test on Windows without the fix fails and passes with it. Thanks to Simon Tooke who helped testing this patch on Windows. Rejects: $ cat src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java.rej --- XMLEntityManager.java +++ XMLEntityManager.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2009, 2017, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2009, 2018, Oracle and/or its affiliates. All rights reserved. */ /* * Licensed to the Apache Software Foundation (ASF) under one or more @@ -89,7 +89,7 @@ * @author K.Venugopal SUN Microsystems * @author Neeraj Bajaj SUN Microsystems * @author Sunitha Reddy SUN Microsystems - * @LastModified: Oct 2017 + * @LastModified: Nov 2018 */ public class XMLEntityManager implements XMLComponent, XMLEntityResolver { Thoughts? Thanks, Severin From ali.ince at gmail.com Mon Aug 26 22:34:40 2019 From: ali.ince at gmail.com (Ali Ince) Date: Mon, 26 Aug 2019 23:34:40 +0100 Subject: [8u] PATCH: Bundle correct DLLs for later versions of VS Message-ID: Hi All, This is a third attempt of my patch, following my initial [1] "Prevent MSDOS8.3 named DLL in built image" and a larger one with more changes around getting VS2017 build warnings to a minimum [2]. The latter one did bring several upstream changes (with local modifications) into the patch which is probably not the desired approach. Here is a downsized version of the changes, which include the following fixes - which are only applicable to jdk8u. - Prevent MSDOS8.3 named DLL in built image; vcruntime140.dll, which is part of VS2017 built images, 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. - Copy other required MSVC DLLs, other than MSVCR_DLL into the JDK binary folder; VS2010 builds of JDK only depend on msvcr100.dll, and this is place both under 'bin' and 'jre\bin' directories in the built image. However, builds with later versions of VS depend on additional redistributable DLLs. For VS2013, the dependent DLLs are both msvcr120.dll and msvcp120.dll; and for VS2017, they are vcruntime140.dll, msvcp140.dll and also the several api-ms-win*.dll which are usually referred as UCRT DLLs. It should be noted that these mentioned DLLs are already present in 'jre\bin' directory and it is required for them to be placed in the 'jdk' directory as well for the executables (javac.exe, etc.) to be able resolve them successfully. This is similar to the requirement of msvcr100.dll to be placed in both directories when built with VS2010. - Add recent MSVC versions. I would be grateful if someone could sponsor this change for me. Thanks. Ali [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-March/009012.html [2] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-June/009668.html PATCH: --------------- # cd . && hg diff diff -r 2cd484c5b7f8 common/autoconf/toolchain_windows.m4 --- a/common/autoconf/toolchain_windows.m4 Thu Aug 22 17:51:13 2019 +0100 +++ b/common/autoconf/toolchain_windows.m4 Mon Aug 26 23:00:21 2019 +0100 @@ -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 # cd ./hotspot && hg diff diff -r bf9503046dd4 make/windows/makefiles/compile.make --- a/make/windows/makefiles/compile.make Fri Dec 14 11:22:26 2018 +0100 +++ b/make/windows/makefiles/compile.make Mon Aug 26 23:00:22 2019 +0100 @@ -159,6 +159,15 @@ !if "$(MSC_VER)" == "1913" COMPILER_NAME=VS2017 !endif +!if "$(MSC_VER)" == "1914" +COMPILER_NAME=VS2017 +!endif +!if "$(MSC_VER)" == "1915" +COMPILER_NAME=VS2017 +!endif +!if "$(MSC_VER)" == "1916" +COMPILER_NAME=VS2017 +!endif !endif # By default, we do not want to use the debug version of the msvcrt.dll file diff -r bf9503046dd4 make/windows/makefiles/sanity.make --- a/make/windows/makefiles/sanity.make Fri Dec 14 11:22:26 2018 +0100 +++ b/make/windows/makefiles/sanity.make Mon Aug 26 23:00:22 2019 +0100 @@ -31,6 +31,10 @@ if "$(MSC_VER)" NEQ "1800" \ if "$(MSC_VER)" NEQ "1900" \ if "$(MSC_VER)" NEQ "1912" \ + if "$(MSC_VER)" NEQ "1913" \ + if "$(MSC_VER)" NEQ "1914" \ + if "$(MSC_VER)" NEQ "1915" \ + if "$(MSC_VER)" NEQ "1916" \ echo *** WARNING *** unrecognized cl.exe version $(MSC_VER) ($(RAW_MSC_VER)). Use FORCE_MSC_VER to override automatic detection. checkLink: @@ -39,4 +43,8 @@ if "$(LD_VER)" NEQ "1300" \ if "$(LD_VER)" NEQ "1400" \ if "$(LD_VER)" NEQ "1412" \ + if "$(LD_VER)" NEQ "1413" \ + if "$(LD_VER)" NEQ "1414" \ + if "$(LD_VER)" NEQ "1415" \ + if "$(LD_VER)" NEQ "1416" \ echo *** WARNING *** unrecognized link.exe version $(LD_VER) ($(RAW_LD_VER)). Use FORCE_LD_VER to override automatic detection. diff -r bf9503046dd4 src/share/vm/runtime/vm_version.cpp --- a/src/share/vm/runtime/vm_version.cpp Fri Dec 14 11:22:26 2018 +0100 +++ b/src/share/vm/runtime/vm_version.cpp Mon Aug 26 23:00:22 2019 +0100 @@ -231,6 +231,12 @@ #define HOTSPOT_BUILD_COMPILER "MS VC++ 15.5 (VS2017)" #elif _MSC_VER == 1913 #define HOTSPOT_BUILD_COMPILER "MS VC++ 15.6 (VS2017)" + #elif _MSC_VER == 1914 + #define HOTSPOT_BUILD_COMPILER "MS VC++ 15.7 (VS2017)" + #elif _MSC_VER == 1915 + #define HOTSPOT_BUILD_COMPILER "MS VC++ 15.8 (VS2017)" + #elif _MSC_VER == 1916 + #define HOTSPOT_BUILD_COMPILER "MS VC++ 15.9 (VS2017)" #else #define HOTSPOT_BUILD_COMPILER "unknown MS VC++:" XSTR(_MSC_VER) #endif # cd ./jdk && hg diff diff -r 1417d2539c57 make/Images.gmk --- a/make/Images.gmk Fri Aug 23 20:14:36 2019 +0000 +++ b/make/Images.gmk Mon Aug 26 23:00:23 2019 +0100 @@ -130,10 +130,22 @@ hsdb$(EXE_SUFFIX) endif +# Build a list of platform DLL's to keep in the built image folder +# Note that JDK image built on VS2010 requires only MSVCR_DLL to be present, but this has +# changed with later versions and we require more DLL's to be copied over JDK image bin +# folder +ifeq ($(OPENJDK_TARGET_OS), windows) + KEEP_MSVC_DLLS = $(MSVCR_DLL) $(MSVCP_DLL) + + ifneq ($(UCRT_DLL_DIR), ) + KEEP_MSVC_DLLS += $(wildcard $(UCRT_DLL_DIR)/*.dll) + endif +endif + WINDOWS_JDK_BIN_FILES = \ $(EXE_SUFFIX) \ $(LIBRARY_PREFIX)jli$(SHARED_LIBRARY_SUFFIX) \ - $(notdir $(MSVCR_DLL)) + $(notdir $(KEEP_MSVC_DLLS)) WINDOWS_JDKJRE_BIN_FILES := \ $(LIBRARY_PREFIX)attach$(SHARED_LIBRARY_SUFFIX) \ @@ -649,7 +661,7 @@ ifneq ($(POST_STRIP_CMD), ) ifeq ($(OPENJDK_TARGET_OS), windows) - EXEC_LIST_BIN := $(filter-out %$(notdir $(MSVCR_DLL)), $(filter %.exe %.dll, $(ALL_BIN_LIST))) + EXEC_LIST_BIN := $(filter-out %$(notdir $(KEEP_MSVC_DLLS)), $(filter %.exe %.dll, $(ALL_BIN_LIST))) else # Find all executables in JDK_OUTPUTDIR since they exist when this makefile is parsed EXEC_LIST_BIN := $(shell $(FILE) `$(FIND) $(JDK_OUTPUTDIR)/bin -type f -name \*$(EXE_SUFFIX) ! -name \*.debuginfo` \ # exit code 0 From zgu at redhat.com Tue Aug 27 13:39:11 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 27 Aug 2019 09:39:11 -0400 Subject: [8u] 8222108: Reduce minRefreshTime for updating remote printer list on Windows Message-ID: <3b26ee23-1124-7538-6ba0-d5f021fdd12e@redhat.com> I would like to backport this patch to 8u, as it is in Oracle's 8u. The patch does not apply cleanly. In early backports, there were conflicts and we kept 8u code in old styles. E.g. RemotePrinterChangeListener still inherits from Thread, instead of implementing Runnable in new code. Original bug: https://bugs.openjdk.java.net/browse/JDK-8222108 Original code review threads: Code review threads: http://mail.openjdk.java.net/pipermail/2d-dev/2019-June/010153.html http://mail.openjdk.java.net/pipermail/2d-dev/2019-July/010169.html http://mail.openjdk.java.net/pipermail/2d-dev/2019-August/010235.html 8u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8222108-8u/webrev.00/ Thanks, -Zhengyu From verghese at amazon.com Tue Aug 27 18:32:04 2019 From: verghese at amazon.com (Verghese, Clive) Date: Tue, 27 Aug 2019 18:32:04 +0000 Subject: [8u] RFR 8229501: jdk/test/lib/testlibrary/ClassFileInstaller.java should match hotspot//test/testlibrary version In-Reply-To: References: <0E64BD39-BFDA-4506-BD8B-7B63A7BBD0C8@amazon.com> <01cc5f7a-01ed-d712-883e-0cec87c09e8b@redhat.com> Message-ID: Hi Andrew, We have updated the webrev with the bug ids, http://cr.openjdk.java.net/~phh/8189762/webrev.8u.00/ Testing Validated that the test depending on ClassFileInstaller pass. Regards, Clive Verghese ?On 8/23/19, 10:43 AM, "jdk8u-dev on behalf of Verghese, Clive" wrote: Hi Andrew Hughes, Thank you for the detailed feedback, I will update the webrev with the bug id's. Regards, Clive Verghese On 8/21/19, 8:58 AM, "Andrew John Hughes" wrote: On 13/08/2019 23:12, Verghese, Clive wrote: > Hi, > > Requesting review for webrev : http://cr.openjdk.java.net/~phh/8229501/webrev.8u.00/ > JBS Issue : https://bugs.openjdk.java.net/browse/JDK-8229501 > Email discussion : https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010029.html > > hotspot/test/testlibrary/ClassFileInstaller.java and jdk/test/lib/testlibrary/ClassFileInstaller were merged as part of the JDK10 repo merge. For 8u, we should sync the JDK version with the Hotspot version in order to facilitate backports of patches such as the one for JDK-8216401 that assume the merged version. > > Testing > Validated that the test depending on ClassFileInstaller pass. > > > Regards, > Clive Verghese > This appears to just be the result of: $ diff -u hotspot/test/testlibrary/ClassFileInstaller.java jdk/test/lib/testlibrary/ClassFileInstaller.java I don't think a code dump with a unique bug ID is the correct way to fix this. The actual changes come from two HotSpot changes: changeset: 8710:4141ef4c8ba8 user: vaibhav date: Thu Jul 26 06:16:09 2018 -0400 summary: 8189762: [TESTBUG] Create tests for JDK-8146115 container awareness and resource configuration changeset: 4665:43083e670adf user: coleenp date: Mon May 13 15:37:08 2013 -0400 summary: 8005056: NPG: Crash after redefining java.lang.Object The appropriate course of action here is to apply the test/testlibrary/ClassFileInstaller.java changes from these changesets to the copy under test/lib/testlibrary/ClassFileInstaller.java under their appropriate bug IDs, as should have been done to begin with and, I presume, is intended for future changes to keep these in sync. This then associates the changes with their original review and motivation. I just tried this with 8189762 and it applies cleanly, leaving just the changes in 8005056 as the diff. I'd prefer they were separate changesets, but the current webrev could be used with these two bug IDs rather than 8229501. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From hohensee at amazon.com Tue Aug 27 20:05:16 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 27 Aug 2019 20:05:16 +0000 Subject: [8u] RFR 8229501: jdk/test/lib/testlibrary/ClassFileInstaller.java should match hotspot//test/testlibrary version In-Reply-To: References: <0E64BD39-BFDA-4506-BD8B-7B63A7BBD0C8@amazon.com> <01cc5f7a-01ed-d712-883e-0cec87c09e8b@redhat.com> Message-ID: There's perhaps some confusion here. The file to be patched is in the jdk repo, not the hotspot repo, i.e., jdk/test/lib/testlibrary/ClassFileInstaller.java, not hotspot/test/testlibrary/ClassFileInstaller.java. The former is quite small and contains only a "main" method, while the latter is much bigger with much more functionality. The patch for https://bugs.openjdk.java.net/browse/JDK-8005056 went into hs25 and therefore can't be left over after 8189762. I.e., it patches a few lines in the hotspot version, vis @@ -45,7 +45,9 @@ // Create the class file's package directory Path p = Paths.get(pathName); - Files.createDirectories(p.getParent()); + if (pathName.contains("/")) { + Files.createDirectories(p.getParent()); + } // Create the class file Files.copy(is, p, StandardCopyOption.REPLACE_EXISTING); } The above patched code is what's in the current jdk8u version of hotspot/test/testlibrary/ClassFileInstaller.java. "hg log" on jdk8u/hotspot/test/testlibrary/ClassFileInstaller produces changeset: 8710:4141ef4c8ba8 user: vaibhav date: Thu Jul 26 06:16:09 2018 -0400 summary: 8189762: [TESTBUG] Create tests for JDK-8146115 container awareness and resource configuration changeset: 4665:43083e670adf user: coleenp date: Mon May 13 15:37:08 2013 -0400 summary: 8005056: NPG: Crash after redefining java.lang.Object changeset: 4202:1b0dc9f87e75 parent: 4175:1048edb5434a user: mgerdin date: Tue Feb 19 18:45:49 2013 +0100 summary: 8006753: fix failed for JDK-8002415 White box testing API for HotSpot The 8189762 backport patch is at http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/4141ef4c8ba8, and updates the hotspot version to be identical to what's in jdk10 and tip. There is no change to the jdk version at jdk/test/lib/testlibrary/ClassFileInstaller.java. We therefore want to update the jdk version to be the same as the hotspot version, but 8189762 already has a jdk8u backport issue associated with it. Shall we add an openjdk8u232 backport to it that patches the jdk version of ClassFileInstaller.java? We thought that would be confusing, so we filed a new bug to do so, namely https://bugs.openjdk.java.net/browse/JDK-8229501. Which would you prefer? Thanks, Paul ?On 8/27/19, 11:33 AM, "jdk8u-dev on behalf of Verghese, Clive" wrote: Hi Andrew, We have updated the webrev with the bug ids, http://cr.openjdk.java.net/~phh/8189762/webrev.8u.00/ Testing Validated that the test depending on ClassFileInstaller pass. Regards, Clive Verghese On 8/23/19, 10:43 AM, "jdk8u-dev on behalf of Verghese, Clive" wrote: Hi Andrew Hughes, Thank you for the detailed feedback, I will update the webrev with the bug id's. Regards, Clive Verghese On 8/21/19, 8:58 AM, "Andrew John Hughes" wrote: On 13/08/2019 23:12, Verghese, Clive wrote: > Hi, > > Requesting review for webrev : http://cr.openjdk.java.net/~phh/8229501/webrev.8u.00/ > JBS Issue : https://bugs.openjdk.java.net/browse/JDK-8229501 > Email discussion : https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010029.html > > hotspot/test/testlibrary/ClassFileInstaller.java and jdk/test/lib/testlibrary/ClassFileInstaller were merged as part of the JDK10 repo merge. For 8u, we should sync the JDK version with the Hotspot version in order to facilitate backports of patches such as the one for JDK-8216401 that assume the merged version. > > Testing > Validated that the test depending on ClassFileInstaller pass. > > > Regards, > Clive Verghese > This appears to just be the result of: $ diff -u hotspot/test/testlibrary/ClassFileInstaller.java jdk/test/lib/testlibrary/ClassFileInstaller.java I don't think a code dump with a unique bug ID is the correct way to fix this. The actual changes come from two HotSpot changes: changeset: 8710:4141ef4c8ba8 user: vaibhav date: Thu Jul 26 06:16:09 2018 -0400 summary: 8189762: [TESTBUG] Create tests for JDK-8146115 container awareness and resource configuration changeset: 4665:43083e670adf user: coleenp date: Mon May 13 15:37:08 2013 -0400 summary: 8005056: NPG: Crash after redefining java.lang.Object The appropriate course of action here is to apply the test/testlibrary/ClassFileInstaller.java changes from these changesets to the copy under test/lib/testlibrary/ClassFileInstaller.java under their appropriate bug IDs, as should have been done to begin with and, I presume, is intended for future changes to keep these in sync. This then associates the changes with their original review and motivation. I just tried this with 8189762 and it applies cleanly, leaving just the changes in 8005056 as the diff. I'd prefer they were separate changesets, but the current webrev could be used with these two bug IDs rather than 8229501. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From alvdavi at amazon.com Wed Aug 28 01:41:40 2019 From: alvdavi at amazon.com (Alvarez, David) Date: Wed, 28 Aug 2019 01:41:40 +0000 Subject: [8u] RFR 8217731: Font rendering and glyph spacing changed from jdk-8 to jdk-11 Message-ID: <77162812-51BD-473C-AC76-7EFDCEB3A483@amazon.com> Hi, I would like to request a review and jdk8u-fix-yes for this backport related to the interpreter mode to use in Freetype. Bug: https://bugs.openjdk.java.net/browse/JDK-8217731 https://hg.openjdk.java.net/jdk/jdk/rev/18629738b64b The problem happens when using newer versions of Freetype. Webrev: http://cr.openjdk.java.net/~alvdavi/webrevs/8217731/webrev.8u.00/ It is an almost clean backport, only the imports and file name had been changed. I'm sending this for jdk11u too. -- David From neugens at redhat.com Wed Aug 28 08:35:09 2019 From: neugens at redhat.com (Mario Torre) Date: Wed, 28 Aug 2019 10:35:09 +0200 Subject: [JFR Backport] New target version in Jira Message-ID: Hi all! I just wanted to share a quick note, we now have a new "version" in Jira: openjdk8u-jfr-incubator I'm going now through the bugs that we pushed that affected only our incubator and mark them as such, for the future can you please use this version for anything that is specific to the incubator? Thanks! Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From sgehwolf at redhat.com Wed Aug 28 09:23:58 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 28 Aug 2019 11:23:58 +0200 Subject: [8u] RFR 8217731: Font rendering and glyph spacing changed from jdk-8 to jdk-11 In-Reply-To: <77162812-51BD-473C-AC76-7EFDCEB3A483@amazon.com> References: <77162812-51BD-473C-AC76-7EFDCEB3A483@amazon.com> Message-ID: <85611a26da35636174ac021812b141088a483f04.camel@redhat.com> Hi David, On Wed, 2019-08-28 at 01:41 +0000, Alvarez, David wrote: > Hi, > > I would like to request a review and jdk8u-fix-yes for this backport related > to the interpreter mode to use in Freetype. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8217731 > https://hg.openjdk.java.net/jdk/jdk/rev/18629738b64b > > The problem happens when using newer versions of Freetype. > > Webrev: > http://cr.openjdk.java.net/~alvdavi/webrevs/8217731/webrev.8u.00/ > > It is an almost clean backport, only the imports and file name had been > changed. Backport looks good. Context only changes: jdk/jdk patch has '#include FT_LCD_FILTER_H', jdk8 has not. Otherwise the same modulo path changes. Thanks, Severin From gnu.andrew at redhat.com Wed Aug 28 16:27:04 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 28 Aug 2019 17:27:04 +0100 Subject: RFC: backport of JDK-8222980: Upgrade IANA Language Subtag Registry to Version 2019-04-03 In-Reply-To: References: Message-ID: <6a5c5201-2446-a2f3-b560-d62f505c7940@redhat.com> On 23/08/2019 10:41, Mario Torre wrote: > On Thu, Aug 22, 2019 at 8:56 PM Aleksey Shipilev wrote: >> >> On 8/22/19 3:01 PM, Mario Torre wrote: >>> I would like to backport the following bug: >>> https://bugs.openjdk.java.net/browse/JDK-8222980 >>> >>> To jdk8u-dev. >>> >>> Patch applies cleanly, compiles and passes its test. >> >> I am confused, why are you asking here? You can proceed to label the issue and put "Fix Request", as >> per step 6 in checklist: >> https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix > > Merely CC'ing in triple copy to keep bureaucracy happy ;) > Please don't. Having done the previous batch of these last CPU cycle, I was surprised to see a RFR for this. >> There is apparently jdk8u-fix-request, but no "Fix request" comment. > > Added. > Approved. Please mention if the patch applies cleanly or link to an RFR in the fix request. If that had been present, I could have approved this a couple of days ago when I cleared such low hanging fruit. > Cheers, > Mario > 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 xxinliu at amazon.com Wed Aug 28 17:03:47 2019 From: xxinliu at amazon.com (Liu, Xin) Date: Wed, 28 Aug 2019 17:03:47 +0000 Subject: Backport vmTestbase tests to jdk8u-dev? Message-ID: <94B97CA8-3921-45EA-9823-D77D016396E8@amazon.com> Hi, Internally at Amazon, we?ve backported vmTestbase from jdk13 (as of 3 months ago) to corretto-8. Even though more tests can be enabled, we currently run only the following tests in our nightly job of fastdebug. We treat them as complement tests. TEST STATS: name=hotspot_vmtest_mlvm run=47 pass=47 fail=0 TEST STATS: name=hotspot_vmtest_jit run=224 pass=224 fail=0 TEST STATS: name=hotspot_vmtest_gc run=1 pass=1 fail=0 TEST STATS: name=hotspot_vmtest_runtime run=266 pass=266 fail=0 We wonder if the community is interested in vmTestbase in jdk8u. If yes, we can create a JBS issue to talk about how to upstream it. It?s not a clean backport. Here?s the rationale for our changes. Opinions welcome. We will work on the mercurial repo and refactor it after discussion. 1. Path locations We did a clean copy from jdk13/test/hotspot/jtreg/vmTestbase to jdk8u/hotspot/test/vmTestbase. We think it?s a good idea to use the jdk8u test layout. 2. Support @library /test/lib Many vmTestbase tests depend on additional testing library. We?ve backported from jdk13 and placed it in ?hotspot/test/test/lib/jdk/?. Elegance is not our primary consideration. We want to keep vmTestbase as intact as possible. Because vmTestbase is still in active development in upstream, this eases backporting. If we change /test/lib somewhere else, a global change of @library has to be made. Maintainers couldn?t directly apply future backport patches anymore. A jumbo change include both 1 and 2. https://github.com/navyxliu/corretto-8/commit/8aad9bdc2659660267e5a102cd625164552c79ee 3. Native compilation for tests Some vmtestbase tests rely on native libraries, but jdk8u doesn?t support native compilation for tests. We added this function to hotspot build logic. https://github.com/navyxliu/corretto-8/commit/f7beb63f4f4dfa31bd0854f228b266a49eefefed 4. Java option changed Logging format changed, so we have to change from `-Xlog:gc:gc.log` to `-Xloggc:gc.log` globally. Another example is force vmTestbase skip -XX-CompactString. https://github.com/navyxliu/corretto-8/commit/35fb47e0bfbd3fc95c58f13356624b8b18f908c1 5. Some code changes because of API changes Unsafe, Process, Stream etc. By putting above changes together, we can run vmTestbase in jdk8u. # kick off nightly tests make test-native echo "****hotspot_vmtest_mlvm***" (cd /src/hotspot/test; make JT_HOME=/opt/jtreg PRODUCT_HOME=/build/images/j2sdk-image/ ALT_OUTPUTDIR=/build hotspot_vmtest_mlvm) echo "****hotspot_vmtest_jit***" (cd /src/hotspot/test; make JT_HOME=/opt/jtreg PRODUCT_HOME=/build/images/j2sdk-image/ ALT_OUTPUTDIR=/build hotspot_vmtest_jit) echo "****hotspot_vmtest_gc***" (cd /src/hotspot/test; make JT_HOME=/opt/jtreg PRODUCT_HOME=/build/images/j2sdk-image/ ALT_OUTPUTDIR=/build hotspot_vmtest_gc) echo "****hotspot_vmtest_runtime***" (cd /src/hotspot/test; make JT_HOME=/opt/jtreg PRODUCT_HOME=/build/images/j2sdk-image/ ALT_OUTPUTDIR=/build hotspot_vmtest_runtime) 6. Once we?ve backported from jdk13, we can keep up with jdk tip by either backporting individual changes as they occur, or by doing one big backport when jdk14 is done. Thanks, --lx From gnu.andrew at redhat.com Wed Aug 28 17:15:30 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 28 Aug 2019 18:15:30 +0100 Subject: [8u] RFR: 8218780: Update MUSCLE PCSC-Lite header files In-Reply-To: References: Message-ID: On 26/08/2019 14:23, Severin Gehwolf wrote: > Hi, > > Could I please get a review of this MUSCLE header files update in > OpenJDK 8u? I'd like to backport this bug as it's also going to be in > Oracle JDK 8u231 (equiv to OpenJDK 8u232) as well. The OpenJDK 11 patch > applies almost cleanly post path-unshuffelling. Changes which didn't > apply were a copyright header update in pcsc.c. I've omitted these. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218780 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8218780/jdk8/01/webrev/ > JDK 11u changeset: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/0bcc59a50c88 > > There is going to be a follow-up fix adding back COPYING via > JDK-8226607 which I propose for backport to OpenJDK 8u as well. > > Testing: smartcardio sanity and build on Linux x86_64 (Fedora 30 and RHEL 6) > > Thanks to Aleksey Shipilev who helped test this patch. > > Thoughts? > > Thanks, > Severin > Most of this looks good. I was a little confused at first because the patch in your webrev looks quite different to the 11u changeset. However, once applied locally to the 8u repo, the diff between the two was as suggested and the PCSC library files (those in MUSCLE) were identical. I don't know what webrev did in creating that patch. The bit I don't understand is why you've decided to drop the copyright header change on the floor. Just because the original in 8u has 2014, while the original in 11u had 2015, does not make the change inapplicable. A better alternative may actually be to backport JDK-8207233 [0] first which is a nice little cleanup patch. I suspect this patch would then apply cleanly as these PCSC files are rarely touched. [0] https://bugs.openjdk.java.net/browse/JDK-8207233 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 mbalao at redhat.com Wed Aug 28 20:32:03 2019 From: mbalao at redhat.com (Martin Balao) Date: Wed, 28 Aug 2019 17:32:03 -0300 Subject: [8u] RFC 8177334: Update xmldsig implementation to Apache Santuario 2.1.1 Message-ID: Hello, This is a rough list* of dependencies for a clean jdk8u backport of JDK-8177334 [1]: * 6850612: Deprecate Class.newInstance since it violates the checked exception language contract * https://bugs.openjdk.java.net/browse/JDK-6850612 * http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/03453120a011 * Affected files * src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/SignatureAlgorithm.java * src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolver.java * src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolverSpi.java * src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolver.java * 8134984: Text files should end in exactly one newline * https://bugs.openjdk.java.net/browse/JDK-8134984 * http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a4299d47bd00 * Affected files (all this files will be deleted anyways) * src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/package.html * src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/keyvalues/package.html * src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/package.html * src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/package.html * src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/package.html * src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/package.html * src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/package.html * src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/package.html * 8055723: Replace concat String to append in StringBuilder parameters * https://bugs.openjdk.java.net/browse/JDK-8055723 * http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/4d6c9954ac70 * Affected files * src/share/classes/com/sun/org/apache/xml/internal/security/encryption/AbstractSerializer.java * This file will be deleted anyways * src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/InclusiveNamespaces.java * src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java * 8156661: Handful of typos in javadoc * https://bugs.openjdk.java.net/browse/JDK-8156661 * http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/1049321b86cb * Affected files * src/share/classes/com/sun/org/apache/xml/internal/security/encryption/AgreementMethod.java * This file will be deleted anyways * 8133802: replace some tags (obsolete in html5) in security-libs docs * https://bugs.openjdk.java.net/browse/JDK-8133802 * http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/bd9629077386 * Affected files * src/share/classes/com/sun/org/apache/xml/internal/security/encryption/CipherReference.java * This file will be deleted anyways * src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionProperty.java * This file will be deleted anyways * src/share/classes/com/sun/org/apache/xml/internal/security/encryption/ReferenceList.java * This file will be deleted anyways * @gnu_andrew already requested a jdk8u backport of this bug * 8067377: My hobby: caning, then then canning, the the can-can * https://bugs.openjdk.java.net/browse/JDK-8067377 * http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/678faa7d1a6a * Affected files * src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionMethod.java * This file will be deleted anyways * src/share/classes/com/sun/org/apache/xml/internal/security/keys/KeyUtils.java * 8031191: Warning exception when XMLSignature logging is enabled * https://bugs.openjdk.java.net/browse/JDK-8031191 * http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/1edcb81fb7cc * Affected files * src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignature.java * 8181150: Fix lint warnings in JAXP repo: rawtypes and unchecked * https://bugs.openjdk.java.net/browse/JDK-8181150 * http://hg.openjdk.java.net/jdk10/master/rev/e1a6c0168741 * Affected files * src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHere.java * 8162723: Array index overflow in Base64 utility class * https://bugs.openjdk.java.net/browse/JDK-8162723 * http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/138876450c3a * Affected files * src/share/classes/com/sun/org/apache/xml/internal/security/utils/Base64.java * 8079140: IgnoreAllErrorHandler should use doPrivileged when it reads system properties * https://bugs.openjdk.java.net/browse/JDK-8079140 * http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f717a1d287b0 * Affected files * src/share/classes/com/sun/org/apache/xml/internal/security/utils/IgnoreAllErrorHandler.java * 8038913: Bolster XML support * https://bugs.openjdk.java.net/browse/JDK-8038913 * http://hg.openjdk.java.net/jdk/jdk/rev/1ceee8d3844d * Affected files * src/share/classes/com/sun/org/apache/xml/internal/security/utils/JavaUtils.java * 8087283: Add support for the XML Signature here() function to the JDK XPath implementation * https://bugs.openjdk.java.net/browse/JDK-8087283 * http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/23de469e194d * Affected files * src/share/classes/com/sun/org/apache/xml/internal/security/utils/XalanXPathAPI.java * 8038431: Close InputStream when finished retrieving XML Signature HTTP References * https://bugs.openjdk.java.net/browse/JDK-8038431 * http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/cacad86dccd0 * Affected files * src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverDirectHTTP.java * 8046949: Generify the javax.xml.crypto API * https://bugs.openjdk.java.net/browse/JDK-8046949 * http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3e276a212a96 * Affected files * src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheCanonicalizer.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfo.java * src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheTransform.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMExcC14NMethod.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfoFactory.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignedInfo.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMManifest.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMPGPData.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMPGPData.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperties.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperty.java * src/share/classes/org/jcp/xml/dsig/internal/dom/Utils.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathTransform.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMUtils.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignatureFactory.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLObject.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java * test/jdk/javax/xml/crypto/dsig/GenerationTests.java * 8132130: Some docs cleanup * https://bugs.openjdk.java.net/browse/JDK-8132130 * http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/339e2b4a5241 * Affected files * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCryptoBinary.java * Deleted anyways * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMPGPData.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperties.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperty.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMTransform.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509Data.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLObject.java * 8041679: Replace uses of StringBuffer with StringBuilder within core library classes * https://bugs.openjdk.java.net/browse/JDK-8041679 * http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/319f26fadef4 * Affected files * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMExcC14NMethod.java * 8046044: Fix raw and unchecked lint warnings in XML Signature Impl * https://bugs.openjdk.java.net/browse/JDK-8046044 * http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7d6154df328c * Affected files * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfo.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignedInfo.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSubTreeData.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMManifest.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMPGPData.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperties.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperty.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509Data.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignatureFactory.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLObject.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java * 8046724: XML Signature ECKeyValue elements cannot be marshalled or unmarshalled * https://bugs.openjdk.java.net/browse/JDK-8046724 * http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/eed55a6ebaa3 * Affected files * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyValue.java * test/jdk/javax/xml/crypto/dsig/KeySelectors.java * test/jdk/javax/xml/crypto/dsig/GenerationTests.java * 8079693: Add support for ECDSA P-384 and P-521 curves to XML Signature * https://bugs.openjdk.java.net/browse/JDK-8079693 * http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/5ad36a27ddf3 * Affected files * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyValue.java * test/jdk/javax/xml/crypto/dsig/GenerationTests.java * 8032733: Fix cast lint warnings in client libraries * https://bugs.openjdk.java.net/browse/JDK-8032733 * http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/4e2cd8998f3d * Affected files * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMPGPData.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java * 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes * https://bugs.openjdk.java.net/browse/JDK-8042967 * http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/4d86414d3d1d * Affected files * src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureMethod.java * 8169925: Organize licenses by module in source, JMOD file, and run-time image * https://bugs.openjdk.java.net/browse/JDK-8169925 * http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c6b2de8d1f29 * Affected files * src/share/legal/santuario.md * 8081347: Add @modules to jdk_core tests * https://bugs.openjdk.java.net/browse/JDK-8081347 * http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/5d60882157c9 * Affected files * test/jdk/javax/xml/crypto/dsig/GenerationTests.java * Multiple copyright date conflicts * I.e.: * src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheNodeSetData.java * src/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java * May be (in part) due to: * 8029235: Update copyright year to match last edit in jdk8 jdk repository for 2013 * https://bugs.openjdk.java.net/browse/JDK-8029235 * http://hg.openjdk.java.net/jdk/jdk/rev/6dadb192ad81 Some of these changesets look "reverted" by 8177334 patch, but we need them if we want a clean backport. The question is: which of those do we want or makes sense to backport to jdk8u? For the rest, we will need to fix conflicts manually. (*) I might be mising dependencies of dependencies here. Unless we do the actual work, there won't be a final list. That said, this should be a good approximation base on what I've seen from each file history. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8177334 [2] - http://hg.openjdk.java.net/jdk/jdk/rev/3810c9a2efa1 From xxinliu at amazon.com Wed Aug 28 21:00:41 2019 From: xxinliu at amazon.com (Liu, Xin) Date: Wed, 28 Aug 2019 21:00:41 +0000 Subject: [8u] 8062808: Turn on the -Wreturn-type warning Message-ID: <1567026041604.28992@amazon.com> Hi, I'd like to backport JDK-8062808. Enabling -Wreturn-type helps us to catch undefined code. Could you review it and update label in that issue? webrev: https://cr.openjdk.java.net/~xliu/8062808/webrev/ It's almost a clean patch. One single difference is that original patch doesn't include perfData.hpp. It has been changed in JDK-8064811. When we backported JDK-8064811 to jdk8u, I think we drop it by mistake. I have verified it using the jdk8u repo. Both fastdebug and slowdebug work as expected. thanks, --lx From neugens at redhat.com Thu Aug 29 09:58:45 2019 From: neugens at redhat.com (Mario Torre) Date: Thu, 29 Aug 2019 11:58:45 +0200 Subject: RFC: backport JDK-8139965: Hang seen when using com.sun.jndi.ldap.search.replyQueueSize Message-ID: Hi, I would like to backport the following bug: https://bugs.openjdk.java.net/browse/JDK-8139965 The backport is based on the 11u patch rather than the original, for similar reasons as highlighted here: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-June/001257.html The patch applied mostly cleanly, however some manual reshuffling was necessary, here the request for review: http://cr.openjdk.java.net/~neugens/8139965/webrev.00/ Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From jvanek at redhat.com Thu Aug 29 10:31:05 2019 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 29 Aug 2019 12:31:05 +0200 Subject: [8u] RFR Backport JDK-8154313, Generated javadoc scattered all over the place In-Reply-To: <26c825e0e54df08018dff414850ae7d418818433.camel@redhat.com> References: <26c825e0e54df08018dff414850ae7d418818433.camel@redhat.com> Message-ID: <5885ad80-e984-ab0e-e77f-38182d8ffc46@redhat.com> Updated: >> http://cr.openjdk.java.net/~jvanek/8154313/ (https://bugs.openjdk.java.net/browse/JDK-8154313) http://cr.openjdk.java.net/~jvanek/8154313/webrev/ > make/Javadoc.gmk > ---------------- > > FULL_VERSION changed to VERSION_STRING in JDK 9+, hence the change in > JAVADOC_ARCHIVE_NAME. Ok. TY for confirmation! > > 222 PLATFORM_DOCSDIR = $(DOCSDIR)/platform > 223 > 224 > 225 JAVADOC_ARCHIVE_NAME := jdk-$(FULL_VERSION)-docs.zip > 226 JAVADOC_ARCHIVE_ASSEMBLY_DIR := $(DOCSTMPDIR)/zip-docs > 227 JAVADOC_ARCHIVE_DIR := $(OUTPUT_ROOT)/bundles > 228 JAVADOC_ARCHIVE := $(JAVADOC_ARCHIVE_DIR)/$(JAVADOC_ARCHIVE_NAME) > > Please remove the extra empty line on line 224. Done > > 352 # > 353 > 354 $(JAVADOC_ARCHIVE): $(COREAPI_INDEX_FILE) > 355 @$(ECHO) "Compressing javadoc to single $(JAVADOC_ARCHIVE_NAME)" ; > > Shouldn't this be something like this? The JDK 9 patch logs this to log info: > http://hg.openjdk.java.net/jdk9/jdk9/rev/ec69c5bf68a6#l1.41 Sure. Fixed. > > @$(ECHO) $(LOG_INFO) "Compressing javadoc to single $(JAVADOC_ARCHIVE_NAME)" > > 356 $(MKDIR) -p $(JAVADOC_ARCHIVE_DIR) ; > 357 $(RM) -r $(JAVADOC_ARCHIVE_ASSEMBLY_DIR) ; > 358 $(MKDIR) -p $(JAVADOC_ARCHIVE_ASSEMBLY_DIR); > 359 all_roots=`$(FIND) $(DOCSDIR) | $(GREP) index.html `; \ > > Why is "grep -v old/doclet" missing from the JDK 8 patch? > http://hg.openjdk.java.net/jdk9/jdk9/rev/ec69c5bf68a6#l1.45 Because it is not needed? I added that for sake of compactness. > > Are extra semicolons on lines 355-358 needed? It makes the patch Just personal taste. Removed. Thank you. > diverge from the JDK 9 version for no good reason... > > 360 pushd $(JAVADOC_ARCHIVE_ASSEMBLY_DIR); \ > 361 for index_file in $${all_roots} ; do \ > 362 target_dir=`dirname $${index_file}`; \ > 363 name=`$(ECHO) $${target_dir} | $(SED) "s;/spec;;" | $(SED) "s;.*/;;"`; \ > 364 $(LN) -s $${target_dir} $${name}; \ > 365 done; \ > 366 $(ZIP) -q -r $(JAVADOC_ARCHIVE) * ; \ > 367 popd ; > 368 > > Adding new "zip-docs" target is missing from .PHONY in this patch. Please add it. > http://hg.openjdk.java.net/jdk9/jdk9/rev/ec69c5bf68a6#l1.58 Thanx! Fixed. > > make/Main.gmk > ------------- > > No comments. > > Does "make clean-docs" work as expected? It appears it'll leave > bundles/jdk-*-docs.zip behind. No. And never was. I had added clean-docs-zip target now. > > Perhaps add a condition for "docs" component in CleanComponent here? > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/file/cd2e5f820a0d/make/MakeHelpers.gmk#l299 > > Then it would work similar to what the JDK 9 patch did with: > http://hg.openjdk.java.net/jdk9/jdk9/rev/ec69c5bf68a6#l3.7 > Thank you verey much for guiding review! J. From junguoj at amazon.com Fri Aug 30 01:29:06 2019 From: junguoj at amazon.com (Guo, James) Date: Fri, 30 Aug 2019 01:29:06 +0000 Subject: [8u] RFR 8208715: Conversion of milliseconds to nanoseconds in UNIXProcess contains bug Message-ID: <029E8BC0-B1BC-4FED-97CA-6763D2138E36@amazon.com> Hi, Original bug: https://bugs.openjdk.java.net/browse/JDK-8208715 https://hg.openjdk.java.net/jdk/jdk/rev/41257a58a588 Original patch does not apply cleanly to 8u: 1. java.base/unix doesn't exist. I had to move the change of java.base/unix/classes/java/lang/ProcessImpl.java to solaris/classes/java/lang/UNIXProcess.java to make the patch work in Unix. 2. Due to the conflict in test/java/lang/ProcessBuilder/Basic.java, I had to replace the testcase that checks Process.waitFor(timeout, TimeUnit.MILLISECONDS) with the one in 12u[1] and add a millisElapsedSince(long startNanoTime) method for it. 8u webrev: http://cr.openjdk.java.net/~alvdavi/webrevs/8208715/webrev.8u.00/ Testing: x86_64 build, affected tests [2], tier1 Thanks, James Guo [1] http://hg.openjdk.java.net/jdk/jdk/file/41257a58a588/test/jdk/java/lang/ProcessBuilder/Basic.java#l2410 [2] https://bugs.openjdk.java.net/secure/attachment/78016/JI9056393.java From felix.yang at huawei.com Fri Aug 30 06:31:18 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Fri, 30 Aug 2019 06:31:18 +0000 Subject: [Ping] Re: Request for Approval: Backport of 8047212 : runtime/ParallelClassLoading/bootstrap/random/inner-complex assert(ObjectSynchronizer::verify_objmon_isinpool(inf)) failed: monitor is invalid Message-ID: Ping... Hi, May I got review for the backport of 8146792 to 8u master repo please? Webrev: http://cr.openjdk.java.net/~fyang/8047212-8u-backport/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8047212 JDK9 Changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/a0c7a69277da This bug can always be reproduced by running jcstress test on our 64/128-core aarch64 server platform with 8u aarch64 fastdebug build. Error messge: # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/yangfei/openjdk8u-aarch64/hotspot/src/share/vm/runtime/synchronizer.cpp:1252), pid=16581, tid=0x0000ffff23c7f200 # assert(ObjectSynchronizer::verify_objmon_isinpool(inf)) failed: monitor is invalid # # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-fastdebug-yangfei_2019_08_18_14_24-b00) # Java VM: OpenJDK 64-Bit Server VM (25.71-b00-fastdebug mixed mode linux-aarch64 compressed oops) # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x0000ffff24123000): JavaThread "worker1" daemon [_thread_in_Java, id=16798, stack(0x0000ffff23a7f000,0x0000ffff23c80000)] Stack: [0x0000ffff23a7f000,0x0000ffff23c80000], sp=0x0000ffff23c7dac0, free space=2042k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x1117444] VMError::report_and_die()+0x144 V [libjvm.so+0x703ba4] report_vm_error(char const*, int, char const*, char const*)+0x7c V [libjvm.so+0x1032a78] ObjectSynchronizer::inflate(Thread*, oop)+0xbc8 V [libjvm.so+0x1036b40] ObjectSynchronizer::slow_exit(oop, BasicLock*, Thread*)+0x110 V [libjvm.so+0xeeb340] SharedRuntime::complete_monitor_unlocking_C(oopDesc*, BasicLock*)+0x130 J 73% C2 org.openjdk.jcstress.tests.seqcst.sync.L1_S1__S1__S1__S2_L2__Test_jcstress.actor3()Ljava/lang/Void; (166 bytes) @ 0x0000ffff782c4318 [0x0000ffff782c2 f80+0x1398] C 0x0000ffff2e872650 As the patch changes shared code, it has to be backported to 8u master repo before it goes to 8u-aarch64 repo. Due to the use of 'PaddedEnd' in jdk9 or higher version, some trivial tweaks are necessary for the backport. As we changed to use ordered access for global `gBlockList`, risk should be low. Jtreg tested with 8u x86_64 fastdebug build. Also passed two round of jcstress test with 8u aarch64 fastdebug build. Thanks for your help, Felix From gnu.andrew at redhat.com Fri Aug 30 15:52:00 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 30 Aug 2019 16:52:00 +0100 Subject: [8u] 8062808: Turn on the -Wreturn-type warning In-Reply-To: <1567026041604.28992@amazon.com> References: <1567026041604.28992@amazon.com> Message-ID: On 28/08/2019 22:00, Liu, Xin wrote: > Hi, > > > I'd like to backport JDK-8062808. Enabling -Wreturn-type helps us to catch undefined code. Could you review it and update label in that issue? > > webrev: https://cr.openjdk.java.net/~xliu/8062808/webrev/ > > > It's almost a clean patch. One single difference is that original patch doesn't include perfData.hpp. It has been changed in JDK-8064811. When we backported JDK-8064811 to jdk8u, I think we drop it by mistake. > > > I have verified it using the jdk8u repo. Both fastdebug and slowdebug work as expected. > > > thanks, > > --lx > I already have a backport of this, which I intend to post once JDK-8141570 is in; see [0]. Doing this beforehand will break the Zero build. [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010100.html 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 xxinliu at amazon.com Fri Aug 30 16:29:24 2019 From: xxinliu at amazon.com (Liu, Xin) Date: Fri, 30 Aug 2019 16:29:24 +0000 Subject: [8u] 8062808: Turn on the -Wreturn-type warning In-Reply-To: References: <1567026041604.28992@amazon.com> Message-ID: Thanks, Andrew. I saw you got review approval by Severin. How about we move forward? I am good if you apply your patch for JDK-8062808. Could you also take care of 'perfData.hpp'? we missed it. Thanks, --lx ?On 8/30/19, 8:53 AM, "Andrew John Hughes" wrote: On 28/08/2019 22:00, Liu, Xin wrote: > Hi, > > > I'd like to backport JDK-8062808. Enabling -Wreturn-type helps us to catch undefined code. Could you review it and update label in that issue? > > webrev: https://cr.openjdk.java.net/~xliu/8062808/webrev/ > > > It's almost a clean patch. One single difference is that original patch doesn't include perfData.hpp. It has been changed in JDK-8064811. When we backported JDK-8064811 to jdk8u, I think we drop it by mistake. > > > I have verified it using the jdk8u repo. Both fastdebug and slowdebug work as expected. > > > thanks, > > --lx > I already have a backport of this, which I intend to post once JDK-8141570 is in; see [0]. Doing this beforehand will break the Zero build. [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010100.html 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 dheeraj.madhu at gmail.com Fri Aug 23 14:53:13 2019 From: dheeraj.madhu at gmail.com (Dheeraj Joshi) Date: Fri, 23 Aug 2019 14:53:13 -0000 Subject: JDK 8 Updates from OpenJDK community In-Reply-To: <94ecd35c-fa09-17d4-b270-04c3731292be@redhat.com> References: <2dc4a25c-a2ed-f243-2ddc-9ef2d8e4cc87@redhat.com> <94ecd35c-fa09-17d4-b270-04c3731292be@redhat.com> Message-ID: Thanks Andrew. This clarifies things. We will work on upgrading JDK to 11. Rather than being on JDK 8. Even though JDK 8 is supported till 2023. On Fri, 23 Aug, 2019, 7:23 PM Andrew Haley, wrote: > On 8/23/19 1:23 PM, Dheeraj Joshi wrote: > > That means as community openjdk doesn't have road map > > Absolutely not. It means no such thing, and there is no way you can place > such an implication on what I wrote. > > The current road map is that I will continue to lead this project until > 2023. > > > and as long as some org like jboss or adoptopenjdk provides fix to > > JDK 8 it will be available. > > Well, yes, as long as someone maintains JDK8 it will be maintained. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From adossant at redhat.com Thu Aug 15 18:33:08 2019 From: adossant at redhat.com (Alexandre Dos Santos) Date: Thu, 15 Aug 2019 18:33:08 -0000 Subject: [ 02448081] Keystore was tampered with, or password was incorrect Message-ID: Hi Team, The client has already validated the keystore creation steps for java-1.8.0-openjdk-1.8.0.222.b10-0.el6_10.x86_64, but still has errors. He recently changed the password to the default 'changeit' and the error no longer occurs. Any suggestions? ~~~ Caused by: java.io.IOException: Keystore was tampered with, or password was incorrect Caused by: java.security.KeyStoreException: problem accessing trust store Caused by: java.security.UnrecoverableKeyException: Password verification failed ~~~ Thanks, Alexandre Dos Santos Software Maintenance Engineer GSS - Global Support Services