From sgehwolf at redhat.com Mon Sep 2 12:14:12 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 02 Sep 2019 14:14:12 +0200 Subject: [8u] RFR: 8218780: Update MUSCLE PCSC-Lite header files In-Reply-To: References: Message-ID: Hi Andrew, Thanks for the review! On Wed, 2019-08-28 at 18:15 +0100, Andrew John Hughes wrote: > 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. OK. I see. I wasn't sure how to deal with copyright year updates. I've added the copyright update back. The patch is now identical to JDK 11u (modulo differing copyright year base: 2014 - jdk 8 - vs. 2018 - jdk 11): http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8218780/jdk8/02/webrev > 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 Hmm, this seems overkill just to get the copyright hunk to apply. I'd prefer to keep this dependency out of scope for this patch. While a nice clean-up it's not without risk backporting that too. Thoughts? Thanks, Severin From gnu.andrew at redhat.com Mon Sep 2 14:20:48 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 2 Sep 2019 15:20:48 +0100 Subject: [8u] RFR: 8218780: Update MUSCLE PCSC-Lite header files In-Reply-To: References: Message-ID: On 02/09/2019 13:14, Severin Gehwolf wrote: snip... >>> >> >> 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. > > OK. I see. I wasn't sure how to deal with copyright year updates. I've > added the copyright update back. The patch is now identical to JDK 11u > (modulo differing copyright year base: 2014 - jdk 8 - vs. 2018 - jdk > 11): > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8218780/jdk8/02/webrev > This looks good now (though still issues with the original diff vs local application of it) Please flag the bug for approval. > >> 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 > > Hmm, this seems overkill just to get the copyright hunk to apply. I'd > prefer to keep this dependency out of scope for this patch. While a > nice clean-up it's not without risk backporting that too. Thoughts? > Well, I think it's a useful cleanup too, but I'm not going to force it as a dependency of this. I just thought it might make the review for this fix redundant as it would then be a clean backport. I might look into it myself at a later date. > Thanks, > Severin > -- 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 Sep 2 14:38:47 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 2 Sep 2019 15:38:47 +0100 Subject: [8u] RFR: 8226607: Inconsistent info between pcsclite.md and MUSCLE headers In-Reply-To: References: Message-ID: <846dd0f7-c132-e2a9-b9d4-343a0524f784@redhat.com> On 26/08/2019 14:24, Severin Gehwolf wrote: > 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 > > > The *.md files in OpenJDK 9+ are the modular equivalent of the THIRD_PARTY_README file found in each OpenJDK 8u repository. See my review of JDK-8217676 [0] for Zhengyu for more details. For reference, the conversion took place in JDK-8169925. [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010116.html [1] https://bugs.openjdk.java.net/browse/JDK-8169925 -- 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 Mon Sep 2 15:05:54 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 02 Sep 2019 17:05:54 +0200 Subject: [8u] RFR: 8226607: Inconsistent info between pcsclite.md and MUSCLE headers In-Reply-To: <846dd0f7-c132-e2a9-b9d4-343a0524f784@redhat.com> References: <846dd0f7-c132-e2a9-b9d4-343a0524f784@redhat.com> Message-ID: On Mon, 2019-09-02 at 15:38 +0100, Andrew John Hughes wrote: > > On 26/08/2019 14:24, Severin Gehwolf wrote: > > 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 > > > > > > > > The *.md files in OpenJDK 9+ are the modular equivalent of the > THIRD_PARTY_README file found in each OpenJDK 8u repository. See my > review of JDK-8217676 [0] for Zhengyu for more details. > > For reference, the conversion took place in JDK-8169925. Thanks for this. Updated webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226607/jdk8/02/webrev/ I intend to push the same updat to THIRD_PARTY_README files on all other repos. Example here is jdk repo. Do you want to see webrevs of this THIRD_PARTY_README update for all 7 other repos? Thanks, Severin > [0] > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010116.html > [1] https://bugs.openjdk.java.net/browse/JDK-8169925 From jaroslav.bachorik at datadoghq.com Mon Sep 2 15:50:38 2019 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Mon, 2 Sep 2019 17:50:38 +0200 Subject: [8u] [JFR] RFR 8230448: JFRSecurityTestSuite.java is failing on Windows Message-ID: Hi, please, review a simple test fix for the JFR backport related code. JIRA: https://bugs.openjdk.java.net/browse/JDK-8230448 Webrev: http://cr.openjdk.java.net/~jbachorik/8230448/webrev.00/ Thanks! -JB- From gnu.andrew at redhat.com Mon Sep 2 15:59:46 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 2 Sep 2019 16:59:46 +0100 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: <37f5f0c8-154d-e066-95f4-77b5f6a9afe1@redhat.com> On 27/08/2019 21:05, Hohensee, Paul wrote: > 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 don't believe I was suggesting it was. 8189762 was over five years after 8005056. 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? Neither. There is no reason to manually file backport bugs, as the bug system will handle this, and a new bug ID would lose any connection between the changes and their original source. Looking at this again, it appears that the JDK version already has the same fix to ClassInstaller.java in 8005056, but slightly different code. This is the result of JDK-8027803 [0] [1]. So we actually only need to sync the changes in 8189762. I suggest: https://cr.openjdk.java.net/~andrew/openjdk8/8189762-jdk/webrev.01/ which then leaves the difference between the two versions as just the variation in the fixes: $ diff -u test/lib/testlibrary/ClassFileInstaller.java ../hotspot/test/testlibrary/ClassFileInstaller.java --- test/lib/testlibrary/ClassFileInstaller.java 2019-09-02 16:44:24.993301954 +0100 +++ ../hotspot/test/testlibrary/ClassFileInstaller.java 2019-06-04 23:50:49.082742173 +0100 @@ -246,9 +246,8 @@ } else { // Create the class file's package directory Path p = Paths.get(pathName); - Path parent = p.getParent(); - if (parent != null) { - Files.createDirectories(parent); + if (pathName.contains("/")) { + Files.createDirectories(p.getParent()); } // Create the class file Files.copy(is, p, StandardCopyOption.REPLACE_EXISTING); I think that can stay. I actually think the JDK fix is a little nicer. If you're happy with that, I'll push it. > > Thanks, > > Paul > [0] https://bugs.openjdk.java.net/browse/JDK-8027803 [1] https://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/c04e46dbfea8 Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From sgehwolf at redhat.com Mon Sep 2 16:16:50 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 02 Sep 2019 18:16:50 +0200 Subject: [8u] RFR Backport JDK-8154313, Generated javadoc scattered all over the place In-Reply-To: <5885ad80-e984-ab0e-e77f-38182d8ffc46@redhat.com> References: <26c825e0e54df08018dff414850ae7d418818433.camel@redhat.com> <5885ad80-e984-ab0e-e77f-38182d8ffc46@redhat.com> Message-ID: <6406f01ce84eb261c2ef633b767db191fc2d49bd.camel@redhat.com> Hi, On Thu, 2019-08-29 at 12:31 +0200, Jiri Vanek wrote: > Updated: > > > http://cr.openjdk.java.net/~jvanek/8154313/ ( > > > https://bugs.openjdk.java.net/browse/JDK-8154313) > http://cr.openjdk.java.net/~jvanek/8154313/webrev/ Thanks for the update. I should note that this backport introduces the new target as 'docs-zip' right away instead of the original name of 'zip-docs' in JDK 9 which then got renamed to 'docs-zip' via JDK- 8168772. Not sure if that was already the case for v1 of the webrev. > > > > 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. What do you mean by "And never was."? Are you suggesting it doesn't work on JDK 9+? If so JDK-8168772 seems a likely culprit. Anyway... > > 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! > make/Main.gmk: 202 # Remove everything, except the output from configure. 203 clean: clean-langtools clean-corba clean-jaxp clean-jaxws clean-hotspot clean-jdk clean-nashorn clean-images clean-overlay-images clean-bootcycle-build clean-docs clean-docs-zip clean-test You are adding clean-docs-zip to the default "clean" target. Yet, "make docs" doesn't seem to build docs-zip. That seems inconsistent. I'd require an explicit "make clean-docs-zip" call. I.e. don't add it to the list of dep-targets for "make clean". 257 .PHONY: langtools corba jaxp jaxws hotspot jdk nashorn images overlay-images install test docs docs-zip docs-zip-only 258 .PHONY: langtools-only corba-only jaxp-only jaxws-only hotspot-only jdk-only nashorn-only images-only overlay-images-only install-only test-only docs-only Style: It seems all 'foo-only' targets are on one line, and 'foo' on another. Please move the docs-zip-only addition to line 258. Looks OK otherwise. Thanks, Severin From jvanek at redhat.com Mon Sep 2 16:39:11 2019 From: jvanek at redhat.com (Jiri Vanek) Date: Mon, 2 Sep 2019 18:39:11 +0200 Subject: [8u] RFR Backport JDK-8154313, Generated javadoc scattered all over the place In-Reply-To: <6406f01ce84eb261c2ef633b767db191fc2d49bd.camel@redhat.com> References: <26c825e0e54df08018dff414850ae7d418818433.camel@redhat.com> <5885ad80-e984-ab0e-e77f-38182d8ffc46@redhat.com> <6406f01ce84eb261c2ef633b767db191fc2d49bd.camel@redhat.com> Message-ID: <2be84fea-875d-6765-e551-19c8a71279ff@redhat.com> On 9/2/19 6:16 PM, Severin Gehwolf wrote: > Hi, > > On Thu, 2019-08-29 at 12:31 +0200, Jiri Vanek wrote: >> Updated: >>>> http://cr.openjdk.java.net/~jvanek/8154313/ ( >>>> https://bugs.openjdk.java.net/browse/JDK-8154313) >> http://cr.openjdk.java.net/~jvanek/8154313/webrev/ > > Thanks for the update. I should note that this backport introduces the > new target as 'docs-zip' right away instead of the original name of > 'zip-docs' in JDK 9 which then got renamed to 'docs-zip' via JDK- > 8168772. Not sure if that was already the case for v1 of the webrev. Yes. I Intentionally introduced the jdk11 name, rather then jdk9 one. I strongly suggest to keep the target aligned with jdk11. I would say, that the target was not even solidly noticed in jdk9/10 > >>> >>> 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. > > What do you mean by "And never was."? Are you suggesting it doesn't > work on JDK 9+? If so JDK-8168772 seems a likely culprit. Anyway... sorry for not being clear. The clean was not working in original my original backport. It is of course working now, and in jdk11. > >>> 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! >> > > make/Main.gmk: > > 202 # Remove everything, except the output from configure. > 203 clean: clean-langtools clean-corba clean-jaxp clean-jaxws clean-hotspot clean-jdk clean-nashorn clean-images clean-overlay-images clean-bootcycle-build clean-docs clean-docs-zip clean-test > > You are adding clean-docs-zip to the default "clean" target. Yet, "make > docs" doesn't seem to build docs-zip. That seems inconsistent. I'd > require an explicit "make clean-docs-zip" call. I.e. don't add it to > the list of dep-targets for "make clean". Isn't maybe better to add docs-zip to default docs target? > > 257 .PHONY: langtools corba jaxp jaxws hotspot jdk nashorn images overlay-images install test docs docs-zip docs-zip-only > 258 .PHONY: langtools-only corba-only jaxp-only jaxws-only hotspot-only jdk-only nashorn-only images-only overlay-images-only install-only test-only docs-only > > Style: It seems all 'foo-only' targets are on one line, and 'foo' on > another. Please move the docs-zip-only addition to line 258. I see. will be fixed. > > Looks OK otherwise. > > Thanks, > Severin > -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek at redhat.com M: +420775390109 From sgehwolf at redhat.com Mon Sep 2 16:55:11 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 02 Sep 2019 18:55:11 +0200 Subject: [8u] RFR Backport JDK-8154313, Generated javadoc scattered all over the place In-Reply-To: <2be84fea-875d-6765-e551-19c8a71279ff@redhat.com> References: <26c825e0e54df08018dff414850ae7d418818433.camel@redhat.com> <5885ad80-e984-ab0e-e77f-38182d8ffc46@redhat.com> <6406f01ce84eb261c2ef633b767db191fc2d49bd.camel@redhat.com> <2be84fea-875d-6765-e551-19c8a71279ff@redhat.com> Message-ID: <6a422810d25f0c9a26283c4a16a0ea202d49cb47.camel@redhat.com> On Mon, 2019-09-02 at 18:39 +0200, Jiri Vanek wrote: > > make/Main.gmk: > > > > 202 # Remove everything, except the output from configure. > > 203 clean: clean-langtools clean-corba clean-jaxp clean-jaxws clean-hotspot clean-jdk clean-nashorn clean-images clean-overlay-images clean-bootcycle-build clean-docs clean-docs-zip clean-test > > > > You are adding clean-docs-zip to the default "clean" target. Yet, "make > > docs" doesn't seem to build docs-zip. That seems inconsistent. I'd > > require an explicit "make clean-docs-zip" call. I.e. don't add it to > > the list of dep-targets for "make clean". > > Isn't maybe better to add docs-zip to default docs target? I'm not sure. My concern is about people who are using "make docs" now and not breaking their use-cases. Even if that just means longer build time in reality. It's not unreasonable to assume "make docs" is potentially more widely used. As docs-zip is new, it cannot be used. I'd error on the side of caution for both cases: "make clean" and "make docs". Thanks, Severin From neugens.limasoftware at gmail.com Mon Sep 2 17:03:53 2019 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 2 Sep 2019 19:03:53 +0200 Subject: [8u] [JFR] RFR 8230448: JFRSecurityTestSuite.java is failing on Windows In-Reply-To: References: Message-ID: The patch looks good. I believe you will need to manually close the bug with the appropriate commit link once pushed, I don't think we have Jira hooks in place for this repository. Thanks! Cheers, Mario Il giorno lun 2 set 2019 alle ore 17:51 Jaroslav Bachor?k ha scritto: > > Hi, > > please, review a simple test fix for the JFR backport related code. > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8230448 > Webrev: http://cr.openjdk.java.net/~jbachorik/8230448/webrev.00/ > > Thanks! > > -JB- -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From gnu.andrew at redhat.com Mon Sep 2 17:48:08 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 2 Sep 2019 18:48:08 +0100 Subject: [8u] RFR Backport of 8203324: Use out of scope in getMacOSXLocale of java_props_macosx.c:120 In-Reply-To: References: Message-ID: <58c74191-8c9b-20d8-c3b8-5429563631f0@redhat.com> On 20/08/2019 14:49, Simon Tooke wrote: > 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 > > > Looks sensible to me. Approved. Out of interest, is it possible to build on Mac OS X at present? I remember you posted another patch to work on this. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Mon Sep 2 17:54:11 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 2 Sep 2019 18:54:11 +0100 Subject: RFR: 8194653: Deadlock involving FileSystems.getDefault and System.loadLibrary call In-Reply-To: <3b02d5c7-5c6f-88b4-557a-af7c3f01ac23@redhat.com> References: <1fc64685-f010-8825-5bbf-87441f535476@redhat.com> <3b02d5c7-5c6f-88b4-557a-af7c3f01ac23@redhat.com> Message-ID: On 20/06/2019 18:08, Andrew John Hughes wrote: > On 19/06/2019 11:02, Andrew Dinn wrote: >> Could I please have reviews for the following patch against jdk8u-dev: >> >> Webrev: http://cr.openjdk.java.net/~adinn/8194653/webrev.00/ >> JIRA: https://bugs.openjdk.java.net/browse/JDK-8194653 >> >> Background: >> >> The email threads discussing this issue were a tad inconclusive for both >> jdk8u and jdk9+. >> >> On jdk8 a suggestion was left hanging that a fix in the jdk not jvm >> might be better. >> >> On jdk9+ upwards the deadlock does not manifest but it might do in >> future so an investigation was requested by Alan Bateman which has not >> been followed up. >> >> Nevertheless, Oracle have applied a jdk8u patch in 8u212, although using >> a different JIRA issue. >> >> https://bugs.openjdk.java.net/browse/JDK-8222858 >> >> I am not sure why this has been done as a backport? Note it may be >> relevant that the original JIRA (8194653) is marked as being against 8u231. >> >> Testing: >> >> The reproduced supplied with the original patch and included in the >> above webrev fails before applying and works afterwards. >> >> regards, >> >> >> Andrew Dinn >> ----------- >> > > The clue is in the build number. The high (30+) build numbers generally > indicate customer builds, as far as we can tell. It's relatively common > for an issue to be listed as fixed in 8ux b30 and 8ux+1 b30, before > finally being in the GA build of 8ux+2. I think this one just looks > extra odd because the main bug is fixed directly in 8, rather than a > later JDK release and all the 8 fixes being backports. Our filter > actually missed some bugs marked as 8u202 b3x last cycle, because it was > assumed they were fixed by the integration of 8u202, before Oracle quit > the project, when actually that work only went up to b08, the GA release. > > This one is another example: > > https://bugs.openjdk.java.net/browse/JDK-8155951 > > That given, I think we can include this in the October CPU, rather than > trying to rush in a release for July's, which freezes next week. > > Thanks, > Is there any movement on this? We're now looking at rampdown for 8u232, and I see no further agreement towards a fix for this. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue Sep 3 03:14:14 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 3 Sep 2019 04:14:14 +0100 Subject: [8u] 8178870: instrumentation.retransformClasses cause coredump In-Reply-To: References: <6d646175-68e2-b280-6475-cd97f2e5d438@redhat.com> <7003c233-d891-b11b-3426-f9b6f7de2d8f@redhat.com> <0bfedafb-f31c-6278-31da-56cb4abc1d34@redhat.com> Message-ID: On 23/08/2019 13:13, Zhengyu Gu wrote: > 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 > > > >> This seems to contain 3 bug IDs. Please post a clean webrev for 8178870 once 8155951 is pushed. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue Sep 3 03:30:05 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 3 Sep 2019 04:30:05 +0100 Subject: [8u] RFR 8155951 & 8151066 In-Reply-To: References: Message-ID: On 13/08/2019 19:13, Zhengyu Gu wrote: > 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 This looks ok. FWIW, the SafepointCheckRequired enum (of which Monitor::_safepoint_check_always is one value) is introduced by JDK-8047290 [0]. The flag results in asserts in debug builds if the runtime behaviour does not match the designated behaviour. That one may be worth considering for backport at some point, but there's no issue with leaving the argument out here because, not only does the argument not exist, but neither does the value or the variable in Monitor: + // Locks can be acquired with or without safepoint check. + // Monitor::lock and Monitor::lock_without_safepoint_check + // checks these flags when acquiring a lock to ensure + // consistent checking for each lock. + // A few existing locks will sometimes have a safepoint check and + // sometimes not, but these locks are set up in such a way to avoid deadlocks. + enum SafepointCheckRequired { + _safepoint_check_never, // Monitors with this value will cause errors + // when acquired with a safepoint check. + _safepoint_check_sometimes, // Certain locks are called sometimes with and + // sometimes without safepoint checks. These + // locks will not produce errors when locked. + _safepoint_check_always // Causes error if locked without a safepoint + // check. + }; + + NOT_PRODUCT(SafepointCheckRequired _safepoint_check_required;) + [0] https://bugs.openjdk.java.net/browse/JDK-8047290 -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue Sep 3 03:44:46 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 3 Sep 2019 04:44:46 +0100 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: On 08/08/2019 20:40, Martin Balao wrote: > 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 > Bringing Convert.java in here is ok because we can't backport the feature changeset "8171277: Elliptic Curves for Security in Crypto", but, in cases like this, please explain why you have chosen to include additional files/hunks beyond the original changes, so reviewers don't have to duplicate the work of finding out the source of these changes. Approved. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue Sep 3 04:28:44 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 3 Sep 2019 05:28:44 +0100 Subject: RFC: backport JDK-8139965: Hang seen when using com.sun.jndi.ldap.search.replyQueueSize In-Reply-To: References: Message-ID: On 29/08/2019 10:58, Mario Torre wrote: > 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 > It doesn't apply cleanly because of two contextual differences: 1. @@ -75,7 +75,7 @@ - } else { - // no timeout is set so we wait infinitely until - // a response is received -- // http://docs.oracle.com/javase/8/docs/technotes/guides/jndi/jndi-ldap.html#PROP +- // https://docs.oracle.com/javase/8/docs/technotes/guides/jndi/jndi-ldap.html#PROP - ldr.wait(); - } - } else { This is because of "8068491: Update the protocol for references of docs.oracle.com to HTTPS" [0] which has oddly only ever been applied to a branch of 8u and isn't in 9+. 2. @@ -191,7 +191,7 @@ + } - // Unblock reader of pending request -- // Should only ever have at most one waiter +- // Should only ever have atmost one waiter - notify(); + synchronized void close() { + closed = true; This is because 8u lacks "8054158: Fix typos in JNDI-related packages" which is probably worth backporting at some point. There did seem to be some other odd whitespace differences in your patch, so I did a clean backport from 11u and pushed the result. [0] https://bugs.openjdk.java.net/browse/JDK-8068491 [1] https://bugs.openjdk.java.net/browse/JDK-8054158 Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue Sep 3 04:50:49 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 3 Sep 2019 05:50:49 +0100 Subject: [8u] 8217676: Upgrade libpng to 1.6.37 In-Reply-To: References: <42cc1803-6f71-ba9d-d262-f79522071f10@redhat.com> Message-ID: On 22/08/2019 21:00, Zhengyu Gu wrote: > snip... > 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 > > The license patch seems to miss some header lines when compared with 11u, and also removes a section about trademarks and export control that isn't altered in the 11u version. How was it applied? I've attached what I get from manually applying the 11u patch to THIRD_PARTY_README. This diffs cleanly against libpng.md in 11u. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: libpng_license.patch Type: text/x-patch Size: 8529 bytes Desc: not available URL: From gnu.andrew at redhat.com Tue Sep 3 05:12:19 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 3 Sep 2019 06:12:19 +0100 Subject: [8u] 8222108: Reduce minRefreshTime for updating remote printer list on Windows In-Reply-To: <3b26ee23-1124-7538-6ba0-d5f021fdd12e@redhat.com> References: <3b26ee23-1124-7538-6ba0-d5f021fdd12e@redhat.com> Message-ID: On 27/08/2019 14:39, Zhengyu Gu wrote: > > 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 This mostly looks ok, but one change seems to have been missed; the prevRemotePrinters variable is not removed. Was there a reason for this? Moreover, it seems the constructor body, which uses prevRemotePrinters, was not removed as part of backporting JDK-8221412. --- 8222108.11u 2019-09-03 05:59:15.876734203 +0100 +++ 8222108.8u 2019-08-27 13:48:07.000000000 +0100 -@@ -398,60 +400,38 @@ +@@ -394,61 +396,40 @@ count of printer status changes(add\remove) and based on it update the printers list. */ -- class RemotePrinterChangeListener implements Runnable { -- private String[] prevRemotePrinters; -+ class RemotePrinterChangeListener implements Comparator, Runnable { +- class RemotePrinterChangeListener extends Thread { ++ class RemotePrinterChangeListener extends Thread implements Comparator{ + private String[] prevRemotePrinters; RemotePrinterChangeListener() { + prevRemotePrinters = getRemotePrintersNames(); } - private boolean doCompare(String[] str1, String[] str2) { -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue Sep 3 05:30:22 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 3 Sep 2019 06:30:22 +0100 Subject: 8u232 Rampdown: Bug Triage Message-ID: Hi all, We have reached the point of rampdown for 8u232 and need to decide which issues are still worth trying to push into that release and which should be deferred until 8u242. I've been going through the list of bugs which are marked as fixed in Oracle's proprietary 8u231/2 [0] to see what is still missing in OpenJDK 8u: 1. JDK-8222496/JDK-8198649 "[8u] Switch on GTK3 as a default GTK L&F in client-libs" This is 8222496 in 8u, but 8198649 in 11u just for extra confusion. I've see no review or approval request for this yet. As a simple default change, I'm happy for this to still go in early in rampdown while there is time for any side-effects to be tested for. It's a clean backport, so I've flagged it for approval. 2. JDK-8219914 Change the environment variable for Java Access Bridge logging to have a directory This is in OpenJDK 13, but not 11. Not sure why. No sign of any review or approval for OpenJDK 8u as yet. 3. JDK-8219013 Update Apache Santuario (XML Signature) to version 2.1.3 This is not yet in OpenJDK 8u or 11u. There are earlier Santuario changes it depends on. 4. JDK-8218629 XML Digital Signature throws NAMESPACE_ERR exception on OpenJDK 11, works 8/9/10 No sign of review or approval. Again, depends on earlier Santuario changes, specifically JDK-8177334. 5. JDK-8218605 Startup Splash Screen of SwingSet2 flashes in smaller coordinates before appearing in the final size This was originally flagged for 8u222. There's no patch to backport and nothing has been posted for review. 6. JDK-8217878 ENVELOPING XML signature no longer works in JDK 11 No sign of review or approval. Again, depends on earlier Santuario changes, specifically JDK-8177334. 7. JDK-8217581 JDK 8 javadoc man page does not list correct values for -source No patch to backport and no sign of a patch for review. Probably requires rather ugly changes directly to the man page as we don't have the sources checked in as far as I'm aware. Probably best to wait until Oracle update the online version. 8. JDK-8216401 Allow "file:" URLs in Class-Path of local JARs Patch has been posted, but needs to be updated following dependent ClassFileInstaller changes being backported (see [1]) 9. JDK-8215210 [macos] Hangul text does not shape to the precomposed form on JDK8u Similar to #5, this is an 8u222 era fix with no patch to backport and no patch posted for review. 10. JDK-8205507 jdk/javax/xml/crypto/dsig/GenerationTests.java timed out Another that depends on JDK-8177334. 11. JDK-8196681 Java Access Bridge logging and debug flags dynamically controlled Similar to 8219914, but this one is in 11u at least. No visible attempts for 8u yet. 12. JDK-8194653 Deadlock involving FileSystems.getDefault and System.loadLibrary call There was discussion on this before 8u222 in June 2019 [2], but no sign of any further consensus on a patch since. 13. JDK-8178870 instrumentation.retransformClasses cause coredump Patch has been posted but needs to be revised once JDK-8155951 is committed. 14. JDK-8177334 Update xmldsig implementation to Apache Santuario 2.1.1 Still in early stages of backport, so will need to defer this to 8u242. 15. JDK-8217676 Upgrade libpng to 1.6.37 This needs some minor work still, but should be able to be pushed to 8u232 during rampdown. 16. JDK-8228469 (tz) Upgrade time-zone data to tzdata2019b This is a late arrival that isn't in 8u or 11u, but we should be able to get it into both during rampdown. 17. JDK-8229868 Update Apache Santuario TPRM version This should be combined with JDK-8219013 (#3) 18. JDK-8222108 Reduce minRefreshTime for updating remote printer list on Windows As with JDK-8217676, the patch needs some minor changes but should be possible to include during rampdown. My current thinking is: * Suitable for rampdown - #1, #7, #8, #13, #15, #16, #18 * Defer to 8u242 - Access bridge patches (#2, #11) - Apache Santuario work (#3, #4, #6, #10, #14, #17) - AWT bugs (#5, #9) - Deadlock bug (#12) Other bugs may be considered during rampdown, but they should be regression fixes or minor bugs / test issues. Feature work should now be focused on 8u242. I think things look better than the last cycle, but we are still seeing too many patches towards the end of the development period. If you want to target something for 8u242, now is the time to start working on it. For 8u232, the primary focus should be testing to make sure there are no major regressions. [0] https://bugs.openjdk.java.net/browse/JDK-8219914?filter=36513 [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010030.html -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue Sep 3 05:38:37 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 3 Sep 2019 06:38:37 +0100 Subject: 8u232 now in RAMPDOWN; 8u & 8u-dev FROZEN for commits Message-ID: <32014feb-f7eb-d17e-a922-a9e4111c3bda@redhat.com> As per the development process [0] and timeline [1], 8u232 is now in rampdown. The 8u-dev tree is frozen for commits while it transitions to 8u232 development. Please do not push any commits to 8u-dev until the all clear is given. I'll push any approved issues that have not yet been pushed [2]. The 8u tree is closed for commits until jdk8u232-b05 is tested and pushed. This should happen within the next 24 hours. Once open, commits will require the jdk8u-critical-yes label. [0] https://wiki.openjdk.java.net/display/jdk8u/Detailed+Process+Description [1] https://wiki.openjdk.java.net/display/jdk8u/Main [2] https://bugs.openjdk.java.net/browse/JDK-8147611?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 aph at redhat.com Tue Sep 3 09:53:53 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 3 Sep 2019 10:53:53 +0100 Subject: 8u232 Rampdown: Bug Triage In-Reply-To: References: Message-ID: <7f18fe0e-288d-8c14-f4aa-de168ea4742b@redhat.com> Hi, On 9/3/19 6:30 AM, Andrew John Hughes wrote: > We have reached the point of rampdown for 8u232 and need to decide which > issues are still worth trying to push into that release and which should > be deferred until 8u242. > > I've been going through the list of bugs which are marked as fixed in > Oracle's proprietary 8u231/2 [0] to see what is still missing in OpenJDK 8u: > > 1. JDK-8222496/JDK-8198649 > "[8u] Switch on GTK3 as a default GTK L&F in client-libs" > > This is 8222496 in 8u, but 8198649 in 11u just for extra confusion. I've > see no review or approval request for this yet. As a simple default > change, I'm happy for this to still go in early in rampdown while there > is time for any side-effects to be tested for. Seems a little risky at this late stage. I'd leave it until the next cycle. > It's a clean backport, so I've flagged it for approval. > > 2. JDK-8219914 > Change the environment variable for Java Access Bridge logging to have a > directory > > This is in OpenJDK 13, but not 11. Not sure why. No sign of any review > or approval for OpenJDK 8u as yet. Punt 'til next time. > 3. JDK-8219013 > Update Apache Santuario (XML Signature) to version 2.1.3 > > This is not yet in OpenJDK 8u or 11u. There are earlier Santuario > changes it depends on. Likewise. > 4. JDK-8218629 > XML Digital Signature throws NAMESPACE_ERR exception on OpenJDK 11, > works 8/9/10 > > No sign of review or approval. Again, depends on earlier Santuario > changes, specifically JDK-8177334. Likewise. > 5. JDK-8218605 > Startup Splash Screen of SwingSet2 flashes in smaller coordinates before > appearing in the final size > > This was originally flagged for 8u222. There's no patch to backport and > nothing has been posted for review. Likewise. > 6. JDK-8217878 > ENVELOPING XML signature no longer works in JDK 11 > > No sign of review or approval. Again, depends on earlier Santuario > changes, specifically JDK-8177334. Likewise. > 7. JDK-8217581 > JDK 8 javadoc man page does not list correct values for -source > > No patch to backport and no sign of a patch for review. Probably > requires rather ugly changes directly to the man page as we don't have > the sources checked in as far as I'm aware. Probably best to wait until > Oracle update the online version. Likewise. > 8. JDK-8216401 > Allow "file:" URLs in Class-Path of local JARs > > Patch has been posted, but needs to be updated following dependent > ClassFileInstaller changes being backported (see [1]) This is a significant patch, and it should go in, but perhaps it's too late for this cycle? > 9. JDK-8215210 > [macos] Hangul text does not shape to the precomposed form on JDK8u > > Similar to #5, this is an 8u222 era fix with no patch to backport and no > patch posted for review. Unless there's a MacOS engineer to step up, we can't do much about this. > 10. JDK-8205507 > jdk/javax/xml/crypto/dsig/GenerationTests.java timed out > > Another that depends on JDK-8177334. > 11. JDK-8196681 > Java Access Bridge logging and debug flags dynamically controlled > > Similar to 8219914, but this one is in 11u at least. No visible attempts > for 8u yet. > > 12. JDK-8194653 > Deadlock involving FileSystems.getDefault and System.loadLibrary call > > There was discussion on this before 8u222 in June 2019 [2], but no sign > of any further consensus on a patch since. It's not clear to me that this is a real problem in practice. I don't know how frequently it occurs in ptactice, if ever. > 13. JDK-8178870 > instrumentation.retransformClasses cause coredump > > Patch has been posted but needs to be revised once JDK-8155951 is committed. > > 14. JDK-8177334 > Update xmldsig implementation to Apache Santuario 2.1.1 > > Still in early stages of backport, so will need to defer this to 8u242. I agree. 8177334 looks sugnificant, but I don't know why. All we have is "We should upgrade this to the latest stable version in JDK 11." > 15. JDK-8217676 > Upgrade libpng to 1.6.37 > > This needs some minor work still, but should be able to be pushed to > 8u232 during rampdown. OK. > 16. JDK-8228469 > (tz) Upgrade time-zone data to tzdata2019b > > This is a late arrival that isn't in 8u or 11u, but we should be able to > get it into both during rampdown. OK. > 17. JDK-8229868 > Update Apache Santuario TPRM version > > This should be combined with JDK-8219013 (#3) > > 18. JDK-8222108 > > Reduce minRefreshTime for updating remote printer list on Windows > > As with JDK-8217676, the patch needs some minor changes but should be > possible to include during rampdown. This doesn't look to be very important. Please consider if it's worth doing in the critical phase. > My current thinking is: > > * Suitable for rampdown > - #1, #7, #8, #13, #15, #16, #18 > > * Defer to 8u242 > - Access bridge patches (#2, #11) > - Apache Santuario work (#3, #4, #6, #10, #14, #17) > - AWT bugs (#5, #9) > - Deadlock bug (#12) > > Other bugs may be considered during rampdown, but they should be > regression fixes or minor bugs / test issues. Feature work should now be > focused on 8u242. I agree. > I think things look better than the last cycle, but we are still seeing > too many patches towards the end of the development period. If you want > to target something for 8u242, now is the time to start working on it. > For 8u232, the primary focus should be testing to make sure there are no > major regressions. I agree with that too. Thank you for this very clear summary. It must have been a significant effort. -- 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 andrey at azul.com Tue Sep 3 11:53:25 2019 From: andrey at azul.com (Andrey Petushkov) Date: Tue, 3 Sep 2019 11:53:25 +0000 Subject: [8u] [JFR] RFR: JFR backports from 11.0.4 Message-ID: Dear All, could you please consider the following set of backports of the JFR fixes from 11.0.4 release into 8u incubator baseline: 8185525: Add JFR event for DictionarySizes 8213448: [TESTBUG] enhance jfr/jvm/TestDumpOnCrash 8215727: Restore JFR thread sampler loop to old / previous behavior 8216283: Allow shorter method sampling interval than 10 ms 8217362: Emergency dump does not work when disk=false is set 8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64 8219566: JFR did not collect call stacks when MaxJavaStackTraceDepth is set to zero 8219997: [TESTBUG] Create test for JFR events in Docker container: CPU, Memory and Process Info 8220293: Deadlock in JFR string pool 8220555: JFR tool shows potentially misleading message when it cannot access a file 8220657: JFR.dump does not work when filename is set 8221569: JFR tool produces incorrect output when both --categories and --events are specified 8221711: [TESTBUG] create more tests for JFR in container environment 8222888: [TESTBUG] docker/TestJFREvents.java fails due to "RuntimeException: JAVA_MAIN_CLASS_ is not defined" 8223438: add VirtualizationInformation JFR event 8223599: minimal build fails after JDK-8185525 8224217: RecordingInfo should use textual representation of path 8225310: JFR crashed in JfrPeriodicEventSet::requestProtectionDomainCacheTableStatistics() the webrev is at http://cr.openjdk.java.net/~apetushkov/jfr_backports_katya/11.0.4/ all relevant tests have passed on all supported platforms the individual patches can be found at http://cr.openjdk.java.net/~apetushkov/jfr_backports_katya/11.0.4/patches/ the order to apply is: - hotspot 8217362 8219566 8220293 8219241 8223438 8185525 8223599 8225310 8219997 8221711 8222888 8215727 8216283 - jdk 8213448 8220555 8217362 8221569 8223438 8185525 8224217 8216283 8220657 Thanks, Andrey From zgu at redhat.com Tue Sep 3 12:24:07 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 3 Sep 2019 08:24:07 -0400 Subject: [8u] 8178870: instrumentation.retransformClasses cause coredump In-Reply-To: References: <6d646175-68e2-b280-6475-cd97f2e5d438@redhat.com> <7003c233-d891-b11b-3426-f9b6f7de2d8f@redhat.com> <0bfedafb-f31c-6278-31da-56cb4abc1d34@redhat.com> Message-ID: <03cd4243-91e7-fb9f-5b5b-bbacf1de547d@redhat.com> Hi Andrew >> >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8178870-8u/webrev.01/ >> >> Thanks, >> >> -Zhengyu >> >> >> >>> > > This seems to contain 3 bug IDs. Please post a clean webrev for 8178870 > once 8155951 is pushed. Yes. JDK-8155951 is prerequisite and its changeset contains two bug fixes. Updated: http://cr.openjdk.java.net/~zgu/JDK-8178870-8u/webrev.02/ Thanks, -Zhengyu > > Thanks, > From stooke at redhat.com Tue Sep 3 12:32:51 2019 From: stooke at redhat.com (Simon Tooke) Date: Tue, 3 Sep 2019 08:32:51 -0400 Subject: [8u] RFR Backport of 8203324: Use out of scope in getMacOSXLocale of java_props_macosx.c:120 In-Reply-To: <58c74191-8c9b-20d8-c3b8-5429563631f0@redhat.com> References: <58c74191-8c9b-20d8-c3b8-5429563631f0@redhat.com> Message-ID: <6f96b5ae-de8c-8bc4-0d85-e09beee38dc5@redhat.com> On 9/2/2019 1:48 PM, Andrew John Hughes wrote: > > On 20/08/2019 14:49, Simon Tooke wrote: >> 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 >> >> >> > Looks sensible to me. Approved. > > Out of interest, is it possible to build on Mac OS X at present? I > remember you posted another patch to work on this. > > Thanks, I have an updated version of the patch [1], and I've actually run tier1 on it, although there are failures [2]. It's unclear which failures I should be expecting, but the patch does produce a very useable JDK8u on current macOS using current Xcode. I originally put the macOS patch out as a backport, but (since it's just a small subset of the backport) perhaps I should do it as a new issue that references the upstream issue? [1] https://github.com/stooke/jdk8u-xcode10/tree/master/jdk8u-patch [2] https://github.com/stooke/jdk8u-xcode10/blob/master/current-jdk8u-tier1-failures.txt From zgu at redhat.com Tue Sep 3 12:56:57 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 3 Sep 2019 08:56:57 -0400 Subject: [8u] 8222108: Reduce minRefreshTime for updating remote printer list on Windows In-Reply-To: References: <3b26ee23-1124-7538-6ba0-d5f021fdd12e@redhat.com> Message-ID: On 9/3/19 1:12 AM, Andrew John Hughes wrote: > > > On 27/08/2019 14:39, Zhengyu Gu wrote: >> >> 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 > > This mostly looks ok, but one change seems to have been missed; the > prevRemotePrinters variable is not removed. Was there a reason for this? My bad. Updated: http://cr.openjdk.java.net/~zgu/JDK-8222108-8u/webrev.01/ Retested on Windows x86_64 Thanks, -Zhengyu > > Moreover, it seems the constructor body, which uses prevRemotePrinters, > was not removed as part of backporting JDK-8221412. > > --- 8222108.11u 2019-09-03 05:59:15.876734203 +0100 > +++ 8222108.8u 2019-08-27 13:48:07.000000000 +0100 > -@@ -398,60 +400,38 @@ > +@@ -394,61 +396,40 @@ > count of printer status changes(add\remove) and based on it > update the printers > list. > */ > -- class RemotePrinterChangeListener implements Runnable { > -- private String[] prevRemotePrinters; > -+ class RemotePrinterChangeListener implements Comparator, > Runnable { > +- class RemotePrinterChangeListener extends Thread { > ++ class RemotePrinterChangeListener extends Thread implements > Comparator{ > + private String[] prevRemotePrinters; > > RemotePrinterChangeListener() { > + prevRemotePrinters = getRemotePrintersNames(); > } > > - private boolean doCompare(String[] str1, String[] str2) { > From zgu at redhat.com Tue Sep 3 14:18:47 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 3 Sep 2019 10:18:47 -0400 Subject: [8u] 8217676: Upgrade libpng to 1.6.37 In-Reply-To: References: <42cc1803-6f71-ba9d-d262-f79522071f10@redhat.com> Message-ID: <4a2daffd-c776-25fa-8f08-ac61949f4caa@redhat.com> Hi Andrew, > The license patch seems to miss some header lines when compared with > 11u, and also removes a section about trademarks and export control that > isn't altered in the 11u version. How was it applied? > > I've attached what I get from manually applying the 11u patch to > THIRD_PARTY_README. This diffs cleanly against libpng.md in 11u. > Updated all THIRD_PARTY_README files with your patch. http://cr.openjdk.java.net/~zgu/JDK-8217676-8u/v2/ Retested with jdk_imageio. Thanks, -Zhengyu > Thanks, > From hohensee at amazon.com Tue Sep 3 14:20:05 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 3 Sep 2019 14:20:05 +0000 Subject: [8u] RFR 8229501: jdk/test/lib/testlibrary/ClassFileInstaller.java should match hotspot//test/testlibrary version In-Reply-To: <37f5f0c8-154d-e066-95f4-77b5f6a9afe1@redhat.com> References: <0E64BD39-BFDA-4506-BD8B-7B63A7BBD0C8@amazon.com> <01cc5f7a-01ed-d712-883e-0cec87c09e8b@redhat.com> <37f5f0c8-154d-e066-95f4-77b5f6a9afe1@redhat.com> Message-ID: <659A8743-4E12-42C1-8CEA-E8996959690D@amazon.com> Works for us. Thanks, Paul ?On 9/2/19, 9:00 AM, "Andrew John Hughes" wrote: On 27/08/2019 21:05, Hohensee, Paul wrote: > 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 don't believe I was suggesting it was. 8189762 was over five years after 8005056. 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? Neither. There is no reason to manually file backport bugs, as the bug system will handle this, and a new bug ID would lose any connection between the changes and their original source. Looking at this again, it appears that the JDK version already has the same fix to ClassInstaller.java in 8005056, but slightly different code. This is the result of JDK-8027803 [0] [1]. So we actually only need to sync the changes in 8189762. I suggest: https://cr.openjdk.java.net/~andrew/openjdk8/8189762-jdk/webrev.01/ which then leaves the difference between the two versions as just the variation in the fixes: $ diff -u test/lib/testlibrary/ClassFileInstaller.java ../hotspot/test/testlibrary/ClassFileInstaller.java --- test/lib/testlibrary/ClassFileInstaller.java 2019-09-02 16:44:24.993301954 +0100 +++ ../hotspot/test/testlibrary/ClassFileInstaller.java 2019-06-04 23:50:49.082742173 +0100 @@ -246,9 +246,8 @@ } else { // Create the class file's package directory Path p = Paths.get(pathName); - Path parent = p.getParent(); - if (parent != null) { - Files.createDirectories(parent); + if (pathName.contains("/")) { + Files.createDirectories(p.getParent()); } // Create the class file Files.copy(is, p, StandardCopyOption.REPLACE_EXISTING); I think that can stay. I actually think the JDK fix is a little nicer. If you're happy with that, I'll push it. > > Thanks, > > Paul > [0] https://bugs.openjdk.java.net/browse/JDK-8027803 [1] https://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/c04e46dbfea8 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 jvanek at redhat.com Tue Sep 3 14:37:11 2019 From: jvanek at redhat.com (Jiri Vanek) Date: Tue, 3 Sep 2019 16:37:11 +0200 Subject: [8u] RFR Backport JDK-8154313, Generated javadoc scattered all over the place In-Reply-To: <6a422810d25f0c9a26283c4a16a0ea202d49cb47.camel@redhat.com> References: <26c825e0e54df08018dff414850ae7d418818433.camel@redhat.com> <5885ad80-e984-ab0e-e77f-38182d8ffc46@redhat.com> <6406f01ce84eb261c2ef633b767db191fc2d49bd.camel@redhat.com> <2be84fea-875d-6765-e551-19c8a71279ff@redhat.com> <6a422810d25f0c9a26283c4a16a0ea202d49cb47.camel@redhat.com> Message-ID: <4faf46fe-6aa0-311f-9578-cfc1cba4619f@redhat.com> On 9/2/19 6:55 PM, Severin Gehwolf wrote: > On Mon, 2019-09-02 at 18:39 +0200, Jiri Vanek wrote: >>> make/Main.gmk: >>> >>> 202 # Remove everything, except the output from configure. >>> 203 clean: clean-langtools clean-corba clean-jaxp clean-jaxws clean-hotspot clean-jdk clean-nashorn clean-images clean-overlay-images clean-bootcycle-build clean-docs clean-docs-zip clean-test >>> >>> You are adding clean-docs-zip to the default "clean" target. Yet, "make >>> docs" doesn't seem to build docs-zip. That seems inconsistent. I'd >>> require an explicit "make clean-docs-zip" call. I.e. don't add it to >>> the list of dep-targets for "make clean". >> >> Isn't maybe better to add docs-zip to default docs target? > > I'm not sure. My concern is about people who are using "make docs" now > and not breaking their use-cases. Even if that just means longer build > time in reality. It's not unreasonable to assume "make docs" is > potentially more widely used. As docs-zip is new, it cannot be used. > I'd error on the side of caution for both cases: "make clean" and "make > docs". > fair enough. Ty! > Thanks, > Severin > -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek at redhat.com M: +420775390109 From jvanek at redhat.com Tue Sep 3 15:14:31 2019 From: jvanek at redhat.com (Jiri Vanek) Date: Tue, 3 Sep 2019 17:14:31 +0200 Subject: [8u] RFR Backport JDK-8154313, Generated javadoc scattered all over the place In-Reply-To: <6406f01ce84eb261c2ef633b767db191fc2d49bd.camel@redhat.com> References: <26c825e0e54df08018dff414850ae7d418818433.camel@redhat.com> <5885ad80-e984-ab0e-e77f-38182d8ffc46@redhat.com> <6406f01ce84eb261c2ef633b767db191fc2d49bd.camel@redhat.com> Message-ID: On 9/2/19 6:16 PM, Severin Gehwolf wrote: > Hi, > > On Thu, 2019-08-29 at 12:31 +0200, Jiri Vanek wrote: >> Updated: >>>> http://cr.openjdk.java.net/~jvanek/8154313/ ( >>>> https://bugs.openjdk.java.net/browse/JDK-8154313) >> http://cr.openjdk.java.net/~jvanek/8154313/webrev/ > > Thanks for the update. I should note that this backport introduces the > new target as 'docs-zip' right away instead of the original name of > 'zip-docs' in JDK 9 which then got renamed to 'docs-zip' via JDK- > 8168772. Not sure if that was already the case for v1 of the webrev. > >>> >>> 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. > > What do you mean by "And never was."? Are you suggesting it doesn't > work on JDK 9+? If so JDK-8168772 seems a likely culprit. Anyway... > >>> 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! >> > > make/Main.gmk: > > 202 # Remove everything, except the output from configure. > 203 clean: clean-langtools clean-corba clean-jaxp clean-jaxws clean-hotspot clean-jdk clean-nashorn clean-images clean-overlay-images clean-bootcycle-build clean-docs clean-docs-zip clean-test > > You are adding clean-docs-zip to the default "clean" target. Yet, "make > docs" doesn't seem to build docs-zip. That seems inconsistent. I'd > require an explicit "make clean-docs-zip" call. I.e. don't add it to > the list of dep-targets for "make clean". > > 257 .PHONY: langtools corba jaxp jaxws hotspot jdk nashorn images overlay-images install test docs docs-zip docs-zip-only > 258 .PHONY: langtools-only corba-only jaxp-only jaxws-only hotspot-only jdk-only nashorn-only images-only overlay-images-only install-only test-only docs-only > > Style: It seems all 'foo-only' targets are on one line, and 'foo' on > another. Please move the docs-zip-only addition to line 258. > > Looks OK otherwise. http://cr.openjdk.java.net/~jvanek/8154313/webrev/ updated TY! J. From sgehwolf at redhat.com Tue Sep 3 15:29:14 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 03 Sep 2019 17:29:14 +0200 Subject: [8u] RFR Backport JDK-8154313, Generated javadoc scattered all over the place In-Reply-To: References: <26c825e0e54df08018dff414850ae7d418818433.camel@redhat.com> <5885ad80-e984-ab0e-e77f-38182d8ffc46@redhat.com> <6406f01ce84eb261c2ef633b767db191fc2d49bd.camel@redhat.com> Message-ID: <5a5b4981c6c1497b593aa245830a45efc5a26803.camel@redhat.com> On Tue, 2019-09-03 at 17:14 +0200, Jiri Vanek wrote: > On 9/2/19 6:16 PM, Severin Gehwolf wrote: > > Hi, > > > > On Thu, 2019-08-29 at 12:31 +0200, Jiri Vanek wrote: > > > Updated: > > > > > http://cr.openjdk.java.net/~jvanek/8154313/ ( > > > > > https://bugs.openjdk.java.net/browse/JDK-8154313) > > > http://cr.openjdk.java.net/~jvanek/8154313/webrev/ > > > > Thanks for the update. I should note that this backport introduces the > > new target as 'docs-zip' right away instead of the original name of > > 'zip-docs' in JDK 9 which then got renamed to 'docs-zip' via JDK- > > 8168772. Not sure if that was already the case for v1 of the webrev. > > > > > > 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. > > > > What do you mean by "And never was."? Are you suggesting it doesn't > > work on JDK 9+? If so JDK-8168772 seems a likely culprit. Anyway... > > > > > > 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! > > > > > > > make/Main.gmk: > > > > 202 # Remove everything, except the output from configure. > > 203 clean: clean-langtools clean-corba clean-jaxp clean-jaxws clean-hotspot clean-jdk clean-nashorn clean-images clean-overlay-images clean-bootcycle-build clean-docs clean-docs-zip clean-test > > > > You are adding clean-docs-zip to the default "clean" target. Yet, "make > > docs" doesn't seem to build docs-zip. That seems inconsistent. I'd > > require an explicit "make clean-docs-zip" call. I.e. don't add it to > > the list of dep-targets for "make clean". > > > > 257 .PHONY: langtools corba jaxp jaxws hotspot jdk nashorn images overlay-images install test docs docs-zip docs-zip-only > > 258 .PHONY: langtools-only corba-only jaxp-only jaxws-only hotspot-only jdk-only nashorn-only images-only overlay-images-only install-only test-only docs-only > > > > Style: It seems all 'foo-only' targets are on one line, and 'foo' on > > another. Please move the docs-zip-only addition to line 258. > > > > Looks OK otherwise. > > http://cr.openjdk.java.net/~jvanek/8154313/webrev/ > > updated This URL gives me 404. I assume it's this? http://cr.openjdk.java.net/~jvanek/8154313/ --^ That one looks good. Thanks, Severin From jvanek at redhat.com Tue Sep 3 15:48:32 2019 From: jvanek at redhat.com (Jiri Vanek) Date: Tue, 3 Sep 2019 17:48:32 +0200 Subject: [8u] RFR Backport JDK-8154313, Generated javadoc scattered all over the place In-Reply-To: <5a5b4981c6c1497b593aa245830a45efc5a26803.camel@redhat.com> References: <26c825e0e54df08018dff414850ae7d418818433.camel@redhat.com> <5885ad80-e984-ab0e-e77f-38182d8ffc46@redhat.com> <6406f01ce84eb261c2ef633b767db191fc2d49bd.camel@redhat.com> <5a5b4981c6c1497b593aa245830a45efc5a26803.camel@redhat.com> Message-ID: <4dd8b5df-3284-41dd-8fa1-9061e016cedf@redhat.com> > > http://cr.openjdk.java.net/~jvanek/8154313/ > > --^ That one looks good. > Yup. Tah is it. Sorry for bad url. Thank you for review. Are you an commiter? If so, can you please push on my behalf? From sgehwolf at redhat.com Tue Sep 3 15:50:29 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 03 Sep 2019 17:50:29 +0200 Subject: [8u] RFR: 8213734: SAXParser.parse(File, ..) does not close resources when Exception occurs. In-Reply-To: <0a64931ab640afd557f4bd46aa7bb05512bc79d6.camel@redhat.com> References: <0a64931ab640afd557f4bd46aa7bb05512bc79d6.camel@redhat.com> Message-ID: On Mon, 2019-08-26 at 17:54 +0200, Severin Gehwolf wrote: > 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 { > Gentle reminder. Thanks, Severin > Thoughts? > > Thanks, > Severin From sgehwolf at redhat.com Tue Sep 3 16:08:35 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 03 Sep 2019 18:08:35 +0200 Subject: [8u] RFR Backport JDK-8154313, Generated javadoc scattered all over the place In-Reply-To: <4dd8b5df-3284-41dd-8fa1-9061e016cedf@redhat.com> References: <26c825e0e54df08018dff414850ae7d418818433.camel@redhat.com> <5885ad80-e984-ab0e-e77f-38182d8ffc46@redhat.com> <6406f01ce84eb261c2ef633b767db191fc2d49bd.camel@redhat.com> <5a5b4981c6c1497b593aa245830a45efc5a26803.camel@redhat.com> <4dd8b5df-3284-41dd-8fa1-9061e016cedf@redhat.com> Message-ID: <53908e96663b8e8df468fafc0f7864217b392fef.camel@redhat.com> On Tue, 2019-09-03 at 17:48 +0200, Jiri Vanek wrote: > > http://cr.openjdk.java.net/~jvanek/8154313/ > > > > --^ That one looks good. > > > > Yup. Tah is it. Sorry for bad url. Thank you for review. Are you an commiter? If so, can you please > push on my behalf? I am committer and can help getting this pushed, but JDK 8u is currently in rampdown[1]. Before you push a Fix Request comment and a label is needed to request approval of the fix to JDK 8u. See: https://wiki.openjdk.java.net/display/jdk8u Once you have jdk8u-fix-yes, we need to coordinate with maintainers when and where to push. Please let me know when you have approval and then send me a proper HG exported patch which passes jcheck and I'll push it for you. Thanks, Severin [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-September/010202.html From gnu.andrew at redhat.com Wed Sep 4 04:36:48 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 4 Sep 2019 05:36:48 +0100 Subject: 8u232 Rampdown: Bug Triage In-Reply-To: <7f18fe0e-288d-8c14-f4aa-de168ea4742b@redhat.com> References: <7f18fe0e-288d-8c14-f4aa-de168ea4742b@redhat.com> Message-ID: <892a5204-59a4-c346-93c9-8369c39c6fee@redhat.com> On 03/09/2019 10:53, Andrew Haley wrote: snip... > >> My current thinking is: >> >> * Suitable for rampdown >> - #1, #7, #8, #13, #15, #16, #18 >> >> * Defer to 8u242 >> - Access bridge patches (#2, #11) >> - Apache Santuario work (#3, #4, #6, #10, #14, #17) >> - AWT bugs (#5, #9) >> - Deadlock bug (#12) So, based on your comments, I would update this to: * Suitable for rampdown - #13, #15, #16, #18 * Defer to 8u242 - Access bridge patches (#2, #11) - Apache Santuario work (#3, #4, #6, #10, #14, #17) - AWT bugs (#5, #9) - Deadlock bug (#12) - Gtk+ default switch (#1) - Javadoc correction (#7) - "file" URLs (#8) I agree with you about #1, in retrospect. I guess I was just a little disappointed that it seemed to have been missed, when it could have been an easy backport early in the cycle. I'm not sure why I added #7 to the rampdown list when I also said we should wait for the online version, so thanks for catching that. As #8 depends on another bug (backporting ClassFileInstaller changes), I'm now tending towards punting that to 8u242 as well, but I'm open to someone making a case for inclusion if the bug warrants it. Of the remaining four marked for rampdown, three are pretty much done and would have been pushed if not for some minor issues found in the review process. The only one that actually needs backporting from scratch is the tzdata one, where there's a precedent for that coming in late with the security changes. I'll get onto that for 8u & 11u as soon as rampdown of 8u is completed. >> >> Other bugs may be considered during rampdown, but they should be >> regression fixes or minor bugs / test issues. Feature work should now be >> focused on 8u242. > > I agree. > >> I think things look better than the last cycle, but we are still seeing >> too many patches towards the end of the development period. If you want >> to target something for 8u242, now is the time to start working on it. >> For 8u232, the primary focus should be testing to make sure there are no >> major regressions. > > I agree with that too. > > Thank you for this very clear summary. It must have been a significant > effort. > Thanks. It did take longer than I initially expected, but it was also helpful to me in organising everything. -- 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 Sep 4 04:39:18 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 4 Sep 2019 05:39:18 +0100 Subject: [8u] RFR Backport JDK-8154313, Generated javadoc scattered all over the place In-Reply-To: <53908e96663b8e8df468fafc0f7864217b392fef.camel@redhat.com> References: <26c825e0e54df08018dff414850ae7d418818433.camel@redhat.com> <5885ad80-e984-ab0e-e77f-38182d8ffc46@redhat.com> <6406f01ce84eb261c2ef633b767db191fc2d49bd.camel@redhat.com> <5a5b4981c6c1497b593aa245830a45efc5a26803.camel@redhat.com> <4dd8b5df-3284-41dd-8fa1-9061e016cedf@redhat.com> <53908e96663b8e8df468fafc0f7864217b392fef.camel@redhat.com> Message-ID: On 03/09/2019 17:08, Severin Gehwolf wrote: > On Tue, 2019-09-03 at 17:48 +0200, Jiri Vanek wrote: >>> http://cr.openjdk.java.net/~jvanek/8154313/ >>> >>> --^ That one looks good. >>> >> >> Yup. Tah is it. Sorry for bad url. Thank you for review. Are you an commiter? If so, can you please >> push on my behalf? > > I am committer and can help getting this pushed, but JDK 8u is > currently in rampdown[1]. Before you push a Fix Request comment and a > label is needed to request approval of the fix to JDK 8u. See: > https://wiki.openjdk.java.net/display/jdk8u > > Once you have jdk8u-fix-yes, we need to coordinate with maintainers > when and where to push. Please let me know when you have approval and > then send me a proper HG exported patch which passes jcheck and I'll > push it for you. > > Thanks, > Severin > > [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-September/010202.html > Thanks for explaining the approval process. I'd say this one definitely comes under new features rather than a regression or minor bug fix, so it should wait until we open for 8u242. I'll look over it once rampdown is complete. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From doko at ubuntu.com Wed Sep 4 05:54:22 2019 From: doko at ubuntu.com (Matthias Klose) Date: Wed, 4 Sep 2019 07:54:22 +0200 Subject: 8u232 Rampdown: Bug Triage In-Reply-To: References: Message-ID: <78b81391-3eec-34a2-acfd-c42875a1534f@ubuntu.com> On 03.09.19 07:30, Andrew John Hughes wrote: > Hi all, > > We have reached the point of rampdown for 8u232 and need to decide which > issues are still worth trying to push into that release and which should > be deferred until 8u242. > > I've been going through the list of bugs which are marked as fixed in > Oracle's proprietary 8u231/2 [0] to see what is still missing in OpenJDK 8u: > > 1. JDK-8222496/JDK-8198649 > "[8u] Switch on GTK3 as a default GTK L&F in client-libs" > > This is 8222496 in 8u, but 8198649 in 11u just for extra confusion. I've > see no review or approval request for this yet. As a simple default > change, I'm happy for this to still go in early in rampdown while there > is time for any side-effects to be tested for. > > It's a clean backport, so I've flagged it for approval. Is it safe to backport this one? I remember that the we reverted back the Debian/Ubuntu builds to use GTK2 by default because of rendering issues. I can't remember the details, but maybe Tiago could point to these issues. Matthias From neugens at redhat.com Wed Sep 4 09:52:41 2019 From: neugens at redhat.com (Mario Torre) Date: Wed, 4 Sep 2019 11:52:41 +0200 Subject: [8u] [JFR] RFR: JFR backports from 11.0.4 In-Reply-To: References: Message-ID: <72db089a-fb9f-e088-8fcd-8a6e25bec29b@redhat.com> On 03/09/2019 13:53, Andrey Petushkov wrote: > Dear All, > > could you please consider the following set of backports of the JFR fixes from 11.0.4 release into 8u incubator baseline: This seems good, the only nit I have now is that some of those changes may break zero again, I think it may make sense to fix it in this patch set instead of filing a dedicated bug report later. See for example: JDK-8219241 +void VM_Version::print_platform_virtualization_info(outputStream* st) { etc.. 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 Wed Sep 4 13:11:03 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 4 Sep 2019 09:11:03 -0400 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: Rebased patch on top of Andrew Hughes' ClassFileInstaller patch [1] Webrev: http://cr.openjdk.java.net/~zgu/JDK-8216401-8u/webrev.01/ Test: Reran JarClassPathFileEntry.java test. Thanks, -Zhengyu [1] https://cr.openjdk.java.net/~andrew/openjdk8/8189762-jdk/webrev.01/ On 8/13/19 4:09 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 hohensee at amazon.com Wed Sep 4 13:47:35 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 4 Sep 2019 13:47:35 +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> <934D8BCF-E52F-4E38-AB0C-38552083AE6F@amazon.com> <33a80c36-82aa-aa53-c06e-e70b62611593@redhat.com> Message-ID: <59E8A403-649D-4A4C-98CB-787DD44D2FB5@amazon.com> Looks good. Thanks, Paul ?On 9/4/19, 6:11 AM, "Zhengyu Gu" wrote: Rebased patch on top of Andrew Hughes' ClassFileInstaller patch [1] Webrev: http://cr.openjdk.java.net/~zgu/JDK-8216401-8u/webrev.01/ Test: Reran JarClassPathFileEntry.java test. Thanks, -Zhengyu [1] https://cr.openjdk.java.net/~andrew/openjdk8/8189762-jdk/webrev.01/ On 8/13/19 4:09 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 zgu at redhat.com Wed Sep 4 13:53:58 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 4 Sep 2019 09:53:58 -0400 Subject: [8u] RFR 8216401: Allow "file:" URLs in Class-Path of local JARs In-Reply-To: <59E8A403-649D-4A4C-98CB-787DD44D2FB5@amazon.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> <59E8A403-649D-4A4C-98CB-787DD44D2FB5@amazon.com> Message-ID: <0ea9c216-e2a3-c0c6-3fec-40d6e1d05bbc@redhat.com> Thanks, Paul -Zhengyu On 9/4/19 9:47 AM, Hohensee, Paul wrote: > Looks good. > > Thanks, > > Paul > > ?On 9/4/19, 6:11 AM, "Zhengyu Gu" wrote: > > Rebased patch on top of Andrew Hughes' ClassFileInstaller patch [1] > > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8216401-8u/webrev.01/ > > Test: > Reran JarClassPathFileEntry.java test. > > Thanks, > > -Zhengyu > > > [1] https://cr.openjdk.java.net/~andrew/openjdk8/8189762-jdk/webrev.01/ > > On 8/13/19 4:09 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 andrey at azul.com Wed Sep 4 14:09:10 2019 From: andrey at azul.com (Andrey Petushkov) Date: Wed, 4 Sep 2019 14:09:10 +0000 Subject: [8u] [JFR] RFR: JFR backports from 11.0.4 In-Reply-To: <72db089a-fb9f-e088-8fcd-8a6e25bec29b@redhat.com> References: <72db089a-fb9f-e088-8fcd-8a6e25bec29b@redhat.com> Message-ID: <4DE97FAF-FB3A-41C5-BCC2-1BE799E9AA6C@azul.com> Hi Mario, zero build is fine (e.g. mentioned method has default no-op implementation in vm_version.hpp) Andrey > On 4 Sep 2019, at 12:52, Mario Torre wrote: > > On 03/09/2019 13:53, Andrey Petushkov wrote: >> Dear All, >> >> could you please consider the following set of backports of the JFR fixes from 11.0.4 release into 8u incubator baseline: > > This seems good, the only nit I have now is that some of those changes > may break zero again, I think it may make sense to fix it in this patch > set instead of filing a dedicated bug report later. > > See for example: > > JDK-8219241 > > +void VM_Version::print_platform_virtualization_info(outputStream* st) { > > etc.. > > 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 Wed Sep 4 14:46:29 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 4 Sep 2019 15:46:29 +0100 Subject: 8u232 Rampdown: Bug Triage In-Reply-To: <78b81391-3eec-34a2-acfd-c42875a1534f@ubuntu.com> References: <78b81391-3eec-34a2-acfd-c42875a1534f@ubuntu.com> Message-ID: <112fe4fb-7668-f937-d61e-b3264905effc@redhat.com> On 04/09/2019 06:54, Matthias Klose wrote: > On 03.09.19 07:30, Andrew John Hughes wrote: >> Hi all, >> >> We have reached the point of rampdown for 8u232 and need to decide which >> issues are still worth trying to push into that release and which should >> be deferred until 8u242. >> >> I've been going through the list of bugs which are marked as fixed in >> Oracle's proprietary 8u231/2 [0] to see what is still missing in >> OpenJDK 8u: >> >> 1. JDK-8222496/JDK-8198649 >> "[8u] Switch on GTK3 as a default GTK L&F in client-libs" >> >> This is 8222496 in 8u, but 8198649 in 11u just for extra confusion. I've >> see no review or approval request for this yet. As a simple default >> change, I'm happy for this to still go in early in rampdown while there >> is time for any side-effects to be tested for. >> >> It's a clean backport, so I've flagged it for approval. > > Is it safe to backport this one? I remember that the we reverted back > the Debian/Ubuntu builds to use GTK2 by default because of rendering > issues.? I can't remember the details, but maybe Tiago could point to > these issues. > > Matthias aph raised the same issue and we've bumped it to 8u242. It's a clean backport so I'll push it early once we've forked and then hopefully you'll have plenty of time to test. In the worse case, reverting is also trivial and the version can also be selected via a runtime property. 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 neugens at redhat.com Wed Sep 4 14:47:59 2019 From: neugens at redhat.com (Mario Torre) Date: Wed, 4 Sep 2019 16:47:59 +0200 Subject: [8u] [JFR] RFR: JFR backports from 11.0.4 In-Reply-To: <4DE97FAF-FB3A-41C5-BCC2-1BE799E9AA6C@azul.com> References: <72db089a-fb9f-e088-8fcd-8a6e25bec29b@redhat.com> <4DE97FAF-FB3A-41C5-BCC2-1BE799E9AA6C@azul.com> Message-ID: Awesome, thanks for checking zero. As discussed offline, we have a few backports that were directly backported to 8u without first being in 11u: https://bugs.openjdk.java.net/browse/JDK-8185525 https://bugs.openjdk.java.net/browse/JDK-8223599 https://bugs.openjdk.java.net/browse/JDK-8225310 https://bugs.openjdk.java.net/browse/JDK-8221711 https://bugs.openjdk.java.net/browse/JDK-8222888 https://bugs.openjdk.java.net/browse/JDK-8216283 https://bugs.openjdk.java.net/browse/JDK-8220555 https://bugs.openjdk.java.net/browse/JDK-8217362 https://bugs.openjdk.java.net/browse/JDK-8221569 https://bugs.openjdk.java.net/browse/JDK-8224217 A couple of those are wither being worked on or of interest for 11u, so they should be fine, some aren't and while may not be critical I think they are nice to have (like the container tests), so I would expect all of them to be backported to 11u. Since this is a staging repository we may go ahead and push them and work on the backport to 11 afterward, but I would prefer to not create a discrepancy at this moment, so if possible we should work on the backports to 11 first. Cheers, Mario On Wed, Sep 4, 2019 at 4:09 PM Andrey Petushkov wrote: > > Hi Mario, > > zero build is fine (e.g. mentioned method has default no-op implementation in vm_version.hpp) > > Andrey > > > On 4 Sep 2019, at 12:52, Mario Torre wrote: > > > > On 03/09/2019 13:53, Andrey Petushkov wrote: > >> Dear All, > >> > >> could you please consider the following set of backports of the JFR fixes from 11.0.4 release into 8u incubator baseline: > > > > This seems good, the only nit I have now is that some of those changes > > may break zero again, I think it may make sense to fix it in this patch > > set instead of filing a dedicated bug report later. > > > > See for example: > > > > JDK-8219241 > > > > +void VM_Version::print_platform_virtualization_info(outputStream* st) { > > > > etc.. > > > > 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 mbalao at redhat.com Wed Sep 4 15:58:49 2019 From: mbalao at redhat.com (Martin Balao) Date: Wed, 4 Sep 2019 12:58:49 -0300 Subject: [8u] [JFR] RFR 8230448: JFRSecurityTestSuite.java is failing on Windows In-Reply-To: References: Message-ID: <968cdc98-0512-fdfa-f4d0-8130e8b3c766@redhat.com> On 9/2/19 12:50 PM, Jaroslav Bachor?k wrote: > Hi, > > please, review a simple test fix for the JFR backport related code. > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8230448 > Webrev: http://cr.openjdk.java.net/~jbachorik/8230448/webrev.00/ > > Thanks! > > -JB- > Looks good to me. Thanks for fixing this one. From mbalao at redhat.com Wed Sep 4 16:04:22 2019 From: mbalao at redhat.com (Martin Balao) Date: Wed, 4 Sep 2019 13:04:22 -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: References: Message-ID: <96f63b0d-dace-59ec-ae95-d785a865270d@redhat.com> On 9/3/19 12:44 AM, Andrew John Hughes wrote: > > > Bringing Convert.java in here is ok because we can't backport the > feature changeset "8171277: Elliptic Curves for Security in Crypto", > but, in cases like this, please explain why you have chosen to include > additional files/hunks beyond the original changes, so reviewers don't > have to duplicate the work of finding out the source of these changes. Right. > > Approved. > Would you mind pushing this on my behalf? (as I don't have commit permissions) Thanks, Martin.- From gnu.andrew at redhat.com Wed Sep 4 16:52:56 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 4 Sep 2019 17:52:56 +0100 Subject: Request for Approval: Backport of 8147611: G1 - Missing memory barrier in start_cset_region_for_worker In-Reply-To: References: Message-ID: <91334f8c-2782-0ea3-5363-7d130e64043e@redhat.com> On 10/06/2019 13:47, Yangfei (Felix) wrote: > Hi, > > > > Please approve the backport of 8147611 to 8u-dev. > > This bug is biting one of our product which is based on the aarch64 Linux platform. > > As the patch changes shared code, it's better to backport it to the jdk8u master repo first. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8147611 > > JDK9 Changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/8fcd5cba7938 > > > > The code change is trivial and should be easy for it to be applied to the jdk8u master repo. > > > > Thanks, > > Felix > There doesn't seem to be a patch here for review. I applied the 11u version and the hunk had to be manually applied instead because of whitespace differences. I've pushed it now, but in future, cases like this should be posted for review before seeking approval. Skipping the review process is only applicable when the patch applies cleanly, after file paths are adjusted. The fix request comment on the bug should detail whether it applies cleanly or not, and link to a review thread if not. Also note that I gave approval for this on 2019-06-12, but it has never been committed in the subsequent two and half months. -- 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 Sep 4 19:13:30 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 4 Sep 2019 20:13:30 +0100 Subject: [RAMPDOWN] 8u & 8u-dev still FROZEN Message-ID: All pending approved changes have now been pushed to the 8u-dev tree. I have tagged this locally as jdk8u232-b05 and will push this once tested. I have also requested that the ops team switch 8u-dev to openjdk8u242. Once I have confirmation of this, 8u-dev will be unfrozen for approved commits for 8u242. Once jdk8u232-b05 is released, 8u will be open for 8u232 critical fixes which have the label jdk8u-critical-yes. This can be requested by adding the label jdk8u-critical-request. 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 Sep 4 19:15:42 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 4 Sep 2019 20:15:42 +0100 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: <96f63b0d-dace-59ec-ae95-d785a865270d@redhat.com> References: <96f63b0d-dace-59ec-ae95-d785a865270d@redhat.com> Message-ID: <28d71e06-2014-1e0f-e59e-9414aec896e6@redhat.com> On 04/09/2019 17:04, Martin Balao wrote: > On 9/3/19 12:44 AM, Andrew John Hughes wrote: >> >> >> Bringing Convert.java in here is ok because we can't backport the >> feature changeset "8171277: Elliptic Curves for Security in Crypto", >> but, in cases like this, please explain why you have chosen to include >> additional files/hunks beyond the original changes, so reviewers don't >> have to duplicate the work of finding out the source of these changes. > > Right. > >> >> Approved. >> > > Would you mind pushing this on my behalf? (as I don't have commit > permissions) > > Thanks, > Martin.- > > > Pushed: https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/6d60b8cf1bd4 As 8u-dev is frozen, it had to be pushed by me anyway. 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 felix.yang at huawei.com Thu Sep 5 00:55:22 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Thu, 5 Sep 2019 00:55:22 +0000 Subject: Request for Approval: Backport of 8147611: G1 - Missing memory barrier in start_cset_region_for_worker Message-ID: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8147611 >> >> JDK9 Changeset: >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/8fcd5cba7938 >> >> >> >> The code change is trivial and should be easy for it to be applied to the jdk8u master repo. >> > There doesn't seem to be a patch here for review. > I applied the 11u version and the hunk had to be manually applied instead because of whitespace differences. > I've pushed it now, but in future, cases like this should be posted for review before seeking approval. Skipping the review process is only applicable when the patch applies cleanly, after file paths are adjusted. > The fix request comment on the bug should detail whether it applies cleanly or not, and link to a review thread if not. Yes, that's the correct backport process. I noticed that process later on and I was following it for my later backport requests. Thank you for your effort. > Also note that I gave approval for this on 2019-06-12, but it has never been committed in the subsequent two and half months. I also saw that approval. I was expecting someone else to help push this `one-line` change as I am not a jdk8u committer. Felix From neugens at redhat.com Thu Sep 5 13:32:30 2019 From: neugens at redhat.com (Mario Torre) Date: Thu, 5 Sep 2019 15:32:30 +0200 Subject: 8u232 Rampdown: Bug Triage In-Reply-To: <112fe4fb-7668-f937-d61e-b3264905effc@redhat.com> References: <78b81391-3eec-34a2-acfd-c42875a1534f@ubuntu.com> <112fe4fb-7668-f937-d61e-b3264905effc@redhat.com> Message-ID: <8326fa09-bdbe-bf8f-cced-232806e27212@redhat.com> On 04/09/2019 16:46, Andrew John Hughes wrote: > > aph raised the same issue and we've bumped it to 8u242. It's a clean > backport so I'll push it early once we've forked and then hopefully > you'll have plenty of time to test. > > In the worse case, reverting is also trivial and the version can also be > selected via a runtime property. Yes, because this patch most likely depends on a number of other GTK fixes that went in during the years, I don't know if all were backported, so it makes sense to delay it to 8u242 and give time to test. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From andrey at azul.com Thu Sep 5 15:55:00 2019 From: andrey at azul.com (Andrey Petushkov) Date: Thu, 5 Sep 2019 15:55:00 +0000 Subject: [8u] [JFR] RFR: JFR backports from 11.0.4 In-Reply-To: References: <72db089a-fb9f-e088-8fcd-8a6e25bec29b@redhat.com> <4DE97FAF-FB3A-41C5-BCC2-1BE799E9AA6C@azul.com> Message-ID: Hi Mario, The following fixes apply trivially to jdk11u, so I've requested the permission to backport per process. https://bugs.openjdk.java.net/browse/JDK-8220555 https://bugs.openjdk.java.net/browse/JDK-8221711 https://bugs.openjdk.java.net/browse/JDK-8222888 https://bugs.openjdk.java.net/browse/JDK-8221569 https://bugs.openjdk.java.net/browse/JDK-8216283 The rest require some rework, I'll post RFRs soon Thanks, Andrey > On 4 Sep 2019, at 17:47, Mario Torre wrote: > > Awesome, thanks for checking zero. > > As discussed offline, we have a few backports that were directly > backported to 8u without first being in 11u: > > https://bugs.openjdk.java.net/browse/JDK-8185525 > https://bugs.openjdk.java.net/browse/JDK-8223599 > https://bugs.openjdk.java.net/browse/JDK-8225310 > https://bugs.openjdk.java.net/browse/JDK-8221711 > https://bugs.openjdk.java.net/browse/JDK-8222888 > https://bugs.openjdk.java.net/browse/JDK-8216283 > https://bugs.openjdk.java.net/browse/JDK-8220555 > https://bugs.openjdk.java.net/browse/JDK-8217362 > https://bugs.openjdk.java.net/browse/JDK-8221569 > https://bugs.openjdk.java.net/browse/JDK-8224217 > > A couple of those are wither being worked on or of interest for 11u, > so they should be fine, some aren't and while may not be critical I > think they are nice to have (like the container tests), so I would > expect all of them to be backported to 11u. > > Since this is a staging repository we may go ahead and push them and > work on the backport to 11 afterward, but I would prefer to not create > a discrepancy at this moment, so if possible we should work on the > backports to 11 first. > > Cheers, > Mario > > > On Wed, Sep 4, 2019 at 4:09 PM Andrey Petushkov wrote: >> >> Hi Mario, >> >> zero build is fine (e.g. mentioned method has default no-op implementation in vm_version.hpp) >> >> Andrey >> >>> On 4 Sep 2019, at 12:52, Mario Torre wrote: >>> >>> On 03/09/2019 13:53, Andrey Petushkov wrote: >>>> Dear All, >>>> >>>> could you please consider the following set of backports of the JFR fixes from 11.0.4 release into 8u incubator baseline: >>> >>> This seems good, the only nit I have now is that some of those changes >>> may break zero again, I think it may make sense to fix it in this patch >>> set instead of filing a dedicated bug report later. >>> >>> See for example: >>> >>> JDK-8219241 >>> >>> +void VM_Version::print_platform_virtualization_info(outputStream* st) { >>> >>> etc.. >>> >>> 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 gnu.andrew at redhat.com Fri Sep 6 02:25:20 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 6 Sep 2019 03:25:20 +0100 Subject: [RAMPDOWN] 8u & 8u-dev now OPEN for commits Message-ID: jdk8u232-b05 has been pushed to 8u and these trees are now open for 8u232 changes with jdk8u-critical-yes. jdk8u242-b00 has been tagged in 8u-dev and these trees are now open for 8u242 changes with jdk8u-fix-yes. Please see the wiki for further details and an updated schedule: https://wiki.openjdk.java.net/display/jdk8u/Main Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Fri Sep 6 03:49:57 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 6 Sep 2019 04:49:57 +0100 Subject: OpenJDK 8u232-b05 EA Released Message-ID: <444ea8b2-25df-0c64-4ed0-48fb87674250@redhat.com> I've made available an early access source bundle for 8u232, based on the tag jdk8u232-b05: https://openjdk-sources.osci.io/openjdk8/openjdk8u232-b05-ea.tar.xz The tarball is accompanied by a digital signature available at: https://openjdk-sources.osci.io/openjdk8/openjdk8u232-b05-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: aa859593e0fd6b4518e7c625b4edf21450d45b852764ddcc89d383b04781f649 openjdk8u232-b05-ea.tar.xz d7252a4a6dca72412e4bf88cd8fb3d8fff22c7f877773e034039af0a455205f4 openjdk8u232-b05-ea.tar.xz.sig They are listed at https://openjdk-sources.osci.io/openjdk8/openjdk8u232-b05-ea.sha256 Changes in 8u232-b05: - S8080157: assert(allocates2(pc)) failed: not in CodeBuffer memory - S8087128: C2: Disallow definition split on MachCopySpill nodes - S8139965: Hang seen when using com.sun.jndi.ldap.search.replyQueueSize - S8141570: Fix Zero interpreter build for --disable-precompiled-headers - S8147502: Digest is incorrectly truncated for ECDSA signatures when the bit length of n is less than the field size - S8147611: G1 - Missing memory barrier in start_cset_region_for_worker - S8151066: assert(0 <= i && i < length()) failed: index out of bounds - S8155951: VM crash in nsk/jvmti/RedefineClasses/StressRedefine: assert failed: Corrupted constant pool - S8202948: C2: assert(init_offset >= 0) failed: positive offset from object start - S8203324: Use out of scope in getMacOSXLocale of java_props_macosx.c:120 - S8206879: Currency decimal marker incorrect for Peru - S8211232: GraphKit::make_runtime_call() sometimes attaches wrong memory state to call - S8214687: Optimize Collections.nCopies().hashCode() and equals() - S8214702: Wrong text position for whitespaced string in printing Swing text - S8215130: Fix errors in LittleCMS 2.9 reported by GCC 8 - S8215265: C2: range check elimination may allow illegal out of bound access - S8217359: C2 compiler triggers SIGSEGV after transformation in ConvI2LNode::Ideal - S8217731: Font rendering and glyph spacing changed from jdk-8 to jdk-11 - S8217896: Make better use of LCPUs when building on AIX - S8218201: Failures when vmIntrinsics::_getClass is not inlined - S8218280: LineNumberReader throws "Mark invalid" exception if CRLF straddles buffer. - S8218780: Update MUSCLE PCSC-Lite header files - S8219517: assert(false) failed: infinite loop in PhaseIterGVN::optimize - S8220072: GCC 8.3 reports errors in java.base - S8222980: Upgrade IANA Language Subtag Registry to Version 2019-04-03 - S8223177: Data race on JvmtiEnvBase::_tag_map in double-checked locking - S8223227: Rename acquire_tag_map() to tag_map_acquire() in jvmtiEnvBase - S8225423: GTK L&F: JSplitPane: There is no divider shown - S8226798: JVM crash in klassItable::initialize_itable_for_interface(int, InstanceKlass*, bool, Thread*) - S8226964: [Yaru] GTK L&F: There is no difference between menu selected and de-selected - S8228440: TestAESCiphers tests fail with "access denied" trying to access ArrayUtil Bundles for b03 & b04 are also available: https://openjdk-sources.osci.io/openjdk8/openjdk8u232-b03-ea.tar.xz https://openjdk-sources.osci.io/openjdk8/openjdk8u232-b04-ea.tar.xz https://openjdk-sources.osci.io/openjdk8/openjdk8u232-b03-ea.tar.xz.sig https://openjdk-sources.osci.io/openjdk8/openjdk8u232-b04-ea.tar.xz.sig e33fb9fea4e8723ebdd2d4932691ec5a2fb7538f91bdf46f47f12e70aad36a67 openjdk8u232-b03-ea.tar.xz 43623eafd92ab9f26bdba423f8f1a9b40f15c14f4fa28b833627b730c59cdcde openjdk8u232-b03-ea.tar.xz.sig https://openjdk-sources.osci.io/openjdk8/openjdk8u232-b03-ea.sha256 73a60ac5465b4fe6c10c7be5c06ed42cda126884b00fd498a80eaf04950c430d openjdk8u232-b04-ea.tar.xz 73bcb7962bfca0c285c2d8f30ad722dea697432460a38151ffc1cbf9e4c12225 openjdk8u232-b04-ea.tar.xz.sig https://openjdk-sources.osci.io/openjdk8/openjdk8u232-b04-ea.sha256 Changes in 8u232-b03: - S8213561: ZipFile/MultiThreadedReadTest.java timed out in tier1 - S8217785: Padding ParallelTaskTerminator::_offered_termination variable Changes in 8u232-b04: - S8188868: PPC64: Support AES intrinsics on Big Endian 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 denghui.ddh at alibaba-inc.com Mon Sep 9 02:07:31 2019 From: denghui.ddh at alibaba-inc.com (DDH) Date: Mon, 09 Sep 2019 10:07:31 +0800 Subject: =?UTF-8?B?UmU6IFs4dV0gW0pGUl0gUkZSOiBKRlIgYmFja3BvcnRzIGZyb20gMTEuMC40?= In-Reply-To: References: <72db089a-fb9f-e088-8fcd-8a6e25bec29b@redhat.com> <4DE97FAF-FB3A-41C5-BCC2-1BE799E9AA6C@azul.com> , Message-ID: hi all, We(Alibaba) picked some jfr backports as follows from JBS (https://bugs.openjdk.java.net/browse/JDK-8230624?jql=Subcomponent%20%3D%20jfr%20and%20resolution%20%3D%20Fixed%20and%20fixVersion%20%3E%2011.0.6%20and%20type%20!%3D%20Backport), we think it is worth porting them to 8u/11u. We plan to backport them to 11u at first, and then to 8u, what's your comment? If you think it is reasonable, we can provide our webrev of some issues as soon as possible, and continue work on other issues. 8223396: [TESTBUG] several jfr tests do not clean up files created in /tmp 8225004: Remove invalid assertion in jfr_conditional_flush() 8214542: [BUG] JFR: Old Object Sample event slow on a deep heap in debug builds (Unresolved) 8228834: [BUG] Regression caused by JDK-8214542 not installing complete checkpoint data to candidates 8228359: [TESTBUG] jdk.jfr.e.g.c.TestGCHeapConfigurationEventWith32BitOops.java does not expect MinHeapSize to be aligned to HeapAlignment 8227605: [BUG] Kitchensink fails "assert((((klass)->trace_id() & (JfrTraceIdEpoch::leakp_in_use_this_epoch_bit())) != 0)) failed: invariant" 8227411: [BUG] TestTimeMultiple.java failed "assert(!lease()) failed: invariant" 8224172: [BUG] assert(jfr_is_event_enabled(id)) failed: invariant 8212663: [BUG] Remove conservative at_safepoint assert when JFR writes type sets during class unloading 8216064: [BUG] -XX:StartFlightRecording:settings= doesn't work properly 8214750: [BUG] Unnecessary

tags in jfr classes 8213570: [TESTBUG] Update JFR sanity test set 8226779: [TESTBUG] Test JFR API from Java agent 8229189: [Enhancement] Improve JFR leak profiler tracing to deal with discontiguous heaps 8223438: [Enhancement] add VirtualizationInformation JFR event ------------------------------------------------------------------ From:Andrey Petushkov Send Time:2019?9?5?(???) 23:55 To:Mario Torre Cc:jdk8u-dev at openjdk.java.net Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 Hi Mario, The following fixes apply trivially to jdk11u, so I've requested the permission to backport per process. https://bugs.openjdk.java.net/browse/JDK-8220555 https://bugs.openjdk.java.net/browse/JDK-8221711 https://bugs.openjdk.java.net/browse/JDK-8222888 https://bugs.openjdk.java.net/browse/JDK-8221569 https://bugs.openjdk.java.net/browse/JDK-8216283 The rest require some rework, I'll post RFRs soon Thanks, Andrey > On 4 Sep 2019, at 17:47, Mario Torre wrote: > > Awesome, thanks for checking zero. > > As discussed offline, we have a few backports that were directly > backported to 8u without first being in 11u: > > https://bugs.openjdk.java.net/browse/JDK-8185525 > https://bugs.openjdk.java.net/browse/JDK-8223599 > https://bugs.openjdk.java.net/browse/JDK-8225310 > https://bugs.openjdk.java.net/browse/JDK-8221711 > https://bugs.openjdk.java.net/browse/JDK-8222888 > https://bugs.openjdk.java.net/browse/JDK-8216283 > https://bugs.openjdk.java.net/browse/JDK-8220555 > https://bugs.openjdk.java.net/browse/JDK-8217362 > https://bugs.openjdk.java.net/browse/JDK-8221569 > https://bugs.openjdk.java.net/browse/JDK-8224217 > > A couple of those are wither being worked on or of interest for 11u, > so they should be fine, some aren't and while may not be critical I > think they are nice to have (like the container tests), so I would > expect all of them to be backported to 11u. > > Since this is a staging repository we may go ahead and push them and > work on the backport to 11 afterward, but I would prefer to not create > a discrepancy at this moment, so if possible we should work on the > backports to 11 first. > > Cheers, > Mario > > > On Wed, Sep 4, 2019 at 4:09 PM Andrey Petushkov wrote: >> >> Hi Mario, >> >> zero build is fine (e.g. mentioned method has default no-op implementation in vm_version.hpp) >> >> Andrey >> >>> On 4 Sep 2019, at 12:52, Mario Torre wrote: >>> >>> On 03/09/2019 13:53, Andrey Petushkov wrote: >>>> Dear All, >>>> >>>> could you please consider the following set of backports of the JFR fixes from 11.0.4 release into 8u incubator baseline: >>> >>> This seems good, the only nit I have now is that some of those changes >>> may break zero again, I think it may make sense to fix it in this patch >>> set instead of filing a dedicated bug report later. >>> >>> See for example: >>> >>> JDK-8219241 >>> >>> +void VM_Version::print_platform_virtualization_info(outputStream* st) { >>> >>> etc.. >>> >>> 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 neugens at redhat.com Mon Sep 9 09:37:50 2019 From: neugens at redhat.com (Mario Torre) Date: Mon, 9 Sep 2019 11:37:50 +0200 Subject: [8u] [JFR] RFR: JFR backports from 11.0.4 In-Reply-To: References: <72db089a-fb9f-e088-8fcd-8a6e25bec29b@redhat.com> <4DE97FAF-FB3A-41C5-BCC2-1BE799E9AA6C@azul.com> Message-ID: Hi Denghui, Yes, the list looks good to me. As you mentioned, we should try first the 11u backports and then backport to 8u. The process for the backport is highlighted here: https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix Cheers, Mario On Mon, Sep 9, 2019 at 4:07 AM DDH wrote: > > hi all, > We(Alibaba) picked some jfr backports as follows from JBS > (https://bugs.openjdk.java.net/browse/JDK-8230624?jql=Subcomponent%20%3D%20jfr%20and%20resolution%20%3D%20Fixed%20and%20fixVersion%20%3E%2011.0.6%20and%20type%20!%3D%20Backport), we > think it is worth porting them to 8u/11u. > We plan to backport them to 11u at first, and then to 8u, what's your comment? > If you think it is reasonable, we can provide our webrev of some issues as soon as possible, and continue work on other issues. > > 8223396: [TESTBUG] several jfr tests do not clean up files created in /tmp > 8225004: Remove invalid assertion in jfr_conditional_flush() > 8214542: [BUG] JFR: Old Object Sample event slow on a deep heap in debug builds (Unresolved) > 8228834: [BUG] Regression caused by JDK-8214542 not installing complete checkpoint data to candidates > 8228359: [TESTBUG] jdk.jfr.e.g.c.TestGCHeapConfigurationEventWith32BitOops.java does not expect MinHeapSize to be aligned to HeapAlignment > 8227605: [BUG] Kitchensink fails "assert((((klass)->trace_id() & (JfrTraceIdEpoch::leakp_in_use_this_epoch_bit())) != 0)) failed: invariant" > 8227411: [BUG] TestTimeMultiple.java failed "assert(!lease()) failed: invariant" > 8224172: [BUG] assert(jfr_is_event_enabled(id)) failed: invariant > 8212663: [BUG] Remove conservative at_safepoint assert when JFR writes type sets during class unloading > 8216064: [BUG] -XX:StartFlightRecording:settings= doesn't work properly > 8214750: [BUG] Unnecessary

tags in jfr classes > 8213570: [TESTBUG] Update JFR sanity test set > 8226779: [TESTBUG] Test JFR API from Java agent > 8229189: [Enhancement] Improve JFR leak profiler tracing to deal with discontiguous heaps > 8223438: [Enhancement] add VirtualizationInformation JFR event > > ------------------------------------------------------------------ > From:Andrey Petushkov > Send Time:2019?9?5?(???) 23:55 > To:Mario Torre > Cc:jdk8u-dev at openjdk.java.net > Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 > > Hi Mario, > > The following fixes apply trivially to jdk11u, so I've requested the permission to backport per process. > > https://bugs.openjdk.java.net/browse/JDK-8220555 > https://bugs.openjdk.java.net/browse/JDK-8221711 > https://bugs.openjdk.java.net/browse/JDK-8222888 > https://bugs.openjdk.java.net/browse/JDK-8221569 > https://bugs.openjdk.java.net/browse/JDK-8216283 > > The rest require some rework, I'll post RFRs soon > > Thanks, > Andrey > > > On 4 Sep 2019, at 17:47, Mario Torre wrote: > > > > Awesome, thanks for checking zero. > > > > As discussed offline, we have a few backports that were directly > > backported to 8u without first being in 11u: > > > > https://bugs.openjdk.java.net/browse/JDK-8185525 > > https://bugs.openjdk.java.net/browse/JDK-8223599 > > https://bugs.openjdk.java.net/browse/JDK-8225310 > > https://bugs.openjdk.java.net/browse/JDK-8221711 > > https://bugs.openjdk.java.net/browse/JDK-8222888 > > https://bugs.openjdk.java.net/browse/JDK-8216283 > > https://bugs.openjdk.java.net/browse/JDK-8220555 > > https://bugs.openjdk.java.net/browse/JDK-8217362 > > https://bugs.openjdk.java.net/browse/JDK-8221569 > > https://bugs.openjdk.java.net/browse/JDK-8224217 > > > > A couple of those are wither being worked on or of interest for 11u, > > so they should be fine, some aren't and while may not be critical I > > think they are nice to have (like the container tests), so I would > > expect all of them to be backported to 11u. > > > > Since this is a staging repository we may go ahead and push them and > > work on the backport to 11 afterward, but I would prefer to not create > > a discrepancy at this moment, so if possible we should work on the > > backports to 11 first. > > > > Cheers, > > Mario > > > > > > On Wed, Sep 4, 2019 at 4:09 PM Andrey Petushkov wrote: > >> > >> Hi Mario, > >> > >> zero build is fine (e.g. mentioned method has default no-op implementation in vm_version.hpp) > >> > >> Andrey > >> > >>> On 4 Sep 2019, at 12:52, Mario Torre wrote: > >>> > >>> On 03/09/2019 13:53, Andrey Petushkov wrote: > >>>> Dear All, > >>>> > >>>> could you please consider the following set of backports of the JFR fixes from 11.0.4 release into 8u incubator baseline: > >>> > >>> This seems good, the only nit I have now is that some of those changes > >>> may break zero again, I think it may make sense to fix it in this patch > >>> set instead of filing a dedicated bug report later. > >>> > >>> See for example: > >>> > >>> JDK-8219241 > >>> > >>> +void VM_Version::print_platform_virtualization_info(outputStream* st) { > >>> > >>> etc.. > >>> > >>> 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 -- 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 Sep 9 12:59:10 2019 From: andrey at azul.com (Andrey Petushkov) Date: Mon, 9 Sep 2019 12:59:10 +0000 Subject: [8u] [JFR] RFR: JFR backports from 11.0.4 In-Reply-To: References: <72db089a-fb9f-e088-8fcd-8a6e25bec29b@redhat.com> <4DE97FAF-FB3A-41C5-BCC2-1BE799E9AA6C@azul.com> Message-ID: <0FE4C1EB-FCD3-435B-A944-9786BB1EC7C9@azul.com> Hi Denghui, Just a note, from the list below one backport (8223438: [Enhancement] add VirtualizationInformation JFR event) is already proposed for integration as part of Azul's effort ([1]). However since it's not yet integrated into jdk11u there still work to be done. We can do it, but if you'd like and if you feel it's more convenient, you can take over. Anyway you might want to check implementation of the backport in the respective webrev ([2]). Please let us know, thanks Regards, Andrey [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-September/010204.html [2] http://cr.openjdk.java.net/~apetushkov/jfr_backports_katya/11.0.4/ > On 9 Sep 2019, at 12:37, Mario Torre wrote: > > Hi Denghui, > > Yes, the list looks good to me. As you mentioned, we should try first > the 11u backports and then backport to 8u. > > The process for the backport is highlighted here: > https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix > > Cheers, > Mario > > On Mon, Sep 9, 2019 at 4:07 AM DDH wrote: >> >> hi all, >> We(Alibaba) picked some jfr backports as follows from JBS >> (https://bugs.openjdk.java.net/browse/JDK-8230624?jql=Subcomponent%20%3D%20jfr%20and%20resolution%20%3D%20Fixed%20and%20fixVersion%20%3E%2011.0.6%20and%20type%20!%3D%20Backport), we >> think it is worth porting them to 8u/11u. >> We plan to backport them to 11u at first, and then to 8u, what's your comment? >> If you think it is reasonable, we can provide our webrev of some issues as soon as possible, and continue work on other issues. >> >> 8223396: [TESTBUG] several jfr tests do not clean up files created in /tmp >> 8225004: Remove invalid assertion in jfr_conditional_flush() >> 8214542: [BUG] JFR: Old Object Sample event slow on a deep heap in debug builds (Unresolved) >> 8228834: [BUG] Regression caused by JDK-8214542 not installing complete checkpoint data to candidates >> 8228359: [TESTBUG] jdk.jfr.e.g.c.TestGCHeapConfigurationEventWith32BitOops.java does not expect MinHeapSize to be aligned to HeapAlignment >> 8227605: [BUG] Kitchensink fails "assert((((klass)->trace_id() & (JfrTraceIdEpoch::leakp_in_use_this_epoch_bit())) != 0)) failed: invariant" >> 8227411: [BUG] TestTimeMultiple.java failed "assert(!lease()) failed: invariant" >> 8224172: [BUG] assert(jfr_is_event_enabled(id)) failed: invariant >> 8212663: [BUG] Remove conservative at_safepoint assert when JFR writes type sets during class unloading >> 8216064: [BUG] -XX:StartFlightRecording:settings= doesn't work properly >> 8214750: [BUG] Unnecessary

tags in jfr classes >> 8213570: [TESTBUG] Update JFR sanity test set >> 8226779: [TESTBUG] Test JFR API from Java agent >> 8229189: [Enhancement] Improve JFR leak profiler tracing to deal with discontiguous heaps >> 8223438: [Enhancement] add VirtualizationInformation JFR event >> >> ------------------------------------------------------------------ >> From:Andrey Petushkov >> Send Time:2019?9?5?(???) 23:55 >> To:Mario Torre >> Cc:jdk8u-dev at openjdk.java.net >> Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 >> >> Hi Mario, >> >> The following fixes apply trivially to jdk11u, so I've requested the permission to backport per process. >> >> https://bugs.openjdk.java.net/browse/JDK-8220555 >> https://bugs.openjdk.java.net/browse/JDK-8221711 >> https://bugs.openjdk.java.net/browse/JDK-8222888 >> https://bugs.openjdk.java.net/browse/JDK-8221569 >> https://bugs.openjdk.java.net/browse/JDK-8216283 >> >> The rest require some rework, I'll post RFRs soon >> >> Thanks, >> Andrey >> >>> On 4 Sep 2019, at 17:47, Mario Torre wrote: >>> >>> Awesome, thanks for checking zero. >>> >>> As discussed offline, we have a few backports that were directly >>> backported to 8u without first being in 11u: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8185525 >>> https://bugs.openjdk.java.net/browse/JDK-8223599 >>> https://bugs.openjdk.java.net/browse/JDK-8225310 >>> https://bugs.openjdk.java.net/browse/JDK-8221711 >>> https://bugs.openjdk.java.net/browse/JDK-8222888 >>> https://bugs.openjdk.java.net/browse/JDK-8216283 >>> https://bugs.openjdk.java.net/browse/JDK-8220555 >>> https://bugs.openjdk.java.net/browse/JDK-8217362 >>> https://bugs.openjdk.java.net/browse/JDK-8221569 >>> https://bugs.openjdk.java.net/browse/JDK-8224217 >>> >>> A couple of those are wither being worked on or of interest for 11u, >>> so they should be fine, some aren't and while may not be critical I >>> think they are nice to have (like the container tests), so I would >>> expect all of them to be backported to 11u. >>> >>> Since this is a staging repository we may go ahead and push them and >>> work on the backport to 11 afterward, but I would prefer to not create >>> a discrepancy at this moment, so if possible we should work on the >>> backports to 11 first. >>> >>> Cheers, >>> Mario >>> >>> >>> On Wed, Sep 4, 2019 at 4:09 PM Andrey Petushkov wrote: >>>> >>>> Hi Mario, >>>> >>>> zero build is fine (e.g. mentioned method has default no-op implementation in vm_version.hpp) >>>> >>>> Andrey >>>> >>>>> On 4 Sep 2019, at 12:52, Mario Torre wrote: >>>>> >>>>> On 03/09/2019 13:53, Andrey Petushkov wrote: >>>>>> Dear All, >>>>>> >>>>>> could you please consider the following set of backports of the JFR fixes from 11.0.4 release into 8u incubator baseline: >>>>> >>>>> This seems good, the only nit I have now is that some of those changes >>>>> may break zero again, I think it may make sense to fix it in this patch >>>>> set instead of filing a dedicated bug report later. >>>>> >>>>> See for example: >>>>> >>>>> JDK-8219241 >>>>> >>>>> +void VM_Version::print_platform_virtualization_info(outputStream* st) { >>>>> >>>>> etc.. >>>>> >>>>> 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 > > > > -- > 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 Sep 9 13:01:27 2019 From: neugens at redhat.com (Mario Torre) Date: Mon, 9 Sep 2019 15:01:27 +0200 Subject: [JFR] CSR filed: JDK-8230764 Message-ID: Hi all, I just filed the CSR for our backport: https://bugs.openjdk.java.net/browse/JDK-8230764 Since it's my first one, I may have missed some details, if you have feedback or corrections please let me know! Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From christoph.langer at sap.com Mon Sep 9 13:03:28 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 9 Sep 2019 13:03:28 +0000 Subject: [8u] [JFR] RFR: JFR backports from 11.0.4 In-Reply-To: References: <72db089a-fb9f-e088-8fcd-8a6e25bec29b@redhat.com> <4DE97FAF-FB3A-41C5-BCC2-1BE799E9AA6C@azul.com> Message-ID: Hi Andrey, I approved these patches in 11u. They all seem to be viable candidates for backports. Best regards Christoph > -----Original Message----- > From: jdk8u-dev On Behalf Of > Andrey Petushkov > Sent: Donnerstag, 5. September 2019 17:55 > To: Mario Torre > Cc: jdk8u-dev at openjdk.java.net > Subject: Re: [8u] [JFR] RFR: JFR backports from 11.0.4 > > Hi Mario, > > The following fixes apply trivially to jdk11u, so I've requested the permission > to backport per process. > > https://bugs.openjdk.java.net/browse/JDK-8220555 > https://bugs.openjdk.java.net/browse/JDK-8221711 > https://bugs.openjdk.java.net/browse/JDK-8222888 > https://bugs.openjdk.java.net/browse/JDK-8221569 > https://bugs.openjdk.java.net/browse/JDK-8216283 > > The rest require some rework, I'll post RFRs soon > > Thanks, > Andrey > > > On 4 Sep 2019, at 17:47, Mario Torre wrote: > > > > Awesome, thanks for checking zero. > > > > As discussed offline, we have a few backports that were directly > > backported to 8u without first being in 11u: > > > > https://bugs.openjdk.java.net/browse/JDK-8185525 > > https://bugs.openjdk.java.net/browse/JDK-8223599 > > https://bugs.openjdk.java.net/browse/JDK-8225310 > > https://bugs.openjdk.java.net/browse/JDK-8221711 > > https://bugs.openjdk.java.net/browse/JDK-8222888 > > https://bugs.openjdk.java.net/browse/JDK-8216283 > > https://bugs.openjdk.java.net/browse/JDK-8220555 > > https://bugs.openjdk.java.net/browse/JDK-8217362 > > https://bugs.openjdk.java.net/browse/JDK-8221569 > > https://bugs.openjdk.java.net/browse/JDK-8224217 > > > > A couple of those are wither being worked on or of interest for 11u, > > so they should be fine, some aren't and while may not be critical I > > think they are nice to have (like the container tests), so I would > > expect all of them to be backported to 11u. > > > > Since this is a staging repository we may go ahead and push them and > > work on the backport to 11 afterward, but I would prefer to not create > > a discrepancy at this moment, so if possible we should work on the > > backports to 11 first. > > > > Cheers, > > Mario > > > > > > On Wed, Sep 4, 2019 at 4:09 PM Andrey Petushkov > wrote: > >> > >> Hi Mario, > >> > >> zero build is fine (e.g. mentioned method has default no-op > implementation in vm_version.hpp) > >> > >> Andrey > >> > >>> On 4 Sep 2019, at 12:52, Mario Torre wrote: > >>> > >>> On 03/09/2019 13:53, Andrey Petushkov wrote: > >>>> Dear All, > >>>> > >>>> could you please consider the following set of backports of the JFR > fixes from 11.0.4 release into 8u incubator baseline: > >>> > >>> This seems good, the only nit I have now is that some of those changes > >>> may break zero again, I think it may make sense to fix it in this patch > >>> set instead of filing a dedicated bug report later. > >>> > >>> See for example: > >>> > >>> JDK-8219241 > >>> > >>> +void VM_Version::print_platform_virtualization_info(outputStream* > st) { > >>> > >>> etc.. > >>> > >>> Cheers, > >>> Mario > >>> > >>> -- > >>> Mario Torre > >>> Associate Manager, Software Engineering > >>> Red Hat GmbH > >>> 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > >> > > > > > > -- > > Mario Torre > > Associate Manager, Software Engineering > > Red Hat GmbH > > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From sgehwolf at redhat.com Mon Sep 9 15:31:44 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 09 Sep 2019 17:31:44 +0200 Subject: OpenJDK 8u232-b05 EA Released In-Reply-To: <444ea8b2-25df-0c64-4ed0-48fb87674250@redhat.com> References: <444ea8b2-25df-0c64-4ed0-48fb87674250@redhat.com> Message-ID: <641d04dffc104cb77040020268983b67172b7184.camel@redhat.com> Hi, Note that EA OpenJDK Project Builds for b05 (EA) are available as well: https://adoptopenjdk.net/upstream.html Thanks, Severin On Fri, 2019-09-06 at 04:49 +0100, Andrew John Hughes wrote: > I've made available an early access source bundle for 8u232, based on > the tag jdk8u232-b05: > > https://openjdk-sources.osci.io/openjdk8/openjdk8u232-b05-ea.tar.xz > > The tarball is accompanied by a digital signature available at: > > https://openjdk-sources.osci.io/openjdk8/openjdk8u232-b05-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: > > aa859593e0fd6b4518e7c625b4edf21450d45b852764ddcc89d383b04781f649 > openjdk8u232-b05-ea.tar.xz > d7252a4a6dca72412e4bf88cd8fb3d8fff22c7f877773e034039af0a455205f4 > openjdk8u232-b05-ea.tar.xz.sig > > They are listed at > https://openjdk-sources.osci.io/openjdk8/openjdk8u232-b05-ea.sha256 > > Changes in 8u232-b05: > - S8080157: assert(allocates2(pc)) failed: not in CodeBuffer memory > - S8087128: C2: Disallow definition split on MachCopySpill nodes > - S8139965: Hang seen when using com.sun.jndi.ldap.search.replyQueueSize > - S8141570: Fix Zero interpreter build for --disable-precompiled-headers > - S8147502: Digest is incorrectly truncated for ECDSA signatures when > the bit length of n is less than the field size > - S8147611: G1 - Missing memory barrier in start_cset_region_for_worker > - S8151066: assert(0 <= i && i < length()) failed: index out of bounds > - S8155951: VM crash in nsk/jvmti/RedefineClasses/StressRedefine: > assert failed: Corrupted constant pool > - S8202948: C2: assert(init_offset >= 0) failed: positive offset from > object start > - S8203324: Use out of scope in getMacOSXLocale of java_props_macosx.c:120 > - S8206879: Currency decimal marker incorrect for Peru > - S8211232: GraphKit::make_runtime_call() sometimes attaches wrong > memory state to call > - S8214687: Optimize Collections.nCopies().hashCode() and equals() > - S8214702: Wrong text position for whitespaced string in printing > Swing text > - S8215130: Fix errors in LittleCMS 2.9 reported by GCC 8 > - S8215265: C2: range check elimination may allow illegal out of bound > access > - S8217359: C2 compiler triggers SIGSEGV after transformation in > ConvI2LNode::Ideal > - S8217731: Font rendering and glyph spacing changed from jdk-8 to jdk-11 > - S8217896: Make better use of LCPUs when building on AIX > - S8218201: Failures when vmIntrinsics::_getClass is not inlined > - S8218280: LineNumberReader throws "Mark invalid" exception if CRLF > straddles buffer. > - S8218780: Update MUSCLE PCSC-Lite header files > - S8219517: assert(false) failed: infinite loop in PhaseIterGVN::optimize > - S8220072: GCC 8.3 reports errors in java.base > - S8222980: Upgrade IANA Language Subtag Registry to Version 2019-04-03 > - S8223177: Data race on JvmtiEnvBase::_tag_map in double-checked locking > - S8223227: Rename acquire_tag_map() to tag_map_acquire() in jvmtiEnvBase > - S8225423: GTK L&F: JSplitPane: There is no divider shown > - S8226798: JVM crash in > klassItable::initialize_itable_for_interface(int, InstanceKlass*, bool, > Thread*) > - S8226964: [Yaru] GTK L&F: There is no difference between menu > selected and de-selected > - S8228440: TestAESCiphers tests fail with "access denied" trying to > access ArrayUtil > > Bundles for b03 & b04 are also available: > > https://openjdk-sources.osci.io/openjdk8/openjdk8u232-b03-ea.tar.xz > https://openjdk-sources.osci.io/openjdk8/openjdk8u232-b04-ea.tar.xz > > https://openjdk-sources.osci.io/openjdk8/openjdk8u232-b03-ea.tar.xz.sig > https://openjdk-sources.osci.io/openjdk8/openjdk8u232-b04-ea.tar.xz.sig > > e33fb9fea4e8723ebdd2d4932691ec5a2fb7538f91bdf46f47f12e70aad36a67 > openjdk8u232-b03-ea.tar.xz > 43623eafd92ab9f26bdba423f8f1a9b40f15c14f4fa28b833627b730c59cdcde > openjdk8u232-b03-ea.tar.xz.sig > > https://openjdk-sources.osci.io/openjdk8/openjdk8u232-b03-ea.sha256 > > 73a60ac5465b4fe6c10c7be5c06ed42cda126884b00fd498a80eaf04950c430d > openjdk8u232-b04-ea.tar.xz > 73bcb7962bfca0c285c2d8f30ad722dea697432460a38151ffc1cbf9e4c12225 > openjdk8u232-b04-ea.tar.xz.sig > > https://openjdk-sources.osci.io/openjdk8/openjdk8u232-b04-ea.sha256 > > Changes in 8u232-b03: > - S8213561: ZipFile/MultiThreadedReadTest.java timed out in tier1 > - S8217785: Padding ParallelTaskTerminator::_offered_termination variable > > Changes in 8u232-b04: > - S8188868: PPC64: Support AES intrinsics on Big Endian > > Thanks, From akashche at redhat.com Mon Sep 9 16:29:56 2019 From: akashche at redhat.com (Alex Kashchenko) Date: Mon, 9 Sep 2019 17:29:56 +0100 Subject: [8u] RFR: 8196681: Java Access Bridge logging and debug flags dynamically controlled Message-ID: Hi, Please review the code change required to backport JDK-8196681 to 8u. Bug: https://bugs.openjdk.java.net/browse/JDK-8196681 Original review thread: http://mail.openjdk.java.net/pipermail/awt-dev/2018-September/014302.html 11u changeset: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/af9ad0ae9039 Patch does not apply cleanly, because std::chrono is used for timestamps. And this part of C++11 standard is not supported by VS2010 toolchain that is used for 8u windows builds. The following change reimplements the same timestamps without std::chrono: auto getTimeStamp() -> long long { - using namespace std::chrono; - auto timeNow = duration_cast(steady_clock::now().time_since_epoch()); - - return timeNow.count(); + LARGE_INTEGER freqLarge; + ::QueryPerformanceFrequency(&freqLarge); + long long freq = freqLarge.QuadPart; + LARGE_INTEGER counterLarge; + ::QueryPerformanceCounter(&counterLarge); + long long counter = counterLarge.QuadPart; + long long milliDen = 1000; + long long whole = (counter / freq) * milliDen; + long long part = (counter % freq) * milliDen / freq; + return whole + part; } Backport also depends on JDK-8077707 and JDK-8132249 (both apply cleanly), "jdk8u-fix-request" label was added for them. Backport requires CSR that was filed in JDK-8230699. Thanks! -- -Alex From xxinliu at amazon.com Mon Sep 9 20:04:27 2019 From: xxinliu at amazon.com (Liu, Xin) Date: Mon, 9 Sep 2019 20:04:27 +0000 Subject: Backport vmTestbase tests to jdk8u-dev? In-Reply-To: References: Message-ID: Hi, Konstantin, We are glad to work with you to get vmTestbase landed into jdk8u. Our original intent is get design reviewed by the jdk8u maintainer. After then, we can proceed to refactor it. We can work together to refactor it. we plan to do it anyway. Back to the webrev you send. What did you modify in [3]? Ideally, we can should have a series of patches. The first one should be intact vmTestbase code from the tip of JDK. All we changes should come after it and be reviewed by this mail-list. In addition to refactoring, we can also offer help to figure out those failed cases. What do you think? Thanks, --lx From: Konstantin Shefov Date: Friday, September 6, 2019 at 12:55 PM To: "jdk8u-dev at openjdk.java.net" Cc: "Liu, Xin" Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, We at Azul think it is a good idea to backport vmTestbase tests to OpenJDK 8. We have used patches you suggested, done some refactoring to enable more tests to work with JDK 8. We have run all 3550 tests from ?vmTestbase? folder against Zulu 8 at ARM64 platform: 1. 3371 tests PASS (see [1]); 2. 179 tests FAIL (see [2]): reasons are being investigated. Patches we have used (contain our refactoring): 1. Hotspot folder [3] 2. Main folder [4] We plan to investigate causes of those 177 failures, purify unused code from hotspot/test/test/lib/jdk, and run the tests against different platforms. We also compared vmTestbase from JDK 11 with that from JDK 13, we found out: 1. 332 test have been removed in JDK 13; 2. Only 2 test have been added in JDK 13; 3. Tests that remained were modified, but these modifications mostly are copyright years, or output format, or API changes. From the above results we can tell that vmTestbase does not grow. It looks like that tests are been removed from there or transferred somewhere else. [1] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/passed_tests.html [2] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/failed_tests.html [3] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_hotspot.patch [4] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_root.patch Regards, --Konstantin From denghui.ddh at alibaba-inc.com Tue Sep 10 05:04:33 2019 From: denghui.ddh at alibaba-inc.com (DDH) Date: Tue, 10 Sep 2019 13:04:33 +0800 Subject: =?UTF-8?B?UmU6IFs4dV0gW0pGUl0gUkZSOiBKRlIgYmFja3BvcnRzIGZyb20gMTEuMC40?= In-Reply-To: <0FE4C1EB-FCD3-435B-A944-9786BB1EC7C9@azul.com> References: <72db089a-fb9f-e088-8fcd-8a6e25bec29b@redhat.com> <4DE97FAF-FB3A-41C5-BCC2-1BE799E9AA6C@azul.com> , <0FE4C1EB-FCD3-435B-A944-9786BB1EC7C9@azul.com> Message-ID: Hi Andrey, Since you have already processed on 8223438([Enhancement] add VirtualizationInformation JFR event), we think that we don't need to do this issue again, we will remove it from our list. By the way, can you send us a complete list that you will backport? We can double check there are any repeated issues. Thanks, DDH ------------------------------------------------------------------ From:Andrey Petushkov Send Time:2019?9?9?(???) 20:59 To:Mario Torre ; ???(??) Cc:jdk8u-dev ; Ekaterina Vergizova Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 Hi Denghui, Just a note, from the list below one backport (8223438: [Enhancement] add VirtualizationInformation JFR event) is already proposed for integration as part of Azul's effort ([1]). However since it's not yet integrated into jdk11u there still work to be done. We can do it, but if you'd like and if you feel it's more convenient, you can take over. Anyway you might want to check implementation of the backport in the respective webrev ([2]). Please let us know, thanks Regards, Andrey [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-September/010204.html [2] http://cr.openjdk.java.net/~apetushkov/jfr_backports_katya/11.0.4/ On 9 Sep 2019, at 12:37, Mario Torre wrote: Hi Denghui, Yes, the list looks good to me. As you mentioned, we should try first the 11u backports and then backport to 8u. The process for the backport is highlighted here: https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix Cheers, Mario On Mon, Sep 9, 2019 at 4:07 AM DDH wrote: hi all, We(Alibaba) picked some jfr backports as follows from JBS (https://bugs.openjdk.java.net/browse/JDK-8230624?jql=Subcomponent%20%3D%20jfr%20and%20resolution%20%3D%20Fixed%20and%20fixVersion%20%3E%2011.0.6%20and%20type%20!%3D%20Backport), we think it is worth porting them to 8u/11u. We plan to backport them to 11u at first, and then to 8u, what's your comment? If you think it is reasonable, we can provide our webrev of some issues as soon as possible, and continue work on other issues. 8223396: [TESTBUG] several jfr tests do not clean up files created in /tmp 8225004: Remove invalid assertion in jfr_conditional_flush() 8214542: [BUG] JFR: Old Object Sample event slow on a deep heap in debug builds (Unresolved) 8228834: [BUG] Regression caused by JDK-8214542 not installing complete checkpoint data to candidates 8228359: [TESTBUG] jdk.jfr.e.g.c.TestGCHeapConfigurationEventWith32BitOops.java does not expect MinHeapSize to be aligned to HeapAlignment 8227605: [BUG] Kitchensink fails "assert((((klass)->trace_id() & (JfrTraceIdEpoch::leakp_in_use_this_epoch_bit())) != 0)) failed: invariant" 8227411: [BUG] TestTimeMultiple.java failed "assert(!lease()) failed: invariant" 8224172: [BUG] assert(jfr_is_event_enabled(id)) failed: invariant 8212663: [BUG] Remove conservative at_safepoint assert when JFR writes type sets during class unloading 8216064: [BUG] -XX:StartFlightRecording:settings= doesn't work properly 8214750: [BUG] Unnecessary

tags in jfr classes 8213570: [TESTBUG] Update JFR sanity test set 8226779: [TESTBUG] Test JFR API from Java agent 8229189: [Enhancement] Improve JFR leak profiler tracing to deal with discontiguous heaps 8223438: [Enhancement] add VirtualizationInformation JFR event ------------------------------------------------------------------ From:Andrey Petushkov Send Time:2019?9?5?(???) 23:55 To:Mario Torre Cc:jdk8u-dev at openjdk.java.net Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 Hi Mario, The following fixes apply trivially to jdk11u, so I've requested the permission to backport per process. https://bugs.openjdk.java.net/browse/JDK-8220555 https://bugs.openjdk.java.net/browse/JDK-8221711 https://bugs.openjdk.java.net/browse/JDK-8222888 https://bugs.openjdk.java.net/browse/JDK-8221569 https://bugs.openjdk.java.net/browse/JDK-8216283 The rest require some rework, I'll post RFRs soon Thanks, Andrey On 4 Sep 2019, at 17:47, Mario Torre wrote: Awesome, thanks for checking zero. As discussed offline, we have a few backports that were directly backported to 8u without first being in 11u: https://bugs.openjdk.java.net/browse/JDK-8185525 https://bugs.openjdk.java.net/browse/JDK-8223599 https://bugs.openjdk.java.net/browse/JDK-8225310 https://bugs.openjdk.java.net/browse/JDK-8221711 https://bugs.openjdk.java.net/browse/JDK-8222888 https://bugs.openjdk.java.net/browse/JDK-8216283 https://bugs.openjdk.java.net/browse/JDK-8220555 https://bugs.openjdk.java.net/browse/JDK-8217362 https://bugs.openjdk.java.net/browse/JDK-8221569 https://bugs.openjdk.java.net/browse/JDK-8224217 A couple of those are wither being worked on or of interest for 11u, so they should be fine, some aren't and while may not be critical I think they are nice to have (like the container tests), so I would expect all of them to be backported to 11u. Since this is a staging repository we may go ahead and push them and work on the backport to 11 afterward, but I would prefer to not create a discrepancy at this moment, so if possible we should work on the backports to 11 first. Cheers, Mario On Wed, Sep 4, 2019 at 4:09 PM Andrey Petushkov wrote: Hi Mario, zero build is fine (e.g. mentioned method has default no-op implementation in vm_version.hpp) Andrey On 4 Sep 2019, at 12:52, Mario Torre wrote: On 03/09/2019 13:53, Andrey Petushkov wrote: Dear All, could you please consider the following set of backports of the JFR fixes from 11.0.4 release into 8u incubator baseline: This seems good, the only nit I have now is that some of those changes may break zero again, I think it may make sense to fix it in this patch set instead of filing a dedicated bug report later. See for example: JDK-8219241 +void VM_Version::print_platform_virtualization_info(outputStream* st) { etc.. 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 -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From jaroslav.bachorik at datadoghq.com Tue Sep 10 08:57:00 2019 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Tue, 10 Sep 2019 10:57:00 +0200 Subject: [8u] [jfr] RFR 8230707: JFR related tests are failing Message-ID: JIRA: https://bugs.openjdk.java.net/browse/JDK-8230707 Webrev: http://cr.openjdk.java.net/~jbachorik/8230707/ Please, review this test-only change to JFR related tests which were brought in as a part of the JFR backport effort. Due to differences in GC, runtime, compiler, etc. implementations between JDK 8 and JDK 9+ some tests need updating or complete removal. The most significant differences: - no segmented code cache - no G1 IHOP - G1 emits serial old event instead G1 full - no CI and compilation directives - no unified logging The changes are usually quite trivial (removing the offending JVM arg or removing test relying on non-existent features). With these changes in place all jdk_jfr tests are passing. Cheers, -JB- From neugens.limasoftware at gmail.com Tue Sep 10 09:38:16 2019 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Tue, 10 Sep 2019 11:38:16 +0200 Subject: [8u] [jfr] RFR 8230707: JFR related tests are failing In-Reply-To: References: Message-ID: Hi Jaroslav, Thanks for the patch. I think there are a number of commented out lines and "TODOs", we should probably remove them instead. If the test do not apply, we should remove the test, otherwise a fix may be necessary, but we can't push commented out code. The patch itself seems generally good, I guess we should only remove the commented code instances and it's ok to push? Cheers, Mario Il giorno mar 10 set 2019 alle ore 10:57 Jaroslav Bachor?k ha scritto: > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8230707 > Webrev: http://cr.openjdk.java.net/~jbachorik/8230707/ > > Please, review this test-only change to JFR related tests which were > brought in as a part of the JFR backport effort. Due to differences in GC, > runtime, compiler, etc. implementations between JDK 8 and JDK 9+ some tests > need updating or complete removal. > > The most significant differences: > - no segmented code cache > - no G1 IHOP > - G1 emits serial old event instead G1 full > - no CI and compilation directives > - no unified logging > > The changes are usually quite trivial (removing the offending JVM arg or > removing test relying on non-existent features). > > With these changes in place all jdk_jfr tests are passing. > > Cheers, > > -JB- -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From andrew_m_leonard at uk.ibm.com Tue Sep 10 10:35:37 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Tue, 10 Sep 2019 11:35:37 +0100 Subject: [8u] RFR Backport of 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target In-Reply-To: References: <16723387-7f3e-bc37-c533-9c63700d897a@oracle.com> Message-ID: Hi Andrew, Andrew, As maintainers for jdk8u, please can I request backport approval (jdk8u-fix-yes) for this bug in https://bugs.openjdk.java.net/browse/JDK-8067429 The backport patch has been reviewed by Vincente and Aleksey here: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010061.html https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010075.html Thanks Andrew 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: Vicente Romero Cc: compiler-dev at openjdk.java.net, jdk8u-dev at openjdk.java.net Date: 20/08/2019 09:45 Subject: Re: [8u] RFR Backport of 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target 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 Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From andrey at azul.com Tue Sep 10 12:50:38 2019 From: andrey at azul.com (Andrey Petushkov) Date: Tue, 10 Sep 2019 12:50:38 +0000 Subject: [8u] [JFR] RFR: JFR backports from 11.0.4 In-Reply-To: References: <72db089a-fb9f-e088-8fcd-8a6e25bec29b@redhat.com> <4DE97FAF-FB3A-41C5-BCC2-1BE799E9AA6C@azul.com> <0FE4C1EB-FCD3-435B-A944-9786BB1EC7C9@azul.com> Message-ID: <961B2FE0-A663-4912-9E78-434F1D03B5F8@azul.com> Hi Denghui, Thank you. We'll take care of it then. The list of backports we're currently working on (for jdk8u incubator) was part of initial email. For convenience please find it below: https://bugs.openjdk.java.net/browse/JDK-8185525: Add JFR event for DictionarySizes https://bugs.openjdk.java.net/browse/JDK-8213448: [TESTBUG] enhance jfr/jvm/TestDumpOnCrash https://bugs.openjdk.java.net/browse/JDK-8215727: Restore JFR thread sampler loop to old / previous behavior https://bugs.openjdk.java.net/browse/JDK-8216283: Allow shorter method sampling interval than 10 ms https://bugs.openjdk.java.net/browse/JDK-8217362: Emergency dump does not work when disk=false is set https://bugs.openjdk.java.net/browse/JDK-8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64 https://bugs.openjdk.java.net/browse/JDK-8219566: JFR did not collect call stacks when MaxJavaStackTraceDepth is set to zero https://bugs.openjdk.java.net/browse/JDK-8219997: [TESTBUG] Create test for JFR events in Docker container: CPU, Memory and Process Info https://bugs.openjdk.java.net/browse/JDK-8220293: Deadlock in JFR string pool https://bugs.openjdk.java.net/browse/JDK-8220555: JFR tool shows potentially misleading message when it cannot access a file https://bugs.openjdk.java.net/browse/JDK-8220657: JFR.dump does not work when filename is set https://bugs.openjdk.java.net/browse/JDK-8221569: JFR tool produces incorrect output when both --categories and --events are specified https://bugs.openjdk.java.net/browse/JDK-8221711: [TESTBUG] create more tests for JFR in container environment https://bugs.openjdk.java.net/browse/JDK-8222888: [TESTBUG] docker/TestJFREvents.java fails due to "RuntimeException: JAVA_MAIN_CLASS_ is not defined" https://bugs.openjdk.java.net/browse/JDK-8223438: add VirtualizationInformation JFR event https://bugs.openjdk.java.net/browse/JDK-8223599: minimal build fails after JDK-8185525 https://bugs.openjdk.java.net/browse/JDK-8224217: RecordingInfo should use textual representation of path https://bugs.openjdk.java.net/browse/JDK-8225310: JFR crashed in JfrPeriodicEventSet::requestProtectionDomainCacheTableStatistics() from these there are number of issues which are not yet ported to jdk11u. We're on it, some of them have been pushed to jdk11u today. The rest are: https://bugs.openjdk.java.net/browse/JDK-8185525: Add JFR event for DictionarySizes https://bugs.openjdk.java.net/browse/JDK-8223599: minimal build fails after JDK-8185525 https://bugs.openjdk.java.net/browse/JDK-8225310: JFR crashed in JfrPeriodicEventSet::requestProtectionDomainCacheTableStatistics() https://bugs.openjdk.java.net/browse/JDK-8217362: Emergency dump does not work when disk=false is set https://bugs.openjdk.java.net/browse/JDK-8224217: RecordingInfo should use textual representation of path we'll working on preparing review requests for those into jdk11u Best Regards, Andrey > On 10 Sep 2019, at 08:04, DDH wrote: > > Hi Andrey, > > Since you have already processed on 8223438([Enhancement] add VirtualizationInformation JFR event), > we think that we don't need to do this issue again, we will remove it from our list. > By the way, can you send us a complete list that you will backport? We can double check there are any repeated issues. > > Thanks, > DDH > ------------------------------------------------------------------ > From:Andrey Petushkov > Send Time:2019?9?9?(???) 20:59 > To:Mario Torre ; ???(??) > Cc:jdk8u-dev ; Ekaterina Vergizova > Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 > > Hi Denghui, > > Just a note, from the list below one backport (8223438: [Enhancement] add VirtualizationInformation JFR event) > is already proposed for integration as part of Azul's effort ([1]). > However since it's not yet integrated into jdk11u there still work to be done. We can do it, but if you'd like > and if you feel it's more convenient, you can take over. Anyway you might want to check implementation of > the backport in the respective webrev ([2]). Please let us know, thanks > > Regards, > Andrey > > [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-September/010204.html > [2] http://cr.openjdk.java.net/~apetushkov/jfr_backports_katya/11.0.4/ > > On 9 Sep 2019, at 12:37, Mario Torre wrote: > > Hi Denghui, > > Yes, the list looks good to me. As you mentioned, we should try first > the 11u backports and then backport to 8u. > > The process for the backport is highlighted here: > https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix > > Cheers, > Mario > > On Mon, Sep 9, 2019 at 4:07 AM DDH wrote: > > hi all, > We(Alibaba) picked some jfr backports as follows from JBS > (https://bugs.openjdk.java.net/browse/JDK-8230624?jql=Subcomponent%20%3D%20jfr%20and%20resolution%20%3D%20Fixed%20and%20fixVersion%20%3E%2011.0.6%20and%20type%20!%3D%20Backport), we > think it is worth porting them to 8u/11u. > We plan to backport them to 11u at first, and then to 8u, what's your comment? > If you think it is reasonable, we can provide our webrev of some issues as soon as possible, and continue work on other issues. > > 8223396: [TESTBUG] several jfr tests do not clean up files created in /tmp > 8225004: Remove invalid assertion in jfr_conditional_flush() > 8214542: [BUG] JFR: Old Object Sample event slow on a deep heap in debug builds (Unresolved) > 8228834: [BUG] Regression caused by JDK-8214542 not installing complete checkpoint data to candidates > 8228359: [TESTBUG] jdk.jfr.e.g.c.TestGCHeapConfigurationEventWith32BitOops.java does not expect MinHeapSize to be aligned to HeapAlignment > 8227605: [BUG] Kitchensink fails "assert((((klass)->trace_id() & (JfrTraceIdEpoch::leakp_in_use_this_epoch_bit())) != 0)) failed: invariant" > 8227411: [BUG] TestTimeMultiple.java failed "assert(!lease()) failed: invariant" > 8224172: [BUG] assert(jfr_is_event_enabled(id)) failed: invariant > 8212663: [BUG] Remove conservative at_safepoint assert when JFR writes type sets during class unloading > 8216064: [BUG] -XX:StartFlightRecording:settings= doesn't work properly > 8214750: [BUG] Unnecessary

tags in jfr classes > 8213570: [TESTBUG] Update JFR sanity test set > 8226779: [TESTBUG] Test JFR API from Java agent > 8229189: [Enhancement] Improve JFR leak profiler tracing to deal with discontiguous heaps > 8223438: [Enhancement] add VirtualizationInformation JFR event > > ------------------------------------------------------------------ > From:Andrey Petushkov > Send Time:2019?9?5?(???) 23:55 > To:Mario Torre > Cc:jdk8u-dev at openjdk.java.net > Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 > > Hi Mario, > > The following fixes apply trivially to jdk11u, so I've requested the permission to backport per process. > > https://bugs.openjdk.java.net/browse/JDK-8220555 > https://bugs.openjdk.java.net/browse/JDK-8221711 > https://bugs.openjdk.java.net/browse/JDK-8222888 > https://bugs.openjdk.java.net/browse/JDK-8221569 > https://bugs.openjdk.java.net/browse/JDK-8216283 > > The rest require some rework, I'll post RFRs soon > > Thanks, > Andrey > > On 4 Sep 2019, at 17:47, Mario Torre wrote: > > Awesome, thanks for checking zero. > > As discussed offline, we have a few backports that were directly > backported to 8u without first being in 11u: > > https://bugs.openjdk.java.net/browse/JDK-8185525 > https://bugs.openjdk.java.net/browse/JDK-8223599 > https://bugs.openjdk.java.net/browse/JDK-8225310 > https://bugs.openjdk.java.net/browse/JDK-8221711 > https://bugs.openjdk.java.net/browse/JDK-8222888 > https://bugs.openjdk.java.net/browse/JDK-8216283 > https://bugs.openjdk.java.net/browse/JDK-8220555 > https://bugs.openjdk.java.net/browse/JDK-8217362 > https://bugs.openjdk.java.net/browse/JDK-8221569 > https://bugs.openjdk.java.net/browse/JDK-8224217 > > A couple of those are wither being worked on or of interest for 11u, > so they should be fine, some aren't and while may not be critical I > think they are nice to have (like the container tests), so I would > expect all of them to be backported to 11u. > > Since this is a staging repository we may go ahead and push them and > work on the backport to 11 afterward, but I would prefer to not create > a discrepancy at this moment, so if possible we should work on the > backports to 11 first. > > Cheers, > Mario > > > On Wed, Sep 4, 2019 at 4:09 PM Andrey Petushkov wrote: > > Hi Mario, > > zero build is fine (e.g. mentioned method has default no-op implementation in vm_version.hpp) > > Andrey > > On 4 Sep 2019, at 12:52, Mario Torre wrote: > > On 03/09/2019 13:53, Andrey Petushkov wrote: > Dear All, > > could you please consider the following set of backports of the JFR fixes from 11.0.4 release into 8u incubator baseline: > > This seems good, the only nit I have now is that some of those changes > may break zero again, I think it may make sense to fix it in this patch > set instead of filing a dedicated bug report later. > > See for example: > > JDK-8219241 > > +void VM_Version::print_platform_virtualization_info(outputStream* st) { > > etc.. > > 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 > > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > From jaroslav.bachorik at datadoghq.com Tue Sep 10 12:54:25 2019 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Tue, 10 Sep 2019 14:54:25 +0200 Subject: [8u] [jfr] RFR 8230707: JFR related tests are failing In-Reply-To: References: Message-ID: Hi Mario, thanks for the comments. I left in the comments because I wanted to avoid a situation when we remove the tests now because of lacking implementation and then when the implementation is added nobody will remember to modify JFR tests back. Not sure what is the correct process for this. Thing is that the missing stuff is quite heavy weight and would ideally be ported by someone with good understanding of the backported feature as JDK 8 implementation will differ significantly. Anyway, if the correct way is just to remove non-functional, commented out lines I will do it, no problem. Cheers, -JB- On Tue, Sep 10, 2019 at 11:38 AM Mario Torre wrote: > Hi Jaroslav, > > Thanks for the patch. I think there are a number of commented out > lines and "TODOs", we should probably remove them instead. If the test > do not apply, we should remove the test, otherwise a fix may be > necessary, but we can't push commented out code. > > The patch itself seems generally good, I guess we should only remove > the commented code instances and it's ok to push? > > Cheers, > Mario > > Il giorno mar 10 set 2019 alle ore 10:57 Jaroslav Bachor?k > ha scritto: > > > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8230707 > > Webrev: http://cr.openjdk.java.net/~jbachorik/8230707/ > > > > Please, review this test-only change to JFR related tests which were > > brought in as a part of the JFR backport effort. Due to differences in > GC, > > runtime, compiler, etc. implementations between JDK 8 and JDK 9+ some > tests > > need updating or complete removal. > > > > The most significant differences: > > - no segmented code cache > > - no G1 IHOP > > - G1 emits serial old event instead G1 full > > - no CI and compilation directives > > - no unified logging > > > > The changes are usually quite trivial (removing the offending JVM arg or > > removing test relying on non-existent features). > > > > With these changes in place all jdk_jfr tests are passing. > > > > Cheers, > > > > -JB- > > > > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens > Proud GNU Classpath developer: http://www.classpath.org/ > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ > From shade at redhat.com Tue Sep 10 17:09:17 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 10 Sep 2019 19:09:17 +0200 Subject: [8u] RFA 8010500: [parfait] Possible null pointer dereference at hotspot/src/share/vm/opto/loopnode.hpp Message-ID: Hi, I would like to request *approval* for this 8u backport: https://hg.openjdk.java.net/jdk/jdk/rev/4d686766ac23 The issue itself is Confidential, and so our usual approval process does not work. The issue cannot be opened, because it contains confidential information, alas. Patch applies cleanly to 8u, passes regular tier1 testing. It is required to fix fuzzer test failure caught by JDK-8230238: that test would SEGV exactly where the warning told us. I would push JDK-8230238 right after this fix. -- Thanks, -Aleksey From jaroslav.bachorik at datadoghq.com Tue Sep 10 18:06:28 2019 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Tue, 10 Sep 2019 20:06:28 +0200 Subject: [8u] [jfr] RFR 8230707: JFR related tests are failing In-Reply-To: References: Message-ID: I have removed all the TODOs and commented out lines - http://cr.openjdk.java.net/~jbachorik/8230707/jdk/webrev.01/ -JB- On Tue, Sep 10, 2019 at 2:54 PM Jaroslav Bachor?k < jaroslav.bachorik at datadoghq.com> wrote: > Hi Mario, > > thanks for the comments. I left in the comments because I wanted to avoid > a situation when we remove the tests now because of lacking implementation > and then when the implementation is added nobody will remember to modify > JFR tests back. > Not sure what is the correct process for this. Thing is that the missing > stuff is quite heavy weight and would ideally be ported by someone with > good understanding of the backported feature as JDK 8 implementation will > differ significantly. > > Anyway, if the correct way is just to remove non-functional, commented out > lines I will do it, no problem. > > Cheers, > > -JB- > > On Tue, Sep 10, 2019 at 11:38 AM Mario Torre < > neugens.limasoftware at gmail.com> wrote: > >> Hi Jaroslav, >> >> Thanks for the patch. I think there are a number of commented out >> lines and "TODOs", we should probably remove them instead. If the test >> do not apply, we should remove the test, otherwise a fix may be >> necessary, but we can't push commented out code. >> >> The patch itself seems generally good, I guess we should only remove >> the commented code instances and it's ok to push? >> >> Cheers, >> Mario >> >> Il giorno mar 10 set 2019 alle ore 10:57 Jaroslav Bachor?k >> ha scritto: >> > >> > JIRA: https://bugs.openjdk.java.net/browse/JDK-8230707 >> > Webrev: http://cr.openjdk.java.net/~jbachorik/8230707/ >> > >> > Please, review this test-only change to JFR related tests which were >> > brought in as a part of the JFR backport effort. Due to differences in >> GC, >> > runtime, compiler, etc. implementations between JDK 8 and JDK 9+ some >> tests >> > need updating or complete removal. >> > >> > The most significant differences: >> > - no segmented code cache >> > - no G1 IHOP >> > - G1 emits serial old event instead G1 full >> > - no CI and compilation directives >> > - no unified logging >> > >> > The changes are usually quite trivial (removing the offending JVM arg or >> > removing test relying on non-existent features). >> > >> > With these changes in place all jdk_jfr tests are passing. >> > >> > Cheers, >> > >> > -JB- >> >> >> >> -- >> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF >> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF >> >> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens >> Proud GNU Classpath developer: http://www.classpath.org/ >> OpenJDK: http://openjdk.java.net/projects/caciocavallo/ >> >> Please, support open standards: >> http://endsoftpatents.org/ >> > From shade at redhat.com Tue Sep 10 18:47:52 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 10 Sep 2019 20:47:52 +0200 Subject: [8u] RFR 8225425: java.lang.UnsatisfiedLinkError: net.dll: Can't find dependent libraries Message-ID: Original bug: https://bugs.openjdk.java.net/browse/JDK-8230573 https://hg.openjdk.java.net/jdk/jdk/rev/56df9a08ed9c 11u fix (would be handy for URIBuilder, see below): https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/343f922e2fbe This is in 8u231, so it is important to get it into jdk8u232. Ivan, Chris, can you eyeball it too, please? The patch does not apply cleanly, because build system is different, the context is different, test library layout is different, URIBuilder is not there, etc. 8u webrev: https://cr.openjdk.java.net/~shade/8225425/webrev.8u.01/ Notable changes w.r.t. original fix: *) The build system fix goes into make/lib/NetworkingLibraries.gmk, not in make/lib/Lib-java.base.gmk *) src/java.base/windows/native/libnet/NTLMAuthentication.c failed to apply, because "LPCWSTR bstrURL;" was in context. Had to reapply the entire patch to that file by hand. *) test/lib/jdk/test/lib/net/URIBuilder.java put into location that fits 8u. *) test/sun/net/www/protocol/http/TestTransparentNTLM.java has several changes: Fit new location of URIBuilder: 30 * @library ../../../../../lib/ Read the InputStream without readAllBytes method (added in 9): 85 InputStream is = uc.getInputStream(); 86 byte[] buf = new byte[1024]; 87 while (is.read(buf) != -1) {}; Testing: new test on Windows, jdk_security on Windows; eyeballing net.dll dependencies before/after the fix -- urlmon.dll is indeed gone; Linux x86_64 tier1 -- Thanks, -Aleksey From bourges.laurent at gmail.com Wed Sep 11 07:27:55 2019 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 11 Sep 2019 09:27:55 +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: Hi Andrews, I successfull imported 2 patches fixing the PNGImageWriter... Your instructions were precious but I give you my feedback as it could improve the wiki / process / howto: - I cloned jdk8u-dev, jdk9/jdk to find my original by changeset id as the unshuffle-script needs git diff format only - my first attempt did not apply cleanly (hg import 8-fixed-patch) as PNGImageWriter was changed by another jdk9 fix - I used the hg web interface to easily read the file history... it is painful as jdk9u does not have the complete history... only jdk9/jdk has the complete changeset log. http://hg.openjdk.java.net/jdk9/jdk9/jdk/log/65464a307408/src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java 2015-12-16 prr 6488522: PNG writer should permit setting compression level and iDAT chunk maximum size 2015-12-01 jdv 6967419: IndexOutOfBoundsException when drawing PNGs - I rollbacked my first attempt, extracted the 2 patches from jdk9(hg export --git changeset-id > file), fixed them (unshuffle-script from jdk9u) and applied the 2 jdk8-fixed patches in order and it applied well. I made a clean build (jdk8u-dev/ make images) and ran manually my tests: imageio & png only. The jdk-updates says I must run tier1 tests but the command 'make run-tests tier1' does not work... Anyway these patches only affect javax/imageio ... Which jtreg build should I use with jdk8u ? My recent jtreg binaries fails to parse jdk8 version string ! Where can I download it ? What is the process now to propose these 2 png patches for jdk8u integration ? I can just put the jdk8u-fix-request label on these 2 bugs, but is it enough ? I also need a jdk8u sponsor, as I am not a committer on 8 but >= 9... I can start a RFR thread on this png encoder topic: The jdk9 fix changes the default deflater level 9 to 4 to reduce the cpu overhead and improve png encoding performance: see original RFR thread https://bugs.openjdk.java.net/browse/JDK-6488522 " I quickly tested several Deflater compression levels [0 to 9] on some huge map images: * total size: * level 1: 49.9 Mb * level 3: 46.9 Mb * level 4: 40.7 Mb * level 9: 37 Mb * write PNG time (most complex image) : * level 1: 8211 ms * level 3: 7793 ms * level 4: 9450 ms * level 9: 23562 ms I would choose by default the level 4 to have the best compromise between speed vs time. " Do you agree or not as it will change the jdk8 behaviour ? Thanks, Laurent Le mer. 21 ao?t 2019 ? 18:08, Andrew John Hughes 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 > > -- > 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 kshefov at azul.com Wed Sep 11 07:53:13 2019 From: kshefov at azul.com (Konstantin Shefov) Date: Wed, 11 Sep 2019 07:53:13 +0000 Subject: Backport vmTestbase tests to jdk8u-dev? In-Reply-To: References: Message-ID: <9ba7e7af9a1645c4831610327c96f22b@azul.com> Hi, LX Answering to your e-mail, as for what we modified in [3]: 1. API changes (Process, Unsafe), Xloggc option, that were not in your patches; 2. In a file hotspot/test/JtregNativeHotspot.gmk we changed ?-lpthread? option to ?-pthread? to prevent compilation error. I agree that there should be a series of patches to track file changes. As for investigation of failures: do you have the same? We ran against Arm64 platform, but we can try against x86-64 too. Konstantin From: Liu, Xin Sent: Monday, September 9, 2019 11:04 PM To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, We are glad to work with you to get vmTestbase landed into jdk8u. Our original intent is get design reviewed by the jdk8u maintainer. After then, we can proceed to refactor it. We can work together to refactor it. we plan to do it anyway. Back to the webrev you send. What did you modify in [3]? Ideally, we can should have a series of patches. The first one should be intact vmTestbase code from the tip of JDK. All we changes should come after it and be reviewed by this mail-list. In addition to refactoring, we can also offer help to figure out those failed cases. What do you think? Thanks, --lx From: Konstantin Shefov > Date: Friday, September 6, 2019 at 12:55 PM To: "jdk8u-dev at openjdk.java.net" > Cc: "Liu, Xin" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, We at Azul think it is a good idea to backport vmTestbase tests to OpenJDK 8. We have used patches you suggested, done some refactoring to enable more tests to work with JDK 8. We have run all 3550 tests from ?vmTestbase? folder against Zulu 8 at ARM64 platform: 1. 3371 tests PASS (see [1]); 2. 179 tests FAIL (see [2]): reasons are being investigated. Patches we have used (contain our refactoring): 1. Hotspot folder [3] 2. Main folder [4] We plan to investigate causes of those 177 failures, purify unused code from hotspot/test/test/lib/jdk, and run the tests against different platforms. We also compared vmTestbase from JDK 11 with that from JDK 13, we found out: 1. 332 test have been removed in JDK 13; 2. Only 2 test have been added in JDK 13; 3. Tests that remained were modified, but these modifications mostly are copyright years, or output format, or API changes. From the above results we can tell that vmTestbase does not grow. It looks like that tests are been removed from there or transferred somewhere else. [1] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/passed_tests.html [2] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/failed_tests.html [3] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_hotspot.patch [4] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_root.patch Regards, --Konstantin From chris.hegarty at oracle.com Wed Sep 11 08:53:03 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 11 Sep 2019 09:53:03 +0100 Subject: [8u] RFR 8225425: java.lang.UnsatisfiedLinkError: net.dll: Can't find dependent libraries In-Reply-To: References: Message-ID: <20df0ec0-ab0e-348d-6a9d-1c626f959774@oracle.com> Aleksey, On 10/09/2019 19:47, Aleksey Shipilev wrote: > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8230573 > https://hg.openjdk.java.net/jdk/jdk/rev/56df9a08ed9c > > 11u fix (would be handy for URIBuilder, see below): > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/343f922e2fbe > > This is in 8u231, so it is important to get it into jdk8u232. Ivan, Chris, can you eyeball it too, > please? > > The patch does not apply cleanly, because build system is different, the context is different, test > library layout is different, URIBuilder is not there, etc. > > 8u webrev: > https://cr.openjdk.java.net/~shade/8225425/webrev.8u.01/ Looks fine. > Notable changes w.r.t. original fix: > > *) The build system fix goes into make/lib/NetworkingLibraries.gmk, not in make/lib/Lib-java.base.gmk > > *) src/java.base/windows/native/libnet/NTLMAuthentication.c failed to apply, because "LPCWSTR > bstrURL;" was in context. Had to reapply the entire patch to that file by hand. > > *) test/lib/jdk/test/lib/net/URIBuilder.java put into location that fits 8u. > > *) test/sun/net/www/protocol/http/TestTransparentNTLM.java has several changes: > > Fit new location of URIBuilder: > 30 * @library ../../../../../lib/ > > Read the InputStream without readAllBytes method (added in 9): > 85 InputStream is = uc.getInputStream(); > 86 byte[] buf = new byte[1024]; > 87 while (is.read(buf) != -1) {}; These changes w.r.t. original fix, seem reasonable. -Chris. From neugens at redhat.com Wed Sep 11 09:27:35 2019 From: neugens at redhat.com (Mario Torre) Date: Wed, 11 Sep 2019 11:27:35 +0200 Subject: [8u] [jfr] RFR 8230707: JFR related tests are failing In-Reply-To: References: Message-ID: Hi Jaroslav, Thanks for addressing my concerns, the patch looks good! Cheers, Mario On Tue, Sep 10, 2019 at 8:07 PM Jaroslav Bachor?k wrote: > > I have removed all the TODOs and commented out lines - > http://cr.openjdk.java.net/~jbachorik/8230707/jdk/webrev.01/ > > -JB- > > On Tue, Sep 10, 2019 at 2:54 PM Jaroslav Bachor?k < > jaroslav.bachorik at datadoghq.com> wrote: > > > Hi Mario, > > > > thanks for the comments. I left in the comments because I wanted to avoid > > a situation when we remove the tests now because of lacking implementation > > and then when the implementation is added nobody will remember to modify > > JFR tests back. > > Not sure what is the correct process for this. Thing is that the missing > > stuff is quite heavy weight and would ideally be ported by someone with > > good understanding of the backported feature as JDK 8 implementation will > > differ significantly. > > > > Anyway, if the correct way is just to remove non-functional, commented out > > lines I will do it, no problem. > > > > Cheers, > > > > -JB- > > > > On Tue, Sep 10, 2019 at 11:38 AM Mario Torre < > > neugens.limasoftware at gmail.com> wrote: > > > >> Hi Jaroslav, > >> > >> Thanks for the patch. I think there are a number of commented out > >> lines and "TODOs", we should probably remove them instead. If the test > >> do not apply, we should remove the test, otherwise a fix may be > >> necessary, but we can't push commented out code. > >> > >> The patch itself seems generally good, I guess we should only remove > >> the commented code instances and it's ok to push? > >> > >> Cheers, > >> Mario > >> > >> Il giorno mar 10 set 2019 alle ore 10:57 Jaroslav Bachor?k > >> ha scritto: > >> > > >> > JIRA: https://bugs.openjdk.java.net/browse/JDK-8230707 > >> > Webrev: http://cr.openjdk.java.net/~jbachorik/8230707/ > >> > > >> > Please, review this test-only change to JFR related tests which were > >> > brought in as a part of the JFR backport effort. Due to differences in > >> GC, > >> > runtime, compiler, etc. implementations between JDK 8 and JDK 9+ some > >> tests > >> > need updating or complete removal. > >> > > >> > The most significant differences: > >> > - no segmented code cache > >> > - no G1 IHOP > >> > - G1 emits serial old event instead G1 full > >> > - no CI and compilation directives > >> > - no unified logging > >> > > >> > The changes are usually quite trivial (removing the offending JVM arg or > >> > removing test relying on non-existent features). > >> > > >> > With these changes in place all jdk_jfr tests are passing. > >> > > >> > Cheers, > >> > > >> > -JB- > >> > >> > >> > >> -- > >> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > >> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > >> > >> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens > >> Proud GNU Classpath developer: http://www.classpath.org/ > >> OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > >> > >> Please, support open standards: > >> http://endsoftpatents.org/ > >> > > -- 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 Sep 11 09:30:26 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 11 Sep 2019 11:30:26 +0200 Subject: [8u] RFR 8225425: java.lang.UnsatisfiedLinkError: net.dll: Can't find dependent libraries In-Reply-To: <20df0ec0-ab0e-348d-6a9d-1c626f959774@oracle.com> References: <20df0ec0-ab0e-348d-6a9d-1c626f959774@oracle.com> Message-ID: On 9/11/19 10:53 AM, Chris Hegarty wrote: >> 8u webrev: >> ?? https://cr.openjdk.java.net/~shade/8225425/webrev.8u.01/ > > Looks fine. Thanks! -- -Aleksey From jaroslav.bachorik at datadoghq.com Wed Sep 11 10:20:20 2019 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Wed, 11 Sep 2019 12:20:20 +0200 Subject: [8u] [JFR] RFR: JFR backports from 11.0.4 In-Reply-To: <961B2FE0-A663-4912-9E78-434F1D03B5F8@azul.com> References: <72db089a-fb9f-e088-8fcd-8a6e25bec29b@redhat.com> <4DE97FAF-FB3A-41C5-BCC2-1BE799E9AA6C@azul.com> <0FE4C1EB-FCD3-435B-A944-9786BB1EC7C9@azul.com> <961B2FE0-A663-4912-9E78-434F1D03B5F8@azul.com> Message-ID: Hi all, we are planning to port also the following patches https://bugs.openjdk.java.net/browse/JDK-8210158 (already in 11u) https://bugs.openjdk.java.net/browse/JDK-8225797 (being worked on in dev, will be backported to 11u adn jdk8u once done) Cheers, -JB- On Tue, Sep 10, 2019 at 2:53 PM Andrey Petushkov wrote: > Hi Denghui, > > Thank you. We'll take care of it then. > The list of backports we're currently working on (for jdk8u incubator) > was part of initial email. For convenience please find it below: > > https://bugs.openjdk.java.net/browse/JDK-8185525: Add JFR event for > DictionarySizes > https://bugs.openjdk.java.net/browse/JDK-8213448: [TESTBUG] enhance > jfr/jvm/TestDumpOnCrash > https://bugs.openjdk.java.net/browse/JDK-8215727: Restore JFR thread > sampler loop to old / previous behavior > https://bugs.openjdk.java.net/browse/JDK-8216283: Allow shorter method > sampling interval than 10 ms > https://bugs.openjdk.java.net/browse/JDK-8217362: Emergency dump does not > work when disk=false is set > https://bugs.openjdk.java.net/browse/JDK-8219241: Provide basic > virtualization related info in the hs_error file on linux/windows x86_64 > https://bugs.openjdk.java.net/browse/JDK-8219566: JFR did not collect > call stacks when MaxJavaStackTraceDepth is set to zero > https://bugs.openjdk.java.net/browse/JDK-8219997: [TESTBUG] Create test > for JFR events in Docker container: CPU, Memory and Process Info > https://bugs.openjdk.java.net/browse/JDK-8220293: Deadlock in JFR string > pool > https://bugs.openjdk.java.net/browse/JDK-8220555: JFR tool shows > potentially misleading message when it cannot access a file > https://bugs.openjdk.java.net/browse/JDK-8220657: JFR.dump does not work > when filename is set > https://bugs.openjdk.java.net/browse/JDK-8221569: JFR tool produces > incorrect output when both --categories and --events are specified > https://bugs.openjdk.java.net/browse/JDK-8221711: [TESTBUG] create more > tests for JFR in container environment > https://bugs.openjdk.java.net/browse/JDK-8222888: [TESTBUG] > docker/TestJFREvents.java fails due to "RuntimeException: JAVA_MAIN_CLASS_ > is not defined" > https://bugs.openjdk.java.net/browse/JDK-8223438: add > VirtualizationInformation JFR event > https://bugs.openjdk.java.net/browse/JDK-8223599: minimal build fails > after JDK-8185525 > https://bugs.openjdk.java.net/browse/JDK-8224217: RecordingInfo should > use textual representation of path > https://bugs.openjdk.java.net/browse/JDK-8225310: JFR crashed in > JfrPeriodicEventSet::requestProtectionDomainCacheTableStatistics() > > from these there are number of issues which are not yet ported to jdk11u. > We're on it, > some of them have been pushed to jdk11u today. The rest are: > > https://bugs.openjdk.java.net/browse/JDK-8185525: Add JFR event for > DictionarySizes > https://bugs.openjdk.java.net/browse/JDK-8223599: minimal build fails > after JDK-8185525 > https://bugs.openjdk.java.net/browse/JDK-8225310: JFR crashed in > JfrPeriodicEventSet::requestProtectionDomainCacheTableStatistics() > https://bugs.openjdk.java.net/browse/JDK-8217362: Emergency dump does not > work when disk=false is set > https://bugs.openjdk.java.net/browse/JDK-8224217: RecordingInfo should > use textual representation of path > > we'll working on preparing review requests for those into jdk11u > > Best Regards, > Andrey > > > On 10 Sep 2019, at 08:04, DDH wrote: > > > > Hi Andrey, > > > > Since you have already processed on 8223438([Enhancement] add > VirtualizationInformation JFR event), > > we think that we don't need to do this issue again, we will remove it > from our list. > > By the way, can you send us a complete list that you will backport? > We can double check there are any repeated issues. > > > > Thanks, > > DDH > > ------------------------------------------------------------------ > > From:Andrey Petushkov > > Send Time:2019?9?9?(???) 20:59 > > To:Mario Torre ; ???(??) < > denghui.ddh at alibaba-inc.com> > > Cc:jdk8u-dev ; Ekaterina Vergizova < > katya at azul.com> > > Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 > > > > Hi Denghui, > > > > Just a note, from the list below one backport (8223438: [Enhancement] > add VirtualizationInformation JFR event) > > is already proposed for integration as part of Azul's effort ([1]). > > However since it's not yet integrated into jdk11u there still work to be > done. We can do it, but if you'd like > > and if you feel it's more convenient, you can take over. Anyway you > might want to check implementation of > > the backport in the respective webrev ([2]). Please let us know, thanks > > > > Regards, > > Andrey > > > > [1] > http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-September/010204.html > > [2] http://cr.openjdk.java.net/~apetushkov/jfr_backports_katya/11.0.4/ > > > > On 9 Sep 2019, at 12:37, Mario Torre wrote: > > > > Hi Denghui, > > > > Yes, the list looks good to me. As you mentioned, we should try first > > the 11u backports and then backport to 8u. > > > > The process for the backport is highlighted here: > > https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix > > > > Cheers, > > Mario > > > > On Mon, Sep 9, 2019 at 4:07 AM DDH wrote: > > > > hi all, > > We(Alibaba) picked some jfr backports as follows from JBS > > ( > https://bugs.openjdk.java.net/browse/JDK-8230624?jql=Subcomponent%20%3D%20jfr%20and%20resolution%20%3D%20Fixed%20and%20fixVersion%20%3E%2011.0.6%20and%20type%20!%3D%20Backport), > we > > think it is worth porting them to 8u/11u. > > We plan to backport them to 11u at first, and then to 8u, what's your > comment? > > If you think it is reasonable, we can provide our webrev of some issues > as soon as possible, and continue work on other issues. > > > > 8223396: [TESTBUG] several jfr tests do not clean up files created in > /tmp > > 8225004: Remove invalid assertion in jfr_conditional_flush() > > 8214542: [BUG] JFR: Old Object Sample event slow on a deep heap in debug > builds (Unresolved) > > 8228834: [BUG] Regression caused by JDK-8214542 not installing complete > checkpoint data to candidates > > 8228359: [TESTBUG] > jdk.jfr.e.g.c.TestGCHeapConfigurationEventWith32BitOops.java does not > expect MinHeapSize to be aligned to HeapAlignment > > 8227605: [BUG] Kitchensink fails "assert((((klass)->trace_id() & > (JfrTraceIdEpoch::leakp_in_use_this_epoch_bit())) != 0)) failed: invariant" > > 8227411: [BUG] TestTimeMultiple.java failed "assert(!lease()) failed: > invariant" > > 8224172: [BUG] assert(jfr_is_event_enabled(id)) failed: invariant > > 8212663: [BUG] Remove conservative at_safepoint assert when JFR writes > type sets during class unloading > > 8216064: [BUG] -XX:StartFlightRecording:settings= doesn't work properly > > 8214750: [BUG] Unnecessary

tags in jfr classes > > 8213570: [TESTBUG] Update JFR sanity test set > > 8226779: [TESTBUG] Test JFR API from Java agent > > 8229189: [Enhancement] Improve JFR leak profiler tracing to deal with > discontiguous heaps > > 8223438: [Enhancement] add VirtualizationInformation JFR event > > > > ------------------------------------------------------------------ > > From:Andrey Petushkov > > Send Time:2019?9?5?(???) 23:55 > > To:Mario Torre > > Cc:jdk8u-dev at openjdk.java.net > > Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 > > > > Hi Mario, > > > > The following fixes apply trivially to jdk11u, so I've requested the > permission to backport per process. > > > > https://bugs.openjdk.java.net/browse/JDK-8220555 > > https://bugs.openjdk.java.net/browse/JDK-8221711 > > https://bugs.openjdk.java.net/browse/JDK-8222888 > > https://bugs.openjdk.java.net/browse/JDK-8221569 > > https://bugs.openjdk.java.net/browse/JDK-8216283 > > > > The rest require some rework, I'll post RFRs soon > > > > Thanks, > > Andrey > > > > On 4 Sep 2019, at 17:47, Mario Torre wrote: > > > > Awesome, thanks for checking zero. > > > > As discussed offline, we have a few backports that were directly > > backported to 8u without first being in 11u: > > > > https://bugs.openjdk.java.net/browse/JDK-8185525 > > https://bugs.openjdk.java.net/browse/JDK-8223599 > > https://bugs.openjdk.java.net/browse/JDK-8225310 > > https://bugs.openjdk.java.net/browse/JDK-8221711 > > https://bugs.openjdk.java.net/browse/JDK-8222888 > > https://bugs.openjdk.java.net/browse/JDK-8216283 > > https://bugs.openjdk.java.net/browse/JDK-8220555 > > https://bugs.openjdk.java.net/browse/JDK-8217362 > > https://bugs.openjdk.java.net/browse/JDK-8221569 > > https://bugs.openjdk.java.net/browse/JDK-8224217 > > > > A couple of those are wither being worked on or of interest for 11u, > > so they should be fine, some aren't and while may not be critical I > > think they are nice to have (like the container tests), so I would > > expect all of them to be backported to 11u. > > > > Since this is a staging repository we may go ahead and push them and > > work on the backport to 11 afterward, but I would prefer to not create > > a discrepancy at this moment, so if possible we should work on the > > backports to 11 first. > > > > Cheers, > > Mario > > > > > > On Wed, Sep 4, 2019 at 4:09 PM Andrey Petushkov wrote: > > > > Hi Mario, > > > > zero build is fine (e.g. mentioned method has default no-op > implementation in vm_version.hpp) > > > > Andrey > > > > On 4 Sep 2019, at 12:52, Mario Torre wrote: > > > > On 03/09/2019 13:53, Andrey Petushkov wrote: > > Dear All, > > > > could you please consider the following set of backports of the JFR > fixes from 11.0.4 release into 8u incubator baseline: > > > > This seems good, the only nit I have now is that some of those changes > > may break zero again, I think it may make sense to fix it in this patch > > set instead of filing a dedicated bug report later. > > > > See for example: > > > > JDK-8219241 > > > > +void VM_Version::print_platform_virtualization_info(outputStream* st) { > > > > etc.. > > > > 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 > > > > > > > > -- > > 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 Wed Sep 11 14:50:42 2019 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 11 Sep 2019 16:50:42 +0200 Subject: Backport proposal of the Marlin renderer in OpenJDK8 In-Reply-To: References: <7539DA05-ACC0-4BB2-8ED5-BC2F32F99ABE@azul.com> Message-ID: Hi, I am wondering how to start with such big backport. - list all original patches among 9 to 14 repositories (=11u as I backported few changes already) - use my github fork of jdk8u_jdk or stay on mercurial but a new jdk8u_marlin forrest should be created ? - identify interested people (azul, adoptopenjdk, amazon) to build a tiger team to start the concrete work - who can sponsor (committer) / review these patches ? Finally I still wonder how to deal with the former classes (RenderingEngine conflict). How did you handle this aspect in the zulu codebase ? Laurent Le jeu. 8 ao?t 2019 ? 20:51, Andrew John Hughes a ?crit : > > > 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 neugens.limasoftware at gmail.com Wed Sep 11 15:41:10 2019 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Wed, 11 Sep 2019 17:41:10 +0200 Subject: Backport proposal of the Marlin renderer in OpenJDK8 In-Reply-To: References: <7539DA05-ACC0-4BB2-8ED5-BC2F32F99ABE@azul.com> Message-ID: I suggest to do what we are doing for JFR, which means the project lead created a repository for us where we are merging individual bugs (and adding new where necessary, like minor fixes only applicable to 8u), with every commit accompanied by the relative bug id. Once everything is done, you can propose the whole batch for integration. We also mark individual bugs in Jira for the back port with a special label, so they should be easier to track. As for who approves the patches, ideally you want to have a reviewer working with you, but for the staging repository you don't strictly need it since its purpose is obviously to get the patches back ported and the assumption is that you are the original author so you know best ;) Once everything is ready, a reviewer will go through the patches (or the big patch) and approve it (or not!). Cheers, Mario Il giorno mer 11 set 2019 alle ore 16:51 Laurent Bourg?s ha scritto: > > Hi, > > I am wondering how to start with such big backport. > - list all original patches among 9 to 14 repositories (=11u as I > backported few changes already) > - use my github fork of jdk8u_jdk or stay on mercurial but a new > jdk8u_marlin forrest should be created ? > - identify interested people (azul, adoptopenjdk, amazon) to build a tiger > team to start the concrete work > - who can sponsor (committer) / review these patches ? > > Finally I still wonder how to deal with the former classes (RenderingEngine > conflict). How did you handle this aspect in the zulu codebase ? > > Laurent > > > Le jeu. 8 ao?t 2019 ? 20:51, Andrew John Hughes a > ?crit : > > > > > > > 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 > > -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From gnu.andrew at redhat.com Thu Sep 12 02:04:00 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 12 Sep 2019 03:04:00 +0100 Subject: [8u] 8178870: instrumentation.retransformClasses cause coredump In-Reply-To: <03cd4243-91e7-fb9f-5b5b-bbacf1de547d@redhat.com> References: <6d646175-68e2-b280-6475-cd97f2e5d438@redhat.com> <7003c233-d891-b11b-3426-f9b6f7de2d8f@redhat.com> <0bfedafb-f31c-6278-31da-56cb4abc1d34@redhat.com> <03cd4243-91e7-fb9f-5b5b-bbacf1de547d@redhat.com> Message-ID: <241f6d60-0392-4225-61aa-706dfb62e194@redhat.com> On 03/09/2019 13:24, Zhengyu Gu wrote: > Hi Andrew >>> >>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8178870-8u/webrev.01/ >>> >>> Thanks, >>> >>> -Zhengyu >>> >>> >>> >>>> >> >> This seems to contain 3 bug IDs. Please post a clean webrev for 8178870 >> once 8155951 is pushed. > > Yes. JDK-8155951 is prerequisite and its changeset contains two bug fixes. > > Updated: http://cr.openjdk.java.net/~zgu/JDK-8178870-8u/webrev.02/ > > Thanks, > > -Zhengyu > > > > >> >> Thanks, >> This looks ok. I presume you intend to commit with the correct metadata, as currently it says "imported patch JDK-8178870_coredump.patch"? As this is one of the fixes we still intend to get into 8u232, please flag the bug with jdk8u-critical-request and then push to https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot when approved. For the record, the change to scratch_classes is part of a big cleanup in https://bugs.openjdk.java.net/browse/JDK-8155672, which itself is part of the PermGen removal, so not something that can be backported as it stands. 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 Sep 12 02:11:05 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 12 Sep 2019 03:11:05 +0100 Subject: [8u] 8217676: Upgrade libpng to 1.6.37 In-Reply-To: <4a2daffd-c776-25fa-8f08-ac61949f4caa@redhat.com> References: <42cc1803-6f71-ba9d-d262-f79522071f10@redhat.com> <4a2daffd-c776-25fa-8f08-ac61949f4caa@redhat.com> Message-ID: On 03/09/2019 15:18, Zhengyu Gu wrote: > Hi Andrew, > >> The license patch seems to miss some header lines when compared with >> 11u, and also removes a section about trademarks and export control that >> isn't altered in the 11u version. How was it applied? >> >> I've attached what I get from manually applying the 11u patch to >> THIRD_PARTY_README. This diffs cleanly against libpng.md in 11u. >> > > Updated all THIRD_PARTY_README files with your patch. > > http://cr.openjdk.java.net/~zgu/JDK-8217676-8u/v2/ > > Retested with jdk_imageio. > > Thanks, > > -Zhengyu > >> Thanks, >> Looks good. As this is one of the fixes we still intend to get into 8u232, please flag the bug with jdk8u-critical-request and then push to the https://hg.openjdk.java.net/jdk8u/jdk8u/ family of repos when approved. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Thu Sep 12 02:55:47 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 12 Sep 2019 03:55:47 +0100 Subject: [8u] RFR 8225425: java.lang.UnsatisfiedLinkError: net.dll: Can't find dependent libraries In-Reply-To: References: Message-ID: On 10/09/2019 19:47, Aleksey Shipilev wrote: > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8230573 > https://hg.openjdk.java.net/jdk/jdk/rev/56df9a08ed9c > > 11u fix (would be handy for URIBuilder, see below): > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/343f922e2fbe > > This is in 8u231, so it is important to get it into jdk8u232. Ivan, Chris, can you eyeball it too, > please? That alone isn't really a reason for critical inclusion. There are other changes that have had to be deferred to 8u242. However, this looks ok for 8u232. > > The patch does not apply cleanly, because build system is different, the context is different, test > library layout is different, URIBuilder is not there, etc. > > 8u webrev: > https://cr.openjdk.java.net/~shade/8225425/webrev.8u.01/ > > Notable changes w.r.t. original fix: > > *) The build system fix goes into make/lib/NetworkingLibraries.gmk, not in make/lib/Lib-java.base.gmk > Looks fine, matches the original backport of the security fix where urlmon was added. > *) src/java.base/windows/native/libnet/NTLMAuthentication.c failed to apply, because "LPCWSTR > bstrURL;" was in context. Had to reapply the entire patch to that file by hand. > diff suggests this went well :) > *) test/lib/jdk/test/lib/net/URIBuilder.java put into location that fits 8u. > The diff I'm looking at has it at that same location: $ diffstat -p0 8225425.8u new/make/lib/NetworkingLibraries.gmk | 2 new/src/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java | 14 new/src/windows/native/sun/net/www/protocol/http/ntlm/NTLMAuthentication.c | 32 + new/test/lib/jdk/test/lib/net/URIBuilder.java | 111 +++++ new/test/sun/net/www/protocol/http/TestTransparentNTLM.java | 196 ++++++++++ 5 files changed, 349 insertions(+), 6 deletions(-) The right location would seem to be jdk/test/lib/testlibrary/jdk/testlibrary/net as jdk/test/lib/testlibrary/jdk/testlibrary/ houses JDKToolLauncher.java, which is in test/lib/jdk/test/lib/ in trunk. Why is this being backported as part of this and not a backport of https://bugs.openjdk.java.net/browse/JDK-8220575 which would also mean we get the advantages of introducing this helper class in other tests? > *) test/sun/net/www/protocol/http/TestTransparentNTLM.java has several changes: > > Fit new location of URIBuilder: > 30 * @library ../../../../../lib/ > > Read the InputStream without readAllBytes method (added in 9): > 85 InputStream is = uc.getInputStream(); > 86 byte[] buf = new byte[1024]; > 87 while (is.read(buf) != -1) {}; > This conversion loses the output of the read data. Something closer to the original would be along the lines of: InputStream is = uc.getInputStream(); BufferedReader r = new BufferedReader(new InputStreamReader(is, UTF_8); String body = r.readLine(); out.print("received body: " + body); while (body != null) { body = r.readLine(); out.print(body); } > Testing: new test on Windows, jdk_security on Windows; eyeballing net.dll dependencies before/after > the fix -- urlmon.dll is indeed gone; Linux x86_64 tier1 > -- 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 Sep 12 03:02:01 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 12 Sep 2019 04:02:01 +0100 Subject: [8u] 8222108: Reduce minRefreshTime for updating remote printer list on Windows In-Reply-To: References: <3b26ee23-1124-7538-6ba0-d5f021fdd12e@redhat.com> Message-ID: <7c348032-eced-179a-82fa-c015db60d693@redhat.com> On 03/09/2019 13:56, Zhengyu Gu wrote: > > > On 9/3/19 1:12 AM, Andrew John Hughes wrote: >> >> >> On 27/08/2019 14:39, Zhengyu Gu wrote: >>> >>> 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 >> >> This mostly looks ok, but one change seems to have been missed; the >> prevRemotePrinters variable is not removed. Was there a reason for this? > > My bad. > > Updated: http://cr.openjdk.java.net/~zgu/JDK-8222108-8u/webrev.01/ > > Retested on Windows x86_64 > > Thanks, > > -Zhengyu > Looks good. As this is one of the fixes we still intend to get into 8u232, please flag the bug with jdk8u-critical-request and then push to https://hg.openjdk.java.net/jdk8u/jdk8u/jdk when approved. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From zgu at redhat.com Thu Sep 12 12:28:25 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 12 Sep 2019 08:28:25 -0400 Subject: [8u] 8178870: instrumentation.retransformClasses cause coredump In-Reply-To: <241f6d60-0392-4225-61aa-706dfb62e194@redhat.com> References: <6d646175-68e2-b280-6475-cd97f2e5d438@redhat.com> <7003c233-d891-b11b-3426-f9b6f7de2d8f@redhat.com> <0bfedafb-f31c-6278-31da-56cb4abc1d34@redhat.com> <03cd4243-91e7-fb9f-5b5b-bbacf1de547d@redhat.com> <241f6d60-0392-4225-61aa-706dfb62e194@redhat.com> Message-ID: <79be4136-9e79-8552-a041-eb525f036dbf@redhat.com> On 9/11/19 10:04 PM, Andrew John Hughes wrote: > > > On 03/09/2019 13:24, Zhengyu Gu wrote: >> Hi Andrew >>>> >>>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8178870-8u/webrev.01/ >>>> >>>> Thanks, >>>> >>>> -Zhengyu >>>> >>>> >>>> >>>>> >>> >>> This seems to contain 3 bug IDs. Please post a clean webrev for 8178870 >>> once 8155951 is pushed. >> >> Yes. JDK-8155951 is prerequisite and its changeset contains two bug fixes. >> >> Updated: http://cr.openjdk.java.net/~zgu/JDK-8178870-8u/webrev.02/ >> >> Thanks, >> >> -Zhengyu >> >> >> >> >>> >>> Thanks, >>> > > This looks ok. I presume you intend to commit with the correct metadata, > as currently it says "imported patch JDK-8178870_coredump.patch"? Of course. Otherwise, it won't push. Thanks, -Zhengyu > > As this is one of the fixes we still intend to get into 8u232, please > flag the bug with jdk8u-critical-request and then push to > https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot when approved. > > For the record, the change to scratch_classes is part of a big cleanup > in https://bugs.openjdk.java.net/browse/JDK-8155672, which itself is > part of the PermGen removal, so not something that can be backported as > it stands. > > Thanks, > From abrygin at azul.com Thu Sep 12 13:32:39 2019 From: abrygin at azul.com (Andrew Brygin) Date: Thu, 12 Sep 2019 13:32:39 +0000 Subject: Backport proposal of the Marlin renderer in OpenJDK8 In-Reply-To: References: <7539DA05-ACC0-4BB2-8ED5-BC2F32F99ABE@azul.com> Message-ID: <4EBE26E4-7BFF-44E3-AF11-18466AE0B691@azul.com> Hello Laurent, thank you for your great work on the Marlin renderer. As you know we (Azul) have already integrated Marlin into Zulu 8, we are ready to help with the integration into OpenJDK 8. >> Finally I still wonder how to deal with the former classes (RenderingEngine >> conflict). How did you handle this aspect in the zulu codebase ? In Zulu8 we have updated the rendering engine selection in order to use Marlin by default. However, we have preserved the Pisces renderer just in case if somebody wants to use it, and uses sun.java2d.renderer property to specify Pisces explicitly. We have registered Marlin renderer as a service in src/share/classes/sun/java2d/pisces/META-INF/services/sun.java2d.pipe.RenderingEngine in order to make it available via ServiceLoader machinery. We will be happy to share our patches, as well as test and review the integration. Thanks, Andrew > On Sep 11, 2019, at 6:41 PM, Mario Torre wrote: > > I suggest to do what we are doing for JFR, which means the project > lead created a repository for us where we are merging individual bugs > (and adding new where necessary, like minor fixes only applicable to > 8u), with every commit accompanied by the relative bug id. Once > everything is done, you can propose the whole batch for integration. > We also mark individual bugs in Jira for the back port with a special > label, so they should be easier to track. > > As for who approves the patches, ideally you want to have a reviewer > working with you, but for the staging repository you don't strictly > need it since its purpose is obviously to get the patches back ported > and the assumption is that you are the original author so you know > best ;) > > Once everything is ready, a reviewer will go through the patches (or > the big patch) and approve it (or not!). > > Cheers, > Mario > > Il giorno mer 11 set 2019 alle ore 16:51 Laurent Bourg?s > ha scritto: >> >> Hi, >> >> I am wondering how to start with such big backport. >> - list all original patches among 9 to 14 repositories (=11u as I >> backported few changes already) >> - use my github fork of jdk8u_jdk or stay on mercurial but a new >> jdk8u_marlin forrest should be created ? >> - identify interested people (azul, adoptopenjdk, amazon) to build a tiger >> team to start the concrete work >> - who can sponsor (committer) / review these patches ? >> >> Finally I still wonder how to deal with the former classes (RenderingEngine >> conflict). How did you handle this aspect in the zulu codebase ? >> >> Laurent >> >> >> Le jeu. 8 ao?t 2019 ? 20:51, Andrew John Hughes a >> ?crit : >> >>> >>> >>> 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 >>> > > > > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens > Proud GNU Classpath developer: http://www.classpath.org/ > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ From gnu.andrew at redhat.com Thu Sep 12 16:43:05 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 12 Sep 2019 17:43:05 +0100 Subject: [8u] 8178870: instrumentation.retransformClasses cause coredump In-Reply-To: <79be4136-9e79-8552-a041-eb525f036dbf@redhat.com> References: <6d646175-68e2-b280-6475-cd97f2e5d438@redhat.com> <7003c233-d891-b11b-3426-f9b6f7de2d8f@redhat.com> <0bfedafb-f31c-6278-31da-56cb4abc1d34@redhat.com> <03cd4243-91e7-fb9f-5b5b-bbacf1de547d@redhat.com> <241f6d60-0392-4225-61aa-706dfb62e194@redhat.com> <79be4136-9e79-8552-a041-eb525f036dbf@redhat.com> Message-ID: <558f30e9-939d-ce1c-dda4-877857ce97e7@redhat.com> On 12/09/2019 13:28, Zhengyu Gu wrote: snip... >>>> >> >> This looks ok. I presume you intend to commit with the correct metadata, >> as currently it says "imported patch JDK-8178870_coredump.patch"? > > Of course. Otherwise, it won't push. > Running jcheck locally [0], I can't even commit something like that :) Just wanted to be sure. [0] https://openjdk.java.net/projects/code-tools/jcheck/ 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 bourges.laurent at gmail.com Thu Sep 12 19:54:59 2019 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 12 Sep 2019 21:54:59 +0200 Subject: Backport proposal of the Marlin renderer in OpenJDK8 In-Reply-To: <4EBE26E4-7BFF-44E3-AF11-18466AE0B691@azul.com> References: <7539DA05-ACC0-4BB2-8ED5-BC2F32F99ABE@azul.com> <4EBE26E4-7BFF-44E3-AF11-18466AE0B691@azul.com> Message-ID: Hi Andrew B (& other Andrew in this thread), I have an idea that could satisfy both approaches: - As the azul team backported already jdk9+ patches into their openjdk8 / zulu repository, it implies jdk8u patches are ready for integration and I already reviewed the code: zulu could be considered as both an incubator that proved Marlin works on jdk8 in production (as I did on my github). Two solutions: - extract & apply all zulu-ready patches in order in jdk8u-dev - extract one big patch (from zulu) and apply it on jdk8u-dev I do not see any reason to use another incubator repository... I can review all individual patches or the all-in-one and we are all done, up to the last patch backported in zulu 8 (version 0.9.1.1 merged in dec 2018 according to me). Moreover I already maintain a github branch for the Marlin / openjdk (8): https://github.com/bourgesl/marlin-renderer/tree/openjdk?files=1 It is my reference to easily compare with any jdk8 codebase. >From this first step, I will manage the missing patches to be up-to-date with latest jdk14 (v0.9.1.3 ie 2 patches) and future ones. What do you think ? This approach requires some work from zulu team to publish jdk8 patches that I will review and I need a jdk8u sponsor to endorse, follow & push the patch train or the all-in-one patch integration. Cheers, Laurent Le jeu. 12 sept. 2019 ? 15:32, Andrew Brygin a ?crit : > Hello Laurent, > > thank you for your great work on the Marlin renderer. > > As you know we (Azul) have already integrated Marlin into > Zulu 8, we are ready to help with the integration into OpenJDK 8. > > >> Finally I still wonder how to deal with the former classes > (RenderingEngine > >> conflict). How did you handle this aspect in the zulu codebase ? > > In Zulu8 we have updated the rendering engine selection in order to use > Marlin by default. However, we have preserved the Pisces renderer just > in case if somebody wants to use it, and uses sun.java2d.renderer property > to specify Pisces explicitly. > > We have registered Marlin renderer as a service in > > src/share/classes/sun/java2d/pisces/META-INF/services/sun.java2d.pipe.RenderingEngine > in order to make it available via ServiceLoader machinery. > > We will be happy to share our patches, as well as test and review the > integration. > > Thanks, > Andrew > > > On Sep 11, 2019, at 6:41 PM, Mario Torre > wrote: > > > > I suggest to do what we are doing for JFR, which means the project > > lead created a repository for us where we are merging individual bugs > > (and adding new where necessary, like minor fixes only applicable to > > 8u), with every commit accompanied by the relative bug id. Once > > everything is done, you can propose the whole batch for integration. > > We also mark individual bugs in Jira for the back port with a special > > label, so they should be easier to track. > > > > As for who approves the patches, ideally you want to have a reviewer > > working with you, but for the staging repository you don't strictly > > need it since its purpose is obviously to get the patches back ported > > and the assumption is that you are the original author so you know > > best ;) > > > > Once everything is ready, a reviewer will go through the patches (or > > the big patch) and approve it (or not!). > > > > Cheers, > > Mario > > > > Il giorno mer 11 set 2019 alle ore 16:51 Laurent Bourg?s > > ha scritto: > >> > >> Hi, > >> > >> I am wondering how to start with such big backport. > >> - list all original patches among 9 to 14 repositories (=11u as I > >> backported few changes already) > >> - use my github fork of jdk8u_jdk or stay on mercurial but a new > >> jdk8u_marlin forrest should be created ? > >> - identify interested people (azul, adoptopenjdk, amazon) to build a > tiger > >> team to start the concrete work > >> - who can sponsor (committer) / review these patches ? > >> > >> Finally I still wonder how to deal with the former classes > (RenderingEngine > >> conflict). How did you handle this aspect in the zulu codebase ? > >> > >> Laurent > >> > >> > >> Le jeu. 8 ao?t 2019 ? 20:51, Andrew John Hughes > a > >> ?crit : > >> > >>> > >>> > >>> 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 > >>> > > > > > > > > -- > > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > > > Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens > > Proud GNU Classpath developer: http://www.classpath.org/ > > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > > > Please, support open standards: > > http://endsoftpatents.org/ > > Le jeu. 12 sept. 2019 ? 15:32, Andrew Brygin a ?crit : > Hello Laurent, > > thank you for your great work on the Marlin renderer. > > As you know we (Azul) have already integrated Marlin into > Zulu 8, we are ready to help with the integration into OpenJDK 8. > > >> Finally I still wonder how to deal with the former classes > (RenderingEngine > >> conflict). How did you handle this aspect in the zulu codebase ? > > In Zulu8 we have updated the rendering engine selection in order to use > Marlin by default. However, we have preserved the Pisces renderer just > in case if somebody wants to use it, and uses sun.java2d.renderer property > to specify Pisces explicitly. > > We have registered Marlin renderer as a service in > > src/share/classes/sun/java2d/pisces/META-INF/services/sun.java2d.pipe.RenderingEngine > in order to make it available via ServiceLoader machinery. > > We will be happy to share our patches, as well as test and review the > integration. > > Thanks, > Andrew > > > On Sep 11, 2019, at 6:41 PM, Mario Torre > wrote: > > > > I suggest to do what we are doing for JFR, which means the project > > lead created a repository for us where we are merging individual bugs > > (and adding new where necessary, like minor fixes only applicable to > > 8u), with every commit accompanied by the relative bug id. Once > > everything is done, you can propose the whole batch for integration. > > We also mark individual bugs in Jira for the back port with a special > > label, so they should be easier to track. > > > > As for who approves the patches, ideally you want to have a reviewer > > working with you, but for the staging repository you don't strictly > > need it since its purpose is obviously to get the patches back ported > > and the assumption is that you are the original author so you know > > best ;) > > > > Once everything is ready, a reviewer will go through the patches (or > > the big patch) and approve it (or not!). > > > > Cheers, > > Mario > > > > Il giorno mer 11 set 2019 alle ore 16:51 Laurent Bourg?s > > ha scritto: > >> > >> Hi, > >> > >> I am wondering how to start with such big backport. > >> - list all original patches among 9 to 14 repositories (=11u as I > >> backported few changes already) > >> - use my github fork of jdk8u_jdk or stay on mercurial but a new > >> jdk8u_marlin forrest should be created ? > >> - identify interested people (azul, adoptopenjdk, amazon) to build a > tiger > >> team to start the concrete work > >> - who can sponsor (committer) / review these patches ? > >> > >> Finally I still wonder how to deal with the former classes > (RenderingEngine > >> conflict). How did you handle this aspect in the zulu codebase ? > >> > >> Laurent > >> > >> > >> Le jeu. 8 ao?t 2019 ? 20:51, Andrew John Hughes > a > >> ?crit : > >> > >>> > >>> > >>> 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 > >>> > > > > > > > > -- > > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > > > Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens > > Proud GNU Classpath developer: http://www.classpath.org/ > > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > > > Please, support open standards: > > http://endsoftpatents.org/ > > From gnu.andrew at redhat.com Thu Sep 12 21:33:31 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 12 Sep 2019 22:33:31 +0100 Subject: [8u] RFA 8010500: [parfait] Possible null pointer dereference at hotspot/src/share/vm/opto/loopnode.hpp In-Reply-To: References: Message-ID: On 10/09/2019 18:09, Aleksey Shipilev wrote: > Hi, > > I would like to request *approval* for this 8u backport: > https://hg.openjdk.java.net/jdk/jdk/rev/4d686766ac23 > > The issue itself is Confidential, and so our usual approval process does not work. The issue cannot > be opened, because it contains confidential information, alas. > > Patch applies cleanly to 8u, passes regular tier1 testing. It is required to fix fuzzer test failure > caught by JDK-8230238: that test would SEGV exactly where the warning told us. I would push > JDK-8230238 right after this fix. > Fine by 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 andrew_m_leonard at uk.ibm.com Fri Sep 13 08:14:33 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Fri, 13 Sep 2019 09:14:33 +0100 Subject: Bump: Re: [8u] RFR Backport of 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target Message-ID: Hi, Maintainers for jdk8u, please can I request backport approval (jdk8u-fix-yes) for this bug in https://bugs.openjdk.java.net/browse/JDK-8067429 The backport patch has been reviewed by Vincente and Aleksey here: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010061.html https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010075.html 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 aph at redhat.com Fri Sep 13 08:24:30 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 13 Sep 2019 09:24:30 +0100 Subject: Bump: Re: [8u] RFR Backport of 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target In-Reply-To: References: Message-ID: <71cfc552-e6eb-0acf-24f1-41c282448433@redhat.com> On 9/13/19 9:14 AM, Andrew Leonard wrote: > please can I request backport approval (jdk8u-fix-yes) for this bug in > https://bugs.openjdk.java.net/browse/JDK-8067429 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 Fri Sep 13 08:26:24 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 13 Sep 2019 09:26:24 +0100 Subject: [8u] RFA 8010500: [parfait] Possible null pointer dereference at hotspot/src/share/vm/opto/loopnode.hpp In-Reply-To: References: Message-ID: <11ad6c72-5ce1-b777-2547-ac8dbbb0b3c9@redhat.com> On 9/10/19 6:09 PM, Aleksey Shipilev wrote: > I would like to request *approval* for this 8u backport: > https://hg.openjdk.java.net/jdk/jdk/rev/4d686766ac23 > > The issue itself is Confidential, and so our usual approval process does not work. The issue cannot > be opened, because it contains confidential information, alas. Perhaps we should consider creating public clones of confidential bugs. Of course we wouldn't be able to link the original bug to our clone. -- 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 jaroslav.bachorik at datadoghq.com Fri Sep 13 11:56:31 2019 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Fri, 13 Sep 2019 13:56:31 +0200 Subject: [8u] [JFR] RFR 8230947: TestLookForUntestedEvents.java is failing after JDK-8230707 Message-ID: Please, review this simple test update after JDK-8230707 JIRA: https://bugs.openjdk.java.net/browse/JDK-8230947 Webrev: http://cr.openjdk.java.net/~jbachorik/8230947/webrev/ Cheers, -JB- From stooke at redhat.com Fri Sep 13 14:05:14 2019 From: stooke at redhat.com (Simon Tooke) Date: Fri, 13 Sep 2019 10:05:14 -0400 Subject: [8u] RFR 8226288 - Upgrade to XCode 10+ for building JDK 8u and 11u Message-ID: <16e90c95-20dc-e784-32fe-1b8341498c08@redhat.com> Hello all, This is a request for review of my patch to enable building 8u with modern (9,10,11) Xcode versions on macOS.? I've received a few recent enquiries so I thought I'd submit this. When I first created this patch is was more for convenience, but soon macOS will require applications to be "notarized", which cannot be done with the old version of Xcode.? This will become mandatory long before 8u is due to retire [1]. This patch is not intended to remove the current ability to build 8u on the current supported build platform. I have used the patch with Xcode 9,10 and a beta of 11, and used the resultant JDK to build Graal.? I have not build a JDK using the old Xcode and this patch; my intent was to ensure this was still possible. There is some information available on my GitHub page: https://github.com/stooke/jdk8u-xcode10 Issue: https://bugs.openjdk.java.net/browse/JDK-8226288 Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8226288-jdk8u/00/ Previous discussion:? https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-June/009733.html? https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-July/009760.html Thank you for your time, -Simon [1] https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution From andrew_m_leonard at uk.ibm.com Fri Sep 13 17:09:42 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Fri, 13 Sep 2019 18:09:42 +0100 Subject: [8u] Request for approved backport push: 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target 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-8067429 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 new testcase passes. Updated webrev for jdk8u: http://cr.openjdk.java.net/~aleonard/8067429/webrev.00 RFR reviews: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010061.html https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010075.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 sgehwolf at redhat.com Fri Sep 13 18:14:44 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 13 Sep 2019 20:14:44 +0200 Subject: [8u] Request for approved backport push: 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target In-Reply-To: References: Message-ID: Hi Andrew, On Fri, 2019-09-13 at 18:09 +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-8067429 > > 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 new testcase passes. > Updated webrev for jdk8u: > http://cr.openjdk.java.net/~aleonard/8067429/webrev.00 > > RFR reviews: > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010061.html > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010075.html Please send me an HG exported patch which passes jcheck with proper reviewer attribution and I'll push it for you. Thanks, Severin From martijnverburg at gmail.com Sat Sep 14 18:02:04 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Sat, 14 Sep 2019 11:02:04 -0700 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> <0AD1FBFB-F7BE-4F57-B9CF-868ABAC308A7@azul.com> Message-ID: Hi all, As an update we're finally getting JFR Linux builds out of Adopt - I'll update during OC1 with a download location for the nightly builds. If other platforms are desired please let me know, it's fairly easy to start expanding from here on in... Cheers, Martijn On Mon, 12 Aug 2019 at 08:56, Mario Torre wrote: > 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 jaroslav.bachorik at datadoghq.com Mon Sep 16 09:53:21 2019 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Mon, 16 Sep 2019 11:53:21 +0200 Subject: [8u] [JFR] RFR: JFR backports from 11.0.4 In-Reply-To: References: <72db089a-fb9f-e088-8fcd-8a6e25bec29b@redhat.com> <4DE97FAF-FB3A-41C5-BCC2-1BE799E9AA6C@azul.com> <0FE4C1EB-FCD3-435B-A944-9786BB1EC7C9@azul.com> <961B2FE0-A663-4912-9E78-434F1D03B5F8@azul.com> Message-ID: On Wed, Sep 11, 2019 at 12:20 PM Jaroslav Bachor?k < jaroslav.bachorik at datadoghq.com> wrote: > Hi all, > > we are planning to port also the following patches > https://bugs.openjdk.java.net/browse/JDK-8210158 (already in 11u) > This one turned out to be not applicable to jdk8u > https://bugs.openjdk.java.net/browse/JDK-8225797 (being worked on in dev, > will be backported to 11u adn jdk8u once done) > This fix has been merged to dev and I started working on the backport to 11u. So far it seems that the backport will be far from simple as it touches many places which are fundamentally different in dev, 11u and 8u :/ -JB- > > Cheers, > > -JB- > > > On Tue, Sep 10, 2019 at 2:53 PM Andrey Petushkov wrote: > >> Hi Denghui, >> >> Thank you. We'll take care of it then. >> The list of backports we're currently working on (for jdk8u incubator) >> was part of initial email. For convenience please find it below: >> >> https://bugs.openjdk.java.net/browse/JDK-8185525: Add JFR event for >> DictionarySizes >> https://bugs.openjdk.java.net/browse/JDK-8213448: [TESTBUG] enhance >> jfr/jvm/TestDumpOnCrash >> https://bugs.openjdk.java.net/browse/JDK-8215727: Restore JFR thread >> sampler loop to old / previous behavior >> https://bugs.openjdk.java.net/browse/JDK-8216283: Allow shorter method >> sampling interval than 10 ms >> https://bugs.openjdk.java.net/browse/JDK-8217362: Emergency dump does >> not work when disk=false is set >> https://bugs.openjdk.java.net/browse/JDK-8219241: Provide basic >> virtualization related info in the hs_error file on linux/windows x86_64 >> https://bugs.openjdk.java.net/browse/JDK-8219566: JFR did not collect >> call stacks when MaxJavaStackTraceDepth is set to zero >> https://bugs.openjdk.java.net/browse/JDK-8219997: [TESTBUG] Create test >> for JFR events in Docker container: CPU, Memory and Process Info >> https://bugs.openjdk.java.net/browse/JDK-8220293: Deadlock in JFR string >> pool >> https://bugs.openjdk.java.net/browse/JDK-8220555: JFR tool shows >> potentially misleading message when it cannot access a file >> https://bugs.openjdk.java.net/browse/JDK-8220657: JFR.dump does not work >> when filename is set >> https://bugs.openjdk.java.net/browse/JDK-8221569: JFR tool produces >> incorrect output when both --categories and --events are specified >> https://bugs.openjdk.java.net/browse/JDK-8221711: [TESTBUG] create more >> tests for JFR in container environment >> https://bugs.openjdk.java.net/browse/JDK-8222888: [TESTBUG] >> docker/TestJFREvents.java fails due to "RuntimeException: JAVA_MAIN_CLASS_ >> is not defined" >> https://bugs.openjdk.java.net/browse/JDK-8223438: add >> VirtualizationInformation JFR event >> https://bugs.openjdk.java.net/browse/JDK-8223599: minimal build fails >> after JDK-8185525 >> https://bugs.openjdk.java.net/browse/JDK-8224217: RecordingInfo should >> use textual representation of path >> https://bugs.openjdk.java.net/browse/JDK-8225310: JFR crashed in >> JfrPeriodicEventSet::requestProtectionDomainCacheTableStatistics() >> >> from these there are number of issues which are not yet ported to jdk11u. >> We're on it, >> some of them have been pushed to jdk11u today. The rest are: >> >> https://bugs.openjdk.java.net/browse/JDK-8185525: Add JFR event for >> DictionarySizes >> https://bugs.openjdk.java.net/browse/JDK-8223599: minimal build fails >> after JDK-8185525 >> https://bugs.openjdk.java.net/browse/JDK-8225310: JFR crashed in >> JfrPeriodicEventSet::requestProtectionDomainCacheTableStatistics() >> https://bugs.openjdk.java.net/browse/JDK-8217362: Emergency dump does >> not work when disk=false is set >> https://bugs.openjdk.java.net/browse/JDK-8224217: RecordingInfo should >> use textual representation of path >> >> we'll working on preparing review requests for those into jdk11u >> >> Best Regards, >> Andrey >> >> > On 10 Sep 2019, at 08:04, DDH wrote: >> > >> > Hi Andrey, >> > >> > Since you have already processed on 8223438([Enhancement] add >> VirtualizationInformation JFR event), >> > we think that we don't need to do this issue again, we will remove it >> from our list. >> > By the way, can you send us a complete list that you will backport? >> We can double check there are any repeated issues. >> > >> > Thanks, >> > DDH >> > ------------------------------------------------------------------ >> > From:Andrey Petushkov >> > Send Time:2019?9?9?(???) 20:59 >> > To:Mario Torre ; ???(??) < >> denghui.ddh at alibaba-inc.com> >> > Cc:jdk8u-dev ; Ekaterina Vergizova < >> katya at azul.com> >> > Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 >> > >> > Hi Denghui, >> > >> > Just a note, from the list below one backport (8223438: [Enhancement] >> add VirtualizationInformation JFR event) >> > is already proposed for integration as part of Azul's effort ([1]). >> > However since it's not yet integrated into jdk11u there still work to >> be done. We can do it, but if you'd like >> > and if you feel it's more convenient, you can take over. Anyway you >> might want to check implementation of >> > the backport in the respective webrev ([2]). Please let us know, thanks >> > >> > Regards, >> > Andrey >> > >> > [1] >> http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-September/010204.html >> > [2] http://cr.openjdk.java.net/~apetushkov/jfr_backports_katya/11.0.4/ >> > >> > On 9 Sep 2019, at 12:37, Mario Torre wrote: >> > >> > Hi Denghui, >> > >> > Yes, the list looks good to me. As you mentioned, we should try first >> > the 11u backports and then backport to 8u. >> > >> > The process for the backport is highlighted here: >> > >> https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix >> > >> > Cheers, >> > Mario >> > >> > On Mon, Sep 9, 2019 at 4:07 AM DDH wrote: >> > >> > hi all, >> > We(Alibaba) picked some jfr backports as follows from JBS >> > ( >> https://bugs.openjdk.java.net/browse/JDK-8230624?jql=Subcomponent%20%3D%20jfr%20and%20resolution%20%3D%20Fixed%20and%20fixVersion%20%3E%2011.0.6%20and%20type%20!%3D%20Backport), >> we >> > think it is worth porting them to 8u/11u. >> > We plan to backport them to 11u at first, and then to 8u, what's your >> comment? >> > If you think it is reasonable, we can provide our webrev of some >> issues as soon as possible, and continue work on other issues. >> > >> > 8223396: [TESTBUG] several jfr tests do not clean up files created in >> /tmp >> > 8225004: Remove invalid assertion in jfr_conditional_flush() >> > 8214542: [BUG] JFR: Old Object Sample event slow on a deep heap in >> debug builds (Unresolved) >> > 8228834: [BUG] Regression caused by JDK-8214542 not installing complete >> checkpoint data to candidates >> > 8228359: [TESTBUG] >> jdk.jfr.e.g.c.TestGCHeapConfigurationEventWith32BitOops.java does not >> expect MinHeapSize to be aligned to HeapAlignment >> > 8227605: [BUG] Kitchensink fails "assert((((klass)->trace_id() & >> (JfrTraceIdEpoch::leakp_in_use_this_epoch_bit())) != 0)) failed: invariant" >> > 8227411: [BUG] TestTimeMultiple.java failed "assert(!lease()) failed: >> invariant" >> > 8224172: [BUG] assert(jfr_is_event_enabled(id)) failed: invariant >> > 8212663: [BUG] Remove conservative at_safepoint assert when JFR writes >> type sets during class unloading >> > 8216064: [BUG] -XX:StartFlightRecording:settings= doesn't work properly >> > 8214750: [BUG] Unnecessary

tags in jfr classes >> > 8213570: [TESTBUG] Update JFR sanity test set >> > 8226779: [TESTBUG] Test JFR API from Java agent >> > 8229189: [Enhancement] Improve JFR leak profiler tracing to deal with >> discontiguous heaps >> > 8223438: [Enhancement] add VirtualizationInformation JFR event >> > >> > ------------------------------------------------------------------ >> > From:Andrey Petushkov >> > Send Time:2019?9?5?(???) 23:55 >> > To:Mario Torre >> > Cc:jdk8u-dev at openjdk.java.net >> > Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 >> > >> > Hi Mario, >> > >> > The following fixes apply trivially to jdk11u, so I've requested the >> permission to backport per process. >> > >> > https://bugs.openjdk.java.net/browse/JDK-8220555 >> > https://bugs.openjdk.java.net/browse/JDK-8221711 >> > https://bugs.openjdk.java.net/browse/JDK-8222888 >> > https://bugs.openjdk.java.net/browse/JDK-8221569 >> > https://bugs.openjdk.java.net/browse/JDK-8216283 >> > >> > The rest require some rework, I'll post RFRs soon >> > >> > Thanks, >> > Andrey >> > >> > On 4 Sep 2019, at 17:47, Mario Torre wrote: >> > >> > Awesome, thanks for checking zero. >> > >> > As discussed offline, we have a few backports that were directly >> > backported to 8u without first being in 11u: >> > >> > https://bugs.openjdk.java.net/browse/JDK-8185525 >> > https://bugs.openjdk.java.net/browse/JDK-8223599 >> > https://bugs.openjdk.java.net/browse/JDK-8225310 >> > https://bugs.openjdk.java.net/browse/JDK-8221711 >> > https://bugs.openjdk.java.net/browse/JDK-8222888 >> > https://bugs.openjdk.java.net/browse/JDK-8216283 >> > https://bugs.openjdk.java.net/browse/JDK-8220555 >> > https://bugs.openjdk.java.net/browse/JDK-8217362 >> > https://bugs.openjdk.java.net/browse/JDK-8221569 >> > https://bugs.openjdk.java.net/browse/JDK-8224217 >> > >> > A couple of those are wither being worked on or of interest for 11u, >> > so they should be fine, some aren't and while may not be critical I >> > think they are nice to have (like the container tests), so I would >> > expect all of them to be backported to 11u. >> > >> > Since this is a staging repository we may go ahead and push them and >> > work on the backport to 11 afterward, but I would prefer to not create >> > a discrepancy at this moment, so if possible we should work on the >> > backports to 11 first. >> > >> > Cheers, >> > Mario >> > >> > >> > On Wed, Sep 4, 2019 at 4:09 PM Andrey Petushkov >> wrote: >> > >> > Hi Mario, >> > >> > zero build is fine (e.g. mentioned method has default no-op >> implementation in vm_version.hpp) >> > >> > Andrey >> > >> > On 4 Sep 2019, at 12:52, Mario Torre wrote: >> > >> > On 03/09/2019 13:53, Andrey Petushkov wrote: >> > Dear All, >> > >> > could you please consider the following set of backports of the JFR >> fixes from 11.0.4 release into 8u incubator baseline: >> > >> > This seems good, the only nit I have now is that some of those changes >> > may break zero again, I think it may make sense to fix it in this patch >> > set instead of filing a dedicated bug report later. >> > >> > See for example: >> > >> > JDK-8219241 >> > >> > +void VM_Version::print_platform_virtualization_info(outputStream* st) { >> > >> > etc.. >> > >> > 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 >> > >> > >> > >> > -- >> > 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 Sep 16 10:31:57 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 16 Sep 2019 12:31:57 +0200 Subject: [8u] RFA 8010500: [parfait] Possible null pointer dereference at hotspot/src/share/vm/opto/loopnode.hpp In-Reply-To: References: Message-ID: <0900c668-fe5e-9ca8-7843-cf1145419452@redhat.com> On 9/12/19 11:33 PM, Andrew John Hughes wrote: > On 10/09/2019 18:09, Aleksey Shipilev wrote: >> I would like to request *approval* for this 8u backport: >> https://hg.openjdk.java.net/jdk/jdk/rev/4d686766ac23 >> >> The issue itself is Confidential, and so our usual approval process does not work. The issue cannot >> be opened, because it contains confidential information, alas. >> >> Patch applies cleanly to 8u, passes regular tier1 testing. It is required to fix fuzzer test failure >> caught by JDK-8230238: that test would SEGV exactly where the warning told us. I would push >> JDK-8230238 right after this fix. >> > > Fine by me. Thanks, pushed. -- -Aleksey From shade at redhat.com Mon Sep 16 10:42:32 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 16 Sep 2019 12:42:32 +0200 Subject: [8u] RFA 8010500: [parfait] Possible null pointer dereference at hotspot/src/share/vm/opto/loopnode.hpp In-Reply-To: <11ad6c72-5ce1-b777-2547-ac8dbbb0b3c9@redhat.com> References: <11ad6c72-5ce1-b777-2547-ac8dbbb0b3c9@redhat.com> Message-ID: <623a9389-d14f-1e90-ab00-4ed837e8d7f0@redhat.com> On 9/13/19 10:26 AM, Andrew Haley wrote: > On 9/10/19 6:09 PM, Aleksey Shipilev wrote: >> I would like to request *approval* for this 8u backport: >> https://hg.openjdk.java.net/jdk/jdk/rev/4d686766ac23 >> >> The issue itself is Confidential, and so our usual approval process does not work. The issue cannot >> be opened, because it contains confidential information, alas. > > Perhaps we should consider creating public clones of confidential bugs. > Of course we wouldn't be able to link the original bug to our clone. Not sure about that. The changesets are clearly visible, and we have to keep them searchable. Separate bug IDs would make it harder. I think these cases are exceptional enough for us not to care. It usually possible to ask Oracle folks to open the issue for our usual processes to work. -- Thanks, -Aleksey From shade at redhat.com Mon Sep 16 11:40:12 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 16 Sep 2019 13:40:12 +0200 Subject: [8u] RFR 8225425: java.lang.UnsatisfiedLinkError: net.dll: Can't find dependent libraries In-Reply-To: References: Message-ID: <6797b384-3603-6cc7-00aa-6ce1ba047870@redhat.com> On 9/12/19 4:55 AM, Andrew John Hughes wrote: > On 10/09/2019 19:47, Aleksey Shipilev wrote: >> *) test/lib/jdk/test/lib/net/URIBuilder.java put into location that fits 8u. > > The right location would seem to be > jdk/test/lib/testlibrary/jdk/testlibrary/net as > jdk/test/lib/testlibrary/jdk/testlibrary/ houses JDKToolLauncher.java, > which is in test/lib/jdk/test/lib/ in trunk. Right. testlibrary is a mess. Moved to: test/lib/testlibrary/jdk/testlibrary/net/URIBuilder.java > Why is this being backported as part of this and not a backport of > https://bugs.openjdk.java.net/browse/JDK-8220575 which would also mean > we get the advantages of introducing this helper class in other tests? Because this is a critical bugfix, and we don't want to pull in more that necessary. It also matches what was done in 11u. >> Read the InputStream without readAllBytes method (added in 9): >> 85 InputStream is = uc.getInputStream(); >> 86 byte[] buf = new byte[1024]; >> 87 while (is.read(buf) != -1) {}; > > This conversion loses the output of the read data. Something closer to > the original would be along the lines of: > > InputStream is = uc.getInputStream(); > BufferedReader r = new BufferedReader(new InputStreamReader(is, UTF_8); > String body = r.readLine(); > out.print("received body: " + body); > while (body != null) { body = r.readLine(); out.print(body); } Well, this part of the test is not critical, and its job is to drain the InputStream first and foremost. But okay, we can also print it. The code above would print "null" at the end, though, so we need to make a proper post-condition loop. See new patch: InputStream is = uc.getInputStream(); BufferedReader r = new BufferedReader(new InputStreamReader(is, UTF_8)); String body = r.readLine(); out.print("received body: "); do { out.print(body); body = r.readLine(); } while (body != null); Updated 8u webrev: https://cr.openjdk.java.net/~shade/8225425/webrev.8u.02/ Still passes new test. Haven't retested anything else, because all changes were related to test code only. -- Thanks, -Aleksey From andrew_m_leonard at uk.ibm.com Mon Sep 16 14:04:04 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Mon, 16 Sep 2019 15:04:04 +0100 Subject: [8u] Request for approved backport push: 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target In-Reply-To: References: Message-ID: Thanks Severin, I've uploaded a jchecked'd exported hg patch here, built and tested with latest jdk8u: http://cr.openjdk.java.net/~aleonard/8067429/8067429.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 Date: 13/09/2019 19:14 Subject: Re: [8u] Request for approved backport push: 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target Hi Andrew, On Fri, 2019-09-13 at 18:09 +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=BTzLYAvgTwaDCA4uldJOVsGjIVKkDV92bvnwCs78W1I&s=yE0Bzcuu5iE_O1cQQcSUZtq_my66Nh3cMARfLUgQxbo&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-2D8067429&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=BTzLYAvgTwaDCA4uldJOVsGjIVKkDV92bvnwCs78W1I&s=BeZ21PKnm6aTcqBKT8NvGovpUyqFLNesLASihOsvPmc&e= > > 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 new testcase passes. > Updated webrev for jdk8u: > 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=BTzLYAvgTwaDCA4uldJOVsGjIVKkDV92bvnwCs78W1I&s=M5UAsPisyc5yzGulWwv89cF3awxeG8I-f_lDSxFmPOs&e= > > RFR reviews: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openjdk.java.net_pipermail_jdk8u-2Ddev_2019-2DAugust_010061.html&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=BTzLYAvgTwaDCA4uldJOVsGjIVKkDV92bvnwCs78W1I&s=qVTfu8M0xJ28FpAfseSt7n_t8VF1H1gLHVRCEEKxF6M&e= > > https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openjdk.java.net_pipermail_jdk8u-2Ddev_2019-2DAugust_010075.html&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=BTzLYAvgTwaDCA4uldJOVsGjIVKkDV92bvnwCs78W1I&s=V3Qc7C1gTaS5FJsqTfMd93Q-hLCxQW6MVOP9mzxvAno&e= Please send me an HG exported patch which passes jcheck with proper reviewer attribution and I'll push it for you. Thanks, Severin 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 Mon Sep 16 14:04:36 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 16 Sep 2019 15:04:36 +0100 Subject: [8u] RFR Backport of 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target In-Reply-To: References: Message-ID: <640ea4da-2592-8412-7f75-97189ff68fae@redhat.com> On 12/08/2019 17:15, Andrew Leonard wrote: > 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 > This is a clean backport (once paths are fixed using the jdk9/common/bin/unshuffle_patch.sh script) so there is no need for review, only approval. I've pushed the original version of this fix, without the unnecessary copyright changes that seem to be in your webrev: https://hg.openjdk.java.net/jdk8u/jdk8u-dev/langtools/rev/f02d967ddce2 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 Mon Sep 16 14:12:52 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Mon, 16 Sep 2019 15:12:52 +0100 Subject: [8u] RFR Backport of 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target In-Reply-To: <640ea4da-2592-8412-7f75-97189ff68fae@redhat.com> References: <640ea4da-2592-8412-7f75-97189ff68fae@redhat.com> Message-ID: Thanks Andrew, I'll try unshuffle_patch next time, that sounds useful, would have saved me time! Cheers 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: 16/09/2019 15:06 Subject: Re: [8u] RFR Backport of 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target On 12/08/2019 17:15, Andrew Leonard wrote: > 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=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=DQLrWqQFPORmCxvDo8h106uWUooNVYZ_Fo19Ilr4xj0&s=QEg9D0wG_S6KQwQLdlw-Khs2AEwuHsps5TCqmEz1k-I&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 > This is a clean backport (once paths are fixed using the jdk9/common/bin/unshuffle_patch.sh script) so there is no need for review, only approval. I've pushed the original version of this fix, without the unnecessary copyright changes that seem to be in your webrev: https://urldefense.proofpoint.com/v2/url?u=https-3A__hg.openjdk.java.net_jdk8u_jdk8u-2Ddev_langtools_rev_f02d967ddce2&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=DQLrWqQFPORmCxvDo8h106uWUooNVYZ_Fo19Ilr4xj0&s=H00jdHCuHkeTcoxKzYqFLixgh9sugWpgC0jN0lBvl_s&e= Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. ( https://urldefense.proofpoint.com/v2/url?u=http-3A__www.redhat.com&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=DQLrWqQFPORmCxvDo8h106uWUooNVYZ_Fo19Ilr4xj0&s=4tqi9529StPHiytZmw4obcA8v0-WmPnEdZloGSjgRs0&e= ) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://urldefense.proofpoint.com/v2/url?u=https-3A__keybase.io_gnu-5Fandrew&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=DQLrWqQFPORmCxvDo8h106uWUooNVYZ_Fo19Ilr4xj0&s=WfyHottZ9FUhRo0Hmp55lnf465M4zs01QiIzFDn4z3c&e= Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From sgehwolf at redhat.com Mon Sep 16 14:14:11 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 16 Sep 2019 16:14:11 +0200 Subject: [8u] Request for approved backport push: 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target In-Reply-To: References: Message-ID: <9f943112b2d48ada895321b7b71494ab3ab19944.camel@redhat.com> Hi Andrew, On Mon, 2019-09-16 at 15:04 +0100, Andrew Leonard wrote: > Thanks Severin, > I've uploaded a jchecked'd exported hg patch here, built and tested > with latest jdk8u: > http://cr.openjdk.java.net/~aleonard/8067429/8067429.patch > Many thanks Hmm, looks like Andrew Hughes pushed 8067429 already: https://bugs.openjdk.java.net/browse/JDK-8231063 Sorry about that. I wasn't aware that he was doing it. Something seems to have been communicated badly one way or another. Thanks, Severin > > > > From: Severin Gehwolf > To: Andrew Leonard , jdk8u-dev < > jdk8u-dev at openjdk.java.net> > Date: 13/09/2019 19:14 > Subject: Re: [8u] Request for approved backport push: 8067429: > java.lang.VerifyError: Inconsistent stackmap frames at branch target > > > > Hi Andrew, > > On Fri, 2019-09-13 at 18:09 +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-8067429 > > > > 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 new testcase passes. > > Updated webrev for jdk8u: > > http://cr.openjdk.java.net/~aleonard/8067429/webrev.00 > > > > RFR reviews: > > > > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010061.html > > > > > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010075.html > > > Please send me an HG exported patch which passes jcheck with proper > reviewer attribution and I'll push it for you. > > Thanks, > Severin > > > > > > 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 Sep 16 14:18:05 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Mon, 16 Sep 2019 15:18:05 +0100 Subject: [8u] RFR Backport of 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target In-Reply-To: <640ea4da-2592-8412-7f75-97189ff68fae@redhat.com> References: <640ea4da-2592-8412-7f75-97189ff68fae@redhat.com> Message-ID: fyi, I couldn't find an obvious How to contribute doc for jdk8u, so I was following the jdk11u one here inserting jdk8u...: https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix I infered from this since I had to modify the patch to backport to jdk8 from jdk9, even though it's just path changes, I needed a review... 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: 16/09/2019 15:06 Subject: Re: [8u] RFR Backport of 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target On 12/08/2019 17:15, Andrew Leonard wrote: > 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=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=DQLrWqQFPORmCxvDo8h106uWUooNVYZ_Fo19Ilr4xj0&s=QEg9D0wG_S6KQwQLdlw-Khs2AEwuHsps5TCqmEz1k-I&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 > This is a clean backport (once paths are fixed using the jdk9/common/bin/unshuffle_patch.sh script) so there is no need for review, only approval. I've pushed the original version of this fix, without the unnecessary copyright changes that seem to be in your webrev: https://urldefense.proofpoint.com/v2/url?u=https-3A__hg.openjdk.java.net_jdk8u_jdk8u-2Ddev_langtools_rev_f02d967ddce2&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=DQLrWqQFPORmCxvDo8h106uWUooNVYZ_Fo19Ilr4xj0&s=H00jdHCuHkeTcoxKzYqFLixgh9sugWpgC0jN0lBvl_s&e= Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. ( https://urldefense.proofpoint.com/v2/url?u=http-3A__www.redhat.com&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=DQLrWqQFPORmCxvDo8h106uWUooNVYZ_Fo19Ilr4xj0&s=4tqi9529StPHiytZmw4obcA8v0-WmPnEdZloGSjgRs0&e= ) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://urldefense.proofpoint.com/v2/url?u=https-3A__keybase.io_gnu-5Fandrew&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=DQLrWqQFPORmCxvDo8h106uWUooNVYZ_Fo19Ilr4xj0&s=WfyHottZ9FUhRo0Hmp55lnf465M4zs01QiIzFDn4z3c&e= Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From gnu.andrew at redhat.com Mon Sep 16 14:26:34 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 16 Sep 2019 15:26:34 +0100 Subject: [8u] RFR Backport of 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target In-Reply-To: References: <640ea4da-2592-8412-7f75-97189ff68fae@redhat.com> Message-ID: <08279a86-1db7-c51d-65a0-0ed5843dbe56@redhat.com> On 16/09/2019 15:12, Andrew Leonard wrote: > Thanks Andrew, > I'll try unshuffle_patch next time, that sounds useful, would have saved > me time! > Cheers > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > It doesn't always work, as the paths may not match the database it uses, but it's usually worth a try. If the patch is from a later version, you may need to run it through multiple versions of the script from different repos. For the most common case of going from 11u to 8u (the two active update versions), I usually have to run the 11u unshuffle script (jdk11/bin/unshuffle_patch.sh) to move things back into the multi-repo structure of 9 and earlier, and then the 9 one way to use the old paths to the source files, prior to modularisation. It's a pain, but my main point was that, if path changes are enough to make hg import cleanly apply the patch on 8u, you don't need to ask for a review, just approval of the shuffled patch :) Hope that helps, -- 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 Sep 16 14:29:48 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 16 Sep 2019 15:29:48 +0100 Subject: [8u] RFR Backport of 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target In-Reply-To: References: <640ea4da-2592-8412-7f75-97189ff68fae@redhat.com> Message-ID: <981e476f-7444-8daa-abeb-a60c8dbdb85c@redhat.com> On 16/09/2019 15:18, Andrew Leonard wrote: > fyi, > I couldn't find an obvious How to contribute doc for jdk8u, so I was > following the jdk11u one here inserting jdk8u...: > https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix > I infered from this since I had to modify the patch to backport to jdk8 > from jdk9, even though it's just path changes, I needed a review... > Thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > The 8u project is separate to jdk-updates, for legacy reasons. The wiki is: https://wiki.openjdk.java.net/display/jdk8u/Main If there's anything unclear on there, or you have any suggestions, please let me know and we'll try and make it better. When you're used to doing something, it's hard to look at it from the perspective of a newcomer. 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 Sep 16 17:12:31 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 16 Sep 2019 18:12:31 +0100 Subject: [8u] RFA 8010500: [parfait] Possible null pointer dereference at hotspot/src/share/vm/opto/loopnode.hpp In-Reply-To: <11ad6c72-5ce1-b777-2547-ac8dbbb0b3c9@redhat.com> References: <11ad6c72-5ce1-b777-2547-ac8dbbb0b3c9@redhat.com> Message-ID: <2e9243f5-28ef-5792-1ee0-4fd5683c53fb@redhat.com> On 13/09/2019 09:26, Andrew Haley wrote: > On 9/10/19 6:09 PM, Aleksey Shipilev wrote: >> I would like to request *approval* for this 8u backport: >> https://hg.openjdk.java.net/jdk/jdk/rev/4d686766ac23 >> >> The issue itself is Confidential, and so our usual approval process does not work. The issue cannot >> be opened, because it contains confidential information, alas. > > Perhaps we should consider creating public clones of confidential bugs. > Of course we wouldn't be able to link the original bug to our clone. > I don't see how we could "clone" a bug we can't access. We could create a replacement, but then, as Aleksey suggests, we'd have the same thing under different bug IDs in different repositories. I think it would be better to push Oracle to open up bugs where possible. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From zgu at redhat.com Mon Sep 16 18:04:43 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 16 Sep 2019 14:04:43 -0400 Subject: [8u] RFR: 8196681: Java Access Bridge logging and debug flags dynamically controlled In-Reply-To: References: Message-ID: <257397da-ae0c-a0e0-f20f-c3f2094d6c48@redhat.com> Hi Alex, On 9/9/19 12:29 PM, Alex Kashchenko wrote: > Hi, > > Please review the code change required to backport JDK-8196681 to 8u. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196681 > > Original review thread: > http://mail.openjdk.java.net/pipermail/awt-dev/2018-September/014302.html > > 11u changeset: > https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/af9ad0ae9039 > > Patch does not apply cleanly, because std::chrono is used for > timestamps. And this part of C++11 standard is not supported by VS2010 > toolchain that is used for 8u windows builds. The following change > reimplements the same timestamps without std::chrono: > > > ?auto getTimeStamp() -> long long { > -??? using namespace std::chrono; > -??? auto timeNow = > duration_cast(steady_clock::now().time_since_epoch()); > - > -??? return timeNow.count(); > +??? LARGE_INTEGER freqLarge; > +??? ::QueryPerformanceFrequency(&freqLarge); > +??? long long freq = freqLarge.QuadPart; > +??? LARGE_INTEGER counterLarge; > +??? ::QueryPerformanceCounter(&counterLarge); > +??? long long counter = counterLarge.QuadPart; > +??? long long milliDen = 1000; > +??? long long whole = (counter / freq) * milliDen; > +??? long long part = (counter % freq) * milliDen / freq; > +??? return whole + part; > ?} > Would this whole + part calculation just (counter * milliDen) / freq? or you are worry about overflow? Otherwise, looks good to me. Thanks, -Zhengyu > > Backport also depends on JDK-8077707 and JDK-8132249 (both apply > cleanly), "jdk8u-fix-request" label was added for them. > > Backport requires CSR that was filed in JDK-8230699. > > Thanks! > From akashche at redhat.com Tue Sep 17 09:41:13 2019 From: akashche at redhat.com (Alex Kashchenko) Date: Tue, 17 Sep 2019 10:41:13 +0100 Subject: [8u] RFR: 8196681: Java Access Bridge logging and debug flags dynamically controlled In-Reply-To: <257397da-ae0c-a0e0-f20f-c3f2094d6c48@redhat.com> References: <257397da-ae0c-a0e0-f20f-c3f2094d6c48@redhat.com> Message-ID: Hi Zhengyu, On 09/16/2019 07:04 PM, Zhengyu Gu wrote: > Hi Alex, > > On 9/9/19 12:29 PM, Alex Kashchenko wrote: >> Hi, >> >> Please review the code change required to backport JDK-8196681 to 8u. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8196681 >> >> Original review thread: >> http://mail.openjdk.java.net/pipermail/awt-dev/2018-September/014302.html >> >> 11u changeset: >> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/af9ad0ae9039 >> >> Patch does not apply cleanly, because std::chrono is used for >> timestamps. And this part of C++11 standard is not supported by VS2010 >> toolchain that is used for 8u windows builds. The following change >> reimplements the same timestamps without std::chrono: >> >> >> ??auto getTimeStamp() -> long long { >> -??? using namespace std::chrono; >> -??? auto timeNow = >> duration_cast(steady_clock::now().time_since_epoch()); >> - >> -??? return timeNow.count(); >> +??? LARGE_INTEGER freqLarge; >> +??? ::QueryPerformanceFrequency(&freqLarge); >> +??? long long freq = freqLarge.QuadPart; >> +??? LARGE_INTEGER counterLarge; >> +??? ::QueryPerformanceCounter(&counterLarge); >> +??? long long counter = counterLarge.QuadPart; >> +??? long long milliDen = 1000; >> +??? long long whole = (counter / freq) * milliDen; >> +??? long long part = (counter % freq) * milliDen / freq; >> +??? return whole + part; >> ??} >> > Would this whole + part calculation just (counter * milliDen) / freq? or > you are worry about overflow? > > Otherwise, looks good to me. Thanks for the review! Yes, overflow here doesn't matter for milliseconds, but will happen if nanoseconds are used. > > [...] > -- -Alex From zgu at redhat.com Tue Sep 17 13:40:00 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 17 Sep 2019 09:40:00 -0400 Subject: [8u] RFR: 8196681: Java Access Bridge logging and debug flags dynamically controlled In-Reply-To: References: <257397da-ae0c-a0e0-f20f-c3f2094d6c48@redhat.com> Message-ID: <6364845a-a48e-c96a-7a9b-5a9edc9413d8@redhat.com> On 9/17/19 5:41 AM, Alex Kashchenko wrote: > Hi Zhengyu, > > On 09/16/2019 07:04 PM, Zhengyu Gu wrote: >> Hi Alex, >> >> On 9/9/19 12:29 PM, Alex Kashchenko wrote: >>> Hi, >>> >>> Please review the code change required to backport JDK-8196681 to 8u. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196681 >>> >>> Original review thread: >>> http://mail.openjdk.java.net/pipermail/awt-dev/2018-September/014302.html >>> >>> >>> 11u changeset: >>> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/af9ad0ae9039 >>> >>> Patch does not apply cleanly, because std::chrono is used for >>> timestamps. And this part of C++11 standard is not supported by >>> VS2010 toolchain that is used for 8u windows builds. The following >>> change reimplements the same timestamps without std::chrono: >>> >>> >>> ??auto getTimeStamp() -> long long { >>> -??? using namespace std::chrono; >>> -??? auto timeNow = >>> duration_cast(steady_clock::now().time_since_epoch()); >>> - >>> -??? return timeNow.count(); >>> +??? LARGE_INTEGER freqLarge; >>> +??? ::QueryPerformanceFrequency(&freqLarge); >>> +??? long long freq = freqLarge.QuadPart; >>> +??? LARGE_INTEGER counterLarge; >>> +??? ::QueryPerformanceCounter(&counterLarge); >>> +??? long long counter = counterLarge.QuadPart; >>> +??? long long milliDen = 1000; >>> +??? long long whole = (counter / freq) * milliDen; >>> +??? long long part = (counter % freq) * milliDen / freq; >>> +??? return whole + part; >>> ??} >>> >> Would this whole + part calculation just (counter * milliDen) / freq? >> or you are worry about overflow? >> >> Otherwise, looks good to me. > > Thanks for the review! > > Yes, overflow here doesn't matter for milliseconds, but will happen if > nanoseconds are used. Okay, a comment will be good. Thanks, -Zhengyu > >> >> [...] >> > > From akashche at redhat.com Tue Sep 17 15:14:19 2019 From: akashche at redhat.com (Alex Kashchenko) Date: Tue, 17 Sep 2019 16:14:19 +0100 Subject: [8u] RFR: 8196681: Java Access Bridge logging and debug flags dynamically controlled In-Reply-To: <6364845a-a48e-c96a-7a9b-5a9edc9413d8@redhat.com> References: <257397da-ae0c-a0e0-f20f-c3f2094d6c48@redhat.com> <6364845a-a48e-c96a-7a9b-5a9edc9413d8@redhat.com> Message-ID: On 9/17/19 2:40 PM, Zhengyu Gu wrote: > > > On 9/17/19 5:41 AM, Alex Kashchenko wrote: >> Hi Zhengyu, >> >> On 09/16/2019 07:04 PM, Zhengyu Gu wrote: >>> Hi Alex, >>> >>> On 9/9/19 12:29 PM, Alex Kashchenko wrote: >>>> Hi, >>>> >>>> Please review the code change required to backport JDK-8196681 to 8u. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196681 >>>> >>>> Original review thread: >>>> http://mail.openjdk.java.net/pipermail/awt-dev/2018-September/014302.html >>>> >>>> >>>> 11u changeset: >>>> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/af9ad0ae9039 >>>> >>>> Patch does not apply cleanly, because std::chrono is used for >>>> timestamps. And this part of C++11 standard is not supported by >>>> VS2010 toolchain that is used for 8u windows builds. The following >>>> change reimplements the same timestamps without std::chrono: >>>> >>>> >>>> ??auto getTimeStamp() -> long long { >>>> -??? using namespace std::chrono; >>>> -??? auto timeNow = >>>> duration_cast(steady_clock::now().time_since_epoch()); >>>> - >>>> -??? return timeNow.count(); >>>> +??? LARGE_INTEGER freqLarge; >>>> +??? ::QueryPerformanceFrequency(&freqLarge); >>>> +??? long long freq = freqLarge.QuadPart; >>>> +??? LARGE_INTEGER counterLarge; >>>> +??? ::QueryPerformanceCounter(&counterLarge); >>>> +??? long long counter = counterLarge.QuadPart; >>>> +??? long long milliDen = 1000; >>>> +??? long long whole = (counter / freq) * milliDen; >>>> +??? long long part = (counter % freq) * milliDen / freq; >>>> +??? return whole + part; >>>> ??} >>>> >>> Would this whole + part calculation just (counter * milliDen) / freq? >>> or you are worry about overflow? >>> >>> Otherwise, looks good to me. >> >> Thanks for the review! >> >> Yes, overflow here doesn't matter for milliseconds, but will happen if >> nanoseconds are used. > Okay, a comment will be good. Added a comment: + // prevent possible overflow + long long whole = (counter / freq) * milliDen; + long long part = (counter % freq) * milliDen / freq; + return whole + part; Full webrev just for the record: http://cr.openjdk.java.net/~akasko/jdk8u/8196681/webrev.01/ All other changes to original patch, besides AccessBridgeDebug#getTimeStamp() above, are either path changes or string literal changes in debug messages. > > [...] > -- -Alex From zgu at redhat.com Tue Sep 17 16:05:06 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 17 Sep 2019 12:05:06 -0400 Subject: [8u] RFR: 8196681: Java Access Bridge logging and debug flags dynamically controlled In-Reply-To: References: <257397da-ae0c-a0e0-f20f-c3f2094d6c48@redhat.com> <6364845a-a48e-c96a-7a9b-5a9edc9413d8@redhat.com> Message-ID: <18257e04-a41c-a551-f2a4-51863eaa2427@redhat.com> >>>>> >>>> Would this whole + part calculation just (counter * milliDen) / >>>> freq? or you are worry about overflow? >>>> >>>> Otherwise, looks good to me. >>> >>> Thanks for the review! >>> >>> Yes, overflow here doesn't matter for milliseconds, but will happen >>> if nanoseconds are used. >> Okay, a comment will be good. > > Added a comment: > > +??? // prevent possible overflow > +??? long long whole = (counter / freq) * milliDen; > +??? long long part = (counter % freq) * milliDen / freq; > +??? return whole + part; > > Full webrev just for the record: > http://cr.openjdk.java.net/~akasko/jdk8u/8196681/webrev.01/ > > All other changes to original patch, besides > AccessBridgeDebug#getTimeStamp() above, are either path changes or > string literal changes in debug messages. Looks good. Thanks, -Zhengyu > >> >> [...] >> > > From gnu.andrew at redhat.com Tue Sep 17 18:52:51 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 17 Sep 2019 19:52:51 +0100 Subject: Backport proposal of the Marlin renderer in OpenJDK8 In-Reply-To: References: <7539DA05-ACC0-4BB2-8ED5-BC2F32F99ABE@azul.com> <4EBE26E4-7BFF-44E3-AF11-18466AE0B691@azul.com> Message-ID: <93327ecf-bd13-802f-6d6c-eb51f185a3ed@redhat.com> On 12/09/2019 20:54, Laurent Bourg?s wrote: > Hi Andrew B (& other Andrew in this thread), > > I have an idea that could satisfy both approaches: > - As the azul team backported already jdk9+ patches into their openjdk8 / > zulu repository, it implies jdk8u patches are ready for integration and I > already reviewed the code: zulu could be considered as both an incubator > that proved Marlin works on jdk8 in production (as I did on my github). > > Two solutions: > - extract & apply all zulu-ready patches in order in jdk8u-dev > - extract one big patch (from zulu) and apply it on jdk8u-dev > I do not see any reason to use another incubator repository... > > I can review all individual patches or the all-in-one and we are all done, > up to the last patch backported in zulu 8 (version 0.9.1.1 merged in dec > 2018 according to me). > > Moreover I already maintain a github branch for the Marlin / openjdk (8): > https://github.com/bourgesl/marlin-renderer/tree/openjdk?files=1 > It is my reference to easily compare with any jdk8 codebase. > > From this first step, I will manage the missing patches to be up-to-date > with latest jdk14 (v0.9.1.3 ie 2 patches) and future ones. > > What do you think ? > This approach requires some work from zulu team to publish jdk8 patches > that I will review and I need a jdk8u sponsor to endorse, follow & push the > patch train or the all-in-one patch integration. > > Cheers, > Laurent > Is this Zulu public? Does it use OpenJDK bug IDs for the changesets? As I said before, my preferred method is the backport of changesets corresponding to individual OpenJDK bug IDs, so we have a clear idea of what issues are now fixed in 8u. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue Sep 17 19:56:57 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 17 Sep 2019 20:56:57 +0100 Subject: Result: New OpenJDK 8 Updates Committer: Martin Balao Message-ID: Voting for Martin Balao [0] is now closed. Yes: 10 Veto: 0 Abstain: 0 Turnout: 4.5% (10/220) According to the Bylaws definition of Lazy Consensus [1], this is sufficient to approve the nomination. [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-July/009858.html [1] https://openjdk.java.net/bylaws#lazy-consensus -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue Sep 17 20:52:24 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 17 Sep 2019 21:52:24 +0100 Subject: CFV: New OpenJDK 8 Updates Committer: Simon Tooke Message-ID: I hereby nominate Simon Tooke (stooke) [0] to OpenJDK 8 Updates Committer. Simon has done work in the main JDK project [1] as well as backporting work for 8u [2]. Making him a committer would aid this backporting work by avoiding the need for someone else to push his fixes. Votes are due by 21h00 UTC on the 1st of October, 2019. Only current OpenJDK 8 Updates Committers (and above) [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. [0] https://openjdk.java.net/census#stooke [1] https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%20%22))+and+not+merge() [2] https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%20%22))+and+not+merge() [3] http://openjdk.java.net/census#jdk8u [4] http://openjdk.java.net/projects/#committer-vote -- 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 Sep 17 23:21:40 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 17 Sep 2019 23:21:40 +0000 Subject: New OpenJDK 8 Updates Committer: Simon Tooke In-Reply-To: References: Message-ID: <5B38EA17-D96D-4200-AF35-D414CD8C5010@amazon.com> Vote: yes ?On 9/17/19, 1:53 PM, "jdk8u-dev on behalf of Andrew John Hughes" wrote: I hereby nominate Simon Tooke (stooke) [0] to OpenJDK 8 Updates Committer. Simon has done work in the main JDK project [1] as well as backporting work for 8u [2]. Making him a committer would aid this backporting work by avoiding the need for someone else to push his fixes. Votes are due by 21h00 UTC on the 1st of October, 2019. Only current OpenJDK 8 Updates Committers (and above) [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. [0] https://openjdk.java.net/census#stooke [1] https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%20%22))+and+not+merge() [2] https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%20%22))+and+not+merge() [3] http://openjdk.java.net/census#jdk8u [4] http://openjdk.java.net/projects/#committer-vote -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From zgu at redhat.com Wed Sep 18 00:57:43 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 17 Sep 2019 20:57:43 -0400 Subject: CFV: New OpenJDK 8 Updates Committer: Simon Tooke In-Reply-To: References: Message-ID: <1c66c458-6318-dd6e-aca1-683a748a096f@redhat.com> Vote: yes -Zhengyu On 9/17/19 4:52 PM, Andrew John Hughes wrote: > I hereby nominate Simon Tooke (stooke) [0] to OpenJDK 8 Updates Committer. > > Simon has done work in the main JDK project [1] as well as backporting > work for 8u [2]. Making him a committer would aid this backporting work > by avoiding the need for someone else to push his fixes. > > Votes are due by 21h00 UTC on the 1st of October, 2019. > > Only current OpenJDK 8 Updates Committers (and above) [3] are eligible > to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > [0] https://openjdk.java.net/census#stooke > [1] > https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%20%22))+and+not+merge() > [2] > https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%20%22))+and+not+merge() > [3] http://openjdk.java.net/census#jdk8u > [4] http://openjdk.java.net/projects/#committer-vote > From bourges.laurent at gmail.com Wed Sep 18 07:44:37 2019 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 18 Sep 2019 09:44:37 +0200 Subject: How to import patch from jdk/jdk In-Reply-To: References: <5d12f77e-a674-f989-39f0-e8fa57b6a0b0@redhat.com> Message-ID: Hi, Just a reminder, I need info how to go forward and become familiar with the jdk8update process. I will publish my 2 jdk8u patches on my cr.openjdk account and send a RFR to jdk8u-dev. I need a sponsor & reviewer. Cheers, Laurent Le mer. 11 sept. 2019 ? 09:27, Laurent Bourg?s a ?crit : > Hi Andrews, > > I successfull imported 2 patches fixing the PNGImageWriter... > > Your instructions were precious but I give you my feedback as it could > improve the wiki / process / howto: > - I cloned jdk8u-dev, jdk9/jdk to find my original by changeset id as the > unshuffle-script needs git diff format only > - my first attempt did not apply cleanly (hg import 8-fixed-patch) as > PNGImageWriter was changed by another jdk9 fix > - I used the hg web interface to easily read the file history... it is > painful as jdk9u does not have the complete history... only jdk9/jdk has > the complete changeset log. > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log/65464a307408/src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java > > 2015-12-16 prr 6488522: PNG writer should permit setting compression > level and iDAT chunk maximum size > > 2015-12-01 jdv 6967419: IndexOutOfBoundsException when drawing PNGs > > > - I rollbacked my first attempt, extracted the 2 patches from jdk9(hg > export --git changeset-id > file), fixed them (unshuffle-script from jdk9u) > and applied the 2 jdk8-fixed patches in order and it applied well. > > I made a clean build (jdk8u-dev/ make images) and ran manually my tests: > imageio & png only. > The jdk-updates says I must run tier1 tests but the command 'make > run-tests tier1' does not work... Anyway these patches only affect > javax/imageio ... > > Which jtreg build should I use with jdk8u ? My recent jtreg binaries fails > to parse jdk8 version string ! > Where can I download it ? > > What is the process now to propose these 2 png patches for jdk8u > integration ? > I can just put the jdk8u-fix-request label on these 2 bugs, but is it > enough ? > I also need a jdk8u sponsor, as I am not a committer on 8 but >= 9... > > I can start a RFR thread on this png encoder topic: > The jdk9 fix changes the default deflater level 9 to 4 to reduce the cpu > overhead and improve png encoding performance: see original RFR thread > https://bugs.openjdk.java.net/browse/JDK-6488522 > > " > > I quickly tested several Deflater compression levels [0 to 9] on some huge > map images: > * total size: > * level 1: 49.9 Mb > * level 3: 46.9 Mb > * level 4: 40.7 Mb > * level 9: 37 Mb > * write PNG time (most complex image) : > * level 1: 8211 ms > * level 3: 7793 ms > * level 4: 9450 ms > * level 9: 23562 ms > > I would choose by default the level 4 to have the best compromise between > speed vs time. > " > > Do you agree or not as it will change the jdk8 behaviour ? > > Thanks, > Laurent > > > Le mer. 21 ao?t 2019 ? 18:08, Andrew John Hughes > 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 >> >> -- >> 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 Sep 18 08:08:18 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 18 Sep 2019 10:08:18 +0200 Subject: CFV: New OpenJDK 8 Updates Committer: Simon Tooke In-Reply-To: References: Message-ID: <1b95269e-4c19-6fd4-cee1-31f17ff82166@redhat.com> Vote: yes On 9/17/19 10:52 PM, Andrew John Hughes wrote: > I hereby nominate Simon Tooke (stooke) [0] to OpenJDK 8 Updates Committer. -- Thanks, -Aleksey From sgehwolf at redhat.com Wed Sep 18 08:17:11 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 18 Sep 2019 10:17:11 +0200 Subject: CFV: New OpenJDK 8 Updates Committer: Simon Tooke In-Reply-To: References: Message-ID: Vote: yes On Tue, 2019-09-17 at 21:52 +0100, Andrew John Hughes wrote: > I hereby nominate Simon Tooke (stooke) [0] to OpenJDK 8 Updates Committer. > > Simon has done work in the main JDK project [1] as well as backporting > work for 8u [2]. Making him a committer would aid this backporting work > by avoiding the need for someone else to push his fixes. > > Votes are due by 21h00 UTC on the 1st of October, 2019. > > Only current OpenJDK 8 Updates Committers (and above) [3] are eligible > to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > [0] https://openjdk.java.net/census#stooke > [1] > https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%20%22))+and+not+merge() > [2] > https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%20%22))+and+not+merge() > [3] http://openjdk.java.net/census#jdk8u > [4] http://openjdk.java.net/projects/#committer-vote From kshefov at azul.com Wed Sep 18 08:56:04 2019 From: kshefov at azul.com (Konstantin Shefov) Date: Wed, 18 Sep 2019 08:56:04 +0000 Subject: Backport vmTestbase tests to jdk8u-dev? In-Reply-To: <9ba7e7af9a1645c4831610327c96f22b@azul.com> References: <9ba7e7af9a1645c4831610327c96f22b@azul.com> Message-ID: <51653b0b3223448bbe2f9186d11556af@azul.com> Hi We ran the tests against x86_64 Ubuntu Linux and there are just the same failed tests as it was with Arm64 Ubuntu Linux plus 2 more tests: vmTestbase/gc/lock/jni/jnilock002/TestDescription.java vmTestbase/nsk/jdb/set/set001/set001.java Konstantin From: Konstantin Shefov Sent: Wednesday, September 11, 2019 10:53 AM To: 'Liu, Xin' ; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, LX Answering to your e-mail, as for what we modified in [3]: 1. API changes (Process, Unsafe), Xloggc option, that were not in your patches; 2. In a file hotspot/test/JtregNativeHotspot.gmk we changed ?-lpthread? option to ?-pthread? to prevent compilation error. I agree that there should be a series of patches to track file changes. As for investigation of failures: do you have the same? We ran against Arm64 platform, but we can try against x86-64 too. Konstantin From: Liu, Xin > Sent: Monday, September 9, 2019 11:04 PM To: Konstantin Shefov >; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, We are glad to work with you to get vmTestbase landed into jdk8u. Our original intent is get design reviewed by the jdk8u maintainer. After then, we can proceed to refactor it. We can work together to refactor it. we plan to do it anyway. Back to the webrev you send. What did you modify in [3]? Ideally, we can should have a series of patches. The first one should be intact vmTestbase code from the tip of JDK. All we changes should come after it and be reviewed by this mail-list. In addition to refactoring, we can also offer help to figure out those failed cases. What do you think? Thanks, --lx From: Konstantin Shefov > Date: Friday, September 6, 2019 at 12:55 PM To: "jdk8u-dev at openjdk.java.net" > Cc: "Liu, Xin" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, We at Azul think it is a good idea to backport vmTestbase tests to OpenJDK 8. We have used patches you suggested, done some refactoring to enable more tests to work with JDK 8. We have run all 3550 tests from ?vmTestbase? folder against Zulu 8 at ARM64 platform: 1. 3371 tests PASS (see [1]); 2. 179 tests FAIL (see [2]): reasons are being investigated. Patches we have used (contain our refactoring): 1. Hotspot folder [3] 2. Main folder [4] We plan to investigate causes of those 177 failures, purify unused code from hotspot/test/test/lib/jdk, and run the tests against different platforms. We also compared vmTestbase from JDK 11 with that from JDK 13, we found out: 1. 332 test have been removed in JDK 13; 2. Only 2 test have been added in JDK 13; 3. Tests that remained were modified, but these modifications mostly are copyright years, or output format, or API changes. From the above results we can tell that vmTestbase does not grow. It looks like that tests are been removed from there or transferred somewhere else. [1] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/passed_tests.html [2] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/failed_tests.html [3] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_hotspot.patch [4] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_root.patch Regards, --Konstantin From stooke at redhat.com Wed Sep 18 12:43:28 2019 From: stooke at redhat.com (Simon Tooke) Date: Wed, 18 Sep 2019 08:43:28 -0400 Subject: [8u] RFR 8226288 - Upgrade to XCode 10+ for building JDK 8u and 11u In-Reply-To: References: <16e90c95-20dc-e784-32fe-1b8341498c08@redhat.com> Message-ID: On 9/17/2019 1:31 PM, Derek Keeler wrote: > Hi build-dev friends! > > I'm Derek Keeler,?the infrastructure lead on the Java Platform team > within?Microsoft, working with the AdoptOpenJDK's George Adams and > John Oliver. > > Simon, I have pulled down your jdk8u patches and have built them > against macOS Mojave (with a good amount of help from George and John). Hi, and thanks for your interest.? > > Currently, the build succeeds! > > I am planning to throw the entire AdoptOpenJDK test roster against it > sometime today/tomorrow. > > I will let you know what I find as a result of those tests, and what > if anything I had to do in order to get things up and running. Yes, please.? Also any difficulties you had with the initial script or instructions; I know there was a syntax error that I just fixed. -Simon > > -Derek > > > ------------------------------------------------------------------------ > *From:* build-dev on behalf of > Simon Tooke > *Sent:* September 13, 2019 7:05 AM > *To:* jdk8u-dev at openjdk.java.net ; > build-dev > *Subject:* [8u] RFR 8226288 - Upgrade to XCode 10+ for building JDK 8u > and 11u > ? > Hello all, > > This is a request for review of my patch to enable building 8u with > modern (9,10,11) Xcode versions on macOS.? I've received a few recent > enquiries so I thought I'd submit this. > > When I first created this patch is was more for convenience, but soon > macOS will require applications to be "notarized", which cannot be done > with the old version of Xcode.? This will become mandatory long before > 8u is due to retire [1]. > > This patch is not intended to remove the current ability to build 8u on > the current supported build platform. > > I have used the patch with Xcode 9,10 and a beta of 11, and used the > resultant JDK to build Graal.? > > I have not build a JDK using the old Xcode and this patch; my intent was > to ensure this was still possible. > > There is some information available on my GitHub page: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fstooke%2Fjdk8u-xcode10&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865878108&sdata=THixfdOpuZrY8%2BdEDHFVjmV%2BnePxVGFsof9eDoqJikE%3D&reserved=0 > > Issue: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8226288&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865878108&sdata=VHN2S0uxbbeJiiuWznYafSpXmERDdp29U%2FqVMJSdUuw%3D&reserved=0 > > Webrev: > https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~stooke%2Fwebrevs%2Fjdk-8226288-jdk8u%2F00%2F&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865888100&sdata=T6uq0ThFfHLrqslWfCz2x846ixtLMIW5EwaP4U4Jvqc%3D&reserved=0 > > Previous discussion:? > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fjdk8u-dev%2F2019-June%2F009733.html&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865888100&sdata=WDUf2fhTqmcNTZJJ2NNnI%2FtCKxr%2BxQLiCfPmpj3m0p8%3D&reserved=0? > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fjdk8u-dev%2F2019-July%2F009760.html&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865888100&sdata=pJXk%2Bg5LlmSpogNhcINgRezCSozo7MbW%2FNWLJNrf%2BV8%3D&reserved=0 > > Thank you for your time, > > -Simon > > > [1] > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.apple.com%2Fdocumentation%2Fsecurity%2Fnotarizing_your_app_before_distribution&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865888100&sdata=TZmbZfAFDXXwpBJ8xibzzfoCicd5Fwm0xwdCo2hIaYo%3D&reserved=0 > From christoph.langer at sap.com Wed Sep 18 14:00:10 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 18 Sep 2019 14:00:10 +0000 Subject: CFV: New OpenJDK 8 Updates Committer: Simon Tooke In-Reply-To: References: Message-ID: Vote:yes > -----Original Message----- > From: jdk8u-dev On Behalf Of > Andrew John Hughes > Sent: Dienstag, 17. September 2019 22:52 > To: 'jdk8u-dev at openjdk.java.net' > Subject: CFV: New OpenJDK 8 Updates Committer: Simon Tooke > > I hereby nominate Simon Tooke (stooke) [0] to OpenJDK 8 Updates > Committer. > > Simon has done work in the main JDK project [1] as well as backporting > work for 8u [2]. Making him a committer would aid this backporting work > by avoiding the need for someone else to push his fixes. > > Votes are due by 21h00 UTC on the 1st of October, 2019. > > Only current OpenJDK 8 Updates Committers (and above) [3] are eligible > to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > [0] https://openjdk.java.net/census#stooke > [1] > https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(stooke > )+or+desc(%22stooke%40redhat.com%20%22))+and+not+merge() > [2] > https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(auth > or(stooke)+or+desc(%22stooke%40redhat.com%20%22))+and+not+merge() > [3] http://openjdk.java.net/census#jdk8u > [4] http://openjdk.java.net/projects/#committer-vote > -- > 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 Sep 18 17:59:26 2019 From: xxinliu at amazon.com (Liu, Xin) Date: Wed, 18 Sep 2019 17:59:26 +0000 Subject: Backport vmTestbase tests to jdk8u-dev? In-Reply-To: <51653b0b3223448bbe2f9186d11556af@azul.com> References: <9ba7e7af9a1645c4831610327c96f22b@azul.com>, <51653b0b3223448bbe2f9186d11556af@azul.com> Message-ID: <1568829532868.82475@amazon.com> Hi, Konstantin, thank you for updating. We care about x86_64 and aarch64 as well. You ran more tests than us. we never run all vmTestbase. Previously, I used a ProblemList.txt file to screen Problem and move on. Do you plan to fix all problems before we check in? Back to refactor, I have filed a JBS issues. https://bugs.openjdk.java.net/browse/JDK-8231089 In the meanwhile, I start splitting the commits to individual hg changesets. https://cr.openjdk.java.net/~xliu/8231089/ 1. base -> copy code from tag jdk-14+14 intact commit for vmTestbase and testlib 2. make apiChanges for ProcessUtils and Unsafe Could you review it? 3. ClassFileInstaller needs /testlibrary it's because ClassFileInstaller is in /test/testlibrary. I use this script to install @library /testlibrary for all tests. out=$(grep "ClassFileInstaller" -R vmTestbase | awk '{print $1}') for i in $out; do f=${i%\:} gsed -i 's/@library \/vmTestbase/&\n * \/testlibrary/' $f done What do you think that this approach? If I got something wrong, we can update the webtrev with yours. thanks, --lx ________________________________ From: Konstantin Shefov Sent: Wednesday, September 18, 2019 4:56 PM To: Liu, Xin; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi We ran the tests against x86_64 Ubuntu Linux and there are just the same failed tests as it was with Arm64 Ubuntu Linux plus 2 more tests: vmTestbase/gc/lock/jni/jnilock002/TestDescription.java vmTestbase/nsk/jdb/set/set001/set001.java Konstantin From: Konstantin Shefov Sent: Wednesday, September 11, 2019 10:53 AM To: 'Liu, Xin' ; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, LX Answering to your e-mail, as for what we modified in [3]: 1. API changes (Process, Unsafe), Xloggc option, that were not in your patches; 2. In a file hotspot/test/JtregNativeHotspot.gmk we changed ?-lpthread? option to ?-pthread? to prevent compilation error. I agree that there should be a series of patches to track file changes. As for investigation of failures: do you have the same? We ran against Arm64 platform, but we can try against x86-64 too. Konstantin From: Liu, Xin > Sent: Monday, September 9, 2019 11:04 PM To: Konstantin Shefov >; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, We are glad to work with you to get vmTestbase landed into jdk8u. Our original intent is get design reviewed by the jdk8u maintainer. After then, we can proceed to refactor it. We can work together to refactor it. we plan to do it anyway. Back to the webrev you send. What did you modify in [3]? Ideally, we can should have a series of patches. The first one should be intact vmTestbase code from the tip of JDK. All we changes should come after it and be reviewed by this mail-list. In addition to refactoring, we can also offer help to figure out those failed cases. What do you think? Thanks, --lx From: Konstantin Shefov > Date: Friday, September 6, 2019 at 12:55 PM To: "jdk8u-dev at openjdk.java.net" > Cc: "Liu, Xin" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, We at Azul think it is a good idea to backport vmTestbase tests to OpenJDK 8. We have used patches you suggested, done some refactoring to enable more tests to work with JDK 8. We have run all 3550 tests from ?vmTestbase? folder against Zulu 8 at ARM64 platform: 1. 3371 tests PASS (see [1]); 2. 179 tests FAIL (see [2]): reasons are being investigated. Patches we have used (contain our refactoring): 1. Hotspot folder [3] 2. Main folder [4] We plan to investigate causes of those 177 failures, purify unused code from hotspot/test/test/lib/jdk, and run the tests against different platforms. We also compared vmTestbase from JDK 11 with that from JDK 13, we found out: 1. 332 test have been removed in JDK 13; 2. Only 2 test have been added in JDK 13; 3. Tests that remained were modified, but these modifications mostly are copyright years, or output format, or API changes. >From the above results we can tell that vmTestbase does not grow. It looks like that tests are been removed from there or transferred somewhere else. [1] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/passed_tests.html [2] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/failed_tests.html [3] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_hotspot.patch [4] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_root.patch Regards, --Konstantin From kshefov at azul.com Fri Sep 6 19:54:05 2019 From: kshefov at azul.com (Konstantin Shefov) Date: Fri, 6 Sep 2019 19:54:05 +0000 Subject: Backport vmTestbase tests to jdk8u-dev? Message-ID: Hi, We at Azul think it is a good idea to backport vmTestbase tests to OpenJDK 8. We have used patches you suggested, done some refactoring to enable more tests to work with JDK 8. We have run all 3550 tests from "vmTestbase" folder against Zulu 8 at ARM64 platform: 1. 3371 tests PASS (see [1]); 2. 179 tests FAIL (see [2]): reasons are being investigated. Patches we have used (contain our refactoring): 1. Hotspot folder [3] 2. Main folder [4] We plan to investigate causes of those 177 failures, purify unused code from hotspot/test/test/lib/jdk, and run the tests against different platforms. We also compared vmTestbase from JDK 11 with that from JDK 13, we found out: 1. 332 test have been removed in JDK 13; 2. Only 2 test have been added in JDK 13; 3. Tests that remained were modified, but these modifications mostly are copyright years, or output format, or API changes. >From the above results we can tell that vmTestbase does not grow. It looks like that tests are been removed from there or transferred somewhere else. [1] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/passed_tests.html [2] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/failed_tests.html [3] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_hotspot.patch [4] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_root.patch Regards, --Konstantin From dekeeler at microsoft.com Tue Sep 17 17:31:08 2019 From: dekeeler at microsoft.com (Derek Keeler) Date: Tue, 17 Sep 2019 17:31:08 +0000 Subject: [8u] RFR 8226288 - Upgrade to XCode 10+ for building JDK 8u and 11u In-Reply-To: <16e90c95-20dc-e784-32fe-1b8341498c08@redhat.com> References: <16e90c95-20dc-e784-32fe-1b8341498c08@redhat.com> Message-ID: Hi build-dev friends! I'm Derek Keeler, the infrastructure lead on the Java Platform team within Microsoft, working with the AdoptOpenJDK's George Adams and John Oliver. Simon, I have pulled down your jdk8u patches and have built them against macOS Mojave (with a good amount of help from George and John). Currently, the build succeeds! I am planning to throw the entire AdoptOpenJDK test roster against it sometime today/tomorrow. I will let you know what I find as a result of those tests, and what if anything I had to do in order to get things up and running. -Derek ________________________________ From: build-dev on behalf of Simon Tooke Sent: September 13, 2019 7:05 AM To: jdk8u-dev at openjdk.java.net ; build-dev Subject: [8u] RFR 8226288 - Upgrade to XCode 10+ for building JDK 8u and 11u Hello all, This is a request for review of my patch to enable building 8u with modern (9,10,11) Xcode versions on macOS. I've received a few recent enquiries so I thought I'd submit this. When I first created this patch is was more for convenience, but soon macOS will require applications to be "notarized", which cannot be done with the old version of Xcode. This will become mandatory long before 8u is due to retire [1]. This patch is not intended to remove the current ability to build 8u on the current supported build platform. I have used the patch with Xcode 9,10 and a beta of 11, and used the resultant JDK to build Graal. I have not build a JDK using the old Xcode and this patch; my intent was to ensure this was still possible. There is some information available on my GitHub page: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fstooke%2Fjdk8u-xcode10&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865878108&sdata=THixfdOpuZrY8%2BdEDHFVjmV%2BnePxVGFsof9eDoqJikE%3D&reserved=0 Issue: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8226288&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865878108&sdata=VHN2S0uxbbeJiiuWznYafSpXmERDdp29U%2FqVMJSdUuw%3D&reserved=0 Webrev: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~stooke%2Fwebrevs%2Fjdk-8226288-jdk8u%2F00%2F&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865888100&sdata=T6uq0ThFfHLrqslWfCz2x846ixtLMIW5EwaP4U4Jvqc%3D&reserved=0 Previous discussion: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fjdk8u-dev%2F2019-June%2F009733.html&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865888100&sdata=WDUf2fhTqmcNTZJJ2NNnI%2FtCKxr%2BxQLiCfPmpj3m0p8%3D&reserved=0 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fjdk8u-dev%2F2019-July%2F009760.html&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865888100&sdata=pJXk%2Bg5LlmSpogNhcINgRezCSozo7MbW%2FNWLJNrf%2BV8%3D&reserved=0 Thank you for your time, -Simon [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.apple.com%2Fdocumentation%2Fsecurity%2Fnotarizing_your_app_before_distribution&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865888100&sdata=TZmbZfAFDXXwpBJ8xibzzfoCicd5Fwm0xwdCo2hIaYo%3D&reserved=0 From ramz.mohan88 at gmail.com Wed Sep 18 18:56:40 2019 From: ramz.mohan88 at gmail.com (Rammohan Vanteru) Date: Wed, 18 Sep 2019 14:56:40 -0400 Subject: JVM dynamic Attach api issue Message-ID: Hi Team, I am facing an issue with JVM dynamic Attach api. We have a source code which connects to target jvms using dynamic attach api which works fine for few days. After couple of days it start?s failing making connections to target jvms because /tmp/.java_pid* is removed automatically. We also see that target JVMs?s generating thread dump?s in stdout. Currently we are using JDK version "1.8.0_172". let me know if anyone have more information this kind of issue. Thanks, Ram. From aph at redhat.com Wed Sep 18 21:40:49 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 18 Sep 2019 22:40:49 +0100 Subject: JVM dynamic Attach api issue In-Reply-To: References: Message-ID: <9a90828c-1533-eb69-523e-33ebd7c9e296@redhat.com> On 9/18/19 7:56 PM, Rammohan Vanteru wrote: > > I am facing an issue with JVM dynamic Attach api. We have a source code > which connects to target jvms using dynamic attach api which works fine for > few days. After couple of days it start?s failing making connections to > target jvms because /tmp/.java_pid* is removed automatically. We also see > that target JVMs?s generating thread dump?s in stdout. > > Currently we are using JDK version "1.8.0_172". Your operating system is doing this. I don't know exactly which OS that is. You should be able to find your system's documentation, and see how the auto-deletion is configured. Then you can turn it off. -- 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 zgu at redhat.com Wed Sep 18 23:40:58 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 18 Sep 2019 19:40:58 -0400 Subject: JVM dynamic Attach api issue In-Reply-To: <9a90828c-1533-eb69-523e-33ebd7c9e296@redhat.com> References: <9a90828c-1533-eb69-523e-33ebd7c9e296@redhat.com> Message-ID: There is an existing thread on this issue. https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2019-June/034906.html -Zhengyu On 9/18/19 5:40 PM, Andrew Haley wrote: > On 9/18/19 7:56 PM, Rammohan Vanteru wrote: >> >> I am facing an issue with JVM dynamic Attach api. We have a source code >> which connects to target jvms using dynamic attach api which works fine for >> few days. After couple of days it start?s failing making connections to >> target jvms because /tmp/.java_pid* is removed automatically. We also see >> that target JVMs?s generating thread dump?s in stdout. >> >> Currently we are using JDK version "1.8.0_172". > > Your operating system is doing this. I don't know exactly which OS > that is. > > You should be able to find your system's documentation, and see how > the auto-deletion is configured. Then you can turn it off. > From aph at redhat.com Thu Sep 19 08:31:28 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 19 Sep 2019 09:31:28 +0100 Subject: JVM dynamic Attach api issue In-Reply-To: References: <9a90828c-1533-eb69-523e-33ebd7c9e296@redhat.com> Message-ID: <9254a20f-f205-28fe-da7f-2b5cf901fa8f@redhat.com> On 9/19/19 1:50 AM, Rammohan Vanteru wrote: > > We are using red linux OS we do not have any cronjobs configured to remove /tmp file system. Well, something is doing it. On my system I would edit the /usr/lib/tmpfiles.d/tmp.conf to exclude the /tmp/.java_pid files. > Thanks Zhengyu, so its a jdk bug. Its a similar issue iam facing too.? > > I see below jdk bug was fixed. I don't see that any bug was fixed. Which message are you referring to? > Any idea as part of which release bug was fixed? Iam not able to find the release notes in regards to this bug. -- 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 zgu at redhat.com Thu Sep 19 10:48:57 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 19 Sep 2019 06:48:57 -0400 Subject: JVM dynamic Attach api issue In-Reply-To: <9254a20f-f205-28fe-da7f-2b5cf901fa8f@redhat.com> References: <9a90828c-1533-eb69-523e-33ebd7c9e296@redhat.com> <9254a20f-f205-28fe-da7f-2b5cf901fa8f@redhat.com> Message-ID: Hi Andrew On 9/19/19 4:31 AM, Andrew Haley wrote: > On 9/19/19 1:50 AM, Rammohan Vanteru wrote: >> >> We are using red linux OS we do not have any cronjobs configured to remove /tmp file system. > > Well, something is doing it. On my system I would edit the /usr/lib/tmpfiles.d/tmp.conf > to exclude the /tmp/.java_pid files. > >> Thanks Zhengyu, so its a jdk bug. Its a similar issue iam facing too. >> >> I see below jdk bug was fixed. > > I don't see that any bug was fixed. Which message are you referring to? > I think he referred to this CR: https://bugs.openjdk.java.net/browse/JDK-8225690 -Zhengyu >> Any idea as part of which release bug was fixed? Iam not able to find the release notes in regards to this bug. > From adinn at redhat.com Thu Sep 19 11:07:58 2019 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 19 Sep 2019 12:07:58 +0100 Subject: CFV: New OpenJDK 8 Updates Committer: Simon Tooke In-Reply-To: References: Message-ID: <1bc5d2d8-39b9-ecb1-fd84-3404c6e570e9@redhat.com> Vote: yes On 17/09/2019 21:52, Andrew John Hughes wrote: > I hereby nominate Simon Tooke (stooke) [0] to OpenJDK 8 Updates Committer. > > Simon has done work in the main JDK project [1] as well as backporting > work for 8u [2]. Making him a committer would aid this backporting work > by avoiding the need for someone else to push his fixes. > > Votes are due by 21h00 UTC on the 1st of October, 2019. > > Only current OpenJDK 8 Updates Committers (and above) [3] are eligible > to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > [0] https://openjdk.java.net/census#stooke > [1] > https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%20%22))+and+not+merge() > [2] > https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%20%22))+and+not+merge() > [3] http://openjdk.java.net/census#jdk8u > [4] http://openjdk.java.net/projects/#committer-vote > -- 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 kshefov at azul.com Thu Sep 19 15:23:57 2019 From: kshefov at azul.com (Konstantin Shefov) Date: Thu, 19 Sep 2019 15:23:57 +0000 Subject: Backport vmTestbase tests to jdk8u-dev? In-Reply-To: <51653b0b3223448bbe2f9186d11556af@azul.com> References: <9ba7e7af9a1645c4831610327c96f22b@azul.com> <51653b0b3223448bbe2f9186d11556af@azul.com> Message-ID: Hello We have updated some more vmTestbase tests so they run with JDK 8 now. Totally we have the following statistics for x86_64 Linux: Passed [1]: 3531 Failed [2]: 13 Timeout [3]: 2 Here is initial patch (just add of non-modified tests) ? see [4]. And patch that shows modification ? see [5]. Webrev with modifications in zip ? see [6]. [1] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport_2/passed_gr.html [2] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport_2/failed_gr.html [3] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport_2/error_gr.html [4] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport_2/vmTestbase_init.patch [5] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport_2/vmTestbase_mod.patch [6] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport_2/webrev.zip Regards, --Konstantin From: Konstantin Shefov Sent: Wednesday, September 18, 2019 11:56 AM To: 'Liu, Xin' ; 'jdk8u-dev at openjdk.java.net' Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi We ran the tests against x86_64 Ubuntu Linux and there are just the same failed tests as it was with Arm64 Ubuntu Linux plus 2 more tests: vmTestbase/gc/lock/jni/jnilock002/TestDescription.java vmTestbase/nsk/jdb/set/set001/set001.java Konstantin From: Konstantin Shefov Sent: Wednesday, September 11, 2019 10:53 AM To: 'Liu, Xin' >; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, LX Answering to your e-mail, as for what we modified in [3]: 1. API changes (Process, Unsafe), Xloggc option, that were not in your patches; 2. In a file hotspot/test/JtregNativeHotspot.gmk we changed ?-lpthread? option to ?-pthread? to prevent compilation error. I agree that there should be a series of patches to track file changes. As for investigation of failures: do you have the same? We ran against Arm64 platform, but we can try against x86-64 too. Konstantin From: Liu, Xin > Sent: Monday, September 9, 2019 11:04 PM To: Konstantin Shefov >; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, We are glad to work with you to get vmTestbase landed into jdk8u. Our original intent is get design reviewed by the jdk8u maintainer. After then, we can proceed to refactor it. We can work together to refactor it. we plan to do it anyway. Back to the webrev you send. What did you modify in [3]? Ideally, we can should have a series of patches. The first one should be intact vmTestbase code from the tip of JDK. All we changes should come after it and be reviewed by this mail-list. In addition to refactoring, we can also offer help to figure out those failed cases. What do you think? Thanks, --lx From: Konstantin Shefov > Date: Friday, September 6, 2019 at 12:55 PM To: "jdk8u-dev at openjdk.java.net" > Cc: "Liu, Xin" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, We at Azul think it is a good idea to backport vmTestbase tests to OpenJDK 8. We have used patches you suggested, done some refactoring to enable more tests to work with JDK 8. We have run all 3550 tests from ?vmTestbase? folder against Zulu 8 at ARM64 platform: 1. 3371 tests PASS (see [1]); 2. 179 tests FAIL (see [2]): reasons are being investigated. Patches we have used (contain our refactoring): 1. Hotspot folder [3] 2. Main folder [4] We plan to investigate causes of those 177 failures, purify unused code from hotspot/test/test/lib/jdk, and run the tests against different platforms. We also compared vmTestbase from JDK 11 with that from JDK 13, we found out: 1. 332 test have been removed in JDK 13; 2. Only 2 test have been added in JDK 13; 3. Tests that remained were modified, but these modifications mostly are copyright years, or output format, or API changes. From the above results we can tell that vmTestbase does not grow. It looks like that tests are been removed from there or transferred somewhere else. [1] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/passed_tests.html [2] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/failed_tests.html [3] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_hotspot.patch [4] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_root.patch Regards, --Konstantin From bourges.laurent at gmail.com Thu Sep 19 17:09:08 2019 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 19 Sep 2019 19:09:08 +0200 Subject: Backport proposal of the Marlin renderer in OpenJDK8 In-Reply-To: <93327ecf-bd13-802f-6d6c-eb51f185a3ed@redhat.com> References: <7539DA05-ACC0-4BB2-8ED5-BC2F32F99ABE@azul.com> <4EBE26E4-7BFF-44E3-AF11-18466AE0B691@azul.com> <93327ecf-bd13-802f-6d6c-eb51f185a3ed@redhat.com> Message-ID: Hi Andrew JH, As I have no more news from Azul, I will start redoing all the proper backport. I identified ~ 25 bug ids and the corresponding hg changeset ids in latest jdk repo. Le mar. 17 sept. 2019 ? 20:53, Andrew John Hughes a ?crit : > > > On 12/09/2019 20:54, Laurent Bourg?s wrote: > > Hi Andrew B (& other Andrew in this thread), > > > > I have an idea that could satisfy both approaches: > > - As the azul team backported already jdk9+ patches into their openjdk8 / > > zulu repository, it implies jdk8u patches are ready for integration and I > > already reviewed the code: zulu could be considered as both an incubator > > that proved Marlin works on jdk8 in production (as I did on my github). > > > > Two solutions: > > - extract & apply all zulu-ready patches in order in jdk8u-dev > > - extract one big patch (from zulu) and apply it on jdk8u-dev > > I do not see any reason to use another incubator repository... > > > > I can review all individual patches or the all-in-one and we are all > done, > > up to the last patch backported in zulu 8 (version 0.9.1.1 merged in dec > > 2018 according to me). > > > > Moreover I already maintain a github branch for the Marlin / openjdk (8): > > https://github.com/bourgesl/marlin-renderer/tree/openjdk?files=1 > > It is my reference to easily compare with any jdk8 codebase. > > > > From this first step, I will manage the missing patches to be up-to-date > > with latest jdk14 (v0.9.1.3 ie 2 patches) and future ones. > > > > What do you think ? > > This approach requires some work from zulu team to publish jdk8 patches > > that I will review and I need a jdk8u sponsor to endorse, follow & push > the > > patch train or the all-in-one patch integration. > > > > Cheers, > > Laurent > > > > Is this Zulu public? Does it use OpenJDK bug IDs for the changesets? > Zulu code is available on demand, no public repository I know. I know they backported patches 1 by 1... but I only reviewed few snapshots. Nevermind. > As I said before, my preferred method is the backport of changesets > corresponding to individual OpenJDK bug IDs, so we have a clear idea of > what issues are now fixed in 8u. > Ok, I will setup a dedicated github repo to gather all unshuffled patches and write a script to import all of them in order on jdk8u/jdk repo. I estimate this work will be 1 month long (spare time only). Thanks for any feedback, Laurent From andrey at azul.com Thu Sep 19 17:31:34 2019 From: andrey at azul.com (Andrey Petushkov) Date: Thu, 19 Sep 2019 10:31:34 -0700 Subject: Backport proposal of the Marlin renderer in OpenJDK8 In-Reply-To: References: <7539DA05-ACC0-4BB2-8ED5-BC2F32F99ABE@azul.com> <4EBE26E4-7BFF-44E3-AF11-18466AE0B691@azul.com> <93327ecf-bd13-802f-6d6c-eb51f185a3ed@redhat.com> Message-ID: <1C24CDFC-B2D2-4262-9F18-9CA1078542CF@azul.com> Dear Laurent, unfortunately Azul engineers and especially Andrew Brygin was overwhelmed by other work last days, e.g. like getting Java 13 builds out of the door. so if you can afford waiting a few more days please give him chance to finish the patches Andrey 19 ???????? 2019 ?. 10:09:08 GMT-07:00, "Laurent Bourg?s" ?????: >Hi Andrew JH, > >As I have no more news from Azul, I will start redoing all the proper >backport. > >I identified ~ 25 bug ids and the corresponding hg changeset ids in >latest >jdk repo. > >Le mar. 17 sept. 2019 ? 20:53, Andrew John Hughes > a >?crit : > >> >> >> On 12/09/2019 20:54, Laurent Bourg?s wrote: >> > Hi Andrew B (& other Andrew in this thread), >> > >> > I have an idea that could satisfy both approaches: >> > - As the azul team backported already jdk9+ patches into their >openjdk8 / >> > zulu repository, it implies jdk8u patches are ready for integration >and I >> > already reviewed the code: zulu could be considered as both an >incubator >> > that proved Marlin works on jdk8 in production (as I did on my >github). >> > >> > Two solutions: >> > - extract & apply all zulu-ready patches in order in jdk8u-dev >> > - extract one big patch (from zulu) and apply it on jdk8u-dev >> > I do not see any reason to use another incubator repository... >> > >> > I can review all individual patches or the all-in-one and we are >all >> done, >> > up to the last patch backported in zulu 8 (version 0.9.1.1 merged >in dec >> > 2018 according to me). >> > >> > Moreover I already maintain a github branch for the Marlin / >openjdk (8): >> > https://github.com/bourgesl/marlin-renderer/tree/openjdk?files=1 >> > It is my reference to easily compare with any jdk8 codebase. >> > >> > From this first step, I will manage the missing patches to be >up-to-date >> > with latest jdk14 (v0.9.1.3 ie 2 patches) and future ones. >> > >> > What do you think ? >> > This approach requires some work from zulu team to publish jdk8 >patches >> > that I will review and I need a jdk8u sponsor to endorse, follow & >push >> the >> > patch train or the all-in-one patch integration. >> > >> > Cheers, >> > Laurent >> > >> >> Is this Zulu public? Does it use OpenJDK bug IDs for the changesets? >> > >Zulu code is available on demand, no public repository I know. I know >they >backported patches 1 by 1... but I only reviewed few snapshots. >Nevermind. > > >> As I said before, my preferred method is the backport of changesets >> corresponding to individual OpenJDK bug IDs, so we have a clear idea >of >> what issues are now fixed in 8u. >> > >Ok, I will setup a dedicated github repo to gather all unshuffled >patches >and write a script to import all of them in order on jdk8u/jdk repo. > >I estimate this work will be 1 month long (spare time only). > >Thanks for any feedback, >Laurent From bourges.laurent at gmail.com Thu Sep 19 18:47:38 2019 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 19 Sep 2019 20:47:38 +0200 Subject: Backport proposal of the Marlin renderer in OpenJDK8 In-Reply-To: <1C24CDFC-B2D2-4262-9F18-9CA1078542CF@azul.com> References: <7539DA05-ACC0-4BB2-8ED5-BC2F32F99ABE@azul.com> <4EBE26E4-7BFF-44E3-AF11-18466AE0B691@azul.com> <93327ecf-bd13-802f-6d6c-eb51f185a3ed@redhat.com> <1C24CDFC-B2D2-4262-9F18-9CA1078542CF@azul.com> Message-ID: Hi, Le jeu. 19 sept. 2019 ? 19:31, Andrey Petushkov a ?crit : > Dear Laurent, > > unfortunately Azul engineers and especially Andrew Brygin was overwhelmed > by other work last days, e.g. like getting Java 13 builds out of the door. > so if you can afford waiting a few more days please give him chance to > finish the patches > Sorry, I understand. I was not aware of such plan, please just say it in the future, if you need time. Of course, I have time but I will start preparing the job. Cheers, Laurent > 19 ???????? 2019 ?. 10:09:08 GMT-07:00, "Laurent Bourg?s" < > bourges.laurent at gmail.com> ?????: >> >> Hi Andrew JH, >> >> As I have no more news from Azul, I will start redoing all the proper >> backport. >> >> I identified ~ 25 bug ids and the corresponding hg changeset ids in latest >> jdk repo. >> >> Le mar. 17 sept. 2019 ? 20:53, Andrew John Hughes a >> ?crit : >> >> >>> >>> On 12/09/2019 20:54, Laurent Bourg?s wrote: >>> >>>> Hi Andrew B (& other Andrew in this thread), >>>> >>>> I have an idea that could satisfy both approaches: >>>> - As the azul team backported already jdk9+ patches into their openjdk8 / >>>> zulu repository, it implies jdk8u patches are ready for integration and I >>>> already reviewed the code: zulu could be considered as both an incubator >>>> that proved Marlin works on jdk8 in production (as I did on my github). >>>> >>>> Two solutions: >>>> - extract & apply all zulu-ready patches in order in jdk8u-dev >>>> - extract one big patch (from zulu) and apply it on jdk8u-dev >>>> I do not see any reason to use another incubator repository... >>>> >>>> I can review all individual patches or the all-in-one and we are all >>>> >>> done, >>> >>>> up to the last patch backported in zulu 8 (version 0.9.1.1 merged in dec >>>> 2018 according to me). >>>> >>>> Moreover I already maintain a github branch for the Marlin / openjdk (8): >>>> https://github.com/bourgesl/marlin-renderer/tree/openjdk?files=1 >>>> It is my reference to easily compare with any jdk8 codebase. >>>> >>>> From this first step, I will manage the missing patches to be up-to-date >>>> with latest jdk14 (v0.9.1.3 ie 2 patches) and future ones. >>>> >>>> What do you think ? >>>> This approach requires some work from zulu team to publish jdk8 patches >>>> that I will review and I need a jdk8u sponsor to endorse, follow & push >>>> >>> the >>> >>>> patch train or the all-in-one patch integration. >>>> >>>> Cheers, >>>> Laurent >>>> >>>> >>> Is this Zulu public? Does it use OpenJDK bug IDs for the changesets? >>> >>> >> Zulu code is available on demand, no public repository I know. I know they >> backported patches 1 by 1... but I only reviewed few snapshots. >> Nevermind. >> >> >> As I said before, my preferred method is the backport of changesets >>> corresponding to individual OpenJDK bug IDs, so we have a clear idea of >>> what issues are now fixed in 8u. >>> >>> >> Ok, I will setup a dedicated github repo to gather all unshuffled patches >> and write a script to import all of them in order on jdk8u/jdk repo. >> >> I estimate this work will be 1 month long (spare time only). >> >> Thanks for any feedback, >> Laurent >> >> From abrygin at azul.com Thu Sep 19 19:17:04 2019 From: abrygin at azul.com (Andrew Brygin) Date: Thu, 19 Sep 2019 19:17:04 +0000 Subject: Backport proposal of the Marlin renderer in OpenJDK8 In-Reply-To: References: <7539DA05-ACC0-4BB2-8ED5-BC2F32F99ABE@azul.com> <4EBE26E4-7BFF-44E3-AF11-18466AE0B691@azul.com> <93327ecf-bd13-802f-6d6c-eb51f185a3ed@redhat.com> <1C24CDFC-B2D2-4262-9F18-9CA1078542CF@azul.com> Message-ID: Hello Laurent, I am sorry for the delay. I have applied Marlin patches from Zulu 8 repo to jdk8u-dev, and generated webrevs. There are 20 patches related to Marlin integration: 01 8143849: Integrate Marlin renderer per JEP 265 02 8145055: Marlin renderer causes unaligned write accesses 03 8144630: Use PrivilegedAction to create Thread in Marlin RendererStats 04 8144446: Automate the Marlin crash test 05 8144445: Maximum size checking in Marlin ArrayCache utility methods is not optimal 06 8144526: Remove Marlin logging use of deleted internal API 07 8144654: Improve Marlin logging 08 8144718: Pisces / Marlin Strokers may generate invalid curves with huge coordinates and round joins 09 8149338: JVM Crash caused by Marlin renderer not handling NaN coordinates 10 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering 11 8144938: Handle properly coordinate overflow in Marlin Renderer 12 8159093: Fix coding conventions in Marlin renderer 13 8159638: Improve array caches and renderer stats in Marlin renderer 14 8180055: Upgrade the Marlin renderer in Java2D 15 8191814: Marlin rasterizer spends time computing geometry for stroked segments that do not intersect the clip 16 8198885: upgrade Marlin (java2d) to 0.9.1 17 8200526: Test sun/java2d/marlin/ClipShapeTest.java times out 18 8202580: Dashed BasicStroke randomly painted incorrectly, may freeze application 19 8210335: Clipping problems with complex affine transforms: negative scaling factors or small scaling factors 20 8180055: Upgrade the Marlin renderer in Java2D (update service list) Webrevs are available here: http://cr.openjdk.java.net/~bae/marlin/webrevs/ Just in case, patches are available here, cleanly applicable to current state of jdk8u-dev: http://cr.openjdk.java.net/~bae/marlin/ Thanks, Andrew > On Sep 19, 2019, at 9:47 PM, Laurent Bourg?s wrote: > > Hi, > > Le jeu. 19 sept. 2019 ? 19:31, Andrey Petushkov a ?crit : > Dear Laurent, > > unfortunately Azul engineers and especially Andrew Brygin was overwhelmed by other work last days, e.g. like getting Java 13 builds out of the door. > so if you can afford waiting a few more days please give him chance to finish the patches > > Sorry, I understand. > I was not aware of such plan, please just say it in the future, if you need time. > > Of course, I have time but I will start preparing the job. > > Cheers, > Laurent > > > 19 ???????? 2019 ?. 10:09:08 GMT-07:00, "Laurent Bourg?s" ?????: > Hi Andrew JH, > > As I have no more news from Azul, I will start redoing all the proper > backport. > > I identified ~ 25 bug ids and the corresponding hg changeset ids in latest > jdk repo. > > Le mar. 17 sept. 2019 ? 20:53, Andrew John Hughes a > ?crit : > > > > On 12/09/2019 20:54, Laurent Bourg?s wrote: > Hi Andrew B (& other Andrew in this thread), > > I have an idea that could satisfy both approaches: > - As the azul team backported already jdk9+ patches into their openjdk8 / > zulu repository, it implies jdk8u patches are ready for integration and I > already reviewed the code: zulu could be considered as both an incubator > that proved Marlin works on jdk8 in production (as I did on my github). > > Two solutions: > - extract & apply all zulu-ready patches in order in jdk8u-dev > - extract one big patch (from zulu) and apply it on jdk8u-dev > I do not see any reason to use another incubator repository... > > I can review all individual patches or the all-in-one and we are all > done, > up to the last patch backported in zulu 8 (version 0.9.1.1 merged in dec > 2018 according to me). > > Moreover I already maintain a github branch for the Marlin / openjdk (8): > https://github.com/bourgesl/marlin-renderer/tree/openjdk?files=1 > It is my reference to easily compare with any jdk8 codebase. > > From this first step, I will manage the missing patches to be up-to-date > with latest jdk14 (v0.9.1.3 ie 2 patches) and future ones. > > What do you think ? > This approach requires some work from zulu team to publish jdk8 patches > that I will review and I need a jdk8u sponsor to endorse, follow & push > the > patch train or the all-in-one patch integration. > > Cheers, > Laurent > > > Is this Zulu public? Does it use OpenJDK bug IDs for the changesets? > > > Zulu code is available on demand, no public repository I know. I know they > backported patches 1 by 1... but I only reviewed few snapshots. > Nevermind. > > > As I said before, my preferred method is the backport of changesets > corresponding to individual OpenJDK bug IDs, so we have a clear idea of > what issues are now fixed in 8u. > > > Ok, I will setup a dedicated github repo to gather all unshuffled patches > and write a script to import all of them in order on jdk8u/jdk repo. > > I estimate this work will be 1 month long (spare time only). > > Thanks for any feedback, > Laurent From bourges.laurent at gmail.com Thu Sep 19 20:09:41 2019 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 19 Sep 2019 22:09:41 +0200 Subject: Backport proposal of the Marlin renderer in OpenJDK8 In-Reply-To: References: <7539DA05-ACC0-4BB2-8ED5-BC2F32F99ABE@azul.com> <4EBE26E4-7BFF-44E3-AF11-18466AE0B691@azul.com> <93327ecf-bd13-802f-6d6c-eb51f185a3ed@redhat.com> <1C24CDFC-B2D2-4262-9F18-9CA1078542CF@azul.com> Message-ID: Hi Andrew B, It is a wonderful work, thanks ! I will carefully check the patchs, review changes and identify which are missing (most recent Marlin changes in 2019): it will take some time. I will also apply them and compare with my latest Marlin code... JDK8 maintainers (Andrew JH) , what do you think of this workflow ? Thank you so much, I did not know you were preparing it, Laurent Le jeu. 19 sept. 2019 ? 21:17, Andrew Brygin a ?crit : > Hello Laurent, > > I am sorry for the delay. > > I have applied Marlin patches from Zulu 8 repo to jdk8u-dev, > and generated webrevs. > > There are 20 patches related to Marlin integration: > > 01 8143849: Integrate Marlin renderer per JEP 265 > 02 8145055: Marlin renderer causes unaligned write accesses > 03 8144630: Use PrivilegedAction to create Thread in Marlin RendererStats > 04 8144446: Automate the Marlin crash test > 05 8144445: Maximum size checking in Marlin ArrayCache utility methods is > not optimal > 06 8144526: Remove Marlin logging use of deleted internal API > 07 8144654: Improve Marlin logging > 08 8144718: Pisces / Marlin Strokers may generate invalid curves with huge > coordinates and round joins > 09 8149338: JVM Crash caused by Marlin renderer not handling NaN > coordinates > 10 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering > 11 8144938: Handle properly coordinate overflow in Marlin Renderer > 12 8159093: Fix coding conventions in Marlin renderer > 13 8159638: Improve array caches and renderer stats in Marlin renderer > 14 8180055: Upgrade the Marlin renderer in Java2D > 15 8191814: Marlin rasterizer spends time computing geometry for stroked > segments that do not intersect the clip > 16 8198885: upgrade Marlin (java2d) to 0.9.1 > 17 8200526: Test sun/java2d/marlin/ClipShapeTest.java times out > 18 8202580: Dashed BasicStroke randomly painted incorrectly, may freeze > application > 19 8210335: Clipping problems with complex affine transforms: negative > scaling factors or small scaling factors > 20 8180055: Upgrade the Marlin renderer in Java2D (update service list) > > Webrevs are available here: > > http://cr.openjdk.java.net/~bae/marlin/webrevs/ > > Just in case, patches are available here, cleanly applicable to > current state of jdk8u-dev: > > http://cr.openjdk.java.net/~bae/marlin/ > > Thanks, > Andrew > > > On Sep 19, 2019, at 9:47 PM, Laurent Bourg?s > wrote: > > > > Hi, > > > > Le jeu. 19 sept. 2019 ? 19:31, Andrey Petushkov a > ?crit : > > Dear Laurent, > > > > unfortunately Azul engineers and especially Andrew Brygin was > overwhelmed by other work last days, e.g. like getting Java 13 builds out > of the door. > > so if you can afford waiting a few more days please give him chance to > finish the patches > > > > Sorry, I understand. > > I was not aware of such plan, please just say it in the future, if you > need time. > > > > Of course, I have time but I will start preparing the job. > > > > Cheers, > > Laurent > > > > > > 19 ???????? 2019 ?. 10:09:08 GMT-07:00, "Laurent Bourg?s" < > bourges.laurent at gmail.com> ?????: > > Hi Andrew JH, > > > > As I have no more news from Azul, I will start redoing all the proper > > backport. > > > > I identified ~ 25 bug ids and the corresponding hg changeset ids in > latest > > jdk repo. > > > > Le mar. 17 sept. 2019 ? 20:53, Andrew John Hughes > a > > ?crit : > > > > > > > > On 12/09/2019 20:54, Laurent Bourg?s wrote: > > Hi Andrew B (& other Andrew in this thread), > > > > I have an idea that could satisfy both approaches: > > - As the azul team backported already jdk9+ patches into their openjdk8 > / > > zulu repository, it implies jdk8u patches are ready for integration and > I > > already reviewed the code: zulu could be considered as both an incubator > > that proved Marlin works on jdk8 in production (as I did on my github). > > > > Two solutions: > > - extract & apply all zulu-ready patches in order in jdk8u-dev > > - extract one big patch (from zulu) and apply it on jdk8u-dev > > I do not see any reason to use another incubator repository... > > > > I can review all individual patches or the all-in-one and we are all > > done, > > up to the last patch backported in zulu 8 (version 0.9.1.1 merged in dec > > 2018 according to me). > > > > Moreover I already maintain a github branch for the Marlin / openjdk > (8): > > https://github.com/bourgesl/marlin-renderer/tree/openjdk?files=1 > > It is my reference to easily compare with any jdk8 codebase. > > > > From this first step, I will manage the missing patches to be up-to-date > > with latest jdk14 (v0.9.1.3 ie 2 patches) and future ones. > > > > What do you think ? > > This approach requires some work from zulu team to publish jdk8 patches > > that I will review and I need a jdk8u sponsor to endorse, follow & push > > the > > patch train or the all-in-one patch integration. > > > > Cheers, > > Laurent > > > > > > Is this Zulu public? Does it use OpenJDK bug IDs for the changesets? > > > > > > Zulu code is available on demand, no public repository I know. I know > they > > backported patches 1 by 1... but I only reviewed few snapshots. > > Nevermind. > > > > > > As I said before, my preferred method is the backport of changesets > > corresponding to individual OpenJDK bug IDs, so we have a clear idea of > > what issues are now fixed in 8u. > > > > > > Ok, I will setup a dedicated github repo to gather all unshuffled patches > > and write a script to import all of them in order on jdk8u/jdk repo. > > > > I estimate this work will be 1 month long (spare time only). > > > > Thanks for any feedback, > > Laurent > > From abrygin at azul.com Fri Sep 20 08:41:03 2019 From: abrygin at azul.com (Andrew Brygin) Date: Fri, 20 Sep 2019 08:41:03 +0000 Subject: Backport proposal of the Marlin renderer in OpenJDK8 In-Reply-To: References: <7539DA05-ACC0-4BB2-8ED5-BC2F32F99ABE@azul.com> <4EBE26E4-7BFF-44E3-AF11-18466AE0B691@azul.com> <93327ecf-bd13-802f-6d6c-eb51f185a3ed@redhat.com> <1C24CDFC-B2D2-4262-9F18-9CA1078542CF@azul.com> Message-ID: Hi Laurent, > On Sep 19, 2019, at 11:09 PM, Laurent Bourg?s wrote: > > Hi Andrew B, > > It is a wonderful work, thanks ! > > I will carefully check the patchs, review changes and identify which are missing (most recent Marlin changes in 2019): it will take some time. > > I will also apply them and compare with my latest Marlin code? Thanks, it will be quite useful. > > JDK8 maintainers (Andrew JH) , what do you think of this workflow ? > > On Sep 17, 2019, at 9:52 PM, Andrew John Hughes wrote: > >Is this Zulu public? Does it use OpenJDK bug IDs for the changesets? All Marlin-related changes in Zulu were made under OpenJDK bugIDs (actually all of them are just backports from jdk9 and jdk10). > > As I said before, my preferred method is the backport of changesets > corresponding to individual OpenJDK bug IDs, so we have a clear idea of > what issues are now fixed in 8u. This approach seems to be absolutely reasonable. Thanks, Andrew > Le jeu. 19 sept. 2019 ? 21:17, Andrew Brygin a ?crit : > Hello Laurent, > > I am sorry for the delay. > > I have applied Marlin patches from Zulu 8 repo to jdk8u-dev, > and generated webrevs. > > There are 20 patches related to Marlin integration: > > 01 8143849: Integrate Marlin renderer per JEP 265 > 02 8145055: Marlin renderer causes unaligned write accesses > 03 8144630: Use PrivilegedAction to create Thread in Marlin RendererStats > 04 8144446: Automate the Marlin crash test > 05 8144445: Maximum size checking in Marlin ArrayCache utility methods is not optimal > 06 8144526: Remove Marlin logging use of deleted internal API > 07 8144654: Improve Marlin logging > 08 8144718: Pisces / Marlin Strokers may generate invalid curves with huge coordinates and round joins > 09 8149338: JVM Crash caused by Marlin renderer not handling NaN coordinates > 10 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering > 11 8144938: Handle properly coordinate overflow in Marlin Renderer > 12 8159093: Fix coding conventions in Marlin renderer > 13 8159638: Improve array caches and renderer stats in Marlin renderer > 14 8180055: Upgrade the Marlin renderer in Java2D > 15 8191814: Marlin rasterizer spends time computing geometry for stroked segments that do not intersect the clip > 16 8198885: upgrade Marlin (java2d) to 0.9.1 > 17 8200526: Test sun/java2d/marlin/ClipShapeTest.java times out > 18 8202580: Dashed BasicStroke randomly painted incorrectly, may freeze application > 19 8210335: Clipping problems with complex affine transforms: negative scaling factors or small scaling factors > 20 8180055: Upgrade the Marlin renderer in Java2D (update service list) > > Webrevs are available here: > > http://cr.openjdk.java.net/~bae/marlin/webrevs/ > > Just in case, patches are available here, cleanly applicable to > current state of jdk8u-dev: > > http://cr.openjdk.java.net/~bae/marlin/ > > Thanks, > Andrew > > > On Sep 19, 2019, at 9:47 PM, Laurent Bourg?s wrote: > > > > Hi, > > > > Le jeu. 19 sept. 2019 ? 19:31, Andrey Petushkov a ?crit : > > Dear Laurent, > > > > unfortunately Azul engineers and especially Andrew Brygin was overwhelmed by other work last days, e.g. like getting Java 13 builds out of the door. > > so if you can afford waiting a few more days please give him chance to finish the patches > > > > Sorry, I understand. > > I was not aware of such plan, please just say it in the future, if you need time. > > > > Of course, I have time but I will start preparing the job. > > > > Cheers, > > Laurent > > > > > > 19 ???????? 2019 ?. 10:09:08 GMT-07:00, "Laurent Bourg?s" ?????: > > Hi Andrew JH, > > > > As I have no more news from Azul, I will start redoing all the proper > > backport. > > > > I identified ~ 25 bug ids and the corresponding hg changeset ids in latest > > jdk repo. > > > > Le mar. 17 sept. 2019 ? 20:53, Andrew John Hughes a > > ?crit : > > > > > > > > On 12/09/2019 20:54, Laurent Bourg?s wrote: > > Hi Andrew B (& other Andrew in this thread), > > > > I have an idea that could satisfy both approaches: > > - As the azul team backported already jdk9+ patches into their openjdk8 / > > zulu repository, it implies jdk8u patches are ready for integration and I > > already reviewed the code: zulu could be considered as both an incubator > > that proved Marlin works on jdk8 in production (as I did on my github). > > > > Two solutions: > > - extract & apply all zulu-ready patches in order in jdk8u-dev > > - extract one big patch (from zulu) and apply it on jdk8u-dev > > I do not see any reason to use another incubator repository... > > > > I can review all individual patches or the all-in-one and we are all > > done, > > up to the last patch backported in zulu 8 (version 0.9.1.1 merged in dec > > 2018 according to me). > > > > Moreover I already maintain a github branch for the Marlin / openjdk (8): > > https://github.com/bourgesl/marlin-renderer/tree/openjdk?files=1 > > It is my reference to easily compare with any jdk8 codebase. > > > > From this first step, I will manage the missing patches to be up-to-date > > with latest jdk14 (v0.9.1.3 ie 2 patches) and future ones. > > > > What do you think ? > > This approach requires some work from zulu team to publish jdk8 patches > > that I will review and I need a jdk8u sponsor to endorse, follow & push > > the > > patch train or the all-in-one patch integration. > > > > Cheers, > > Laurent > > > > > > Is this Zulu public? Does it use OpenJDK bug IDs for the changesets? > > > > > > Zulu code is available on demand, no public repository I know. I know they > > backported patches 1 by 1... but I only reviewed few snapshots. > > Nevermind. > > > > > > As I said before, my preferred method is the backport of changesets > > corresponding to individual OpenJDK bug IDs, so we have a clear idea of > > what issues are now fixed in 8u. > > > > > > Ok, I will setup a dedicated github repo to gather all unshuffled patches > > and write a script to import all of them in order on jdk8u/jdk repo. > > > > I estimate this work will be 1 month long (spare time only). > > > > Thanks for any feedback, > > Laurent > From kshefov at azul.com Fri Sep 20 09:25:50 2019 From: kshefov at azul.com (Konstantin Shefov) Date: Fri, 20 Sep 2019 09:25:50 +0000 Subject: Backport vmTestbase tests to jdk8u-dev? In-Reply-To: <1568829532868.82475@amazon.com> References: <9ba7e7af9a1645c4831610327c96f22b@azul.com> <51653b0b3223448bbe2f9186d11556af@azul.com> <1568829532868.82475@amazon.com> Message-ID: <0CFA2C19-FD39-4DDF-99E8-FB5B43936AFE@azul.com> Hi, We will use your new patches to run tests and merge my changes with yours for those tests that will not work. BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. I see your webrevs do not contain native part build scripts for now. We have to address this problem so the scripts should work for older GCC versions also. Regards Konstantin From: "Liu, Xin" Date: Wednesday, 18 September 2019 at 20:59 To: Konstantin Shefov , "jdk8u-dev at openjdk.java.net" Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, thank you for updating. We care about x86_64 and aarch64 as well. You ran more tests than us. we never run all vmTestbase. Previously, I used a ProblemList.txt file to screen Problem and move on. Do you plan to fix all problems before we check in? Back to refactor, I have filed a JBS issues. https://bugs.openjdk.java.net/browse/JDK-8231089 In the meanwhile, I start splitting the commits to individual hg changesets. https://cr.openjdk.java.net/~xliu/8231089/ 1. base -> copy code from tag jdk-14+14 intact commit for vmTestbase and testlib 2. make apiChanges for ProcessUtils and Unsafe Could you review it? 3. ClassFileInstaller needs /testlibrary it's because ClassFileInstaller is in /test/testlibrary. I use this script to install @library /testlibrary for all tests. out=$(grep "ClassFileInstaller" -R vmTestbase | awk '{print $1}') for i in $out; do f=${i%\:} gsed -i 's/@library \/vmTestbase/&\n * \/testlibrary/' $f done What do you think that this approach? If I got something wrong, we can update the webtrev with yours. thanks, --lx ________________________________ From: Konstantin Shefov Sent: Wednesday, September 18, 2019 4:56 PM To: Liu, Xin; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi We ran the tests against x86_64 Ubuntu Linux and there are just the same failed tests as it was with Arm64 Ubuntu Linux plus 2 more tests: vmTestbase/gc/lock/jni/jnilock002/TestDescription.java vmTestbase/nsk/jdb/set/set001/set001.java Konstantin From: Konstantin Shefov Sent: Wednesday, September 11, 2019 10:53 AM To: 'Liu, Xin' ; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, LX Answering to your e-mail, as for what we modified in [3]: 1. API changes (Process, Unsafe), Xloggc option, that were not in your patches; 2. In a file hotspot/test/JtregNativeHotspot.gmk we changed ?-lpthread? option to ?-pthread? to prevent compilation error. I agree that there should be a series of patches to track file changes. As for investigation of failures: do you have the same? We ran against Arm64 platform, but we can try against x86-64 too. Konstantin From: Liu, Xin > Sent: Monday, September 9, 2019 11:04 PM To: Konstantin Shefov >; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, We are glad to work with you to get vmTestbase landed into jdk8u. Our original intent is get design reviewed by the jdk8u maintainer. After then, we can proceed to refactor it. We can work together to refactor it. we plan to do it anyway. Back to the webrev you send. What did you modify in [3]? Ideally, we can should have a series of patches. The first one should be intact vmTestbase code from the tip of JDK. All we changes should come after it and be reviewed by this mail-list. In addition to refactoring, we can also offer help to figure out those failed cases. What do you think? Thanks, --lx From: Konstantin Shefov > Date: Friday, September 6, 2019 at 12:55 PM To: "jdk8u-dev at openjdk.java.net" > Cc: "Liu, Xin" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, We at Azul think it is a good idea to backport vmTestbase tests to OpenJDK 8. We have used patches you suggested, done some refactoring to enable more tests to work with JDK 8. We have run all 3550 tests from ?vmTestbase? folder against Zulu 8 at ARM64 platform: 1. 3371 tests PASS (see [1]); 2. 179 tests FAIL (see [2]): reasons are being investigated. Patches we have used (contain our refactoring): 1. Hotspot folder [3] 2. Main folder [4] We plan to investigate causes of those 177 failures, purify unused code from hotspot/test/test/lib/jdk, and run the tests against different platforms. We also compared vmTestbase from JDK 11 with that from JDK 13, we found out: 1. 332 test have been removed in JDK 13; 2. Only 2 test have been added in JDK 13; 3. Tests that remained were modified, but these modifications mostly are copyright years, or output format, or API changes. From the above results we can tell that vmTestbase does not grow. It looks like that tests are been removed from there or transferred somewhere else. [1] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/passed_tests.html [2] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/failed_tests.html [3] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_hotspot.patch [4] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_root.patch Regards, --Konstantin From xxinliu at amazon.com Fri Sep 20 17:35:05 2019 From: xxinliu at amazon.com (Liu, Xin) Date: Fri, 20 Sep 2019 17:35:05 +0000 Subject: Backport vmTestbase tests to jdk8u-dev? In-Reply-To: <0CFA2C19-FD39-4DDF-99E8-FB5B43936AFE@azul.com> References: <9ba7e7af9a1645c4831610327c96f22b@azul.com> <51653b0b3223448bbe2f9186d11556af@azul.com> <1568829532868.82475@amazon.com> <0CFA2C19-FD39-4DDF-99E8-FB5B43936AFE@azul.com> Message-ID: <48213D1C-7CE4-41E9-B799-1E8A199846A0@amazon.com> Konstantin, I am refactoring makefiles. I plan to upload this webrev today. I found that you have solved almost all problems. I can help to troubleshoot the remaining tests. >BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. Could you give me an example tests for this? Thanks, --lx From: Konstantin Shefov Date: Friday, September 20, 2019 at 2:26 AM To: "Liu, Xin" , "jdk8u-dev at openjdk.java.net" Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, We will use your new patches to run tests and merge my changes with yours for those tests that will not work. BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. I see your webrevs do not contain native part build scripts for now. We have to address this problem so the scripts should work for older GCC versions also. Regards Konstantin From: "Liu, Xin" Date: Wednesday, 18 September 2019 at 20:59 To: Konstantin Shefov , "jdk8u-dev at openjdk.java.net" Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, thank you for updating. We care about x86_64 and aarch64 as well. You ran more tests than us. we never run all vmTestbase. Previously, I used a ProblemList.txt file to screen Problem and move on. Do you plan to fix all problems before we check in? Back to refactor, I have filed a JBS issues. https://bugs.openjdk.java.net/browse/JDK-8231089 In the meanwhile, I start splitting the commits to individual hg changesets. https://cr.openjdk.java.net/~xliu/8231089/ 1. base -> copy code from tag jdk-14+14 intact commit for vmTestbase and testlib 2. make apiChanges for ProcessUtils and Unsafe Could you review it? 3. ClassFileInstaller needs /testlibrary it's because ClassFileInstaller is in /test/testlibrary. I use this script to install @library /testlibrary for all tests. out=$(grep "ClassFileInstaller" -R vmTestbase | awk '{print $1}') for i in $out; do f=${i%\:} gsed -i 's/@library \/vmTestbase/&\n * \/testlibrary/' $f done What do you think that this approach? If I got something wrong, we can update the webtrev with yours. thanks, --lx ________________________________ From: Konstantin Shefov Sent: Wednesday, September 18, 2019 4:56 PM To: Liu, Xin; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi We ran the tests against x86_64 Ubuntu Linux and there are just the same failed tests as it was with Arm64 Ubuntu Linux plus 2 more tests: vmTestbase/gc/lock/jni/jnilock002/TestDescription.java vmTestbase/nsk/jdb/set/set001/set001.java Konstantin From: Konstantin Shefov Sent: Wednesday, September 11, 2019 10:53 AM To: 'Liu, Xin' ; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, LX Answering to your e-mail, as for what we modified in [3]: 1. API changes (Process, Unsafe), Xloggc option, that were not in your patches; 2. In a file hotspot/test/JtregNativeHotspot.gmk we changed ?-lpthread? option to ?-pthread? to prevent compilation error. I agree that there should be a series of patches to track file changes. As for investigation of failures: do you have the same? We ran against Arm64 platform, but we can try against x86-64 too. Konstantin From: Liu, Xin > Sent: Monday, September 9, 2019 11:04 PM To: Konstantin Shefov >; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, We are glad to work with you to get vmTestbase landed into jdk8u. Our original intent is get design reviewed by the jdk8u maintainer. After then, we can proceed to refactor it. We can work together to refactor it. we plan to do it anyway. Back to the webrev you send. What did you modify in [3]? Ideally, we can should have a series of patches. The first one should be intact vmTestbase code from the tip of JDK. All we changes should come after it and be reviewed by this mail-list. In addition to refactoring, we can also offer help to figure out those failed cases. What do you think? Thanks, --lx From: Konstantin Shefov > Date: Friday, September 6, 2019 at 12:55 PM To: "jdk8u-dev at openjdk.java.net" > Cc: "Liu, Xin" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, We at Azul think it is a good idea to backport vmTestbase tests to OpenJDK 8. We have used patches you suggested, done some refactoring to enable more tests to work with JDK 8. We have run all 3550 tests from ?vmTestbase? folder against Zulu 8 at ARM64 platform: 1. 3371 tests PASS (see [1]); 2. 179 tests FAIL (see [2]): reasons are being investigated. Patches we have used (contain our refactoring): 1. Hotspot folder [3] 2. Main folder [4] We plan to investigate causes of those 177 failures, purify unused code from hotspot/test/test/lib/jdk, and run the tests against different platforms. We also compared vmTestbase from JDK 11 with that from JDK 13, we found out: 1. 332 test have been removed in JDK 13; 2. Only 2 test have been added in JDK 13; 3. Tests that remained were modified, but these modifications mostly are copyright years, or output format, or API changes. From the above results we can tell that vmTestbase does not grow. It looks like that tests are been removed from there or transferred somewhere else. [1] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/passed_tests.html [2] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/failed_tests.html [3] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_hotspot.patch [4] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_root.patch Regards, --Konstantin From kshefov at azul.com Fri Sep 20 18:00:28 2019 From: kshefov at azul.com (Konstantin Shefov) Date: Fri, 20 Sep 2019 18:00:28 +0000 Subject: Backport vmTestbase tests to jdk8u-dev? In-Reply-To: <48213D1C-7CE4-41E9-B799-1E8A199846A0@amazon.com> References: <9ba7e7af9a1645c4831610327c96f22b@azul.com> <51653b0b3223448bbe2f9186d11556af@azul.com> <1568829532868.82475@amazon.com> <0CFA2C19-FD39-4DDF-99E8-FB5B43936AFE@azul.com> <48213D1C-7CE4-41E9-B799-1E8A199846A0@amazon.com> Message-ID: <104bc421591046c8a4e7c2edcb962d81@azul.com> Hi, Liu Xin > I am refactoring makefiles. I plan to upload this webrev today. Fine! We will try to compile with our toolchains. >> BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. > Could you give me an example tests for this? One example is this https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/ConflictingDefaultsTest.java#L329 And most of vmTestbase/vm/runtime/defmeth tests seem to test JVM spec in some way. See here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L50 and here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L134 Konstantin From: Liu, Xin Sent: Friday, September 20, 2019 8:35 PM To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Konstantin, I am refactoring makefiles. I plan to upload this webrev today. I found that you have solved almost all problems. I can help to troubleshoot the remaining tests. >BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. Could you give me an example tests for this? Thanks, --lx From: Konstantin Shefov > Date: Friday, September 20, 2019 at 2:26 AM To: "Liu, Xin" >, "jdk8u-dev at openjdk.java.net" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, We will use your new patches to run tests and merge my changes with yours for those tests that will not work. BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. I see your webrevs do not contain native part build scripts for now. We have to address this problem so the scripts should work for older GCC versions also. Regards Konstantin From: "Liu, Xin" > Date: Wednesday, 18 September 2019 at 20:59 To: Konstantin Shefov >, "jdk8u-dev at openjdk.java.net" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, thank you for updating. We care about x86_64 and aarch64 as well. You ran more tests than us. we never run all vmTestbase. Previously, I used a ProblemList.txt file to screen Problem and move on. Do you plan to fix all problems before we check in? Back to refactor, I have filed a JBS issues. https://bugs.openjdk.java.net/browse/JDK-8231089 In the meanwhile, I start splitting the commits to individual hg changesets. https://cr.openjdk.java.net/~xliu/8231089/ 1. base -> copy code from tag jdk-14+14 intact commit for vmTestbase and testlib 2. make apiChanges for ProcessUtils and Unsafe Could you review it? 3. ClassFileInstaller needs /testlibrary it's because ClassFileInstaller is in /test/testlibrary. I use this script to install @library /testlibrary for all tests. out=$(grep "ClassFileInstaller" -R vmTestbase | awk '{print $1}') for i in $out; do f=${i%\:} gsed -i 's/@library \/vmTestbase/&\n * \/testlibrary/' $f done What do you think that this approach? If I got something wrong, we can update the webtrev with yours. thanks, --lx ________________________________ From: Konstantin Shefov > Sent: Wednesday, September 18, 2019 4:56 PM To: Liu, Xin; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi We ran the tests against x86_64 Ubuntu Linux and there are just the same failed tests as it was with Arm64 Ubuntu Linux plus 2 more tests: vmTestbase/gc/lock/jni/jnilock002/TestDescription.java vmTestbase/nsk/jdb/set/set001/set001.java Konstantin From: Konstantin Shefov Sent: Wednesday, September 11, 2019 10:53 AM To: 'Liu, Xin' >; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, LX Answering to your e-mail, as for what we modified in [3]: 1. API changes (Process, Unsafe), Xloggc option, that were not in your patches; 2. In a file hotspot/test/JtregNativeHotspot.gmk we changed ?-lpthread? option to ?-pthread? to prevent compilation error. I agree that there should be a series of patches to track file changes. As for investigation of failures: do you have the same? We ran against Arm64 platform, but we can try against x86-64 too. Konstantin From: Liu, Xin > Sent: Monday, September 9, 2019 11:04 PM To: Konstantin Shefov >; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, We are glad to work with you to get vmTestbase landed into jdk8u. Our original intent is get design reviewed by the jdk8u maintainer. After then, we can proceed to refactor it. We can work together to refactor it. we plan to do it anyway. Back to the webrev you send. What did you modify in [3]? Ideally, we can should have a series of patches. The first one should be intact vmTestbase code from the tip of JDK. All we changes should come after it and be reviewed by this mail-list. In addition to refactoring, we can also offer help to figure out those failed cases. What do you think? Thanks, --lx From: Konstantin Shefov > Date: Friday, September 6, 2019 at 12:55 PM To: "jdk8u-dev at openjdk.java.net" > Cc: "Liu, Xin" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, We at Azul think it is a good idea to backport vmTestbase tests to OpenJDK 8. We have used patches you suggested, done some refactoring to enable more tests to work with JDK 8. We have run all 3550 tests from ?vmTestbase? folder against Zulu 8 at ARM64 platform: 1. 3371 tests PASS (see [1]); 2. 179 tests FAIL (see [2]): reasons are being investigated. Patches we have used (contain our refactoring): 1. Hotspot folder [3] 2. Main folder [4] We plan to investigate causes of those 177 failures, purify unused code from hotspot/test/test/lib/jdk, and run the tests against different platforms. We also compared vmTestbase from JDK 11 with that from JDK 13, we found out: 1. 332 test have been removed in JDK 13; 2. Only 2 test have been added in JDK 13; 3. Tests that remained were modified, but these modifications mostly are copyright years, or output format, or API changes. From the above results we can tell that vmTestbase does not grow. It looks like that tests are been removed from there or transferred somewhere else. [1] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/passed_tests.html [2] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/failed_tests.html [3] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_hotspot.patch [4] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_root.patch Regards, --Konstantin From xxinliu at amazon.com Fri Sep 20 18:58:12 2019 From: xxinliu at amazon.com (Liu, Xin) Date: Fri, 20 Sep 2019 18:58:12 +0000 Subject: Backport vmTestbase tests to jdk8u-dev? In-Reply-To: <104bc421591046c8a4e7c2edcb962d81@azul.com> References: <9ba7e7af9a1645c4831610327c96f22b@azul.com> <51653b0b3223448bbe2f9186d11556af@azul.com> <1568829532868.82475@amazon.com> <0CFA2C19-FD39-4DDF-99E8-FB5B43936AFE@azul.com> <48213D1C-7CE4-41E9-B799-1E8A199846A0@amazon.com> <104bc421591046c8a4e7c2edcb962d81@azul.com> Message-ID: From: Konstantin Shefov Date: Friday, September 20, 2019 at 11:01 AM To: "Liu, Xin" , "jdk8u-dev at openjdk.java.net" Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, Liu Xin > I am refactoring makefiles. I plan to upload this webrev today. Fine! We will try to compile with our toolchains. Are you aware of this issue? https://gist.github.com/navyxliu/bacd47891b17ac8d33d04708b648b531 for me, it looks that the root cause the building system chooses gcc instead of g++ to compile/link native libraries for tests. I used to work around it using STATIC_STDCXX_FLAGS . but it won?t be portable I guess. https://github.com/navyxliu/corretto-8/commit/f7beb63f4f4dfa31bd0854f228b266a49eefefed >> BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. > Could you give me an example tests for this? One example is this https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/ConflictingDefaultsTest.java#L329 And most of vmTestbase/vm/runtime/defmeth tests seem to test JVM spec in some way. See here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L50 and here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L134 Thanks for head-up! I don?t know this issue before. I think we can put them together in a ProblemList.txt file. Konstantin From: Liu, Xin Sent: Friday, September 20, 2019 8:35 PM To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Konstantin, I am refactoring makefiles. I plan to upload this webrev today. I found that you have solved almost all problems. I can help to troubleshoot the remaining tests. >BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. Could you give me an example tests for this? Thanks, --lx From: Konstantin Shefov > Date: Friday, September 20, 2019 at 2:26 AM To: "Liu, Xin" >, "jdk8u-dev at openjdk.java.net" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, We will use your new patches to run tests and merge my changes with yours for those tests that will not work. BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. I see your webrevs do not contain native part build scripts for now. We have to address this problem so the scripts should work for older GCC versions also. Regards Konstantin From: "Liu, Xin" > Date: Wednesday, 18 September 2019 at 20:59 To: Konstantin Shefov >, "jdk8u-dev at openjdk.java.net" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, thank you for updating. We care about x86_64 and aarch64 as well. You ran more tests than us. we never run all vmTestbase. Previously, I used a ProblemList.txt file to screen Problem and move on. Do you plan to fix all problems before we check in? Back to refactor, I have filed a JBS issues. https://bugs.openjdk.java.net/browse/JDK-8231089 In the meanwhile, I start splitting the commits to individual hg changesets. https://cr.openjdk.java.net/~xliu/8231089/ 1. base -> copy code from tag jdk-14+14 intact commit for vmTestbase and testlib 2. make apiChanges for ProcessUtils and Unsafe Could you review it? 3. ClassFileInstaller needs /testlibrary it's because ClassFileInstaller is in /test/testlibrary. I use this script to install @library /testlibrary for all tests. out=$(grep "ClassFileInstaller" -R vmTestbase | awk '{print $1}') for i in $out; do f=${i%\:} gsed -i 's/@library \/vmTestbase/&\n * \/testlibrary/' $f done What do you think that this approach? If I got something wrong, we can update the webtrev with yours. thanks, --lx ________________________________ From: Konstantin Shefov > Sent: Wednesday, September 18, 2019 4:56 PM To: Liu, Xin; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi We ran the tests against x86_64 Ubuntu Linux and there are just the same failed tests as it was with Arm64 Ubuntu Linux plus 2 more tests: vmTestbase/gc/lock/jni/jnilock002/TestDescription.java vmTestbase/nsk/jdb/set/set001/set001.java Konstantin From: Konstantin Shefov Sent: Wednesday, September 11, 2019 10:53 AM To: 'Liu, Xin' >; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, LX Answering to your e-mail, as for what we modified in [3]: 1. API changes (Process, Unsafe), Xloggc option, that were not in your patches; 2. In a file hotspot/test/JtregNativeHotspot.gmk we changed ?-lpthread? option to ?-pthread? to prevent compilation error. I agree that there should be a series of patches to track file changes. As for investigation of failures: do you have the same? We ran against Arm64 platform, but we can try against x86-64 too. Konstantin From: Liu, Xin > Sent: Monday, September 9, 2019 11:04 PM To: Konstantin Shefov >; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, We are glad to work with you to get vmTestbase landed into jdk8u. Our original intent is get design reviewed by the jdk8u maintainer. After then, we can proceed to refactor it. We can work together to refactor it. we plan to do it anyway. Back to the webrev you send. What did you modify in [3]? Ideally, we can should have a series of patches. The first one should be intact vmTestbase code from the tip of JDK. All we changes should come after it and be reviewed by this mail-list. In addition to refactoring, we can also offer help to figure out those failed cases. What do you think? Thanks, --lx From: Konstantin Shefov > Date: Friday, September 6, 2019 at 12:55 PM To: "jdk8u-dev at openjdk.java.net" > Cc: "Liu, Xin" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, We at Azul think it is a good idea to backport vmTestbase tests to OpenJDK 8. We have used patches you suggested, done some refactoring to enable more tests to work with JDK 8. We have run all 3550 tests from ?vmTestbase? folder against Zulu 8 at ARM64 platform: 1. 3371 tests PASS (see [1]); 2. 179 tests FAIL (see [2]): reasons are being investigated. Patches we have used (contain our refactoring): 1. Hotspot folder [3] 2. Main folder [4] We plan to investigate causes of those 177 failures, purify unused code from hotspot/test/test/lib/jdk, and run the tests against different platforms. We also compared vmTestbase from JDK 11 with that from JDK 13, we found out: 1. 332 test have been removed in JDK 13; 2. Only 2 test have been added in JDK 13; 3. Tests that remained were modified, but these modifications mostly are copyright years, or output format, or API changes. From the above results we can tell that vmTestbase does not grow. It looks like that tests are been removed from there or transferred somewhere else. [1] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/passed_tests.html [2] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/failed_tests.html [3] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_hotspot.patch [4] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_root.patch Regards, --Konstantin From xxinliu at amazon.com Fri Sep 20 20:48:08 2019 From: xxinliu at amazon.com (Liu, Xin) Date: Fri, 20 Sep 2019 20:48:08 +0000 Subject: Backport vmTestbase tests to jdk8u-dev? In-Reply-To: <104bc421591046c8a4e7c2edcb962d81@azul.com> References: <9ba7e7af9a1645c4831610327c96f22b@azul.com> <51653b0b3223448bbe2f9186d11556af@azul.com> <1568829532868.82475@amazon.com> <0CFA2C19-FD39-4DDF-99E8-FB5B43936AFE@azul.com> <48213D1C-7CE4-41E9-B799-1E8A199846A0@amazon.com> <104bc421591046c8a4e7c2edcb962d81@azul.com> Message-ID: Hi, Konstantin, As I promised, here is the refactored webrev for native compilation Hotspot: https://cr.openjdk.java.net/~xliu/8231089/native_libraries/hotspot/webrev/ root: https://cr.openjdk.java.net/~xliu/8231089/native_libraries/root/webrev/ so the new target ?test-image? is added. to fix https://gist.github.com/navyxliu/bacd47891b17ac8d33d04708b648b531, I added ?LDFLAGS_SUFFIX := $$(LIBCXX), ? to TestFilesCompilation.gmk. Thanks, --lx From: Konstantin Shefov Date: Friday, September 20, 2019 at 11:01 AM To: "Liu, Xin" , "jdk8u-dev at openjdk.java.net" Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, Liu Xin > I am refactoring makefiles. I plan to upload this webrev today. Fine! We will try to compile with our toolchains. >> BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. > Could you give me an example tests for this? One example is this https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/ConflictingDefaultsTest.java#L329 And most of vmTestbase/vm/runtime/defmeth tests seem to test JVM spec in some way. See here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L50 and here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L134 Konstantin From: Liu, Xin Sent: Friday, September 20, 2019 8:35 PM To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Konstantin, I am refactoring makefiles. I plan to upload this webrev today. I found that you have solved almost all problems. I can help to troubleshoot the remaining tests. >BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. Could you give me an example tests for this? Thanks, --lx From: Konstantin Shefov > Date: Friday, September 20, 2019 at 2:26 AM To: "Liu, Xin" >, "jdk8u-dev at openjdk.java.net" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, We will use your new patches to run tests and merge my changes with yours for those tests that will not work. BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. I see your webrevs do not contain native part build scripts for now. We have to address this problem so the scripts should work for older GCC versions also. Regards Konstantin From: "Liu, Xin" > Date: Wednesday, 18 September 2019 at 20:59 To: Konstantin Shefov >, "jdk8u-dev at openjdk.java.net" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, thank you for updating. We care about x86_64 and aarch64 as well. You ran more tests than us. we never run all vmTestbase. Previously, I used a ProblemList.txt file to screen Problem and move on. Do you plan to fix all problems before we check in? Back to refactor, I have filed a JBS issues. https://bugs.openjdk.java.net/browse/JDK-8231089 In the meanwhile, I start splitting the commits to individual hg changesets. https://cr.openjdk.java.net/~xliu/8231089/ 1. base -> copy code from tag jdk-14+14 intact commit for vmTestbase and testlib 2. make apiChanges for ProcessUtils and Unsafe Could you review it? 3. ClassFileInstaller needs /testlibrary it's because ClassFileInstaller is in /test/testlibrary. I use this script to install @library /testlibrary for all tests. out=$(grep "ClassFileInstaller" -R vmTestbase | awk '{print $1}') for i in $out; do f=${i%\:} gsed -i 's/@library \/vmTestbase/&\n * \/testlibrary/' $f done What do you think that this approach? If I got something wrong, we can update the webtrev with yours. thanks, --lx ________________________________ From: Konstantin Shefov > Sent: Wednesday, September 18, 2019 4:56 PM To: Liu, Xin; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi We ran the tests against x86_64 Ubuntu Linux and there are just the same failed tests as it was with Arm64 Ubuntu Linux plus 2 more tests: vmTestbase/gc/lock/jni/jnilock002/TestDescription.java vmTestbase/nsk/jdb/set/set001/set001.java Konstantin From: Konstantin Shefov Sent: Wednesday, September 11, 2019 10:53 AM To: 'Liu, Xin' >; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, LX Answering to your e-mail, as for what we modified in [3]: 1. API changes (Process, Unsafe), Xloggc option, that were not in your patches; 2. In a file hotspot/test/JtregNativeHotspot.gmk we changed ?-lpthread? option to ?-pthread? to prevent compilation error. I agree that there should be a series of patches to track file changes. As for investigation of failures: do you have the same? We ran against Arm64 platform, but we can try against x86-64 too. Konstantin From: Liu, Xin > Sent: Monday, September 9, 2019 11:04 PM To: Konstantin Shefov >; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, We are glad to work with you to get vmTestbase landed into jdk8u. Our original intent is get design reviewed by the jdk8u maintainer. After then, we can proceed to refactor it. We can work together to refactor it. we plan to do it anyway. Back to the webrev you send. What did you modify in [3]? Ideally, we can should have a series of patches. The first one should be intact vmTestbase code from the tip of JDK. All we changes should come after it and be reviewed by this mail-list. In addition to refactoring, we can also offer help to figure out those failed cases. What do you think? Thanks, --lx From: Konstantin Shefov > Date: Friday, September 6, 2019 at 12:55 PM To: "jdk8u-dev at openjdk.java.net" > Cc: "Liu, Xin" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, We at Azul think it is a good idea to backport vmTestbase tests to OpenJDK 8. We have used patches you suggested, done some refactoring to enable more tests to work with JDK 8. We have run all 3550 tests from ?vmTestbase? folder against Zulu 8 at ARM64 platform: 1. 3371 tests PASS (see [1]); 2. 179 tests FAIL (see [2]): reasons are being investigated. Patches we have used (contain our refactoring): 1. Hotspot folder [3] 2. Main folder [4] We plan to investigate causes of those 177 failures, purify unused code from hotspot/test/test/lib/jdk, and run the tests against different platforms. We also compared vmTestbase from JDK 11 with that from JDK 13, we found out: 1. 332 test have been removed in JDK 13; 2. Only 2 test have been added in JDK 13; 3. Tests that remained were modified, but these modifications mostly are copyright years, or output format, or API changes. From the above results we can tell that vmTestbase does not grow. It looks like that tests are been removed from there or transferred somewhere else. [1] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/passed_tests.html [2] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/failed_tests.html [3] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_hotspot.patch [4] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_root.patch Regards, --Konstantin From chengjingwei1 at huawei.com Sat Sep 21 02:10:27 2019 From: chengjingwei1 at huawei.com (chengjingwei (A)) Date: Sat, 21 Sep 2019 02:10:27 +0000 Subject: [jdk8u][aarch64] Zookeeper crash during full GC Message-ID: We are witnessing several GC crashes when running a zookeeper based application on aarch64 jdk8 port. All these crashes, although slightly different in the call stack, share something in common that they all happened in the old gen, during full GC. After some investigation, we had little progress. We've put some of the crash logs in the following URL[*]. Someone have ideas or suggestions on these crashes? [*] http://cr.openjdk.java.net/~fyang/hs_err_log/ From chengjingwei1 at huawei.com Sat Sep 21 02:19:28 2019 From: chengjingwei1 at huawei.com (chengjingwei (A)) Date: Sat, 21 Sep 2019 02:19:28 +0000 Subject: [jdk8u][aarch64] Zookeeper crash in full GC Message-ID: We are witnessing several GC crashes when running a zookeeper based application on aarch64 jdk8 port. All these crashes, although slightly different in the call stack, share something in common that they all happened in the old gen, during full GC. After some investigation, we had little progress. We've put some of the crash logs in the following URL[*]. Someone have ideas or suggestions on these crashes? [*] http://cr.openjdk.java.net/~fyang/hs_err_log/ From aph at redhat.com Sat Sep 21 07:31:41 2019 From: aph at redhat.com (Andrew Haley) Date: Sat, 21 Sep 2019 08:31:41 +0100 Subject: [aarch64-port-dev ] [jdk8u][aarch64] Zookeeper crash in full GC In-Reply-To: References: Message-ID: <22095858-4bb7-c492-2338-607ee86c4f2f@redhat.com> On 9/21/19 3:19 AM, chengjingwei (A) wrote: > We've put some of the crash logs in the following URL[*]. > Someone have ideas or suggestions on these crashes? > > [*] http://cr.openjdk.java.net/~fyang/hs_err_log/ I have fixed two GC bugs that were due to missing memory barriers or missing volatile. http://cr.openjdk.java.net/~aph/8225716/ http://cr.openjdk.java.net/~aph/8138966/ These bugs are extremely hard to find. In both cases it took me weeks to debug the problem. You might like to provide us with a reproducer. -- 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 Mon Sep 23 05:55:14 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 23 Sep 2019 06:55:14 +0100 Subject: [8u] RFR 8225425: java.lang.UnsatisfiedLinkError: net.dll: Can't find dependent libraries In-Reply-To: <6797b384-3603-6cc7-00aa-6ce1ba047870@redhat.com> References: <6797b384-3603-6cc7-00aa-6ce1ba047870@redhat.com> Message-ID: On 16/09/2019 12:40, Aleksey Shipilev wrote: > On 9/12/19 4:55 AM, Andrew John Hughes wrote: >> On 10/09/2019 19:47, Aleksey Shipilev wrote: >>> *) test/lib/jdk/test/lib/net/URIBuilder.java put into location that fits 8u. >> >> The right location would seem to be >> jdk/test/lib/testlibrary/jdk/testlibrary/net as >> jdk/test/lib/testlibrary/jdk/testlibrary/ houses JDKToolLauncher.java, >> which is in test/lib/jdk/test/lib/ in trunk. > > Right. testlibrary is a mess. Moved to: > test/lib/testlibrary/jdk/testlibrary/net/URIBuilder.java > Thanks. >> Why is this being backported as part of this and not a backport of >> https://bugs.openjdk.java.net/browse/JDK-8220575 which would also mean >> we get the advantages of introducing this helper class in other tests? > > Because this is a critical bugfix, and we don't want to pull in more that necessary. It also matches > what was done in 11u. > I'm not sure that's a great reason to do a rushed job. And I would have said the same for 11, FWIW. At the very least, it should be flagged for later backport. >>> Read the InputStream without readAllBytes method (added in 9): >>> 85 InputStream is = uc.getInputStream(); >>> 86 byte[] buf = new byte[1024]; >>> 87 while (is.read(buf) != -1) {}; >> >> This conversion loses the output of the read data. Something closer to >> the original would be along the lines of: >> >> InputStream is = uc.getInputStream(); >> BufferedReader r = new BufferedReader(new InputStreamReader(is, UTF_8); >> String body = r.readLine(); >> out.print("received body: " + body); >> while (body != null) { body = r.readLine(); out.print(body); } > > Well, this part of the test is not critical, and its job is to drain the InputStream first and > foremost. But okay, we can also print it. The code above would print "null" at the end, though, so > we need to make a proper post-condition loop. See new patch: > > InputStream is = uc.getInputStream(); > BufferedReader r = new BufferedReader(new InputStreamReader(is, UTF_8)); > String body = r.readLine(); > out.print("received body: "); > do { > out.print(body); > body = r.readLine(); > } while (body != null); > > Updated 8u webrev: > https://cr.openjdk.java.net/~shade/8225425/webrev.8u.02/ > > Still passes new test. Haven't retested anything else, because all changes were related to test code > only. > Heh, it was pretty close for off the top of my head with no testing :P Approved for 8u. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From xxinliu at amazon.com Mon Sep 23 07:12:38 2019 From: xxinliu at amazon.com (Liu, Xin) Date: Mon, 23 Sep 2019 07:12:38 +0000 Subject: Backport vmTestbase tests to jdk8u-dev? In-Reply-To: References: <9ba7e7af9a1645c4831610327c96f22b@azul.com> <51653b0b3223448bbe2f9186d11556af@azul.com> <1568829532868.82475@amazon.com> <0CFA2C19-FD39-4DDF-99E8-FB5B43936AFE@azul.com> <48213D1C-7CE4-41E9-B799-1E8A199846A0@amazon.com> <104bc421591046c8a4e7c2edcb962d81@azul.com>, Message-ID: <1569222717555.22304@amazon.com> hi, Konstantin, I also apply your patch to the last webrev. eventually, JDK-8231089 consists of 6 patches. now I think it's easier to review it. https://cr.openjdk.java.net/~xliu/8231089/ We should apply them in order. 1. base 2. apiChanges 3. classFileInstaller 4. gclog 5. native_libraries 6. azul_contrib for your patch, i keep it everything except for -Xloggc. Could you tell me why you modify from 0x21 to 0x2e? diff -r 95eb898ada95 -r 6c35ac679aa8 test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c --- a/test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c Thu Sep 19 17:30:08 2019 +0300 +++ b/test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c Thu Sep 19 17:35:58 2019 +0300 @@ -89,7 +89,7 @@ jlocation loc, jint i) { jvmtiError err; jclass cls; - jlocation loc_exp = (i == 0) ? 0x21 : 0xd; + jlocation loc_exp = (i == 0) ? 0x2e : 0xd; char *sigClass, *name, *sig, *generic; jvmtiLocalVariableEntry *table = NULL; jint entryCount = 0; ________________________________________ From: jdk8u-dev on behalf of Liu, Xin Sent: Saturday, September 21, 2019 4:48 AM To: Konstantin Shefov; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, As I promised, here is the refactored webrev for native compilation Hotspot: https://cr.openjdk.java.net/~xliu/8231089/native_libraries/hotspot/webrev/ root: https://cr.openjdk.java.net/~xliu/8231089/native_libraries/root/webrev/ so the new target ?test-image? is added. to fix https://gist.github.com/navyxliu/bacd47891b17ac8d33d04708b648b531, I added ?LDFLAGS_SUFFIX := $$(LIBCXX), ? to TestFilesCompilation.gmk. Thanks, --lx From: Konstantin Shefov Date: Friday, September 20, 2019 at 11:01 AM To: "Liu, Xin" , "jdk8u-dev at openjdk.java.net" Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, Liu Xin > I am refactoring makefiles. I plan to upload this webrev today. Fine! We will try to compile with our toolchains. >> BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. > Could you give me an example tests for this? One example is this https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/ConflictingDefaultsTest.java#L329 And most of vmTestbase/vm/runtime/defmeth tests seem to test JVM spec in some way. See here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L50 and here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L134 Konstantin From: Liu, Xin Sent: Friday, September 20, 2019 8:35 PM To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Konstantin, I am refactoring makefiles. I plan to upload this webrev today. I found that you have solved almost all problems. I can help to troubleshoot the remaining tests. >BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. Could you give me an example tests for this? Thanks, --lx From: Konstantin Shefov > Date: Friday, September 20, 2019 at 2:26 AM To: "Liu, Xin" >, "jdk8u-dev at openjdk.java.net" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, We will use your new patches to run tests and merge my changes with yours for those tests that will not work. BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. I see your webrevs do not contain native part build scripts for now. We have to address this problem so the scripts should work for older GCC versions also. Regards Konstantin From: "Liu, Xin" > Date: Wednesday, 18 September 2019 at 20:59 To: Konstantin Shefov >, "jdk8u-dev at openjdk.java.net" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, thank you for updating. We care about x86_64 and aarch64 as well. You ran more tests than us. we never run all vmTestbase. Previously, I used a ProblemList.txt file to screen Problem and move on. Do you plan to fix all problems before we check in? Back to refactor, I have filed a JBS issues. https://bugs.openjdk.java.net/browse/JDK-8231089 In the meanwhile, I start splitting the commits to individual hg changesets. https://cr.openjdk.java.net/~xliu/8231089/ 1. base -> copy code from tag jdk-14+14 intact commit for vmTestbase and testlib 2. make apiChanges for ProcessUtils and Unsafe Could you review it? 3. ClassFileInstaller needs /testlibrary it's because ClassFileInstaller is in /test/testlibrary. I use this script to install @library /testlibrary for all tests. out=$(grep "ClassFileInstaller" -R vmTestbase | awk '{print $1}') for i in $out; do f=${i%\:} gsed -i 's/@library \/vmTestbase/&\n * \/testlibrary/' $f done What do you think that this approach? If I got something wrong, we can update the webtrev with yours. thanks, --lx ________________________________ From: Konstantin Shefov > Sent: Wednesday, September 18, 2019 4:56 PM To: Liu, Xin; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi We ran the tests against x86_64 Ubuntu Linux and there are just the same failed tests as it was with Arm64 Ubuntu Linux plus 2 more tests: vmTestbase/gc/lock/jni/jnilock002/TestDescription.java vmTestbase/nsk/jdb/set/set001/set001.java Konstantin From: Konstantin Shefov Sent: Wednesday, September 11, 2019 10:53 AM To: 'Liu, Xin' >; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, LX Answering to your e-mail, as for what we modified in [3]: 1. API changes (Process, Unsafe), Xloggc option, that were not in your patches; 2. In a file hotspot/test/JtregNativeHotspot.gmk we changed ?-lpthread? option to ?-pthread? to prevent compilation error. I agree that there should be a series of patches to track file changes. As for investigation of failures: do you have the same? We ran against Arm64 platform, but we can try against x86-64 too. Konstantin From: Liu, Xin > Sent: Monday, September 9, 2019 11:04 PM To: Konstantin Shefov >; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, We are glad to work with you to get vmTestbase landed into jdk8u. Our original intent is get design reviewed by the jdk8u maintainer. After then, we can proceed to refactor it. We can work together to refactor it. we plan to do it anyway. Back to the webrev you send. What did you modify in [3]? Ideally, we can should have a series of patches. The first one should be intact vmTestbase code from the tip of JDK. All we changes should come after it and be reviewed by this mail-list. In addition to refactoring, we can also offer help to figure out those failed cases. What do you think? Thanks, --lx From: Konstantin Shefov > Date: Friday, September 6, 2019 at 12:55 PM To: "jdk8u-dev at openjdk.java.net" > Cc: "Liu, Xin" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, We at Azul think it is a good idea to backport vmTestbase tests to OpenJDK 8. We have used patches you suggested, done some refactoring to enable more tests to work with JDK 8. We have run all 3550 tests from ?vmTestbase? folder against Zulu 8 at ARM64 platform: 1. 3371 tests PASS (see [1]); 2. 179 tests FAIL (see [2]): reasons are being investigated. Patches we have used (contain our refactoring): 1. Hotspot folder [3] 2. Main folder [4] We plan to investigate causes of those 177 failures, purify unused code from hotspot/test/test/lib/jdk, and run the tests against different platforms. We also compared vmTestbase from JDK 11 with that from JDK 13, we found out: 1. 332 test have been removed in JDK 13; 2. Only 2 test have been added in JDK 13; 3. Tests that remained were modified, but these modifications mostly are copyright years, or output format, or API changes. >From the above results we can tell that vmTestbase does not grow. It looks like that tests are been removed from there or transferred somewhere else. [1] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/passed_tests.html [2] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/failed_tests.html [3] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_hotspot.patch [4] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_root.patch Regards, --Konstantin From shade at redhat.com Mon Sep 23 08:03:03 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 23 Sep 2019 10:03:03 +0200 Subject: [8u] RFR 8225425: java.lang.UnsatisfiedLinkError: net.dll: Can't find dependent libraries In-Reply-To: References: <6797b384-3603-6cc7-00aa-6ce1ba047870@redhat.com> Message-ID: <749fe870-2b79-f42a-4332-ec4a94f20227@redhat.com> On 9/23/19 7:55 AM, Andrew John Hughes wrote: > On 16/09/2019 12:40, Aleksey Shipilev wrote: >> On 9/12/19 4:55 AM, Andrew John Hughes wrote: >>> Why is this being backported as part of this and not a backport of >>> https://bugs.openjdk.java.net/browse/JDK-8220575 which would also mean >>> we get the advantages of introducing this helper class in other tests? >> >> Because this is a critical bugfix, and we don't want to pull in more that necessary. It also matches >> what was done in 11u. > > I'm not sure that's a great reason to do a rushed job. And I would have > said the same for 11, FWIW. Granted, English is not my mother tongue, but the dictionary says "rushed job" implies this is done without care. However, this patch is done with care to minimize test dependencies pushed to stabilizing tree. For the regular backport with the weeks of spare time ahead, I would bring more dependencies that can be tested more thoroughly; but this one is not a regular backport. > At the very least, it should be flagged for later backport. Flagged. > Approved for 8u. Pushed. -- Thanks, -Aleksey From denghui.ddh at alibaba-inc.com Mon Sep 23 09:49:40 2019 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Mon, 23 Sep 2019 17:49:40 +0800 Subject: =?UTF-8?B?Wzh1XSBSRlIgYmFja3BvcnQgb2YgSkRLLTgxOTg0MjM6IEltcHJvdmUgbWV0YXNwYWNlIGNo?= =?UTF-8?B?dW5rIGFsbG9jYXRpb24=?= Message-ID: <28ec3851-73c9-45d4-9d97-f5c4d83b8f8d.denghui.ddh@alibaba-inc.com> Hi all, I'd like to request a backport of JDK-8198423. I found some long-time running application will oom caused by metaspace if the application loads / unloads classes (by different classloaders) frequently, even if there are many free chunks in freelist. The root cause is the algorithm of metaspace allocation in 8u didn't support chunk split and merge, and if there is no chunk of the same size(except humongous chunk) as the request on the free list, the algorithm will commit more memory. So i plan to backport JDK-8198423, this patch imporve metaspace chunk allocation, the chunks on freelist can be split and merged. By the way, i also found https://openjdk.java.net/jeps/8221173, but it still be a draft. Original bug: https://bugs.openjdk.java.net/browse/JDK-8198423 Original patch:http://hg.openjdk.java.net/jdk/jdk/rev/825f006619e5 This patch doesn't apply cleanly to 8u-dev, if you think this backport is reasonable, i will provide my webrev. What's your comments? Thanks Denghui Dong From kshefov at azul.com Mon Sep 23 13:47:20 2019 From: kshefov at azul.com (Konstantin Shefov) Date: Mon, 23 Sep 2019 13:47:20 +0000 Subject: Backport vmTestbase tests to jdk8u-dev? In-Reply-To: <1569222717555.22304@amazon.com> References: <9ba7e7af9a1645c4831610327c96f22b@azul.com> <51653b0b3223448bbe2f9186d11556af@azul.com> <1568829532868.82475@amazon.com> <0CFA2C19-FD39-4DDF-99E8-FB5B43936AFE@azul.com> <48213D1C-7CE4-41E9-B799-1E8A199846A0@amazon.com> <104bc421591046c8a4e7c2edcb962d81@azul.com>, <1569222717555.22304@amazon.com> Message-ID: <58139b1e7a454e8ca48d4046001cf7b5@azul.com> Hi, Liu Xin Thank you for combining our patch with yours, we will test the whole chain of patches to work at our side. As an answer to your question about modification from 0x21 to 0x2e at earlyretint.c. Java class file format has changed between JDK 8 and JDK 11+. In earlyretint.c from JDK 11+ we have the following line: "jlocation loc_exp = (i == 0) ? 0x21 : 0xd; " This "loc_exp" is an expected location of instruction inside a java method (see and [1] and [2]). By the test scenario we breakpoint inside countDownBoolean(I)V method after checkPoint()V method. In Java 8 the number of instruction before which we breakpoint is 0x2e (hex) and 46 (decimal). In Java 11+ the number of instruction before which we breakpoint is 0x21 (hex) and 33 (decimal). That is why we have to change the test here. [1] https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#SingleStep [2] https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#jlocation Regards, Konstantin -----Original Message----- From: Liu, Xin Sent: Monday, September 23, 2019 10:13 AM To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? hi, Konstantin, I also apply your patch to the last webrev. eventually, JDK-8231089 consists of 6 patches. now I think it's easier to review it. https://cr.openjdk.java.net/~xliu/8231089/ We should apply them in order. 1. base 2. apiChanges 3. classFileInstaller 4. gclog 5. native_libraries 6. azul_contrib for your patch, i keep it everything except for -Xloggc. Could you tell me why you modify from 0x21 to 0x2e? diff -r 95eb898ada95 -r 6c35ac679aa8 test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c --- a/test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c Thu Sep 19 17:30:08 2019 +0300 +++ b/test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c Thu Sep 19 17:35:58 2019 +0300 @@ -89,7 +89,7 @@ jlocation loc, jint i) { jvmtiError err; jclass cls; - jlocation loc_exp = (i == 0) ? 0x21 : 0xd; + jlocation loc_exp = (i == 0) ? 0x2e : 0xd; char *sigClass, *name, *sig, *generic; jvmtiLocalVariableEntry *table = NULL; jint entryCount = 0; ________________________________________ From: jdk8u-dev on behalf of Liu, Xin Sent: Saturday, September 21, 2019 4:48 AM To: Konstantin Shefov; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, As I promised, here is the refactored webrev for native compilation Hotspot: https://cr.openjdk.java.net/~xliu/8231089/native_libraries/hotspot/webrev/ root: https://cr.openjdk.java.net/~xliu/8231089/native_libraries/root/webrev/ so the new target 'test-image' is added. to fix https://gist.github.com/navyxliu/bacd47891b17ac8d33d04708b648b531, I added "LDFLAGS_SUFFIX := $$(LIBCXX), " to TestFilesCompilation.gmk. Thanks, --lx From: Konstantin Shefov Date: Friday, September 20, 2019 at 11:01 AM To: "Liu, Xin" , "jdk8u-dev at openjdk.java.net" Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, Liu Xin > I am refactoring makefiles. I plan to upload this webrev today. Fine! We will try to compile with our toolchains. >> BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. > Could you give me an example tests for this? One example is this https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/ConflictingDefaultsTest.java#L329 And most of vmTestbase/vm/runtime/defmeth tests seem to test JVM spec in some way. See here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L50 and here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L134 Konstantin From: Liu, Xin Sent: Friday, September 20, 2019 8:35 PM To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Konstantin, I am refactoring makefiles. I plan to upload this webrev today. I found that you have solved almost all problems. I can help to troubleshoot the remaining tests. >BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. Could you give me an example tests for this? Thanks, --lx From: Konstantin Shefov > Date: Friday, September 20, 2019 at 2:26 AM To: "Liu, Xin" >, "jdk8u-dev at openjdk.java.net" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, We will use your new patches to run tests and merge my changes with yours for those tests that will not work. BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. I see your webrevs do not contain native part build scripts for now. We have to address this problem so the scripts should work for older GCC versions also. Regards Konstantin From: "Liu, Xin" > Date: Wednesday, 18 September 2019 at 20:59 To: Konstantin Shefov >, "jdk8u-dev at openjdk.java.net" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, thank you for updating. We care about x86_64 and aarch64 as well. You ran more tests than us. we never run all vmTestbase. Previously, I used a ProblemList.txt file to screen Problem and move on. Do you plan to fix all problems before we check in? Back to refactor, I have filed a JBS issues. https://bugs.openjdk.java.net/browse/JDK-8231089 In the meanwhile, I start splitting the commits to individual hg changesets. https://cr.openjdk.java.net/~xliu/8231089/ 1. base -> copy code from tag jdk-14+14 intact commit for vmTestbase and testlib 2. make apiChanges for ProcessUtils and Unsafe Could you review it? 3. ClassFileInstaller needs /testlibrary it's because ClassFileInstaller is in /test/testlibrary. I use this script to install @library /testlibrary for all tests. out=$(grep "ClassFileInstaller" -R vmTestbase | awk '{print $1}') for i in $out; do f=${i%\:} gsed -i 's/@library \/vmTestbase/&\n * \/testlibrary/' $f done What do you think that this approach? If I got something wrong, we can update the webtrev with yours. thanks, --lx ________________________________ From: Konstantin Shefov > Sent: Wednesday, September 18, 2019 4:56 PM To: Liu, Xin; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi We ran the tests against x86_64 Ubuntu Linux and there are just the same failed tests as it was with Arm64 Ubuntu Linux plus 2 more tests: vmTestbase/gc/lock/jni/jnilock002/TestDescription.java vmTestbase/nsk/jdb/set/set001/set001.java Konstantin From: Konstantin Shefov Sent: Wednesday, September 11, 2019 10:53 AM To: 'Liu, Xin' >; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, LX Answering to your e-mail, as for what we modified in [3]: 1. API changes (Process, Unsafe), Xloggc option, that were not in your patches; 2. In a file hotspot/test/JtregNativeHotspot.gmk we changed "-lpthread" option to "-pthread" to prevent compilation error. I agree that there should be a series of patches to track file changes. As for investigation of failures: do you have the same? We ran against Arm64 platform, but we can try against x86-64 too. Konstantin From: Liu, Xin > Sent: Monday, September 9, 2019 11:04 PM To: Konstantin Shefov >; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, We are glad to work with you to get vmTestbase landed into jdk8u. Our original intent is get design reviewed by the jdk8u maintainer. After then, we can proceed to refactor it. We can work together to refactor it. we plan to do it anyway. Back to the webrev you send. What did you modify in [3]? Ideally, we can should have a series of patches. The first one should be intact vmTestbase code from the tip of JDK. All we changes should come after it and be reviewed by this mail-list. In addition to refactoring, we can also offer help to figure out those failed cases. What do you think? Thanks, --lx From: Konstantin Shefov > Date: Friday, September 6, 2019 at 12:55 PM To: "jdk8u-dev at openjdk.java.net" > Cc: "Liu, Xin" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, We at Azul think it is a good idea to backport vmTestbase tests to OpenJDK 8. We have used patches you suggested, done some refactoring to enable more tests to work with JDK 8. We have run all 3550 tests from "vmTestbase" folder against Zulu 8 at ARM64 platform: 1. 3371 tests PASS (see [1]); 2. 179 tests FAIL (see [2]): reasons are being investigated. Patches we have used (contain our refactoring): 1. Hotspot folder [3] 2. Main folder [4] We plan to investigate causes of those 177 failures, purify unused code from hotspot/test/test/lib/jdk, and run the tests against different platforms. We also compared vmTestbase from JDK 11 with that from JDK 13, we found out: 1. 332 test have been removed in JDK 13; 2. Only 2 test have been added in JDK 13; 3. Tests that remained were modified, but these modifications mostly are copyright years, or output format, or API changes. >From the above results we can tell that vmTestbase does not grow. It looks like that tests are been removed from there or transferred somewhere else. [1] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/passed_tests.html [2] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/failed_tests.html [3] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_hotspot.patch [4] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_root.patch Regards, --Konstantin From gnu.andrew at redhat.com Mon Sep 23 14:55:55 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 23 Sep 2019 15:55:55 +0100 Subject: [8u] RFR 8225425: java.lang.UnsatisfiedLinkError: net.dll: Can't find dependent libraries In-Reply-To: <749fe870-2b79-f42a-4332-ec4a94f20227@redhat.com> References: <6797b384-3603-6cc7-00aa-6ce1ba047870@redhat.com> <749fe870-2b79-f42a-4332-ec4a94f20227@redhat.com> Message-ID: <54b835fd-9de9-5745-50b8-0925c16f9f3c@redhat.com> On 23/09/2019 09:03, Aleksey Shipilev wrote: > On 9/23/19 7:55 AM, Andrew John Hughes wrote: >> On 16/09/2019 12:40, Aleksey Shipilev wrote: >>> On 9/12/19 4:55 AM, Andrew John Hughes wrote: >>>> Why is this being backported as part of this and not a backport of >>>> https://bugs.openjdk.java.net/browse/JDK-8220575 which would also mean >>>> we get the advantages of introducing this helper class in other tests? >>> >>> Because this is a critical bugfix, and we don't want to pull in more that necessary. It also matches >>> what was done in 11u. >> >> I'm not sure that's a great reason to do a rushed job. And I would have >> said the same for 11, FWIW. > > Granted, English is not my mother tongue, but the dictionary says "rushed job" implies this is done > without care. However, this patch is done with care to minimize test dependencies pushed to > stabilizing tree. For the regular backport with the weeks of spare time ahead, I would bring more > dependencies that can be tested more thoroughly; but this one is not a regular backport. > Sorry, that wasn't my implication, but I admit the phrase can be used with negative connotations. I concur with what you're saying that you'd do things differently if there was more time: "We need to do X, Y and Z to get the job done" "I need it by Friday" "Ok, we can do just X and Z, but it'll be a rush job" i.e. in the sense it's not what I'd do under normal circumstances. At the time of the original request, I thought there was time for what is just a testcase update. Now we're freezing this Wednesday, I'm grudgingly waving it through. I know I make a fuss about things like this, but I also know the pain of finding your clean backport has been messed up by some file appearing largely unexplained in a different changeset :-) >> At the very least, it should be flagged for later backport. > > Flagged. > >> Approved for 8u. > > Pushed. > Thanks for the quick turnaround. -- 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 kshefov at azul.com Mon Sep 23 15:29:55 2019 From: kshefov at azul.com (Konstantin Shefov) Date: Mon, 23 Sep 2019 15:29:55 +0000 Subject: Backport vmTestbase tests to jdk8u-dev? In-Reply-To: <58139b1e7a454e8ca48d4046001cf7b5@azul.com> References: <9ba7e7af9a1645c4831610327c96f22b@azul.com> <51653b0b3223448bbe2f9186d11556af@azul.com> <1568829532868.82475@amazon.com> <0CFA2C19-FD39-4DDF-99E8-FB5B43936AFE@azul.com> <48213D1C-7CE4-41E9-B799-1E8A199846A0@amazon.com> <104bc421591046c8a4e7c2edcb962d81@azul.com>, <1569222717555.22304@amazon.com> <58139b1e7a454e8ca48d4046001cf7b5@azul.com> Message-ID: Hi, Liu Xin After applying all the patches, I have successfully built the native part, but I had to do some more changes. After all tests run, I will prepare one more patch "azul_contrib_2" and send it here. Konstantin -----Original Message----- From: Konstantin Shefov Sent: Monday, September 23, 2019 4:47 PM To: 'Liu, Xin' ; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, Liu Xin Thank you for combining our patch with yours, we will test the whole chain of patches to work at our side. As an answer to your question about modification from 0x21 to 0x2e at earlyretint.c. Java class file format has changed between JDK 8 and JDK 11+. In earlyretint.c from JDK 11+ we have the following line: "jlocation loc_exp = (i == 0) ? 0x21 : 0xd; " This "loc_exp" is an expected location of instruction inside a java method (see and [1] and [2]). By the test scenario we breakpoint inside countDownBoolean(I)V method after checkPoint()V method. In Java 8 the number of instruction before which we breakpoint is 0x2e (hex) and 46 (decimal). In Java 11+ the number of instruction before which we breakpoint is 0x21 (hex) and 33 (decimal). That is why we have to change the test here. [1] https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#SingleStep [2] https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#jlocation Regards, Konstantin -----Original Message----- From: Liu, Xin Sent: Monday, September 23, 2019 10:13 AM To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? hi, Konstantin, I also apply your patch to the last webrev. eventually, JDK-8231089 consists of 6 patches. now I think it's easier to review it. https://cr.openjdk.java.net/~xliu/8231089/ We should apply them in order. 1. base 2. apiChanges 3. classFileInstaller 4. gclog 5. native_libraries 6. azul_contrib for your patch, i keep it everything except for -Xloggc. Could you tell me why you modify from 0x21 to 0x2e? diff -r 95eb898ada95 -r 6c35ac679aa8 test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c --- a/test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c Thu Sep 19 17:30:08 2019 +0300 +++ b/test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c Thu Sep 19 17:35:58 2019 +0300 @@ -89,7 +89,7 @@ jlocation loc, jint i) { jvmtiError err; jclass cls; - jlocation loc_exp = (i == 0) ? 0x21 : 0xd; + jlocation loc_exp = (i == 0) ? 0x2e : 0xd; char *sigClass, *name, *sig, *generic; jvmtiLocalVariableEntry *table = NULL; jint entryCount = 0; ________________________________________ From: jdk8u-dev on behalf of Liu, Xin Sent: Saturday, September 21, 2019 4:48 AM To: Konstantin Shefov; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, As I promised, here is the refactored webrev for native compilation Hotspot: https://cr.openjdk.java.net/~xliu/8231089/native_libraries/hotspot/webrev/ root: https://cr.openjdk.java.net/~xliu/8231089/native_libraries/root/webrev/ so the new target 'test-image' is added. to fix https://gist.github.com/navyxliu/bacd47891b17ac8d33d04708b648b531, I added "LDFLAGS_SUFFIX := $$(LIBCXX), " to TestFilesCompilation.gmk. Thanks, --lx From: Konstantin Shefov Date: Friday, September 20, 2019 at 11:01 AM To: "Liu, Xin" , "jdk8u-dev at openjdk.java.net" Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, Liu Xin > I am refactoring makefiles. I plan to upload this webrev today. Fine! We will try to compile with our toolchains. >> BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. > Could you give me an example tests for this? One example is this https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/ConflictingDefaultsTest.java#L329 And most of vmTestbase/vm/runtime/defmeth tests seem to test JVM spec in some way. See here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L50 and here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L134 Konstantin From: Liu, Xin Sent: Friday, September 20, 2019 8:35 PM To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Konstantin, I am refactoring makefiles. I plan to upload this webrev today. I found that you have solved almost all problems. I can help to troubleshoot the remaining tests. >BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. Could you give me an example tests for this? Thanks, --lx From: Konstantin Shefov > Date: Friday, September 20, 2019 at 2:26 AM To: "Liu, Xin" >, "jdk8u-dev at openjdk.java.net" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, We will use your new patches to run tests and merge my changes with yours for those tests that will not work. BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. I see your webrevs do not contain native part build scripts for now. We have to address this problem so the scripts should work for older GCC versions also. Regards Konstantin From: "Liu, Xin" > Date: Wednesday, 18 September 2019 at 20:59 To: Konstantin Shefov >, "jdk8u-dev at openjdk.java.net" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, thank you for updating. We care about x86_64 and aarch64 as well. You ran more tests than us. we never run all vmTestbase. Previously, I used a ProblemList.txt file to screen Problem and move on. Do you plan to fix all problems before we check in? Back to refactor, I have filed a JBS issues. https://bugs.openjdk.java.net/browse/JDK-8231089 In the meanwhile, I start splitting the commits to individual hg changesets. https://cr.openjdk.java.net/~xliu/8231089/ 1. base -> copy code from tag jdk-14+14 intact commit for vmTestbase and testlib 2. make apiChanges for ProcessUtils and Unsafe Could you review it? 3. ClassFileInstaller needs /testlibrary it's because ClassFileInstaller is in /test/testlibrary. I use this script to install @library /testlibrary for all tests. out=$(grep "ClassFileInstaller" -R vmTestbase | awk '{print $1}') for i in $out; do f=${i%\:} gsed -i 's/@library \/vmTestbase/&\n * \/testlibrary/' $f done What do you think that this approach? If I got something wrong, we can update the webtrev with yours. thanks, --lx ________________________________ From: Konstantin Shefov > Sent: Wednesday, September 18, 2019 4:56 PM To: Liu, Xin; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi We ran the tests against x86_64 Ubuntu Linux and there are just the same failed tests as it was with Arm64 Ubuntu Linux plus 2 more tests: vmTestbase/gc/lock/jni/jnilock002/TestDescription.java vmTestbase/nsk/jdb/set/set001/set001.java Konstantin From: Konstantin Shefov Sent: Wednesday, September 11, 2019 10:53 AM To: 'Liu, Xin' >; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, LX Answering to your e-mail, as for what we modified in [3]: 1. API changes (Process, Unsafe), Xloggc option, that were not in your patches; 2. In a file hotspot/test/JtregNativeHotspot.gmk we changed "-lpthread" option to "-pthread" to prevent compilation error. I agree that there should be a series of patches to track file changes. As for investigation of failures: do you have the same? We ran against Arm64 platform, but we can try against x86-64 too. Konstantin From: Liu, Xin > Sent: Monday, September 9, 2019 11:04 PM To: Konstantin Shefov >; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, We are glad to work with you to get vmTestbase landed into jdk8u. Our original intent is get design reviewed by the jdk8u maintainer. After then, we can proceed to refactor it. We can work together to refactor it. we plan to do it anyway. Back to the webrev you send. What did you modify in [3]? Ideally, we can should have a series of patches. The first one should be intact vmTestbase code from the tip of JDK. All we changes should come after it and be reviewed by this mail-list. In addition to refactoring, we can also offer help to figure out those failed cases. What do you think? Thanks, --lx From: Konstantin Shefov > Date: Friday, September 6, 2019 at 12:55 PM To: "jdk8u-dev at openjdk.java.net" > Cc: "Liu, Xin" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, We at Azul think it is a good idea to backport vmTestbase tests to OpenJDK 8. We have used patches you suggested, done some refactoring to enable more tests to work with JDK 8. We have run all 3550 tests from "vmTestbase" folder against Zulu 8 at ARM64 platform: 1. 3371 tests PASS (see [1]); 2. 179 tests FAIL (see [2]): reasons are being investigated. Patches we have used (contain our refactoring): 1. Hotspot folder [3] 2. Main folder [4] We plan to investigate causes of those 177 failures, purify unused code from hotspot/test/test/lib/jdk, and run the tests against different platforms. We also compared vmTestbase from JDK 11 with that from JDK 13, we found out: 1. 332 test have been removed in JDK 13; 2. Only 2 test have been added in JDK 13; 3. Tests that remained were modified, but these modifications mostly are copyright years, or output format, or API changes. >From the above results we can tell that vmTestbase does not grow. It looks like that tests are been removed from there or transferred somewhere else. [1] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/passed_tests.html [2] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/failed_tests.html [3] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_hotspot.patch [4] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_root.patch Regards, --Konstantin From gnu.andrew at redhat.com Mon Sep 23 21:04:04 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 23 Sep 2019 22:04:04 +0100 Subject: [8u] RFR 8225425: java.lang.UnsatisfiedLinkError: net.dll: Can't find dependent libraries In-Reply-To: <749fe870-2b79-f42a-4332-ec4a94f20227@redhat.com> References: <6797b384-3603-6cc7-00aa-6ce1ba047870@redhat.com> <749fe870-2b79-f42a-4332-ec4a94f20227@redhat.com> Message-ID: <47a148a1-c809-496d-8c8a-ce7388404891@redhat.com> On 23/09/2019 09:03, Aleksey Shipilev wrote: > On 9/23/19 7:55 AM, Andrew John Hughes wrote: >> On 16/09/2019 12:40, Aleksey Shipilev wrote: >>> On 9/12/19 4:55 AM, Andrew John Hughes wrote: >>>> Why is this being backported as part of this and not a backport of >>>> https://bugs.openjdk.java.net/browse/JDK-8220575 which would also mean >>>> we get the advantages of introducing this helper class in other tests? >>> >>> Because this is a critical bugfix, and we don't want to pull in more that necessary. It also matches >>> what was done in 11u. >> >> I'm not sure that's a great reason to do a rushed job. And I would have >> said the same for 11, FWIW. > > Granted, English is not my mother tongue, but the dictionary says "rushed job" implies this is done > without care. However, this patch is done with care to minimize test dependencies pushed to > stabilizing tree. For the regular backport with the weeks of spare time ahead, I would bring more > dependencies that can be tested more thoroughly; but this one is not a regular backport. > Sorry, that wasn't my implication, but I admit the phrase can be used with negative connotations. I concur with what you're saying that you'd do things differently if there was more time: "We need to do X, Y and Z to get the job done" "I need it by Friday" "Ok, we can do just X and Z, but it'll be a rush job" i.e. in the sense it's not what I'd do under normal circumstances. At the time of the original request, I thought there was time for what is just a testcase update. Now we're freezing this Wednesday, I'm grudgingly waving it through. I know I make a fuss about things like this, but I also know the pain of finding your clean backport has been messed up by some file appearing largely unexplained in a different changeset :-) >> At the very least, it should be flagged for later backport. > > Flagged. > >> Approved for 8u. > > Pushed. > Thanks for the quick turnaround. -- 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 Tue Sep 24 01:07:16 2019 From: alvdavi at amazon.com (Alvarez, David) Date: Tue, 24 Sep 2019 01:07:16 +0000 Subject: [8u] 8178870: instrumentation.retransformClasses cause coredump In-Reply-To: <558f30e9-939d-ce1c-dda4-877857ce97e7@redhat.com> References: <6d646175-68e2-b280-6475-cd97f2e5d438@redhat.com> <7003c233-d891-b11b-3426-f9b6f7de2d8f@redhat.com> <0bfedafb-f31c-6278-31da-56cb4abc1d34@redhat.com> <03cd4243-91e7-fb9f-5b5b-bbacf1de547d@redhat.com> <241f6d60-0392-4225-61aa-706dfb62e194@redhat.com> <79be4136-9e79-8552-a041-eb525f036dbf@redhat.com> <558f30e9-939d-ce1c-dda4-877857ce97e7@redhat.com> Message-ID: <37BA6F70-74A1-4BF0-A860-4EBFBFDFF2F7@amazon.com> Hi, After importing jdk8u232-b06 we are seeing two new failures in jtreg apparently caused by this change. Affected tests are: runtime/RedefineTests/test8178870.sh runtime/RedefineTests/RedefineDoubleDelete.java test8178870.sh fails because it is defined as test.sh in the jtreg section. Fixing this will allow the test to run, but it will still fail later with a ClassNotFoundException. RedefineDoubleDelete will fail during compilation locating RedefineClassHelper as it does not have @library defined, but after adding it will still fail with an NPE. -- David Alvarez ?On 2019-09-12, 09:47, "jdk8u-dev on behalf of Andrew John Hughes" wrote: On 12/09/2019 13:28, Zhengyu Gu wrote: snip... >>>> >> >> This looks ok. I presume you intend to commit with the correct metadata, >> as currently it says "imported patch JDK-8178870_coredump.patch"? > > Of course. Otherwise, it won't push. > Running jcheck locally [0], I can't even commit something like that :) Just wanted to be sure. [0] https://openjdk.java.net/projects/code-tools/jcheck/ 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 Tue Sep 24 08:15:11 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 24 Sep 2019 10:15:11 +0200 Subject: [8u] RFR (XS) 8231398: Add time tracing for gc log rotation at safepoint cleanup Message-ID: RFE: https://bugs.openjdk.java.net/browse/JDK-8231398 There is a nice gotcha when dealing with low latency workloads. The safepoint cleanup does lots of things, notably rotating the GC logs in 8 (fixed by transition to Unified Logging in 9+, see JDK-8145092). Those things are normally caught by -XX:+TraceSafepointCleanupTime, but not gc log rotation, since it misses the tracing statement. We should consider adding the tracing there. Webrev: https://cr.openjdk.java.net/~shade/8231398/webrev.01/ Testing: eyeballing safepoint cleanup tracing, tier1 (running) -- Thanks, -Aleksey From thomas.stuefe at gmail.com Tue Sep 24 09:23:20 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 24 Sep 2019 11:23:20 +0200 Subject: [8u] RFR backport of JDK-8198423: Improve metaspace chunk allocation Message-ID: Hi Denghui, This is quite a large change and will be a bit of work getting into jdk8. But offhand I think JDK-8198423 should work in 8. However, it is not the best technical solution. As you mentioned there is currently work going on for https://openjdk.java.net/jeps/8221173, which is a complete rewrite of the metaspace allocator and is quite a bit better than what we have now in 11+. There exists a prototype in the jdk-sandbox repository: http://hg.openjdk.java.net/jdk/sandbox/ , branch "stuefe-new-metaspace-branch". It is stable already and shows quite a bit of promise; in particular it is way more elastic than the current allocator. I plan to bring the new allocator down to 11 when it is done but I cannot say when that will be. My hope is to get it in for jdk15 (14 is probably too late). So if the matter is not pressing and you can wait a bit, you may skip downporting JDK-8198423 and downport a superior solution, https://openjdk.java.net/jeps/8221173. (BTW, I am not sure whether 8221173 will come in the form of a JEP, there is currently a lot of confusion about what needs a JEP and what doesnt. JDK-8198423 was supposed to be a JEP too but then I just did it as a normal RFE.) Cheers, Thomas > Hi all, > I'd like to request a backport of JDK-8198423. > I found some long-time running application will oom caused by metaspace if > the application loads / unloads classes (by different classloaders) frequently, > even if there are many free chunks in freelist. > The root cause is the algorithm of metaspace allocation in 8u didn't support chunk > split and merge, and if there is no chunk of the same size(except humongous chunk) > as the request on the free list, the algorithm will commit more memory. > So i plan to backport JDK-8198423, this patch imporve metaspace chunk allocation, > the chunks on freelist can be split and merged. > By the way, i also found https://openjdk.java.net/jeps/8221173, but it still be > a draft. > Original bug: https://bugs.openjdk.java.net/browse/JDK-8198423 > Original patch:http://hg.openjdk.java.net/jdk/jdk/rev/825f006619e5 > This patch doesn't apply cleanly to 8u-dev, if you think this backport is reasonable, > i will provide my webrev. > What's your comments? > > Thanks > Denghui Dong From adinn at redhat.com Tue Sep 24 09:56:05 2019 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 24 Sep 2019 10:56:05 +0100 Subject: [8u] RFR backport of JDK-8198423: Improve metaspace chunk allocation In-Reply-To: <28ec3851-73c9-45d4-9d97-f5c4d83b8f8d.denghui.ddh@alibaba-inc.com> References: <28ec3851-73c9-45d4-9d97-f5c4d83b8f8d.denghui.ddh@alibaba-inc.com> Message-ID: On 23/09/2019 10:49, Denghui Dong wrote: > Hi all, > I'd like to request a backport of JDK-8198423. > I found some long-time running application will oom caused by metaspace if > the application loads / unloads classes (by different classloaders) frequently, > even if there are many free chunks in freelist. > . . . > This patch doesn't apply cleanly to 8u-dev, if you think this backport is reasonable, > i will provide my webrev. > What's your comments? I think backporting this patch is probably a bad idea. It is a large and complex change to a critical part of the JVM runtime so the risk involved is quite high. Likewise I would expect that backporting whatever eventually gets done under JDK-8221173 is going to be equally risky. It might help if you could give an idea of how much of a problem this is. I can see how very long-running apps might suffer from fragmentation of metadata space without the patch. Is this something you are seeing regularly or intermittently? I would expect that allocating more memory to the JVM can be used as a workaround to delay the onset/lower the frequency of this problem. Is there a reason why that approach is not available to you? And, of course, there is always the option of upgrading to jdk11u. Eventually, that is going to be needed to resolve more and more of the problems remaining in jdk8u. Perhaps Andrew Haley or Christoph Langer might be able to comment on this? 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 denghui.ddh at alibaba-inc.com Tue Sep 24 09:59:23 2019 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Tue, 24 Sep 2019 17:59:23 +0800 Subject: =?UTF-8?B?UmU6IFs4dV0gUkZSIGJhY2twb3J0IG9mIEpESy04MTk4NDIzOiBJbXByb3ZlIG1ldGFzcGFj?= =?UTF-8?B?ZSBjaHVuayBhbGxvY2F0aW9u?= In-Reply-To: References: Message-ID: Hi Thomas, Thank you for your reply, i agree with you that JDK-8221173 is a better solution, hope it come soon. Cheers Denghui Dong ------------------------------------------------------------------ From:Thomas St?fe Send Time:2019?9?24?(???) 17:23 To:jdk8u-dev ; ???(??) Subject:[8u] RFR backport of JDK-8198423: Improve metaspace chunk allocation Hi Denghui, This is quite a large change and will be a bit of work getting into jdk8. But offhand I think JDK-8198423 should work in 8. However, it is not the best technical solution. As you mentioned there is currently work going on for https://openjdk.java.net/jeps/8221173, which is a complete rewrite of the metaspace allocator and is quite a bit better than what we have now in 11+. There exists a prototype in the jdk-sandbox repository: http://hg.openjdk.java.net/jdk/sandbox/ , branch "stuefe-new-metaspace-branch". It is stable already and shows quite a bit of promise; in particular it is way more elastic than the current allocator. I plan to bring the new allocator down to 11 when it is done but I cannot say when that will be. My hope is to get it in for jdk15 (14 is probably too late). So if the matter is not pressing and you can wait a bit, you may skip downporting JDK-8198423 and downport a superior solution, https://openjdk.java.net/jeps/8221173. (BTW, I am not sure whether 8221173 will come in the form of a JEP, there is currently a lot of confusion about what needs a JEP and what doesnt. JDK-8198423 was supposed to be a JEP too but then I just did it as a normal RFE.) Cheers, Thomas > Hi all, > I'd like to request a backport of JDK-8198423. > I found some long-time running application will oom caused by metaspace if > the application loads / unloads classes (by different classloaders) frequently, > even if there are many free chunks in freelist. > The root cause is the algorithm of metaspace allocation in 8u didn't support chunk > split and merge, and if there is no chunk of the same size(except humongous chunk) > as the request on the free list, the algorithm will commit more memory. > So i plan to backport JDK-8198423, this patch imporve metaspace chunk allocation, > the chunks on freelist can be split and merged. > By the way, i also found https://openjdk.java.net/jeps/8221173, but it still be > a draft. > Original bug: https://bugs.openjdk.java.net/browse/JDK-8198423 > Original patch:http://hg.openjdk.java.net/jdk/jdk/rev/825f006619e5 > This patch doesn't apply cleanly to 8u-dev, if you think this backport is reasonable, > i will provide my webrev. > What's your comments? > > Thanks > Denghui Dong From zgu at redhat.com Tue Sep 24 12:18:26 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 24 Sep 2019 08:18:26 -0400 Subject: [8u] 8178870: instrumentation.retransformClasses cause coredump In-Reply-To: <37BA6F70-74A1-4BF0-A860-4EBFBFDFF2F7@amazon.com> References: <6d646175-68e2-b280-6475-cd97f2e5d438@redhat.com> <7003c233-d891-b11b-3426-f9b6f7de2d8f@redhat.com> <0bfedafb-f31c-6278-31da-56cb4abc1d34@redhat.com> <03cd4243-91e7-fb9f-5b5b-bbacf1de547d@redhat.com> <241f6d60-0392-4225-61aa-706dfb62e194@redhat.com> <79be4136-9e79-8552-a041-eb525f036dbf@redhat.com> <558f30e9-939d-ce1c-dda4-877857ce97e7@redhat.com> <37BA6F70-74A1-4BF0-A860-4EBFBFDFF2F7@amazon.com> Message-ID: <034e3ee3-fae6-f14c-fd23-3dbe6f10f277@redhat.com> On 9/23/19 9:07 PM, Alvarez, David wrote: > Hi, > > After importing jdk8u232-b06 we are seeing two new failures in jtreg apparently > caused by this change. > > Affected tests are: > runtime/RedefineTests/test8178870.sh > runtime/RedefineTests/RedefineDoubleDelete.java > > test8178870.sh fails because it is defined as test.sh in the jtreg section. Oops, I did make stupid last minute name change. But other than that, test runs fine for me. diff -r 7d5c800dae75 test/runtime/RedefineTests/test8178870.sh --- a/test/runtime/RedefineTests/test8178870.sh Tue Sep 10 19:58:22 2019 +0200 +++ b/test/runtime/RedefineTests/test8178870.sh Tue Sep 24 08:17:05 2019 -0400 @@ -26,7 +26,7 @@ ## @test test.sh ## @bug 8178870 ## @summary test instrumentation.retransformClasses -## @run shell test.sh +## @run shell test8178870.sh if [ "${TESTSRC}" = "" ] then [zgu at localhost jdk8u-dev]$ ~/jtreg/bin/jtreg -jdk:/home/zgu/ws/jdk8u-dev/build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image/ hotspot/test/runtime/RedefineTests/test8178870.sh Directory "JTwork" not found: creating Directory "JTreport" not found: creating Test results: passed: 1 Report written to /home/zgu/ws/jdk8u-dev/JTreport/html/report.html Results written to /home/zgu/ws/jdk8u-dev/JTwork -Zhengyu > Fixing this will allow the test to run, but it will still fail later with a > ClassNotFoundException. > > RedefineDoubleDelete will fail during compilation locating RedefineClassHelper > as it does not have @library defined, but after adding it will still fail with > an NPE. > > -- > David Alvarez > > > ?On 2019-09-12, 09:47, "jdk8u-dev on behalf of Andrew John Hughes" wrote: > > > > On 12/09/2019 13:28, Zhengyu Gu wrote: > > snip... > > >>>> > >> > >> This looks ok. I presume you intend to commit with the correct metadata, > >> as currently it says "imported patch JDK-8178870_coredump.patch"? > > > > Of course. Otherwise, it won't push. > > > > Running jcheck locally [0], I can't even commit something like that :) > > Just wanted to be sure. > > [0] https://openjdk.java.net/projects/code-tools/jcheck/ > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew > > > From christoph.langer at sap.com Tue Sep 24 12:22:19 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 24 Sep 2019 12:22:19 +0000 Subject: [8u] RFR backport of JDK-8198423: Improve metaspace chunk allocation In-Reply-To: References: <28ec3851-73c9-45d4-9d97-f5c4d83b8f8d.denghui.ddh@alibaba-inc.com> Message-ID: Hi, from a technical perspective, Thomas Stuefe is probably the right contact for this backport. And I see, he has already commented on it. Whether it is appropriate for OpenJDK 8u and can make it there, you'll probably have to convince Andrew Haley and Andrew Hughes. I'm not a maintainer for 8u. Best regards Christoph > -----Original Message----- > From: Andrew Dinn > Sent: Dienstag, 24. September 2019 11:56 > To: Denghui Dong ; jdk8u- > dev at openjdk.java.net; Andrew Haley ; Langer, > Christoph > Subject: Re: [8u] RFR backport of JDK-8198423: Improve metaspace chunk > allocation > > On 23/09/2019 10:49, Denghui Dong wrote: > > Hi all, > > I'd like to request a backport of JDK-8198423. > > I found some long-time running application will oom caused by metaspace > if > > the application loads / unloads classes (by different classloaders) > frequently, > > even if there are many free chunks in freelist. > > . . . > > This patch doesn't apply cleanly to 8u-dev, if you think this backport is > reasonable, > > i will provide my webrev. > > What's your comments? > I think backporting this patch is probably a bad idea. It is a large and > complex change to a critical part of the JVM runtime so the risk > involved is quite high. > > Likewise I would expect that backporting whatever eventually gets done > under JDK-8221173 is going to be equally risky. > > It might help if you could give an idea of how much of a problem this > is. I can see how very long-running apps might suffer from fragmentation > of metadata space without the patch. Is this something you are seeing > regularly or intermittently? > > I would expect that allocating more memory to the JVM can be used as a > workaround to delay the onset/lower the frequency of this problem. Is > there a reason why that approach is not available to you? > > And, of course, there is always the option of upgrading to jdk11u. > Eventually, that is going to be needed to resolve more and more of the > problems remaining in jdk8u. > > Perhaps Andrew Haley or Christoph Langer might be able to comment on > this? > > 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 thomas.stuefe at gmail.com Tue Sep 24 12:39:53 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 24 Sep 2019 14:39:53 +0200 Subject: [8u] RFR backport of JDK-8198423: Improve metaspace chunk allocation In-Reply-To: References: <28ec3851-73c9-45d4-9d97-f5c4d83b8f8d.denghui.ddh@alibaba-inc.com> Message-ID: I agree with Andrew that backporting JDK-8198423 is a large effort and a bit risky. If that has not been clear from my first mail I recommend against it. As for JDK-8221173, lets see how that pans out. I plan to bring it at least to SapMachine11, upstream 11 if it makes sense. But this is still in the future. Cheers, Thomas On Tue, Sep 24, 2019 at 2:22 PM Langer, Christoph wrote: > Hi, > > from a technical perspective, Thomas Stuefe is probably the right contact > for this backport. And I see, he has already commented on it. > > Whether it is appropriate for OpenJDK 8u and can make it there, you'll > probably have to convince Andrew Haley and Andrew Hughes. I'm not a > maintainer for 8u. > > Best regards > Christoph > > > -----Original Message----- > > From: Andrew Dinn > > Sent: Dienstag, 24. September 2019 11:56 > > To: Denghui Dong ; jdk8u- > > dev at openjdk.java.net; Andrew Haley ; Langer, > > Christoph > > Subject: Re: [8u] RFR backport of JDK-8198423: Improve metaspace chunk > > allocation > > > > On 23/09/2019 10:49, Denghui Dong wrote: > > > Hi all, > > > I'd like to request a backport of JDK-8198423. > > > I found some long-time running application will oom caused by > metaspace > > if > > > the application loads / unloads classes (by different classloaders) > > frequently, > > > even if there are many free chunks in freelist. > > > . . . > > > This patch doesn't apply cleanly to 8u-dev, if you think this > backport is > > reasonable, > > > i will provide my webrev. > > > What's your comments? > > I think backporting this patch is probably a bad idea. It is a large and > > complex change to a critical part of the JVM runtime so the risk > > involved is quite high. > > > > Likewise I would expect that backporting whatever eventually gets done > > under JDK-8221173 is going to be equally risky. > > > > It might help if you could give an idea of how much of a problem this > > is. I can see how very long-running apps might suffer from fragmentation > > of metadata space without the patch. Is this something you are seeing > > regularly or intermittently? > > > > I would expect that allocating more memory to the JVM can be used as a > > workaround to delay the onset/lower the frequency of this problem. Is > > there a reason why that approach is not available to you? > > > > And, of course, there is always the option of upgrading to jdk11u. > > Eventually, that is going to be needed to resolve more and more of the > > problems remaining in jdk8u. > > > > Perhaps Andrew Haley or Christoph Langer might be able to comment on > > this? > > > > 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 denghui.ddh at alibaba-inc.com Tue Sep 24 13:37:06 2019 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Tue, 24 Sep 2019 21:37:06 +0800 Subject: =?UTF-8?B?UmU6IFs4dV0gUkZSIGJhY2twb3J0IG9mIEpESy04MTk4NDIzOiBJbXByb3ZlIG1ldGFzcGFj?= =?UTF-8?B?ZSBjaHVuayBhbGxvY2F0aW9u?= In-Reply-To: References: <28ec3851-73c9-45d4-9d97-f5c4d83b8f8d.denghui.ddh@alibaba-inc.com> , Message-ID: <84ce2b29-2af4-4230-9be5-76ae68f26479.denghui.ddh@alibaba-inc.com> Hi, In fact, i have found some application in our production environment occurred the problem mentioned in my first email, What they have in common is that they use a lot of small groovy or scripts., with a lot of classes loading and unloading, there are many 4k(Small for no-klass) chunks in used or in freelist. So we backport JDK-8198423 to our in-house jdk, and it produced some good results. As Andrew said, we can increase the MaxMetaspaceSize or upgrad to jdk11u, but it is difficult to do these changes for some reasons. Finally, i quite agree with your point of view. Thanks, Denghui Dong ------------------------------------------------------------------ From:Thomas St?fe Send Time:2019?9?24?(???) 20:40 To:"Langer, Christoph" Cc:Andrew Dinn ; ???(??) ; jdk8u-dev at openjdk.java.net ; Andrew Haley ; Andrew John Hughes Subject:Re: [8u] RFR backport of JDK-8198423: Improve metaspace chunk allocation I agree with Andrew that backporting JDK-8198423 is a large effort and a bit risky. If that has not been clear from my first mail I recommend against it. As for JDK-8221173, lets see how that pans out. I plan to bring it at least to SapMachine11, upstream 11 if it makes sense. But this is still in the future. Cheers, Thomas On Tue, Sep 24, 2019 at 2:22 PM Langer, Christoph wrote: Hi, from a technical perspective, Thomas Stuefe is probably the right contact for this backport. And I see, he has already commented on it. Whether it is appropriate for OpenJDK 8u and can make it there, you'll probably have to convince Andrew Haley and Andrew Hughes. I'm not a maintainer for 8u. Best regards Christoph > -----Original Message----- > From: Andrew Dinn > Sent: Dienstag, 24. September 2019 11:56 > To: Denghui Dong ; jdk8u- > dev at openjdk.java.net; Andrew Haley ; Langer, > Christoph > Subject: Re: [8u] RFR backport of JDK-8198423: Improve metaspace chunk > allocation > > On 23/09/2019 10:49, Denghui Dong wrote: > > Hi all, > > I'd like to request a backport of JDK-8198423. > > I found some long-time running application will oom caused by metaspace > if > > the application loads / unloads classes (by different classloaders) > frequently, > > even if there are many free chunks in freelist. > > . . . > > This patch doesn't apply cleanly to 8u-dev, if you think this backport is > reasonable, > > i will provide my webrev. > > What's your comments? > I think backporting this patch is probably a bad idea. It is a large and > complex change to a critical part of the JVM runtime so the risk > involved is quite high. > > Likewise I would expect that backporting whatever eventually gets done > under JDK-8221173 is going to be equally risky. > > It might help if you could give an idea of how much of a problem this > is. I can see how very long-running apps might suffer from fragmentation > of metadata space without the patch. Is this something you are seeing > regularly or intermittently? > > I would expect that allocating more memory to the JVM can be used as a > workaround to delay the onset/lower the frequency of this problem. Is > there a reason why that approach is not available to you? > > And, of course, there is always the option of upgrading to jdk11u. > Eventually, that is going to be needed to resolve more and more of the > problems remaining in jdk8u. > > Perhaps Andrew Haley or Christoph Langer might be able to comment on > this? > > 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 thomas.stuefe at gmail.com Tue Sep 24 13:52:02 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 24 Sep 2019 15:52:02 +0200 Subject: [8u] RFR backport of JDK-8198423: Improve metaspace chunk allocation In-Reply-To: <84ce2b29-2af4-4230-9be5-76ae68f26479.denghui.ddh@alibaba-inc.com> References: <28ec3851-73c9-45d4-9d97-f5c4d83b8f8d.denghui.ddh@alibaba-inc.com> <84ce2b29-2af4-4230-9be5-76ae68f26479.denghui.ddh@alibaba-inc.com> Message-ID: So, you already backported JDK-8198423 inhouse and got it working? -- About your scenario, I remember that Zhengyu Gu added a small patch for JDK 10 reducing the chunk size for anonymous classes from 4K to 1K ( https://bugs.openjdk.java.net/browse/JDK-8190729). That one would be easy to downport to jdk8 and might alleviate the pain a little. Cheers, Thomas On Tue, Sep 24, 2019 at 3:39 PM Denghui Dong wrote: > Hi, > In fact, i have found some application in our production environment > occurred the problem mentioned in my first email, > What they have in common is that they use a lot of small groovy or > scripts., with a lot of classes loading and unloading, there are > many 4k(Small for no-klass) chunks in used or in freelist. So we backport > JDK-8198423 to our in-house jdk, and it produced some good results. > As Andrew said, we can increase the MaxMetaspaceSize or upgrad to > jdk11u, but it is difficult to do these changes for some reasons. > Finally, i quite agree with your point of view. > > Thanks, > Denghui Dong > ------------------------------------------------------------------ > From:Thomas St?fe > Send Time:2019?9?24?(???) 20:40 > To:"Langer, Christoph" > Cc:Andrew Dinn ; ???(??) ; > jdk8u-dev at openjdk.java.net ; Andrew Haley < > aph at redhat.com>; Andrew John Hughes > Subject:Re: [8u] RFR backport of JDK-8198423: Improve metaspace chunk > allocation > > I agree with Andrew that backporting JDK-8198423 is a large effort and a > bit risky. If that has not been clear from my first mail I recommend > against it. > > As for JDK-8221173, lets see how that pans out. I plan to bring it at > least to SapMachine11, upstream 11 if it makes sense. But this is still in > the future. > > Cheers, Thomas > > > On Tue, Sep 24, 2019 at 2:22 PM Langer, Christoph < > christoph.langer at sap.com> wrote: > Hi, > > from a technical perspective, Thomas Stuefe is probably the right contact > for this backport. And I see, he has already commented on it. > > Whether it is appropriate for OpenJDK 8u and can make it there, you'll > probably have to convince Andrew Haley and Andrew Hughes. I'm not a > maintainer for 8u. > > Best regards > Christoph > > > -----Original Message----- > > From: Andrew Dinn > > Sent: Dienstag, 24. September 2019 11:56 > > To: Denghui Dong ; jdk8u- > > dev at openjdk.java.net; Andrew Haley ; Langer, > > Christoph > > Subject: Re: [8u] RFR backport of JDK-8198423: Improve metaspace chunk > > allocation > > > > On 23/09/2019 10:49, Denghui Dong wrote: > > > Hi all, > > > I'd like to request a backport of JDK-8198423. > > > I found some long-time running application will oom caused by > metaspace > > if > > > the application loads / unloads classes (by different classloaders) > > frequently, > > > even if there are many free chunks in freelist. > > > . . . > > > This patch doesn't apply cleanly to 8u-dev, if you think this > backport is > > reasonable, > > > i will provide my webrev. > > > What's your comments? > > I think backporting this patch is probably a bad idea. It is a large and > > complex change to a critical part of the JVM runtime so the risk > > involved is quite high. > > > > Likewise I would expect that backporting whatever eventually gets done > > under JDK-8221173 is going to be equally risky. > > > > It might help if you could give an idea of how much of a problem this > > is. I can see how very long-running apps might suffer from fragmentation > > of metadata space without the patch. Is this something you are seeing > > regularly or intermittently? > > > > I would expect that allocating more memory to the JVM can be used as a > > workaround to delay the onset/lower the frequency of this problem. Is > > there a reason why that approach is not available to you? > > > > And, of course, there is always the option of upgrading to jdk11u. > > Eventually, that is going to be needed to resolve more and more of the > > problems remaining in jdk8u. > > > > Perhaps Andrew Haley or Christoph Langer might be able to comment on > > this? > > > > 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 denghui.ddh at alibaba-inc.com Tue Sep 24 14:11:43 2019 From: denghui.ddh at alibaba-inc.com (=?UTF-8?B?6JGj55m76L6JKOWNk+aYgik=?=) Date: Tue, 24 Sep 2019 22:11:43 +0800 Subject: =?UTF-8?B?UmU6IFs4dV0gUkZSIGJhY2twb3J0IG9mIEpESy04MTk4NDIzOiBJbXByb3ZlIG1ldGFzcGFj?= =?UTF-8?B?ZSBjaHVuayBhbGxvY2F0aW9u?= In-Reply-To: References: <28ec3851-73c9-45d4-9d97-f5c4d83b8f8d.denghui.ddh@alibaba-inc.com> <84ce2b29-2af4-4230-9be5-76ae68f26479.denghui.ddh@alibaba-inc.com>, Message-ID: Hi Thomas, Yes, we also include JDK-8190729 and make _small_chunk_limit configurable, but we think it's more important to support merge/split chunk. By the way, anonymous metaspace is most used in lamda in my experience. Thanks Denghui Dong ------------------------------------------------------------------ From:Thomas St?fe Send Time:2019?9?24?(???) 21:52 To:???(??) ; jdk8u-dev at openjdk.java.net Subject:Re: [8u] RFR backport of JDK-8198423: Improve metaspace chunk allocation So, you already backported JDK-8198423 inhouse and got it working? -- About your scenario, I remember that Zhengyu Gu added a small patch for JDK 10 reducing the chunk size for anonymous classes from 4K to 1K (https://bugs.openjdk.java.net/browse/JDK-8190729). That one would be easy to downport to jdk8 and might alleviate the pain a little. Cheers, Thomas On Tue, Sep 24, 2019 at 3:39 PM Denghui Dong wrote: Hi, In fact, i have found some application in our production environment occurred the problem mentioned in my first email, What they have in common is that they use a lot of small groovy or scripts., with a lot of classes loading and unloading, there are many 4k(Small for no-klass) chunks in used or in freelist. So we backport JDK-8198423 to our in-house jdk, and it produced some good results. As Andrew said, we can increase the MaxMetaspaceSize or upgrad to jdk11u, but it is difficult to do these changes for some reasons. Finally, i quite agree with your point of view. Thanks, Denghui Dong ------------------------------------------------------------------ From:Thomas St?fe Send Time:2019?9?24?(???) 20:40 To:"Langer, Christoph" Cc:Andrew Dinn ; ???(??) ; jdk8u-dev at openjdk.java.net ; Andrew Haley ; Andrew John Hughes Subject:Re: [8u] RFR backport of JDK-8198423: Improve metaspace chunk allocation I agree with Andrew that backporting JDK-8198423 is a large effort and a bit risky. If that has not been clear from my first mail I recommend against it. As for JDK-8221173, lets see how that pans out. I plan to bring it at least to SapMachine11, upstream 11 if it makes sense. But this is still in the future. Cheers, Thomas On Tue, Sep 24, 2019 at 2:22 PM Langer, Christoph wrote: Hi, from a technical perspective, Thomas Stuefe is probably the right contact for this backport. And I see, he has already commented on it. Whether it is appropriate for OpenJDK 8u and can make it there, you'll probably have to convince Andrew Haley and Andrew Hughes. I'm not a maintainer for 8u. Best regards Christoph > -----Original Message----- > From: Andrew Dinn > Sent: Dienstag, 24. September 2019 11:56 > To: Denghui Dong ; jdk8u- > dev at openjdk.java.net; Andrew Haley ; Langer, > Christoph > Subject: Re: [8u] RFR backport of JDK-8198423: Improve metaspace chunk > allocation > > On 23/09/2019 10:49, Denghui Dong wrote: > > Hi all, > > I'd like to request a backport of JDK-8198423. > > I found some long-time running application will oom caused by metaspace > if > > the application loads / unloads classes (by different classloaders) > frequently, > > even if there are many free chunks in freelist. > > . . . > > This patch doesn't apply cleanly to 8u-dev, if you think this backport is > reasonable, > > i will provide my webrev. > > What's your comments? > I think backporting this patch is probably a bad idea. It is a large and > complex change to a critical part of the JVM runtime so the risk > involved is quite high. > > Likewise I would expect that backporting whatever eventually gets done > under JDK-8221173 is going to be equally risky. > > It might help if you could give an idea of how much of a problem this > is. I can see how very long-running apps might suffer from fragmentation > of metadata space without the patch. Is this something you are seeing > regularly or intermittently? > > I would expect that allocating more memory to the JVM can be used as a > workaround to delay the onset/lower the frequency of this problem. Is > there a reason why that approach is not available to you? > > And, of course, there is always the option of upgrading to jdk11u. > Eventually, that is going to be needed to resolve more and more of the > problems remaining in jdk8u. > > Perhaps Andrew Haley or Christoph Langer might be able to comment on > this? > > 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 denghui.ddh at alibaba-inc.com Wed Sep 25 06:25:08 2019 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Wed, 25 Sep 2019 14:25:08 +0800 Subject: =?UTF-8?B?Wzh1XSBSRlIgYmFja3BvcnQgb2YgSkRLLTgxNDQ3MzI6IFZNX0hlYXBEdW1wZXIgaGl0cyBh?= =?UTF-8?B?c3NlcnQgd2l0aCBiYWQgZHVtcF9sZW4=?= Message-ID: <78672c52-2587-4e01-98d9-350c9239fe48.denghui.ddh@alibaba-inc.com> Hi all, I'd like to request a backport of JDK-8144732. In our production environment, many application use large heap, and there are some big arrays in the heap. When developers use jmap to dump heap, and use Eclipse MAT(mostly) or jhat to analyze the file, often got error. For example: public class BigArray { public static void main(String[] args) throws Exception { long[] b = new long[1024 * 1024 * 1024 / 2]; Object o = new Object(); synchronized(o) { o.wait(60000); } } } If you run the above code, and use jmap to generate a dump file, then use jhat to parse it, you will got a warning message: "WARNING: Error reading heap dump or heap dump segment: Byte count is -4294967296 instead of 0" Eclipse MAT also can't parse the dump file correctly. The root cause is the length of the segment exceeds the limit. I found that JDK-8144732 can resolve this problem, because it can truncate the array whose size is too large and ensure a segment length within limit. The patch (from JDK9) doesn't apply cleanly. Original bug: https://bugs.openjdk.java.net/browse/JDK-8150432 Original patch: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/91a26000bfb5 My webrev: http://cr.openjdk.java.net/~luchsh/8144732_8u/ Testing: jdk/test/demo/jvmti/hprof/HeapDumpTest.java passed. jdk/test/sun/tools/jhat/HatHeapDump1Test.java passed. What's your comments ? Thanks Denghui Dong From thomas.stuefe at gmail.com Wed Sep 25 07:11:42 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 25 Sep 2019 09:11:42 +0200 Subject: [8u] RFR backport of JDK-8198423: Improve metaspace chunk allocation In-Reply-To: References: <28ec3851-73c9-45d4-9d97-f5c4d83b8f8d.denghui.ddh@alibaba-inc.com> <84ce2b29-2af4-4230-9be5-76ae68f26479.denghui.ddh@alibaba-inc.com> Message-ID: Hi Denghui, interesting. Happy my patch helped you. The new implementation uses buddy allocation for metaspace chunks. Decreases fragmentation and waste overhead, and chunks get committed on demand and uncommitted when free, so the cost for free lists greatly decreases. Cheers, Thomas On Tue, Sep 24, 2019 at 4:11 PM ???(??) wrote: > Hi Thomas, > Yes, we also include JDK-8190729 > and make > _small_chunk_limit configurable, but we think it's more important to > support merge/split chunk. > By the way, anonymous metaspace is most used in lamda in my experience. > > Thanks > Denghui Dong > > ------------------------------------------------------------------ > From:Thomas St?fe > Send Time:2019?9?24?(???) 21:52 > To:???(??) ; jdk8u-dev at openjdk.java.net < > jdk8u-dev at openjdk.java.net> > Subject:Re: [8u] RFR backport of JDK-8198423: Improve metaspace chunk > allocation > > So, you already backported JDK-8198423 inhouse and got it working? > > -- > > About your scenario, I remember that Zhengyu Gu added a small patch for > JDK 10 reducing the chunk size for anonymous classes from 4K to 1K ( > https://bugs.openjdk.java.net/browse/JDK-8190729). > > That one would be easy to downport to jdk8 and might alleviate the pain a > little. > > Cheers, Thomas > > > On Tue, Sep 24, 2019 at 3:39 PM Denghui Dong > wrote: > Hi, > In fact, i have found some application in our production environment > occurred the problem mentioned in my first email, > What they have in common is that they use a lot of small groovy or > scripts., with a lot of classes loading and unloading, there are > many 4k(Small for no-klass) chunks in used or in freelist. So we backport > JDK-8198423 to our in-house jdk, and it produced some good results. > As Andrew said, we can increase the MaxMetaspaceSize or upgrad to > jdk11u, but it is difficult to do these changes for some reasons. > Finally, i quite agree with your point of view. > > Thanks, > Denghui Dong > ------------------------------------------------------------------ > From:Thomas St?fe > Send Time:2019?9?24?(???) 20:40 > To:"Langer, Christoph" > Cc:Andrew Dinn ; ???(??) ; > jdk8u-dev at openjdk.java.net ; Andrew Haley < > aph at redhat.com>; Andrew John Hughes > Subject:Re: [8u] RFR backport of JDK-8198423: Improve metaspace chunk > allocation > > I agree with Andrew that backporting JDK-8198423 is a large effort and a > bit risky. If that has not been clear from my first mail I recommend > against it. > > As for JDK-8221173, lets see how that pans out. I plan to bring it at > least to SapMachine11, upstream 11 if it makes sense. But this is still in > the future. > > Cheers, Thomas > > > On Tue, Sep 24, 2019 at 2:22 PM Langer, Christoph < > christoph.langer at sap.com> wrote: > Hi, > > from a technical perspective, Thomas Stuefe is probably the right contact > for this backport. And I see, he has already commented on it. > > Whether it is appropriate for OpenJDK 8u and can make it there, you'll > probably have to convince Andrew Haley and Andrew Hughes. I'm not a > maintainer for 8u. > > Best regards > Christoph > > > -----Original Message----- > > From: Andrew Dinn > > Sent: Dienstag, 24. September 2019 11:56 > > To: Denghui Dong ; jdk8u- > > dev at openjdk.java.net; Andrew Haley ; Langer, > > Christoph > > Subject: Re: [8u] RFR backport of JDK-8198423: Improve metaspace chunk > > allocation > > > > On 23/09/2019 10:49, Denghui Dong wrote: > > > Hi all, > > > I'd like to request a backport of JDK-8198423. > > > I found some long-time running application will oom caused by > metaspace > > if > > > the application loads / unloads classes (by different classloaders) > > frequently, > > > even if there are many free chunks in freelist. > > > . . . > > > This patch doesn't apply cleanly to 8u-dev, if you think this > backport is > > reasonable, > > > i will provide my webrev. > > > What's your comments? > > I think backporting this patch is probably a bad idea. It is a large and > > complex change to a critical part of the JVM runtime so the risk > > involved is quite high. > > > > Likewise I would expect that backporting whatever eventually gets done > > under JDK-8221173 is going to be equally risky. > > > > It might help if you could give an idea of how much of a problem this > > is. I can see how very long-running apps might suffer from fragmentation > > of metadata space without the patch. Is this something you are seeing > > regularly or intermittently? > > > > I would expect that allocating more memory to the JVM can be used as a > > workaround to delay the onset/lower the frequency of this problem. Is > > there a reason why that approach is not available to you? > > > > And, of course, there is always the option of upgrading to jdk11u. > > Eventually, that is going to be needed to resolve more and more of the > > problems remaining in jdk8u. > > > > Perhaps Andrew Haley or Christoph Langer might be able to comment on > > this? > > > > 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 denghui.ddh at alibaba-inc.com Wed Sep 25 08:02:07 2019 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Wed, 25 Sep 2019 16:02:07 +0800 Subject: =?UTF-8?B?UmU6IFs4dV0gUkZSIGJhY2twb3J0IG9mIEpESy04MTQ0NzMyOiBWTV9IZWFwRHVtcGVyIGhp?= =?UTF-8?B?dHMgYXNzZXJ0IHdpdGggYmFkIGR1bXBfbGVu?= In-Reply-To: <78672c52-2587-4e01-98d9-350c9239fe48.denghui.ddh@alibaba-inc.com> References: <78672c52-2587-4e01-98d9-350c9239fe48.denghui.ddh@alibaba-inc.com> Message-ID: <3311cb47-2b6d-4172-a579-d3bb4cf6de65.denghui.ddh@alibaba-inc.com> A correction: Original bug: https://bugs.openjdk.java.net/browse/JDK-8144732 Thanks Denghui Dong ------------------------------------------------------------------ From:???(??) Send Time:2019?9?25?(???) 14:25 To:jdk8u-dev Subject:[8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len Hi all, I'd like to request a backport of JDK-8144732. In our production environment, many application use large heap, and there are some big arrays in the heap. When developers use jmap to dump heap, and use Eclipse MAT(mostly) or jhat to analyze the file, often got error. For example: public class BigArray { public static void main(String[] args) throws Exception { long[] b = new long[1024 * 1024 * 1024 / 2]; Object o = new Object(); synchronized(o) { o.wait(60000); } } } If you run the above code, and use jmap to generate a dump file, then use jhat to parse it, you will got a warning message: "WARNING: Error reading heap dump or heap dump segment: Byte count is -4294967296 instead of 0" Eclipse MAT also can't parse the dump file correctly. The root cause is the length of the segment exceeds the limit. I found that JDK-8144732 can resolve this problem, because it can truncate the array whose size is too large and ensure a segment length within limit. The patch (from JDK9) doesn't apply cleanly. Original bug: https://bugs.openjdk.java.net/browse/JDK-8150432 Original patch: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/91a26000bfb5 My webrev: http://cr.openjdk.java.net/~luchsh/8144732_8u/ Testing: jdk/test/demo/jvmti/hprof/HeapDumpTest.java passed. jdk/test/sun/tools/jhat/HatHeapDump1Test.java passed. What's your comments ? Thanks Denghui Dong From kshefov at azul.com Wed Sep 25 10:19:17 2019 From: kshefov at azul.com (Konstantin Shefov) Date: Wed, 25 Sep 2019 10:19:17 +0000 Subject: Backport vmTestbase tests to jdk8u-dev? In-Reply-To: References: <9ba7e7af9a1645c4831610327c96f22b@azul.com> <51653b0b3223448bbe2f9186d11556af@azul.com> <1568829532868.82475@amazon.com> <0CFA2C19-FD39-4DDF-99E8-FB5B43936AFE@azul.com> <48213D1C-7CE4-41E9-B799-1E8A199846A0@amazon.com> <104bc421591046c8a4e7c2edcb962d81@azul.com>, <1569222717555.22304@amazon.com> <58139b1e7a454e8ca48d4046001cf7b5@azul.com> Message-ID: <7478c13cb1ca4d1293fc8ab5b300ff04@azul.com> Hi Here is one more patch from Azul side: http://cr.openjdk.java.net/~kshefov/vmTestbase_8_azul_contrib_2/webrev/ This patch is supposed to be applied just after "azul_contrib" patch sent by Liu Xin. The list of changes is the following: 1) Removed unused code from hotspot/test/test/lib folder (we ran all tests after that, nothing breaks); 2) Fixed some tests so they work with JDK 8 (they used JDK 13 API, so had to refactor); 3) Removed tests that test "Compact String" feature, which is not available in JDK 8; 4) Made a small change in test/JtregNativeHotspot.gmk file so that now native test libs are automatically copied to jdk8u-dev/build//images/test directory exactly as it is done in JDK 11+. In JDK 8 "TEST_IMAGE_DIR" variable is not defined, so it was replaced by "$(IMAGES_OUTPUTDIR)/test". With all changes provided by Liu Xin and the patch provided here we think it can be pushed. Thanks, --Konstantin -----Original Message----- From: Konstantin Shefov Sent: Monday, September 23, 2019 6:30 PM To: 'Liu, Xin' ; 'jdk8u-dev at openjdk.java.net' Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, Liu Xin After applying all the patches, I have successfully built the native part, but I had to do some more changes. After all tests run, I will prepare one more patch "azul_contrib_2" and send it here. Konstantin -----Original Message----- From: Konstantin Shefov Sent: Monday, September 23, 2019 4:47 PM To: 'Liu, Xin' ; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, Liu Xin Thank you for combining our patch with yours, we will test the whole chain of patches to work at our side. As an answer to your question about modification from 0x21 to 0x2e at earlyretint.c. Java class file format has changed between JDK 8 and JDK 11+. In earlyretint.c from JDK 11+ we have the following line: "jlocation loc_exp = (i == 0) ? 0x21 : 0xd; " This "loc_exp" is an expected location of instruction inside a java method (see and [1] and [2]). By the test scenario we breakpoint inside countDownBoolean(I)V method after checkPoint()V method. In Java 8 the number of instruction before which we breakpoint is 0x2e (hex) and 46 (decimal). In Java 11+ the number of instruction before which we breakpoint is 0x21 (hex) and 33 (decimal). That is why we have to change the test here. [1] https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#SingleStep [2] https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#jlocation Regards, Konstantin -----Original Message----- From: Liu, Xin Sent: Monday, September 23, 2019 10:13 AM To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? hi, Konstantin, I also apply your patch to the last webrev. eventually, JDK-8231089 consists of 6 patches. now I think it's easier to review it. https://cr.openjdk.java.net/~xliu/8231089/ We should apply them in order. 1. base 2. apiChanges 3. classFileInstaller 4. gclog 5. native_libraries 6. azul_contrib for your patch, i keep it everything except for -Xloggc. Could you tell me why you modify from 0x21 to 0x2e? diff -r 95eb898ada95 -r 6c35ac679aa8 test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c --- a/test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c Thu Sep 19 17:30:08 2019 +0300 +++ b/test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c Thu Sep 19 17:35:58 2019 +0300 @@ -89,7 +89,7 @@ jlocation loc, jint i) { jvmtiError err; jclass cls; - jlocation loc_exp = (i == 0) ? 0x21 : 0xd; + jlocation loc_exp = (i == 0) ? 0x2e : 0xd; char *sigClass, *name, *sig, *generic; jvmtiLocalVariableEntry *table = NULL; jint entryCount = 0; ________________________________________ From: jdk8u-dev on behalf of Liu, Xin Sent: Saturday, September 21, 2019 4:48 AM To: Konstantin Shefov; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, As I promised, here is the refactored webrev for native compilation Hotspot: https://cr.openjdk.java.net/~xliu/8231089/native_libraries/hotspot/webrev/ root: https://cr.openjdk.java.net/~xliu/8231089/native_libraries/root/webrev/ so the new target 'test-image' is added. to fix https://gist.github.com/navyxliu/bacd47891b17ac8d33d04708b648b531, I added "LDFLAGS_SUFFIX := $$(LIBCXX), " to TestFilesCompilation.gmk. Thanks, --lx From: Konstantin Shefov Date: Friday, September 20, 2019 at 11:01 AM To: "Liu, Xin" , "jdk8u-dev at openjdk.java.net" Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, Liu Xin > I am refactoring makefiles. I plan to upload this webrev today. Fine! We will try to compile with our toolchains. >> BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. > Could you give me an example tests for this? One example is this https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/ConflictingDefaultsTest.java#L329 And most of vmTestbase/vm/runtime/defmeth tests seem to test JVM spec in some way. See here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L50 and here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L134 Konstantin From: Liu, Xin Sent: Friday, September 20, 2019 8:35 PM To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Konstantin, I am refactoring makefiles. I plan to upload this webrev today. I found that you have solved almost all problems. I can help to troubleshoot the remaining tests. >BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. Could you give me an example tests for this? Thanks, --lx From: Konstantin Shefov > Date: Friday, September 20, 2019 at 2:26 AM To: "Liu, Xin" >, "jdk8u-dev at openjdk.java.net" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, We will use your new patches to run tests and merge my changes with yours for those tests that will not work. BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. I see your webrevs do not contain native part build scripts for now. We have to address this problem so the scripts should work for older GCC versions also. Regards Konstantin From: "Liu, Xin" > Date: Wednesday, 18 September 2019 at 20:59 To: Konstantin Shefov >, "jdk8u-dev at openjdk.java.net" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, thank you for updating. We care about x86_64 and aarch64 as well. You ran more tests than us. we never run all vmTestbase. Previously, I used a ProblemList.txt file to screen Problem and move on. Do you plan to fix all problems before we check in? Back to refactor, I have filed a JBS issues. https://bugs.openjdk.java.net/browse/JDK-8231089 In the meanwhile, I start splitting the commits to individual hg changesets. https://cr.openjdk.java.net/~xliu/8231089/ 1. base -> copy code from tag jdk-14+14 intact commit for vmTestbase and testlib 2. make apiChanges for ProcessUtils and Unsafe Could you review it? 3. ClassFileInstaller needs /testlibrary it's because ClassFileInstaller is in /test/testlibrary. I use this script to install @library /testlibrary for all tests. out=$(grep "ClassFileInstaller" -R vmTestbase | awk '{print $1}') for i in $out; do f=${i%\:} gsed -i 's/@library \/vmTestbase/&\n * \/testlibrary/' $f done What do you think that this approach? If I got something wrong, we can update the webtrev with yours. thanks, --lx ________________________________ From: Konstantin Shefov > Sent: Wednesday, September 18, 2019 4:56 PM To: Liu, Xin; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi We ran the tests against x86_64 Ubuntu Linux and there are just the same failed tests as it was with Arm64 Ubuntu Linux plus 2 more tests: vmTestbase/gc/lock/jni/jnilock002/TestDescription.java vmTestbase/nsk/jdb/set/set001/set001.java Konstantin From: Konstantin Shefov Sent: Wednesday, September 11, 2019 10:53 AM To: 'Liu, Xin' >; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, LX Answering to your e-mail, as for what we modified in [3]: 1. API changes (Process, Unsafe), Xloggc option, that were not in your patches; 2. In a file hotspot/test/JtregNativeHotspot.gmk we changed "-lpthread" option to "-pthread" to prevent compilation error. I agree that there should be a series of patches to track file changes. As for investigation of failures: do you have the same? We ran against Arm64 platform, but we can try against x86-64 too. Konstantin From: Liu, Xin > Sent: Monday, September 9, 2019 11:04 PM To: Konstantin Shefov >; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, We are glad to work with you to get vmTestbase landed into jdk8u. Our original intent is get design reviewed by the jdk8u maintainer. After then, we can proceed to refactor it. We can work together to refactor it. we plan to do it anyway. Back to the webrev you send. What did you modify in [3]? Ideally, we can should have a series of patches. The first one should be intact vmTestbase code from the tip of JDK. All we changes should come after it and be reviewed by this mail-list. In addition to refactoring, we can also offer help to figure out those failed cases. What do you think? Thanks, --lx From: Konstantin Shefov > Date: Friday, September 6, 2019 at 12:55 PM To: "jdk8u-dev at openjdk.java.net" > Cc: "Liu, Xin" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, We at Azul think it is a good idea to backport vmTestbase tests to OpenJDK 8. We have used patches you suggested, done some refactoring to enable more tests to work with JDK 8. We have run all 3550 tests from "vmTestbase" folder against Zulu 8 at ARM64 platform: 1. 3371 tests PASS (see [1]); 2. 179 tests FAIL (see [2]): reasons are being investigated. Patches we have used (contain our refactoring): 1. Hotspot folder [3] 2. Main folder [4] We plan to investigate causes of those 177 failures, purify unused code from hotspot/test/test/lib/jdk, and run the tests against different platforms. We also compared vmTestbase from JDK 11 with that from JDK 13, we found out: 1. 332 test have been removed in JDK 13; 2. Only 2 test have been added in JDK 13; 3. Tests that remained were modified, but these modifications mostly are copyright years, or output format, or API changes. >From the above results we can tell that vmTestbase does not grow. It looks like that tests are been removed from there or transferred somewhere else. [1] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/passed_tests.html [2] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/failed_tests.html [3] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_hotspot.patch [4] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_root.patch Regards, --Konstantin From zgu at redhat.com Wed Sep 25 11:06:02 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 25 Sep 2019 07:06:02 -0400 Subject: [8u] 8178870: instrumentation.retransformClasses cause coredump In-Reply-To: <034e3ee3-fae6-f14c-fd23-3dbe6f10f277@redhat.com> References: <6d646175-68e2-b280-6475-cd97f2e5d438@redhat.com> <7003c233-d891-b11b-3426-f9b6f7de2d8f@redhat.com> <0bfedafb-f31c-6278-31da-56cb4abc1d34@redhat.com> <03cd4243-91e7-fb9f-5b5b-bbacf1de547d@redhat.com> <241f6d60-0392-4225-61aa-706dfb62e194@redhat.com> <79be4136-9e79-8552-a041-eb525f036dbf@redhat.com> <558f30e9-939d-ce1c-dda4-877857ce97e7@redhat.com> <37BA6F70-74A1-4BF0-A860-4EBFBFDFF2F7@amazon.com> <034e3ee3-fae6-f14c-fd23-3dbe6f10f277@redhat.com> Message-ID: <1bd4edec-4e96-6742-595b-b2dccbd91eb8@redhat.com> Hi David, Do you still have problems other than the wrong test name? Andrew, Aleksey: What's the process to fix this bad test? Sorry for the troubles. Thanks, -Zhengyu On 9/24/19 8:18 AM, Zhengyu Gu wrote: > > > On 9/23/19 9:07 PM, Alvarez, David wrote: >> Hi, >> >> After importing jdk8u232-b06 we are seeing two new failures in jtreg >> apparently >> caused by this change. >> >> Affected tests are: >> runtime/RedefineTests/test8178870.sh >> runtime/RedefineTests/RedefineDoubleDelete.java >> >> test8178870.sh fails because it is defined as test.sh in the jtreg >> section. > Oops, I did make stupid last minute name change. But other than that, > test runs fine for me. > > diff -r 7d5c800dae75 test/runtime/RedefineTests/test8178870.sh > --- a/test/runtime/RedefineTests/test8178870.sh Tue Sep 10 19:58:22 2019 > +0200 > +++ b/test/runtime/RedefineTests/test8178870.sh Tue Sep 24 08:17:05 2019 > -0400 > @@ -26,7 +26,7 @@ > ?## @test test.sh > ?## @bug 8178870 > ?## @summary test instrumentation.retransformClasses > -## @run shell test.sh > +## @run shell test8178870.sh > > ?if [ "${TESTSRC}" = "" ] > ?then > > > > [zgu at localhost jdk8u-dev]$ ~/jtreg/bin/jtreg > -jdk:/home/zgu/ws/jdk8u-dev/build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image/ > hotspot/test/runtime/RedefineTests/test8178870.sh > Directory "JTwork" not found: creating > Directory "JTreport" not found: creating > Test results: passed: 1 > Report written to /home/zgu/ws/jdk8u-dev/JTreport/html/report.html > Results written to /home/zgu/ws/jdk8u-dev/JTwork > > > -Zhengyu > > >> Fixing this will allow the test to run, but it will still fail later >> with a >> ClassNotFoundException. >> >> RedefineDoubleDelete will fail during compilation locating >> RedefineClassHelper >> as it does not have @library defined, but after adding it will still >> fail with >> an NPE. >> >> -- >> David Alvarez >> >> >> ?On 2019-09-12, 09:47, "jdk8u-dev on behalf of Andrew John Hughes" >> > gnu.andrew at redhat.com> wrote: >> >> ???? On 12/09/2019 13:28, Zhengyu Gu wrote: >> ???? snip... >> ???? >>>> >> ???? >> >> ???? >> This looks ok. I presume you intend to commit with the correct >> metadata, >> ???? >> as currently it says "imported patch JDK-8178870_coredump.patch"? >> ???? > >> ???? > Of course. Otherwise, it won't push. >> ???? > >> ???? Running jcheck locally [0], I can't even commit something like >> that :) >> ???? Just wanted to be sure. >> ???? [0] https://openjdk.java.net/projects/code-tools/jcheck/ >> ???? 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 Sep 25 11:07:55 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 25 Sep 2019 13:07:55 +0200 Subject: [8u] 8178870: instrumentation.retransformClasses cause coredump In-Reply-To: <1bd4edec-4e96-6742-595b-b2dccbd91eb8@redhat.com> References: <6d646175-68e2-b280-6475-cd97f2e5d438@redhat.com> <7003c233-d891-b11b-3426-f9b6f7de2d8f@redhat.com> <0bfedafb-f31c-6278-31da-56cb4abc1d34@redhat.com> <03cd4243-91e7-fb9f-5b5b-bbacf1de547d@redhat.com> <241f6d60-0392-4225-61aa-706dfb62e194@redhat.com> <79be4136-9e79-8552-a041-eb525f036dbf@redhat.com> <558f30e9-939d-ce1c-dda4-877857ce97e7@redhat.com> <37BA6F70-74A1-4BF0-A860-4EBFBFDFF2F7@amazon.com> <034e3ee3-fae6-f14c-fd23-3dbe6f10f277@redhat.com> <1bd4edec-4e96-6742-595b-b2dccbd91eb8@redhat.com> Message-ID: <2f967719-c1c4-bf45-d0d3-28cd3a841e80@redhat.com> On 9/25/19 1:06 PM, Zhengyu Gu wrote: > Andrew, Aleksey: > What's the process to fix this bad test? Sorry for the troubles. The same process, you just need a new issue that targets openjdk8u232, RFR it here, add jdk8u-critical-request. -- Thanks, -Aleksey From zgu at redhat.com Wed Sep 25 11:13:47 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 25 Sep 2019 07:13:47 -0400 Subject: [8u] 8178870: instrumentation.retransformClasses cause coredump In-Reply-To: <2f967719-c1c4-bf45-d0d3-28cd3a841e80@redhat.com> References: <6d646175-68e2-b280-6475-cd97f2e5d438@redhat.com> <7003c233-d891-b11b-3426-f9b6f7de2d8f@redhat.com> <0bfedafb-f31c-6278-31da-56cb4abc1d34@redhat.com> <03cd4243-91e7-fb9f-5b5b-bbacf1de547d@redhat.com> <241f6d60-0392-4225-61aa-706dfb62e194@redhat.com> <79be4136-9e79-8552-a041-eb525f036dbf@redhat.com> <558f30e9-939d-ce1c-dda4-877857ce97e7@redhat.com> <37BA6F70-74A1-4BF0-A860-4EBFBFDFF2F7@amazon.com> <034e3ee3-fae6-f14c-fd23-3dbe6f10f277@redhat.com> <1bd4edec-4e96-6742-595b-b2dccbd91eb8@redhat.com> <2f967719-c1c4-bf45-d0d3-28cd3a841e80@redhat.com> Message-ID: <647dee69-17c7-06c6-79ef-8e32278b6ea7@redhat.com> Thanks, Aleksey. I will wait David's reply to proceed. -Zhengyu On 9/25/19 7:07 AM, Aleksey Shipilev wrote: > On 9/25/19 1:06 PM, Zhengyu Gu wrote: >> Andrew, Aleksey: >> What's the process to fix this bad test? Sorry for the troubles. > The same process, you just need a new issue that targets openjdk8u232, RFR it here, add > jdk8u-critical-request. > From alvdavi at amazon.com Wed Sep 25 14:02:16 2019 From: alvdavi at amazon.com (Alvarez, David) Date: Wed, 25 Sep 2019 14:02:16 +0000 Subject: [8u] 8178870: instrumentation.retransformClasses cause coredump In-Reply-To: <647dee69-17c7-06c6-79ef-8e32278b6ea7@redhat.com> References: <6d646175-68e2-b280-6475-cd97f2e5d438@redhat.com> <7003c233-d891-b11b-3426-f9b6f7de2d8f@redhat.com> <0bfedafb-f31c-6278-31da-56cb4abc1d34@redhat.com> <03cd4243-91e7-fb9f-5b5b-bbacf1de547d@redhat.com> <241f6d60-0392-4225-61aa-706dfb62e194@redhat.com> <79be4136-9e79-8552-a041-eb525f036dbf@redhat.com> <558f30e9-939d-ce1c-dda4-877857ce97e7@redhat.com> <37BA6F70-74A1-4BF0-A860-4EBFBFDFF2F7@amazon.com> <034e3ee3-fae6-f14c-fd23-3dbe6f10f277@redhat.com> <1bd4edec-4e96-6742-595b-b2dccbd91eb8@redhat.com> <2f967719-c1c4-bf45-d0d3-28cd3a841e80@redhat.com> <647dee69-17c7-06c6-79ef-8e32278b6ea7@redhat.com> Message-ID: <655272AF-3042-4209-9A53-92713EBA1365@amazon.com> Hi, Sadly, applying your patch was not enough to make jtreg run: jtreg -v:summary -jdk:/home/alvdavi/hg/jdk8u/build/linux-x86_64-normal-server-release/images/j2sdk-image hotspot/test/runtime/RedefineTests Directory "JTwork" not found: creating Directory "JTreport" not found: creating Passed: runtime/RedefineTests/RedefineAnnotations.java FAILED: runtime/RedefineTests/RedefineDoubleDelete.java Passed: runtime/RedefineTests/RedefineFinalizer.java Passed: runtime/RedefineTests/RedefineInterfaceCall.java Passed: runtime/RedefineTests/RedefineRunningMethods.java Passed: runtime/RedefineTests/RedefineRunningMethodsWithResolutionErrors.java FAILED: runtime/RedefineTests/test8178870.sh Test results: passed: 5; failed: 2 This is in a jdk8u232-b07 vanilla build. I've fixed RedefineDoubleDelete.java by applying this: diff --git a/test/runtime/RedefineTests/RedefineDoubleDelete.java b/test/runtime/RedefineTests/Redefi --- a/test/runtime/RedefineTests/RedefineDoubleDelete.java +++ b/test/runtime/RedefineTests/RedefineDoubleDelete.java @@ -24,7 +24,11 @@ /* * @test * @bug 8178870 + * @library /testlibrary * @summary Redefine class with CFLH twice to test deleting the cached_class_file + * @build RedefineClassHelper + * @run main RedefineClassHelper + * @run main/othervm -javaagent:redefineagent.jar RedefineDoubleDelete */ For test8178870.sh, the situation is a little bit trickier. The test will pass if it is called directly, but it fails when called as part of a group. And I'm only able to consistently reproduce this behavior if I wipe out the JTwork folder in between runs: $ jtreg -v:summary -retain:none -jdk:/home/alvdavi/hg/jdk8u/build/linux-x86_64-normal-server-release/images/j2sdk-image hotspot/test/runtime/RedefineTests/test8178870.sh Directory "JTwork" not found: creating Directory "JTreport" not found: creating Passed: runtime/RedefineTests/test8178870.sh Test results: passed: 1 Report written to /local/home/alvdavi/hg/jdk8u/JTreport/html/report.html Results written to /local/home/alvdavi/hg/jdk8u/JTwork $ rm -rf JTreport JTwork $ jtreg -v:summary -retain:none -jdk:/home/alvdavi/hg/jdk8u/build/linux-x86_64-normal-server-release/images/j2sdk-image hotspot/test/runtime/RedefineTests/ Directory "JTwork" not found: creating Directory "JTreport" not found: creating Passed: runtime/RedefineTests/RedefineAnnotations.java Passed: runtime/RedefineTests/RedefineDoubleDelete.java Passed: runtime/RedefineTests/RedefineFinalizer.java Passed: runtime/RedefineTests/RedefineInterfaceCall.java Passed: runtime/RedefineTests/RedefineRunningMethods.java Passed: runtime/RedefineTests/RedefineRunningMethodsWithResolutionErrors.java FAILED: runtime/RedefineTests/test8178870.sh Test results: passed: 6; failed: 1 Report written to /local/home/alvdavi/hg/jdk8u/JTreport/html/report.html Results written to /local/home/alvdavi/hg/jdk8u/JTwork Error: Some tests failed or other problems occurred. Later today I will take a look. -- David ?On 2019-09-25, 04:14, "Zhengyu Gu" wrote: Thanks, Aleksey. I will wait David's reply to proceed. -Zhengyu On 9/25/19 7:07 AM, Aleksey Shipilev wrote: > On 9/25/19 1:06 PM, Zhengyu Gu wrote: >> Andrew, Aleksey: >> What's the process to fix this bad test? Sorry for the troubles. > The same process, you just need a new issue that targets openjdk8u232, RFR it here, add > jdk8u-critical-request. > From gnu.andrew at redhat.com Wed Sep 25 14:23:40 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 25 Sep 2019 15:23:40 +0100 Subject: [8u] 8178870: instrumentation.retransformClasses cause coredump In-Reply-To: <1bd4edec-4e96-6742-595b-b2dccbd91eb8@redhat.com> References: <6d646175-68e2-b280-6475-cd97f2e5d438@redhat.com> <7003c233-d891-b11b-3426-f9b6f7de2d8f@redhat.com> <0bfedafb-f31c-6278-31da-56cb4abc1d34@redhat.com> <03cd4243-91e7-fb9f-5b5b-bbacf1de547d@redhat.com> <241f6d60-0392-4225-61aa-706dfb62e194@redhat.com> <79be4136-9e79-8552-a041-eb525f036dbf@redhat.com> <558f30e9-939d-ce1c-dda4-877857ce97e7@redhat.com> <37BA6F70-74A1-4BF0-A860-4EBFBFDFF2F7@amazon.com> <034e3ee3-fae6-f14c-fd23-3dbe6f10f277@redhat.com> <1bd4edec-4e96-6742-595b-b2dccbd91eb8@redhat.com> Message-ID: <39df63b4-dc21-7d2f-27da-8483f73559a4@redhat.com> On 25/09/2019 12:06, Zhengyu Gu wrote: > Hi David, > > Do you still have problems other than the wrong test name? > > Andrew, Aleksey: > > What's the process to fix this bad test? Sorry for the troubles. > > Thanks, > > -Zhengyu > > Zhengyu, please file a new bug and post a patch ASAP, as freeze for 8u232 is due today. Once reviewed, it should be flagged jdk8u-critical-request. David, can you please confirm Zhengyu's fix makes the test work for you? I don't think this is a release showstopper, but it would be preferable to get it fixed if possible. 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 Sep 25 14:37:05 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 25 Sep 2019 15:37:05 +0100 Subject: [RFR] [8u] 8228469: (tz) Upgrade time-zone data to tzdata2019b Message-ID: <79ad8252-260b-5b2d-a5f4-7a129d3e9c32@redhat.com> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8228469/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8228469 This is the regular timezone data update for the next CPU. The only real difference from the patch for 11 & 14 is that I chose to keep with rearguard format for now. We can look at backporting JDK-8212970 for 8u242, but I don't want to make such a change at this late stage in 8u232. The effect of this is in make/data/tzdata/africa where the additions for Morocco don't use a negative offset and the context of the changes being applied differs slightly (some lines have to be commented out in rearguard, such as Ireland's negative offset) The rearguard version was created by downloading the tzdata2019b bundle and running 'make rearguard_tarballs' as specified in the bug text. This generated version was then compared against that from jdk11, with the only difference being those Morocco rules. The only other trivial change from jdk11 is in test/java/util/TimeZone/TimeZoneTest.java where the bug ID list is different. I also took the opportunity to drop the useless @modules line from there. Once reviewed, I'll propose this for jdk8u-critical-request. 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 Sep 25 14:46:54 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 25 Sep 2019 15:46:54 +0100 Subject: [RFR] [8u] 8228469: (tz) Upgrade time-zone data to tzdata2019b In-Reply-To: <79ad8252-260b-5b2d-a5f4-7a129d3e9c32@redhat.com> References: <79ad8252-260b-5b2d-a5f4-7a129d3e9c32@redhat.com> Message-ID: <4f084610-70bc-5354-7425-6e0fbfd5278f@redhat.com> On 25/09/2019 15:37, Andrew John Hughes wrote: > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8228469/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8228469 > > This is the regular timezone data update for the next CPU. > > The only real difference from the patch for 11 & 14 is that I chose to > keep with rearguard format for now. We can look at backporting > JDK-8212970 for 8u242, but I don't want to make such a change at this > late stage in 8u232. > > The effect of this is in make/data/tzdata/africa where the additions for > Morocco don't use a negative offset and the context of the changes being > applied differs slightly (some lines have to be commented out in > rearguard, such as Ireland's negative offset) > > The rearguard version was created by downloading the tzdata2019b bundle > and running 'make rearguard_tarballs' as specified in the bug text. This > generated version was then compared against that from jdk11, with the > only difference being those Morocco rules. > > The only other trivial change from jdk11 is in > test/java/util/TimeZone/TimeZoneTest.java where the bug ID list is > different. I also took the opportunity to drop the useless @modules line > from there. > > Once reviewed, I'll propose this for jdk8u-critical-request. > > Thanks, > I've included the rearguard data tarball I used here: https://cr.openjdk.java.net/~andrew/openjdk8/8228469/tzdata2019b-rearguard.tar.gz -- 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 Sep 25 14:49:24 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 25 Sep 2019 15:49:24 +0100 Subject: CFV: New OpenJDK 8 Updates Committer: Simon Tooke In-Reply-To: References: Message-ID: On 17/09/2019 21:52, Andrew John Hughes wrote: > I hereby nominate Simon Tooke (stooke) [0] to OpenJDK 8 Updates Committer. > > Simon has done work in the main JDK project [1] as well as backporting > work for 8u [2]. Making him a committer would aid this backporting work > by avoiding the need for someone else to push his fixes. > > Votes are due by 21h00 UTC on the 1st of October, 2019. > > Only current OpenJDK 8 Updates Committers (and above) [3] are eligible > to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > [0] https://openjdk.java.net/census#stooke > [1] > https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%20%22))+and+not+merge() > [2] > https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%20%22))+and+not+merge() > [3] http://openjdk.java.net/census#jdk8u > [4] http://openjdk.java.net/projects/#committer-vote > Vote: Yes -- 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 Sep 25 14:53:28 2019 From: alvdavi at amazon.com (Alvarez, David) Date: Wed, 25 Sep 2019 14:53:28 +0000 Subject: [8u] 8178870: instrumentation.retransformClasses cause coredump In-Reply-To: <39df63b4-dc21-7d2f-27da-8483f73559a4@redhat.com> References: <6d646175-68e2-b280-6475-cd97f2e5d438@redhat.com> <7003c233-d891-b11b-3426-f9b6f7de2d8f@redhat.com> <0bfedafb-f31c-6278-31da-56cb4abc1d34@redhat.com> <03cd4243-91e7-fb9f-5b5b-bbacf1de547d@redhat.com> <241f6d60-0392-4225-61aa-706dfb62e194@redhat.com> <79be4136-9e79-8552-a041-eb525f036dbf@redhat.com> <558f30e9-939d-ce1c-dda4-877857ce97e7@redhat.com> <37BA6F70-74A1-4BF0-A860-4EBFBFDFF2F7@amazon.com> <034e3ee3-fae6-f14c-fd23-3dbe6f10f277@redhat.com> <1bd4edec-4e96-6742-595b-b2dccbd91eb8@redhat.com> <39df63b4-dc21-7d2f-27da-8483f73559a4@redhat.com> Message-ID: > On 2019-09-25, at 07:23, Andrew John Hughes wrote: > > > David, can you please confirm Zhengyu's fix makes the test work for you? By applying the Zhengyu?s patch and my own, all the tests will pass when called individually or when called as part of a group, like hotspot_tier1. It seems the test will still fail when jtreg is called to run all the tests in the test/runtime/RedefineTests, it seems due to the location of the ClassFileInstaller, although I haven't looked into this yet. It still means the test is a bit flaky, but at least, call jtreg for a specific subdir will not be the most common case. The full patch that I have applied is attached to the bottom of this email. -- David Alvarez diff --git a/test/runtime/RedefineTests/RedefineDoubleDelete.java b/test/runtime/RedefineTests/RedefineDoubleDelete.java index 7b18b45f..1f4533f8 100644 --- a/test/runtime/RedefineTests/RedefineDoubleDelete.java +++ b/test/runtime/RedefineTests/RedefineDoubleDelete.java @@ -24,7 +24,11 @@ /* * @test * @bug 8178870 + * @library /testlibrary * @summary Redefine class with CFLH twice to test deleting the cached_class_file + * @build RedefineClassHelper + * @run main RedefineClassHelper + * @run main/othervm -javaagent:redefineagent.jar RedefineDoubleDelete */ public class RedefineDoubleDelete { diff --git a/test/runtime/RedefineTests/test8178870.sh b/test/runtime/RedefineTests/test8178870.sh index 4a90e265..48d737f0 100644 --- a/test/runtime/RedefineTests/test8178870.sh +++ b/test/runtime/RedefineTests/test8178870.sh @@ -26,7 +26,7 @@ ## @test test.sh ## @bug 8178870 ## @summary test instrumentation.retransformClasses -## @run shell test.sh +## @run shell test8178870.sh if [ "${TESTSRC}" = "" ] then From gnu.andrew at redhat.com Wed Sep 25 14:59:32 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 25 Sep 2019 15:59:32 +0100 Subject: [8u] RFR: 8226607: Inconsistent info between pcsclite.md and MUSCLE headers In-Reply-To: References: <846dd0f7-c132-e2a9-b9d4-343a0524f784@redhat.com> Message-ID: <74e204af-a8f9-c450-b386-c2ea6cebe68d@redhat.com> On 02/09/2019 16:05, Severin Gehwolf wrote: > On Mon, 2019-09-02 at 15:38 +0100, Andrew John Hughes wrote: >> >> On 26/08/2019 14:24, Severin Gehwolf wrote: >>> 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 >>> >>> >>> >> >> The *.md files in OpenJDK 9+ are the modular equivalent of the >> THIRD_PARTY_README file found in each OpenJDK 8u repository. See my >> review of JDK-8217676 [0] for Zhengyu for more details. >> >> For reference, the conversion took place in JDK-8169925. > > Thanks for this. Updated webrev: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226607/jdk8/02/webrev/ > > I intend to push the same updat to > THIRD_PARTY_README files on all other repos. Example here is jdk repo. > Do you want to see webrevs of this THIRD_PARTY_README update for all 7 > other repos? > > Thanks, > Severin > >> [0] >> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010116.html >> [1] https://bugs.openjdk.java.net/browse/JDK-8169925 > I'm happy assuming the same THIRD_PARTY_README change for all repos. This looks fine to me. Can you flag it jdk8u-critical-request so we can get this into 8u232 with JDK-8218780? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From zgu at redhat.com Wed Sep 25 15:02:46 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 25 Sep 2019 11:02:46 -0400 Subject: [8u] RFR 8231463: Fix runtime/RedefineTests/RedefineDoubleDelete.java test in 8u Message-ID: <917c9bc4-41b2-7913-1100-8db1203f250e@redhat.com> During the early JDK-8178870 8u backport, I converted its test case to shell script, due to imcompatible of test infrastructure. This is no longer the case, we should reverse the test case and eliminate the shell version. Bug: https://bugs.openjdk.java.net/browse/JDK-8231463 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8231463/webrev.00/ Test: ~/jtreg/bin/jtreg -v:summary -jdk:${TEST_JDK} hotspot/test/runtime/RedefineTests and ~/jtreg/bin/jtreg -v:summary -jdk:${TEST_JDK} hotspot/test/runtime/RedefineTests/RedefineDoubleDelete.java Thanks, -Zhengyu From shade at redhat.com Wed Sep 25 15:05:57 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 25 Sep 2019 17:05:57 +0200 Subject: [RFR] [8u] 8228469: (tz) Upgrade time-zone data to tzdata2019b In-Reply-To: <79ad8252-260b-5b2d-a5f4-7a129d3e9c32@redhat.com> References: <79ad8252-260b-5b2d-a5f4-7a129d3e9c32@redhat.com> Message-ID: <28bd3198-f5a5-4291-f249-4d625ba229ac@redhat.com> On 9/25/19 4:37 PM, Andrew John Hughes wrote: > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8228469/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8228469 Bejesus, what a mess. Our other reference point might be jdk13u that still ships tzdata in rearguard format: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/061667.html After applying 8u patch, tzdata matches what is in 13u exactly: $ diff -uwb jdk8u-jdk8u/jdk/make/data/tzdata/ jdk-updates-jdk13u/make/data/tzdata/ So, looks good to me. -- Thanks, -Aleksey From zgu at redhat.com Wed Sep 25 15:06:48 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 25 Sep 2019 11:06:48 -0400 Subject: [8u] 8178870: instrumentation.retransformClasses cause coredump In-Reply-To: <655272AF-3042-4209-9A53-92713EBA1365@amazon.com> References: <6d646175-68e2-b280-6475-cd97f2e5d438@redhat.com> <7003c233-d891-b11b-3426-f9b6f7de2d8f@redhat.com> <0bfedafb-f31c-6278-31da-56cb4abc1d34@redhat.com> <03cd4243-91e7-fb9f-5b5b-bbacf1de547d@redhat.com> <241f6d60-0392-4225-61aa-706dfb62e194@redhat.com> <79be4136-9e79-8552-a041-eb525f036dbf@redhat.com> <558f30e9-939d-ce1c-dda4-877857ce97e7@redhat.com> <37BA6F70-74A1-4BF0-A860-4EBFBFDFF2F7@amazon.com> <034e3ee3-fae6-f14c-fd23-3dbe6f10f277@redhat.com> <1bd4edec-4e96-6742-595b-b2dccbd91eb8@redhat.com> <2f967719-c1c4-bf45-d0d3-28cd3a841e80@redhat.com> <647dee69-17c7-06c6-79ef-8e32278b6ea7@redhat.com> <655272AF-3042-4209-9A53-92713EBA1365@amazon.com> Message-ID: Hi David, On 9/25/19 10:02 AM, Alvarez, David wrote: > > For test8178870.sh, the situation is a little bit trickier. The test will pass > if it is called directly, but it fails when called as part of a group. And I'm > only able to consistently reproduce this behavior if I wipe out the JTwork > folder in between runs: test8178870.sh was written to replace test annotation in RedefineDoubleDelete.java. Now, it works, so we should just remove test8178870.sh. I just RFR the fix: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-September/010365.html Could you please review it? Thanks, -Zhengyu > > $ jtreg -v:summary -retain:none -jdk:/home/alvdavi/hg/jdk8u/build/linux-x86_64-normal-server-release/images/j2sdk-image hotspot/test/runtime/RedefineTests/test8178870.sh > Directory "JTwork" not found: creating > Directory "JTreport" not found: creating > Passed: runtime/RedefineTests/test8178870.sh > Test results: passed: 1 > Report written to /local/home/alvdavi/hg/jdk8u/JTreport/html/report.html > Results written to /local/home/alvdavi/hg/jdk8u/JTwork > > $ rm -rf JTreport JTwork > > $ jtreg -v:summary -retain:none -jdk:/home/alvdavi/hg/jdk8u/build/linux-x86_64-normal-server-release/images/j2sdk-image hotspot/test/runtime/RedefineTests/ > Directory "JTwork" not found: creating > Directory "JTreport" not found: creating > Passed: runtime/RedefineTests/RedefineAnnotations.java > Passed: runtime/RedefineTests/RedefineDoubleDelete.java > Passed: runtime/RedefineTests/RedefineFinalizer.java > Passed: runtime/RedefineTests/RedefineInterfaceCall.java > Passed: runtime/RedefineTests/RedefineRunningMethods.java > Passed: runtime/RedefineTests/RedefineRunningMethodsWithResolutionErrors.java > FAILED: runtime/RedefineTests/test8178870.sh > Test results: passed: 6; failed: 1 > Report written to /local/home/alvdavi/hg/jdk8u/JTreport/html/report.html > Results written to /local/home/alvdavi/hg/jdk8u/JTwork > Error: Some tests failed or other problems occurred. > > Later today I will take a look. > > -- > David > > ?On 2019-09-25, 04:14, "Zhengyu Gu" wrote: > > Thanks, Aleksey. > > I will wait David's reply to proceed. > > -Zhengyu > > On 9/25/19 7:07 AM, Aleksey Shipilev wrote: > > On 9/25/19 1:06 PM, Zhengyu Gu wrote: > >> Andrew, Aleksey: > >> What's the process to fix this bad test? Sorry for the troubles. > > The same process, you just need a new issue that targets openjdk8u232, RFR it here, add > > jdk8u-critical-request. > > > > From gnu.andrew at redhat.com Wed Sep 25 15:16:09 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 25 Sep 2019 16:16:09 +0100 Subject: [RFR] [8u] 8228469: (tz) Upgrade time-zone data to tzdata2019b In-Reply-To: <28bd3198-f5a5-4291-f249-4d625ba229ac@redhat.com> References: <79ad8252-260b-5b2d-a5f4-7a129d3e9c32@redhat.com> <28bd3198-f5a5-4291-f249-4d625ba229ac@redhat.com> Message-ID: <2436e3dd-bf7e-24d6-898b-532904b57d89@redhat.com> On 25/09/2019 16:05, Aleksey Shipilev wrote: > On 9/25/19 4:37 PM, Andrew John Hughes wrote: >> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8228469/webrev.01/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8228469 > > Bejesus, what a mess. > > Our other reference point might be jdk13u that still ships tzdata in rearguard format: > https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/061667.html > > After applying 8u patch, tzdata matches what is in 13u exactly: > $ diff -uwb jdk8u-jdk8u/jdk/make/data/tzdata/ jdk-updates-jdk13u/make/data/tzdata/ > > > So, looks good to me. > Thanks for the quick review, I didn't even think to check 13, though I did notice the vanguard change wasn't marked as being in Oracle's 11u. FWIW, I forgot to mention that I ran the tests in test/java/util/TimeZone/ and the updated TimeZoneTest.java passes on the patched version and fails on the original. The rest are the same between the two. -- 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 Sep 25 15:18:33 2019 From: alvdavi at amazon.com (Alvarez, David) Date: Wed, 25 Sep 2019 15:18:33 +0000 Subject: [8u] RFR 8231463: Fix runtime/RedefineTests/RedefineDoubleDelete.java test in 8u In-Reply-To: <917c9bc4-41b2-7913-1100-8db1203f250e@redhat.com> References: <917c9bc4-41b2-7913-1100-8db1203f250e@redhat.com> Message-ID: <1FE9D5AB-978F-48D6-9F0A-BA57AC25A7EA@amazon.com> I?m not a reviewer, but I can confirm it fixes the jtreg test. > On 25 Sep 2019, at 08:04, Zhengyu Gu wrote: > > ?During the early JDK-8178870 8u backport, I converted its test case to shell script, due to imcompatible of test infrastructure. > > This is no longer the case, we should reverse the test case and eliminate the shell version. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231463 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8231463/webrev.00/ > > Test: > ~/jtreg/bin/jtreg -v:summary -jdk:${TEST_JDK} hotspot/test/runtime/RedefineTests > > and > > ~/jtreg/bin/jtreg -v:summary -jdk:${TEST_JDK} hotspot/test/runtime/RedefineTests/RedefineDoubleDelete.java > > Thanks, > > -Zhengyu > From zgu at redhat.com Wed Sep 25 15:19:29 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 25 Sep 2019 11:19:29 -0400 Subject: [8u] RFR 8231463: Fix runtime/RedefineTests/RedefineDoubleDelete.java test in 8u In-Reply-To: <1FE9D5AB-978F-48D6-9F0A-BA57AC25A7EA@amazon.com> References: <917c9bc4-41b2-7913-1100-8db1203f250e@redhat.com> <1FE9D5AB-978F-48D6-9F0A-BA57AC25A7EA@amazon.com> Message-ID: <797a8ecc-2582-3e3d-3a51-cc142afe1fd4@redhat.com> Thanks, David. -Zhengyu On 9/25/19 11:18 AM, Alvarez, David wrote: > I?m not a reviewer, but I can confirm it fixes the jtreg test. > >> On 25 Sep 2019, at 08:04, Zhengyu Gu wrote: >> >> ?During the early JDK-8178870 8u backport, I converted its test case to shell script, due to imcompatible of test infrastructure. >> >> This is no longer the case, we should reverse the test case and eliminate the shell version. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8231463 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8231463/webrev.00/ >> >> Test: >> ~/jtreg/bin/jtreg -v:summary -jdk:${TEST_JDK} hotspot/test/runtime/RedefineTests >> >> and >> >> ~/jtreg/bin/jtreg -v:summary -jdk:${TEST_JDK} hotspot/test/runtime/RedefineTests/RedefineDoubleDelete.java >> >> Thanks, >> >> -Zhengyu >> From martinrb at google.com Wed Sep 25 15:47:40 2019 From: martinrb at google.com (Martin Buchholz) Date: Wed, 25 Sep 2019 08:47:40 -0700 Subject: [RFR] [8u] 8228469: (tz) Upgrade time-zone data to tzdata2019b In-Reply-To: <2436e3dd-bf7e-24d6-898b-532904b57d89@redhat.com> References: <79ad8252-260b-5b2d-a5f4-7a129d3e9c32@redhat.com> <28bd3198-f5a5-4291-f249-4d625ba229ac@redhat.com> <2436e3dd-bf7e-24d6-898b-532904b57d89@redhat.com> Message-ID: At Google we try to keep our internal JDK's tzdata updated within a week or so of an IANA tzdata release, so we are already using tzdata2019c, and I recommend backporting that for your jdk8u (in rearguard!). But there are also risks when simply replacing upstream tzdata files, e.g. we've run into https://bugs.openjdk.java.net/browse/JDK-8226704 but tzdata2019c looks pitfall-free. From sgehwolf at redhat.com Wed Sep 25 15:49:33 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 25 Sep 2019 17:49:33 +0200 Subject: [8u] RFR: 8226607: Inconsistent info between pcsclite.md and MUSCLE headers In-Reply-To: <74e204af-a8f9-c450-b386-c2ea6cebe68d@redhat.com> References: <846dd0f7-c132-e2a9-b9d4-343a0524f784@redhat.com> <74e204af-a8f9-c450-b386-c2ea6cebe68d@redhat.com> Message-ID: <18ba0f7b13c979efb93791af018e3ec57e7fe56d.camel@redhat.com> On Wed, 2019-09-25 at 15:59 +0100, Andrew John Hughes wrote: > On 02/09/2019 16:05, Severin Gehwolf wrote: > > On Mon, 2019-09-02 at 15:38 +0100, Andrew John Hughes wrote: > > > On 26/08/2019 14:24, Severin Gehwolf wrote: > > > > 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 > > > > > > > > > > > > > > > > > > The *.md files in OpenJDK 9+ are the modular equivalent of the > > > THIRD_PARTY_README file found in each OpenJDK 8u repository. See my > > > review of JDK-8217676 [0] for Zhengyu for more details. > > > > > > For reference, the conversion took place in JDK-8169925. > > > > Thanks for this. Updated webrev: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226607/jdk8/02/webrev/ > > > > I intend to push the same updat to > > THIRD_PARTY_README files on all other repos. Example here is jdk repo. > > Do you want to see webrevs of this THIRD_PARTY_README update for all 7 > > other repos? > > > > Thanks, > > Severin > > > > > [0] > > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010116.html > > > [1] https://bugs.openjdk.java.net/browse/JDK-8169925 > > I'm happy assuming the same THIRD_PARTY_README change for all repos. > > This looks fine to me. Thanks for the review! > Can you flag it jdk8u-critical-request so we can > get this into 8u232 with JDK-8218780? Done. Thanks, Severin From gnu.andrew at redhat.com Wed Sep 25 16:08:07 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 25 Sep 2019 17:08:07 +0100 Subject: [8u] RFR 8231463: Fix runtime/RedefineTests/RedefineDoubleDelete.java test in 8u In-Reply-To: <1FE9D5AB-978F-48D6-9F0A-BA57AC25A7EA@amazon.com> References: <917c9bc4-41b2-7913-1100-8db1203f250e@redhat.com> <1FE9D5AB-978F-48D6-9F0A-BA57AC25A7EA@amazon.com> Message-ID: On 25/09/2019 16:18, Alvarez, David wrote: > I?m not a reviewer, but I can confirm it fixes the jtreg test. > >> On 25 Sep 2019, at 08:04, Zhengyu Gu wrote: >> >> ?During the early JDK-8178870 8u backport, I converted its test case to shell script, due to imcompatible of test infrastructure. >> >> This is no longer the case, we should reverse the test case and eliminate the shell version. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8231463 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8231463/webrev.00/ >> >> Test: >> ~/jtreg/bin/jtreg -v:summary -jdk:${TEST_JDK} hotspot/test/runtime/RedefineTests >> >> and >> >> ~/jtreg/bin/jtreg -v:summary -jdk:${TEST_JDK} hotspot/test/runtime/RedefineTests/RedefineDoubleDelete.java >> >> Thanks, >> >> -Zhengyu >> I am a reviewer and happy to take into account that this fixes the issues for David. The patch looks good to me, and makes the test work for me too: Before: $ run_jtreg.sh /usr/lib/jvm/icedtea-8 hotspot/test/runtime/RedefineTests Java: /usr/lib/jvm/icedtea-8 Test Path: hotspot/test/runtime/RedefineTests Passed: runtime/RedefineTests/RedefineAnnotations.java FAILED: runtime/RedefineTests/RedefineDoubleDelete.java Passed: runtime/RedefineTests/RedefineFinalizer.java Passed: runtime/RedefineTests/RedefineInterfaceCall.java Passed: runtime/RedefineTests/RedefineRunningMethods.java Passed: runtime/RedefineTests/RedefineRunningMethodsWithResolutionErrors.java Error: runtime/RedefineTests/test8178870.sh Test results: passed: 5; failed: 1; error: 1 After: $ run_jtreg.sh /usr/lib/jvm/icedtea-8 hotspot/test/runtime/RedefineTestsJava: /usr/lib/jvm/icedtea-8 Test Path: hotspot/test/runtime/RedefineTests Passed: runtime/RedefineTests/RedefineAnnotations.java Passed: runtime/RedefineTests/RedefineDoubleDelete.java Passed: runtime/RedefineTests/RedefineFinalizer.java Passed: runtime/RedefineTests/RedefineInterfaceCall.java Passed: runtime/RedefineTests/RedefineRunningMethods.java Passed: runtime/RedefineTests/RedefineRunningMethodsWithResolutionErrors.java Test results: passed: 6 My only worry is that the JDK I tested on is 8u222-b10, and so doesn't have the 8178870 patch, so are we sure this test is actually verifying the bug is fixed? $ /usr/lib/jvm/icedtea-8/bin/java -version openjdk version "1.8.0_222" OpenJDK Runtime Environment (IcedTea 3.13.0) (Gentoo icedtea-3.13.0) OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) 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 Sep 25 16:15:19 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 25 Sep 2019 17:15:19 +0100 Subject: [RFR] [8u] 8228469: (tz) Upgrade time-zone data to tzdata2019b In-Reply-To: References: <79ad8252-260b-5b2d-a5f4-7a129d3e9c32@redhat.com> <28bd3198-f5a5-4291-f249-4d625ba229ac@redhat.com> <2436e3dd-bf7e-24d6-898b-532904b57d89@redhat.com> Message-ID: On 25/09/2019 16:47, Martin Buchholz wrote: > At Google we try to keep our internal JDK's tzdata updated within a week > or so of an IANA tzdata release, > so we are already using tzdata2019c, and I recommend backporting that > for your jdk8u (in rearguard!). > But there are also risks when simply replacing upstream tzdata files, > e.g. we've run into? > https://bugs.openjdk.java.net/browse/JDK-8226704 > > but tzdata2019c?looks pitfall-free. I did consider whether we should do tzdata2019c too, after seeing it was out. Doing so would need an OpenJDK bug, so I tend to work for Oracle's team to do that. It seems they have: https://bugs.openjdk.java.net/browse/JDK-8231098 If I backport that (in rearguard), would you be willing to do a quick review? I'd prefer not to hassle Aleksey for one twice in one day :) We do something similar in RHEL, in that we generate the tzdata as part of system tzdata updates rather than relying on the JDK copy. So when the system gets tzdata2019c, all JDK versions do too. This does mean we've run into the exact same problem you mention and has made us wary of that being the right approach. Do you have any sanity tests you run following an update? I'm thinking along the lines of something we could quickly run at the end of a package build cycle rather than the whole TCK :) P.S. I agree it would be nice if tzupdater was open sourced... Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From zgu at redhat.com Wed Sep 25 16:26:13 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 25 Sep 2019 12:26:13 -0400 Subject: [8u] RFR 8231463: Fix runtime/RedefineTests/RedefineDoubleDelete.java test in 8u In-Reply-To: References: <917c9bc4-41b2-7913-1100-8db1203f250e@redhat.com> <1FE9D5AB-978F-48D6-9F0A-BA57AC25A7EA@amazon.com> Message-ID: <9e98a776-3699-6125-b075-f9dfb718e7f4@redhat.com> Hi Andrew, > > My only worry is that the JDK I tested on is 8u222-b10, and so doesn't > have the 8178870 patch, so are we sure this test is actually verifying > the bug is fixed? > This bug is related to JDK-8135322, does 8u222-b10 have this patch? Thanks, -Zhengyu > $ /usr/lib/jvm/icedtea-8/bin/java -version > openjdk version "1.8.0_222" > OpenJDK Runtime Environment (IcedTea 3.13.0) (Gentoo icedtea-3.13.0) > OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) > > Thanks, > From martinrb at google.com Wed Sep 25 17:02:32 2019 From: martinrb at google.com (Martin Buchholz) Date: Wed, 25 Sep 2019 10:02:32 -0700 Subject: [RFR] [8u] 8228469: (tz) Upgrade time-zone data to tzdata2019b In-Reply-To: References: <79ad8252-260b-5b2d-a5f4-7a129d3e9c32@redhat.com> <28bd3198-f5a5-4291-f249-4d625ba229ac@redhat.com> <2436e3dd-bf7e-24d6-898b-532904b57d89@redhat.com> Message-ID: On Wed, Sep 25, 2019 at 9:15 AM Andrew John Hughes wrote: > > > On 25/09/2019 16:47, Martin Buchholz wrote: > > At Google we try to keep our internal JDK's tzdata updated within a week > > or so of an IANA tzdata release, > > so we are already using tzdata2019c, and I recommend backporting that > > for your jdk8u (in rearguard!). > > But there are also risks when simply replacing upstream tzdata files, > > e.g. we've run into > > https://bugs.openjdk.java.net/browse/JDK-8226704 > > > > but tzdata2019c looks pitfall-free. > > I did consider whether we should do tzdata2019c too, after seeing it was > out. Doing so would need an OpenJDK bug, so I tend to work for Oracle's > team to do that. It seems they have: > > https://bugs.openjdk.java.net/browse/JDK-8231098 > > If I backport that (in rearguard), would you be willing to do a quick > review? I'd prefer not to hassle Aleksey for one twice in one day :) > Sure. > We do something similar in RHEL, in that we generate the tzdata as part > of system tzdata updates rather than relying on the JDK copy. So when > the system gets tzdata2019c, all JDK versions do too. > > This does mean we've run into the exact same problem you mention and has > made us wary of that being the right approach. The RHEL and tzupdater both take the approach that tzdata files can "simply" be updated. But in the real world this can't actually work reliably because tzdata releases are incomplete - ICU and CLDR are independent projects that produce additional metadata (like translating names of cities in Kazakhstan into French). With my Google hat on I think I have 6 upstreams - IANA, ICU, CLDR, OpenJDK head, jdk-updates, and my Linux distro provider. Vanguard/Rearguard is an additional problem. We can't get it right, but we muddle through. > Do you have any sanity > tests you run following an update? I'm thinking along the lines of > something we could quickly run at the end of a package build cycle > rather than the whole TCK :) > Well, you have to run all the tests on any release candidate! For tzdata, one should only need to run all the java.time jtreg tests. Not sure if there's a regression test to catch https://bugs.openjdk.java.net/browse/JDK-8226704 From hohensee at amazon.com Wed Sep 25 17:35:23 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 25 Sep 2019 17:35:23 +0000 Subject: [8u] RFR (XS) 8231398: Add time tracing for gc log rotation at safepoint cleanup In-Reply-To: References: Message-ID: Looks good. Paul ?On 9/24/19, 1:17 AM, "hotspot-runtime-dev on behalf of Aleksey Shipilev" wrote: RFE: https://bugs.openjdk.java.net/browse/JDK-8231398 There is a nice gotcha when dealing with low latency workloads. The safepoint cleanup does lots of things, notably rotating the GC logs in 8 (fixed by transition to Unified Logging in 9+, see JDK-8145092). Those things are normally caught by -XX:+TraceSafepointCleanupTime, but not gc log rotation, since it misses the tracing statement. We should consider adding the tracing there. Webrev: https://cr.openjdk.java.net/~shade/8231398/webrev.01/ Testing: eyeballing safepoint cleanup tracing, tier1 (running) -- Thanks, -Aleksey From xxinliu at amazon.com Wed Sep 25 23:24:01 2019 From: xxinliu at amazon.com (Liu, Xin) Date: Wed, 25 Sep 2019 23:24:01 +0000 Subject: Backport vmTestbase tests to jdk8u-dev? In-Reply-To: <7478c13cb1ca4d1293fc8ab5b300ff04@azul.com> References: <9ba7e7af9a1645c4831610327c96f22b@azul.com> <51653b0b3223448bbe2f9186d11556af@azul.com> <1568829532868.82475@amazon.com> <0CFA2C19-FD39-4DDF-99E8-FB5B43936AFE@azul.com> <48213D1C-7CE4-41E9-B799-1E8A199846A0@amazon.com> <104bc421591046c8a4e7c2edcb962d81@azul.com> <1569222717555.22304@amazon.com> <58139b1e7a454e8ca48d4046001cf7b5@azul.com> <7478c13cb1ca4d1293fc8ab5b300ff04@azul.com> Message-ID: <5C06C673-6E83-4049-99E5-FD268F08B7C7@amazon.com> Hi, Konstantin, I think you can also remove Platform.java in test/lib/jdk/test. https://cr.openjdk.java.net/~xliu/8231089/azul_contrib2/webrev/test/test/lib/jdk/test/lib/Platform.java.patch and change vmProps.java refer to jdk.testlibrary.Platform. https://cr.openjdk.java.net/~xliu/8231089/azul_contrib2/webrev/test/jtreg-ext/requires/VMProps.java.udiff.html It's because jdk.testlibrary.Platform is superset of the delete one. Thanks, --lx ?On 9/25/19, 3:20 AM, "Konstantin Shefov" wrote: Hi Here is one more patch from Azul side: http://cr.openjdk.java.net/~kshefov/vmTestbase_8_azul_contrib_2/webrev/ This patch is supposed to be applied just after "azul_contrib" patch sent by Liu Xin. The list of changes is the following: 1) Removed unused code from hotspot/test/test/lib folder (we ran all tests after that, nothing breaks); 2) Fixed some tests so they work with JDK 8 (they used JDK 13 API, so had to refactor); 3) Removed tests that test "Compact String" feature, which is not available in JDK 8; 4) Made a small change in test/JtregNativeHotspot.gmk file so that now native test libs are automatically copied to jdk8u-dev/build//images/test directory exactly as it is done in JDK 11+. In JDK 8 "TEST_IMAGE_DIR" variable is not defined, so it was replaced by "$(IMAGES_OUTPUTDIR)/test". With all changes provided by Liu Xin and the patch provided here we think it can be pushed. Thanks, --Konstantin -----Original Message----- From: Konstantin Shefov Sent: Monday, September 23, 2019 6:30 PM To: 'Liu, Xin' ; 'jdk8u-dev at openjdk.java.net' Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, Liu Xin After applying all the patches, I have successfully built the native part, but I had to do some more changes. After all tests run, I will prepare one more patch "azul_contrib_2" and send it here. Konstantin -----Original Message----- From: Konstantin Shefov Sent: Monday, September 23, 2019 4:47 PM To: 'Liu, Xin' ; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, Liu Xin Thank you for combining our patch with yours, we will test the whole chain of patches to work at our side. As an answer to your question about modification from 0x21 to 0x2e at earlyretint.c. Java class file format has changed between JDK 8 and JDK 11+. In earlyretint.c from JDK 11+ we have the following line: "jlocation loc_exp = (i == 0) ? 0x21 : 0xd; " This "loc_exp" is an expected location of instruction inside a java method (see and [1] and [2]). By the test scenario we breakpoint inside countDownBoolean(I)V method after checkPoint()V method. In Java 8 the number of instruction before which we breakpoint is 0x2e (hex) and 46 (decimal). In Java 11+ the number of instruction before which we breakpoint is 0x21 (hex) and 33 (decimal). That is why we have to change the test here. [1] https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#SingleStep [2] https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#jlocation Regards, Konstantin -----Original Message----- From: Liu, Xin Sent: Monday, September 23, 2019 10:13 AM To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? hi, Konstantin, I also apply your patch to the last webrev. eventually, JDK-8231089 consists of 6 patches. now I think it's easier to review it. https://cr.openjdk.java.net/~xliu/8231089/ We should apply them in order. 1. base 2. apiChanges 3. classFileInstaller 4. gclog 5. native_libraries 6. azul_contrib for your patch, i keep it everything except for -Xloggc. Could you tell me why you modify from 0x21 to 0x2e? diff -r 95eb898ada95 -r 6c35ac679aa8 test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c --- a/test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c Thu Sep 19 17:30:08 2019 +0300 +++ b/test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c Thu Sep 19 17:35:58 2019 +0300 @@ -89,7 +89,7 @@ jlocation loc, jint i) { jvmtiError err; jclass cls; - jlocation loc_exp = (i == 0) ? 0x21 : 0xd; + jlocation loc_exp = (i == 0) ? 0x2e : 0xd; char *sigClass, *name, *sig, *generic; jvmtiLocalVariableEntry *table = NULL; jint entryCount = 0; ________________________________________ From: jdk8u-dev on behalf of Liu, Xin Sent: Saturday, September 21, 2019 4:48 AM To: Konstantin Shefov; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, As I promised, here is the refactored webrev for native compilation Hotspot: https://cr.openjdk.java.net/~xliu/8231089/native_libraries/hotspot/webrev/ root: https://cr.openjdk.java.net/~xliu/8231089/native_libraries/root/webrev/ so the new target 'test-image' is added. to fix https://gist.github.com/navyxliu/bacd47891b17ac8d33d04708b648b531, I added "LDFLAGS_SUFFIX := $$(LIBCXX), " to TestFilesCompilation.gmk. Thanks, --lx From: Konstantin Shefov Date: Friday, September 20, 2019 at 11:01 AM To: "Liu, Xin" , "jdk8u-dev at openjdk.java.net" Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, Liu Xin > I am refactoring makefiles. I plan to upload this webrev today. Fine! We will try to compile with our toolchains. >> BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. > Could you give me an example tests for this? One example is this https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/ConflictingDefaultsTest.java#L329 And most of vmTestbase/vm/runtime/defmeth tests seem to test JVM spec in some way. See here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L50 and here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L134 Konstantin From: Liu, Xin Sent: Friday, September 20, 2019 8:35 PM To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Konstantin, I am refactoring makefiles. I plan to upload this webrev today. I found that you have solved almost all problems. I can help to troubleshoot the remaining tests. >BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. Could you give me an example tests for this? Thanks, --lx From: Konstantin Shefov > Date: Friday, September 20, 2019 at 2:26 AM To: "Liu, Xin" >, "jdk8u-dev at openjdk.java.net" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, We will use your new patches to run tests and merge my changes with yours for those tests that will not work. BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. I see your webrevs do not contain native part build scripts for now. We have to address this problem so the scripts should work for older GCC versions also. Regards Konstantin From: "Liu, Xin" > Date: Wednesday, 18 September 2019 at 20:59 To: Konstantin Shefov >, "jdk8u-dev at openjdk.java.net" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, thank you for updating. We care about x86_64 and aarch64 as well. You ran more tests than us. we never run all vmTestbase. Previously, I used a ProblemList.txt file to screen Problem and move on. Do you plan to fix all problems before we check in? Back to refactor, I have filed a JBS issues. https://bugs.openjdk.java.net/browse/JDK-8231089 In the meanwhile, I start splitting the commits to individual hg changesets. https://cr.openjdk.java.net/~xliu/8231089/ 1. base -> copy code from tag jdk-14+14 intact commit for vmTestbase and testlib 2. make apiChanges for ProcessUtils and Unsafe Could you review it? 3. ClassFileInstaller needs /testlibrary it's because ClassFileInstaller is in /test/testlibrary. I use this script to install @library /testlibrary for all tests. out=$(grep "ClassFileInstaller" -R vmTestbase | awk '{print $1}') for i in $out; do f=${i%\:} gsed -i 's/@library \/vmTestbase/&\n * \/testlibrary/' $f done What do you think that this approach? If I got something wrong, we can update the webtrev with yours. thanks, --lx ________________________________ From: Konstantin Shefov > Sent: Wednesday, September 18, 2019 4:56 PM To: Liu, Xin; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi We ran the tests against x86_64 Ubuntu Linux and there are just the same failed tests as it was with Arm64 Ubuntu Linux plus 2 more tests: vmTestbase/gc/lock/jni/jnilock002/TestDescription.java vmTestbase/nsk/jdb/set/set001/set001.java Konstantin From: Konstantin Shefov Sent: Wednesday, September 11, 2019 10:53 AM To: 'Liu, Xin' >; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, LX Answering to your e-mail, as for what we modified in [3]: 1. API changes (Process, Unsafe), Xloggc option, that were not in your patches; 2. In a file hotspot/test/JtregNativeHotspot.gmk we changed "-lpthread" option to "-pthread" to prevent compilation error. I agree that there should be a series of patches to track file changes. As for investigation of failures: do you have the same? We ran against Arm64 platform, but we can try against x86-64 too. Konstantin From: Liu, Xin > Sent: Monday, September 9, 2019 11:04 PM To: Konstantin Shefov >; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, We are glad to work with you to get vmTestbase landed into jdk8u. Our original intent is get design reviewed by the jdk8u maintainer. After then, we can proceed to refactor it. We can work together to refactor it. we plan to do it anyway. Back to the webrev you send. What did you modify in [3]? Ideally, we can should have a series of patches. The first one should be intact vmTestbase code from the tip of JDK. All we changes should come after it and be reviewed by this mail-list. In addition to refactoring, we can also offer help to figure out those failed cases. What do you think? Thanks, --lx From: Konstantin Shefov > Date: Friday, September 6, 2019 at 12:55 PM To: "jdk8u-dev at openjdk.java.net" > Cc: "Liu, Xin" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, We at Azul think it is a good idea to backport vmTestbase tests to OpenJDK 8. We have used patches you suggested, done some refactoring to enable more tests to work with JDK 8. We have run all 3550 tests from "vmTestbase" folder against Zulu 8 at ARM64 platform: 1. 3371 tests PASS (see [1]); 2. 179 tests FAIL (see [2]): reasons are being investigated. Patches we have used (contain our refactoring): 1. Hotspot folder [3] 2. Main folder [4] We plan to investigate causes of those 177 failures, purify unused code from hotspot/test/test/lib/jdk, and run the tests against different platforms. We also compared vmTestbase from JDK 11 with that from JDK 13, we found out: 1. 332 test have been removed in JDK 13; 2. Only 2 test have been added in JDK 13; 3. Tests that remained were modified, but these modifications mostly are copyright years, or output format, or API changes. From the above results we can tell that vmTestbase does not grow. It looks like that tests are been removed from there or transferred somewhere else. [1] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/passed_tests.html [2] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/failed_tests.html [3] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_hotspot.patch [4] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_root.patch Regards, --Konstantin From hohensee at amazon.com Thu Sep 26 00:56:58 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 26 Sep 2019 00:56:58 +0000 Subject: [8u] RFR 8208715: Conversion of milliseconds to nanoseconds in UNIXProcess contains bug In-Reply-To: <029E8BC0-B1BC-4FED-97CA-6763D2138E36@amazon.com> References: <029E8BC0-B1BC-4FED-97CA-6763D2138E36@amazon.com> Message-ID: <854ACCAE-598E-471A-AFD8-B0E1D74087F6@amazon.com> Ping (it's been nearly a month :)). I posted an updated webrev at http://cr.openjdk.java.net/~phh/8208715/webrev.00/ The only difference between it and the previous one is that the copyright dates are 2018 instead of 2019 to match the original patch date. Passes tier1 and the modified jtreg test (as part of test/jdk/java/lang/ProcessBuilder) on both linxux-x64 and windows-x64. Thanks, Paul ?On 8/29/19, 6:30 PM, "jdk8u-dev on behalf of Guo, James" wrote: 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 gnu.andrew at redhat.com Thu Sep 26 06:14:46 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 26 Sep 2019 07:14:46 +0100 Subject: [FREEZE] 8u232 NOW FROZEN Message-ID: <6e84f5e0-ac90-31a9-aa58-1467b40c3cae@redhat.com> The release tree: https://hg.openjdk.java.net/jdk8u/jdk8u (and friends) is now frozen in preparation for release on 2019-10-15. I will push the final pre-release tag, jdk8u232-b08, following successful testing of the current state of the repositories. The final release tag will be no lower than jdk8u232-b09. 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 kshefov at azul.com Thu Sep 26 09:52:06 2019 From: kshefov at azul.com (Konstantin Shefov) Date: Thu, 26 Sep 2019 09:52:06 +0000 Subject: Backport vmTestbase tests to jdk8u-dev? In-Reply-To: <5C06C673-6E83-4049-99E5-FD268F08B7C7@amazon.com> References: <9ba7e7af9a1645c4831610327c96f22b@azul.com> <51653b0b3223448bbe2f9186d11556af@azul.com> <1568829532868.82475@amazon.com> <0CFA2C19-FD39-4DDF-99E8-FB5B43936AFE@azul.com> <48213D1C-7CE4-41E9-B799-1E8A199846A0@amazon.com> <104bc421591046c8a4e7c2edcb962d81@azul.com> <1569222717555.22304@amazon.com> <58139b1e7a454e8ca48d4046001cf7b5@azul.com> <7478c13cb1ca4d1293fc8ab5b300ff04@azul.com> <5C06C673-6E83-4049-99E5-FD268F08B7C7@amazon.com> Message-ID: Hello I have no objections against removing Platform.java and using the existing one. Konstantin -----Original Message----- From: Liu, Xin Sent: Thursday, September 26, 2019 2:24 AM To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, I think you can also remove Platform.java in test/lib/jdk/test. https://cr.openjdk.java.net/~xliu/8231089/azul_contrib2/webrev/test/test/lib/jdk/test/lib/Platform.java.patch and change vmProps.java refer to jdk.testlibrary.Platform. https://cr.openjdk.java.net/~xliu/8231089/azul_contrib2/webrev/test/jtreg-ext/requires/VMProps.java.udiff.html It's because jdk.testlibrary.Platform is superset of the delete one. Thanks, --lx ?On 9/25/19, 3:20 AM, "Konstantin Shefov" wrote: Hi Here is one more patch from Azul side: http://cr.openjdk.java.net/~kshefov/vmTestbase_8_azul_contrib_2/webrev/ This patch is supposed to be applied just after "azul_contrib" patch sent by Liu Xin. The list of changes is the following: 1) Removed unused code from hotspot/test/test/lib folder (we ran all tests after that, nothing breaks); 2) Fixed some tests so they work with JDK 8 (they used JDK 13 API, so had to refactor); 3) Removed tests that test "Compact String" feature, which is not available in JDK 8; 4) Made a small change in test/JtregNativeHotspot.gmk file so that now native test libs are automatically copied to jdk8u-dev/build//images/test directory exactly as it is done in JDK 11+. In JDK 8 "TEST_IMAGE_DIR" variable is not defined, so it was replaced by "$(IMAGES_OUTPUTDIR)/test". With all changes provided by Liu Xin and the patch provided here we think it can be pushed. Thanks, --Konstantin -----Original Message----- From: Konstantin Shefov Sent: Monday, September 23, 2019 6:30 PM To: 'Liu, Xin' ; 'jdk8u-dev at openjdk.java.net' Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, Liu Xin After applying all the patches, I have successfully built the native part, but I had to do some more changes. After all tests run, I will prepare one more patch "azul_contrib_2" and send it here. Konstantin -----Original Message----- From: Konstantin Shefov Sent: Monday, September 23, 2019 4:47 PM To: 'Liu, Xin' ; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, Liu Xin Thank you for combining our patch with yours, we will test the whole chain of patches to work at our side. As an answer to your question about modification from 0x21 to 0x2e at earlyretint.c. Java class file format has changed between JDK 8 and JDK 11+. In earlyretint.c from JDK 11+ we have the following line: "jlocation loc_exp = (i == 0) ? 0x21 : 0xd; " This "loc_exp" is an expected location of instruction inside a java method (see and [1] and [2]). By the test scenario we breakpoint inside countDownBoolean(I)V method after checkPoint()V method. In Java 8 the number of instruction before which we breakpoint is 0x2e (hex) and 46 (decimal). In Java 11+ the number of instruction before which we breakpoint is 0x21 (hex) and 33 (decimal). That is why we have to change the test here. [1] https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#SingleStep [2] https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#jlocation Regards, Konstantin -----Original Message----- From: Liu, Xin Sent: Monday, September 23, 2019 10:13 AM To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? hi, Konstantin, I also apply your patch to the last webrev. eventually, JDK-8231089 consists of 6 patches. now I think it's easier to review it. https://cr.openjdk.java.net/~xliu/8231089/ We should apply them in order. 1. base 2. apiChanges 3. classFileInstaller 4. gclog 5. native_libraries 6. azul_contrib for your patch, i keep it everything except for -Xloggc. Could you tell me why you modify from 0x21 to 0x2e? diff -r 95eb898ada95 -r 6c35ac679aa8 test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c --- a/test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c Thu Sep 19 17:30:08 2019 +0300 +++ b/test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c Thu Sep 19 17:35:58 2019 +0300 @@ -89,7 +89,7 @@ jlocation loc, jint i) { jvmtiError err; jclass cls; - jlocation loc_exp = (i == 0) ? 0x21 : 0xd; + jlocation loc_exp = (i == 0) ? 0x2e : 0xd; char *sigClass, *name, *sig, *generic; jvmtiLocalVariableEntry *table = NULL; jint entryCount = 0; ________________________________________ From: jdk8u-dev on behalf of Liu, Xin Sent: Saturday, September 21, 2019 4:48 AM To: Konstantin Shefov; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, As I promised, here is the refactored webrev for native compilation Hotspot: https://cr.openjdk.java.net/~xliu/8231089/native_libraries/hotspot/webrev/ root: https://cr.openjdk.java.net/~xliu/8231089/native_libraries/root/webrev/ so the new target 'test-image' is added. to fix https://gist.github.com/navyxliu/bacd47891b17ac8d33d04708b648b531, I added "LDFLAGS_SUFFIX := $$(LIBCXX), " to TestFilesCompilation.gmk. Thanks, --lx From: Konstantin Shefov Date: Friday, September 20, 2019 at 11:01 AM To: "Liu, Xin" , "jdk8u-dev at openjdk.java.net" Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, Liu Xin > I am refactoring makefiles. I plan to upload this webrev today. Fine! We will try to compile with our toolchains. >> BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. > Could you give me an example tests for this? One example is this https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/ConflictingDefaultsTest.java#L329 And most of vmTestbase/vm/runtime/defmeth tests seem to test JVM spec in some way. See here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L50 and here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L134 Konstantin From: Liu, Xin Sent: Friday, September 20, 2019 8:35 PM To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Konstantin, I am refactoring makefiles. I plan to upload this webrev today. I found that you have solved almost all problems. I can help to troubleshoot the remaining tests. >BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. Could you give me an example tests for this? Thanks, --lx From: Konstantin Shefov > Date: Friday, September 20, 2019 at 2:26 AM To: "Liu, Xin" >, "jdk8u-dev at openjdk.java.net" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, We will use your new patches to run tests and merge my changes with yours for those tests that will not work. BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. I see your webrevs do not contain native part build scripts for now. We have to address this problem so the scripts should work for older GCC versions also. Regards Konstantin From: "Liu, Xin" > Date: Wednesday, 18 September 2019 at 20:59 To: Konstantin Shefov >, "jdk8u-dev at openjdk.java.net" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, thank you for updating. We care about x86_64 and aarch64 as well. You ran more tests than us. we never run all vmTestbase. Previously, I used a ProblemList.txt file to screen Problem and move on. Do you plan to fix all problems before we check in? Back to refactor, I have filed a JBS issues. https://bugs.openjdk.java.net/browse/JDK-8231089 In the meanwhile, I start splitting the commits to individual hg changesets. https://cr.openjdk.java.net/~xliu/8231089/ 1. base -> copy code from tag jdk-14+14 intact commit for vmTestbase and testlib 2. make apiChanges for ProcessUtils and Unsafe Could you review it? 3. ClassFileInstaller needs /testlibrary it's because ClassFileInstaller is in /test/testlibrary. I use this script to install @library /testlibrary for all tests. out=$(grep "ClassFileInstaller" -R vmTestbase | awk '{print $1}') for i in $out; do f=${i%\:} gsed -i 's/@library \/vmTestbase/&\n * \/testlibrary/' $f done What do you think that this approach? If I got something wrong, we can update the webtrev with yours. thanks, --lx ________________________________ From: Konstantin Shefov > Sent: Wednesday, September 18, 2019 4:56 PM To: Liu, Xin; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi We ran the tests against x86_64 Ubuntu Linux and there are just the same failed tests as it was with Arm64 Ubuntu Linux plus 2 more tests: vmTestbase/gc/lock/jni/jnilock002/TestDescription.java vmTestbase/nsk/jdb/set/set001/set001.java Konstantin From: Konstantin Shefov Sent: Wednesday, September 11, 2019 10:53 AM To: 'Liu, Xin' >; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, LX Answering to your e-mail, as for what we modified in [3]: 1. API changes (Process, Unsafe), Xloggc option, that were not in your patches; 2. In a file hotspot/test/JtregNativeHotspot.gmk we changed "-lpthread" option to "-pthread" to prevent compilation error. I agree that there should be a series of patches to track file changes. As for investigation of failures: do you have the same? We ran against Arm64 platform, but we can try against x86-64 too. Konstantin From: Liu, Xin > Sent: Monday, September 9, 2019 11:04 PM To: Konstantin Shefov >; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, We are glad to work with you to get vmTestbase landed into jdk8u. Our original intent is get design reviewed by the jdk8u maintainer. After then, we can proceed to refactor it. We can work together to refactor it. we plan to do it anyway. Back to the webrev you send. What did you modify in [3]? Ideally, we can should have a series of patches. The first one should be intact vmTestbase code from the tip of JDK. All we changes should come after it and be reviewed by this mail-list. In addition to refactoring, we can also offer help to figure out those failed cases. What do you think? Thanks, --lx From: Konstantin Shefov > Date: Friday, September 6, 2019 at 12:55 PM To: "jdk8u-dev at openjdk.java.net" > Cc: "Liu, Xin" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, We at Azul think it is a good idea to backport vmTestbase tests to OpenJDK 8. We have used patches you suggested, done some refactoring to enable more tests to work with JDK 8. We have run all 3550 tests from "vmTestbase" folder against Zulu 8 at ARM64 platform: 1. 3371 tests PASS (see [1]); 2. 179 tests FAIL (see [2]): reasons are being investigated. Patches we have used (contain our refactoring): 1. Hotspot folder [3] 2. Main folder [4] We plan to investigate causes of those 177 failures, purify unused code from hotspot/test/test/lib/jdk, and run the tests against different platforms. We also compared vmTestbase from JDK 11 with that from JDK 13, we found out: 1. 332 test have been removed in JDK 13; 2. Only 2 test have been added in JDK 13; 3. Tests that remained were modified, but these modifications mostly are copyright years, or output format, or API changes. From the above results we can tell that vmTestbase does not grow. It looks like that tests are been removed from there or transferred somewhere else. [1] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/passed_tests.html [2] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/failed_tests.html [3] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_hotspot.patch [4] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_root.patch Regards, --Konstantin From kshefov at azul.com Thu Sep 26 11:50:54 2019 From: kshefov at azul.com (Konstantin Shefov) Date: Thu, 26 Sep 2019 11:50:54 +0000 Subject: Backport vmTestbase tests to jdk8u-dev? In-Reply-To: References: <9ba7e7af9a1645c4831610327c96f22b@azul.com> <51653b0b3223448bbe2f9186d11556af@azul.com> <1568829532868.82475@amazon.com> <0CFA2C19-FD39-4DDF-99E8-FB5B43936AFE@azul.com> <48213D1C-7CE4-41E9-B799-1E8A199846A0@amazon.com> <104bc421591046c8a4e7c2edcb962d81@azul.com> <1569222717555.22304@amazon.com> <58139b1e7a454e8ca48d4046001cf7b5@azul.com> <7478c13cb1ca4d1293fc8ab5b300ff04@azul.com> <5C06C673-6E83-4049-99E5-FD268F08B7C7@amazon.com> Message-ID: <9967a21b81f740f68272d4dbbe3390b5@azul.com> Hi, Liu Xin I have to change my previous answer about Platform.java. We cannot just remove it and change vmProps.java refer to jdk.testlibrary.Platform. The reasons are: 1) There is no jdk.testlibrary.Platform class. We have com.oracle.java.testlibrary.Platform instead. 2) com.oracle.java.testlibrary.Platform is NOT a superset of jdk.test.lib.Platform - it contains less methods. 3) A lot of tests fail to compile because of absent methods in com.oracle.java.testlibrary.Platform. So if we want to get rid of "hostspot/test/test/lib" folder, we have to merge new methods into hotspot/test/testlibrary/com/oracle/java/testlibrary folder. The other solution is to leave everything as is, so use the "azul_contrib2" patch exactly as we provided it. Regards, Konstantin -----Original Message----- From: Konstantin Shefov Sent: Thursday, September 26, 2019 12:52 PM To: 'Liu, Xin' ; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hello I have no objections against removing Platform.java and using the existing one. Konstantin -----Original Message----- From: Liu, Xin Sent: Thursday, September 26, 2019 2:24 AM To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, I think you can also remove Platform.java in test/lib/jdk/test. https://cr.openjdk.java.net/~xliu/8231089/azul_contrib2/webrev/test/test/lib/jdk/test/lib/Platform.java.patch and change vmProps.java refer to jdk.testlibrary.Platform. https://cr.openjdk.java.net/~xliu/8231089/azul_contrib2/webrev/test/jtreg-ext/requires/VMProps.java.udiff.html It's because jdk.testlibrary.Platform is superset of the delete one. Thanks, --lx ?On 9/25/19, 3:20 AM, "Konstantin Shefov" wrote: Hi Here is one more patch from Azul side: http://cr.openjdk.java.net/~kshefov/vmTestbase_8_azul_contrib_2/webrev/ This patch is supposed to be applied just after "azul_contrib" patch sent by Liu Xin. The list of changes is the following: 1) Removed unused code from hotspot/test/test/lib folder (we ran all tests after that, nothing breaks); 2) Fixed some tests so they work with JDK 8 (they used JDK 13 API, so had to refactor); 3) Removed tests that test "Compact String" feature, which is not available in JDK 8; 4) Made a small change in test/JtregNativeHotspot.gmk file so that now native test libs are automatically copied to jdk8u-dev/build//images/test directory exactly as it is done in JDK 11+. In JDK 8 "TEST_IMAGE_DIR" variable is not defined, so it was replaced by "$(IMAGES_OUTPUTDIR)/test". With all changes provided by Liu Xin and the patch provided here we think it can be pushed. Thanks, --Konstantin -----Original Message----- From: Konstantin Shefov Sent: Monday, September 23, 2019 6:30 PM To: 'Liu, Xin' ; 'jdk8u-dev at openjdk.java.net' Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, Liu Xin After applying all the patches, I have successfully built the native part, but I had to do some more changes. After all tests run, I will prepare one more patch "azul_contrib_2" and send it here. Konstantin -----Original Message----- From: Konstantin Shefov Sent: Monday, September 23, 2019 4:47 PM To: 'Liu, Xin' ; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, Liu Xin Thank you for combining our patch with yours, we will test the whole chain of patches to work at our side. As an answer to your question about modification from 0x21 to 0x2e at earlyretint.c. Java class file format has changed between JDK 8 and JDK 11+. In earlyretint.c from JDK 11+ we have the following line: "jlocation loc_exp = (i == 0) ? 0x21 : 0xd; " This "loc_exp" is an expected location of instruction inside a java method (see and [1] and [2]). By the test scenario we breakpoint inside countDownBoolean(I)V method after checkPoint()V method. In Java 8 the number of instruction before which we breakpoint is 0x2e (hex) and 46 (decimal). In Java 11+ the number of instruction before which we breakpoint is 0x21 (hex) and 33 (decimal). That is why we have to change the test here. [1] https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#SingleStep [2] https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#jlocation Regards, Konstantin -----Original Message----- From: Liu, Xin Sent: Monday, September 23, 2019 10:13 AM To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? hi, Konstantin, I also apply your patch to the last webrev. eventually, JDK-8231089 consists of 6 patches. now I think it's easier to review it. https://cr.openjdk.java.net/~xliu/8231089/ We should apply them in order. 1. base 2. apiChanges 3. classFileInstaller 4. gclog 5. native_libraries 6. azul_contrib for your patch, i keep it everything except for -Xloggc. Could you tell me why you modify from 0x21 to 0x2e? diff -r 95eb898ada95 -r 6c35ac679aa8 test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c --- a/test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c Thu Sep 19 17:30:08 2019 +0300 +++ b/test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c Thu Sep 19 17:35:58 2019 +0300 @@ -89,7 +89,7 @@ jlocation loc, jint i) { jvmtiError err; jclass cls; - jlocation loc_exp = (i == 0) ? 0x21 : 0xd; + jlocation loc_exp = (i == 0) ? 0x2e : 0xd; char *sigClass, *name, *sig, *generic; jvmtiLocalVariableEntry *table = NULL; jint entryCount = 0; ________________________________________ From: jdk8u-dev on behalf of Liu, Xin Sent: Saturday, September 21, 2019 4:48 AM To: Konstantin Shefov; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, As I promised, here is the refactored webrev for native compilation Hotspot: https://cr.openjdk.java.net/~xliu/8231089/native_libraries/hotspot/webrev/ root: https://cr.openjdk.java.net/~xliu/8231089/native_libraries/root/webrev/ so the new target 'test-image' is added. to fix https://gist.github.com/navyxliu/bacd47891b17ac8d33d04708b648b531, I added "LDFLAGS_SUFFIX := $$(LIBCXX), " to TestFilesCompilation.gmk. Thanks, --lx From: Konstantin Shefov Date: Friday, September 20, 2019 at 11:01 AM To: "Liu, Xin" , "jdk8u-dev at openjdk.java.net" Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, Liu Xin > I am refactoring makefiles. I plan to upload this webrev today. Fine! We will try to compile with our toolchains. >> BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. > Could you give me an example tests for this? One example is this https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/ConflictingDefaultsTest.java#L329 And most of vmTestbase/vm/runtime/defmeth tests seem to test JVM spec in some way. See here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L50 and here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L134 Konstantin From: Liu, Xin Sent: Friday, September 20, 2019 8:35 PM To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Konstantin, I am refactoring makefiles. I plan to upload this webrev today. I found that you have solved almost all problems. I can help to troubleshoot the remaining tests. >BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. Could you give me an example tests for this? Thanks, --lx From: Konstantin Shefov > Date: Friday, September 20, 2019 at 2:26 AM To: "Liu, Xin" >, "jdk8u-dev at openjdk.java.net" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, We will use your new patches to run tests and merge my changes with yours for those tests that will not work. BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. I see your webrevs do not contain native part build scripts for now. We have to address this problem so the scripts should work for older GCC versions also. Regards Konstantin From: "Liu, Xin" > Date: Wednesday, 18 September 2019 at 20:59 To: Konstantin Shefov >, "jdk8u-dev at openjdk.java.net" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, thank you for updating. We care about x86_64 and aarch64 as well. You ran more tests than us. we never run all vmTestbase. Previously, I used a ProblemList.txt file to screen Problem and move on. Do you plan to fix all problems before we check in? Back to refactor, I have filed a JBS issues. https://bugs.openjdk.java.net/browse/JDK-8231089 In the meanwhile, I start splitting the commits to individual hg changesets. https://cr.openjdk.java.net/~xliu/8231089/ 1. base -> copy code from tag jdk-14+14 intact commit for vmTestbase and testlib 2. make apiChanges for ProcessUtils and Unsafe Could you review it? 3. ClassFileInstaller needs /testlibrary it's because ClassFileInstaller is in /test/testlibrary. I use this script to install @library /testlibrary for all tests. out=$(grep "ClassFileInstaller" -R vmTestbase | awk '{print $1}') for i in $out; do f=${i%\:} gsed -i 's/@library \/vmTestbase/&\n * \/testlibrary/' $f done What do you think that this approach? If I got something wrong, we can update the webtrev with yours. thanks, --lx ________________________________ From: Konstantin Shefov > Sent: Wednesday, September 18, 2019 4:56 PM To: Liu, Xin; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi We ran the tests against x86_64 Ubuntu Linux and there are just the same failed tests as it was with Arm64 Ubuntu Linux plus 2 more tests: vmTestbase/gc/lock/jni/jnilock002/TestDescription.java vmTestbase/nsk/jdb/set/set001/set001.java Konstantin From: Konstantin Shefov Sent: Wednesday, September 11, 2019 10:53 AM To: 'Liu, Xin' >; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, LX Answering to your e-mail, as for what we modified in [3]: 1. API changes (Process, Unsafe), Xloggc option, that were not in your patches; 2. In a file hotspot/test/JtregNativeHotspot.gmk we changed "-lpthread" option to "-pthread" to prevent compilation error. I agree that there should be a series of patches to track file changes. As for investigation of failures: do you have the same? We ran against Arm64 platform, but we can try against x86-64 too. Konstantin From: Liu, Xin > Sent: Monday, September 9, 2019 11:04 PM To: Konstantin Shefov >; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, We are glad to work with you to get vmTestbase landed into jdk8u. Our original intent is get design reviewed by the jdk8u maintainer. After then, we can proceed to refactor it. We can work together to refactor it. we plan to do it anyway. Back to the webrev you send. What did you modify in [3]? Ideally, we can should have a series of patches. The first one should be intact vmTestbase code from the tip of JDK. All we changes should come after it and be reviewed by this mail-list. In addition to refactoring, we can also offer help to figure out those failed cases. What do you think? Thanks, --lx From: Konstantin Shefov > Date: Friday, September 6, 2019 at 12:55 PM To: "jdk8u-dev at openjdk.java.net" > Cc: "Liu, Xin" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, We at Azul think it is a good idea to backport vmTestbase tests to OpenJDK 8. We have used patches you suggested, done some refactoring to enable more tests to work with JDK 8. We have run all 3550 tests from "vmTestbase" folder against Zulu 8 at ARM64 platform: 1. 3371 tests PASS (see [1]); 2. 179 tests FAIL (see [2]): reasons are being investigated. Patches we have used (contain our refactoring): 1. Hotspot folder [3] 2. Main folder [4] We plan to investigate causes of those 177 failures, purify unused code from hotspot/test/test/lib/jdk, and run the tests against different platforms. We also compared vmTestbase from JDK 11 with that from JDK 13, we found out: 1. 332 test have been removed in JDK 13; 2. Only 2 test have been added in JDK 13; 3. Tests that remained were modified, but these modifications mostly are copyright years, or output format, or API changes. From the above results we can tell that vmTestbase does not grow. It looks like that tests are been removed from there or transferred somewhere else. [1] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/passed_tests.html [2] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/failed_tests.html [3] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_hotspot.patch [4] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_root.patch Regards, --Konstantin From xxinliu at amazon.com Thu Sep 26 17:18:53 2019 From: xxinliu at amazon.com (Liu, Xin) Date: Thu, 26 Sep 2019 17:18:53 +0000 Subject: Backport vmTestbase tests to jdk8u-dev? In-Reply-To: <9967a21b81f740f68272d4dbbe3390b5@azul.com> References: <9ba7e7af9a1645c4831610327c96f22b@azul.com> <51653b0b3223448bbe2f9186d11556af@azul.com> <1568829532868.82475@amazon.com> <0CFA2C19-FD39-4DDF-99E8-FB5B43936AFE@azul.com> <48213D1C-7CE4-41E9-B799-1E8A199846A0@amazon.com> <104bc421591046c8a4e7c2edcb962d81@azul.com> <1569222717555.22304@amazon.com> <58139b1e7a454e8ca48d4046001cf7b5@azul.com> <7478c13cb1ca4d1293fc8ab5b300ff04@azul.com> <5C06C673-6E83-4049-99E5-FD268F08B7C7@amazon.com> <9967a21b81f740f68272d4dbbe3390b5@azul.com> Message-ID: Hi, Konstantin, Yes, I am sorry. I also realized that last night. I tried to keep one single copy of Platform.java but failed. It would need too many unnecessary hacks. I have reverted what I modified. Your patch is perfect. Thanks, --lx ?On 9/26/19, 4:52 AM, "Konstantin Shefov" wrote: Hi, Liu Xin I have to change my previous answer about Platform.java. We cannot just remove it and change vmProps.java refer to jdk.testlibrary.Platform. The reasons are: 1) There is no jdk.testlibrary.Platform class. We have com.oracle.java.testlibrary.Platform instead. 2) com.oracle.java.testlibrary.Platform is NOT a superset of jdk.test.lib.Platform - it contains less methods. 3) A lot of tests fail to compile because of absent methods in com.oracle.java.testlibrary.Platform. So if we want to get rid of "hostspot/test/test/lib" folder, we have to merge new methods into hotspot/test/testlibrary/com/oracle/java/testlibrary folder. The other solution is to leave everything as is, so use the "azul_contrib2" patch exactly as we provided it. Regards, Konstantin -----Original Message----- From: Konstantin Shefov Sent: Thursday, September 26, 2019 12:52 PM To: 'Liu, Xin' ; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hello I have no objections against removing Platform.java and using the existing one. Konstantin -----Original Message----- From: Liu, Xin Sent: Thursday, September 26, 2019 2:24 AM To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, I think you can also remove Platform.java in test/lib/jdk/test. https://cr.openjdk.java.net/~xliu/8231089/azul_contrib2/webrev/test/test/lib/jdk/test/lib/Platform.java.patch and change vmProps.java refer to jdk.testlibrary.Platform. https://cr.openjdk.java.net/~xliu/8231089/azul_contrib2/webrev/test/jtreg-ext/requires/VMProps.java.udiff.html It's because jdk.testlibrary.Platform is superset of the delete one. Thanks, --lx On 9/25/19, 3:20 AM, "Konstantin Shefov" wrote: Hi Here is one more patch from Azul side: http://cr.openjdk.java.net/~kshefov/vmTestbase_8_azul_contrib_2/webrev/ This patch is supposed to be applied just after "azul_contrib" patch sent by Liu Xin. The list of changes is the following: 1) Removed unused code from hotspot/test/test/lib folder (we ran all tests after that, nothing breaks); 2) Fixed some tests so they work with JDK 8 (they used JDK 13 API, so had to refactor); 3) Removed tests that test "Compact String" feature, which is not available in JDK 8; 4) Made a small change in test/JtregNativeHotspot.gmk file so that now native test libs are automatically copied to jdk8u-dev/build//images/test directory exactly as it is done in JDK 11+. In JDK 8 "TEST_IMAGE_DIR" variable is not defined, so it was replaced by "$(IMAGES_OUTPUTDIR)/test". With all changes provided by Liu Xin and the patch provided here we think it can be pushed. Thanks, --Konstantin -----Original Message----- From: Konstantin Shefov Sent: Monday, September 23, 2019 6:30 PM To: 'Liu, Xin' ; 'jdk8u-dev at openjdk.java.net' Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, Liu Xin After applying all the patches, I have successfully built the native part, but I had to do some more changes. After all tests run, I will prepare one more patch "azul_contrib_2" and send it here. Konstantin -----Original Message----- From: Konstantin Shefov Sent: Monday, September 23, 2019 4:47 PM To: 'Liu, Xin' ; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, Liu Xin Thank you for combining our patch with yours, we will test the whole chain of patches to work at our side. As an answer to your question about modification from 0x21 to 0x2e at earlyretint.c. Java class file format has changed between JDK 8 and JDK 11+. In earlyretint.c from JDK 11+ we have the following line: "jlocation loc_exp = (i == 0) ? 0x21 : 0xd; " This "loc_exp" is an expected location of instruction inside a java method (see and [1] and [2]). By the test scenario we breakpoint inside countDownBoolean(I)V method after checkPoint()V method. In Java 8 the number of instruction before which we breakpoint is 0x2e (hex) and 46 (decimal). In Java 11+ the number of instruction before which we breakpoint is 0x21 (hex) and 33 (decimal). That is why we have to change the test here. [1] https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#SingleStep [2] https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#jlocation Regards, Konstantin -----Original Message----- From: Liu, Xin Sent: Monday, September 23, 2019 10:13 AM To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? hi, Konstantin, I also apply your patch to the last webrev. eventually, JDK-8231089 consists of 6 patches. now I think it's easier to review it. https://cr.openjdk.java.net/~xliu/8231089/ We should apply them in order. 1. base 2. apiChanges 3. classFileInstaller 4. gclog 5. native_libraries 6. azul_contrib for your patch, i keep it everything except for -Xloggc. Could you tell me why you modify from 0x21 to 0x2e? diff -r 95eb898ada95 -r 6c35ac679aa8 test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c --- a/test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c Thu Sep 19 17:30:08 2019 +0300 +++ b/test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c Thu Sep 19 17:35:58 2019 +0300 @@ -89,7 +89,7 @@ jlocation loc, jint i) { jvmtiError err; jclass cls; - jlocation loc_exp = (i == 0) ? 0x21 : 0xd; + jlocation loc_exp = (i == 0) ? 0x2e : 0xd; char *sigClass, *name, *sig, *generic; jvmtiLocalVariableEntry *table = NULL; jint entryCount = 0; ________________________________________ From: jdk8u-dev on behalf of Liu, Xin Sent: Saturday, September 21, 2019 4:48 AM To: Konstantin Shefov; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, As I promised, here is the refactored webrev for native compilation Hotspot: https://cr.openjdk.java.net/~xliu/8231089/native_libraries/hotspot/webrev/ root: https://cr.openjdk.java.net/~xliu/8231089/native_libraries/root/webrev/ so the new target 'test-image' is added. to fix https://gist.github.com/navyxliu/bacd47891b17ac8d33d04708b648b531, I added "LDFLAGS_SUFFIX := $$(LIBCXX), " to TestFilesCompilation.gmk. Thanks, --lx From: Konstantin Shefov Date: Friday, September 20, 2019 at 11:01 AM To: "Liu, Xin" , "jdk8u-dev at openjdk.java.net" Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, Liu Xin > I am refactoring makefiles. I plan to upload this webrev today. Fine! We will try to compile with our toolchains. >> BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. > Could you give me an example tests for this? One example is this https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/ConflictingDefaultsTest.java#L329 And most of vmTestbase/vm/runtime/defmeth tests seem to test JVM spec in some way. See here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L50 and here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L134 Konstantin From: Liu, Xin Sent: Friday, September 20, 2019 8:35 PM To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Konstantin, I am refactoring makefiles. I plan to upload this webrev today. I found that you have solved almost all problems. I can help to troubleshoot the remaining tests. >BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. Could you give me an example tests for this? Thanks, --lx From: Konstantin Shefov > Date: Friday, September 20, 2019 at 2:26 AM To: "Liu, Xin" >, "jdk8u-dev at openjdk.java.net" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, We will use your new patches to run tests and merge my changes with yours for those tests that will not work. BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. I see your webrevs do not contain native part build scripts for now. We have to address this problem so the scripts should work for older GCC versions also. Regards Konstantin From: "Liu, Xin" > Date: Wednesday, 18 September 2019 at 20:59 To: Konstantin Shefov >, "jdk8u-dev at openjdk.java.net" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, thank you for updating. We care about x86_64 and aarch64 as well. You ran more tests than us. we never run all vmTestbase. Previously, I used a ProblemList.txt file to screen Problem and move on. Do you plan to fix all problems before we check in? Back to refactor, I have filed a JBS issues. https://bugs.openjdk.java.net/browse/JDK-8231089 In the meanwhile, I start splitting the commits to individual hg changesets. https://cr.openjdk.java.net/~xliu/8231089/ 1. base -> copy code from tag jdk-14+14 intact commit for vmTestbase and testlib 2. make apiChanges for ProcessUtils and Unsafe Could you review it? 3. ClassFileInstaller needs /testlibrary it's because ClassFileInstaller is in /test/testlibrary. I use this script to install @library /testlibrary for all tests. out=$(grep "ClassFileInstaller" -R vmTestbase | awk '{print $1}') for i in $out; do f=${i%\:} gsed -i 's/@library \/vmTestbase/&\n * \/testlibrary/' $f done What do you think that this approach? If I got something wrong, we can update the webtrev with yours. thanks, --lx ________________________________ From: Konstantin Shefov > Sent: Wednesday, September 18, 2019 4:56 PM To: Liu, Xin; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi We ran the tests against x86_64 Ubuntu Linux and there are just the same failed tests as it was with Arm64 Ubuntu Linux plus 2 more tests: vmTestbase/gc/lock/jni/jnilock002/TestDescription.java vmTestbase/nsk/jdb/set/set001/set001.java Konstantin From: Konstantin Shefov Sent: Wednesday, September 11, 2019 10:53 AM To: 'Liu, Xin' >; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, LX Answering to your e-mail, as for what we modified in [3]: 1. API changes (Process, Unsafe), Xloggc option, that were not in your patches; 2. In a file hotspot/test/JtregNativeHotspot.gmk we changed "-lpthread" option to "-pthread" to prevent compilation error. I agree that there should be a series of patches to track file changes. As for investigation of failures: do you have the same? We ran against Arm64 platform, but we can try against x86-64 too. Konstantin From: Liu, Xin > Sent: Monday, September 9, 2019 11:04 PM To: Konstantin Shefov >; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, We are glad to work with you to get vmTestbase landed into jdk8u. Our original intent is get design reviewed by the jdk8u maintainer. After then, we can proceed to refactor it. We can work together to refactor it. we plan to do it anyway. Back to the webrev you send. What did you modify in [3]? Ideally, we can should have a series of patches. The first one should be intact vmTestbase code from the tip of JDK. All we changes should come after it and be reviewed by this mail-list. In addition to refactoring, we can also offer help to figure out those failed cases. What do you think? Thanks, --lx From: Konstantin Shefov > Date: Friday, September 6, 2019 at 12:55 PM To: "jdk8u-dev at openjdk.java.net" > Cc: "Liu, Xin" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, We at Azul think it is a good idea to backport vmTestbase tests to OpenJDK 8. We have used patches you suggested, done some refactoring to enable more tests to work with JDK 8. We have run all 3550 tests from "vmTestbase" folder against Zulu 8 at ARM64 platform: 1. 3371 tests PASS (see [1]); 2. 179 tests FAIL (see [2]): reasons are being investigated. Patches we have used (contain our refactoring): 1. Hotspot folder [3] 2. Main folder [4] We plan to investigate causes of those 177 failures, purify unused code from hotspot/test/test/lib/jdk, and run the tests against different platforms. We also compared vmTestbase from JDK 11 with that from JDK 13, we found out: 1. 332 test have been removed in JDK 13; 2. Only 2 test have been added in JDK 13; 3. Tests that remained were modified, but these modifications mostly are copyright years, or output format, or API changes. From the above results we can tell that vmTestbase does not grow. It looks like that tests are been removed from there or transferred somewhere else. [1] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/passed_tests.html [2] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/failed_tests.html [3] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_hotspot.patch [4] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_root.patch Regards, --Konstantin From xxinliu at amazon.com Thu Sep 26 17:29:39 2019 From: xxinliu at amazon.com (Liu, Xin) Date: Thu, 26 Sep 2019 17:29:39 +0000 Subject: [8u] RFR(XS) 8231494: fix a typo in hash functions Message-ID: Hi, reviewer, Could you review this trivial change? I think it?s a typo and get better hash function. JBS: https://bugs.openjdk.java.net/browse/JDK-8231494 Webrev: https://cr.openjdk.java.net/~xliu/8231494/webrev/ I didn?t backport JDK-8055283 because it?s not necessary. Thanks, --lx From hohensee at amazon.com Thu Sep 26 18:12:59 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 26 Sep 2019 18:12:59 +0000 Subject: [8u] RFR(XS) 8231494: fix a typo in hash functions In-Reply-To: References: Message-ID: Looks good. Paul ?On 9/26/19, 10:32 AM, "jdk8u-dev on behalf of Liu, Xin" wrote: Hi, reviewer, Could you review this trivial change? I think it?s a typo and get better hash function. JBS: https://bugs.openjdk.java.net/browse/JDK-8231494 Webrev: https://cr.openjdk.java.net/~xliu/8231494/webrev/ I didn?t backport JDK-8055283 because it?s not necessary. Thanks, --lx From gromero at linux.vnet.ibm.com Fri Sep 27 03:31:27 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Fri, 27 Sep 2019 00:31:27 -0300 Subject: [8u] RFR for backport of 8198894 (CRC32 1/4): [PPC64] More generic vector CRC implementation Message-ID: <0dc83fcb-4e09-5841-04be-aee615e5a7fd@linux.vnet.ibm.com> Hi, Could the following backport for jdk8u be reviewed please? The original change was mainly written to provide a better implementation for CRC32 and CRC32C, but it also improved the CRC32 performance in general. This backport is the first change of a patchset comprised of 4 changes aimed to backport all the latest CRC32 missing parts from JDK 11u. It's a PPC64-only change. Bug : https://bugs.openjdk.java.net/browse/JDK-8198894 Original: http://hg.openjdk.java.net/jdk/jdk/rev/7cd503c499a0 Backport: http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-review/8198894/ It was necessary to backport it to: - Adapt the file names to OpenJDK 8u - Remove CRC32C part, leaving only CRC32 part, since OpenJDK 8u has no CRC32C - Add Assembler::add_const_optimized() from "8077838: Recent developments for ppc" [0] - Fix vpermxor() opcode, replacing VPMSUMW_OPCODE by VPERMXOR_OPCODE, accordingly to fix in "8190781: ppc64 + s390: Fix CriticalJNINatives" [1] - Adapt signatures for the following functions and their callers, accordingly to "8175369: [ppc] Provide intrinsic implementation for CRC32C" [2], also to ease subsequent backports in this patchset: a. MacroAssembler::update_byteLoop_crc32(), removing 'invertCRC' parameter b. MacroAssembler::kernel_crc32_1word(), adding 'invertCRC' parameter Thank you. Best regards, Gustavo [0] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/88847a1b3718 [1] http://hg.openjdk.java.net/jdk/jdk/rev/5a69ba3a4fd1#l1.7 [2] https://bugs.openjdk.java.net/browse/JDK-8175369 From gromero at linux.vnet.ibm.com Fri Sep 27 03:32:25 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Fri, 27 Sep 2019 00:32:25 -0300 Subject: [8u] RFR for backport of 8217459 (CRC32 4/4): [PPC64] Cleanup non-vector version of CRC32 Message-ID: <06bc93e6-59b4-95ec-7a27-ef789ac51564@linux.vnet.ibm.com> Hi, Could the following backport be reviewed please? Bug : https://bugs.openjdk.java.net/browse/JDK-8217459 Original: http://hg.openjdk.java.net/jdk/jdk/rev/60add902a57a Backport: http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-review/8217459/ It's basically a clean up but can also reduce memory footprint for CRC32 constants. It also puts the CRC32 code in jdk8u in sync with jdk11u code, helping any future backport. It's a PPC64-only change except for shared code macros.hpp touched to include two macros not present in jdk8u yet. It was necessary to backport it to: - Adapt signature of kernel_crc32_vpmsum(), since parameter 'invertCRC' is not necessary and removed on a previous change in this patchset (CRC32 3/4). - Fix patch not applying clean due to context changes, mostly because kernel_crc32_vpmsum() and kernel_crc32_1word() parameter 'is_crc32c' was removed on previous changes in this patchset - Add {BIG,LITTLE}_ENDIAN_ONLY to src/share/vm/utilities/macros.hpp Thank you. Best regards, Gustavo From gromero at linux.vnet.ibm.com Fri Sep 27 03:32:06 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Fri, 27 Sep 2019 00:32:06 -0300 Subject: [8u] RFR for backport of 8216376 (CRC32 2/4): [PPC64] Possibly unreliable stack frame resizing in template interpreter Message-ID: <73628ff7-5f89-7ce7-5902-773ca3043a9f@linux.vnet.ibm.com> Hi, Could the following backport for jdk8u be reviewed please? Bug : https://bugs.openjdk.java.net/browse/JDK-8216376 Original: http://hg.openjdk.java.net/jdk/jdk12/rev/672b629e1f72 Backport: http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-review/8216376/ It improves stack frame resizing in the interpreter and is also a preparation to subsequent changes in the CRC32 backport patchset. It's a PPC64-only change. It was necessary to backport it to: - Adapt file names to OpenJDK 8u - Remove code related to crc32c part Thank you. Best regards, Gustavo From gromero at linux.vnet.ibm.com Fri Sep 27 03:32:14 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Fri, 27 Sep 2019 00:32:14 -0300 Subject: [8u] RFR for backport of 8216060 (CRC32 3/4): [PPC64] Vector CRC implementation should be used by interpreter and be faster for short arrays Message-ID: <675a6c68-ca08-27ba-d9cb-8fa02efc5102@linux.vnet.ibm.com> Hi, Could the following backport be reviewed please? Bug : https://bugs.openjdk.java.net/browse/JDK-8216060 Original: http://hg.openjdk.java.net/jdk/jdk/rev/e17d7ffad9e3 Backport: http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-review/8216060/ It enhances performance for CRC32 computed over short arrays and also wires up a faster CRC32 implementation to be used by the interpreter. It's also a preparation to the last change in this patchset. It's a PPC64-only change. It was necessary to backport it to: - Remove CRC32C code, basically removing is_crc32c in crc32(), and adapt callers - Remove mentions to CRC32C in generate_CRC32_updateBytes() stub code mark - Remove invertCRC when it's not necessary, like in a. kernel_crc32_1word() b. kernel_crc32_vpmsum() Thank you. Best regards, Gustavo From denghui.ddh at alibaba-inc.com Fri Sep 27 05:59:55 2019 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Fri, 27 Sep 2019 13:59:55 +0800 Subject: =?UTF-8?B?UmU6IFs4dV0gW0pGUl0gUkZSOiBKRlIgYmFja3BvcnRzIGZyb20gMTEuMC40?= In-Reply-To: References: <72db089a-fb9f-e088-8fcd-8a6e25bec29b@redhat.com> <4DE97FAF-FB3A-41C5-BCC2-1BE799E9AA6C@azul.com> <0FE4C1EB-FCD3-435B-A944-9786BB1EC7C9@azul.com> <961B2FE0-A663-4912-9E78-434F1D03B5F8@azul.com> , Message-ID: Hi, Please review this backports for: 8224172: [BUG] assert(jfr_is_event_enabled(id)) failed: invariant 8216064: [BUG] -XX:StartFlightRecording:settings= doesn't work properly 8226779: [TESTBUG] Test JFR API from Java agent 8214750: [BUG] Unnecessary

tags in jfr classes 8227011: Starting a JFR recording in response to JVMTI VMInit and / or Java agent premain corrupts memory http://cr.openjdk.java.net/~wzhuo/8224172/hotspot.00/ http://cr.openjdk.java.net/~wzhuo/8216064/jdk.00/ In fact, 8227011 is not in my plan, but test/jdk/jfr/javaagent/TestPremainAgent.java (8216064) will be failed without 8227011, I also checked the mail list and found no other people are backpoting it. Please help me to push it to jdk8u-jfr-incubator if you think there's no problem. Thanks Denghui Dong ------------------------------------------------------------------ From:Jaroslav Bachor?k Send Time:2019?9?16?(???) 17:53 To:Andrey Petushkov Cc:???(??) ; jdk8u-dev ; Ekaterina Vergizova Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 On Wed, Sep 11, 2019 at 12:20 PM Jaroslav Bachor?k wrote: Hi all, we are planning to port also the following patches https://bugs.openjdk.java.net/browse/JDK-8210158 (already in 11u) This one turned out to be not applicable to jdk8u https://bugs.openjdk.java.net/browse/JDK-8225797 (being worked on in dev, will be backported to 11u adn jdk8u once done) This fix has been merged to dev and I started working on the backport to 11u. So far it seems that the backport will be far from simple as it touches many places which are fundamentally different in dev, 11u and 8u :/ -JB- Cheers, -JB- On Tue, Sep 10, 2019 at 2:53 PM Andrey Petushkov wrote: Hi Denghui, Thank you. We'll take care of it then. The list of backports we're currently working on (for jdk8u incubator) was part of initial email. For convenience please find it below: https://bugs.openjdk.java.net/browse/JDK-8185525: Add JFR event for DictionarySizes https://bugs.openjdk.java.net/browse/JDK-8213448: [TESTBUG] enhance jfr/jvm/TestDumpOnCrash https://bugs.openjdk.java.net/browse/JDK-8215727: Restore JFR thread sampler loop to old / previous behavior https://bugs.openjdk.java.net/browse/JDK-8216283: Allow shorter method sampling interval than 10 ms https://bugs.openjdk.java.net/browse/JDK-8217362: Emergency dump does not work when disk=false is set https://bugs.openjdk.java.net/browse/JDK-8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64 https://bugs.openjdk.java.net/browse/JDK-8219566: JFR did not collect call stacks when MaxJavaStackTraceDepth is set to zero https://bugs.openjdk.java.net/browse/JDK-8219997: [TESTBUG] Create test for JFR events in Docker container: CPU, Memory and Process Info https://bugs.openjdk.java.net/browse/JDK-8220293: Deadlock in JFR string pool https://bugs.openjdk.java.net/browse/JDK-8220555: JFR tool shows potentially misleading message when it cannot access a file https://bugs.openjdk.java.net/browse/JDK-8220657: JFR.dump does not work when filename is set https://bugs.openjdk.java.net/browse/JDK-8221569: JFR tool produces incorrect output when both --categories and --events are specified https://bugs.openjdk.java.net/browse/JDK-8221711: [TESTBUG] create more tests for JFR in container environment https://bugs.openjdk.java.net/browse/JDK-8222888: [TESTBUG] docker/TestJFREvents.java fails due to "RuntimeException: JAVA_MAIN_CLASS_ is not defined" https://bugs.openjdk.java.net/browse/JDK-8223438: add VirtualizationInformation JFR event https://bugs.openjdk.java.net/browse/JDK-8223599: minimal build fails after JDK-8185525 https://bugs.openjdk.java.net/browse/JDK-8224217: RecordingInfo should use textual representation of path https://bugs.openjdk.java.net/browse/JDK-8225310: JFR crashed in JfrPeriodicEventSet::requestProtectionDomainCacheTableStatistics() from these there are number of issues which are not yet ported to jdk11u. We're on it, some of them have been pushed to jdk11u today. The rest are: https://bugs.openjdk.java.net/browse/JDK-8185525: Add JFR event for DictionarySizes https://bugs.openjdk.java.net/browse/JDK-8223599: minimal build fails after JDK-8185525 https://bugs.openjdk.java.net/browse/JDK-8225310: JFR crashed in JfrPeriodicEventSet::requestProtectionDomainCacheTableStatistics() https://bugs.openjdk.java.net/browse/JDK-8217362: Emergency dump does not work when disk=false is set https://bugs.openjdk.java.net/browse/JDK-8224217: RecordingInfo should use textual representation of path we'll working on preparing review requests for those into jdk11u Best Regards, Andrey > On 10 Sep 2019, at 08:04, DDH wrote: > > Hi Andrey, > > Since you have already processed on 8223438([Enhancement] add VirtualizationInformation JFR event), > we think that we don't need to do this issue again, we will remove it from our list. > By the way, can you send us a complete list that you will backport? We can double check there are any repeated issues. > > Thanks, > DDH > ------------------------------------------------------------------ > From:Andrey Petushkov > Send Time:2019?9?9?(???) 20:59 > To:Mario Torre ; ???(??) > Cc:jdk8u-dev ; Ekaterina Vergizova > Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 > > Hi Denghui, > > Just a note, from the list below one backport (8223438: [Enhancement] add VirtualizationInformation JFR event) > is already proposed for integration as part of Azul's effort ([1]). > However since it's not yet integrated into jdk11u there still work to be done. We can do it, but if you'd like > and if you feel it's more convenient, you can take over. Anyway you might want to check implementation of > the backport in the respective webrev ([2]). Please let us know, thanks > > Regards, > Andrey > > [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-September/010204.html > [2] http://cr.openjdk.java.net/~apetushkov/jfr_backports_katya/11.0.4/ > > On 9 Sep 2019, at 12:37, Mario Torre wrote: > > Hi Denghui, > > Yes, the list looks good to me. As you mentioned, we should try first > the 11u backports and then backport to 8u. > > The process for the backport is highlighted here: > https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix > > Cheers, > Mario > > On Mon, Sep 9, 2019 at 4:07 AM DDH wrote: > > hi all, > We(Alibaba) picked some jfr backports as follows from JBS > (https://bugs.openjdk.java.net/browse/JDK-8230624?jql=Subcomponent%20%3D%20jfr%20and%20resolution%20%3D%20Fixed%20and%20fixVersion%20%3E%2011.0.6%20and%20type%20!%3D%20Backport), we > think it is worth porting them to 8u/11u. > We plan to backport them to 11u at first, and then to 8u, what's your comment? > If you think it is reasonable, we can provide our webrev of some issues as soon as possible, and continue work on other issues. > > 8223396: [TESTBUG] several jfr tests do not clean up files created in /tmp > 8225004: Remove invalid assertion in jfr_conditional_flush() > 8214542: [BUG] JFR: Old Object Sample event slow on a deep heap in debug builds (Unresolved) > 8228834: [BUG] Regression caused by JDK-8214542 not installing complete checkpoint data to candidates > 8228359: [TESTBUG] jdk.jfr.e.g.c.TestGCHeapConfigurationEventWith32BitOops.java does not expect MinHeapSize to be aligned to HeapAlignment > 8227605: [BUG] Kitchensink fails "assert((((klass)->trace_id() & (JfrTraceIdEpoch::leakp_in_use_this_epoch_bit())) != 0)) failed: invariant" > 8227411: [BUG] TestTimeMultiple.java failed "assert(!lease()) failed: invariant" > 8224172: [BUG] assert(jfr_is_event_enabled(id)) failed: invariant > 8212663: [BUG] Remove conservative at_safepoint assert when JFR writes type sets during class unloading > 8216064: [BUG] -XX:StartFlightRecording:settings= doesn't work properly > 8214750: [BUG] Unnecessary

tags in jfr classes > 8213570: [TESTBUG] Update JFR sanity test set > 8226779: [TESTBUG] Test JFR API from Java agent > 8229189: [Enhancement] Improve JFR leak profiler tracing to deal with discontiguous heaps > 8223438: [Enhancement] add VirtualizationInformation JFR event > > ------------------------------------------------------------------ > From:Andrey Petushkov > Send Time:2019?9?5?(???) 23:55 > To:Mario Torre > Cc:jdk8u-dev at openjdk.java.net > Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 > > Hi Mario, > > The following fixes apply trivially to jdk11u, so I've requested the permission to backport per process. > > https://bugs.openjdk.java.net/browse/JDK-8220555 > https://bugs.openjdk.java.net/browse/JDK-8221711 > https://bugs.openjdk.java.net/browse/JDK-8222888 > https://bugs.openjdk.java.net/browse/JDK-8221569 > https://bugs.openjdk.java.net/browse/JDK-8216283 > > The rest require some rework, I'll post RFRs soon > > Thanks, > Andrey > > On 4 Sep 2019, at 17:47, Mario Torre wrote: > > Awesome, thanks for checking zero. > > As discussed offline, we have a few backports that were directly > backported to 8u without first being in 11u: > > https://bugs.openjdk.java.net/browse/JDK-8185525 > https://bugs.openjdk.java.net/browse/JDK-8223599 > https://bugs.openjdk.java.net/browse/JDK-8225310 > https://bugs.openjdk.java.net/browse/JDK-8221711 > https://bugs.openjdk.java.net/browse/JDK-8222888 > https://bugs.openjdk.java.net/browse/JDK-8216283 > https://bugs.openjdk.java.net/browse/JDK-8220555 > https://bugs.openjdk.java.net/browse/JDK-8217362 > https://bugs.openjdk.java.net/browse/JDK-8221569 > https://bugs.openjdk.java.net/browse/JDK-8224217 > > A couple of those are wither being worked on or of interest for 11u, > so they should be fine, some aren't and while may not be critical I > think they are nice to have (like the container tests), so I would > expect all of them to be backported to 11u. > > Since this is a staging repository we may go ahead and push them and > work on the backport to 11 afterward, but I would prefer to not create > a discrepancy at this moment, so if possible we should work on the > backports to 11 first. > > Cheers, > Mario > > > On Wed, Sep 4, 2019 at 4:09 PM Andrey Petushkov wrote: > > Hi Mario, > > zero build is fine (e.g. mentioned method has default no-op implementation in vm_version.hpp) > > Andrey > > On 4 Sep 2019, at 12:52, Mario Torre wrote: > > On 03/09/2019 13:53, Andrey Petushkov wrote: > Dear All, > > could you please consider the following set of backports of the JFR fixes from 11.0.4 release into 8u incubator baseline: > > This seems good, the only nit I have now is that some of those changes > may break zero again, I think it may make sense to fix it in this patch > set instead of filing a dedicated bug report later. > > See for example: > > JDK-8219241 > > +void VM_Version::print_platform_virtualization_info(outputStream* st) { > > etc.. > > 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 > > > > -- > 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 Sep 27 06:02:11 2019 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Fri, 27 Sep 2019 14:02:11 +0800 Subject: =?UTF-8?B?UmU6IFs4dV0gW0pGUl0gUkZSOiBKRlIgYmFja3BvcnRzIGZyb20gMTEuMC40?= In-Reply-To: References: <72db089a-fb9f-e088-8fcd-8a6e25bec29b@redhat.com> <4DE97FAF-FB3A-41C5-BCC2-1BE799E9AA6C@azul.com> <0FE4C1EB-FCD3-435B-A944-9786BB1EC7C9@azul.com> <961B2FE0-A663-4912-9E78-434F1D03B5F8@azul.com> , , Message-ID: a mistake: 8214750 is already in jdk8u-jfr-incubator, and not included in this webrev. Thanks Denghui Dong ------------------------------------------------------------------ From:???(??) Send Time:2019?9?27?(???) 13:59 To:jdk8u-dev Cc:Mario Torre ; Andrey Petushkov Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 Hi, Please review this backports for: 8224172: [BUG] assert(jfr_is_event_enabled(id)) failed: invariant 8216064: [BUG] -XX:StartFlightRecording:settings= doesn't work properly 8226779: [TESTBUG] Test JFR API from Java agent 8214750: [BUG] Unnecessary

tags in jfr classes 8227011: Starting a JFR recording in response to JVMTI VMInit and / or Java agent premain corrupts memory http://cr.openjdk.java.net/~wzhuo/8224172/hotspot.00/ http://cr.openjdk.java.net/~wzhuo/8216064/jdk.00/ In fact, 8227011 is not in my plan, but test/jdk/jfr/javaagent/TestPremainAgent.java (8216064) will be failed without 8227011, I also checked the mail list and found no other people are backpoting it. Please help me to push it to jdk8u-jfr-incubator if you think there's no problem. Thanks Denghui Dong ------------------------------------------------------------------ From:Jaroslav Bachor?k Send Time:2019?9?16?(???) 17:53 To:Andrey Petushkov Cc:???(??) ; jdk8u-dev ; Ekaterina Vergizova Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 On Wed, Sep 11, 2019 at 12:20 PM Jaroslav Bachor?k wrote: Hi all, we are planning to port also the following patches https://bugs.openjdk.java.net/browse/JDK-8210158 (already in 11u) This one turned out to be not applicable to jdk8u https://bugs.openjdk.java.net/browse/JDK-8225797 (being worked on in dev, will be backported to 11u adn jdk8u once done) This fix has been merged to dev and I started working on the backport to 11u. So far it seems that the backport will be far from simple as it touches many places which are fundamentally different in dev, 11u and 8u :/ -JB- Cheers, -JB- On Tue, Sep 10, 2019 at 2:53 PM Andrey Petushkov wrote: Hi Denghui, Thank you. We'll take care of it then. The list of backports we're currently working on (for jdk8u incubator) was part of initial email. For convenience please find it below: https://bugs.openjdk.java.net/browse/JDK-8185525: Add JFR event for DictionarySizes https://bugs.openjdk.java.net/browse/JDK-8213448: [TESTBUG] enhance jfr/jvm/TestDumpOnCrash https://bugs.openjdk.java.net/browse/JDK-8215727: Restore JFR thread sampler loop to old / previous behavior https://bugs.openjdk.java.net/browse/JDK-8216283: Allow shorter method sampling interval than 10 ms https://bugs.openjdk.java.net/browse/JDK-8217362: Emergency dump does not work when disk=false is set https://bugs.openjdk.java.net/browse/JDK-8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64 https://bugs.openjdk.java.net/browse/JDK-8219566: JFR did not collect call stacks when MaxJavaStackTraceDepth is set to zero https://bugs.openjdk.java.net/browse/JDK-8219997: [TESTBUG] Create test for JFR events in Docker container: CPU, Memory and Process Info https://bugs.openjdk.java.net/browse/JDK-8220293: Deadlock in JFR string pool https://bugs.openjdk.java.net/browse/JDK-8220555: JFR tool shows potentially misleading message when it cannot access a file https://bugs.openjdk.java.net/browse/JDK-8220657: JFR.dump does not work when filename is set https://bugs.openjdk.java.net/browse/JDK-8221569: JFR tool produces incorrect output when both --categories and --events are specified https://bugs.openjdk.java.net/browse/JDK-8221711: [TESTBUG] create more tests for JFR in container environment https://bugs.openjdk.java.net/browse/JDK-8222888: [TESTBUG] docker/TestJFREvents.java fails due to "RuntimeException: JAVA_MAIN_CLASS_ is not defined" https://bugs.openjdk.java.net/browse/JDK-8223438: add VirtualizationInformation JFR event https://bugs.openjdk.java.net/browse/JDK-8223599: minimal build fails after JDK-8185525 https://bugs.openjdk.java.net/browse/JDK-8224217: RecordingInfo should use textual representation of path https://bugs.openjdk.java.net/browse/JDK-8225310: JFR crashed in JfrPeriodicEventSet::requestProtectionDomainCacheTableStatistics() from these there are number of issues which are not yet ported to jdk11u. We're on it, some of them have been pushed to jdk11u today. The rest are: https://bugs.openjdk.java.net/browse/JDK-8185525: Add JFR event for DictionarySizes https://bugs.openjdk.java.net/browse/JDK-8223599: minimal build fails after JDK-8185525 https://bugs.openjdk.java.net/browse/JDK-8225310: JFR crashed in JfrPeriodicEventSet::requestProtectionDomainCacheTableStatistics() https://bugs.openjdk.java.net/browse/JDK-8217362: Emergency dump does not work when disk=false is set https://bugs.openjdk.java.net/browse/JDK-8224217: RecordingInfo should use textual representation of path we'll working on preparing review requests for those into jdk11u Best Regards, Andrey > On 10 Sep 2019, at 08:04, DDH wrote: > > Hi Andrey, > > Since you have already processed on 8223438([Enhancement] add VirtualizationInformation JFR event), > we think that we don't need to do this issue again, we will remove it from our list. > By the way, can you send us a complete list that you will backport? We can double check there are any repeated issues. > > Thanks, > DDH > ------------------------------------------------------------------ > From:Andrey Petushkov > Send Time:2019?9?9?(???) 20:59 > To:Mario Torre ; ???(??) > Cc:jdk8u-dev ; Ekaterina Vergizova > Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 > > Hi Denghui, > > Just a note, from the list below one backport (8223438: [Enhancement] add VirtualizationInformation JFR event) > is already proposed for integration as part of Azul's effort ([1]). > However since it's not yet integrated into jdk11u there still work to be done. We can do it, but if you'd like > and if you feel it's more convenient, you can take over. Anyway you might want to check implementation of > the backport in the respective webrev ([2]). Please let us know, thanks > > Regards, > Andrey > > [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-September/010204.html > [2] http://cr.openjdk.java.net/~apetushkov/jfr_backports_katya/11.0.4/ > > On 9 Sep 2019, at 12:37, Mario Torre wrote: > > Hi Denghui, > > Yes, the list looks good to me. As you mentioned, we should try first > the 11u backports and then backport to 8u. > > The process for the backport is highlighted here: > https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix > > Cheers, > Mario > > On Mon, Sep 9, 2019 at 4:07 AM DDH wrote: > > hi all, > We(Alibaba) picked some jfr backports as follows from JBS > (https://bugs.openjdk.java.net/browse/JDK-8230624?jql=Subcomponent%20%3D%20jfr%20and%20resolution%20%3D%20Fixed%20and%20fixVersion%20%3E%2011.0.6%20and%20type%20!%3D%20Backport), we > think it is worth porting them to 8u/11u. > We plan to backport them to 11u at first, and then to 8u, what's your comment? > If you think it is reasonable, we can provide our webrev of some issues as soon as possible, and continue work on other issues. > > 8223396: [TESTBUG] several jfr tests do not clean up files created in /tmp > 8225004: Remove invalid assertion in jfr_conditional_flush() > 8214542: [BUG] JFR: Old Object Sample event slow on a deep heap in debug builds (Unresolved) > 8228834: [BUG] Regression caused by JDK-8214542 not installing complete checkpoint data to candidates > 8228359: [TESTBUG] jdk.jfr.e.g.c.TestGCHeapConfigurationEventWith32BitOops.java does not expect MinHeapSize to be aligned to HeapAlignment > 8227605: [BUG] Kitchensink fails "assert((((klass)->trace_id() & (JfrTraceIdEpoch::leakp_in_use_this_epoch_bit())) != 0)) failed: invariant" > 8227411: [BUG] TestTimeMultiple.java failed "assert(!lease()) failed: invariant" > 8224172: [BUG] assert(jfr_is_event_enabled(id)) failed: invariant > 8212663: [BUG] Remove conservative at_safepoint assert when JFR writes type sets during class unloading > 8216064: [BUG] -XX:StartFlightRecording:settings= doesn't work properly > 8214750: [BUG] Unnecessary

tags in jfr classes > 8213570: [TESTBUG] Update JFR sanity test set > 8226779: [TESTBUG] Test JFR API from Java agent > 8229189: [Enhancement] Improve JFR leak profiler tracing to deal with discontiguous heaps > 8223438: [Enhancement] add VirtualizationInformation JFR event > > ------------------------------------------------------------------ > From:Andrey Petushkov > Send Time:2019?9?5?(???) 23:55 > To:Mario Torre > Cc:jdk8u-dev at openjdk.java.net > Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 > > Hi Mario, > > The following fixes apply trivially to jdk11u, so I've requested the permission to backport per process. > > https://bugs.openjdk.java.net/browse/JDK-8220555 > https://bugs.openjdk.java.net/browse/JDK-8221711 > https://bugs.openjdk.java.net/browse/JDK-8222888 > https://bugs.openjdk.java.net/browse/JDK-8221569 > https://bugs.openjdk.java.net/browse/JDK-8216283 > > The rest require some rework, I'll post RFRs soon > > Thanks, > Andrey > > On 4 Sep 2019, at 17:47, Mario Torre wrote: > > Awesome, thanks for checking zero. > > As discussed offline, we have a few backports that were directly > backported to 8u without first being in 11u: > > https://bugs.openjdk.java.net/browse/JDK-8185525 > https://bugs.openjdk.java.net/browse/JDK-8223599 > https://bugs.openjdk.java.net/browse/JDK-8225310 > https://bugs.openjdk.java.net/browse/JDK-8221711 > https://bugs.openjdk.java.net/browse/JDK-8222888 > https://bugs.openjdk.java.net/browse/JDK-8216283 > https://bugs.openjdk.java.net/browse/JDK-8220555 > https://bugs.openjdk.java.net/browse/JDK-8217362 > https://bugs.openjdk.java.net/browse/JDK-8221569 > https://bugs.openjdk.java.net/browse/JDK-8224217 > > A couple of those are wither being worked on or of interest for 11u, > so they should be fine, some aren't and while may not be critical I > think they are nice to have (like the container tests), so I would > expect all of them to be backported to 11u. > > Since this is a staging repository we may go ahead and push them and > work on the backport to 11 afterward, but I would prefer to not create > a discrepancy at this moment, so if possible we should work on the > backports to 11 first. > > Cheers, > Mario > > > On Wed, Sep 4, 2019 at 4:09 PM Andrey Petushkov wrote: > > Hi Mario, > > zero build is fine (e.g. mentioned method has default no-op implementation in vm_version.hpp) > > Andrey > > On 4 Sep 2019, at 12:52, Mario Torre wrote: > > On 03/09/2019 13:53, Andrey Petushkov wrote: > Dear All, > > could you please consider the following set of backports of the JFR fixes from 11.0.4 release into 8u incubator baseline: > > This seems good, the only nit I have now is that some of those changes > may break zero again, I think it may make sense to fix it in this patch > set instead of filing a dedicated bug report later. > > See for example: > > JDK-8219241 > > +void VM_Version::print_platform_virtualization_info(outputStream* st) { > > etc.. > > 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 > > > > -- > 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 Sep 27 08:33:58 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 27 Sep 2019 10:33:58 +0200 Subject: [8u] PING: RFR: 8213734: SAXParser.parse(File, ..) does not close resources when Exception occurs. In-Reply-To: References: <0a64931ab640afd557f4bd46aa7bb05512bc79d6.camel@redhat.com> Message-ID: <3adc99dd5410882edcf129859ddfb7b0648c941d.camel@redhat.com> Hi! I'd appreciate a review of this one. Thanks in advance! See below. On Tue, 2019-09-03 at 17:50 +0200, Severin Gehwolf wrote: > On Mon, 2019-08-26 at 17:54 +0200, Severin Gehwolf wrote: > > 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 { > > > > Gentle reminder. Anyone? It's been a month :( FWIW, I've updated XMLEntityManager to include the copyright update upper bound to 2018. The @LastModified lines don't exist in JDK 8u, so I've omitted that. Latest webrevs: 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/02/webrev/ Thanks, Severin From sgehwolf at redhat.com Fri Sep 27 15:48:02 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 27 Sep 2019 17:48:02 +0200 Subject: [8u] RFR: 8227397: Add --with-extra-asflags configure option Message-ID: <62e03a27132a82b9f8f22c8fb16d21fba66a7bb6.camel@redhat.com> Hi, Could I please get a review of this 8u build change backport which adds --with-extra-asflags to OpenJDK 8u. At Red Hat, we need to pass certain assembler only flags for some builds. For example "-Wa,--generate- missing-build-notes=yes", to assembly files only. As the build system is different in 8u over 11u I've re-done the patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8227397 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227397/jdk8/01/ Testing: Built with --with-extra-asflags=-Wa,--generate-missing-build- notes=yes on Linux x86_64, confirmed linux_x86_64.s gets assembled with the flag and only that file. I've omitted the windows portion of passing as flags to the hotspot build as I've no idea how. Contributions welcome if that should get included. Thoughts? Thanks, Severin From sgehwolf at redhat.com Fri Sep 27 15:52:20 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 27 Sep 2019 17:52:20 +0200 Subject: [8u] RFR: 8219772: EXTRA_CFLAGS not being picked up for assembler files In-Reply-To: References: <7f87fd812c222ded2a530bad406eece42a079c6e.camel@redhat.com> <0ff9a2d7-d8ee-582d-0332-00a3a4e72edb@redhat.com> Message-ID: <71b8059a8fefbc3f7a9bec026d09114f38f036c4.camel@redhat.com> On Mon, 2019-03-11 at 20:58 +0100, Severin Gehwolf wrote: > On Mon, 2019-03-11 at 18:01 +0000, Andrew John Hughes wrote: > > On 11/03/2019 10:45, Severin Gehwolf wrote: > > > Hi, > > > > > > Could somebody please review this one-liner change for the 8u (OpenJDK) > > > build system? The issue at hand is that for assembler source files > > > extra C flags are not being passed to the compiler (GCC in the Linux > > > case). This is a problem for instrumented builds to facilitate checks > > > on produced binaries in terms of optimization flags and other build- > > > time invariants[1]. The patch doesn't affect builds without extra C- > > > flags. Thus, risk should be minimal. > > > > > > This is an 8u-only change. The new build system in JDK 11 and up seems > > > to handle these cases correctly. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8219772 > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8219772/01/webrev/ > > > > > > Testing: Compiling with extra cflags, inspecting build logs for > > > assembler source files on Linux x86_64 > > > > > > Thoughts? > > > > > > Thanks, > > > Severin > > > > > > [1] https://developers.redhat.com/blog/2019/02/04/annocheck-examining-the-contents-of-binary-files/ > > > > > > > Surely the correct way to do this is to add an --with-extra-asflags > > option rather than abuse flags for the C compiler? > > Fair enough. It would require for this option to go into jdk/jdk first, > which seems reasonable. Proposed this for review now (it's in jdk/jdk and jdk 11.0.6): http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-September/010393.html Thanks, Severin From gnu.andrew at redhat.com Fri Sep 27 16:36:32 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 27 Sep 2019 17:36:32 +0100 Subject: [8u] RFR(XS) 8231494: fix a typo in hash functions In-Reply-To: References: Message-ID: <1a0dd78e-8852-eb9a-3b85-c033498b59ae@redhat.com> On 26/09/2019 18:29, Liu, Xin wrote: > Hi, reviewer, > > Could you review this trivial change? I think it?s a typo and get better hash function. > JBS: https://bugs.openjdk.java.net/browse/JDK-8231494 > Webrev: https://cr.openjdk.java.net/~xliu/8231494/webrev/ > > I didn?t backport JDK-8055283 because it?s not necessary. > > Thanks, > --lx > > Can you elaborate on why you chose not to backport JDK-8055283? It also adds tests for resourceHash and is a pretty straight-forward backport. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Fri Sep 27 16:53:17 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 27 Sep 2019 17:53:17 +0100 Subject: [RFR] [8u] JDK-8055283: Expand ResourceHashtable with C_HEAP allocation, removal and some unit tests Message-ID: <09e87ea3-1d5e-5870-c120-d5331b78083a@redhat.com> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8055283/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8055283 This is largely a clean backport, bar some context differences. It fixes a typo in the hash function, as well as adding tests for ResourceHashtable. I also included the change of return value for ResourceHashtable::put from void to bool from JDK-8035946 for the benefit of the unit tests. I didn't bring in the main body of that fix because it fixes issues with changes to dependency checks introduced by JDK-8035946, JDK-8034839 & JDK-7194669 [0] [1] [2], none of which are present in 8u. Given the number of revisions of those fixes, it seems better to steer clear of backporting these. New tests run fine: $ /mnt/builder/8u-dev/images/j2sdk-image/bin/java -XX:+ExecuteInternalVMTests -version Running internal VM tests Running test: TestOS_test() Running test: TestReservedSpace_test() Running test: TestReserveMemorySpecial_test() Running test: TestVirtualSpace_test() Running test: TestMetaspaceAux_test() Running test: TestMetachunk_test() Running test: TestVirtualSpaceNode_test() Running test: GlobalDefinitions::test_globals() Running test: GlobalDefinitions::test_proper_unit() Running test: GCTimerAllTest::all() Running test: arrayOopDesc::test_max_array_length() Running test: CollectedHeap::test_is_in() Running test: QuickSort::test_quick_sort() Running test: GuardedMemory::test_guarded_memory() Running test: AltHashing::test_alt_hash() Running test: test_loggc_filename() Running test: test_snprintf() Running test: TestNewSize_test() Running test: TestKlass_test() Running test: TestResourcehash_test() Running test: Test_linked_list() Running test: TestChunkedList_test() Running test: ObjectMonitor::sanity_checks() WARNING: the _header and _owner fields are closer than a cache line which permits false sharing. WARNING: ObjectMonitor size is not a multiple of a cache line which permits false sharing. INFO: error_cnt=0 INFO: warning_cnt=2 Running test: VMStructs::test() Running test: TestOldFreeSpaceCalculation_test() Running test: TestG1BiasedArray_test() Running test: HeapRegionRemSet::test_prt() Running test: SpaceManager_test_adjust_initial_chunk_size() Running test: ChunkManager_test_list_index() Running test: TestBufferingOopClosure_test() Running test: TestCodeCacheRemSet_test() All internal VM tests passed openjdk version "1.8.0-internal-debug" OpenJDK Runtime Environment (build 1.8.0-internal-debug-andre_2019_09_27_17_02-b00) OpenJDK 64-Bit Server VM (build 25.71-b00-debug, mixed mode) [1] https://bugs.openjdk.java.net/browse/JDK-8035946 [2] https://bugs.openjdk.java.net/browse/JDK-8034839 [3] https://bugs.openjdk.java.net/browse/JDK-7194669 -- 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 Sep 27 20:39:28 2019 From: xxinliu at amazon.com (Liu, Xin) Date: Fri, 27 Sep 2019 20:39:28 +0000 Subject: [8u] RFR(XS) 8231494: fix a typo in hash functions In-Reply-To: References: Message-ID: Hi, Andrew, I backported it and verified the test using hotspot/test/sanity/ExecuteInternalVMTests.java Here is webrev. https://cr.openjdk.java.net/~xliu/8231494/v1/webrev/ jdk8u-dev can apply the patch almost clean. The only thing I changed is make ResourceHashtable::put return a Boolean value. + bool put(K const& key, V const& value) { The test needs it. I also add label 'jdk8u-fix-request' to JDK-8055283 Thanks, --lx ?On 9/26/19, 10:32 AM, "jdk8u-dev on behalf of Liu, Xin" wrote: Hi, reviewer, Could you review this trivial change? I think it?s a typo and get better hash function. JBS: https://bugs.openjdk.java.net/browse/JDK-8231494 Webrev: https://cr.openjdk.java.net/~xliu/8231494/webrev/ I didn?t backport JDK-8055283 because it?s not necessary. Thanks, --lx From hohensee at amazon.com Fri Sep 27 22:10:45 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 27 Sep 2019 22:10:45 +0000 Subject: [RFR] [8u] JDK-8055283: Expand ResourceHashtable with C_HEAP allocation, removal and some unit tests In-Reply-To: <09e87ea3-1d5e-5870-c120-d5331b78083a@redhat.com> References: <09e87ea3-1d5e-5870-c120-d5331b78083a@redhat.com> Message-ID: <12F0E193-44FA-4A56-8D39-518A2E32B2CC@amazon.com> Looks good. 8231494 looks to be superceded by this backport. Paul ?On 9/27/19, 9:57 AM, "jdk8u-dev on behalf of Andrew John Hughes" wrote: Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8055283/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8055283 This is largely a clean backport, bar some context differences. It fixes a typo in the hash function, as well as adding tests for ResourceHashtable. I also included the change of return value for ResourceHashtable::put from void to bool from JDK-8035946 for the benefit of the unit tests. I didn't bring in the main body of that fix because it fixes issues with changes to dependency checks introduced by JDK-8035946, JDK-8034839 & JDK-7194669 [0] [1] [2], none of which are present in 8u. Given the number of revisions of those fixes, it seems better to steer clear of backporting these. New tests run fine: $ /mnt/builder/8u-dev/images/j2sdk-image/bin/java -XX:+ExecuteInternalVMTests -version Running internal VM tests Running test: TestOS_test() Running test: TestReservedSpace_test() Running test: TestReserveMemorySpecial_test() Running test: TestVirtualSpace_test() Running test: TestMetaspaceAux_test() Running test: TestMetachunk_test() Running test: TestVirtualSpaceNode_test() Running test: GlobalDefinitions::test_globals() Running test: GlobalDefinitions::test_proper_unit() Running test: GCTimerAllTest::all() Running test: arrayOopDesc::test_max_array_length() Running test: CollectedHeap::test_is_in() Running test: QuickSort::test_quick_sort() Running test: GuardedMemory::test_guarded_memory() Running test: AltHashing::test_alt_hash() Running test: test_loggc_filename() Running test: test_snprintf() Running test: TestNewSize_test() Running test: TestKlass_test() Running test: TestResourcehash_test() Running test: Test_linked_list() Running test: TestChunkedList_test() Running test: ObjectMonitor::sanity_checks() WARNING: the _header and _owner fields are closer than a cache line which permits false sharing. WARNING: ObjectMonitor size is not a multiple of a cache line which permits false sharing. INFO: error_cnt=0 INFO: warning_cnt=2 Running test: VMStructs::test() Running test: TestOldFreeSpaceCalculation_test() Running test: TestG1BiasedArray_test() Running test: HeapRegionRemSet::test_prt() Running test: SpaceManager_test_adjust_initial_chunk_size() Running test: ChunkManager_test_list_index() Running test: TestBufferingOopClosure_test() Running test: TestCodeCacheRemSet_test() All internal VM tests passed openjdk version "1.8.0-internal-debug" OpenJDK Runtime Environment (build 1.8.0-internal-debug-andre_2019_09_27_17_02-b00) OpenJDK 64-Bit Server VM (build 25.71-b00-debug, mixed mode) [1] https://bugs.openjdk.java.net/browse/JDK-8035946 [2] https://bugs.openjdk.java.net/browse/JDK-8034839 [3] https://bugs.openjdk.java.net/browse/JDK-7194669 -- 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 Sat Sep 28 05:09:41 2019 From: xxinliu at amazon.com (Liu, Xin) Date: Sat, 28 Sep 2019 05:09:41 +0000 Subject: [8u] RFR(XS) 8231494: fix a typo in hash functions In-Reply-To: References: Message-ID: <1543714B-8BF4-4A54-9E74-6897B06C10DA@amazon.com> Hi, Andrew, Here is the webrev for the backported patch. https://cr.openjdk.java.net/~xliu/8055283/webrev/ I only modified one line. + bool put(K const& key, V const& value) { Forget about JDK-8231494, I will close it after the backport goes into jdk8u-dev. Thanks, --lx ?On 9/27/19, 1:41 PM, "jdk8u-dev on behalf of Liu, Xin" wrote: Hi, Andrew, I backported it and verified the test using hotspot/test/sanity/ExecuteInternalVMTests.java Here is webrev. https://cr.openjdk.java.net/~xliu/8231494/v1/webrev/ jdk8u-dev can apply the patch almost clean. The only thing I changed is make ResourceHashtable::put return a Boolean value. + bool put(K const& key, V const& value) { The test needs it. I also add label 'jdk8u-fix-request' to JDK-8055283 Thanks, --lx On 9/26/19, 10:32 AM, "jdk8u-dev on behalf of Liu, Xin" wrote: Hi, reviewer, Could you review this trivial change? I think it?s a typo and get better hash function. JBS: https://bugs.openjdk.java.net/browse/JDK-8231494 Webrev: https://cr.openjdk.java.net/~xliu/8231494/webrev/ I didn?t backport JDK-8055283 because it?s not necessary. Thanks, --lx From xxinliu at amazon.com Sat Sep 28 05:27:13 2019 From: xxinliu at amazon.com (Liu, Xin) Date: Sat, 28 Sep 2019 05:27:13 +0000 Subject: [8u] RFR(XS) 8231494: fix a typo in hash functions In-Reply-To: <1543714B-8BF4-4A54-9E74-6897B06C10DA@amazon.com> References: <1543714B-8BF4-4A54-9E74-6897B06C10DA@amazon.com> Message-ID: <8A1F557D-7D6A-4E54-B320-701B0B6F13BD@amazon.com> Hi, Andrew, I just notice that you have sent a backport review to jdk8u. In this morning, I replied you but I sent to 'jdk8u-dev ', it probably went to nowhere. I read you CR. It's almost same as mine, but yours has better comments, So please go ahead. I've closed JDK-8231494. Thanks, --lx ?On 9/27/19, 10:11 PM, "jdk8u-dev on behalf of Liu, Xin" wrote: Hi, Andrew, Here is the webrev for the backported patch. https://cr.openjdk.java.net/~xliu/8055283/webrev/ I only modified one line. + bool put(K const& key, V const& value) { Forget about JDK-8231494, I will close it after the backport goes into jdk8u-dev. Thanks, --lx On 9/27/19, 1:41 PM, "jdk8u-dev on behalf of Liu, Xin" wrote: Hi, Andrew, I backported it and verified the test using hotspot/test/sanity/ExecuteInternalVMTests.java Here is webrev. https://cr.openjdk.java.net/~xliu/8231494/v1/webrev/ jdk8u-dev can apply the patch almost clean. The only thing I changed is make ResourceHashtable::put return a Boolean value. + bool put(K const& key, V const& value) { The test needs it. I also add label 'jdk8u-fix-request' to JDK-8055283 Thanks, --lx On 9/26/19, 10:32 AM, "jdk8u-dev on behalf of Liu, Xin" wrote: Hi, reviewer, Could you review this trivial change? I think it?s a typo and get better hash function. JBS: https://bugs.openjdk.java.net/browse/JDK-8231494 Webrev: https://cr.openjdk.java.net/~xliu/8231494/webrev/ I didn?t backport JDK-8055283 because it?s not necessary. Thanks, --lx From magnus.ihse.bursie at oracle.com Mon Sep 30 09:36:07 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 30 Sep 2019 11:36:07 +0200 Subject: [8u] RFR: 8227397: Add --with-extra-asflags configure option In-Reply-To: <62e03a27132a82b9f8f22c8fb16d21fba66a7bb6.camel@redhat.com> References: <62e03a27132a82b9f8f22c8fb16d21fba66a7bb6.camel@redhat.com> Message-ID: On 2019-09-27 17:48, Severin Gehwolf wrote: > Hi, > > Could I please get a review of this 8u build change backport which adds > --with-extra-asflags to OpenJDK 8u. At Red Hat, we need to pass certain > assembler only flags for some builds. For example "-Wa,--generate- > missing-build-notes=yes", to assembly files only. As the build system > is different in 8u over 11u I've re-done the patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227397 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227397/jdk8/01/ Looks good to me. /Magnus > > Testing: Built with --with-extra-asflags=-Wa,--generate-missing-build- > notes=yes on Linux x86_64, confirmed linux_x86_64.s gets assembled with > the flag and only that file. > > I've omitted the windows portion of passing as flags to the hotspot > build as I've no idea how. Contributions welcome if that should get > included. > > Thoughts? > > Thanks, > Severin > From sgehwolf at redhat.com Mon Sep 30 09:40:26 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 30 Sep 2019 11:40:26 +0200 Subject: [8u] RFR: 8227397: Add --with-extra-asflags configure option In-Reply-To: References: <62e03a27132a82b9f8f22c8fb16d21fba66a7bb6.camel@redhat.com> Message-ID: <2713290d3fe9b5fd4aecc47edb1e16d9b79c1063.camel@redhat.com> On Mon, 2019-09-30 at 11:36 +0200, Magnus Ihse Bursie wrote: > On 2019-09-27 17:48, Severin Gehwolf wrote: > > Hi, > > > > Could I please get a review of this 8u build change backport which adds > > --with-extra-asflags to OpenJDK 8u. At Red Hat, we need to pass certain > > assembler only flags for some builds. For example "-Wa,--generate- > > missing-build-notes=yes", to assembly files only. As the build system > > is different in 8u over 11u I've re-done the patch. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227397 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227397/jdk8/01/ > Looks good to me. > > /Magnus Thanks for the review, Magnus! Cheers, Severin > > Testing: Built with --with-extra-asflags=-Wa,--generate-missing-build- > > notes=yes on Linux x86_64, confirmed linux_x86_64.s gets assembled with > > the flag and only that file. > > > > I've omitted the windows portion of passing as flags to the hotspot > > build as I've no idea how. Contributions welcome if that should get > > included. > > > > Thoughts? > > > > Thanks, > > Severin > > > From ronmac1978 at hotmail.com Mon Sep 30 20:52:31 2019 From: ronmac1978 at hotmail.com (ronald mckenzie) Date: Mon, 30 Sep 2019 20:52:31 +0000 Subject: openjdk8u JVM libjvm.so link error on SPARC 32bit java execution Message-ID: Ive been beating my head against this for weeks so I thought I would try. I understand jdk8u 32 bit is not a supported Solaris sparc build anymore, but we have been using it for a little while now with some success knowing this was a opensource product and assuming that oracles direction did not affect opensource products direction. However we are using a really old version jdk8u74b02. When i tried to compile something a little newer, it compiles correctly, but when executing java it reports a ld.so error with reguards to libjvm.so which is present and in the correct location. Swapping older source code files from u74b02 to u232b04 and compiling allows us to get around this error, but we end up with a hacked build that is probably easily resolved if I could just navigate the millions of lines of code ??. The files I swap are in the hotspot source ( os_solaris.cpp, thread_solaris.inline.hpp, threadLocalStorage.{h,c}pp, threadLS_solaris_sparc{c,h}pp). One noteworthy item, if I compile in slowdebug mode , I do not see the link error, but have to ignore an error in the offset of 8 for AES. To follow the code, is well past my level of expertise, but I was hoping this might jar something of a memory as to a simple line is causing the linking issue. Again, i understand 32 bit sparc isnt supported and I wouldnt ask if I had other alternative. Thank you for any time you offer to help me. Respectfully, Ron From bob.vandette at oracle.com Mon Sep 30 21:13:19 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Mon, 30 Sep 2019 17:13:19 -0400 Subject: openjdk8u JVM libjvm.so link error on SPARC 32bit java execution In-Reply-To: References: Message-ID: <52BA90A6-F428-427C-B74A-6F2E7C5410C1@oracle.com> Ron, In order to rule out a 32-bit compiler problem, you might want to add your list of files in the makefile that reduces the optimization level for individual files. Look in hotspot/make/solaris/makefiles/sparc.make. Add your files to this file like this example: OPT_CFLAGS/ad_sparc.o $(OPT_CFLAGS/SLOWER) Bob. > On Sep 30, 2019, at 4:52 PM, ronald mckenzie wrote: > > Ive been beating my head against this for weeks so I thought I would try. I understand jdk8u 32 bit is not a supported Solaris sparc build anymore, but we have been using it for a little while now with some success knowing this was a opensource product and assuming that oracles direction did not affect opensource products direction. However we are using a really old version jdk8u74b02. When i tried to compile something a little newer, it compiles correctly, but when executing java it reports a ld.so error with reguards to libjvm.so which is present and in the correct location. Swapping older source code files from u74b02 to u232b04 and compiling allows us to get around this error, but we end up with a hacked build that is probably easily resolved if I could just navigate the millions of lines of code ??. The files I swap are in the hotspot source ( os_solaris.cpp, thread_solaris.inline.hpp, threadLocalStorage.{h,c}pp, threadLS_solaris_sparc{c,h}pp). One noteworthy item, if I compile in slowdebug mode , I do not see the link error, but have to ignore an error in the offset of 8 for AES. To follow the code, is well past my level of expertise, but I was hoping this might jar something of a memory as to a simple line is causing the linking issue. Again, i understand 32 bit sparc isnt supported and I wouldnt ask if I had other alternative. Thank you for any time you offer to help me. Respectfully, Ron From ramz.mohan88 at gmail.com Thu Sep 19 00:51:05 2019 From: ramz.mohan88 at gmail.com (Rammohan Vanteru) Date: Thu, 19 Sep 2019 00:51:05 -0000 Subject: JVM dynamic Attach api issue In-Reply-To: References: <9a90828c-1533-eb69-523e-33ebd7c9e296@redhat.com> Message-ID: Hi Andrew, We are using red linux OS we do not have any cronjobs configured to remove /tmp file system. Thanks Zhengyu, so its a jdk bug. Its a similar issue iam facing too. I see below jdk bug was fixed. Any idea as part of which release bug was fixed? Iam not able to find the release notes in regards to this bug. Thanks, Rammohan. On Wed, Sep 18, 2019 at 7:41 PM Zhengyu Gu wrote: > There is an existing thread on this issue. > > > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2019-June/034906.html > > -Zhengyu > > > > On 9/18/19 5:40 PM, Andrew Haley wrote: > > On 9/18/19 7:56 PM, Rammohan Vanteru wrote: > >> > >> I am facing an issue with JVM dynamic Attach api. We have a source code > >> which connects to target jvms using dynamic attach api which works fine > for > >> few days. After couple of days it start?s failing making connections to > >> target jvms because /tmp/.java_pid* is removed automatically. We also > see > >> that target JVMs?s generating thread dump?s in stdout. > >> > >> Currently we are using JDK version "1.8.0_172". > > > > Your operating system is doing this. I don't know exactly which OS > > that is. > > > > You should be able to find your system's documentation, and see how > > the auto-deletion is configured. Then you can turn it off. > > > From ramz.mohan88 at gmail.com Thu Sep 19 12:48:47 2019 From: ramz.mohan88 at gmail.com (Rammohan Vanteru) Date: Thu, 19 Sep 2019 12:48:47 -0000 Subject: JVM dynamic Attach api issue In-Reply-To: References: <9a90828c-1533-eb69-523e-33ebd7c9e296@redhat.com> <9254a20f-f205-28fe-da7f-2b5cf901fa8f@redhat.com> Message-ID: Hi Andrew/ Zhengyu, Yes iam reffering to https://bugs.openjdk.java.net/browse/JDK-8225690 . I will also cross check /usr/lib/tmpfiles.d/tmp.conf to exclude the /tmp/.java_pid files Thanks. Rammohan. On Thu, Sep 19, 2019 at 6:49 AM Zhengyu Gu wrote: > Hi Andrew > > On 9/19/19 4:31 AM, Andrew Haley wrote: > > On 9/19/19 1:50 AM, Rammohan Vanteru wrote: > >> > >> We are using red linux OS we do not have any cronjobs configured to > remove /tmp file system. > > > > Well, something is doing it. On my system I would edit the > /usr/lib/tmpfiles.d/tmp.conf > > to exclude the /tmp/.java_pid files. > > > >> Thanks Zhengyu, so its a jdk bug. Its a similar issue iam facing too. > >> > >> I see below jdk bug was fixed. > > > > I don't see that any bug was fixed. Which message are you referring to? > > > I think he referred to this CR: > > https://bugs.openjdk.java.net/browse/JDK-8225690 > > > -Zhengyu > > > > > >> Any idea as part of which release bug was fixed? Iam not able to find > the release notes in regards to this bug. > > > From dekeeler at microsoft.com Fri Sep 20 20:43:06 2019 From: dekeeler at microsoft.com (Derek Keeler) Date: Fri, 20 Sep 2019 20:43:06 -0000 Subject: [8u] RFR 8226288 - Upgrade to XCode 10+ for building JDK 8u and 11u In-Reply-To: References: <16e90c95-20dc-e784-32fe-1b8341498c08@redhat.com> , Message-ID: I'd been over-optimistic in my estimate and haven't gotten our pipeline in a state where it runs the AdoptOpenJDK tests completely quite yet. However, the build works just fine, and many of the tests do complete successfully. I'll follow up with more detailed results next week. -Derek ________________________________ From: Simon Tooke Sent: September 18, 2019 5:43 AM To: Derek Keeler ; jdk8u-dev at openjdk.java.net ; build-dev Subject: Re: [8u] RFR 8226288 - Upgrade to XCode 10+ for building JDK 8u and 11u On 9/17/2019 1:31 PM, Derek Keeler wrote: Hi build-dev friends! I'm Derek Keeler, the infrastructure lead on the Java Platform team within Microsoft, working with the AdoptOpenJDK's George Adams and John Oliver. Simon, I have pulled down your jdk8u patches and have built them against macOS Mojave (with a good amount of help from George and John). Hi, and thanks for your interest. Currently, the build succeeds! I am planning to throw the entire AdoptOpenJDK test roster against it sometime today/tomorrow. I will let you know what I find as a result of those tests, and what if anything I had to do in order to get things up and running. Yes, please. Also any difficulties you had with the initial script or instructions; I know there was a syntax error that I just fixed. -Simon -Derek ________________________________ From: build-dev on behalf of Simon Tooke Sent: September 13, 2019 7:05 AM To: jdk8u-dev at openjdk.java.net ; build-dev Subject: [8u] RFR 8226288 - Upgrade to XCode 10+ for building JDK 8u and 11u Hello all, This is a request for review of my patch to enable building 8u with modern (9,10,11) Xcode versions on macOS. I've received a few recent enquiries so I thought I'd submit this. When I first created this patch is was more for convenience, but soon macOS will require applications to be "notarized", which cannot be done with the old version of Xcode. This will become mandatory long before 8u is due to retire [1]. This patch is not intended to remove the current ability to build 8u on the current supported build platform. I have used the patch with Xcode 9,10 and a beta of 11, and used the resultant JDK to build Graal. I have not build a JDK using the old Xcode and this patch; my intent was to ensure this was still possible. There is some information available on my GitHub page: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fstooke%2Fjdk8u-xcode10&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865878108&sdata=THixfdOpuZrY8%2BdEDHFVjmV%2BnePxVGFsof9eDoqJikE%3D&reserved=0 Issue: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8226288&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865878108&sdata=VHN2S0uxbbeJiiuWznYafSpXmERDdp29U%2FqVMJSdUuw%3D&reserved=0 Webrev: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~stooke%2Fwebrevs%2Fjdk-8226288-jdk8u%2F00%2F&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865888100&sdata=T6uq0ThFfHLrqslWfCz2x846ixtLMIW5EwaP4U4Jvqc%3D&reserved=0 Previous discussion: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fjdk8u-dev%2F2019-June%2F009733.html&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865888100&sdata=WDUf2fhTqmcNTZJJ2NNnI%2FtCKxr%2BxQLiCfPmpj3m0p8%3D&reserved=0 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fjdk8u-dev%2F2019-July%2F009760.html&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865888100&sdata=pJXk%2Bg5LlmSpogNhcINgRezCSozo7MbW%2FNWLJNrf%2BV8%3D&reserved=0 Thank you for your time, -Simon [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.apple.com%2Fdocumentation%2Fsecurity%2Fnotarizing_your_app_before_distribution&data=02%7C01%7Cdekeeler%40microsoft.com%7Cc0539708320c4d8421a908d73853cbe8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637039804865888100&sdata=TZmbZfAFDXXwpBJ8xibzzfoCicd5Fwm0xwdCo2hIaYo%3D&reserved=0 From ygaevsky at azul.com Fri Sep 27 14:50:38 2019 From: ygaevsky at azul.com (Yuri Gaevsky) Date: Fri, 27 Sep 2019 14:50:38 -0000 Subject: Request for approval: JDK-8073108 "Use x86 and SPARC CPU instructions for GHASH acceleration" Message-ID: <3699d2a22d2c45318afb21b209c1c64c@azul.com> Hello, Please approve backport of JDK-8073108 "Use x86 and SPARC CPU instructions for GHASH acceleration" to jdk8u. Bug: https://bugs.openjdk.java.net/browse/JDK-8073108 JDK9 review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-February/017178.html Changesets: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ce0c612ea443 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/1e10709d34af Webrevs: http://cr.openjdk.java.net/~ygaevsky/8073108.8u/webrev.hotspot/ http://cr.openjdk.java.net/~ygaevsky/8073108.8u/webrev.jdk/ The original changes for jdk9 do not apply cleanly to jdk8u codebase due to slightly different file layouts and absence of aarch64 platform. Testing: windows-i586: ( known failures due to https://bugs.openjdk.java.net/browse/JDK-8130341 (work in progress)) windows-x64: linux-x64: JTREG tests: (jdk8u) hotspot/test/compiler/7184394/ (jdk8u) jdk/test/com/sun/crypto/provider/Cipher/AES/ (also checked the output from TestAESMain for performance improvements w/ -XX:+UseGHASHIntrinsics) build for PowerPC: checked output for -XX:+UseGHASHIntrinsics ("GHASH intrinsics are not available on this CPU") build for Solaris-sparcv9: no JTREG tests were run because the available sparc machine doesn't support VIS3 instruction set, so just checked output for -XX:+UseGHASHIntrinsics ("GHASH intrinsics require VIS3 insructions support. Intriniscs will be disabled"). It would be great if someone could check the real intrinsic code on the appropriate solaris-sparc (SPARC T4?) hardware. Thank you, Yuri Gaevsky Azul Systems, Inc.