From shade at redhat.com Tue Oct 1 10:16:57 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 1 Oct 2019 12:16:57 +0200 Subject: [8u] RFR (XS) 8231398: Add time tracing for gc log rotation at safepoint cleanup In-Reply-To: References: Message-ID: <6528b956-d168-a8cf-de96-4bdf708e8632@redhat.com> Thanks Paul. I'll wait for 8u approval now. -Aleksey On 9/25/19 7:35 PM, Hohensee, Paul wrote: > 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 > > > -- Thanks, -Aleksey From sgehwolf at redhat.com Tue Oct 1 13:01:32 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 01 Oct 2019 15:01:32 +0200 Subject: [8u] RFR: 8195088: [TEST_BUG] StartManagementAgent got unexpected exception Message-ID: Hi, Please review this OpenJDK 8u vs. Oracle JDK 8 parity patch. I wasn't sure whether I need review for this one as the bug in question is a JDK 8-only bug and the patch applies as-is. Anyway, here it is: Bug: https://bugs.openjdk.java.net/browse/JDK-8195088 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8195088/01/webrev/ Testing: StartManagementAgent.java test fails prior and passes after this patch. Thoughts? Thanks, Severin From bourges.laurent at gmail.com Tue Oct 1 21:06:29 2019 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 1 Oct 2019 23:06:29 +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 all, FYI I started working on the Marlin renderer backport for JDK8u: - consolidate the azul zulu patch list with my own bug list (hg log + JBS) - retrieve all corresponding patches from jdk/client repository - I am reviewing patches (original vs azul) now I will try automating the integration locally (sed + hg import locally + build) to let me test the all process. Here is my patch list: ------------------------------------------------ | Marlin renderer patches history (jdk/client) | ------------------------------------------------ * 2015 34419:14108cfd0823 m01.8143849.patch 8143849: Integrate Marlin renderer per JEP 265 35979:4462913d471a NEW m01b.8149896.patch 8149896: Remove unnecessary values in FloatConsts and DoubleConsts => Merge with m01.8143849.patch 34689:4b5bf9f960c8 m02.8145055.patch 8145055: Marlin renderer causes unaligned write accesses 34801:a7740dae1f3a m03.8144630.patch 8144630: Use PrivilegedAction to create Thread in Marlin RendererStats 34814:09435f7f0013 m04.8144446.patch 8144446: Automate the Marlin crash test 34815:81e87daa9876 m05.8144445.patch 8144445: Maximum size checking in Marlin ArrayCache utility methods is not optimal 34422:438c2710ab20 m06.8144526.patch 8144526: Remove Marlin logging use of deleted internal API 34816:5ff696b1bbac m07.8144654.patch 8144654: Improve Marlin logging * 2016 35445:86db4c432b19 SKIP 8147443: Use the Common Cleaner in Marlin OffHeapArray 35645:a96d68e3fda2 m08.8144718.patch 8144718: Pisces / Marlin Strokers may generate invalid curves with huge coordinates and round joins 35665:e90002447fd5 SKIP 8146076: Fail of sun/java2d/marlin/CeilAndFloorTests.java with Jigsaw 36446:c06d6e681158 m09.8149338.patch 8149338: JVM Crash caused by Marlin renderer not handling NaN coordinates 36458:25786a73a5fc m10.8148886.patch 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering 36902:bb30d89aa00e m11.8144938.patch 8144938: Handle properly coordinate overflow in Marlin Renderer 39519:21bfc4452441 m12.8159093.patch 8159093: Fix coding conventions in Marlin renderer 40421:d5ee65e2b0fb m13.8159638.patch 8159638: Improve array caches and renderer stats in Marlin renderer * 2017 47126:188ef162f019 m14.8180055.patch 8180055: Upgrade the Marlin renderer in Java2D CHECK azul m20.8180055.patch 48258:fd7fbc929001 m15.8191814.patch 8191814: Marlin rasterizer spends time computing geometry for stroked segments that do not intersect the clip * 2018 49318:1ea202af7a97 m16.8198885.patch 8198885: upgrade Marlin (java2d) to 0.9.1 49524:a38e7ef21cc0 m17.8200526.patch 8200526: Test sun/java2d/marlin/ClipShapeTest.java times out 50019:793e481c7641 m18.8202580.patch 8202580: Dashed BasicStroke randomly painted incorrectly, may freeze application 51887:4ec74929fbfe m19.8210335.patch 8210335: Clipping problems with complex affine transforms: negative scaling factors or small scaling factors 2019: 55816:13178f7e75d5 NEW m20.8228711.patch 8228711: Path rendered incorrectly when it goes outside the clipping region 56131:7f55aad34ac4 NEW m21.8230728.patch 8230728: Thin stroked shapes are not rendered if affine transform has flip bit Laurent Le ven. 20 sept. 2019 ? 10:41, Andrew Brygin a ?crit : > 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 From sgehwolf at redhat.com Wed Oct 2 10:17:44 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 02 Oct 2019 12:17:44 +0200 Subject: [8u] RFR: 8134579: [TESTBUG] Some bmi tests fail if can_access_local_variables is on. Message-ID: Hi, Could I get a review of this OpenJDK 8u test-fix, please? We are seeing occasional test failures for LZcntTestI.java and/or LZcntTestL.java when running OpenJDK 8u tier1 tests. Backporting this change from JDK 9 fixes the issue. The JDK 9 patch didn't apply cleanly. Modifications I've done are: * Record AddnTest{I,L}.java => AndnTest{L,I}.java as a rename. * Manually removed AddnTest{I,L}.java tests as the removal rejected. This was done part of the rename (hg mv -A source dest) * Kept @library and @run definitions of AndnTest{I,L}.java as they were, modulo test name (last argument). Bug: https://bugs.openjdk.java.net/browse/JDK-8134579 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8134579/jdk8/01/webrev/ Testing: OpenJDK 8u tier1 tests on Linux x86_64 (release/fastdebug). Relevant test(s) fails prior, passes after. Thoughts? Thanks, Severin From ygaevsky at azul.com Wed Oct 2 13:37:51 2019 From: ygaevsky at azul.com (Yuri Gaevsky) Date: Wed, 2 Oct 2019 13:37:51 +0000 Subject: Request for approval: JDK-8073108 "Use x86 and SPARC CPU instructions for GHASH acceleration" Message-ID: (resending) 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: ( there are 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. From serguei.spitsyn at oracle.com Wed Oct 2 23:47:13 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 2 Oct 2019 16:47:13 -0700 Subject: [8u] RFR: 8195088: [TEST_BUG] StartManagementAgent got unexpected exception In-Reply-To: References: Message-ID: <85c52e84-e827-9af1-3cec-6dff26daeda0@oracle.com> Hi Severin, It looks good and applies cleanly. So, I'm not sure you really need a review for this. Thanks, Serguei On 10/1/19 06:01, Severin Gehwolf wrote: > Hi, > > Please review this OpenJDK 8u vs. Oracle JDK 8 parity patch. I wasn't > sure whether I need review for this one as the bug in question is a JDK > 8-only bug and the patch applies as-is. Anyway, here it is: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8195088 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8195088/01/webrev/ > > Testing: StartManagementAgent.java test fails prior and passes after > this patch. > > Thoughts? > > Thanks, > Severin > From rwestrel at redhat.com Thu Oct 3 08:52:29 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 03 Oct 2019 10:52:29 +0200 Subject: [8u] RFR: 8134579: [TESTBUG] Some bmi tests fail if can_access_local_variables is on. In-Reply-To: References: Message-ID: <87tv8q2otu.fsf@redhat.com> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8134579/jdk8/01/webrev/ Looks good to me. Roland. From sgehwolf at redhat.com Thu Oct 3 08:59:52 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 03 Oct 2019 10:59:52 +0200 Subject: [8u] RFR: 8134579: [TESTBUG] Some bmi tests fail if can_access_local_variables is on. In-Reply-To: <87tv8q2otu.fsf@redhat.com> References: <87tv8q2otu.fsf@redhat.com> Message-ID: On Thu, 2019-10-03 at 10:52 +0200, Roland Westrelin wrote: > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8134579/jdk8/01/webrev/ > > Looks good to me. Thanks for the review, Roland! Cheers, Severin From sgehwolf at redhat.com Thu Oct 3 15:02:28 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 03 Oct 2019 17:02:28 +0200 Subject: [8u] RFR: JDK-8227715: GPLv2 files missing Classpath Exception In-Reply-To: References: Message-ID: <1ba62e8c7f31c1c0efd7a09fe0a6beb24c63080c.camel@redhat.com> Hi Adam, This looks like an RFR for OpenJDK 8u. Adding the appropriate mailing list (jdk8u-dev not jdk-updates-dev; bcc'ed the latter) and fixing the subject line. Thanks, Severin On Thu, 2019-10-03 at 15:53 +0100, Adam Farley8 wrote: > Hey all, > > Four GPLv2 files in 8u seem to be missing the classpath exception from the > copyright section. > > Requesting reviews and a sponsor. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227715 > > Webrev: http://cr.openjdk.java.net/~afarley/8227715/webrev/ > > Best Regards > > Adam Farley > IBM Runtimes > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From neugens at redhat.com Fri Oct 4 10:30:49 2019 From: neugens at redhat.com (Mario Torre) Date: Fri, 4 Oct 2019 12:30:49 +0200 Subject: [8u] [JFR] RFR 8230947: TestLookForUntestedEvents.java is failing after JDK-8230707 In-Reply-To: References: Message-ID: On 13/09/2019 13:56, Jaroslav Bachor?k wrote: > 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/ Ok, Cheers, Mario -- 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 Sat Oct 5 02:26:56 2019 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Sat, 05 Oct 2019 10:26:56 +0800 Subject: =?UTF-8?B?UmU6IFs4dV0gUkZSIGJhY2twb3J0IG9mIEpESy04MTQ0NzMyOiBWTV9IZWFwRHVtcGVyIGhp?= =?UTF-8?B?dHMgYXNzZXJ0IHdpdGggYmFkIGR1bXBfbGVu?= In-Reply-To: <3311cb47-2b6d-4172-a579-d3bb4cf6de65.denghui.ddh@alibaba-inc.com> References: <78672c52-2587-4e01-98d9-350c9239fe48.denghui.ddh@alibaba-inc.com>, <3311cb47-2b6d-4172-a579-d3bb4cf6de65.denghui.ddh@alibaba-inc.com> Message-ID: Any comments ? Thanks, Denghui Dong ------------------------------------------------------------------ From:???(??) Send Time:2019?9?25?(???) 16:02 To:jdk8u-dev Subject:Re: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len 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 xxinliu at amazon.com Mon Oct 7 07:03:42 2019 From: xxinliu at amazon.com (Liu, Xin) Date: Mon, 7 Oct 2019 07:03:42 +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 and other reviewers, I used hg/mq to reformat those 7 patches. It's a very useful tool to manage commits in hg. I can jump back and modify what I comitted. $hg qapplied base updateAPIs classFileInstaller gclog nativeLibraries azul_contrib1 azul_contrib2 Could you review my changes? I didn't generate webrev because they are huge. https://cr.openjdk.java.net/~xliu/8231089/ @Konstantin, I move some changes to updateAPIs and gclog from your patches. It's you who identified and solved that problems. I just try to collect one kind of problem into one patch. It's easier for reviewers. I have some comments for your patches. 1) previously, you have deleted all @module. Eg. /* * @test - * @modules java.base/jdk.internal.misc:+open * @key stress gc * * @summary converted from VM Testbase gc/g1/unloading/tests/unloading_anonclassloader_inMemoryCompilation_keep_class. * VM Testbase keywords: [gc, stress, stressopt, nonconcurrent, javac] * - * @modules java.base/jdk.internal.misc * @library /vmTestbase * /testlibrary * /test/lib @@ -40,7 +38,6 @@ * @comment generate HumongousTemplateClass and compile it to test.classes * @run driver gc.g1.unloading.bytecode.GenClassesBuilder * - * @requires vm.gc.G1 I don't think it's mandatory. Jtreg automatically ignores unknown annotations like @module. if you don't modify it, your patch will be dramatically smaller. It's easy to review and reduce conflicts for future merges. I also added property vm.gc.G1, which returns true unconditionally. 2. has you solved this issue? https://gist.github.com/navyxliu/856ac2feab41591ec9220fb259d83072 I still can't pass some tests under vmTestbase/gc/g1/unloading. They all failed with the same error code. it looks that G1GC unloaded some classes. 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 kshefov at azul.com Mon Oct 7 10:10:54 2019 From: kshefov at azul.com (Konstantin Shefov) Date: Mon, 7 Oct 2019 10:10: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> <9967a21b81f740f68272d4dbbe3390b5@azul.com> Message-ID: Hi. Liu Xin Removing @modules is indeed not mandatory, it just strange to have this tag in JDK 8. As for G1 GC tests, G1 GC in JDK8 has not been in production state yet, so it is expected that some tests from JDK 14 are failing against JDK 8. We have 4 tests failing, but we have not looked deeply into them yet. Konstantin ?On 07/10/2019, 10:07, "Liu, Xin" wrote: Hi, Konstantin and other reviewers, I used hg/mq to reformat those 7 patches. It's a very useful tool to manage commits in hg. I can jump back and modify what I comitted. $hg qapplied base updateAPIs classFileInstaller gclog nativeLibraries azul_contrib1 azul_contrib2 Could you review my changes? I didn't generate webrev because they are huge. https://cr.openjdk.java.net/~xliu/8231089/ @Konstantin, I move some changes to updateAPIs and gclog from your patches. It's you who identified and solved that problems. I just try to collect one kind of problem into one patch. It's easier for reviewers. I have some comments for your patches. 1) previously, you have deleted all @module. Eg. /* * @test - * @modules java.base/jdk.internal.misc:+open * @key stress gc * * @summary converted from VM Testbase gc/g1/unloading/tests/unloading_anonclassloader_inMemoryCompilation_keep_class. * VM Testbase keywords: [gc, stress, stressopt, nonconcurrent, javac] * - * @modules java.base/jdk.internal.misc * @library /vmTestbase * /testlibrary * /test/lib @@ -40,7 +38,6 @@ * @comment generate HumongousTemplateClass and compile it to test.classes * @run driver gc.g1.unloading.bytecode.GenClassesBuilder * - * @requires vm.gc.G1 I don't think it's mandatory. Jtreg automatically ignores unknown annotations like @module. if you don't modify it, your patch will be dramatically smaller. It's easy to review and reduce conflicts for future merges. I also added property vm.gc.G1, which returns true unconditionally. 2. has you solved this issue? https://gist.github.com/navyxliu/856ac2feab41591ec9220fb259d83072 I still can't pass some tests under vmTestbase/gc/g1/unloading. They all failed with the same error code. it looks that G1GC unloaded some classes. 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 yan at azul.com Mon Oct 7 12:25:55 2019 From: yan at azul.com (Yuri Nesterenko) Date: Mon, 7 Oct 2019 15:25:55 +0300 Subject: RFR: JDK-8215210: [macos] Hangul text does not shape to the precomposed form on JDK8u Message-ID: <878c78ef-d14b-51f8-acff-d060143eef56@azul.com> Hi all, could you please review this downport of https://bugs.openjdk.java.net/browse/JDK-8215210 to openjdk 8u? Link to webrev: http://cr.openjdk.java.net/~yan/8215210/webrev.0/ There is a single digit change discovered by prr and a couple of regression tests: one verifies that required shaping works as expected and another -- that there's no obvious regression for JDK-8201801 Thank you! --yan From rkennke at redhat.com Mon Oct 7 18:25:34 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 7 Oct 2019 20:25:34 +0200 Subject: RFR: 8213325: (props) Properties.loadFromXML does not fully comply with the spec In-Reply-To: References: <1d0a8a5d-3467-99ed-3dff-187b70ea95fa@redhat.com> Message-ID: <465b5374-b539-164a-9fcb-7789c77212c5@redhat.com> I just realized that this has still not been reviewed. Can I do anything to move forward? Thanks, Roman > I added one extra verification to the JAXP based properties parser to > verify that no extra internal DTD is being supplied. As far as I can > tell, the other checks that have been added to the ukit parser for this > bug are already done by the JAXP parser, by validating the XML against > the built-in DTD. > > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8213325/webrev.01/ > > This passes all relevant tests, and I also run tier1 w/o regressions. > > What do you think? > > Roman > >> This is a backport of: >> >> https://bugs.openjdk.java.net/browse/JDK-8227274 >> >> which is a backport of the original: >> >> https://bugs.openjdk.java.net/browse/JDK-8213325 >> >> It's mostly the original change with a few significant extra modifications: >> >> - >> src/share/classes/sun/util/xml/META-INF/services/sun.util.spi.XmlPropertiesProvider >> >> is changed from: >> sun.util.xml.PlatformXmlPropertiesProvider >> >> to: >> jdk.internal.util.xml.BasicXmlPropertiesProvider >> >> The reason is that the fix is for the latter, but 8u uses the former by >> default. As far as I understand, the latter uses the new slimmer parser, >> while the former uses the fullblown XML parser, but I am not sure about >> that. However, we need to consider this, because it might be a very >> significant change. >> >> The alternative would be to port over the fixes to the other XML parser, >> which I have no desire to do. >> >> - The (test) JAR file: >> test/java/util/spi/ResourceBundleControlProvider/rbcontrolprovider.jar >> >> has been regenerated from the modified sources XmlRB.xml and XmlRB_ja.xml. >> >> This is not present in jdk11 and later. I think it's generated on the >> fly and not checked-in. >> >> Webrev: >> http://cr.openjdk.java.net/~rkennke/JDK-8213325/webrev.00/ >> >> Testing: New testcases are passing. No regressions in tier1 tests. >> >> Opinions? Can I get reviews? >> >> Thanks, >> Roman >> > From rkennke at redhat.com Mon Oct 7 18:30:00 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 7 Oct 2019 20:30:00 +0200 Subject: RFR: Backport: 8216549: Mismatched unsafe access to non escaping object fails In-Reply-To: <294433c3-a28e-7c49-24d0-40294e1d55be@redhat.com> References: <294433c3-a28e-7c49-24d0-40294e1d55be@redhat.com> Message-ID: <39c1529c-56c3-c553-8416-27d735afe615@redhat.com> Ping! This is still awaiting review. Thanks, Roman > This backports: > https://bugs.openjdk.java.net/browse/JDK-8216549 > > Original change: > hg.openjdk.java.net/jdk/jdk12/rev/f0490430ef7a > > JDK11u backport: > http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/d5fb6ad4203b > > In order to make it work on 8u, I needed the extra change in > library_call.cpp. Thanks Roland who helped with this. > > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8216549-8u/webrev.00/ > > Testing: > The new testcase fails without the fix, and passes with the fix. tier1 & > tier2 show no regressions. > > Can I please get a review? > > Thanks, > Roman > From ramz.mohan88 at gmail.com Mon Oct 7 18:45:53 2019 From: ramz.mohan88 at gmail.com (Rammohan Vanteru) Date: Mon, 7 Oct 2019 14:45:53 -0400 Subject: Openjdk info needed Message-ID: Hello team, One of my application running on jdk8. I see that below bug is fixed. How do i apply a patch on existing jdk8? Where do i find the patched version of jdk8 to fix the below bug in my environment? https://bugs.openjdk.java.net/browse/JDK-8225690 Thanks, Ramm. From shade at redhat.com Tue Oct 8 09:03:58 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 8 Oct 2019 11:03:58 +0200 Subject: JDK-8225690 (was: Re: Openjdk info needed) In-Reply-To: References: Message-ID: On 10/7/19 8:45 PM, Rammohan Vanteru wrote: > One of my application running on jdk8. > I see that below bug is fixed. How do i apply a patch on existing jdk8? Well, you can pick up the patch from the jdk/jdk repository: https://hg.openjdk.java.net/jdk/jdk/raw-rev/70fab3a8ff02 ...and apply it to jdk8u/jdk8u-dev/hotspot here: https://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/ The patch touches lots of environments, though, so testing would be tedious. It also has two simple follow-up bugfixes, those need to be looked at as well. You can work with JDK 8u Updates project to backport it yourself: https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix > Where do i find the patched version of jdk8 to fix the below bug in my > environment? If one existed in OpenJDK, then the issue would have the linked issue in "Backports" section. There are no such linked issues, which indicates no one had backported it (yet). -- Thanks, -Aleksey From neugens at redhat.com Tue Oct 8 10:14:21 2019 From: neugens at redhat.com (Mario Torre) Date: Tue, 8 Oct 2019 12:14: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: Hi Denghui, Ok to push to the incubator repository! Cheers, Mario On Fri, Sep 27, 2019 at 8:00 AM Denghui Dong wrote: > > 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 > > > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From kshefov at azul.com Tue Oct 8 10:42:41 2019 From: kshefov at azul.com (Konstantin Shefov) Date: Tue, 8 Oct 2019 10:42:41 +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> <9967a21b81f740f68272d4dbbe3390b5@azul.com> Message-ID: Hello In order to speed up vmTestbase's native part compilation we have to change target test-image in make/Main.gmk a bit: diff -r 31d7a6f35834 make/Main.gmk --- a/make/Main.gmk Thu Sep 26 16:41:02 2019 +0300 +++ b/make/Main.gmk Tue Oct 08 13:40:57 2019 +0300 @@ -168,10 +168,10 @@ @$(call TargetExit) test-image: start-make @$(call TargetEnter) - ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j1 MAKEFLAGS= SPEC=$(SPEC) \ + ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j$(JOBS) MAKEFLAGS= SPEC=$(SPEC) \ JT_HOME=$(JT_HOME) PRODUCT_HOME=$(JDK_IMAGE_DIR) ALT_OUTPUTDIR=$(OUTPUT_ROOT) CONCURRENCY=$(JOBS) \ -f JtregNativeHotspot.gmk build-test-hotspot-jtreg-native) - ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j1 MAKEFLAGS= SPEC=$(SPEC) \ + ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j$(JOBS) MAKEFLAGS= SPEC=$(SPEC) \ JT_HOME=$(JT_HOME) PRODUCT_HOME=$(JDK_IMAGE_DIR) ALT_OUTPUTDIR=$(OUTPUT_ROOT) CONCURRENCY=$(JOBS) \ -f JtregNativeHotspot.gmk test-image-hotspot-jtreg-native) @$(call TargetExit) Konstantin ?On 07/10/2019, 13:10, "Konstantin Shefov" wrote: Hi. Liu Xin Removing @modules is indeed not mandatory, it just strange to have this tag in JDK 8. As for G1 GC tests, G1 GC in JDK8 has not been in production state yet, so it is expected that some tests from JDK 14 are failing against JDK 8. We have 4 tests failing, but we have not looked deeply into them yet. Konstantin On 07/10/2019, 10:07, "Liu, Xin" wrote: Hi, Konstantin and other reviewers, I used hg/mq to reformat those 7 patches. It's a very useful tool to manage commits in hg. I can jump back and modify what I comitted. $hg qapplied base updateAPIs classFileInstaller gclog nativeLibraries azul_contrib1 azul_contrib2 Could you review my changes? I didn't generate webrev because they are huge. https://cr.openjdk.java.net/~xliu/8231089/ @Konstantin, I move some changes to updateAPIs and gclog from your patches. It's you who identified and solved that problems. I just try to collect one kind of problem into one patch. It's easier for reviewers. I have some comments for your patches. 1) previously, you have deleted all @module. Eg. /* * @test - * @modules java.base/jdk.internal.misc:+open * @key stress gc * * @summary converted from VM Testbase gc/g1/unloading/tests/unloading_anonclassloader_inMemoryCompilation_keep_class. * VM Testbase keywords: [gc, stress, stressopt, nonconcurrent, javac] * - * @modules java.base/jdk.internal.misc * @library /vmTestbase * /testlibrary * /test/lib @@ -40,7 +38,6 @@ * @comment generate HumongousTemplateClass and compile it to test.classes * @run driver gc.g1.unloading.bytecode.GenClassesBuilder * - * @requires vm.gc.G1 I don't think it's mandatory. Jtreg automatically ignores unknown annotations like @module. if you don't modify it, your patch will be dramatically smaller. It's easy to review and reduce conflicts for future merges. I also added property vm.gc.G1, which returns true unconditionally. 2. has you solved this issue? https://gist.github.com/navyxliu/856ac2feab41591ec9220fb259d83072 I still can't pass some tests under vmTestbase/gc/g1/unloading. They all failed with the same error code. it looks that G1GC unloaded some classes. 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 Tue Oct 8 17:46:39 2019 From: xxinliu at amazon.com (Liu, Xin) Date: Tue, 8 Oct 2019 17:46:39 +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> <9967a21b81f740f68272d4dbbe3390b5@azul.com> Message-ID: Hi, Konstantin, Yes, it makes sense. I prepare a webrev and include it your change. https://cr.openjdk.java.net/~xliu/8231089/root/webrev/ Can we at least push it first? Thanks, --lx ?On 10/8/19, 3:43 AM, "Konstantin Shefov" wrote: Hello In order to speed up vmTestbase's native part compilation we have to change target test-image in make/Main.gmk a bit: diff -r 31d7a6f35834 make/Main.gmk --- a/make/Main.gmk Thu Sep 26 16:41:02 2019 +0300 +++ b/make/Main.gmk Tue Oct 08 13:40:57 2019 +0300 @@ -168,10 +168,10 @@ @$(call TargetExit) test-image: start-make @$(call TargetEnter) - ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j1 MAKEFLAGS= SPEC=$(SPEC) \ + ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j$(JOBS) MAKEFLAGS= SPEC=$(SPEC) \ JT_HOME=$(JT_HOME) PRODUCT_HOME=$(JDK_IMAGE_DIR) ALT_OUTPUTDIR=$(OUTPUT_ROOT) CONCURRENCY=$(JOBS) \ -f JtregNativeHotspot.gmk build-test-hotspot-jtreg-native) - ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j1 MAKEFLAGS= SPEC=$(SPEC) \ + ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j$(JOBS) MAKEFLAGS= SPEC=$(SPEC) \ JT_HOME=$(JT_HOME) PRODUCT_HOME=$(JDK_IMAGE_DIR) ALT_OUTPUTDIR=$(OUTPUT_ROOT) CONCURRENCY=$(JOBS) \ -f JtregNativeHotspot.gmk test-image-hotspot-jtreg-native) @$(call TargetExit) Konstantin On 07/10/2019, 13:10, "Konstantin Shefov" wrote: Hi. Liu Xin Removing @modules is indeed not mandatory, it just strange to have this tag in JDK 8. As for G1 GC tests, G1 GC in JDK8 has not been in production state yet, so it is expected that some tests from JDK 14 are failing against JDK 8. We have 4 tests failing, but we have not looked deeply into them yet. Konstantin On 07/10/2019, 10:07, "Liu, Xin" wrote: Hi, Konstantin and other reviewers, I used hg/mq to reformat those 7 patches. It's a very useful tool to manage commits in hg. I can jump back and modify what I comitted. $hg qapplied base updateAPIs classFileInstaller gclog nativeLibraries azul_contrib1 azul_contrib2 Could you review my changes? I didn't generate webrev because they are huge. https://cr.openjdk.java.net/~xliu/8231089/ @Konstantin, I move some changes to updateAPIs and gclog from your patches. It's you who identified and solved that problems. I just try to collect one kind of problem into one patch. It's easier for reviewers. I have some comments for your patches. 1) previously, you have deleted all @module. Eg. /* * @test - * @modules java.base/jdk.internal.misc:+open * @key stress gc * * @summary converted from VM Testbase gc/g1/unloading/tests/unloading_anonclassloader_inMemoryCompilation_keep_class. * VM Testbase keywords: [gc, stress, stressopt, nonconcurrent, javac] * - * @modules java.base/jdk.internal.misc * @library /vmTestbase * /testlibrary * /test/lib @@ -40,7 +38,6 @@ * @comment generate HumongousTemplateClass and compile it to test.classes * @run driver gc.g1.unloading.bytecode.GenClassesBuilder * - * @requires vm.gc.G1 I don't think it's mandatory. Jtreg automatically ignores unknown annotations like @module. if you don't modify it, your patch will be dramatically smaller. It's easy to review and reduce conflicts for future merges. I also added property vm.gc.G1, which returns true unconditionally. 2. has you solved this issue? https://gist.github.com/navyxliu/856ac2feab41591ec9220fb259d83072 I still can't pass some tests under vmTestbase/gc/g1/unloading. They all failed with the same error code. it looks that G1GC unloaded some classes. 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 hohensee at amazon.com Tue Oct 8 21:31:07 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 8 Oct 2019 21:31:07 +0000 Subject: Backport: 8216549: Mismatched unsafe access to non escaping object fails Message-ID: <03C8C56B-A75C-40F2-8E9B-471414DDD5D9@amazon.com> The code in library_call.cpp comes seems to come from two patches https://bugs.openjdk.java.net/browse/JDK-8160360 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/4be0cada20ad and https://bugs.openjdk.java.net/browse/JDK-8162101 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/10dad1d40843 I'd backport those first. Paul ?On 10/7/19, 11:31 AM, "jdk8u-dev on behalf of Roman Kennke" wrote: Ping! This is still awaiting review. Thanks, Roman > This backports: > https://bugs.openjdk.java.net/browse/JDK-8216549 > > Original change: > hg.openjdk.java.net/jdk/jdk12/rev/f0490430ef7a > > JDK11u backport: > http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/d5fb6ad4203b > > In order to make it work on 8u, I needed the extra change in > library_call.cpp. Thanks Roland who helped with this. > > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8216549-8u/webrev.00/ > > Testing: > The new testcase fails without the fix, and passes with the fix. tier1 & > tier2 show no regressions. > > Can I please get a review? > > Thanks, > Roman > From hohensee at amazon.com Tue Oct 8 21:50:13 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 8 Oct 2019 21:50:13 +0000 Subject: JDK-8215210: [macos] Hangul text does not shape to the precomposed form on JDK8u In-Reply-To: <878c78ef-d14b-51f8-acff-d060143eef56@azul.com> References: <878c78ef-d14b-51f8-acff-d060143eef56@azul.com> Message-ID: <045CB7FE-AA43-4EF7-89B7-38C81EA1A837@amazon.com> This looks reasonable to me based on prr's description, but I've got almost no experience in this area. I'd cross-post to 2d-dev to see what they think. They might be interested in your regression tests. Paul ?On 10/7/19, 5:28 AM, "jdk8u-dev on behalf of Yuri Nesterenko" wrote: Hi all, could you please review this downport of https://bugs.openjdk.java.net/browse/JDK-8215210 to openjdk 8u? Link to webrev: http://cr.openjdk.java.net/~yan/8215210/webrev.0/ There is a single digit change discovered by prr and a couple of regression tests: one verifies that required shaping works as expected and another -- that there's no obvious regression for JDK-8201801 Thank you! --yan From rwestrel at redhat.com Wed Oct 9 07:59:58 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 09 Oct 2019 09:59:58 +0200 Subject: [8u] RFR: 8134739: compiler/loopopts/superword/TestVectorizationWithInvariant crashes in loop opts Message-ID: <87y2xuz6v5.fsf@redhat.com> Change does not apply cleanly to 8u but can be trivially adapted: http://cr.openjdk.java.net/~roland/8134739.8u/webrev.00/ Initial change: https://bugs.openjdk.java.net/browse/JDK-8134739 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6d9d273e7f0d Tested with tier1. Roland. From denghui.ddh at alibaba-inc.com Wed Oct 9 08:51:18 2019 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Wed, 09 Oct 2019 16:51:18 +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 all, Please review this backports (http://cr.openjdk.java.net/~ddong/19-10-9-jfr-backports/hotspot.00/) for: 8214542: JFR: Old Object Sample event slow on a deep heap in debug builds 8228834: Regression caused by JDK-8214542 not installing complete checkpoint data to candidates 8229437: assert(is_aligned(ref, HeapWordSize)) failed: invariant 8214542 is quite a large patch. Please help me to push it to jdk8u-jfr-incubator if you think it's ok. Cheers Denghui Dong ------------------------------------------------------------------ From:Mario Torre Send Time:2019?10?8?(???) 18:16 To:???(??) Cc:jdk8u-dev ; Andrey Petushkov Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 Hi Denghui, Ok to push to the incubator repository! Cheers, Mario On Fri, Sep 27, 2019 at 8:00 AM Denghui Dong wrote: > > 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 > > > -- 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 Wed Oct 9 09:10:26 2019 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Wed, 09 Oct 2019 17:10:26 +0800 Subject: =?UTF-8?B?UmU6IFs4dV0gUkZSIGJhY2twb3J0IG9mIEpESy04MTQ0NzMyOiBWTV9IZWFwRHVtcGVyIGhp?= =?UTF-8?B?dHMgYXNzZXJ0IHdpdGggYmFkIGR1bXBfbGVu?= In-Reply-To: References: Message-ID: Hi Team: The previous webrev didn't contain original commit information, so I made a new webrev in http://cr.openjdk.java.net/~ddong/8144732/hotspot.00/ Can you help to review it ? I think it is worth backporting. Thanks Denghui Dong ------------------------------------------------------------------ From:kelthuzadx <1948638989 at qq.com> Send Time:2019?10?7?(???) 10:28 To:???(??) Subject:Re: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len Good job? it ?s necessary to support large heap dump since 8u contains g1gc whose design principle is managing the large heap ------------------ Original ------------------ From: Denghui Dong Date: Sat,Oct 5,2019 10:27 AM To: jdk8u-dev Subject: Re: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len Any comments ? Thanks, Denghui Dong ------------------------------------------------------------------ From:???(??) Send Time:2019?9?25?(???) 16:02 To:jdk8u-dev Subject:Re: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len 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 rkennke at redhat.com Wed Oct 9 10:06:43 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 9 Oct 2019 12:06:43 +0200 Subject: Backport: 8216549: Mismatched unsafe access to non escaping object fails In-Reply-To: <03C8C56B-A75C-40F2-8E9B-471414DDD5D9@amazon.com> References: <03C8C56B-A75C-40F2-8E9B-471414DDD5D9@amazon.com> Message-ID: <5a5259ba-4754-ee16-3998-f98c7703fdea@redhat.com> Hi Paul, Thanks for checking it! > The code in library_call.cpp comes seems to come from two patches > > https://bugs.openjdk.java.net/browse/JDK-8160360 > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/4be0cada20ad I will look into backporting this change. > https://bugs.openjdk.java.net/browse/JDK-8162101 > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/10dad1d40843 This is already in jdk8u: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/7ca49bca3c2a Roman > I'd backport those first. > > Paul > > ?On 10/7/19, 11:31 AM, "jdk8u-dev on behalf of Roman Kennke" wrote: > > Ping! This is still awaiting review. > > Thanks, > Roman > > > > This backports: > > https://bugs.openjdk.java.net/browse/JDK-8216549 > > > > Original change: > > hg.openjdk.java.net/jdk/jdk12/rev/f0490430ef7a > > > > JDK11u backport: > > http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/d5fb6ad4203b > > > > In order to make it work on 8u, I needed the extra change in > > library_call.cpp. Thanks Roland who helped with this. > > > > Webrev: > > http://cr.openjdk.java.net/~rkennke/JDK-8216549-8u/webrev.00/ > > > > Testing: > > The new testcase fails without the fix, and passes with the fix. tier1 & > > tier2 show no regressions. > > > > Can I please get a review? > > > > Thanks, > > Roman > > > > > From hohensee at amazon.com Wed Oct 9 14:53:07 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 9 Oct 2019 14:53:07 +0000 Subject: Backport: 8216549: Mismatched unsafe access to non escaping object fails In-Reply-To: <5a5259ba-4754-ee16-3998-f98c7703fdea@redhat.com> References: <03C8C56B-A75C-40F2-8E9B-471414DDD5D9@amazon.com> <5a5259ba-4754-ee16-3998-f98c7703fdea@redhat.com> Message-ID: <573A0B31-A7A7-40A6-BE61-713A685F9939@amazon.com> Something of a nit: most of 8162101 is indeed in 8u :), but the change at line 1.42/1.43 - } else if (alias_type->adr_type() == TypeOopPtr::BOTTOM) { + } else if (alias_type->adr_type()->isa_oopptr()) { is missing because the test wasn't already there. Thanks, Paul ?On 10/9/19, 3:07 AM, "Roman Kennke" wrote: Hi Paul, Thanks for checking it! > The code in library_call.cpp comes seems to come from two patches > > https://bugs.openjdk.java.net/browse/JDK-8160360 > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/4be0cada20ad I will look into backporting this change. > https://bugs.openjdk.java.net/browse/JDK-8162101 > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/10dad1d40843 This is already in jdk8u: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/7ca49bca3c2a Roman > I'd backport those first. > > Paul > > ?On 10/7/19, 11:31 AM, "jdk8u-dev on behalf of Roman Kennke" wrote: > > Ping! This is still awaiting review. > > Thanks, > Roman > > > > This backports: > > https://bugs.openjdk.java.net/browse/JDK-8216549 > > > > Original change: > > hg.openjdk.java.net/jdk/jdk12/rev/f0490430ef7a > > > > JDK11u backport: > > http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/d5fb6ad4203b > > > > In order to make it work on 8u, I needed the extra change in > > library_call.cpp. Thanks Roland who helped with this. > > > > Webrev: > > http://cr.openjdk.java.net/~rkennke/JDK-8216549-8u/webrev.00/ > > > > Testing: > > The new testcase fails without the fix, and passes with the fix. tier1 & > > tier2 show no regressions. > > > > Can I please get a review? > > > > Thanks, > > Roman > > > > > From jaroslav.bachorik at datadoghq.com Wed Oct 9 15:23:58 2019 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Wed, 9 Oct 2019 17:23:58 +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: Hi Denghui, I went through the diff of diffs and as far as I can see the backport is correct. But I saw a bunch of comment lines with 'XX' in them. Could you clean up those comments before final merge? Regards, -JB- On Wed, Oct 9, 2019 at 10:57 AM Denghui Dong wrote: > Hi all, > Please review this backports ( > http://cr.openjdk.java.net/~ddong/19-10-9-jfr-backports/hotspot.00/) for: > 8214542: JFR: Old Object Sample event slow on a deep heap in debug > builds > 8228834: Regression caused by JDK-8214542 not installing complete > checkpoint data to candidates > 8229437: assert(is_aligned(ref, HeapWordSize)) failed: invariant > > 8214542 is quite a large patch. > Please help me to push it to jdk8u-jfr-incubator if you think it's ok. > > Cheers > Denghui Dong > ------------------------------------------------------------------ > From:Mario Torre > Send Time:2019?10?8?(???) 18:16 > To:???(??) > Cc:jdk8u-dev ; Andrey Petushkov < > andrey at azul.com> > Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 > > Hi Denghui, > > Ok to push to the incubator repository! > > Cheers, > Mario > > On Fri, Sep 27, 2019 at 8:00 AM Denghui Dong > wrote: > > > > 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 < > jdk8u-dev at openjdk.java.net>; 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 < > 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 > > > > > > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From neugens at redhat.com Wed Oct 9 17:00:20 2019 From: neugens at redhat.com (Mario Torre) Date: Wed, 9 Oct 2019 19:00:20 +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: This is because the API is slightly different, for instance Threads::oops_do in 8214542 has only two arguments, similarly DFSClosure extends ExtendedOopClosure rather than BasicOopIterateClosure, which was a refactoring that happened in 8204540 I think. We probably may want to remove those comments or make them more explicit if really necessary. Cheers, Mario On Wed, Oct 9, 2019 at 5:25 PM Jaroslav Bachor?k wrote: > > Hi Denghui, > > I went through the diff of diffs and as far as I can see the backport is > correct. But I saw a bunch of comment lines with 'XX' in them. Could you > clean up those comments before final merge? > > Regards, > > -JB- > > On Wed, Oct 9, 2019 at 10:57 AM Denghui Dong > wrote: > > > Hi all, > > Please review this backports ( > > http://cr.openjdk.java.net/~ddong/19-10-9-jfr-backports/hotspot.00/) for: > > 8214542: JFR: Old Object Sample event slow on a deep heap in debug > > builds > > 8228834: Regression caused by JDK-8214542 not installing complete > > checkpoint data to candidates > > 8229437: assert(is_aligned(ref, HeapWordSize)) failed: invariant > > > > 8214542 is quite a large patch. > > Please help me to push it to jdk8u-jfr-incubator if you think it's ok. > > > > Cheers > > Denghui Dong > > ------------------------------------------------------------------ > > From:Mario Torre > > Send Time:2019?10?8?(???) 18:16 > > To:???(??) > > Cc:jdk8u-dev ; Andrey Petushkov < > > andrey at azul.com> > > Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 > > > > Hi Denghui, > > > > Ok to push to the incubator repository! > > > > Cheers, > > Mario > > > > On Fri, Sep 27, 2019 at 8:00 AM Denghui Dong > > wrote: > > > > > > 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 < > > jdk8u-dev at openjdk.java.net>; 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 < > > 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 > > > > > > > > > > > > > -- > > 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 Wed Oct 9 17:14:41 2019 From: andrey at azul.com (Andrey Petushkov) Date: Wed, 9 Oct 2019 17:14:41 +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> <961B2FE0-A663-4912-9E78-434F1D03B5F8@azul.com> Message-ID: Hi Denghui, All, The patch looks good for me as well. Regarding those XXX, in fact none of them were introduced by Denghui. Instead they are coming from current incubator code and in fact it's deed of mine, sorry for that. They indicate a few places where I was a tiny bit hesitant making changes to original (jdk11) JFR implementation. As such it would be nice if someone could review them for correctness before removal Thanks, Andrey > On 9 Oct 2019, at 18:23, Jaroslav Bachor?k wrote: > > Hi Denghui, > > I went through the diff of diffs and as far as I can see the backport is > correct. But I saw a bunch of comment lines with 'XX' in them. Could you > clean up those comments before final merge? > > Regards, > > -JB- > > On Wed, Oct 9, 2019 at 10:57 AM Denghui Dong > wrote: > >> Hi all, >> Please review this backports ( >> http://cr.openjdk.java.net/~ddong/19-10-9-jfr-backports/hotspot.00/) for: >> 8214542: JFR: Old Object Sample event slow on a deep heap in debug >> builds >> 8228834: Regression caused by JDK-8214542 not installing complete >> checkpoint data to candidates >> 8229437: assert(is_aligned(ref, HeapWordSize)) failed: invariant >> >> 8214542 is quite a large patch. >> Please help me to push it to jdk8u-jfr-incubator if you think it's ok. >> >> Cheers >> Denghui Dong >> ------------------------------------------------------------------ >> From:Mario Torre >> Send Time:2019?10?8?(???) 18:16 >> To:???(??) >> Cc:jdk8u-dev ; Andrey Petushkov < >> andrey at azul.com> >> Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 >> >> Hi Denghui, >> >> Ok to push to the incubator repository! >> >> Cheers, >> Mario >> >> On Fri, Sep 27, 2019 at 8:00 AM Denghui Dong >> wrote: >>> >>> 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 < >> jdk8u-dev at openjdk.java.net>; 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 < >> 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 >>>> >>> >> >> >> -- >> 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 Thu Oct 10 05:50:56 2019 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Thu, 10 Oct 2019 13:50:56 +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, Those comments were not introduced by this patch, but the original jfr patch just as Andrey said. It's necessary to confirm those comments are correct, I think we can do this task later and create a new jira issue to track it. What's your comments ? Cheers Denghui Dong ------------------------------------------------------------------ From:Andrey Petushkov Send Time:2019?10?10?(???) 01:14 To:"Jaroslav Bachor?k" ; ???(??) ; jdk8u-dev Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 Hi Denghui, All, The patch looks good for me as well. Regarding those XXX, in fact none of them were introduced by Denghui. Instead they are coming from current incubator code and in fact it's deed of mine, sorry for that. They indicate a few places where I was a tiny bit hesitant making changes to original (jdk11) JFR implementation. As such it would be nice if someone could review them for correctness before removal Thanks, Andrey > On 9 Oct 2019, at 18:23, Jaroslav Bachor?k wrote: > > Hi Denghui, > > I went through the diff of diffs and as far as I can see the backport is > correct. But I saw a bunch of comment lines with 'XX' in them. Could you > clean up those comments before final merge? > > Regards, > > -JB- > > On Wed, Oct 9, 2019 at 10:57 AM Denghui Dong > wrote: > >> Hi all, >> Please review this backports ( >> http://cr.openjdk.java.net/~ddong/19-10-9-jfr-backports/hotspot.00/) for: >> 8214542: JFR: Old Object Sample event slow on a deep heap in debug >> builds >> 8228834: Regression caused by JDK-8214542 not installing complete >> checkpoint data to candidates >> 8229437: assert(is_aligned(ref, HeapWordSize)) failed: invariant >> >> 8214542 is quite a large patch. >> Please help me to push it to jdk8u-jfr-incubator if you think it's ok. >> >> Cheers >> Denghui Dong >> ------------------------------------------------------------------ >> From:Mario Torre >> Send Time:2019?10?8?(???) 18:16 >> To:???(??) >> Cc:jdk8u-dev ; Andrey Petushkov < >> andrey at azul.com> >> Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 >> >> Hi Denghui, >> >> Ok to push to the incubator repository! >> >> Cheers, >> Mario >> >> On Fri, Sep 27, 2019 at 8:00 AM Denghui Dong >> wrote: >>> >>> 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 < >> jdk8u-dev at openjdk.java.net>; 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 < >> 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 >>>> >>> >> >> >> -- >> Mario Torre >> Associate Manager, Software Engineering >> Red Hat GmbH >> 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From ygaevsky at azul.com Thu Oct 10 09:51:36 2019 From: ygaevsky at azul.com (Yuri Gaevsky) Date: Thu, 10 Oct 2019 09:51:36 +0000 Subject: Request for approval: JDK-8130341 "GHASH 32bit intrinsics has AEADBadTagException" Message-ID: <990e8a14c8f6442bb4225d3b9b0f1eec@azul.com> Hello, Please approve backport of JDK-8130341 "GHASH 32bit intrinsics has AEADBadTagException" to jdk8u which is a required follow-up fix for the issue mentioned in [1]. Bug: https://bugs.openjdk.java.net/browse/JDK-8130341 JDK9 review thread: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-July/018402.html JDK9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/36fd5d1982b0 Webrev: http://cr.openjdk.java.net/~ygaevsky/8130341.8u/webrev.hotspot/ NB: The original change for JDK9 does apply cleanly to jdk8u codebase w/ minor correction to the test path (test/compiler/codegen/7184394/ --> test/compiler/7184394/). Testing: windows-i586: (known failures mentioned in [1] are gone) windows-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) Thank you, -Yuri Gaevsky, Azul Systems, Inc. [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-October/010409.html From rkennke at redhat.com Thu Oct 10 10:18:37 2019 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 10 Oct 2019 12:18:37 +0200 Subject: Backport: 8216549: Mismatched unsafe access to non escaping object fails In-Reply-To: <573A0B31-A7A7-40A6-BE61-713A685F9939@amazon.com> References: <03C8C56B-A75C-40F2-8E9B-471414DDD5D9@amazon.com> <5a5259ba-4754-ee16-3998-f98c7703fdea@redhat.com> <573A0B31-A7A7-40A6-BE61-713A685F9939@amazon.com> Message-ID: Hi Paul, > Something of a nit: most of 8162101 is indeed in 8u :), but the change at line 1.42/1.43 > > - } else if (alias_type->adr_type() == TypeOopPtr::BOTTOM) { > + } else if (alias_type->adr_type()->isa_oopptr()) { > > is missing because the test wasn't already there. Right. I tried backporting JDK-8160360, but the problem there is similar: in order to be a clean-ish backport, it requires a couple of other changes first. That's a rat's tail of (unrelated/unimportant) stuff to backport just for those two lines. Instead, I'd rather opt to include the above 2 lines (which are essentially completing the JDK-8162101 backport) instead. Roman > Thanks, > > Paul > > ?On 10/9/19, 3:07 AM, "Roman Kennke" wrote: > > Hi Paul, > > Thanks for checking it! > > > The code in library_call.cpp comes seems to come from two patches > > > > https://bugs.openjdk.java.net/browse/JDK-8160360 > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/4be0cada20ad > > I will look into backporting this change. > > > https://bugs.openjdk.java.net/browse/JDK-8162101 > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/10dad1d40843 > > This is already in jdk8u: > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/7ca49bca3c2a > > Roman > > > > > I'd backport those first. > > > > Paul > > > > ?On 10/7/19, 11:31 AM, "jdk8u-dev on behalf of Roman Kennke" wrote: > > > > Ping! This is still awaiting review. > > > > Thanks, > > Roman > > > > > > > This backports: > > > https://bugs.openjdk.java.net/browse/JDK-8216549 > > > > > > Original change: > > > hg.openjdk.java.net/jdk/jdk12/rev/f0490430ef7a > > > > > > JDK11u backport: > > > http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/d5fb6ad4203b > > > > > > In order to make it work on 8u, I needed the extra change in > > > library_call.cpp. Thanks Roland who helped with this. > > > > > > Webrev: > > > http://cr.openjdk.java.net/~rkennke/JDK-8216549-8u/webrev.00/ > > > > > > Testing: > > > The new testcase fails without the fix, and passes with the fix. tier1 & > > > tier2 show no regressions. > > > > > > Can I please get a review? > > > > > > Thanks, > > > Roman > > > > > > > > > > > > From neugens at redhat.com Thu Oct 10 11:30:56 2019 From: neugens at redhat.com (Mario Torre) Date: Thu, 10 Oct 2019 13:30:56 +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: Right, makes sense. Ok to push. Cheers, Mario On Thu, Oct 10, 2019 at 7:51 AM Denghui Dong wrote: > > Hi, > Those comments were not introduced by this patch, but the original jfr patch just as Andrey said. > It's necessary to confirm those comments are correct, I think we can do this task later and create a new jira issue to track it. > What's your comments ? > > Cheers > Denghui Dong > > ------------------------------------------------------------------ > From:Andrey Petushkov > Send Time:2019?10?10?(???) 01:14 > To:"Jaroslav Bachor?k" ; ???(??) ; jdk8u-dev > Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 > > Hi Denghui, All, > > The patch looks good for me as well. > Regarding those XXX, in fact none of them were introduced by Denghui. Instead they are coming from current > incubator code and in fact it's deed of mine, sorry for that. They indicate a few places where I was a tiny bit > hesitant making changes to original (jdk11) JFR implementation. As such it would be nice if someone could review > them for correctness before removal > > Thanks, > Andrey > > > On 9 Oct 2019, at 18:23, Jaroslav Bachor?k wrote: > > > > Hi Denghui, > > > > I went through the diff of diffs and as far as I can see the backport is > > correct. But I saw a bunch of comment lines with 'XX' in them. Could you > > clean up those comments before final merge? > > > > Regards, > > > > -JB- > > > > On Wed, Oct 9, 2019 at 10:57 AM Denghui Dong > > wrote: > > > >> Hi all, > >> Please review this backports ( > >> http://cr.openjdk.java.net/~ddong/19-10-9-jfr-backports/hotspot.00/) for: > >> 8214542: JFR: Old Object Sample event slow on a deep heap in debug > >> builds > >> 8228834: Regression caused by JDK-8214542 not installing complete > >> checkpoint data to candidates > >> 8229437: assert(is_aligned(ref, HeapWordSize)) failed: invariant > >> > >> 8214542 is quite a large patch. > >> Please help me to push it to jdk8u-jfr-incubator if you think it's ok. > >> > >> Cheers > >> Denghui Dong > >> ------------------------------------------------------------------ > >> From:Mario Torre > >> Send Time:2019?10?8?(???) 18:16 > >> To:???(??) > >> Cc:jdk8u-dev ; Andrey Petushkov < > >> andrey at azul.com> > >> Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 > >> > >> Hi Denghui, > >> > >> Ok to push to the incubator repository! > >> > >> Cheers, > >> Mario > >> > >> On Fri, Sep 27, 2019 at 8:00 AM Denghui Dong > >> wrote: > >>> > >>> 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 < > >> jdk8u-dev at openjdk.java.net>; 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 < > >> 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 > >>>> > >>> > >> > >> > >> -- > >> 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 hohensee at amazon.com Thu Oct 10 15:53:11 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 10 Oct 2019 15:53:11 +0000 Subject: Backport: 8216549: Mismatched unsafe access to non escaping object fails In-Reply-To: References: <03C8C56B-A75C-40F2-8E9B-471414DDD5D9@amazon.com> <5a5259ba-4754-ee16-3998-f98c7703fdea@redhat.com> <573A0B31-A7A7-40A6-BE61-713A685F9939@amazon.com> Message-ID: <592D8576-CABA-4F05-825C-9C7CFCB69C6F@amazon.com> We're starting to have a general problem, which is that as the tip code base diverges from the update code base, we're getting more backports that depend on other backports. At some point not doing those other backports is going to cause reliability problems. In this particular case it's pretty obvious we're ok, because as you say, the extra 2 lines are just completing the 8162101 backport. Having to leave out code in a backport such as 8162101 is a sign of a problem: it should have been addressed then. Anyway, this patch is good to go afaic. Thanks, Paul ?On 10/10/19, 3:19 AM, "Roman Kennke" wrote: Hi Paul, > Something of a nit: most of 8162101 is indeed in 8u :), but the change at line 1.42/1.43 > > - } else if (alias_type->adr_type() == TypeOopPtr::BOTTOM) { > + } else if (alias_type->adr_type()->isa_oopptr()) { > > is missing because the test wasn't already there. Right. I tried backporting JDK-8160360, but the problem there is similar: in order to be a clean-ish backport, it requires a couple of other changes first. That's a rat's tail of (unrelated/unimportant) stuff to backport just for those two lines. Instead, I'd rather opt to include the above 2 lines (which are essentially completing the JDK-8162101 backport) instead. Roman > Thanks, > > Paul > > ?On 10/9/19, 3:07 AM, "Roman Kennke" wrote: > > Hi Paul, > > Thanks for checking it! > > > The code in library_call.cpp comes seems to come from two patches > > > > https://bugs.openjdk.java.net/browse/JDK-8160360 > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/4be0cada20ad > > I will look into backporting this change. > > > https://bugs.openjdk.java.net/browse/JDK-8162101 > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/10dad1d40843 > > This is already in jdk8u: > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/7ca49bca3c2a > > Roman > > > > > I'd backport those first. > > > > Paul > > > > ?On 10/7/19, 11:31 AM, "jdk8u-dev on behalf of Roman Kennke" wrote: > > > > Ping! This is still awaiting review. > > > > Thanks, > > Roman > > > > > > > This backports: > > > https://bugs.openjdk.java.net/browse/JDK-8216549 > > > > > > Original change: > > > hg.openjdk.java.net/jdk/jdk12/rev/f0490430ef7a > > > > > > JDK11u backport: > > > http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/d5fb6ad4203b > > > > > > In order to make it work on 8u, I needed the extra change in > > > library_call.cpp. Thanks Roland who helped with this. > > > > > > Webrev: > > > http://cr.openjdk.java.net/~rkennke/JDK-8216549-8u/webrev.00/ > > > > > > Testing: > > > The new testcase fails without the fix, and passes with the fix. tier1 & > > > tier2 show no regressions. > > > > > > Can I please get a review? > > > > > > Thanks, > > > Roman > > > > > > > > > > > > From neugens at redhat.com Fri Oct 11 14:47:25 2019 From: neugens at redhat.com (Mario Torre) Date: Fri, 11 Oct 2019 16:47:25 +0200 Subject: [8u] PING: RFR: 8213734: SAXParser.parse(File, ..) does not close resources when Exception occurs. In-Reply-To: <3adc99dd5410882edcf129859ddfb7b0648c941d.camel@redhat.com> References: <0a64931ab640afd557f4bd46aa7bb05512bc79d6.camel@redhat.com> <3adc99dd5410882edcf129859ddfb7b0648c941d.camel@redhat.com> Message-ID: Hi Severin, The patch looks good to me. Cheers, Mario On Fri, Sep 27, 2019 at 10:38 AM Severin Gehwolf wrote: > > 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 > -- 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 Oct 11 14:54:57 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 11 Oct 2019 16:54:57 +0200 Subject: [8u] PING: RFR: 8213734: SAXParser.parse(File, ..) does not close resources when Exception occurs. In-Reply-To: References: <0a64931ab640afd557f4bd46aa7bb05512bc79d6.camel@redhat.com> <3adc99dd5410882edcf129859ddfb7b0648c941d.camel@redhat.com> Message-ID: <71d543639ca7396711a8c04e78aa10ce5823c43f.camel@redhat.com> On Fri, 2019-10-11 at 16:47 +0200, Mario Torre wrote: > Hi Severin, > > The patch looks good to me. Thanks for the review, Mario! Cheers, Severin > On Fri, Sep 27, 2019 at 10:38 AM Severin Gehwolf wrote: > > 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 bourges.laurent at gmail.com Fri Oct 11 22:09:53 2019 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Sat, 12 Oct 2019 00:09:53 +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, Here are some news: I created a small repository to store zulu patches from Andrew Brygin, original jdk/jdk extracted patches and their corresponding jdk8 patches (unshuffled): https://github.com/bourgesl/marlin-jdk8u I am still reviewing patches m01 to m11 are OK = zulu patches are OK by me. See https://github.com/bourgesl/marlin-jdk8u/blob/master/marlin-review.txt I will go on and officially share all this work once done. PS: I applied locally zulu8 patches on my local jdk8u/jdk repository and it works well: Marlin 0.9.1.1 in action ! Cheers, Laurent Le mar. 1 oct. 2019 ? 23:06, Laurent Bourg?s a ?crit : > Hi all, > > FYI I started working on the Marlin renderer backport for JDK8u: > - consolidate the azul zulu patch list with my own bug list (hg log + JBS) > - retrieve all corresponding patches from jdk/client repository > - I am reviewing patches (original vs azul) now > > I will try automating the integration locally (sed + hg import locally + > build) to let me test the all process. > > Here is my patch list: > ------------------------------------------------ > | Marlin renderer patches history (jdk/client) | > ------------------------------------------------ > > * 2015 > 34419:14108cfd0823 m01.8143849.patch 8143849: Integrate Marlin renderer > per JEP 265 > 35979:4462913d471a NEW m01b.8149896.patch 8149896: Remove unnecessary > values in FloatConsts and DoubleConsts => Merge with m01.8143849.patch > > 34689:4b5bf9f960c8 m02.8145055.patch 8145055: Marlin renderer causes > unaligned write accesses > 34801:a7740dae1f3a m03.8144630.patch 8144630: Use PrivilegedAction to > create Thread in Marlin RendererStats > 34814:09435f7f0013 m04.8144446.patch 8144446: Automate the Marlin crash > test > 34815:81e87daa9876 m05.8144445.patch 8144445: Maximum size checking in > Marlin ArrayCache utility methods is not optimal > 34422:438c2710ab20 m06.8144526.patch 8144526: Remove Marlin logging use of > deleted internal API > 34816:5ff696b1bbac m07.8144654.patch 8144654: Improve Marlin logging > > * 2016 > 35445:86db4c432b19 SKIP 8147443: Use the Common Cleaner in Marlin > OffHeapArray > 35645:a96d68e3fda2 m08.8144718.patch 8144718: Pisces / Marlin Strokers may > generate invalid curves with huge coordinates and round joins > 35665:e90002447fd5 SKIP 8146076: Fail of > sun/java2d/marlin/CeilAndFloorTests.java with Jigsaw > 36446:c06d6e681158 m09.8149338.patch 8149338: JVM Crash caused by Marlin > renderer not handling NaN coordinates > 36458:25786a73a5fc m10.8148886.patch 8148886: SEGV in > sun.java2d.marlin.Renderer._endRendering > 36902:bb30d89aa00e m11.8144938.patch 8144938: Handle properly coordinate > overflow in Marlin Renderer > 39519:21bfc4452441 m12.8159093.patch 8159093: Fix coding conventions in > Marlin renderer > 40421:d5ee65e2b0fb m13.8159638.patch 8159638: Improve array caches and > renderer stats in Marlin renderer > > * 2017 > 47126:188ef162f019 m14.8180055.patch 8180055: Upgrade the Marlin renderer > in Java2D > CHECK azul m20.8180055.patch > 48258:fd7fbc929001 m15.8191814.patch 8191814: Marlin rasterizer spends > time computing geometry for stroked segments that do not intersect the clip > > * 2018 > 49318:1ea202af7a97 m16.8198885.patch 8198885: upgrade Marlin (java2d) to > 0.9.1 > 49524:a38e7ef21cc0 m17.8200526.patch 8200526: Test > sun/java2d/marlin/ClipShapeTest.java times out > 50019:793e481c7641 m18.8202580.patch 8202580: Dashed BasicStroke randomly > painted incorrectly, may freeze application > 51887:4ec74929fbfe m19.8210335.patch 8210335: Clipping problems with > complex affine transforms: negative scaling factors or small scaling factors > > 2019: > 55816:13178f7e75d5 NEW m20.8228711.patch 8228711: Path rendered > incorrectly when it goes outside the clipping region > 56131:7f55aad34ac4 NEW m21.8230728.patch 8230728: Thin stroked shapes are > not rendered if affine transform has flip bit > > Laurent > > Le ven. 20 sept. 2019 ? 10:41, Andrew Brygin a ?crit : > >> Hi Laurent, >> >> > On Sep 19, 2019, at 11:09 PM, Laurent Bourg?s < >> bourges.laurent at gmail.com> 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 > > From xxinliu at amazon.com Mon Oct 14 18:54:45 2019 From: xxinliu at amazon.com (Liu, Xin) Date: Mon, 14 Oct 2019 18:54:45 +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> <9967a21b81f740f68272d4dbbe3390b5@azul.com> Message-ID: <8CF2F830-82A3-4D17-96F2-B1910A0588F1@amazon.com> Hello, Reviewers, May I have attention for thread? I have separated the jumbo vmTestbase to 1+7 patches. This patch is the entrypoint in root project. https://cr.openjdk.java.net/~xliu/8231089/root/webrev/ This patch is just vmTestbase blob from jdk14+14. https://cr.openjdk.java.net/~xliu/8231089/base.patch.tar.gz If reviewers allow me to push this two patches, we can review other changes and let remaining patches trickle in. Thanks, --lx ?On 10/8/19, 10:49 AM, "jdk8u-dev on behalf of Liu, Xin" wrote: Hi, Konstantin, Yes, it makes sense. I prepare a webrev and include it your change. https://cr.openjdk.java.net/~xliu/8231089/root/webrev/ Can we at least push it first? Thanks, --lx On 10/8/19, 3:43 AM, "Konstantin Shefov" wrote: Hello In order to speed up vmTestbase's native part compilation we have to change target test-image in make/Main.gmk a bit: diff -r 31d7a6f35834 make/Main.gmk --- a/make/Main.gmk Thu Sep 26 16:41:02 2019 +0300 +++ b/make/Main.gmk Tue Oct 08 13:40:57 2019 +0300 @@ -168,10 +168,10 @@ @$(call TargetExit) test-image: start-make @$(call TargetEnter) - ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j1 MAKEFLAGS= SPEC=$(SPEC) \ + ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j$(JOBS) MAKEFLAGS= SPEC=$(SPEC) \ JT_HOME=$(JT_HOME) PRODUCT_HOME=$(JDK_IMAGE_DIR) ALT_OUTPUTDIR=$(OUTPUT_ROOT) CONCURRENCY=$(JOBS) \ -f JtregNativeHotspot.gmk build-test-hotspot-jtreg-native) - ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j1 MAKEFLAGS= SPEC=$(SPEC) \ + ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j$(JOBS) MAKEFLAGS= SPEC=$(SPEC) \ JT_HOME=$(JT_HOME) PRODUCT_HOME=$(JDK_IMAGE_DIR) ALT_OUTPUTDIR=$(OUTPUT_ROOT) CONCURRENCY=$(JOBS) \ -f JtregNativeHotspot.gmk test-image-hotspot-jtreg-native) @$(call TargetExit) Konstantin On 07/10/2019, 13:10, "Konstantin Shefov" wrote: Hi. Liu Xin Removing @modules is indeed not mandatory, it just strange to have this tag in JDK 8. As for G1 GC tests, G1 GC in JDK8 has not been in production state yet, so it is expected that some tests from JDK 14 are failing against JDK 8. We have 4 tests failing, but we have not looked deeply into them yet. Konstantin On 07/10/2019, 10:07, "Liu, Xin" wrote: Hi, Konstantin and other reviewers, I used hg/mq to reformat those 7 patches. It's a very useful tool to manage commits in hg. I can jump back and modify what I comitted. $hg qapplied base updateAPIs classFileInstaller gclog nativeLibraries azul_contrib1 azul_contrib2 Could you review my changes? I didn't generate webrev because they are huge. https://cr.openjdk.java.net/~xliu/8231089/ @Konstantin, I move some changes to updateAPIs and gclog from your patches. It's you who identified and solved that problems. I just try to collect one kind of problem into one patch. It's easier for reviewers. I have some comments for your patches. 1) previously, you have deleted all @module. Eg. /* * @test - * @modules java.base/jdk.internal.misc:+open * @key stress gc * * @summary converted from VM Testbase gc/g1/unloading/tests/unloading_anonclassloader_inMemoryCompilation_keep_class. * VM Testbase keywords: [gc, stress, stressopt, nonconcurrent, javac] * - * @modules java.base/jdk.internal.misc * @library /vmTestbase * /testlibrary * /test/lib @@ -40,7 +38,6 @@ * @comment generate HumongousTemplateClass and compile it to test.classes * @run driver gc.g1.unloading.bytecode.GenClassesBuilder * - * @requires vm.gc.G1 I don't think it's mandatory. Jtreg automatically ignores unknown annotations like @module. if you don't modify it, your patch will be dramatically smaller. It's easy to review and reduce conflicts for future merges. I also added property vm.gc.G1, which returns true unconditionally. 2. has you solved this issue? https://gist.github.com/navyxliu/856ac2feab41591ec9220fb259d83072 I still can't pass some tests under vmTestbase/gc/g1/unloading. They all failed with the same error code. it looks that G1GC unloaded some classes. 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 sgehwolf at redhat.com Tue Oct 15 12:27:06 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 15 Oct 2019 14:27:06 +0200 Subject: [8u232-b08] New test failures due to tzdata-updates Message-ID: Hi, The latest EA tags of the jdk8u/jdk8u tree (jdk8u232-b08) have new test failures in. jdk8u232-b07 was OK: sun/util/calendar/zi/TestZoneInfo310.java The failure looks like this: Compiling tz files! testing! OLD.getZoneInfoOld()[1]=648 OLD.getZoneInfoOld()[2]=194 OLD.getZoneInfoOld()[3]=169 OLD.getAvailableIDs()=746, total=628 OLD.getAliasTable()=493, total=228 OLD.TotalTZ()=80 (ms) NEW.getTimeZone()[1]=70 NEW.getTimeZone()[2]=16 NEW.getTimeZone()[3]=9 NEW.getAvailableIDs()=18, total=628 NEW.getAliasTable()=74, total=228 NEW.TotalTZ()=1 (ms) ****************************** America/Campo_Grande : America/Campo_Grande offset=-14400000,dstSavings=0,useDaylight=false,transitions=93,offsets=4,checksum=-718118701,gmtChanged=false [NG]offset=-14400000,dstSavings=3600000,useDaylight=false,transitions=129,offsets=4,checksum=374743623,gmtChanged=false ------------- (NG) Different trans size :93, 129 1900-01-01T00:00 [utc=-2208988800 raw=fffffdfdae01dc00, offset=-13108/-03:38:28, saving=0] (OK) 1900-01-01T00:00 [utc=-2208988800 raw=fffffdfdae01dc00, offset=-13108/-03:38:28, saving=0] ----- Failures are also observed at AdoptOpenJDK: https://ci.adoptopenjdk.net/view/Test_upstream/job/Test_openjdk8_hs_sanity.openjdk_x86-64_windows_upstream/19/ These failures are due to these two changesets: http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/d355fd566378 http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/8560bc534080 Both of them would need to update tzdata copies in the test subtree for the tests to pass again. The addendum for JDK-8228469 (rev d355fd566378) would be this: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8228469-8u-fixup/01/webrev/ The addendum for JDK-8231098 (rev 8560bc534080) would be this: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231098-8u-fixup/02/webrev/ The current code in jdk8u232-b08 compares tzdata2019a (test code) with tzdata2019c (jdk code). Thus the test failure(s). Shall I create 8u-only bugs for them or is there another, preferred, solution to this? Thanks, Severin From hohensee at amazon.com Tue Oct 15 16:34:47 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 15 Oct 2019 16:34:47 +0000 Subject: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len In-Reply-To: References: Message-ID: <1F597219-BD21-4ABD-806F-AF7B8B2F2638@amazon.com> The JBS issue and changeset links you posted are for 8150432, not 8144732, which was confusing. The webrev is for 8144732 though. I can find only two places where your patch is different from the original changeset, net of line numbers/file locations. The rest looks fine. They are: In heapDumper.cpp, there should be only one blank line after the definition of WRITE_ARRAY. In arguments.cpp, the obsolete_jvm_flags entry for SegmentedHeapDumpThreshold was changed to conform to 8u. If you apply the patch and issue java -XX: -XX:SegmentedHeapDumpThreshold=2g you get "OpenJDK 64-Bit Server VM warning: ignoring option AutoShutdownNMT; support was removed in 9.0", which is confusing since we're running 8. But, you get the same message from java -XX: -XX:+AutoShutdownNMT so the problem isn?t unique to this patch, and likely the result of previous backports. For this patch, I'd use { "SegmentedHeapDumpThreshold", JDK_Version::jdk_update(8, 242), JDK_Version::jdk(10) }, It would be great if you would file an issue to fix the other two (there's also UseOldInlining, which doesn't generate a message because it hasn't been removed from c2_globals.hpp, which it should be). Thanks, Paul ?On 10/9/19, 2:12 AM, "jdk8u-dev on behalf of Denghui Dong" wrote: Hi Team: The previous webrev didn't contain original commit information, so I made a new webrev in http://cr.openjdk.java.net/~ddong/8144732/hotspot.00/ Can you help to review it ? I think it is worth backporting. Thanks Denghui Dong ------------------------------------------------------------------ From:kelthuzadx <1948638989 at qq.com> Send Time:2019?10?7?(???) 10:28 To:???(??) Subject:Re: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len Good job? it ?s necessary to support large heap dump since 8u contains g1gc whose design principle is managing the large heap ------------------ Original ------------------ From: Denghui Dong Date: Sat,Oct 5,2019 10:27 AM To: jdk8u-dev Subject: Re: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len Any comments ? Thanks, Denghui Dong ------------------------------------------------------------------ From:???(??) Send Time:2019?9?25?(???) 16:02 To:jdk8u-dev Subject:Re: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len 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 johnc at azul.com Tue Oct 15 19:16:03 2019 From: johnc at azul.com (John Cuthbertson) Date: Tue, 15 Oct 2019 19:16:03 +0000 Subject: [8u] RFR (S): Backport: JDK-8048556: Unnecessary GCLocker-initiated young GCs Message-ID: <225B03D6-D4CA-4DEC-84BC-29FE50B74D9B@azul.com> Hi Everyone, I?d like to contribute a back port of the changes for JDK-8048556 to jdk8u-dev/hotspot. You can find the webrev at http://cr.openjdk.java.net/~johnc/8048556/webrev.00/. Please bare with me since it?s been a long time since I contributed to OpenJDK. I apologize for any mis-steps in advance. Andrew has said in email that he has/had added jdk8u-fix-request label to the bug entry. As you would expect the import did not apply cleanly ? mostly because of different paths so a lot had to manually back ported. The main places that needed some hand massaging were: * minor tweaks to the comments in g1CollectedHeap.cpp and genCollectedHeap.cpp, * setting the _full attribute in the VM_GenCollectFull operation (I suppose I should have followed the coding model in vmPSOperations.cpp and added a static is_cause_full() helper routine ? I can do that if people wish), * changing Kim?s test to use GC MXBeans and output Before GC Eden information in a test local format along with some message if the Eden use was below or above 40% of max/committed and have the test grep for the bad message. I also manually tested using Tony P?s second test that was attached to the bug entry with the following combinations of options: ("-XX:+UseParNewGC" "-XX:+UseSerialGC" "-XX:+UseParallelGC" "-XX:+UseConcMarkSweepGC" "-XX:+UseG1GC" "-XX:+UseParallelGC -XX:+UseParallelOldGC" "-XX:+UseConcMarkSweepGC -XX:-UseParNewGC" "-XX:+UseConcMarkSweepGC -XX:+GCLockerInvokesConcurrent" "-XX:+UseG1GC -XX:+GCLockerInvokesConcurrent?) Please note that since CMS and G1 with -XX:+GCLockerInvokesConcurrent does not drop GCLocker initiated GCs we can still see GCs with under utilized Edens with these combinations. Once everything looks OK I think I?ll have to have someone else from Azul push the actual change. Thanks John Cuthbertson From gnu.andrew at redhat.com Tue Oct 15 20:54:30 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 15 Oct 2019 21:54:30 +0100 Subject: [8u232-b08] New test failures due to tzdata-updates In-Reply-To: References: Message-ID: On 15/10/2019 13:27, Severin Gehwolf wrote: > Hi, > > The latest EA tags of the jdk8u/jdk8u tree (jdk8u232-b08) have new test > failures in. jdk8u232-b07 was OK: > > sun/util/calendar/zi/TestZoneInfo310.java > > The failure looks like this: > > Compiling tz files! > testing! > OLD.getZoneInfoOld()[1]=648 > OLD.getZoneInfoOld()[2]=194 > OLD.getZoneInfoOld()[3]=169 > OLD.getAvailableIDs()=746, total=628 > OLD.getAliasTable()=493, total=228 > OLD.TotalTZ()=80 (ms) > NEW.getTimeZone()[1]=70 > NEW.getTimeZone()[2]=16 > NEW.getTimeZone()[3]=9 > NEW.getAvailableIDs()=18, total=628 > NEW.getAliasTable()=74, total=228 > NEW.TotalTZ()=1 (ms) > ****************************** > America/Campo_Grande : America/Campo_Grande > offset=-14400000,dstSavings=0,useDaylight=false,transitions=93,offsets=4,checksum=-718118701,gmtChanged=false > [NG]offset=-14400000,dstSavings=3600000,useDaylight=false,transitions=129,offsets=4,checksum=374743623,gmtChanged=false > ------------- > (NG) Different trans size :93, 129 > 1900-01-01T00:00 [utc=-2208988800 raw=fffffdfdae01dc00, offset=-13108/-03:38:28, saving=0] > (OK) 1900-01-01T00:00 [utc=-2208988800 raw=fffffdfdae01dc00, offset=-13108/-03:38:28, saving=0] > ----- > > Failures are also observed at AdoptOpenJDK: > https://ci.adoptopenjdk.net/view/Test_upstream/job/Test_openjdk8_hs_sanity.openjdk_x86-64_windows_upstream/19/ > > These failures are due to these two changesets: > http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/d355fd566378 > http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/8560bc534080 > > Both of them would need to update tzdata copies in the test subtree for > the tests to pass again. > > The addendum for JDK-8228469 (rev d355fd566378) would be this: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8228469-8u-fixup/01/webrev/ > > The addendum for JDK-8231098 (rev 8560bc534080) would be this: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231098-8u-fixup/02/webrev/ > > The current code in jdk8u232-b08 compares tzdata2019a (test code) with > tzdata2019c (jdk code). Thus the test failure(s). > > Shall I create 8u-only bugs for them or is there another, preferred, > solution to this? > > Thanks, > Severin > Yes, this appears to have been missed because the test changes were not part of the 11u version, having been removed by the switch to vanguard format. I think it would be preferable to just move straight to backporting the vanguard support once the CPU is done and dusted. Fixing the tests before that would just make backporting the vanguard fix (based on 2019a) more difficult with no clear benefit. Thanks for catching this though, -- 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 Oct 15 20:59:29 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 15 Oct 2019 21:59:29 +0100 Subject: [RFR] [8u] jdk8u232-b10/jdk8u232-ga Message-ID: <19a30914-3e6f-4485-85f9-233bf85c5a4c@redhat.com> Here are the remaining changes for the jdk8u repository: Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8u232/ Changes in jdk8u232-b10: - S8167646: Better invalid FilePermission - S8213429, CVE-2019-2933: Windows file handling redux - S8218573, CVE-2019-2945: Better socket support - S8218877: Help transform transformers - S8220186: Improve use of font temporary files - S8220302, CVE-2019-2949: Better Kerberos ccache handling - S8221497: Optional Panes in Swing - S8221858, CVE-2019-2958: Build Better Processes - S8222684, CVE-2019-2964: Better support for patterns - S8222690, CVE-2019-2962: Better Glyph Images - S8223163: Better pattern recognition - S8223505, CVE-2019-2973: Better pattern compilation - S8223518, CVE-2019-2975: Unexpected exception in jjs - S8223892, CVE-2019-2978: Improved handling of jar files - S8224025: Fix for JDK-8220302 is not complete - S8224532, CVE-2019-2981: Better Path supports - S8224915, CVE-2019-2983: Better serial attributes - S8225286, CVE-2019-2987: Better rendering of native glyphs - S8225292, CVE-2019-2988: Better Graphics2D drawing - S8225298, CVE-2019-2989: Improve TLS connection support - S8225597, CVE-2019-2992: Enhance font glyph mapping - S8226765, CVE-2019-2999: Commentary on Javadoc comments - S8227129: Better ligature for subtables - S8227601: Better collection of references - S8228825, CVE-2019-2894: Enhance ECDSA operations jdk8u222-b10 is tagged as jdk8u222-ga. Ok to push? -- 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 Oct 15 21:10:13 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 15 Oct 2019 23:10:13 +0200 Subject: [RFR] [8u] jdk8u232-b10/jdk8u232-ga In-Reply-To: <19a30914-3e6f-4485-85f9-233bf85c5a4c@redhat.com> References: <19a30914-3e6f-4485-85f9-233bf85c5a4c@redhat.com> Message-ID: <523a6383-ec09-10a8-6d14-570e8229e7cd@redhat.com> On 10/15/19 10:59 PM, Andrew John Hughes wrote: > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8u232/ corba: hotspot: javaws: root: Trivially good, only tags. jaxp: langtools: nashorn: Looks good. jdk: Looks good. As with 11u, there are many indenting and whitespace changes that are confusing and not necessary, but this is not the place to fix it. Thumbs up, good to go. -- Thanks, -Aleksey From hohensee at amazon.com Tue Oct 15 21:27:14 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 15 Oct 2019 21:27:14 +0000 Subject: [8u] RFR (S): Backport: JDK-8048556: Unnecessary GCLocker-initiated young GCs In-Reply-To: <225B03D6-D4CA-4DEC-84BC-29FE50B74D9B@azul.com> References: <225B03D6-D4CA-4DEC-84BC-29FE50B74D9B@azul.com> Message-ID: Looks good overall. As you suggest, please add is_cause_full() in gcVMOperations.hpp. I expect your change to TestExcessGCLockerCollections.java is extensive enough for someone besides me to say it's worth doing in tip and backporting it. If you can use Kim's original code for this patch, I'd be happy to file an issue and handle it. Thanks, Paul ?On 10/15/19, 12:17 PM, "jdk8u-dev on behalf of John Cuthbertson" wrote: Hi Everyone, I?d like to contribute a back port of the changes for JDK-8048556 to jdk8u-dev/hotspot. You can find the webrev at http://cr.openjdk.java.net/~johnc/8048556/webrev.00/. Please bare with me since it?s been a long time since I contributed to OpenJDK. I apologize for any mis-steps in advance. Andrew has said in email that he has/had added jdk8u-fix-request label to the bug entry. As you would expect the import did not apply cleanly ? mostly because of different paths so a lot had to manually back ported. The main places that needed some hand massaging were: * minor tweaks to the comments in g1CollectedHeap.cpp and genCollectedHeap.cpp, * setting the _full attribute in the VM_GenCollectFull operation (I suppose I should have followed the coding model in vmPSOperations.cpp and added a static is_cause_full() helper routine ? I can do that if people wish), * changing Kim?s test to use GC MXBeans and output Before GC Eden information in a test local format along with some message if the Eden use was below or above 40% of max/committed and have the test grep for the bad message. I also manually tested using Tony P?s second test that was attached to the bug entry with the following combinations of options: ("-XX:+UseParNewGC" "-XX:+UseSerialGC" "-XX:+UseParallelGC" "-XX:+UseConcMarkSweepGC" "-XX:+UseG1GC" "-XX:+UseParallelGC -XX:+UseParallelOldGC" "-XX:+UseConcMarkSweepGC -XX:-UseParNewGC" "-XX:+UseConcMarkSweepGC -XX:+GCLockerInvokesConcurrent" "-XX:+UseG1GC -XX:+GCLockerInvokesConcurrent?) Please note that since CMS and G1 with -XX:+GCLockerInvokesConcurrent does not drop GCLocker initiated GCs we can still see GCs with under utilized Edens with these combinations. Once everything looks OK I think I?ll have to have someone else from Azul push the actual change. Thanks John Cuthbertson From gnu.andrew at redhat.com Tue Oct 15 23:11:02 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 16 Oct 2019 00:11:02 +0100 Subject: OpenJDK 8u232 Released Message-ID: <0de54ae1-3a44-757d-db70-3d603a997392@redhat.com> We are pleased to announce the release of OpenJDK 8u232. The source tarball is available from: * https://openjdk-sources.osci.io/openjdk8/openjdk8u232-ga.tar.xz The tarball is accompanied by a digital signature available at: * https://openjdk-sources.osci.io/openjdk8/openjdk8u232-ga.tar.xz.sig This is signed by our 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: 5d135c4a9f84e918b190de6f106b0341414d12614b01d728c253450e760627b6 openjdk8u232-ga.tar.xz 52c11d337eeba252dc681137cf002a8caceff482e119c04cde9cd2bfd2a77366 openjdk8u232-ga.tar.xz.sig The checksums can be downloaded from: * https://openjdk-sources.osci.io/openjdk8/openjdk8u232-ga.sha256 What's New? =========== Security fixes - S8167646: Better invalid FilePermission - S8213429, CVE-2019-2933: Windows file handling redux - S8218573, CVE-2019-2945: Better socket support - S8218877: Help transform transformers - S8220186: Improve use of font temporary files - S8220302, CVE-2019-2949: Better Kerberos ccache handling - S8221497: Optional Panes in Swing - S8221858, CVE-2019-2958: Build Better Processes - S8222684, CVE-2019-2964: Better support for patterns - S8222690, CVE-2019-2962: Better Glyph Images - S8223163: Better pattern recognition - S8223505, CVE-2019-2973: Better pattern compilation - S8223518, CVE-2019-2975: Unexpected exception in jjs - S8223892, CVE-2019-2978: Improved handling of jar files - S8224025: Fix for JDK-8220302 is not complete - S8224532, CVE-2019-2981: Better Path supports - S8224915, CVE-2019-2983: Better serial attributes - S8225286, CVE-2019-2987: Better rendering of native glyphs - S8225292, CVE-2019-2988: Better Graphics2D drawing - S8225298, CVE-2019-2989: Improve TLS connection support - S8225597, CVE-2019-2992: Enhance font glyph mapping - S8226765, CVE-2019-2999: Commentary on Javadoc comments - S8227129: Better ligature for subtables - S8227601: Better collection of references - S8228825, CVE-2019-2894: Enhance ECDSA operations Other changes - S6913047: Long term memory leak when using PKCS11 and JCE exceeds 32 bit process address space - S6946830: javax.crypto.Cipher.doFinal behavior differs depending on platform - S6996807: FieldReflectorKey hash code computation can be improved - S8030993: Check jdk/src/share/native/common/jni_util.c for JNI pending exceptions - S8038392: Generating prelink cache breaks JAVA 'jinfo' utility normal behaviour - S8075136: Unnecessary sign extension for byte array access - S8075544: Add tiered testing definitions to the jdk repo - S8075546: Add tiered testing definitions to the langtools repo - S8075573: Add jdk_other and jdk_svc to jdk tier 2 test definition - 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 - S8151486: Class.forName causes memory leak - S8152856: Xcode 7.3 -Wshift-negative-value compile failure on Mac OS X - S8153732: Windows remote printer changes do not reflect in lookupPrintServices() - S8155951: VM crash in nsk/jvmti/RedefineClasses/StressRedefine: assert failed: Corrupted constant pool - S8157792: After Integrating tzdata2016d the test/sun/util/calendar/zi/TestZoneInfo310.java fails for "Asia/Oral" and "Asia/Qyzylorda" Timezones - S8168417: Pending exceptions in java.base/windows/native/libnio - S8170494: JNI exception pending in PlainDatagramSocketImpl.c - S8178870: instrumentation.retransformClasses cause coredump - S8182999: SunEC throws ProviderException on invalid curves - S8185900: hotspot build failed with gcc version Red Hat 4.4.7-3 - S8185979: PPC64: Implement SHA2 intrinsic - S8188868: PPC64: Support AES intrinsics on Big Endian - S8197930: JNI exception pending in initializeEncoding of jni_util.c - S8202252: (aio) Closed AsynchronousSocketChannel keeps completion handler alive - S8202353: os::readdir should use readdir instead of readdir_r - 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 - S8205587: Implicit function declaration in jni_util.c - S8206879: Currency decimal marker incorrect for Peru - S8210761: libjsig is being compiled without optimization - S8211232: GraphKit::make_runtime_call() sometimes attaches wrong memory state to call - S8212202: [Windows] Exception if no printers are installed. - S8213561: ZipFile/MultiThreadedReadTest.java timed out in tier1 - S8214002: Cannot use italic font style if the font has embedded bitmap - 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 - S8215982: (tz) Upgrade time-zone data to tzdata2018i - S8216597: SIGBUS in Java_sun_security_pkcs11_wrapper_PKCS11_getNativeKeyInfo after JDK-6913047 - S8216965: crash in freetypeScaler.c CopyBW2Grey8 - S8217359: C2 compiler triggers SIGSEGV after transformation in ConvI2LNode::Ideal - S8217676: Upgrade libpng to 1.6.37 - S8217731: Font rendering and glyph spacing changed from jdk-8 to jdk-11 - S8217785: Padding ParallelTaskTerminator::_offered_termination variable - 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. - S8218721: C1's CEE optimization produces safepoint poll with invalid debug information - S8218780: Update MUSCLE PCSC-Lite header files - S8218781: Localized names for Japanese era Reiwa in COMPAT provider - S8218854: FontMetrics.getMaxAdvance may be less than the maximum FontMetrics.charWidth - S8219517: assert(false) failed: infinite loop in PhaseIterGVN::optimize - S8219807: C2 crash in IfNode::up_one_dom(Node*, bool) - S8220072: GCC 8.3 reports errors in java.base - S8220513: Wrapper Key may get deleted when closing sessions in SunPKCS11 crypto provider - S8221263: [TEST_BUG] RemotePrinterStatusRefresh test is hard to use - S8221304: Problem list java/awt/FontMetrics/MaxAdvanceIsMax.java - S8221412: lookupPrintServices() does not always update the list of Windows remote printers - S8222108: Reduce minRefreshTime for updating remote printer list on Windows - S8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u - S8222980: Upgrade IANA Language Subtag Registry to Version 2019-04-03 - S8223177: Data race on JvmtiEnvBase::_tag_map in double-checked locking - S8223219: Backport of JDK-8199552 to OpenJDK 8 leads to duplicate -fstack-protector flags, overriding --with-extra-cflags - S8223227: Rename acquire_tag_map() to tag_map_acquire() in jvmtiEnvBase - S8224560: (tz) Upgrade time-zone data to tzdata2019a - S8224580: Matcher can cause oop field/array element to be reloaded - S8225423: GTK L&F: JSplitPane: There is no divider shown - S8225425: java.lang.UnsatisfiedLinkError: net.dll: Can't find dependent libraries - S8225580: tzdata2018i integration causes test failures on jdk-13 - S8225636: SA can't handle prelinked libraries - S8226392: Launcher should not enable legacy stdio streams on GNU/Linux (glibc) - S8226543: Reduce GC pressure during message digest calculations in password-based encryption - S8226607: Inconsistent info between pcsclite.md and MUSCLE headers - S8226798: JVM crash in klassItable::initialize_itable_for_interface(int, InstanceKlass*, bool, Thread*) - S8226870: OpenJDK 8u JRE contains clhsdb and hsdb launchers - S8226928: [TESTBUG] test/java/net/NetworkInterface/IPv4Only.java fails intermittently on AIX - S8226964: [Yaru] GTK L&F: There is no difference between menu selected and de-selected - S8227018: CompletableFuture should not call Runtime.availableProcessors on fast path - S8228405: Incorrect format strings in PhaseIdealLoop::rc_predicate - S8228440: TestAESCiphers tests fail with "access denied" trying to access ArrayUtil - S8228469: (tz) Upgrade time-zone data to tzdata2019b - S8230085: (fs) FileStore::isReadOnly is always true on macOS Catalina - S8231098: (tz) Upgrade time-zone data to tzdata2019c - S8231463: Fix runtime/RedefineTests/RedefineDoubleDelete.java test in 8u -- 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 Wed Oct 16 01:50:15 2019 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Wed, 16 Oct 2019 09:50:15 +0800 Subject: =?UTF-8?B?UmU6IFs4dV0gUkZSIGJhY2twb3J0IG9mIEpESy04MTQ0NzMyOiBWTV9IZWFwRHVtcGVyIGhp?= =?UTF-8?B?dHMgYXNzZXJ0IHdpdGggYmFkIGR1bXBfbGVu?= In-Reply-To: <1F597219-BD21-4ABD-806F-AF7B8B2F2638@amazon.com> References: , <1F597219-BD21-4ABD-806F-AF7B8B2F2638@amazon.com> Message-ID: <1d01ff0c-aa5b-4c3d-8225-1ee76c7b564c.denghui.ddh@alibaba-inc.com> Hi Paul, Thank you, I upload the amended webrev in http://cr.openjdk.java.net/~ddong/8144732/hotspot.01, By the way, I am not sure the update-version should be used in arguments.cpp, I just use 242 mentioned in your previous mail. Also, I will file an issue to fix the obsoleted version of the other two flags (UseOldInlining and AutoShutdownNMT) later. Thanks Denghui Dong ------------------------------------------------------------------ From:Hohensee, Paul Send Time:2019?10?16?(???) 02:21 To:???(??) ; jdk8u-dev Subject:Re: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len The JBS issue and changeset links you posted are for 8150432, not 8144732, which was confusing. The webrev is for 8144732 though. I can find only two places where your patch is different from the original changeset, net of line numbers/file locations. The rest looks fine. They are: In heapDumper.cpp, there should be only one blank line after the definition of WRITE_ARRAY. In arguments.cpp, the obsolete_jvm_flags entry for SegmentedHeapDumpThreshold was changed to conform to 8u. If you apply the patch and issue java -XX: -XX:SegmentedHeapDumpThreshold=2g you get "OpenJDK 64-Bit Server VM warning: ignoring option AutoShutdownNMT; support was removed in 9.0", which is confusing since we're running 8. But, you get the same message from java -XX: -XX:+AutoShutdownNMT so the problem isn?t unique to this patch, and likely the result of previous backports. For this patch, I'd use { "SegmentedHeapDumpThreshold", JDK_Version::jdk_update(8, 242), JDK_Version::jdk(10) }, It would be great if you would file an issue to fix the other two (there's also UseOldInlining, which doesn't generate a message because it hasn't been removed from c2_globals.hpp, which it should be). Thanks, Paul On 10/9/19, 2:12 AM, "jdk8u-dev on behalf of Denghui Dong" wrote: Hi Team: The previous webrev didn't contain original commit information, so I made a new webrev in http://cr.openjdk.java.net/~ddong/8144732/hotspot.00/ Can you help to review it ? I think it is worth backporting. Thanks Denghui Dong ------------------------------------------------------------------ From:kelthuzadx <1948638989 at qq.com> Send Time:2019?10?7?(???) 10:28 To:???(??) Subject:Re: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len Good job? it ?s necessary to support large heap dump since 8u contains g1gc whose design principle is managing the large heap ------------------ Original ------------------ From: Denghui Dong Date: Sat,Oct 5,2019 10:27 AM To: jdk8u-dev Subject: Re: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len Any comments ? Thanks, Denghui Dong ------------------------------------------------------------------ From:???(??) Send Time:2019?9?25?(???) 16:02 To:jdk8u-dev Subject:Re: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len 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 denghui.ddh at alibaba-inc.com Wed Oct 16 03:18:15 2019 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Wed, 16 Oct 2019 11:18:15 +0800 Subject: =?UTF-8?B?Wzh1XSBSRlIgODIzMjM1NTogVHdvIG9ic29sZXRlIGZsYWdzIGhhdmUgdGhlIHdyb25nIG9i?= =?UTF-8?B?c29sZXRlIHZlcnNpb24gaW4gOHU=?= Message-ID: Hi, Please review this patch for JDK-8232355. There are two obsolete flags with the wrong obsolete version("AutoShutdownNMT" and "UseOldInlining") in 8u. Bug: https://bugs.openjdk.java.net/browse/JDK-8232355 webrev: http://cr.openjdk.java.net/~ddong/8232355/hotspot.00/ Thanks, Denghui Dong From sgehwolf at redhat.com Wed Oct 16 07:59:11 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 16 Oct 2019 09:59:11 +0200 Subject: [RFR] [8u] jdk8u232-b09/jdk8u232-ga (was: [RFR] [8u] jdk8u232-b10/jdk8u232-ga) In-Reply-To: <19a30914-3e6f-4485-85f9-233bf85c5a4c@redhat.com> References: <19a30914-3e6f-4485-85f9-233bf85c5a4c@redhat.com> Message-ID: <911214ecb0e0ad7befe067997f15c1ea12f024d5.camel@redhat.com> Hi, Correcting subject and tag names as this might confuse users. On Tue, 2019-10-15 at 21:59 +0100, Andrew John Hughes wrote: > Here are the remaining changes for the jdk8u repository: > > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8u232/ > > Changes in jdk8u232-b10: jdk8u232-b09 :) [...] > jdk8u222-b10 is tagged as jdk8u222-ga. > > Ok to push? Just to clarify, I believe you mean jdk8u232-b09 is tagged as jdk8u232- ga? That's what the actual tags are in reality: http://hg.openjdk.java.net/jdk8u/jdk8u Thanks, Severin From sgehwolf at redhat.com Wed Oct 16 08:03:43 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 16 Oct 2019 10:03:43 +0200 Subject: OpenJDK 8u232 Released In-Reply-To: <0de54ae1-3a44-757d-db70-3d603a997392@redhat.com> References: <0de54ae1-3a44-757d-db70-3d603a997392@redhat.com> Message-ID: <81a59025901a7321d2c618a4edef19bf57ca5499.camel@redhat.com> Hi, On Wed, 2019-10-16 at 00:11 +0100, Andrew John Hughes wrote: > We are pleased to announce the release of OpenJDK 8u232. > > The source tarball is available from: > > * https://openjdk-sources.osci.io/openjdk8/openjdk8u232-ga.tar.xz OpenJDK Project Builds have been updated to 8u232-ga as well: https://adoptopenjdk.net/upstream.html Thanks, Severin > The tarball is accompanied by a digital signature available at: > > * https://openjdk-sources.osci.io/openjdk8/openjdk8u232-ga.tar.xz.sig > > This is signed by our 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: > > 5d135c4a9f84e918b190de6f106b0341414d12614b01d728c253450e760627b6 > openjdk8u232-ga.tar.xz > 52c11d337eeba252dc681137cf002a8caceff482e119c04cde9cd2bfd2a77366 > openjdk8u232-ga.tar.xz.sig > > The checksums can be downloaded from: > > * https://openjdk-sources.osci.io/openjdk8/openjdk8u232-ga.sha256 > > What's New? > =========== > Security fixes > - S8167646: Better invalid FilePermission > - S8213429, CVE-2019-2933: Windows file handling redux > - S8218573, CVE-2019-2945: Better socket support > - S8218877: Help transform transformers > - S8220186: Improve use of font temporary files > - S8220302, CVE-2019-2949: Better Kerberos ccache handling > - S8221497: Optional Panes in Swing > - S8221858, CVE-2019-2958: Build Better Processes > - S8222684, CVE-2019-2964: Better support for patterns > - S8222690, CVE-2019-2962: Better Glyph Images > - S8223163: Better pattern recognition > - S8223505, CVE-2019-2973: Better pattern compilation > - S8223518, CVE-2019-2975: Unexpected exception in jjs > - S8223892, CVE-2019-2978: Improved handling of jar files > - S8224025: Fix for JDK-8220302 is not complete > - S8224532, CVE-2019-2981: Better Path supports > - S8224915, CVE-2019-2983: Better serial attributes > - S8225286, CVE-2019-2987: Better rendering of native glyphs > - S8225292, CVE-2019-2988: Better Graphics2D drawing > - S8225298, CVE-2019-2989: Improve TLS connection support > - S8225597, CVE-2019-2992: Enhance font glyph mapping > - S8226765, CVE-2019-2999: Commentary on Javadoc comments > - S8227129: Better ligature for subtables > - S8227601: Better collection of references > - S8228825, CVE-2019-2894: Enhance ECDSA operations > Other changes > - S6913047: Long term memory leak when using PKCS11 and JCE exceeds 32 > bit process address space > - S6946830: javax.crypto.Cipher.doFinal behavior differs depending on > platform > - S6996807: FieldReflectorKey hash code computation can be improved > - S8030993: Check jdk/src/share/native/common/jni_util.c for JNI > pending exceptions > - S8038392: Generating prelink cache breaks JAVA 'jinfo' utility > normal behaviour > - S8075136: Unnecessary sign extension for byte array access > - S8075544: Add tiered testing definitions to the jdk repo > - S8075546: Add tiered testing definitions to the langtools repo > - S8075573: Add jdk_other and jdk_svc to jdk tier 2 test definition > - 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 > - S8151486: Class.forName causes memory leak > - S8152856: Xcode 7.3 -Wshift-negative-value compile failure on Mac OS X > - S8153732: Windows remote printer changes do not reflect in > lookupPrintServices() > - S8155951: VM crash in nsk/jvmti/RedefineClasses/StressRedefine: > assert failed: Corrupted constant pool > - S8157792: After Integrating tzdata2016d the > test/sun/util/calendar/zi/TestZoneInfo310.java fails for "Asia/Oral" and > "Asia/Qyzylorda" Timezones > - S8168417: Pending exceptions in java.base/windows/native/libnio > - S8170494: JNI exception pending in PlainDatagramSocketImpl.c > - S8178870: instrumentation.retransformClasses cause coredump > - S8182999: SunEC throws ProviderException on invalid curves > - S8185900: hotspot build failed with gcc version Red Hat 4.4.7-3 > - S8185979: PPC64: Implement SHA2 intrinsic > - S8188868: PPC64: Support AES intrinsics on Big Endian > - S8197930: JNI exception pending in initializeEncoding of jni_util.c > - S8202252: (aio) Closed AsynchronousSocketChannel keeps completion > handler alive > - S8202353: os::readdir should use readdir instead of readdir_r > - 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 > - S8205587: Implicit function declaration in jni_util.c > - S8206879: Currency decimal marker incorrect for Peru > - S8210761: libjsig is being compiled without optimization > - S8211232: GraphKit::make_runtime_call() sometimes attaches wrong > memory state to call > - S8212202: [Windows] Exception if no printers are installed. > - S8213561: ZipFile/MultiThreadedReadTest.java timed out in tier1 > - S8214002: Cannot use italic font style if the font has embedded bitmap > - 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 > - S8215982: (tz) Upgrade time-zone data to tzdata2018i > - S8216597: SIGBUS in > Java_sun_security_pkcs11_wrapper_PKCS11_getNativeKeyInfo after JDK-6913047 > - S8216965: crash in freetypeScaler.c CopyBW2Grey8 > - S8217359: C2 compiler triggers SIGSEGV after transformation in > ConvI2LNode::Ideal > - S8217676: Upgrade libpng to 1.6.37 > - S8217731: Font rendering and glyph spacing changed from jdk-8 to jdk-11 > - S8217785: Padding ParallelTaskTerminator::_offered_termination variable > - 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. > - S8218721: C1's CEE optimization produces safepoint poll with invalid > debug information > - S8218780: Update MUSCLE PCSC-Lite header files > - S8218781: Localized names for Japanese era Reiwa in COMPAT provider > - S8218854: FontMetrics.getMaxAdvance may be less than the maximum > FontMetrics.charWidth > - S8219517: assert(false) failed: infinite loop in PhaseIterGVN::optimize > - S8219807: C2 crash in IfNode::up_one_dom(Node*, bool) > - S8220072: GCC 8.3 reports errors in java.base > - S8220513: Wrapper Key may get deleted when closing sessions in > SunPKCS11 crypto provider > - S8221263: [TEST_BUG] RemotePrinterStatusRefresh test is hard to use > - S8221304: Problem list java/awt/FontMetrics/MaxAdvanceIsMax.java > - S8221412: lookupPrintServices() does not always update the list of > Windows remote printers > - S8222108: Reduce minRefreshTime for updating remote printer list on > Windows > - S8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u > - S8222980: Upgrade IANA Language Subtag Registry to Version 2019-04-03 > - S8223177: Data race on JvmtiEnvBase::_tag_map in double-checked locking > - S8223219: Backport of JDK-8199552 to OpenJDK 8 leads to duplicate > -fstack-protector flags, overriding --with-extra-cflags > - S8223227: Rename acquire_tag_map() to tag_map_acquire() in jvmtiEnvBase > - S8224560: (tz) Upgrade time-zone data to tzdata2019a > - S8224580: Matcher can cause oop field/array element to be reloaded > - S8225423: GTK L&F: JSplitPane: There is no divider shown > - S8225425: java.lang.UnsatisfiedLinkError: net.dll: Can't find > dependent libraries > - S8225580: tzdata2018i integration causes test failures on jdk-13 > - S8225636: SA can't handle prelinked libraries > - S8226392: Launcher should not enable legacy stdio streams on > GNU/Linux (glibc) > - S8226543: Reduce GC pressure during message digest calculations in > password-based encryption > - S8226607: Inconsistent info between pcsclite.md and MUSCLE headers > - S8226798: JVM crash in > klassItable::initialize_itable_for_interface(int, InstanceKlass*, bool, > Thread*) > - S8226870: OpenJDK 8u JRE contains clhsdb and hsdb launchers > - S8226928: [TESTBUG] test/java/net/NetworkInterface/IPv4Only.java > fails intermittently on AIX > - S8226964: [Yaru] GTK L&F: There is no difference between menu > selected and de-selected > - S8227018: CompletableFuture should not call > Runtime.availableProcessors on fast path > - S8228405: Incorrect format strings in PhaseIdealLoop::rc_predicate > - S8228440: TestAESCiphers tests fail with "access denied" trying to > access ArrayUtil > - S8228469: (tz) Upgrade time-zone data to tzdata2019b > - S8230085: (fs) FileStore::isReadOnly is always true on macOS Catalina > - S8231098: (tz) Upgrade time-zone data to tzdata2019c > - S8231463: Fix runtime/RedefineTests/RedefineDoubleDelete.java test in 8u > From gnu.andrew at redhat.com Wed Oct 16 12:39:14 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 16 Oct 2019 13:39:14 +0100 Subject: [RFR] [8u] jdk8u232-b09/jdk8u232-ga (was: [RFR] [8u] jdk8u232-b10/jdk8u232-ga) In-Reply-To: <911214ecb0e0ad7befe067997f15c1ea12f024d5.camel@redhat.com> References: <19a30914-3e6f-4485-85f9-233bf85c5a4c@redhat.com> <911214ecb0e0ad7befe067997f15c1ea12f024d5.camel@redhat.com> Message-ID: On 16/10/2019 08:59, Severin Gehwolf wrote: > Hi, > > Correcting subject and tag names as this might confuse users. > > On Tue, 2019-10-15 at 21:59 +0100, Andrew John Hughes wrote: >> Here are the remaining changes for the jdk8u repository: >> >> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8u232/ >> >> Changes in jdk8u232-b10: > > jdk8u232-b09 :) > > [...] >> jdk8u222-b10 is tagged as jdk8u222-ga. >> >> Ok to push? > > Just to clarify, I believe you mean jdk8u232-b09 is tagged as jdk8u232- > ga? That's what the actual tags are in reality: > > http://hg.openjdk.java.net/jdk8u/jdk8u > > Thanks, > Severin > Yes, thanks. That's what we in the trade call a copy-and-paste error :) (It was b10 last time, we skipped one this cycle) -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From hohensee at amazon.com Wed Oct 16 15:28:19 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 16 Oct 2019 15:28:19 +0000 Subject: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len In-Reply-To: <1d01ff0c-aa5b-4c3d-8225-1ee76c7b564c.denghui.ddh@alibaba-inc.com> References: <1F597219-BD21-4ABD-806F-AF7B8B2F2638@amazon.com> <1d01ff0c-aa5b-4c3d-8225-1ee76c7b564c.denghui.ddh@alibaba-inc.com> Message-ID: I asked for 242 because that?s the 8u release in which the change will be shipped. Looks fine now. Thanks, Paul From: Denghui Dong Reply-To: Denghui Dong Date: Tuesday, October 15, 2019 at 6:51 PM To: jdk8u-dev , "Hohensee, Paul" Subject: Re: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len Hi Paul, Thank you, I upload the amended webrev in http://cr.openjdk.java.net/~ddong/8144732/hotspot.01, By the way, I am not sure the update-version should be used in arguments.cpp, I just use 242 mentioned in your previous mail. Also, I will file an issue to fix the obsoleted version of the other two flags (UseOldInlining and AutoShutdownNMT) later. Thanks Denghui Dong ------------------------------------------------------------------ From:Hohensee, Paul Send Time:2019?10?16?(???) 02:21 To:???(??) ; jdk8u-dev Subject:Re: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len The JBS issue and changeset links you posted are for 8150432, not 8144732, which was confusing. The webrev is for 8144732 though. I can find only two places where your patch is different from the original changeset, net of line numbers/file locations. The rest looks fine. They are: In heapDumper.cpp, there should be only one blank line after the definition of WRITE_ARRAY. In arguments.cpp, the obsolete_jvm_flags entry for SegmentedHeapDumpThreshold was changed to conform to 8u. If you apply the patch and issue java -XX: -XX:SegmentedHeapDumpThreshold=2g you get "OpenJDK 64-Bit Server VM warning: ignoring option AutoShutdownNMT; support was removed in 9.0", which is confusing since we're running 8. But, you get the same message from java -XX: -XX:+AutoShutdownNMT so the problem isn?t unique to this patch, and likely the result of previous backports. For this patch, I'd use { "SegmentedHeapDumpThreshold", JDK_Version::jdk_update(8, 242), JDK_Version::jdk(10) }, It would be great if you would file an issue to fix the other two (there's also UseOldInlining, which doesn't generate a message because it hasn't been removed from c2_globals.hpp, which it should be). Thanks, Paul On 10/9/19, 2:12 AM, "jdk8u-dev on behalf of Denghui Dong" wrote: Hi Team: The previous webrev didn't contain original commit information, so I made a new webrev in http://cr.openjdk.java.net/~ddong/8144732/hotspot.00/ Can you help to review it ? I think it is worth backporting. Thanks Denghui Dong ------------------------------------------------------------------ From:kelthuzadx <1948638989 at qq.com> Send Time:2019?10?7?(???) 10:28 To:???(??) Subject:Re: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len Good job? it ?s necessary to support large heap dump since 8u contains g1gc whose design principle is managing the large heap ------------------ Original ------------------ From: Denghui Dong Date: Sat,Oct 5,2019 10:27 AM To: jdk8u-dev Subject: Re: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len Any comments ? Thanks, Denghui Dong ------------------------------------------------------------------ From:???(??) Send Time:2019?9?25?(???) 16:02 To:jdk8u-dev Subject:Re: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len 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 hohensee at amazon.com Wed Oct 16 15:32:30 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 16 Oct 2019 15:32:30 +0000 Subject: [8u] RFR 8232355: Two obsolete flags have the wrong obsolete version in 8u In-Reply-To: References: Message-ID: Looks good. UseOldInling went away in 8u20 and AutoShutdownNMT in 8u40? Thanks, Paul From: Denghui Dong Reply-To: Denghui Dong Date: Tuesday, October 15, 2019 at 8:18 PM To: jdk8u-dev , "Hohensee, Paul" Subject: [8u] RFR 8232355: Two obsolete flags have the wrong obsolete version in 8u Hi, Please review this patch for JDK-8232355. There are two obsolete flags with the wrong obsolete version("AutoShutdownNMT" and "UseOldInlining") in 8u. Bug: https://bugs.openjdk.java.net/browse/JDK-8232355 webrev: http://cr.openjdk.java.net/~ddong/8232355/hotspot.00/ Thanks, Denghui Dong From denghui.ddh at alibaba-inc.com Wed Oct 16 15:52:55 2019 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Wed, 16 Oct 2019 23:52:55 +0800 Subject: =?UTF-8?B?UmU6IFs4dV0gUkZSIDgyMzIzNTU6IFR3byBvYnNvbGV0ZSBmbGFncyBoYXZlIHRoZSB3cm9u?= =?UTF-8?B?ZyBvYnNvbGV0ZSB2ZXJzaW9uIGluIDh1?= Message-ID: <58656d33-a347-4ec7-b35f-2390d13e7998.denghui.ddh@alibaba-inc.com> Yes, I put the links of the changeset in which the flags were made obsolete in the issue?s comment. Please double check if the version are right. Cheers Denghui Dong ----------------------------- ?(??)2019?10?16?, ?(??)??11:32, Hohensee, Paul ?? Looks good. UseOldInling went away in 8u20 and AutoShutdownNMT in 8u40? Thanks, Paul From: Denghui Dong Reply-To: Denghui Dong Date: Tuesday, October 15, 2019 at 8:18 PM To: jdk8u-dev , "Hohensee, Paul" Subject: [8u] RFR 8232355: Two obsolete flags have the wrong obsolete version in 8u Hi, Please review this patch for JDK-8232355. There are two obsolete flags with the wrong obsolete version("AutoShutdownNMT" and "UseOldInlining") in 8u. Bug: https://bugs.openjdk.java.net/browse/JDK-8232355 webrev: http://cr.openjdk.java.net/~ddong/8232355/hotspot.00/ Thanks, Denghui Dong From akozlov at azul.com Wed Oct 16 16:06:29 2019 From: akozlov at azul.com (Anton Kozlov) Date: Wed, 16 Oct 2019 19:06:29 +0300 Subject: [8u] RFR: JDK-8231584: Deadlock with ClassLoader.findLibrary and System.loadLibrary call Message-ID: <526e3855-d43a-f353-0894-5419773e1e11@azul.com> Hi, Please review backport of https://bugs.openjdk.java.net/browse/JDK-8231584 The change resolves a deadlock that was reported as JDK-8194653, but it have not fixed in openjdk 8u yet. Webrev: http://cr.openjdk.java.net/~akozlov/8231584/u8.webrev/ Changes for backport are: * comment in ClassLoader.java updated to match to jdk/jdk * ClassLoader's initLibraryPaths called in different place of System that predates modules system * test lost import of package of CompilerUtils, it's package-less in 8u Thanks, Anton From akozlov at azul.com Wed Oct 16 16:15:58 2019 From: akozlov at azul.com (Anton Kozlov) Date: Wed, 16 Oct 2019 19:15:58 +0300 Subject: 8194653: Deadlock involving FileSystems.getDefault and System.loadLibrary call In-Reply-To: References: <1fc64685-f010-8825-5bbf-87441f535476@redhat.com> <67ec67a6-c985-09f5-b12d-3528b7109962@redhat.com> Message-ID: <9f13be34-f3ea-192c-2ea1-b3eff77b4c94@azul.com> Hi, On 20.06.2019 17:35, Sciampacone, Ryan wrote: > > Yes, we're looking at options, but are also very much open to suggestions! > I've submitted RFR for JDK-8231584 backport [0] that should fix the issue described in this bug. It would be great if you evaluate it. Thanks, Anton [0]: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-October/010461.html From hohensee at amazon.com Wed Oct 16 18:45:08 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 16 Oct 2019 18:45:08 +0000 Subject: [8u] RFR 8232355: Two obsolete flags have the wrong obsolete version in 8u In-Reply-To: <58656d33-a347-4ec7-b35f-2390d13e7998.denghui.ddh@alibaba-inc.com> References: <58656d33-a347-4ec7-b35f-2390d13e7998.denghui.ddh@alibaba-inc.com> Message-ID: <8BD2CB44-73A0-4215-B471-1AD5DF2A74CC@amazon.com> They?re correct. Paul From: Denghui Dong Date: Wednesday, October 16, 2019 at 8:53 AM To: "Hohensee, Paul" , jdk8u-dev Subject: Re: [8u] RFR 8232355: Two obsolete flags have the wrong obsolete version in 8u Yes, I put the links of the changeset in which the flags were made obsolete in the issue?s comment. Please double check if the version are right. Cheers Denghui Dong ----------------------------- ?(??)2019?10?16?, ?(??)??11:32, Hohensee, Paul ?? Looks good. UseOldInling went away in 8u20 and AutoShutdownNMT in 8u40? Thanks, Paul From: Denghui Dong Reply-To: Denghui Dong Date: Tuesday, October 15, 2019 at 8:18 PM To: jdk8u-dev , "Hohensee, Paul" Subject: [8u] RFR 8232355: Two obsolete flags have the wrong obsolete version in 8u Hi, Please review this patch for JDK-8232355. There are two obsolete flags with the wrong obsolete version("AutoShutdownNMT" and "UseOldInlining") in 8u. Bug: https://bugs.openjdk.java.net/browse/JDK-8232355 webrev: http://cr.openjdk.java.net/~ddong/8232355/hotspot.00/ Thanks, Denghui Dong From hohensee at amazon.com Wed Oct 16 19:26:50 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 16 Oct 2019 19:26:50 +0000 Subject: [8u] RFR: JDK-8231584: Deadlock with ClassLoader.findLibrary and System.loadLibrary call In-Reply-To: <526e3855-d43a-f353-0894-5419773e1e11@azul.com> References: <526e3855-d43a-f353-0894-5419773e1e11@azul.com> Message-ID: <7DC7CFE1-6A83-44D3-9A87-876B2B9F7228@amazon.com> Hi, Anton, thanks for picking this up. Ryan has left Amazon, so probably isn't monitoring this list. Your backport looks good to me: the library fix is easier to understand than was Ryan's Hotspot fix. One tiny nit: in Runtime.java, the 14 patch changed the indentation of the line containing "Directory separator should not appear in library name: ": it would be good to carry that over to 8. Thanks, Paul ?On 10/16/19, 9:09 AM, "jdk8u-dev on behalf of Anton Kozlov" wrote: Hi, Please review backport of https://bugs.openjdk.java.net/browse/JDK-8231584 The change resolves a deadlock that was reported as JDK-8194653, but it have not fixed in openjdk 8u yet. Webrev: http://cr.openjdk.java.net/~akozlov/8231584/u8.webrev/ Changes for backport are: * comment in ClassLoader.java updated to match to jdk/jdk * ClassLoader's initLibraryPaths called in different place of System that predates modules system * test lost import of package of CompilerUtils, it's package-less in 8u Thanks, Anton From martijnverburg at gmail.com Wed Oct 16 19:48:56 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 16 Oct 2019 20:48:56 +0100 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, Apologies for the lateness on this, but we now have nightly builds (paused briefly for the CPU release). What other platforms would folks like? Cheers, Martijn On Sat, 14 Sep 2019 at 19:02, Martijn Verburg wrote: > 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 adinn at redhat.com Thu Oct 17 11:45:37 2019 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 17 Oct 2019 12:45:37 +0100 Subject: [8u] RFR: JDK-8231584: Deadlock with ClassLoader.findLibrary and System.loadLibrary call In-Reply-To: <526e3855-d43a-f353-0894-5419773e1e11@azul.com> References: <526e3855-d43a-f353-0894-5419773e1e11@azul.com> Message-ID: <7d756f04-3496-f951-ecab-f96392703329@redhat.com> On 16/10/2019 17:06, Anton Kozlov wrote: > Please review backport of https://bugs.openjdk.java.net/browse/JDK-8231584 > > The change resolves a deadlock that was reported as JDK-8194653, but it have not fixed in openjdk 8u yet. > > Webrev: http://cr.openjdk.java.net/~akozlov/8231584/u8.webrev/ > > Changes for backport are: > * comment in ClassLoader.java updated to match to jdk/jdk > * ClassLoader's initLibraryPaths called in different place of System that predates modules system > * test lost import of package of CompilerUtils, it's package-less in 8u Yes, backport looks good. regards, Andrew Dinn ----------- From denghui.ddh at alibaba-inc.com Thu Oct 17 13:37:47 2019 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Thu, 17 Oct 2019 21:37:47 +0800 Subject: =?UTF-8?B?UmU6IFs4dV0gUkZSIGJhY2twb3J0IG9mIEpESy04MTQ0NzMyOiBWTV9IZWFwRHVtcGVyIGhp?= =?UTF-8?B?dHMgYXNzZXJ0IHdpdGggYmFkIGR1bXBfbGVu?= In-Reply-To: References: <1F597219-BD21-4ABD-806F-AF7B8B2F2638@amazon.com> <1d01ff0c-aa5b-4c3d-8225-1ee76c7b564c.denghui.ddh@alibaba-inc.com>, Message-ID: <9bb6cdf9-084d-41c2-b54e-3a25b2a0a732.denghui.ddh@alibaba-inc.com> Hi Paul, I am not jdk8u committer, could you help me to push it if there is no other problem. Thanks, Denghui Dong ------------------------------------------------------------------ From:Hohensee, Paul Send Time:2019?10?16?(???) 23:28 To:???(??) ; jdk8u-dev Subject:Re: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len I asked for 242 because that?s the 8u release in which the change will be shipped. Looks fine now. Thanks, Paul From: Denghui Dong Reply-To: Denghui Dong Date: Tuesday, October 15, 2019 at 6:51 PM To: jdk8u-dev , "Hohensee, Paul" Subject: Re: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len Hi Paul, Thank you, I upload the amended webrev in http://cr.openjdk.java.net/~ddong/8144732/hotspot.01, By the way, I am not sure the update-version should be used in arguments.cpp, I just use 242 mentioned in your previous mail. Also, I will file an issue to fix the obsoleted version of the other two flags (UseOldInlining and AutoShutdownNMT) later. Thanks Denghui Dong ------------------------------------------------------------------ From:Hohensee, Paul Send Time:2019?10?16?(???) 02:21 To:???(??) ; jdk8u-dev Subject:Re: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len The JBS issue and changeset links you posted are for 8150432, not 8144732, which was confusing. The webrev is for 8144732 though. I can find only two places where your patch is different from the original changeset, net of line numbers/file locations. The rest looks fine. They are: In heapDumper.cpp, there should be only one blank line after the definition of WRITE_ARRAY. In arguments.cpp, the obsolete_jvm_flags entry for SegmentedHeapDumpThreshold was changed to conform to 8u. If you apply the patch and issue java -XX: -XX:SegmentedHeapDumpThreshold=2g you get "OpenJDK 64-Bit Server VM warning: ignoring option AutoShutdownNMT; support was removed in 9.0", which is confusing since we're running 8. But, you get the same message from java -XX: -XX:+AutoShutdownNMT so the problem isn?t unique to this patch, and likely the result of previous backports. For this patch, I'd use { "SegmentedHeapDumpThreshold", JDK_Version::jdk_update(8, 242), JDK_Version::jdk(10) }, It would be great if you would file an issue to fix the other two (there's also UseOldInlining, which doesn't generate a message because it hasn't been removed from c2_globals.hpp, which it should be). Thanks, Paul On 10/9/19, 2:12 AM, "jdk8u-dev on behalf of Denghui Dong" wrote: Hi Team: The previous webrev didn't contain original commit information, so I made a new webrev in http://cr.openjdk.java.net/~ddong/8144732/hotspot.00/ Can you help to review it ? I think it is worth backporting. Thanks Denghui Dong ------------------------------------------------------------------ From:kelthuzadx <1948638989 at qq.com> Send Time:2019?10?7?(???) 10:28 To:???(??) Subject:Re: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len Good job? it ?s necessary to support large heap dump since 8u contains g1gc whose design principle is managing the large heap ------------------ Original ------------------ From: Denghui Dong Date: Sat,Oct 5,2019 10:27 AM To: jdk8u-dev Subject: Re: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len Any comments ? Thanks, Denghui Dong ------------------------------------------------------------------ From:???(??) Send Time:2019?9?25?(???) 16:02 To:jdk8u-dev Subject:Re: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len 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 bourges.laurent at gmail.com Thu Oct 17 16:30:14 2019 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 17 Oct 2019 18:30:14 +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 all, I am almost done, 17/20 patches reviewed: https://raw.githubusercontent.com/bourgesl/marlin-jdk8u/master/marlin-review.txt I will gather also zulu webrevs and my original ones and provide 1 by 1 comparisons on the patched raw outputs, as comparing patch files of the remaining 2 patches is too painful. It becomes necessary to see properly the changes between jdk9+ and 8. Finally the 2 new patches (2019) apply cleanly and I prepared an OpenJDK8u build (dev ie v242) with 21 marlin patches for linux x64: https://github.com/bourgesl/marlin-jdk8u/releases/tag/v0.1 Who can sponsor me (8u reviewer) and help me with the official review process soon ? Cheers, Laurent Le sam. 12 oct. 2019 ? 00:09, Laurent Bourg?s a ?crit : > Hi, > > Here are some news: > > I created a small repository to store zulu patches from Andrew Brygin, > original jdk/jdk extracted patches and their corresponding jdk8 patches > (unshuffled): > https://github.com/bourgesl/marlin-jdk8u > > I am still reviewing patches m01 to m11 are OK = zulu patches are OK by me. > > See https://github.com/bourgesl/marlin-jdk8u/blob/master/marlin-review.txt > > I will go on and officially share all this work once done. > > PS: I applied locally zulu8 patches on my local jdk8u/jdk repository and > it works well: Marlin 0.9.1.1 in action ! > > Cheers, > Laurent > > Le mar. 1 oct. 2019 ? 23:06, Laurent Bourg?s > a ?crit : > >> Hi all, >> >> FYI I started working on the Marlin renderer backport for JDK8u: >> - consolidate the azul zulu patch list with my own bug list (hg log + JBS) >> - retrieve all corresponding patches from jdk/client repository >> - I am reviewing patches (original vs azul) now >> >> I will try automating the integration locally (sed + hg import locally + >> build) to let me test the all process. >> >> Here is my patch list: >> ------------------------------------------------ >> | Marlin renderer patches history (jdk/client) | >> ------------------------------------------------ >> >> * 2015 >> 34419:14108cfd0823 m01.8143849.patch 8143849: Integrate Marlin renderer >> per JEP 265 >> 35979:4462913d471a NEW m01b.8149896.patch 8149896: Remove unnecessary >> values in FloatConsts and DoubleConsts => Merge with m01.8143849.patch >> >> 34689:4b5bf9f960c8 m02.8145055.patch 8145055: Marlin renderer causes >> unaligned write accesses >> 34801:a7740dae1f3a m03.8144630.patch 8144630: Use PrivilegedAction to >> create Thread in Marlin RendererStats >> 34814:09435f7f0013 m04.8144446.patch 8144446: Automate the Marlin crash >> test >> 34815:81e87daa9876 m05.8144445.patch 8144445: Maximum size checking in >> Marlin ArrayCache utility methods is not optimal >> 34422:438c2710ab20 m06.8144526.patch 8144526: Remove Marlin logging use >> of deleted internal API >> 34816:5ff696b1bbac m07.8144654.patch 8144654: Improve Marlin logging >> >> * 2016 >> 35445:86db4c432b19 SKIP 8147443: Use the Common Cleaner in Marlin >> OffHeapArray >> 35645:a96d68e3fda2 m08.8144718.patch 8144718: Pisces / Marlin Strokers >> may generate invalid curves with huge coordinates and round joins >> 35665:e90002447fd5 SKIP 8146076: Fail of >> sun/java2d/marlin/CeilAndFloorTests.java with Jigsaw >> 36446:c06d6e681158 m09.8149338.patch 8149338: JVM Crash caused by Marlin >> renderer not handling NaN coordinates >> 36458:25786a73a5fc m10.8148886.patch 8148886: SEGV in >> sun.java2d.marlin.Renderer._endRendering >> 36902:bb30d89aa00e m11.8144938.patch 8144938: Handle properly coordinate >> overflow in Marlin Renderer >> 39519:21bfc4452441 m12.8159093.patch 8159093: Fix coding conventions in >> Marlin renderer >> 40421:d5ee65e2b0fb m13.8159638.patch 8159638: Improve array caches and >> renderer stats in Marlin renderer >> >> * 2017 >> 47126:188ef162f019 m14.8180055.patch 8180055: Upgrade the Marlin renderer >> in Java2D >> CHECK azul m20.8180055.patch >> 48258:fd7fbc929001 m15.8191814.patch 8191814: Marlin rasterizer spends >> time computing geometry for stroked segments that do not intersect the clip >> >> * 2018 >> 49318:1ea202af7a97 m16.8198885.patch 8198885: upgrade Marlin (java2d) to >> 0.9.1 >> 49524:a38e7ef21cc0 m17.8200526.patch 8200526: Test >> sun/java2d/marlin/ClipShapeTest.java times out >> 50019:793e481c7641 m18.8202580.patch 8202580: Dashed BasicStroke randomly >> painted incorrectly, may freeze application >> 51887:4ec74929fbfe m19.8210335.patch 8210335: Clipping problems with >> complex affine transforms: negative scaling factors or small scaling factors >> >> 2019: >> 55816:13178f7e75d5 NEW m20.8228711.patch 8228711: Path rendered >> incorrectly when it goes outside the clipping region >> 56131:7f55aad34ac4 NEW m21.8230728.patch 8230728: Thin stroked shapes are >> not rendered if affine transform has flip bit >> >> Laurent >> >> Le ven. 20 sept. 2019 ? 10:41, Andrew Brygin a ?crit : >> >>> Hi Laurent, >>> >>> > On Sep 19, 2019, at 11:09 PM, Laurent Bourg?s < >>> bourges.laurent at gmail.com> 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 >> >> From bourges.laurent at gmail.com Thu Oct 17 16:30:14 2019 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 17 Oct 2019 18:30:14 +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 all, I am almost done, 17/20 patches reviewed: https://raw.githubusercontent.com/bourgesl/marlin-jdk8u/master/marlin-review.txt I will gather also zulu webrevs and my original ones and provide 1 by 1 comparisons on the patched raw outputs, as comparing patch files of the remaining 2 patches is too painful. It becomes necessary to see properly the changes between jdk9+ and 8. Finally the 2 new patches (2019) apply cleanly and I prepared an OpenJDK8u build (dev ie v242) with 21 marlin patches for linux x64: https://github.com/bourgesl/marlin-jdk8u/releases/tag/v0.1 Who can sponsor me (8u reviewer) and help me with the official review process soon ? Cheers, Laurent Le sam. 12 oct. 2019 ? 00:09, Laurent Bourg?s a ?crit : > Hi, > > Here are some news: > > I created a small repository to store zulu patches from Andrew Brygin, > original jdk/jdk extracted patches and their corresponding jdk8 patches > (unshuffled): > https://github.com/bourgesl/marlin-jdk8u > > I am still reviewing patches m01 to m11 are OK = zulu patches are OK by me. > > See https://github.com/bourgesl/marlin-jdk8u/blob/master/marlin-review.txt > > I will go on and officially share all this work once done. > > PS: I applied locally zulu8 patches on my local jdk8u/jdk repository and > it works well: Marlin 0.9.1.1 in action ! > > Cheers, > Laurent > > Le mar. 1 oct. 2019 ? 23:06, Laurent Bourg?s > a ?crit : > >> Hi all, >> >> FYI I started working on the Marlin renderer backport for JDK8u: >> - consolidate the azul zulu patch list with my own bug list (hg log + JBS) >> - retrieve all corresponding patches from jdk/client repository >> - I am reviewing patches (original vs azul) now >> >> I will try automating the integration locally (sed + hg import locally + >> build) to let me test the all process. >> >> Here is my patch list: >> ------------------------------------------------ >> | Marlin renderer patches history (jdk/client) | >> ------------------------------------------------ >> >> * 2015 >> 34419:14108cfd0823 m01.8143849.patch 8143849: Integrate Marlin renderer >> per JEP 265 >> 35979:4462913d471a NEW m01b.8149896.patch 8149896: Remove unnecessary >> values in FloatConsts and DoubleConsts => Merge with m01.8143849.patch >> >> 34689:4b5bf9f960c8 m02.8145055.patch 8145055: Marlin renderer causes >> unaligned write accesses >> 34801:a7740dae1f3a m03.8144630.patch 8144630: Use PrivilegedAction to >> create Thread in Marlin RendererStats >> 34814:09435f7f0013 m04.8144446.patch 8144446: Automate the Marlin crash >> test >> 34815:81e87daa9876 m05.8144445.patch 8144445: Maximum size checking in >> Marlin ArrayCache utility methods is not optimal >> 34422:438c2710ab20 m06.8144526.patch 8144526: Remove Marlin logging use >> of deleted internal API >> 34816:5ff696b1bbac m07.8144654.patch 8144654: Improve Marlin logging >> >> * 2016 >> 35445:86db4c432b19 SKIP 8147443: Use the Common Cleaner in Marlin >> OffHeapArray >> 35645:a96d68e3fda2 m08.8144718.patch 8144718: Pisces / Marlin Strokers >> may generate invalid curves with huge coordinates and round joins >> 35665:e90002447fd5 SKIP 8146076: Fail of >> sun/java2d/marlin/CeilAndFloorTests.java with Jigsaw >> 36446:c06d6e681158 m09.8149338.patch 8149338: JVM Crash caused by Marlin >> renderer not handling NaN coordinates >> 36458:25786a73a5fc m10.8148886.patch 8148886: SEGV in >> sun.java2d.marlin.Renderer._endRendering >> 36902:bb30d89aa00e m11.8144938.patch 8144938: Handle properly coordinate >> overflow in Marlin Renderer >> 39519:21bfc4452441 m12.8159093.patch 8159093: Fix coding conventions in >> Marlin renderer >> 40421:d5ee65e2b0fb m13.8159638.patch 8159638: Improve array caches and >> renderer stats in Marlin renderer >> >> * 2017 >> 47126:188ef162f019 m14.8180055.patch 8180055: Upgrade the Marlin renderer >> in Java2D >> CHECK azul m20.8180055.patch >> 48258:fd7fbc929001 m15.8191814.patch 8191814: Marlin rasterizer spends >> time computing geometry for stroked segments that do not intersect the clip >> >> * 2018 >> 49318:1ea202af7a97 m16.8198885.patch 8198885: upgrade Marlin (java2d) to >> 0.9.1 >> 49524:a38e7ef21cc0 m17.8200526.patch 8200526: Test >> sun/java2d/marlin/ClipShapeTest.java times out >> 50019:793e481c7641 m18.8202580.patch 8202580: Dashed BasicStroke randomly >> painted incorrectly, may freeze application >> 51887:4ec74929fbfe m19.8210335.patch 8210335: Clipping problems with >> complex affine transforms: negative scaling factors or small scaling factors >> >> 2019: >> 55816:13178f7e75d5 NEW m20.8228711.patch 8228711: Path rendered >> incorrectly when it goes outside the clipping region >> 56131:7f55aad34ac4 NEW m21.8230728.patch 8230728: Thin stroked shapes are >> not rendered if affine transform has flip bit >> >> Laurent >> >> Le ven. 20 sept. 2019 ? 10:41, Andrew Brygin a ?crit : >> >>> Hi Laurent, >>> >>> > On Sep 19, 2019, at 11:09 PM, Laurent Bourg?s < >>> bourges.laurent at gmail.com> 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 >> >> From johnc at azul.com Thu Oct 17 18:11:18 2019 From: johnc at azul.com (John Cuthbertson) Date: Thu, 17 Oct 2019 18:11:18 +0000 Subject: [8u] RFR (S): Backport: JDK-8048556: Unnecessary GCLocker-initiated young GCs In-Reply-To: <225B03D6-D4CA-4DEC-84BC-29FE50B74D9B@azul.com> References: <225B03D6-D4CA-4DEC-84BC-29FE50B74D9B@azul.com> Message-ID: <36D1ACBF-72F1-406E-8008-763F2903E9DE@azul.com> Hi Everyone, New webrev at http://cr.openjdk.java.net/~johnc/8048556/webrev.01/ I went back and forth about whether to assert that setting the _full attribute using the max generation level matched the cause but decided to take the assert out to keep the change much closer to the original patch. Retested using the modified version of Kim?s test and TonyP?s test. Thanks, JohnC On Oct 15, 2019, at 12:16 PM, John Cuthbertson > wrote: Hi Everyone, I?d like to contribute a back port of the changes for JDK-8048556 to jdk8u-dev/hotspot. You can find the webrev at http://cr.openjdk.java.net/~johnc/8048556/webrev.00/. Please bare with me since it?s been a long time since I contributed to OpenJDK. I apologize for any mis-steps in advance. Andrew has said in email that he has/had added jdk8u-fix-request label to the bug entry. As you would expect the import did not apply cleanly ? mostly because of different paths so a lot had to manually back ported. The main places that needed some hand massaging were: * minor tweaks to the comments in g1CollectedHeap.cpp and genCollectedHeap.cpp, * setting the _full attribute in the VM_GenCollectFull operation (I suppose I should have followed the coding model in vmPSOperations.cpp and added a static is_cause_full() helper routine ? I can do that if people wish), * changing Kim?s test to use GC MXBeans and output Before GC Eden information in a test local format along with some message if the Eden use was below or above 40% of max/committed and have the test grep for the bad message. I also manually tested using Tony P?s second test that was attached to the bug entry with the following combinations of options: ("-XX:+UseParNewGC" "-XX:+UseSerialGC" "-XX:+UseParallelGC" "-XX:+UseConcMarkSweepGC" "-XX:+UseG1GC" "-XX:+UseParallelGC -XX:+UseParallelOldGC" "-XX:+UseConcMarkSweepGC -XX:-UseParNewGC" "-XX:+UseConcMarkSweepGC -XX:+GCLockerInvokesConcurrent" "-XX:+UseG1GC -XX:+GCLockerInvokesConcurrent?) Please note that since CMS and G1 with -XX:+GCLockerInvokesConcurrent does not drop GCLocker initiated GCs we can still see GCs with under utilized Edens with these combinations. Once everything looks OK I think I?ll have to have someone else from Azul push the actual change. Thanks John Cuthbertson From hohensee at amazon.com Thu Oct 17 20:02:50 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 17 Oct 2019 20:02:50 +0000 Subject: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len In-Reply-To: <9bb6cdf9-084d-41c2-b54e-3a25b2a0a732.denghui.ddh@alibaba-inc.com> References: <1F597219-BD21-4ABD-806F-AF7B8B2F2638@amazon.com> <1d01ff0c-aa5b-4c3d-8225-1ee76c7b564c.denghui.ddh@alibaba-inc.com> <9bb6cdf9-084d-41c2-b54e-3a25b2a0a732.denghui.ddh@alibaba-inc.com> Message-ID: <97E45B70-CE90-4872-92D0-B53F803163CB@amazon.com> Sure, I?ll sponsor your patch. Paul From: Denghui Dong Reply-To: Denghui Dong Date: Thursday, October 17, 2019 at 6:38 AM To: jdk8u-dev , "Hohensee, Paul" Subject: Re: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len Hi Paul, I am not jdk8u committer, could you help me to push it if there is no other problem. Thanks, Denghui Dong ------------------------------------------------------------------ From:Hohensee, Paul Send Time:2019?10?16?(???) 23:28 To:???(??) ; jdk8u-dev Subject:Re: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len I asked for 242 because that?s the 8u release in which the change will be shipped. Looks fine now. Thanks, Paul From: Denghui Dong Reply-To: Denghui Dong Date: Tuesday, October 15, 2019 at 6:51 PM To: jdk8u-dev , "Hohensee, Paul" Subject: Re: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len Hi Paul, Thank you, I upload the amended webrev in http://cr.openjdk.java.net/~ddong/8144732/hotspot.01, By the way, I am not sure the update-version should be used in arguments.cpp, I just use 242 mentioned in your previous mail. Also, I will file an issue to fix the obsoleted version of the other two flags (UseOldInlining and AutoShutdownNMT) later. Thanks Denghui Dong ------------------------------------------------------------------ From:Hohensee, Paul Send Time:2019?10?16?(???) 02:21 To:???(??) ; jdk8u-dev Subject:Re: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len The JBS issue and changeset links you posted are for 8150432, not 8144732, which was confusing. The webrev is for 8144732 though. I can find only two places where your patch is different from the original changeset, net of line numbers/file locations. The rest looks fine. They are: In heapDumper.cpp, there should be only one blank line after the definition of WRITE_ARRAY. In arguments.cpp, the obsolete_jvm_flags entry for SegmentedHeapDumpThreshold was changed to conform to 8u. If you apply the patch and issue java -XX: -XX:SegmentedHeapDumpThreshold=2g you get "OpenJDK 64-Bit Server VM warning: ignoring option AutoShutdownNMT; support was removed in 9.0", which is confusing since we're running 8. But, you get the same message from java -XX: -XX:+AutoShutdownNMT so the problem isn?t unique to this patch, and likely the result of previous backports. For this patch, I'd use { "SegmentedHeapDumpThreshold", JDK_Version::jdk_update(8, 242), JDK_Version::jdk(10) }, It would be great if you would file an issue to fix the other two (there's also UseOldInlining, which doesn't generate a message because it hasn't been removed from c2_globals.hpp, which it should be). Thanks, Paul On 10/9/19, 2:12 AM, "jdk8u-dev on behalf of Denghui Dong" wrote: Hi Team: The previous webrev didn't contain original commit information, so I made a new webrev in http://cr.openjdk.java.net/~ddong/8144732/hotspot.00/ Can you help to review it ? I think it is worth backporting. Thanks Denghui Dong ------------------------------------------------------------------ From:kelthuzadx <1948638989 at qq.com> Send Time:2019?10?7?(???) 10:28 To:???(??) Subject:Re: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len Good job? it ?s necessary to support large heap dump since 8u contains g1gc whose design principle is managing the large heap ------------------ Original ------------------ From: Denghui Dong Date: Sat,Oct 5,2019 10:27 AM To: jdk8u-dev Subject: Re: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len Any comments ? Thanks, Denghui Dong ------------------------------------------------------------------ From:???(??) Send Time:2019?9?25?(???) 16:02 To:jdk8u-dev Subject:Re: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len 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 alvdavi at amazon.com Fri Oct 18 00:42:38 2019 From: alvdavi at amazon.com (David Alvarez) Date: Thu, 17 Oct 2019 17:42:38 -0700 Subject: [8u] RFR: Backport of JDK-8146238: [macosx] Java2D Queue Flusher crash on OSX after switching between user accounts Message-ID: Hello Everyone, I would like to request a review for JDK-8146238, recently added by Oracle to 8u232 as a BPR. JBS Issue: https://bugs.openjdk.java.net/browse/JDK-8146238 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/07556f8cd819 Webrev: http://cr.openjdk.java.net/~alvdavi/webrevs/8146238/webrev.8u.00/ Besides the usual quirks, patch did not apply clean due to jdk8u not having JDK-7188942: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/d278d6b53fcb Not having this patch caused some changes in the context, but nothing more. Additionally, src/windows/native/sun/java2d/opengl/WGLSurfaceData.c required moving some variables to the top of the method declaration to avoid breaking the build on old versions of Visual Studio. The patch has passed Tier1 and Tier2 in macosx, linux and windows (x64 for all of them). No new regressions were found. Thanks, David From akozlov at azul.com Fri Oct 18 12:14:38 2019 From: akozlov at azul.com (Anton Kozlov) Date: Fri, 18 Oct 2019 15:14:38 +0300 Subject: [8u] RFR: JDK-8231584: Deadlock with ClassLoader.findLibrary and System.loadLibrary call In-Reply-To: <7DC7CFE1-6A83-44D3-9A87-876B2B9F7228@amazon.com> References: <526e3855-d43a-f353-0894-5419773e1e11@azul.com> <7DC7CFE1-6A83-44D3-9A87-876B2B9F7228@amazon.com> Message-ID: <04281d1c-ae7d-6a64-527e-ffee19da8a30@azul.com> On 17.10.2019 14:45, Andrew Dinn wrote: > backport looks good. On 16.10.2019 22:26, Hohensee, Paul wrote: > Your backport looks good to me Thank you for reviews! I'm going to add backport request labels later. A comment in jdk/jdk bug [1] appeared. It suggests to wait a bit before backporting it anywhere, to let the patch be evaluated for some time. And that's reasonable. > One tiny nit: in Runtime.java, the 14 patch changed the indentation of the line containing "Directory separator should not appear in library name: " I got in webrev.ksh pitfall: it doesn't include white-space changes in fancy view by default. The actual patch have the indentation change. Regenerated webrev with indentation: http://cr.openjdk.java.net/~akozlov/8231584/u8.webrev.01/ Thanks, Anton [1]: https://bugs.openjdk.java.net/browse/JDK-8231584?focusedCommentId=14294841&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14294841 From hohensee at amazon.com Fri Oct 18 13:59:21 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 18 Oct 2019 13:59:21 +0000 Subject: [8u] RFR (S): Backport: JDK-8048556: Unnecessary GCLocker-initiated young GCs In-Reply-To: <36D1ACBF-72F1-406E-8008-763F2903E9DE@azul.com> References: <225B03D6-D4CA-4DEC-84BC-29FE50B74D9B@azul.com> <36D1ACBF-72F1-406E-8008-763F2903E9DE@azul.com> Message-ID: <38CCF6AD-D195-4E50-B85B-4F3A14020674@amazon.com> Looks good. My previous comment on the test was misinformed: the one in the 14 patch depends on unified logging output, so can't be used as is. Thanks, Paul ?On 10/17/19, 11:11 AM, "jdk8u-dev on behalf of John Cuthbertson" wrote: Hi Everyone, New webrev at http://cr.openjdk.java.net/~johnc/8048556/webrev.01/ I went back and forth about whether to assert that setting the _full attribute using the max generation level matched the cause but decided to take the assert out to keep the change much closer to the original patch. Retested using the modified version of Kim?s test and TonyP?s test. Thanks, JohnC On Oct 15, 2019, at 12:16 PM, John Cuthbertson > wrote: Hi Everyone, I?d like to contribute a back port of the changes for JDK-8048556 to jdk8u-dev/hotspot. You can find the webrev at http://cr.openjdk.java.net/~johnc/8048556/webrev.00/. Please bare with me since it?s been a long time since I contributed to OpenJDK. I apologize for any mis-steps in advance. Andrew has said in email that he has/had added jdk8u-fix-request label to the bug entry. As you would expect the import did not apply cleanly ? mostly because of different paths so a lot had to manually back ported. The main places that needed some hand massaging were: * minor tweaks to the comments in g1CollectedHeap.cpp and genCollectedHeap.cpp, * setting the _full attribute in the VM_GenCollectFull operation (I suppose I should have followed the coding model in vmPSOperations.cpp and added a static is_cause_full() helper routine ? I can do that if people wish), * changing Kim?s test to use GC MXBeans and output Before GC Eden information in a test local format along with some message if the Eden use was below or above 40% of max/committed and have the test grep for the bad message. I also manually tested using Tony P?s second test that was attached to the bug entry with the following combinations of options: ("-XX:+UseParNewGC" "-XX:+UseSerialGC" "-XX:+UseParallelGC" "-XX:+UseConcMarkSweepGC" "-XX:+UseG1GC" "-XX:+UseParallelGC -XX:+UseParallelOldGC" "-XX:+UseConcMarkSweepGC -XX:-UseParNewGC" "-XX:+UseConcMarkSweepGC -XX:+GCLockerInvokesConcurrent" "-XX:+UseG1GC -XX:+GCLockerInvokesConcurrent?) Please note that since CMS and G1 with -XX:+GCLockerInvokesConcurrent does not drop GCLocker initiated GCs we can still see GCs with under utilized Edens with these combinations. Once everything looks OK I think I?ll have to have someone else from Azul push the actual change. Thanks John Cuthbertson From hohensee at amazon.com Fri Oct 18 14:06:46 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 18 Oct 2019 14:06:46 +0000 Subject: [8u] RFR: JDK-8231584: Deadlock with ClassLoader.findLibrary and System.loadLibrary call In-Reply-To: <04281d1c-ae7d-6a64-527e-ffee19da8a30@azul.com> References: <526e3855-d43a-f353-0894-5419773e1e11@azul.com> <7DC7CFE1-6A83-44D3-9A87-876B2B9F7228@amazon.com> <04281d1c-ae7d-6a64-527e-ffee19da8a30@azul.com> Message-ID: <4168DCF3-C1C2-4C6A-BBC2-07DAA8FAEF22@amazon.com> Thanks, Anton, for fixing the nit. :) As for when to push, 14 doesn't ship until March, but will get a lot of testing by Oracle and others (e.g., Adopt) before then. It'd be good to get your backport into 8u242 for January. Paul ?On 10/18/19, 5:15 AM, "Anton Kozlov" wrote: On 17.10.2019 14:45, Andrew Dinn wrote: > backport looks good. On 16.10.2019 22:26, Hohensee, Paul wrote: > Your backport looks good to me Thank you for reviews! I'm going to add backport request labels later. A comment in jdk/jdk bug [1] appeared. It suggests to wait a bit before backporting it anywhere, to let the patch be evaluated for some time. And that's reasonable. > One tiny nit: in Runtime.java, the 14 patch changed the indentation of the line containing "Directory separator should not appear in library name: " I got in webrev.ksh pitfall: it doesn't include white-space changes in fancy view by default. The actual patch have the indentation change. Regenerated webrev with indentation: http://cr.openjdk.java.net/~akozlov/8231584/u8.webrev.01/ Thanks, Anton [1]: https://bugs.openjdk.java.net/browse/JDK-8231584?focusedCommentId=14294841&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14294841 From hohensee at amazon.com Fri Oct 18 15:17:13 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 18 Oct 2019 15:17:13 +0000 Subject: [8u] RFR: Backport of JDK-8146238: [macosx] Java2D Queue Flusher crash on OSX after switching between user accounts In-Reply-To: References: Message-ID: <9DE88C0D-9869-4747-9BD6-DC7B6567B6EB@amazon.com> Looks good. Paul ?On 10/17/19, 5:43 PM, "jdk8u-dev on behalf of David Alvarez" wrote: Hello Everyone, I would like to request a review for JDK-8146238, recently added by Oracle to 8u232 as a BPR. JBS Issue: https://bugs.openjdk.java.net/browse/JDK-8146238 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/07556f8cd819 Webrev: http://cr.openjdk.java.net/~alvdavi/webrevs/8146238/webrev.8u.00/ Besides the usual quirks, patch did not apply clean due to jdk8u not having JDK-7188942: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/d278d6b53fcb Not having this patch caused some changes in the context, but nothing more. Additionally, src/windows/native/sun/java2d/opengl/WGLSurfaceData.c required moving some variables to the top of the method declaration to avoid breaking the build on old versions of Visual Studio. The patch has passed Tier1 and Tier2 in macosx, linux and windows (x64 for all of them). No new regressions were found. Thanks, David From hohensee at amazon.com Fri Oct 18 15:21:33 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 18 Oct 2019 15:21:33 +0000 Subject: [8u] RFR 8208715: Conversion of milliseconds to nanoseconds in UNIXProcess contains bug In-Reply-To: <854ACCAE-598E-471A-AFD8-B0E1D74087F6@amazon.com> References: <029E8BC0-B1BC-4FED-97CA-6763D2138E36@amazon.com> <854ACCAE-598E-471A-AFD8-B0E1D74087F6@amazon.com> Message-ID: <322C3C9A-85B5-49D9-9D81-3DF956587C7B@amazon.com> Ping again, please. Thanks, Paul ?On 9/25/19, 5:59 PM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: 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 johnc at azul.com Fri Oct 18 21:03:38 2019 From: johnc at azul.com (John Cuthbertson) Date: Fri, 18 Oct 2019 21:03:38 +0000 Subject: [8u] RFR (S): Backport: JDK-8048556: Unnecessary GCLocker-initiated young GCs In-Reply-To: <38CCF6AD-D195-4E50-B85B-4F3A14020674@amazon.com> References: <225B03D6-D4CA-4DEC-84BC-29FE50B74D9B@azul.com> <36D1ACBF-72F1-406E-8008-763F2903E9DE@azul.com> <38CCF6AD-D195-4E50-B85B-4F3A14020674@amazon.com> Message-ID: <8C019389-ED70-4C19-A0E2-65A688E99809@azul.com> Thanks Paul. JohnC > On Oct 18, 2019, at 6:59 AM, Hohensee, Paul wrote: > > Looks good. My previous comment on the test was misinformed: the one in the 14 patch depends on unified logging output, so can't be used as is. > > Thanks, > > Paul > > ?On 10/17/19, 11:11 AM, "jdk8u-dev on behalf of John Cuthbertson" wrote: > > Hi Everyone, > > New webrev at http://cr.openjdk.java.net/~johnc/8048556/webrev.01/ > > I went back and forth about whether to assert that setting the _full attribute using the max generation level matched the cause but decided to take the assert out to keep the change much closer to the original patch. > > Retested using the modified version of Kim?s test and TonyP?s test. > > Thanks, > > JohnC > > On Oct 15, 2019, at 12:16 PM, John Cuthbertson > wrote: > > Hi Everyone, > > I?d like to contribute a back port of the changes for JDK-8048556 to jdk8u-dev/hotspot. You can find the webrev at http://cr.openjdk.java.net/~johnc/8048556/webrev.00/. > > Please bare with me since it?s been a long time since I contributed to OpenJDK. I apologize for any mis-steps in advance. Andrew has said in email that he has/had added jdk8u-fix-request label to the bug entry. > > As you would expect the import did not apply cleanly ? mostly because of different paths so a lot had to manually back ported. The main places that needed some hand massaging were: > > * minor tweaks to the comments in g1CollectedHeap.cpp and genCollectedHeap.cpp, > * setting the _full attribute in the VM_GenCollectFull operation (I suppose I should have followed the coding model in vmPSOperations.cpp and added a static is_cause_full() helper routine ? I can do that if people wish), > * changing Kim?s test to use GC MXBeans and output Before GC Eden information in a test local format along with some message if the Eden use was below or above 40% of max/committed and have the test grep for the bad message. > > I also manually tested using Tony P?s second test that was attached to the bug entry with the following combinations of options: > > ("-XX:+UseParNewGC" > "-XX:+UseSerialGC" > "-XX:+UseParallelGC" > "-XX:+UseConcMarkSweepGC" > "-XX:+UseG1GC" > "-XX:+UseParallelGC -XX:+UseParallelOldGC" > "-XX:+UseConcMarkSweepGC -XX:-UseParNewGC" > "-XX:+UseConcMarkSweepGC -XX:+GCLockerInvokesConcurrent" > "-XX:+UseG1GC -XX:+GCLockerInvokesConcurrent?) > > Please note that since CMS and G1 with -XX:+GCLockerInvokesConcurrent does not drop GCLocker initiated GCs we can still see GCs with under utilized Edens with these combinations. > > Once everything looks OK I think I?ll have to have someone else from Azul push the actual change. > > Thanks > > John Cuthbertson > > > > > From martinrb at google.com Sat Oct 19 13:56:55 2019 From: martinrb at google.com (Martin Buchholz) Date: Sat, 19 Oct 2019 06:56:55 -0700 Subject: [8u] RFR 8208715: Conversion of milliseconds to nanoseconds in UNIXProcess contains bug In-Reply-To: <854ACCAE-598E-471A-AFD8-B0E1D74087F6@amazon.com> References: <029E8BC0-B1BC-4FED-97CA-6763D2138E36@amazon.com> <854ACCAE-598E-471A-AFD8-B0E1D74087F6@amazon.com> Message-ID: On Wed, Sep 25, 2019 at 5:58 PM Hohensee, Paul wrote: > Ping (it's been nearly a month :)). > > I posted an updated webrev at > > http://cr.openjdk.java.net/~phh/8208715/webrev.00/ This backport Looks Good To Me. I did notice one gratuitous difference. https://hg.openjdk.java.net/jdk/jdk/rev/41257a58a588 The original change deleted this line: - // Round up to next millisecond but the backport failed to do the same. I would fix that. From rkennke at redhat.com Mon Oct 21 13:45:26 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 21 Oct 2019 15:45:26 +0200 Subject: RFR: 8213325: (props) Properties.loadFromXML does not fully comply with the spec In-Reply-To: <465b5374-b539-164a-9fcb-7789c77212c5@redhat.com> References: <1d0a8a5d-3467-99ed-3dff-187b70ea95fa@redhat.com> <465b5374-b539-164a-9fcb-7789c77212c5@redhat.com> Message-ID: <9e6ecbaa-b5b0-8cc9-0aaf-f23b1015ec2b@redhat.com> (adding core-libs-dev) Ping? > I just realized that this has still not been reviewed. Can I do anything > to move forward? > > Thanks, > Roman > >> I added one extra verification to the JAXP based properties parser to >> verify that no extra internal DTD is being supplied. As far as I can >> tell, the other checks that have been added to the ukit parser for this >> bug are already done by the JAXP parser, by validating the XML against >> the built-in DTD. >> >> Webrev: >> http://cr.openjdk.java.net/~rkennke/JDK-8213325/webrev.01/ >> >> This passes all relevant tests, and I also run tier1 w/o regressions. >> >> What do you think? >> >> Roman >> >>> This is a backport of: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8227274 >>> >>> which is a backport of the original: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8213325 >>> >>> It's mostly the original change with a few significant extra modifications: >>> >>> - >>> src/share/classes/sun/util/xml/META-INF/services/sun.util.spi.XmlPropertiesProvider >>> >>> is changed from: >>> sun.util.xml.PlatformXmlPropertiesProvider >>> >>> to: >>> jdk.internal.util.xml.BasicXmlPropertiesProvider >>> >>> The reason is that the fix is for the latter, but 8u uses the former by >>> default. As far as I understand, the latter uses the new slimmer parser, >>> while the former uses the fullblown XML parser, but I am not sure about >>> that. However, we need to consider this, because it might be a very >>> significant change. >>> >>> The alternative would be to port over the fixes to the other XML parser, >>> which I have no desire to do. >>> >>> - The (test) JAR file: >>> test/java/util/spi/ResourceBundleControlProvider/rbcontrolprovider.jar >>> >>> has been regenerated from the modified sources XmlRB.xml and XmlRB_ja.xml. >>> >>> This is not present in jdk11 and later. I think it's generated on the >>> fly and not checked-in. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rkennke/JDK-8213325/webrev.00/ >>> >>> Testing: New testcases are passing. No regressions in tier1 tests. >>> >>> Opinions? Can I get reviews? >>> >>> Thanks, >>> Roman >>> >> > From rkennke at redhat.com Mon Oct 21 13:48:16 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 21 Oct 2019 15:48:16 +0200 Subject: Backport: 8216549: Mismatched unsafe access to non escaping object fails In-Reply-To: References: <03C8C56B-A75C-40F2-8E9B-471414DDD5D9@amazon.com> <5a5259ba-4754-ee16-3998-f98c7703fdea@redhat.com> <573A0B31-A7A7-40A6-BE61-713A685F9939@amazon.com> Message-ID: <739f5165-6aca-efc3-b06d-5c68f3966b54@redhat.com> Ping? What do you think? Roman > Hi Paul, > >> Something of a nit: most of 8162101 is indeed in 8u :), but the change at line 1.42/1.43 >> >> - } else if (alias_type->adr_type() == TypeOopPtr::BOTTOM) { >> + } else if (alias_type->adr_type()->isa_oopptr()) { >> >> is missing because the test wasn't already there. > > Right. > > I tried backporting JDK-8160360, but the problem there is similar: in > order to be a clean-ish backport, it requires a couple of other changes > first. That's a rat's tail of (unrelated/unimportant) stuff to backport > just for those two lines. Instead, I'd rather opt to include the above 2 > lines (which are essentially completing the JDK-8162101 backport) instead. > > Roman > > > > >> Thanks, >> >> Paul >> >> ?On 10/9/19, 3:07 AM, "Roman Kennke" wrote: >> >> Hi Paul, >> >> Thanks for checking it! >> >> > The code in library_call.cpp comes seems to come from two patches >> > >> > https://bugs.openjdk.java.net/browse/JDK-8160360 >> > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/4be0cada20ad >> >> I will look into backporting this change. >> >> > https://bugs.openjdk.java.net/browse/JDK-8162101 >> > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/10dad1d40843 >> >> This is already in jdk8u: >> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/7ca49bca3c2a >> >> Roman >> >> >> >> > I'd backport those first. >> > >> > Paul >> > >> > ?On 10/7/19, 11:31 AM, "jdk8u-dev on behalf of Roman Kennke" wrote: >> > >> > Ping! This is still awaiting review. >> > >> > Thanks, >> > Roman >> > >> > >> > > This backports: >> > > https://bugs.openjdk.java.net/browse/JDK-8216549 >> > > >> > > Original change: >> > > hg.openjdk.java.net/jdk/jdk12/rev/f0490430ef7a >> > > >> > > JDK11u backport: >> > > http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/d5fb6ad4203b >> > > >> > > In order to make it work on 8u, I needed the extra change in >> > > library_call.cpp. Thanks Roland who helped with this. >> > > >> > > Webrev: >> > > http://cr.openjdk.java.net/~rkennke/JDK-8216549-8u/webrev.00/ >> > > >> > > Testing: >> > > The new testcase fails without the fix, and passes with the fix. tier1 & >> > > tier2 show no regressions. >> > > >> > > Can I please get a review? >> > > >> > > Thanks, >> > > Roman >> > > >> > >> > >> > >> >> >> > From hohensee at amazon.com Mon Oct 21 15:25:02 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 21 Oct 2019 15:25:02 +0000 Subject: Backport: 8216549: Mismatched unsafe access to non escaping object fails In-Reply-To: <592D8576-CABA-4F05-825C-9C7CFCB69C6F@amazon.com> References: <03C8C56B-A75C-40F2-8E9B-471414DDD5D9@amazon.com> <5a5259ba-4754-ee16-3998-f98c7703fdea@redhat.com> <573A0B31-A7A7-40A6-BE61-713A685F9939@amazon.com> <592D8576-CABA-4F05-825C-9C7CFCB69C6F@amazon.com> Message-ID: Stuff gets lost in mailboxes all the time. :) Paul ?On 10/10/19, 8:55 AM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: We're starting to have a general problem, which is that as the tip code base diverges from the update code base, we're getting more backports that depend on other backports. At some point not doing those other backports is going to cause reliability problems. In this particular case it's pretty obvious we're ok, because as you say, the extra 2 lines are just completing the 8162101 backport. Having to leave out code in a backport such as 8162101 is a sign of a problem: it should have been addressed then. Anyway, this patch is good to go afaic. Thanks, Paul On 10/10/19, 3:19 AM, "Roman Kennke" wrote: Hi Paul, > Something of a nit: most of 8162101 is indeed in 8u :), but the change at line 1.42/1.43 > > - } else if (alias_type->adr_type() == TypeOopPtr::BOTTOM) { > + } else if (alias_type->adr_type()->isa_oopptr()) { > > is missing because the test wasn't already there. Right. I tried backporting JDK-8160360, but the problem there is similar: in order to be a clean-ish backport, it requires a couple of other changes first. That's a rat's tail of (unrelated/unimportant) stuff to backport just for those two lines. Instead, I'd rather opt to include the above 2 lines (which are essentially completing the JDK-8162101 backport) instead. Roman > Thanks, > > Paul > > On 10/9/19, 3:07 AM, "Roman Kennke" wrote: > > Hi Paul, > > Thanks for checking it! > > > The code in library_call.cpp comes seems to come from two patches > > > > https://bugs.openjdk.java.net/browse/JDK-8160360 > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/4be0cada20ad > > I will look into backporting this change. > > > https://bugs.openjdk.java.net/browse/JDK-8162101 > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/10dad1d40843 > > This is already in jdk8u: > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/7ca49bca3c2a > > Roman > > > > > I'd backport those first. > > > > Paul > > > > On 10/7/19, 11:31 AM, "jdk8u-dev on behalf of Roman Kennke" wrote: > > > > Ping! This is still awaiting review. > > > > Thanks, > > Roman > > > > > > > This backports: > > > https://bugs.openjdk.java.net/browse/JDK-8216549 > > > > > > Original change: > > > hg.openjdk.java.net/jdk/jdk12/rev/f0490430ef7a > > > > > > JDK11u backport: > > > http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/d5fb6ad4203b > > > > > > In order to make it work on 8u, I needed the extra change in > > > library_call.cpp. Thanks Roland who helped with this. > > > > > > Webrev: > > > http://cr.openjdk.java.net/~rkennke/JDK-8216549-8u/webrev.00/ > > > > > > Testing: > > > The new testcase fails without the fix, and passes with the fix. tier1 & > > > tier2 show no regressions. > > > > > > Can I please get a review? > > > > > > Thanks, > > > Roman > > > > > > > > > > > > From hohensee at amazon.com Mon Oct 21 16:10:14 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 21 Oct 2019 16:10:14 +0000 Subject: [8u] RFR 8208715: Conversion of milliseconds to nanoseconds in UNIXProcess contains bug In-Reply-To: References: <029E8BC0-B1BC-4FED-97CA-6763D2138E36@amazon.com> <854ACCAE-598E-471A-AFD8-B0E1D74087F6@amazon.com> Message-ID: <12D8376A-1DDB-41E4-8B9E-BC18299DB8BE@amazon.com> Fixed, see http://cr.openjdk.java.net/~phh/8208715/webrev.01/. Thanks for the review! Paul From: Martin Buchholz Date: Saturday, October 19, 2019 at 6:57 AM To: "Hohensee, Paul" Cc: "Guo, James" , "jdk8u-dev at openjdk.java.net" Subject: Re: [8u] RFR 8208715: Conversion of milliseconds to nanoseconds in UNIXProcess contains bug On Wed, Sep 25, 2019 at 5:58 PM Hohensee, Paul > wrote: Ping (it's been nearly a month :)). I posted an updated webrev at http://cr.openjdk.java.net/~phh/8208715/webrev.00/ This backport Looks Good To Me. I did notice one gratuitous difference. https://hg.openjdk.java.net/jdk/jdk/rev/41257a58a588 The original change deleted this line: - // Round up to next millisecond but the backport failed to do the same. I would fix that. From hohensee at amazon.com Mon Oct 21 16:23:42 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 21 Oct 2019 16:23:42 +0000 Subject: RFR(8u): 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: <5CCC5140-4C75-45CD-A3A2-CC0237DD7AD9@azul.com> References: <5CCC5140-4C75-45CD-A3A2-CC0237DD7AD9@azul.com> Message-ID: <7B2B9DF5-F845-42FC-949C-102B72282975@amazon.com> +jdk8u-dev Paul From: nio-dev on behalf of Vladimir Kempik Date: Monday, October 21, 2019 at 2:47 AM To: "nio-dev at openjdk.java.net" Subject: RFR(8u): 8229872: (fs) Increase buffer size used with getmntent Hello Please review backport of https://bugs.openjdk.java.net/browse/JDK-8229872 to 8u: http://cr.openjdk.java.net/~vkempik/8229872/ojdk8/webrev.00/ Difference between 14/13/11 fix: getline is missing on solaris10, so getlinelen method was moved from UnixNativeDispatcher to LinuxNativeDispatcher. Original fix: https://hg.openjdk.java.net/jdk/jdk/rev/2d40e6a7ce8e Such fix was already included into azul?s october psu for openjdk8 and passed all release cycle tests. Thanks, Vladimir From denghui.ddh at alibaba-inc.com Tue Oct 22 13:08:08 2019 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Tue, 22 Oct 2019 21:08:08 +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 all, Please review this backports ( http://cr.openjdk.java.net/~ddong/8227605/hotspot.00/ ) for: 8227605: Kitchensink fails "assert((((klass)->trace_id() & (JfrTraceIdEpoch::leakp_in_use_this_epoch_bit())) != 0)) failed: invariant" Original bug: https://bugs.openjdk.java.net/browse/JDK-8227605 Original patch: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/804a23905c3e Please help me to push it to jdk8u-jfr-incubator if you think it's ok. Cheers Denghui Dong ------------------------------------------------------------------ From:Mario Torre Send Time:2019?10?10?(???) 19:33 To:???(??) Cc:"Jaroslav Bachor?k" ; jdk8u-dev ; Andrey Petushkov Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 Right, makes sense. Ok to push. Cheers, Mario On Thu, Oct 10, 2019 at 7:51 AM Denghui Dong wrote: > > Hi, > Those comments were not introduced by this patch, but the original jfr patch just as Andrey said. > It's necessary to confirm those comments are correct, I think we can do this task later and create a new jira issue to track it. > What's your comments ? > > Cheers > Denghui Dong > > ------------------------------------------------------------------ > From:Andrey Petushkov > Send Time:2019?10?10?(???) 01:14 > To:"Jaroslav Bachor?k" ; ???(??) ; jdk8u-dev > Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 > > Hi Denghui, All, > > The patch looks good for me as well. > Regarding those XXX, in fact none of them were introduced by Denghui. Instead they are coming from current > incubator code and in fact it's deed of mine, sorry for that. They indicate a few places where I was a tiny bit > hesitant making changes to original (jdk11) JFR implementation. As such it would be nice if someone could review > them for correctness before removal > > Thanks, > Andrey > > > On 9 Oct 2019, at 18:23, Jaroslav Bachor?k wrote: > > > > Hi Denghui, > > > > I went through the diff of diffs and as far as I can see the backport is > > correct. But I saw a bunch of comment lines with 'XX' in them. Could you > > clean up those comments before final merge? > > > > Regards, > > > > -JB- > > > > On Wed, Oct 9, 2019 at 10:57 AM Denghui Dong > > wrote: > > > >> Hi all, > >> Please review this backports ( > >> http://cr.openjdk.java.net/~ddong/19-10-9-jfr-backports/hotspot.00/) for: > >> 8214542: JFR: Old Object Sample event slow on a deep heap in debug > >> builds > >> 8228834: Regression caused by JDK-8214542 not installing complete > >> checkpoint data to candidates > >> 8229437: assert(is_aligned(ref, HeapWordSize)) failed: invariant > >> > >> 8214542 is quite a large patch. > >> Please help me to push it to jdk8u-jfr-incubator if you think it's ok. > >> > >> Cheers > >> Denghui Dong > >> ------------------------------------------------------------------ > >> From:Mario Torre > >> Send Time:2019?10?8?(???) 18:16 > >> To:???(??) > >> Cc:jdk8u-dev ; Andrey Petushkov < > >> andrey at azul.com> > >> Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 > >> > >> Hi Denghui, > >> > >> Ok to push to the incubator repository! > >> > >> Cheers, > >> Mario > >> > >> On Fri, Sep 27, 2019 at 8:00 AM Denghui Dong > >> wrote: > >>> > >>> 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 < > >> jdk8u-dev at openjdk.java.net>; 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 < > >> 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 > >>>> > >>> > >> > >> > >> -- > >> 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 martin.doerr at sap.com Tue Oct 22 14:37:09 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 22 Oct 2019 14:37:09 +0000 Subject: [8u] RFR for backport of 8198894 (CRC32 1/4): [PPC64] More generic vector CRC implementation In-Reply-To: <0dc83fcb-4e09-5841-04be-aee615e5a7fd@linux.vnet.ibm.com> References: <0dc83fcb-4e09-5841-04be-aee615e5a7fd@linux.vnet.ibm.com> Message-ID: Hi Gustavo, backport looks good. The parts you have collected from other changes make sense to me. Best regards, Martin > -----Original Message----- > From: Gustavo Romero > Sent: Freitag, 27. September 2019 05:31 > To: hotspot-compiler-dev at openjdk.java.net; Doerr, Martin > > Cc: jdk8u-dev at openjdk.java.net; Michihiro Horie ; > Kazunori Ogata > Subject: [8u] RFR for backport of 8198894 (CRC32 1/4): [PPC64] More generic > vector CRC implementation > > 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 jaroslav.bachorik at datadoghq.com Tue Oct 22 14:52:15 2019 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Tue, 22 Oct 2019 16:52:15 +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: Hi Denghui, is this a clear backport or you had to do any adjustments? -JB- On Tue, Oct 22, 2019 at 3:09 PM Denghui Dong wrote: > Hi all, > Please review this backports ( > http://cr.openjdk.java.net/~ddong/8227605/hotspot.00/ ) for: > 8227605: Kitchensink fails "assert((((klass)->trace_id() & > (JfrTraceIdEpoch::leakp_in_use_this_epoch_bit())) != 0)) failed: invariant" > Original bug: https://bugs.openjdk.java.net/browse/JDK-8227605 > Original patch: > https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/804a23905c3e > Please help me to push it to jdk8u-jfr-incubator if you think it's ok. > > Cheers > Denghui Dong > ------------------------------------------------------------------ > From:Mario Torre > Send Time:2019?10?10?(???) 19:33 > To:???(??) > Cc:"Jaroslav Bachor?k" ; jdk8u-dev < > jdk8u-dev at openjdk.java.net>; Andrey Petushkov > Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 > > Right, makes sense. > > Ok to push. > > Cheers, > Mario > > On Thu, Oct 10, 2019 at 7:51 AM Denghui Dong > wrote: > > > > Hi, > > Those comments were not introduced by this patch, but the original > jfr patch just as Andrey said. > > It's necessary to confirm those comments are correct, I think we can > do this task later and create a new jira issue to track it. > > What's your comments ? > > > > Cheers > > Denghui Dong > > > > ------------------------------------------------------------------ > > From:Andrey Petushkov > > Send Time:2019?10?10?(???) 01:14 > > To:"Jaroslav Bachor?k" ; ???(??) < > denghui.ddh at alibaba-inc.com>; jdk8u-dev > > Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 > > > > Hi Denghui, All, > > > > The patch looks good for me as well. > > Regarding those XXX, in fact none of them were introduced by Denghui. > Instead they are coming from current > > incubator code and in fact it's deed of mine, sorry for that. They > indicate a few places where I was a tiny bit > > hesitant making changes to original (jdk11) JFR implementation. As such > it would be nice if someone could review > > them for correctness before removal > > > > Thanks, > > Andrey > > > > > On 9 Oct 2019, at 18:23, Jaroslav Bachor?k < > jaroslav.bachorik at datadoghq.com> wrote: > > > > > > Hi Denghui, > > > > > > I went through the diff of diffs and as far as I can see the backport > is > > > correct. But I saw a bunch of comment lines with 'XX' in them. Could > you > > > clean up those comments before final merge? > > > > > > Regards, > > > > > > -JB- > > > > > > On Wed, Oct 9, 2019 at 10:57 AM Denghui Dong < > denghui.ddh at alibaba-inc.com> > > > wrote: > > > > > >> Hi all, > > >> Please review this backports ( > > >> http://cr.openjdk.java.net/~ddong/19-10-9-jfr-backports/hotspot.00/) > for: > > >> 8214542: JFR: Old Object Sample event slow on a deep heap in debug > > >> builds > > >> 8228834: Regression caused by JDK-8214542 not installing complete > > >> checkpoint data to candidates > > >> 8229437: assert(is_aligned(ref, HeapWordSize)) failed: invariant > > >> > > >> 8214542 is quite a large patch. > > >> Please help me to push it to jdk8u-jfr-incubator if you think it's > ok. > > >> > > >> Cheers > > >> Denghui Dong > > >> ------------------------------------------------------------------ > > >> From:Mario Torre > > >> Send Time:2019?10?8?(???) 18:16 > > >> To:???(??) > > >> Cc:jdk8u-dev ; Andrey Petushkov < > > >> andrey at azul.com> > > >> Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 > > >> > > >> Hi Denghui, > > >> > > >> Ok to push to the incubator repository! > > >> > > >> Cheers, > > >> Mario > > >> > > >> On Fri, Sep 27, 2019 at 8:00 AM Denghui Dong > > >> wrote: > > >>> > > >>> 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 < > > >> jdk8u-dev at openjdk.java.net>; 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 < > > >> 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 > > >>>> > > >>> > > >> > > >> > > >> -- > > >> 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 Wed Oct 23 01:46:58 2019 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Wed, 23 Oct 2019 09:46:58 +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: <253b1d97-8d79-481f-ae97-327e37dd0a57.denghui.ddh@alibaba-inc.com> Hi JB, Yes, it's a clear backport. Thanks, Denghui Dong ------------------------------------------------------------------ From:Jaroslav Bachor?k Send Time:2019?10?22?(???) 22:52 To:???(??) Cc:jdk8u-dev Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 Hi Denghui, is this a clear backport or you had to do any adjustments? -JB- On Tue, Oct 22, 2019 at 3:09 PM Denghui Dong wrote: Hi all, Please review this backports ( http://cr.openjdk.java.net/~ddong/8227605/hotspot.00/ ) for: 8227605: Kitchensink fails "assert((((klass)->trace_id() & (JfrTraceIdEpoch::leakp_in_use_this_epoch_bit())) != 0)) failed: invariant" Original bug: https://bugs.openjdk.java.net/browse/JDK-8227605 Original patch: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/804a23905c3e Please help me to push it to jdk8u-jfr-incubator if you think it's ok. Cheers Denghui Dong ------------------------------------------------------------------ From:Mario Torre Send Time:2019?10?10?(???) 19:33 To:???(??) Cc:"Jaroslav Bachor?k" ; jdk8u-dev ; Andrey Petushkov Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 Right, makes sense. Ok to push. Cheers, Mario On Thu, Oct 10, 2019 at 7:51 AM Denghui Dong wrote: > > Hi, > Those comments were not introduced by this patch, but the original jfr patch just as Andrey said. > It's necessary to confirm those comments are correct, I think we can do this task later and create a new jira issue to track it. > What's your comments ? > > Cheers > Denghui Dong > > ------------------------------------------------------------------ > From:Andrey Petushkov > Send Time:2019?10?10?(???) 01:14 > To:"Jaroslav Bachor?k" ; ???(??) ; jdk8u-dev > Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 > > Hi Denghui, All, > > The patch looks good for me as well. > Regarding those XXX, in fact none of them were introduced by Denghui. Instead they are coming from current > incubator code and in fact it's deed of mine, sorry for that. They indicate a few places where I was a tiny bit > hesitant making changes to original (jdk11) JFR implementation. As such it would be nice if someone could review > them for correctness before removal > > Thanks, > Andrey > > > On 9 Oct 2019, at 18:23, Jaroslav Bachor?k wrote: > > > > Hi Denghui, > > > > I went through the diff of diffs and as far as I can see the backport is > > correct. But I saw a bunch of comment lines with 'XX' in them. Could you > > clean up those comments before final merge? > > > > Regards, > > > > -JB- > > > > On Wed, Oct 9, 2019 at 10:57 AM Denghui Dong > > wrote: > > > >> Hi all, > >> Please review this backports ( > >> http://cr.openjdk.java.net/~ddong/19-10-9-jfr-backports/hotspot.00/) for: > >> 8214542: JFR: Old Object Sample event slow on a deep heap in debug > >> builds > >> 8228834: Regression caused by JDK-8214542 not installing complete > >> checkpoint data to candidates > >> 8229437: assert(is_aligned(ref, HeapWordSize)) failed: invariant > >> > >> 8214542 is quite a large patch. > >> Please help me to push it to jdk8u-jfr-incubator if you think it's ok. > >> > >> Cheers > >> Denghui Dong > >> ------------------------------------------------------------------ > >> From:Mario Torre > >> Send Time:2019?10?8?(???) 18:16 > >> To:???(??) > >> Cc:jdk8u-dev ; Andrey Petushkov < > >> andrey at azul.com> > >> Subject:Re: [8u] [JFR] RFR: JFR backports from 11.0.4 > >> > >> Hi Denghui, > >> > >> Ok to push to the incubator repository! > >> > >> Cheers, > >> Mario > >> > >> On Fri, Sep 27, 2019 at 8:00 AM Denghui Dong > >> wrote: > >>> > >>> 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 < > >> jdk8u-dev at openjdk.java.net>; 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 < > >> 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 > >>>> > >>> > >> > >> > >> -- > >> 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 gromero at linux.vnet.ibm.com Wed Oct 23 21:36:26 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 23 Oct 2019 18:36:26 -0300 Subject: [8u] RFR for backport of 8198894 (CRC32 1/4): [PPC64] More generic vector CRC implementation In-Reply-To: References: <0dc83fcb-4e09-5841-04be-aee615e5a7fd@linux.vnet.ibm.com> Message-ID: <67e6e482-df56-27d0-da20-7968615f3ea1@linux.vnet.ibm.com> Hi Martin, On 10/22/2019 11:37 AM, Doerr, Martin wrote: > Hi Gustavo, > > backport looks good. The parts you have collected from other changes make sense to me. Thank you so much for the review. Should I consider patches 2, 3, and 4/4 [0, 1, 2] reviewed too? (since they are part of the CRC32 patchset) I intend to push 1, 2, 3, and 4 at the same time to jdk8u, but there is no harm too if they are not applied at once, it won't break the CRC32 or the JVM. I know that patchset is not small, so I really appreciate your time reviewing the patches. Thank you. Best regards, Gustavo [0] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-September/035219.html [1] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-September/035221.html [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-September/035220.html From martin.doerr at sap.com Thu Oct 24 10:17:12 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 24 Oct 2019 10:17:12 +0000 Subject: [8u] RFR for backport of 8198894 (CRC32 1/4): [PPC64] More generic vector CRC implementation In-Reply-To: <67e6e482-df56-27d0-da20-7968615f3ea1@linux.vnet.ibm.com> References: <0dc83fcb-4e09-5841-04be-aee615e5a7fd@linux.vnet.ibm.com> <67e6e482-df56-27d0-da20-7968615f3ea1@linux.vnet.ibm.com> Message-ID: Hi Gustavo, I think removing invertCRC is an unnecessary manual change. We should minimize that as far as possible. They may create merge conflicts for future backports. Best regards, Martin > -----Original Message----- > From: Gustavo Romero > Sent: Mittwoch, 23. Oktober 2019 23:36 > To: Doerr, Martin ; hotspot-compiler- > dev at openjdk.java.net > Cc: jdk8u-dev at openjdk.java.net > Subject: Re: [8u] RFR for backport of 8198894 (CRC32 1/4): [PPC64] More > generic vector CRC implementation > > Hi Martin, > > On 10/22/2019 11:37 AM, Doerr, Martin wrote: > > Hi Gustavo, > > > > backport looks good. The parts you have collected from other changes > make sense to me. > > Thank you so much for the review. > > Should I consider patches 2, 3, and 4/4 [0, 1, 2] reviewed too? (since they are > part of the CRC32 patchset) > > I intend to push 1, 2, 3, and 4 at the same time to jdk8u, but there is no > harm too if they are not applied at once, it won't break the CRC32 or the > JVM. > > I know that patchset is not small, so I really appreciate your time reviewing > the patches. Thank you. > > Best regards, > Gustavo > > [0] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019- > September/035219.html > [1] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019- > September/035221.html > [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019- > September/035220.html From rwestrel at redhat.com Thu Oct 24 13:20:52 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 24 Oct 2019 15:20:52 +0200 Subject: [8u] RFR: 8134739: compiler/loopopts/superword/TestVectorizationWithInvariant crashes in loop opts In-Reply-To: <87y2xuz6v5.fsf@redhat.com> References: <87y2xuz6v5.fsf@redhat.com> Message-ID: <87zhhq46vf.fsf@redhat.com> > Change does not apply cleanly to 8u but can be trivially adapted: > > http://cr.openjdk.java.net/~roland/8134739.8u/webrev.00/ > > Initial change: > > https://bugs.openjdk.java.net/browse/JDK-8134739 > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6d9d273e7f0d > > Tested with tier1. Anyone for this review? Roland. From hohensee at amazon.com Thu Oct 24 18:52:01 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 24 Oct 2019 18:52:01 +0000 Subject: Pending fix requests Message-ID: Gentle request to 8u maintainers. :) There are a number of reviewed backports waiting for maintainer approval/disapproval (i.e., to be tagged with jdk8u-fix-yes/no), e.g., 8144732. Thanks, Paul From shade at redhat.com Fri Oct 25 10:37:47 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 25 Oct 2019 12:37:47 +0200 Subject: [8u] Apache Spark workloads failures: no mismatched stores, except on raw memory Message-ID: <773de70e-ee59-f9ff-d888-04787eebe803@redhat.com> CI caught a few failures in current jdk8u, does this sound familar to anyone? $ wget https://github.com/renaissance-benchmarks/renaissance/releases/download/v0.9.0/renaissance-mit-0.9.0.jar $ build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image/bin/java -jar renaissance-mit-0.9.0.jar dec-tree -r 5 ====== dec-tree (apache-spark), iteration 0 started ====== # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/memnode.cpp:2489 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/shade/trunks/jdk8u-dev/hotspot/src/share/vm/opto/memnode.cpp:2489), pid=10910, tid=0x00007ff7a84d8700 # assert(Opcode() == mem->Opcode() || phase->C->get_alias_index(adr_type()) == Compile::AliasIdxRaw) failed: no mismatched stores, except on raw memory # # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-fastdebug-shade_2019_10_25_11_31-b00) # Java VM: OpenJDK 64-Bit Server VM (25.71-b00-fastdebug mixed mode linux-amd64 compressed oops) # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /home/shade/trunks/jdk8u-dev/hs_err_pid10910.log # # Compiler replay data is saved as: # /home/shade/trunks/jdk8u-dev/replay_pid10910.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp -- Thanks, -Aleksey From shade at redhat.com Fri Oct 25 12:04:36 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 25 Oct 2019 14:04:36 +0200 Subject: [8u] RFR: 8134739: compiler/loopopts/superword/TestVectorizationWithInvariant crashes in loop opts In-Reply-To: <87y2xuz6v5.fsf@redhat.com> References: <87y2xuz6v5.fsf@redhat.com> Message-ID: <10ff8496-0175-da1c-8b5c-0d89be8bd9d0@redhat.com> On 10/9/19 9:59 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8134739.8u/webrev.00/ Backport looks good. So the only conflict in jdk8u-dev right now is different "phi()" in loopnode.hpp, and superword.cpp actually applies without conflicts, right? I was staring into superword.cpp trying to see the difference, and there does not seem to be any. -- Thanks, -Aleksey From rwestrel at redhat.com Fri Oct 25 12:33:04 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 25 Oct 2019 14:33:04 +0200 Subject: [8u] RFR: 8134739: compiler/loopopts/superword/TestVectorizationWithInvariant crashes in loop opts In-Reply-To: <10ff8496-0175-da1c-8b5c-0d89be8bd9d0@redhat.com> References: <87y2xuz6v5.fsf@redhat.com> <10ff8496-0175-da1c-8b5c-0d89be8bd9d0@redhat.com> Message-ID: <87ftjh3szj.fsf@redhat.com> > Backport looks good. Thanks for reviewing it. > So the only conflict in jdk8u-dev right now is different "phi()" in loopnode.hpp, and superword.cpp > actually applies without conflicts, right? Right. Roland. From rwestrel at redhat.com Fri Oct 25 12:52:38 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 25 Oct 2019 14:52:38 +0200 Subject: [8u] Apache Spark workloads failures: no mismatched stores, except on raw memory In-Reply-To: <773de70e-ee59-f9ff-d888-04787eebe803@redhat.com> References: <773de70e-ee59-f9ff-d888-04787eebe803@redhat.com> Message-ID: <87d0el3s2x.fsf@redhat.com> > CI caught a few failures in current jdk8u, does this sound familar to > anyone? I think a partial backport of 8140309 would be required. Roland. From rwestrel at redhat.com Fri Oct 25 12:54:26 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 25 Oct 2019 14:54:26 +0200 Subject: [8u] Apache Spark workloads failures: no mismatched stores, except on raw memory In-Reply-To: <87d0el3s2x.fsf@redhat.com> References: <773de70e-ee59-f9ff-d888-04787eebe803@redhat.com> <87d0el3s2x.fsf@redhat.com> Message-ID: <87a79p3rzx.fsf@redhat.com> > I think a partial backport of 8140309 would be required. Some details: the code is unsing Unsafe.putLong to set multiple elements in an array of bytes. The assert itself is armless AFAICT. Roland. From shade at redhat.com Fri Oct 25 12:54:40 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 25 Oct 2019 14:54:40 +0200 Subject: [8u] Apache Spark workloads failures: no mismatched stores, except on raw memory In-Reply-To: <87d0el3s2x.fsf@redhat.com> References: <773de70e-ee59-f9ff-d888-04787eebe803@redhat.com> <87d0el3s2x.fsf@redhat.com> Message-ID: <840f84ec-831e-c4e2-9198-ba80f421815f@redhat.com> On 10/25/19 2:52 PM, Roland Westrelin wrote: >> CI caught a few failures in current jdk8u, does this sound familar to >> anyone? > > I think a partial backport of 8140309 would be required. I don't understand, here it is in 8u: 8140309: [REDO] failed: no mismatched stores, except on raw memory: StoreB StoreI Summary: Mismatched stores on same slice possible with Unsafe.Put*Unaligned methods Reviewed-by: kvn, thartmann http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/0ffee573412b -- Thanks, -Aleksey From rwestrel at redhat.com Fri Oct 25 12:57:32 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 25 Oct 2019 14:57:32 +0200 Subject: [8u] Apache Spark workloads failures: no mismatched stores, except on raw memory In-Reply-To: <840f84ec-831e-c4e2-9198-ba80f421815f@redhat.com> References: <773de70e-ee59-f9ff-d888-04787eebe803@redhat.com> <87d0el3s2x.fsf@redhat.com> <840f84ec-831e-c4e2-9198-ba80f421815f@redhat.com> Message-ID: <877e4t3rur.fsf@redhat.com> > I don't understand, here it is in 8u: > > 8140309: [REDO] failed: no mismatched stores, except on raw memory: StoreB StoreI > Summary: Mismatched stores on same slice possible with Unsafe.Put*Unaligned methods > Reviewed-by: kvn, thartmann > > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/0ffee573412b Ah. That piece was not backported: @@ -2393,7 +2400,8 @@ st->Opcode() == Op_StoreVector || Opcode() == Op_StoreVector || phase->C->get_alias_index(adr_type()) == Compile::AliasIdxRaw || - (Opcode() == Op_StoreL && st->Opcode() == Op_StoreI), // expanded ClearArrayNode + (Opcode() == Op_StoreL && st->Opcode() == Op_StoreI) || // expanded ClearArrayNode + (is_mismatched_access() || st->as_Store()->is_mismatched_access()), "no mismatched stores, except on raw memory: %s %s", NodeClassNames[Opcode()], NodeClassNames[st->Opcode()]); if (st->in(MemNode::Address)->eqv_uncast(address) && Roland. From sgehwolf at redhat.com Fri Oct 25 14:58:51 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 25 Oct 2019 16:58:51 +0200 Subject: [8u] Apache Spark workloads failures: no mismatched stores, except on raw memory In-Reply-To: <877e4t3rur.fsf@redhat.com> References: <773de70e-ee59-f9ff-d888-04787eebe803@redhat.com> <87d0el3s2x.fsf@redhat.com> <840f84ec-831e-c4e2-9198-ba80f421815f@redhat.com> <877e4t3rur.fsf@redhat.com> Message-ID: <5fe72b2d7a148cb0c1ea9e5cf130be6de6031e5c.camel@redhat.com> On Fri, 2019-10-25 at 14:57 +0200, Roland Westrelin wrote: > > I don't understand, here it is in 8u: > > > > 8140309: [REDO] failed: no mismatched stores, except on raw memory: StoreB StoreI > > Summary: Mismatched stores on same slice possible with Unsafe.Put*Unaligned methods > > Reviewed-by: kvn, thartmann > > > > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/0ffee573412b > > Ah. That piece was not backported: > > @@ -2393,7 +2400,8 @@ > st->Opcode() == Op_StoreVector || > Opcode() == Op_StoreVector || > phase->C->get_alias_index(adr_type()) == Compile::AliasIdxRaw || > - (Opcode() == Op_StoreL && st->Opcode() == Op_StoreI), // expanded ClearArrayNode > + (Opcode() == Op_StoreL && st->Opcode() == Op_StoreI) || // expanded ClearArrayNode > + (is_mismatched_access() || st->as_Store()->is_mismatched_access()), > "no mismatched stores, except on raw memory: %s %s", NodeClassNames[Opcode()], NodeClassNames[st->Opcode()]); > > if (st->in(MemNode::Address)->eqv_uncast(address) && Sounds to me we should file an 8u-only bug to get it included. Would that be about right? Thanks, Severin From sgehwolf at redhat.com Fri Oct 25 15:49:12 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 25 Oct 2019 17:49:12 +0200 Subject: [8u] Apache Spark workloads failures: no mismatched stores, except on raw memory In-Reply-To: <877e4t3rur.fsf@redhat.com> References: <773de70e-ee59-f9ff-d888-04787eebe803@redhat.com> <87d0el3s2x.fsf@redhat.com> <840f84ec-831e-c4e2-9198-ba80f421815f@redhat.com> <877e4t3rur.fsf@redhat.com> Message-ID: On Fri, 2019-10-25 at 14:57 +0200, Roland Westrelin wrote: > > I don't understand, here it is in 8u: > > > > 8140309: [REDO] failed: no mismatched stores, except on raw memory: StoreB StoreI > > Summary: Mismatched stores on same slice possible with Unsafe.Put*Unaligned methods > > Reviewed-by: kvn, thartmann > > > > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/0ffee573412b > > Ah. That piece was not backported: > > @@ -2393,7 +2400,8 @@ > st->Opcode() == Op_StoreVector || > Opcode() == Op_StoreVector || > phase->C->get_alias_index(adr_type()) == Compile::AliasIdxRaw || > - (Opcode() == Op_StoreL && st->Opcode() == Op_StoreI), // expanded ClearArrayNode > + (Opcode() == Op_StoreL && st->Opcode() == Op_StoreI) || // expanded ClearArrayNode > + (is_mismatched_access() || st->as_Store()->is_mismatched_access()), > "no mismatched stores, except on raw memory: %s %s", NodeClassNames[Opcode()], NodeClassNames[st->Opcode()]); > > if (st->in(MemNode::Address)->eqv_uncast(address) && I've filed a bug to track this issue: https://bugs.openjdk.java.net/browse/JDK-8233023 Thanks, Severin From jai.forums2013 at gmail.com Mon Oct 28 06:09:28 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Mon, 28 Oct 2019 11:39:28 +0530 Subject: Backport request for JDK-8034773 Message-ID: <9a478f32-eafc-e3e3-20a4-8c6a9b60318a@gmail.com> One of the projects I watch, has run into an issue[1] which has been fixed in Java 9+. The fix for Java 9+ went in as part of this issue[2]. The related commit for it is [3] and includes more than one bug fix. The commit itself is relatively small and has a testcase included. I am new to the backport request process. What would be the best way forward to have this change backported to OpenJDK 8? Should I be raising a backport request in the JBS (I've "author" role, so can do that if that's necessary)? Right now, the issue has been worked around[4] in the project where we hit it. But I would like to avoid more such changes all over the place, by having this fixed in OpenJDK itself. [1] https://bugs.openjdk.java.net/browse/JDK-8233015 [2] https://bugs.openjdk.java.net/browse/JDK-8034773 [3] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/6f00367ab8e1 [4] https://github.com/quarkusio/quarkus/pull/4865 -Jaikiran From vkempik at azul.com Mon Oct 28 09:20:22 2019 From: vkempik at azul.com (Vladimir Kempik) Date: Mon, 28 Oct 2019 09:20:22 +0000 Subject: RFR(8u): 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: <7B2B9DF5-F845-42FC-949C-102B72282975@amazon.com> References: <5CCC5140-4C75-45CD-A3A2-CC0237DD7AD9@azul.com> <7B2B9DF5-F845-42FC-949C-102B72282975@amazon.com> Message-ID: Hello Can anyone please take a look at this patch? The difference between 11 and 8 is pretty simple: move one method from superclass to subclass to prevent it being compiled on every Unix system(it can?t be compiled on solaris). This code is only used on Linux so far. Thanks, Vladimir 21 ???. 2019 ?., ? 19:23, Hohensee, Paul > ???????(?): +jdk8u-dev Paul From: nio-dev > on behalf of Vladimir Kempik > Date: Monday, October 21, 2019 at 2:47 AM To: "nio-dev at openjdk.java.net" > Subject: RFR(8u): 8229872: (fs) Increase buffer size used with getmntent Hello Please review backport of https://bugs.openjdk.java.net/browse/JDK-8229872 to 8u: http://cr.openjdk.java.net/~vkempik/8229872/ojdk8/webrev.00/ Difference between 14/13/11 fix: getline is missing on solaris10, so getlinelen method was moved from UnixNativeDispatcher to LinuxNativeDispatcher. Original fix: https://hg.openjdk.java.net/jdk/jdk/rev/2d40e6a7ce8e Such fix was already included into azul?s october psu for openjdk8 and passed all release cycle tests. Thanks, Vladimir From christoph.langer at sap.com Mon Oct 28 10:46:18 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 28 Oct 2019 10:46:18 +0000 Subject: Backport request for JDK-8034773 In-Reply-To: <9a478f32-eafc-e3e3-20a4-8c6a9b60318a@gmail.com> References: <9a478f32-eafc-e3e3-20a4-8c6a9b60318a@gmail.com> Message-ID: Hi Jaikiran, this fix is definitely a good candidate for a backport to jdk8u. What you should do now is to extract the patch and apply it to 8u. It'll probably need some reshuffling and further adaptations. Once you have it, please post an RFR webrev on this mailing list and add the jdk8u-fix-request label to the bug with a comment, referring to the mailing list's review thread. Cheers Christoph > -----Original Message----- > From: jdk8u-dev On Behalf Of > Jaikiran Pai > Sent: Montag, 28. Oktober 2019 07:09 > To: jdk8u-dev at openjdk.java.net > Subject: Backport request for JDK-8034773 > > One of the projects I watch, has run into an issue[1] which has been > fixed in Java 9+. The fix for Java 9+ went in as part of this issue[2]. > The related commit for it is [3] and includes more than one bug fix. The > commit itself is relatively small and has a testcase included. > > I am new to the backport request process. What would be the best way > forward to have this change backported to OpenJDK 8? Should I be raising > a backport request in the JBS (I've "author" role, so can do that if > that's necessary)? > > Right now, the issue has been worked around[4] in the project where we > hit it. But I would like to avoid more such changes all over the place, > by having this fixed in OpenJDK itself. > > [1] https://bugs.openjdk.java.net/browse/JDK-8233015 > > [2] https://bugs.openjdk.java.net/browse/JDK-8034773 > > [3] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/6f00367ab8e1 > > [4] https://github.com/quarkusio/quarkus/pull/4865 > > -Jaikiran > > From jai.forums2013 at gmail.com Mon Oct 28 10:57:37 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Mon, 28 Oct 2019 16:27:37 +0530 Subject: Backport request for JDK-8034773 In-Reply-To: References: <9a478f32-eafc-e3e3-20a4-8c6a9b60318a@gmail.com> Message-ID: Thank you for those details, Christoph. I'll start preparing the patch. Which of the following 2 repos is the correct one to patch and propose a RFR against: https://hg.openjdk.java.net/jdk8u/jdk8u/ https://hg.openjdk.java.net/jdk8u/jdk8u-dev/ -Jaikiran On 28/10/19 4:16 PM, Langer, Christoph wrote: > Hi Jaikiran, > > this fix is definitely a good candidate for a backport to jdk8u. > > What you should do now is to extract the patch and apply it to 8u. It'll probably need some reshuffling and further adaptations. Once you have it, please post an RFR webrev on this mailing list and add the jdk8u-fix-request label to the bug with a comment, referring to the mailing list's review thread. > > Cheers > Christoph > >> -----Original Message----- >> From: jdk8u-dev On Behalf Of >> Jaikiran Pai >> Sent: Montag, 28. Oktober 2019 07:09 >> To: jdk8u-dev at openjdk.java.net >> Subject: Backport request for JDK-8034773 >> >> One of the projects I watch, has run into an issue[1] which has been >> fixed in Java 9+. The fix for Java 9+ went in as part of this issue[2]. >> The related commit for it is [3] and includes more than one bug fix. The >> commit itself is relatively small and has a testcase included. >> >> I am new to the backport request process. What would be the best way >> forward to have this change backported to OpenJDK 8? Should I be raising >> a backport request in the JBS (I've "author" role, so can do that if >> that's necessary)? >> >> Right now, the issue has been worked around[4] in the project where we >> hit it. But I would like to avoid more such changes all over the place, >> by having this fixed in OpenJDK itself. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8233015 >> >> [2] https://bugs.openjdk.java.net/browse/JDK-8034773 >> >> [3] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/6f00367ab8e1 >> >> [4] https://github.com/quarkusio/quarkus/pull/4865 >> >> -Jaikiran >> >> From christoph.langer at sap.com Mon Oct 28 12:56:57 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 28 Oct 2019 12:56:57 +0000 Subject: Backport request for JDK-8034773 In-Reply-To: References: <9a478f32-eafc-e3e3-20a4-8c6a9b60318a@gmail.com> Message-ID: Hi Jaikiran, https://hg.openjdk.java.net/jdk8u/jdk8u-dev/ is the correct one. (Though the same patch would probably apply to jdk8u...) /Christoph > -----Original Message----- > From: Jaikiran Pai > Sent: Montag, 28. Oktober 2019 11:58 > To: Langer, Christoph ; jdk8u- > dev at openjdk.java.net > Subject: Re: Backport request for JDK-8034773 > > Thank you for those details, Christoph. > > I'll start preparing the patch. Which of the following 2 repos is the > correct one to patch and propose a RFR against: > > https://hg.openjdk.java.net/jdk8u/jdk8u/ > > https://hg.openjdk.java.net/jdk8u/jdk8u-dev/ > > -Jaikiran > > On 28/10/19 4:16 PM, Langer, Christoph wrote: > > Hi Jaikiran, > > > > this fix is definitely a good candidate for a backport to jdk8u. > > > > What you should do now is to extract the patch and apply it to 8u. It'll > probably need some reshuffling and further adaptations. Once you have it, > please post an RFR webrev on this mailing list and add the jdk8u-fix-request > label to the bug with a comment, referring to the mailing list's review thread. > > > > Cheers > > Christoph > > > >> -----Original Message----- > >> From: jdk8u-dev On Behalf Of > >> Jaikiran Pai > >> Sent: Montag, 28. Oktober 2019 07:09 > >> To: jdk8u-dev at openjdk.java.net > >> Subject: Backport request for JDK-8034773 > >> > >> One of the projects I watch, has run into an issue[1] which has been > >> fixed in Java 9+. The fix for Java 9+ went in as part of this issue[2]. > >> The related commit for it is [3] and includes more than one bug fix. The > >> commit itself is relatively small and has a testcase included. > >> > >> I am new to the backport request process. What would be the best way > >> forward to have this change backported to OpenJDK 8? Should I be raising > >> a backport request in the JBS (I've "author" role, so can do that if > >> that's necessary)? > >> > >> Right now, the issue has been worked around[4] in the project where we > >> hit it. But I would like to avoid more such changes all over the place, > >> by having this fixed in OpenJDK itself. > >> > >> [1] https://bugs.openjdk.java.net/browse/JDK-8233015 > >> > >> [2] https://bugs.openjdk.java.net/browse/JDK-8034773 > >> > >> [3] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/6f00367ab8e1 > >> > >> [4] https://github.com/quarkusio/quarkus/pull/4865 > >> > >> -Jaikiran > >> > >> From jai.forums2013 at gmail.com Mon Oct 28 13:22:17 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Mon, 28 Oct 2019 18:52:17 +0530 Subject: Backport request for JDK-8034773 In-Reply-To: References: <9a478f32-eafc-e3e3-20a4-8c6a9b60318a@gmail.com> Message-ID: <968d49d8-031a-0047-b443-28b25a1fd62f@gmail.com> Thank you Christoph. -Jaikiran On 28/10/19 6:26 PM, Langer, Christoph wrote: > Hi Jaikiran, > > https://hg.openjdk.java.net/jdk8u/jdk8u-dev/ is the correct one. (Though the same patch would probably apply to jdk8u...) > > /Christoph > >> -----Original Message----- >> From: Jaikiran Pai >> Sent: Montag, 28. Oktober 2019 11:58 >> To: Langer, Christoph ; jdk8u- >> dev at openjdk.java.net >> Subject: Re: Backport request for JDK-8034773 >> >> Thank you for those details, Christoph. >> >> I'll start preparing the patch. Which of the following 2 repos is the >> correct one to patch and propose a RFR against: >> >> https://hg.openjdk.java.net/jdk8u/jdk8u/ >> >> https://hg.openjdk.java.net/jdk8u/jdk8u-dev/ >> >> -Jaikiran >> >> On 28/10/19 4:16 PM, Langer, Christoph wrote: >>> Hi Jaikiran, >>> >>> this fix is definitely a good candidate for a backport to jdk8u. >>> >>> What you should do now is to extract the patch and apply it to 8u. It'll >> probably need some reshuffling and further adaptations. Once you have it, >> please post an RFR webrev on this mailing list and add the jdk8u-fix-request >> label to the bug with a comment, referring to the mailing list's review thread. >>> Cheers >>> Christoph >>> >>>> -----Original Message----- >>>> From: jdk8u-dev On Behalf Of >>>> Jaikiran Pai >>>> Sent: Montag, 28. Oktober 2019 07:09 >>>> To: jdk8u-dev at openjdk.java.net >>>> Subject: Backport request for JDK-8034773 >>>> >>>> One of the projects I watch, has run into an issue[1] which has been >>>> fixed in Java 9+. The fix for Java 9+ went in as part of this issue[2]. >>>> The related commit for it is [3] and includes more than one bug fix. The >>>> commit itself is relatively small and has a testcase included. >>>> >>>> I am new to the backport request process. What would be the best way >>>> forward to have this change backported to OpenJDK 8? Should I be raising >>>> a backport request in the JBS (I've "author" role, so can do that if >>>> that's necessary)? >>>> >>>> Right now, the issue has been worked around[4] in the project where we >>>> hit it. But I would like to avoid more such changes all over the place, >>>> by having this fixed in OpenJDK itself. >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8233015 >>>> >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8034773 >>>> >>>> [3] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/6f00367ab8e1 >>>> >>>> [4] https://github.com/quarkusio/quarkus/pull/4865 >>>> >>>> -Jaikiran >>>> >>>> From ygaevsky at azul.com Mon Oct 28 14:09:58 2019 From: ygaevsky at azul.com (Yuri Gaevsky) Date: Mon, 28 Oct 2019 14:09:58 +0000 Subject: FW: Request for approval: JDK-8073108 "Use x86 and SPARC CPU instructions for GHASH acceleration" Message-ID: <10a00287036640e89a1e1f02340eed1b@azul.com> ping. -----Original Message----- From: Yuri Gaevsky Sent: Wednesday, October 2, 2019 04:38 PM To: jdk8u-dev at openjdk.java.net Subject: Request for approval: JDK-8073108 "Use x86 and SPARC CPU instructions for GHASH acceleration" (resending) 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: ( there are 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. From ygaevsky at azul.com Mon Oct 28 14:12:48 2019 From: ygaevsky at azul.com (Yuri Gaevsky) Date: Mon, 28 Oct 2019 14:12:48 +0000 Subject: FW: Request for approval: JDK-8130341 "GHASH 32bit intrinsics has AEADBadTagException" In-Reply-To: <990e8a14c8f6442bb4225d3b9b0f1eec@azul.com> References: <990e8a14c8f6442bb4225d3b9b0f1eec@azul.com> Message-ID: <23a785bdd5604f33b2b2c1fb54ea3547@azul.com> ping. -----Original Message----- From: jdk8u-dev [mailto:jdk8u-dev-bounces at openjdk.java.net] On Behalf Of Yuri Gaevsky Sent: Thursday, October 10, 2019 12:52 PM To: jdk8u-dev at openjdk.java.net Subject: Request for approval: JDK-8130341 "GHASH 32bit intrinsics has AEADBadTagException" Hello, Please approve backport of JDK-8130341 "GHASH 32bit intrinsics has AEADBadTagException" to jdk8u which is a required follow-up fix for the issue mentioned in [1]. Bug: https://bugs.openjdk.java.net/browse/JDK-8130341 JDK9 review thread: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-July/018402.html JDK9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/36fd5d1982b0 Webrev: http://cr.openjdk.java.net/~ygaevsky/8130341.8u/webrev.hotspot/ NB: The original change for JDK9 does apply cleanly to jdk8u codebase w/ minor correction to the test path (test/compiler/codegen/7184394/ --> test/compiler/7184394/). Testing: windows-i586: (known failures mentioned in [1] are gone) windows-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) Thank you, -Yuri Gaevsky, Azul Systems, Inc. [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-October/010409.html From zgu at redhat.com Mon Oct 28 18:47:27 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 28 Oct 2019 14:47:27 -0400 Subject: [8u] RFR 8229420: [Redo] jstat reports incorrect values for OU for CMS GC Message-ID: <1a056d3e-dbd1-7a4a-e2b0-578788f586ce@redhat.com> Please review this 8u backport, as this CR is on Oracle's 8u backport. The original patch does not apply cleanly, because there are a few general GC refactorings, as well as CMS refactorings. Original Bug: https://bugs.openjdk.java.net/browse/JDK-8229420 Original code review thread: https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-August/028935.html 8u backport: http://cr.openjdk.java.net/~zgu/JDK-8229420_8u/webrev.00/ Test: gc jtreg tests on Linux x86_64 Thanks, -Zhengyu From felix.yang at huawei.com Tue Oct 29 00:53:45 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 29 Oct 2019 00:53:45 +0000 Subject: Request for Approval: Backport of 8231988 : Unexpected test result caused by C2 IdealLoopTree::do_remove_empty_loop Message-ID: Hi, May I got review for the backport of 8231988 to 8u master repo please? This fixes a C2 bug which is level P2. Patch does not apply cleanly to 8u due to file path difference. Webrev: http://cr.openjdk.java.net/~fyang/8231988-8u-backport/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8231988 Upstream Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/45a085445a8c New test fails without the patch, and passes with it. Jtreg test pass with the patch. Thanks, Felix From jai.forums2013 at gmail.com Tue Oct 29 07:44:08 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 29 Oct 2019 13:14:08 +0530 Subject: RFR for backport of JDK-8034773 : (zipfs) newOutputstream uses CREATE_NEW when no options specified Message-ID: Can I please get a review and a sponsor for a fix which backports JDK-8034773 [1] to OpenJDK 8? The backport is available as a webrev at [2]. The JBS issue tracking this backport is at [3]. The commit in this backport patch was manually created since the original commit for [1] does not apply cleanly because of the directory structure changes between the 8u repo and the later JDK repos. This change along with the test case introduced in the original commit, passed locally. [1] https://bugs.openjdk.java.net/browse/JDK-8034773 [2] https://cr.openjdk.java.net/~jpai/webrev/8233103/1/webrev/ [3] https://bugs.openjdk.java.net/browse/JDK-8233103 P.S: Bit surprised that in JDK 8, the source for nio/zipfs resided in "demo" directory and even has a warning stating the code is for demo purpose. -Jaikiran From christoph.langer at sap.com Tue Oct 29 08:24:43 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 29 Oct 2019 08:24:43 +0000 Subject: RFR for backport of JDK-8034773 : (zipfs) newOutputstream uses CREATE_NEW when no options specified In-Reply-To: References: Message-ID: Hi Jaikiran, the backport looks good to me. I can sponsor it, once we get the approval label. Yes, it's really weird that in JDK8 the zipfs coding was still located in the demo folder though it actually belonged to the product. But that's how it is ?? Cheers Christoph > -----Original Message----- > From: jdk8u-dev On Behalf Of > Jaikiran Pai > Sent: Dienstag, 29. Oktober 2019 08:44 > To: jdk8u-dev at openjdk.java.net > Subject: RFR for backport of JDK-8034773 : (zipfs) newOutputstream uses > CREATE_NEW when no options specified > > Can I please get a review and a sponsor for a fix which backports > JDK-8034773 [1] to OpenJDK 8? The backport is available as a webrev at > [2]. The JBS issue tracking this backport is at [3]. > > The commit in this backport patch was manually created since the > original commit for [1] does not apply cleanly because of the directory > structure changes between the 8u repo and the later JDK repos. This > change along with the test case introduced in the original commit, > passed locally. > > > [1] https://bugs.openjdk.java.net/browse/JDK-8034773 > > [2] https://cr.openjdk.java.net/~jpai/webrev/8233103/1/webrev/ > > [3] https://bugs.openjdk.java.net/browse/JDK-8233103 > > P.S: Bit surprised that in JDK 8, the source for nio/zipfs resided in > "demo" directory and even has a warning stating the code is for demo > purpose. > > -Jaikiran > From aph at redhat.com Tue Oct 29 08:32:51 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 29 Oct 2019 08:32:51 +0000 Subject: Request for Approval: Backport of 8231988 : Unexpected test result caused by C2 IdealLoopTree::do_remove_empty_loop In-Reply-To: References: Message-ID: On 10/29/19 12:53 AM, Yangfei (Felix) wrote: > Webrev: http://cr.openjdk.java.net/~fyang/8231988-8u-backport/webrev.00/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231988 > Upstream Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/45a085445a8c OK, thanks. -- 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 felix.yang at huawei.com Tue Oct 29 10:07:33 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 29 Oct 2019 10:07:33 +0000 Subject: Request for Approval: Backport of 8231988 : Unexpected test result caused by C2 IdealLoopTree::do_remove_empty_loop In-Reply-To: References: Message-ID: Thanks you for reviewing this. And I need a sponsor to push the patch as I am not jdk8u committer. Felix > -----Original Message----- > From: Andrew Haley [mailto:aph at redhat.com] > Sent: Tuesday, October 29, 2019 4:33 PM > To: Yangfei (Felix) ; jdk8u-dev at openjdk.java.net > Subject: Re: Request for Approval: Backport of 8231988 : Unexpected test > result caused by C2 IdealLoopTree::do_remove_empty_loop > > On 10/29/19 12:53 AM, Yangfei (Felix) wrote: > > Webrev: > > http://cr.openjdk.java.net/~fyang/8231988-8u-backport/webrev.00/ > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231988 > > Upstream Changeset: > > https://hg.openjdk.java.net/jdk/jdk/rev/45a085445a8c > > OK, thanks. > > -- > 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 Tue Oct 29 18:18:07 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 29 Oct 2019 18:18:07 +0000 Subject: Request for Approval: Backport of 8231988 : Unexpected test result caused by C2 IdealLoopTree::do_remove_empty_loop In-Reply-To: References: Message-ID: On 29/10/2019 00:53, Yangfei (Felix) wrote: > Hi, > > > > May I got review for the backport of 8231988 to 8u master repo please? This fixes a C2 bug which is level P2. > > Ok, but then the subject for this mail should really be 'Request for Review' (or RFR for short) :-) Approvals don't require an e-mail. Labelling the bug 'jdk8u-fix-request' and providing an explanation in the comments (as I see you have for this bug) is sufficient. > > Patch does not apply cleanly to 8u due to file path difference. > > Webrev: http://cr.openjdk.java.net/~fyang/8231988-8u-backport/webrev.00/ > That's acceptable without a review and is true of all backports from >=9. I see other changes were also made here as well, altering a copyright header and removing the package declaration from the test case. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231988 > Upstream Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/45a085445a8c > > New test fails without the patch, and passes with it. > Jtreg test pass with the patch. Confirmed with my own testing. Patch looks fine. Approved and pushed. > > > Thanks, > Felix > 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 Wed Oct 30 02:02:58 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 30 Oct 2019 02:02:58 +0000 Subject: Request for Approval: Backport of 8231988 : Unexpected test result caused by C2 IdealLoopTree::do_remove_empty_loop In-Reply-To: References: Message-ID: > -----Original Message----- > From: Andrew John Hughes [mailto:gnu.andrew at redhat.com] > Sent: Wednesday, October 30, 2019 2:18 AM > To: Yangfei (Felix) ; jdk8u-dev at openjdk.java.net > Subject: Re: Request for Approval: Backport of 8231988 : Unexpected test > result caused by C2 IdealLoopTree::do_remove_empty_loop > > On 29/10/2019 00:53, Yangfei (Felix) wrote: > > Hi, > > > > > > > > May I got review for the backport of 8231988 to 8u master repo please? > This fixes a C2 bug which is level P2. > > > > > > Ok, but then the subject for this mail should really be 'Request for Review' (or > RFR for short) :-) > > Approvals don't require an e-mail. Labelling the bug 'jdk8u-fix-request' > and providing an explanation in the comments (as I see you have for this > bug) is sufficient. > Yes, will follow the same backport process as OpenJDK 11 updates for my later ones : - ) Thanks for reviewing and pushing this. Felix From sgehwolf at redhat.com Wed Oct 30 09:41:26 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 30 Oct 2019 10:41:26 +0100 Subject: [8u] RFR: 8233023: assert(Opcode() == mem->Opcode() || phase->C->get_alias_index(adr_type()) == Compile::AliasIdxRaw) failed: no mismatched stores, except on raw memory Message-ID: <7a2d50793120bdeb86d0047fd09db18c725328e0.camel@redhat.com> Hi, Could I please get a review of this 8u only issue? The reason a fastdebug build of latest OpenJDK 8u asserts for the dec-tree benchmark of the renaissance suite is because the 8u backport of JDK-8140309 was missing this hunk from JDK 9[1]: + (Opcode() == Op_StoreL && st->Opcode() == Op_StoreI) || // expanded ClearArrayNode + (is_mismatched_access() || st->as_Store()->is_mismatched_access()), I had a closer look and there doesn't seem to be missing anything else. The proposed fix is to amend the assert condition in the appropriate place, which brings 8u in line with JDK 9 code where the failure isn't observed. Bug: https://bugs.openjdk.java.net/browse/JDK-8233023 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233023/01/webrev/ Testing: 8u tier1 test set with fastdebug build on x86_64 Linux. No new failures. dec-tree benchmark now runs successfully on an 8u fastdebug build. Thoughts? Thanks, Severin [1] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/4bee38ba018c From neugens at redhat.com Wed Oct 30 12:41:41 2019 From: neugens at redhat.com (Mario Torre) Date: Wed, 30 Oct 2019 13:41:41 +0100 Subject: CFV: New JDK Committer: Denghui Dong Message-ID: Hi all, I hereby nominate Denghui Dong (denghui.ddh at alibaba-inc.com) [1] to JDK 8 Update committer. Denghui has been contributing a large number of backports for the Flight Recorder incubator project and is one of the authors of the original backport patch. Some of the backports include: jdk8u-jfr-incubator: http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/hotspot/rev/a248d0be1309 http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/jdk/rev/625378d53fb1 8229401: Fix JFR code cache test failures 8223689: Add JFR Thread Sampling Support 8223690: Add JFR BiasedLock Event Support 8223691: Add JFR G1 Region Type Change Event Support 8223692: Add JFR G1 Heap Summary Event Support http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/hotspot/rev/8e875c964f41 backport 8232117: JFR: Old Object Sample event slow on a deep heap in debug builds backport 8232799: assert(is_aligned(ref, HeapWordSize)) failed: invariant backport 8232800: Regression caused by JDK-8214542 not installing complete checkpoint data to candidates http://cr.openjdk.java.net/~ddong/8227605/hotspot.00/ (reviewing) backport 8227605: Kitchensink fails "assert((((klass)->trace_id() & (JfrTraceIdEpoch::leakp_in_use_this_epoch_bit())) != 0)) failed: invariant" 11u: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/9b8d1c75f8c7 backport 8232096: RecordingInfo should use textual representation of path http://cr.openjdk.java.net/~wzhuo/8185525/webrev.00/ (reviewing) backport 8185525: Add JFR event for DictionarySizes 8u: http://cr.openjdk.java.net/~ddong/8144732/hotspot.01/ (reviewing) backport 8144732: VM_HeapDumper hits assert with bad dump_len http://cr.openjdk.java.net/~ddong/8232355/hotspot.00/ (reviewing) 8232355: Two obsolete flags have the wrong obsolete version in 8u Votes are due by Nov 13th 19:00 CET. Only current JDK Committers [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 [2]. [1] https://openjdk.java.net/census#ddong [2] http://openjdk.java.net/bylaws#lazy-consensus [3] https://openjdk.java.net/census -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From volker.simonis at gmail.com Wed Oct 30 13:08:04 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 30 Oct 2019 14:08:04 +0100 Subject: CFV: New JDK Committer: Denghui Dong In-Reply-To: References: Message-ID: Vote: yes Mario Torre schrieb am Mi., 30. Okt. 2019, 13:42: > Hi all, > > I hereby nominate Denghui Dong (denghui.ddh at alibaba-inc.com) [1] to > JDK 8 Update committer. > > Denghui has been contributing a large number of backports for the > Flight Recorder incubator project and is one of the authors of the > original backport patch. > > Some of the backports include: > > jdk8u-jfr-incubator: > > http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/hotspot/rev/a248d0be1309 > > http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/jdk/rev/625378d53fb1 > 8229401: Fix JFR code cache test failures > 8223689: Add JFR Thread Sampling Support > 8223690: Add JFR BiasedLock Event Support > 8223691: Add JFR G1 Region Type Change Event Support > 8223692: Add JFR G1 Heap Summary Event Support > > > http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/hotspot/rev/8e875c964f41 > backport 8232117: JFR: Old Object Sample event slow on a deep heap > in debug builds > backport 8232799: assert(is_aligned(ref, HeapWordSize)) failed: > invariant > backport 8232800: Regression caused by JDK-8214542 not installing > complete checkpoint data to candidates > > http://cr.openjdk.java.net/~ddong/8227605/hotspot.00/ (reviewing) > backport 8227605: Kitchensink fails "assert((((klass)->trace_id() > & (JfrTraceIdEpoch::leakp_in_use_this_epoch_bit())) != 0)) failed: > invariant" > > 11u: > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/9b8d1c75f8c7 > backport 8232096: RecordingInfo should use textual representation of > path > http://cr.openjdk.java.net/~wzhuo/8185525/webrev.00/ (reviewing) > backport 8185525: Add JFR event for DictionarySizes > > 8u: > http://cr.openjdk.java.net/~ddong/8144732/hotspot.01/ (reviewing) > backport 8144732: VM_HeapDumper hits assert with bad dump_len > http://cr.openjdk.java.net/~ddong/8232355/hotspot.00/ (reviewing) > 8232355: Two obsolete flags have the wrong obsolete version in 8u > > Votes are due by Nov 13th 19:00 CET. > > Only current JDK Committers [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 [2]. > > [1] https://openjdk.java.net/census#ddong > [2] http://openjdk.java.net/bylaws#lazy-consensus > [3] https://openjdk.java.net/census > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > From sgehwolf at redhat.com Wed Oct 30 13:17:08 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 30 Oct 2019 14:17:08 +0100 Subject: CFV: New JDK 8u Committer: Denghui Dong In-Reply-To: References: Message-ID: <9036e4bade045c7d378db15ebdec0f8a210830d6.camel@redhat.com> Vote: yes On Wed, 2019-10-30 at 13:41 +0100, Mario Torre wrote: > Hi all, > > I hereby nominate Denghui Dong (denghui.ddh at alibaba-inc.com) [1] to > JDK 8 Update committer. > > Denghui has been contributing a large number of backports for the > Flight Recorder incubator project and is one of the authors of the > original backport patch. > > Some of the backports include: > > jdk8u-jfr-incubator: > http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/hotspot/rev/a248d0be1309 > http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/jdk/rev/625378d53fb1 > 8229401: Fix JFR code cache test failures > 8223689: Add JFR Thread Sampling Support > 8223690: Add JFR BiasedLock Event Support > 8223691: Add JFR G1 Region Type Change Event Support > 8223692: Add JFR G1 Heap Summary Event Support > > http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/hotspot/rev/8e875c964f41 > backport 8232117: JFR: Old Object Sample event slow on a deep heap > in debug builds > backport 8232799: assert(is_aligned(ref, HeapWordSize)) failed: invariant > backport 8232800: Regression caused by JDK-8214542 not installing > complete checkpoint data to candidates > > http://cr.openjdk.java.net/~ddong/8227605/hotspot.00/ (reviewing) > backport 8227605: Kitchensink fails "assert((((klass)->trace_id() > & (JfrTraceIdEpoch::leakp_in_use_this_epoch_bit())) != 0)) failed: > invariant" > > 11u: > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/9b8d1c75f8c7 > backport 8232096: RecordingInfo should use textual representation of path > http://cr.openjdk.java.net/~wzhuo/8185525/webrev.00/ (reviewing) > backport 8185525: Add JFR event for DictionarySizes > > 8u: > http://cr.openjdk.java.net/~ddong/8144732/hotspot.01/ (reviewing) > backport 8144732: VM_HeapDumper hits assert with bad dump_len > http://cr.openjdk.java.net/~ddong/8232355/hotspot.00/ (reviewing) > 8232355: Two obsolete flags have the wrong obsolete version in 8u > > Votes are due by Nov 13th 19:00 CET. > > Only current JDK Committers [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 [2]. > > [1] https://openjdk.java.net/census#ddong > [2] http://openjdk.java.net/bylaws#lazy-consensus > [3] https://openjdk.java.net/census > > From adinn at redhat.com Wed Oct 30 13:49:12 2019 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 30 Oct 2019 13:49:12 +0000 Subject: CFV: New JDK Committer: Denghui Dong In-Reply-To: References: Message-ID: Vote: yes On 30/10/2019 12:41, Mario Torre wrote: > Hi all, > > I hereby nominate Denghui Dong (denghui.ddh at alibaba-inc.com) [1] to > JDK 8 Update committer. > > Denghui has been contributing a large number of backports for the > Flight Recorder incubator project and is one of the authors of the > original backport patch. > > Some of the backports include: > > jdk8u-jfr-incubator: > http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/hotspot/rev/a248d0be1309 > http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/jdk/rev/625378d53fb1 > 8229401: Fix JFR code cache test failures > 8223689: Add JFR Thread Sampling Support > 8223690: Add JFR BiasedLock Event Support > 8223691: Add JFR G1 Region Type Change Event Support > 8223692: Add JFR G1 Heap Summary Event Support > > http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/hotspot/rev/8e875c964f41 > backport 8232117: JFR: Old Object Sample event slow on a deep heap > in debug builds > backport 8232799: assert(is_aligned(ref, HeapWordSize)) failed: invariant > backport 8232800: Regression caused by JDK-8214542 not installing > complete checkpoint data to candidates > > http://cr.openjdk.java.net/~ddong/8227605/hotspot.00/ (reviewing) > backport 8227605: Kitchensink fails "assert((((klass)->trace_id() > & (JfrTraceIdEpoch::leakp_in_use_this_epoch_bit())) != 0)) failed: > invariant" > > 11u: > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/9b8d1c75f8c7 > backport 8232096: RecordingInfo should use textual representation of path > http://cr.openjdk.java.net/~wzhuo/8185525/webrev.00/ (reviewing) > backport 8185525: Add JFR event for DictionarySizes > > 8u: > http://cr.openjdk.java.net/~ddong/8144732/hotspot.01/ (reviewing) > backport 8144732: VM_HeapDumper hits assert with bad dump_len > http://cr.openjdk.java.net/~ddong/8232355/hotspot.00/ (reviewing) > 8232355: Two obsolete flags have the wrong obsolete version in 8u > > Votes are due by Nov 13th 19:00 CET. > > Only current JDK Committers [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 [2]. > > [1] https://openjdk.java.net/census#ddong > [2] http://openjdk.java.net/bylaws#lazy-consensus > [3] https://openjdk.java.net/census > > -- 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 From zgu at redhat.com Wed Oct 30 13:58:11 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 30 Oct 2019 09:58:11 -0400 Subject: CFV: New JDK Committer: Denghui Dong In-Reply-To: References: Message-ID: Vote: yes -Zhengyu On 10/30/19 8:41 AM, Mario Torre wrote: > Hi all, > > I hereby nominate Denghui Dong (denghui.ddh at alibaba-inc.com) [1] to > JDK 8 Update committer. > > Denghui has been contributing a large number of backports for the > Flight Recorder incubator project and is one of the authors of the > original backport patch. > > Some of the backports include: > > jdk8u-jfr-incubator: > http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/hotspot/rev/a248d0be1309 > http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/jdk/rev/625378d53fb1 > 8229401: Fix JFR code cache test failures > 8223689: Add JFR Thread Sampling Support > 8223690: Add JFR BiasedLock Event Support > 8223691: Add JFR G1 Region Type Change Event Support > 8223692: Add JFR G1 Heap Summary Event Support > > http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/hotspot/rev/8e875c964f41 > backport 8232117: JFR: Old Object Sample event slow on a deep heap > in debug builds > backport 8232799: assert(is_aligned(ref, HeapWordSize)) failed: invariant > backport 8232800: Regression caused by JDK-8214542 not installing > complete checkpoint data to candidates > > http://cr.openjdk.java.net/~ddong/8227605/hotspot.00/ (reviewing) > backport 8227605: Kitchensink fails "assert((((klass)->trace_id() > & (JfrTraceIdEpoch::leakp_in_use_this_epoch_bit())) != 0)) failed: > invariant" > > 11u: > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/9b8d1c75f8c7 > backport 8232096: RecordingInfo should use textual representation of path > http://cr.openjdk.java.net/~wzhuo/8185525/webrev.00/ (reviewing) > backport 8185525: Add JFR event for DictionarySizes > > 8u: > http://cr.openjdk.java.net/~ddong/8144732/hotspot.01/ (reviewing) > backport 8144732: VM_HeapDumper hits assert with bad dump_len > http://cr.openjdk.java.net/~ddong/8232355/hotspot.00/ (reviewing) > 8232355: Two obsolete flags have the wrong obsolete version in 8u > > Votes are due by Nov 13th 19:00 CET. > > Only current JDK Committers [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 [2]. > > [1] https://openjdk.java.net/census#ddong > [2] http://openjdk.java.net/bylaws#lazy-consensus > [3] https://openjdk.java.net/census > > From hohensee at amazon.com Wed Oct 30 14:20:06 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 30 Oct 2019 14:20:06 +0000 Subject: New JDK Committer: Denghui Dong In-Reply-To: References: Message-ID: Vote: yes ?On 10/30/19, 5:42 AM, "jdk8u-dev on behalf of Mario Torre" wrote: Hi all, I hereby nominate Denghui Dong (denghui.ddh at alibaba-inc.com) [1] to JDK 8 Update committer. Denghui has been contributing a large number of backports for the Flight Recorder incubator project and is one of the authors of the original backport patch. Some of the backports include: jdk8u-jfr-incubator: http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/hotspot/rev/a248d0be1309 http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/jdk/rev/625378d53fb1 8229401: Fix JFR code cache test failures 8223689: Add JFR Thread Sampling Support 8223690: Add JFR BiasedLock Event Support 8223691: Add JFR G1 Region Type Change Event Support 8223692: Add JFR G1 Heap Summary Event Support http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/hotspot/rev/8e875c964f41 backport 8232117: JFR: Old Object Sample event slow on a deep heap in debug builds backport 8232799: assert(is_aligned(ref, HeapWordSize)) failed: invariant backport 8232800: Regression caused by JDK-8214542 not installing complete checkpoint data to candidates http://cr.openjdk.java.net/~ddong/8227605/hotspot.00/ (reviewing) backport 8227605: Kitchensink fails "assert((((klass)->trace_id() & (JfrTraceIdEpoch::leakp_in_use_this_epoch_bit())) != 0)) failed: invariant" 11u: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/9b8d1c75f8c7 backport 8232096: RecordingInfo should use textual representation of path http://cr.openjdk.java.net/~wzhuo/8185525/webrev.00/ (reviewing) backport 8185525: Add JFR event for DictionarySizes 8u: http://cr.openjdk.java.net/~ddong/8144732/hotspot.01/ (reviewing) backport 8144732: VM_HeapDumper hits assert with bad dump_len http://cr.openjdk.java.net/~ddong/8232355/hotspot.00/ (reviewing) 8232355: Two obsolete flags have the wrong obsolete version in 8u Votes are due by Nov 13th 19:00 CET. Only current JDK Committers [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 [2]. [1] https://openjdk.java.net/census#ddong [2] http://openjdk.java.net/bylaws#lazy-consensus [3] https://openjdk.java.net/census -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From yan at azul.com Wed Oct 30 14:25:14 2019 From: yan at azul.com (Yuri Nesterenko) Date: Wed, 30 Oct 2019 17:25:14 +0300 Subject: CFV: New JDK Committer: Denghui Dong In-Reply-To: References: Message-ID: Vote: yes On 30.10.2019 15:41, Mario Torre wrote: > Hi all, > > I hereby nominate Denghui Dong (denghui.ddh at alibaba-inc.com) [1] to > JDK 8 Update committer. > > Denghui has been contributing a large number of backports for the > Flight Recorder incubator project and is one of the authors of the > original backport patch. > > Some of the backports include: > > jdk8u-jfr-incubator: > http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/hotspot/rev/a248d0be1309 > http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/jdk/rev/625378d53fb1 > 8229401: Fix JFR code cache test failures > 8223689: Add JFR Thread Sampling Support > 8223690: Add JFR BiasedLock Event Support > 8223691: Add JFR G1 Region Type Change Event Support > 8223692: Add JFR G1 Heap Summary Event Support > > http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/hotspot/rev/8e875c964f41 > backport 8232117: JFR: Old Object Sample event slow on a deep heap > in debug builds > backport 8232799: assert(is_aligned(ref, HeapWordSize)) failed: invariant > backport 8232800: Regression caused by JDK-8214542 not installing > complete checkpoint data to candidates > > http://cr.openjdk.java.net/~ddong/8227605/hotspot.00/ (reviewing) > backport 8227605: Kitchensink fails "assert((((klass)->trace_id() > & (JfrTraceIdEpoch::leakp_in_use_this_epoch_bit())) != 0)) failed: > invariant" > > 11u: > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/9b8d1c75f8c7 > backport 8232096: RecordingInfo should use textual representation of path > http://cr.openjdk.java.net/~wzhuo/8185525/webrev.00/ (reviewing) > backport 8185525: Add JFR event for DictionarySizes > > 8u: > http://cr.openjdk.java.net/~ddong/8144732/hotspot.01/ (reviewing) > backport 8144732: VM_HeapDumper hits assert with bad dump_len > http://cr.openjdk.java.net/~ddong/8232355/hotspot.00/ (reviewing) > 8232355: Two obsolete flags have the wrong obsolete version in 8u > > Votes are due by Nov 13th 19:00 CET. > > Only current JDK Committers [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 [2]. > > [1] https://openjdk.java.net/census#ddong > [2] http://openjdk.java.net/bylaws#lazy-consensus > [3] https://openjdk.java.net/census > > From neugens at redhat.com Wed Oct 30 15:01:32 2019 From: neugens at redhat.com (Mario Torre) Date: Wed, 30 Oct 2019 16:01:32 +0100 Subject: RFR: Backport of JDK-8212071 to jdk8u-dev Message-ID: Hi all, I would like to backport the following bug to jdk8u-dev: https://bugs.openjdk.java.net/browse/JDK-8212071 The original patch did not apply cleanly due to JDK-8217731, however the jdk11-dev patch applies without modifications (except from the path changes of course): http://cr.openjdk.java.net/~neugens/8212071/webrev.00/ Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From hohensee at amazon.com Wed Oct 30 15:13:19 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 30 Oct 2019 15:13:19 +0000 Subject: Backport of JDK-8212071 to jdk8u-dev In-Reply-To: References: Message-ID: <15D74CE5-CE1C-4792-A0D7-CE1069CC51D8@amazon.com> Looks good. Paul ?On 10/30/19, 8:03 AM, "jdk8u-dev on behalf of Mario Torre" wrote: Hi all, I would like to backport the following bug to jdk8u-dev: https://bugs.openjdk.java.net/browse/JDK-8212071 The original patch did not apply cleanly due to JDK-8217731, however the jdk11-dev patch applies without modifications (except from the path changes of course): http://cr.openjdk.java.net/~neugens/8212071/webrev.00/ Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From sgehwolf at redhat.com Wed Oct 30 15:46:02 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 30 Oct 2019 16:46:02 +0100 Subject: RFR: Backport of JDK-8212071 to jdk8u-dev In-Reply-To: References: Message-ID: <0f2366973ad071847284d893bcd03d2f2956f7e4.camel@redhat.com> Hi, On Wed, 2019-10-30 at 16:01 +0100, Mario Torre wrote: > Hi all, > > I would like to backport the following bug to jdk8u-dev: > > https://bugs.openjdk.java.net/browse/JDK-8212071 > > The original patch did not apply cleanly due to JDK-8217731, however > the jdk11-dev patch applies without modifications (except from the > path changes of course): > > http://cr.openjdk.java.net/~neugens/8212071/webrev.00/ Are you sure this is an jdk8u webrev? It looks like an 11u webrev to me. I'm confused. Thanks, Severin From neugens at redhat.com Wed Oct 30 16:26:19 2019 From: neugens at redhat.com (Mario Torre) Date: Wed, 30 Oct 2019 17:26:19 +0100 Subject: RFR: Backport of JDK-8212071 to jdk8u-dev In-Reply-To: <0f2366973ad071847284d893bcd03d2f2956f7e4.camel@redhat.com> References: <0f2366973ad071847284d893bcd03d2f2956f7e4.camel@redhat.com> Message-ID: Hi Severin, Yes, it's the 11 webrev, I posted here for reference since this patch applies cleanly with the exception of the paths, however the 11 backport had to be modified. I can upload the 8 webrev of course if you would like. Cheers, Mario On Wed, Oct 30, 2019 at 4:46 PM Severin Gehwolf wrote: > > Hi, > > On Wed, 2019-10-30 at 16:01 +0100, Mario Torre wrote: > > Hi all, > > > > I would like to backport the following bug to jdk8u-dev: > > > > https://bugs.openjdk.java.net/browse/JDK-8212071 > > > > The original patch did not apply cleanly due to JDK-8217731, however > > the jdk11-dev patch applies without modifications (except from the > > path changes of course): > > > > http://cr.openjdk.java.net/~neugens/8212071/webrev.00/ > > Are you sure this is an jdk8u webrev? It looks like an 11u webrev to > me. I'm confused. > > Thanks, > Severin > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From sgehwolf at redhat.com Wed Oct 30 16:44:28 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 30 Oct 2019 17:44:28 +0100 Subject: RFR: Backport of JDK-8212071 to jdk8u-dev In-Reply-To: References: <0f2366973ad071847284d893bcd03d2f2956f7e4.camel@redhat.com> Message-ID: <684c3e7dddc6d814f41274903ad61e885f32ff86.camel@redhat.com> Hi Mario, On Wed, 2019-10-30 at 17:26 +0100, Mario Torre wrote: > Hi Severin, > > Yes, it's the 11 webrev, I posted here for reference since this patch > applies cleanly with the exception of the paths, however the 11 > backport had to be modified. I can upload the 8 webrev of course if > you would like. I see. In that case sending this extra email is just noise, IMHO. In general, I think it's acceptable if there are path changes only between 11 and 8 to add a "Fix Request 8u" comment saying as much. It doesn't need a review, just approval. If you do want to send an email to jdk8u-dev for review, then it would be nicer for the reviewer to upload the actual 8u patch. Does that make sense? Thanks, Severin > On Wed, Oct 30, 2019 at 4:46 PM Severin Gehwolf wrote: > > Hi, > > > > On Wed, 2019-10-30 at 16:01 +0100, Mario Torre wrote: > > > Hi all, > > > > > > I would like to backport the following bug to jdk8u-dev: > > > > > > https://bugs.openjdk.java.net/browse/JDK-8212071 > > > > > > The original patch did not apply cleanly due to JDK-8217731, however > > > the jdk11-dev patch applies without modifications (except from the > > > path changes of course): > > > > > > http://cr.openjdk.java.net/~neugens/8212071/webrev.00/ > > > > Are you sure this is an jdk8u webrev? It looks like an 11u webrev to > > me. I'm confused. > > > > Thanks, > > Severin > > > > From neugens at redhat.com Wed Oct 30 16:50:02 2019 From: neugens at redhat.com (Mario Torre) Date: Wed, 30 Oct 2019 17:50:02 +0100 Subject: RFR: Backport of JDK-8212071 to jdk8u-dev In-Reply-To: <684c3e7dddc6d814f41274903ad61e885f32ff86.camel@redhat.com> References: <0f2366973ad071847284d893bcd03d2f2956f7e4.camel@redhat.com> <684c3e7dddc6d814f41274903ad61e885f32ff86.camel@redhat.com> Message-ID: On Wed, Oct 30, 2019 at 5:44 PM Severin Gehwolf wrote: > > Hi Mario, > > On Wed, 2019-10-30 at 17:26 +0100, Mario Torre wrote: > > Hi Severin, > > > > Yes, it's the 11 webrev, I posted here for reference since this patch > > applies cleanly with the exception of the paths, however the 11 > > backport had to be modified. I can upload the 8 webrev of course if > > you would like. > > I see. In that case sending this extra email is just noise, IMHO. > > In general, I think it's acceptable if there are path changes only > between 11 and 8 to add a "Fix Request 8u" comment saying as much. It > doesn't need a review, just approval. > > If you do want to send an email to jdk8u-dev for review, then it would > be nicer for the reviewer to upload the actual 8u patch. Does that make > sense? Well, the patch is really the same. the reason I sent the email is that the patch is different from 14 to 11, but the 11 patch applies to 8 as is, so I think who approves the patch should be aware of this, hence the email. 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 Wed Oct 30 22:41:34 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 30 Oct 2019 22:41:34 +0000 Subject: CFV: New JDK Committer: Denghui Dong In-Reply-To: References: Message-ID: Vote:yes > -----Original Message----- > From: jdk8u-dev On Behalf Of > Mario Torre > Sent: Mittwoch, 30. Oktober 2019 13:42 > To: jdk8u-dev > Subject: CFV: New JDK Committer: Denghui Dong > > Hi all, > > I hereby nominate Denghui Dong (denghui.ddh at alibaba-inc.com) [1] to > JDK 8 Update committer. > > Denghui has been contributing a large number of backports for the > Flight Recorder incubator project and is one of the authors of the > original backport patch. > > Some of the backports include: > > jdk8u-jfr-incubator: > http://hg.openjdk.java.net/jdk8u/jdk8u-jfr- > incubator/hotspot/rev/a248d0be1309 > http://hg.openjdk.java.net/jdk8u/jdk8u-jfr- > incubator/jdk/rev/625378d53fb1 > 8229401: Fix JFR code cache test failures > 8223689: Add JFR Thread Sampling Support > 8223690: Add JFR BiasedLock Event Support > 8223691: Add JFR G1 Region Type Change Event Support > 8223692: Add JFR G1 Heap Summary Event Support > > http://hg.openjdk.java.net/jdk8u/jdk8u-jfr- > incubator/hotspot/rev/8e875c964f41 > backport 8232117: JFR: Old Object Sample event slow on a deep heap > in debug builds > backport 8232799: assert(is_aligned(ref, HeapWordSize)) failed: invariant > backport 8232800: Regression caused by JDK-8214542 not installing > complete checkpoint data to candidates > > http://cr.openjdk.java.net/~ddong/8227605/hotspot.00/ (reviewing) > backport 8227605: Kitchensink fails "assert((((klass)->trace_id() > & (JfrTraceIdEpoch::leakp_in_use_this_epoch_bit())) != 0)) failed: > invariant" > > 11u: > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/9b8d1c75f8c7 > backport 8232096: RecordingInfo should use textual representation of path > http://cr.openjdk.java.net/~wzhuo/8185525/webrev.00/ (reviewing) > backport 8185525: Add JFR event for DictionarySizes > > 8u: > http://cr.openjdk.java.net/~ddong/8144732/hotspot.01/ (reviewing) > backport 8144732: VM_HeapDumper hits assert with bad dump_len > http://cr.openjdk.java.net/~ddong/8232355/hotspot.00/ (reviewing) > 8232355: Two obsolete flags have the wrong obsolete version in 8u > > Votes are due by Nov 13th 19:00 CET. > > Only current JDK Committers [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 [2]. > > [1] https://openjdk.java.net/census#ddong > [2] http://openjdk.java.net/bylaws#lazy-consensus > [3] https://openjdk.java.net/census > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From hohensee at amazon.com Thu Oct 31 00:21:40 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 31 Oct 2019 00:21:40 +0000 Subject: [8u] RFR: 8233023: assert(Opcode() == mem->Opcode() || phase->C->get_alias_index(adr_type()) == Compile::AliasIdxRaw) failed: no mismatched stores, except on raw memory In-Reply-To: <7a2d50793120bdeb86d0047fd09db18c725328e0.camel@redhat.com> References: <7a2d50793120bdeb86d0047fd09db18c725328e0.camel@redhat.com> Message-ID: Lgtm. Paul ?On 10/30/19, 2:42 AM, "jdk8u-dev on behalf of Severin Gehwolf" wrote: Hi, Could I please get a review of this 8u only issue? The reason a fastdebug build of latest OpenJDK 8u asserts for the dec-tree benchmark of the renaissance suite is because the 8u backport of JDK-8140309 was missing this hunk from JDK 9[1]: + (Opcode() == Op_StoreL && st->Opcode() == Op_StoreI) || // expanded ClearArrayNode + (is_mismatched_access() || st->as_Store()->is_mismatched_access()), I had a closer look and there doesn't seem to be missing anything else. The proposed fix is to amend the assert condition in the appropriate place, which brings 8u in line with JDK 9 code where the failure isn't observed. Bug: https://bugs.openjdk.java.net/browse/JDK-8233023 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233023/01/webrev/ Testing: 8u tier1 test set with fastdebug build on x86_64 Linux. No new failures. dec-tree benchmark now runs successfully on an 8u fastdebug build. Thoughts? Thanks, Severin [1] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/4bee38ba018c From sgehwolf at redhat.com Thu Oct 31 09:14:50 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 31 Oct 2019 10:14:50 +0100 Subject: [8u] RFR: 8233023: assert(Opcode() == mem->Opcode() || phase->C->get_alias_index(adr_type()) == Compile::AliasIdxRaw) failed: no mismatched stores, except on raw memory In-Reply-To: References: <7a2d50793120bdeb86d0047fd09db18c725328e0.camel@redhat.com> Message-ID: <2c7a6e1a803213f4bfc983f13db596b40f2838b3.camel@redhat.com> On Thu, 2019-10-31 at 00:21 +0000, Hohensee, Paul wrote: > Lgtm. Thanks for the review, Paul! Cheers, Severin > Paul > > ?On 10/30/19, 2:42 AM, "jdk8u-dev on behalf of Severin Gehwolf" wrote: > > Hi, > > Could I please get a review of this 8u only issue? The reason a > fastdebug build of latest OpenJDK 8u asserts for the dec-tree benchmark > of the renaissance suite is because the 8u backport of JDK-8140309 was > missing this hunk from JDK 9[1]: > > + (Opcode() == Op_StoreL && st->Opcode() == Op_StoreI) || // expanded ClearArrayNode > + (is_mismatched_access() || st->as_Store()->is_mismatched_access()), > > I had a closer look and there doesn't seem to be missing anything else. > The proposed fix is to amend the assert condition in the appropriate > place, which brings 8u in line with JDK 9 code where the failure isn't > observed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8233023 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233023/01/webrev/ > > Testing: 8u tier1 test set with fastdebug build on x86_64 Linux. No new > failures. dec-tree benchmark now runs successfully on an 8u fastdebug > build. > > Thoughts? > > Thanks, > Severin > > [1] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/4bee38ba018c > > > From vkempik at azul.com Thu Oct 31 11:11:18 2019 From: vkempik at azul.com (Vladimir Kempik) Date: Thu, 31 Oct 2019 11:11:18 +0000 Subject: CFV: New JDK Committer: Denghui Dong In-Reply-To: References: Message-ID: <1CC6F0D4-F59B-479D-B150-E0824F0FB88B@azul.com> Vote: Yes > 30 ???. 2019 ?., ? 15:41, Mario Torre ???????(?): > > Hi all, > > I hereby nominate Denghui Dong (denghui.ddh at alibaba-inc.com) [1] to > JDK 8 Update committer. > > Denghui has been contributing a large number of backports for the > Flight Recorder incubator project and is one of the authors of the > original backport patch. > > Some of the backports include: > > jdk8u-jfr-incubator: > http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/hotspot/rev/a248d0be1309 > http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/jdk/rev/625378d53fb1 > 8229401: Fix JFR code cache test failures > 8223689: Add JFR Thread Sampling Support > 8223690: Add JFR BiasedLock Event Support > 8223691: Add JFR G1 Region Type Change Event Support > 8223692: Add JFR G1 Heap Summary Event Support > > http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/hotspot/rev/8e875c964f41 > backport 8232117: JFR: Old Object Sample event slow on a deep heap > in debug builds > backport 8232799: assert(is_aligned(ref, HeapWordSize)) failed: invariant > backport 8232800: Regression caused by JDK-8214542 not installing > complete checkpoint data to candidates > > http://cr.openjdk.java.net/~ddong/8227605/hotspot.00/ (reviewing) > backport 8227605: Kitchensink fails "assert((((klass)->trace_id() > & (JfrTraceIdEpoch::leakp_in_use_this_epoch_bit())) != 0)) failed: > invariant" > > 11u: > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/9b8d1c75f8c7 > backport 8232096: RecordingInfo should use textual representation of path > http://cr.openjdk.java.net/~wzhuo/8185525/webrev.00/ (reviewing) > backport 8185525: Add JFR event for DictionarySizes > > 8u: > http://cr.openjdk.java.net/~ddong/8144732/hotspot.01/ (reviewing) > backport 8144732: VM_HeapDumper hits assert with bad dump_len > http://cr.openjdk.java.net/~ddong/8232355/hotspot.00/ (reviewing) > 8232355: Two obsolete flags have the wrong obsolete version in 8u > > Votes are due by Nov 13th 19:00 CET. > > Only current JDK Committers [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 [2]. > > [1] https://openjdk.java.net/census#ddong > [2] http://openjdk.java.net/bylaws#lazy-consensus > [3] https://openjdk.java.net/census > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From yan at azul.com Thu Oct 31 11:11:22 2019 From: yan at azul.com (Yuri Nesterenko) Date: Thu, 31 Oct 2019 14:11:22 +0300 Subject: RFR(8u): 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: References: <5CCC5140-4C75-45CD-A3A2-CC0237DD7AD9@azul.com> <7B2B9DF5-F845-42FC-949C-102B72282975@amazon.com> Message-ID: Hi Vladimir, the patch looks good to me. --yan On 28.10.2019 12:20, Vladimir Kempik wrote: > Hello > Can anyone please take a look at this patch? > The difference between 11 and 8 is pretty simple: move one method from superclass to subclass to prevent it being compiled on every Unix system(it can?t be compiled on solaris). This code is only used on Linux so far. > > Thanks, Vladimir > > 21 ???. 2019 ?., ? 19:23, Hohensee, Paul > ???????(?): > > +jdk8u-dev > > Paul > > From: nio-dev > on behalf of Vladimir Kempik > > Date: Monday, October 21, 2019 at 2:47 AM > To: "nio-dev at openjdk.java.net" > > Subject: RFR(8u): 8229872: (fs) Increase buffer size used with getmntent > > Hello > > Please review backport of https://bugs.openjdk.java.net/browse/JDK-8229872 to 8u: > http://cr.openjdk.java.net/~vkempik/8229872/ojdk8/webrev.00/ > > Difference between 14/13/11 fix: getline is missing on solaris10, so getlinelen method was moved from UnixNativeDispatcher to LinuxNativeDispatcher. > Original fix: https://hg.openjdk.java.net/jdk/jdk/rev/2d40e6a7ce8e > > Such fix was already included into azul?s october psu for openjdk8 and passed all release cycle tests. > > Thanks, Vladimir > From gnu.andrew at redhat.com Thu Oct 31 12:42:20 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 31 Oct 2019 12:42:20 +0000 Subject: [8u] RFR (XS) 8231398: Add time tracing for gc log rotation at safepoint cleanup In-Reply-To: <6528b956-d168-a8cf-de96-4bdf708e8632@redhat.com> References: <6528b956-d168-a8cf-de96-4bdf708e8632@redhat.com> Message-ID: On 01/10/2019 11:16, Aleksey Shipilev wrote: > Thanks Paul. > > I'll wait for 8u approval now. > > -Aleksey > > On 9/25/19 7:35 PM, Hohensee, Paul wrote: >> 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 >> >> >> > > I was expecting this to be more convoluted from the description, but certainly have no problem with this one-liner :) Certainly don't want to be backporting something like JDK-8145092. Looks good and 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 jvanek at redhat.com Thu Oct 31 12:46:54 2019 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 31 Oct 2019 13:46:54 +0100 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> <5a5b4981c6c1497b593aa245830a45efc5a26803.camel@redhat.com> <4dd8b5df-3284-41dd-8fa1-9061e016cedf@redhat.com> <53908e96663b8e8df468fafc0f7864217b392fef.camel@redhat.com> Message-ID: <7da40825-962f-e6dc-5139-823f858ab32a@redhat.com> Hi! Now when the forests are again unfrozen, can you please push this, or mark the bug as no go for jdk8u? Thanx! J. On 9/4/19 6:39 AM, Andrew John Hughes wrote: > > > 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, > -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek at redhat.com M: +420775390109 From gnu.andrew at redhat.com Thu Oct 31 12:56:11 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 31 Oct 2019 12:56:11 +0000 Subject: [8u] RFR: 8134739: compiler/loopopts/superword/TestVectorizationWithInvariant crashes in loop opts In-Reply-To: <10ff8496-0175-da1c-8b5c-0d89be8bd9d0@redhat.com> References: <87y2xuz6v5.fsf@redhat.com> <10ff8496-0175-da1c-8b5c-0d89be8bd9d0@redhat.com> Message-ID: <97c02fce-a9ea-3a0c-f57c-3fa99d9606ce@redhat.com> On 25/10/2019 13:04, Aleksey Shipilev wrote: > On 10/9/19 9:59 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~roland/8134739.8u/webrev.00/ > > Backport looks good. > > So the only conflict in jdk8u-dev right now is different "phi()" in loopnode.hpp, and superword.cpp > actually applies without conflicts, right? I was staring into superword.cpp trying to see the > difference, and there does not seem to be any. > No difference for me either in comparing the two patches. The meat of this is slightly obscured by the original author deciding it would be a good time to move the position of the '*' in a number of statements, making that the only change in some lines. The actual change is to filter out some scenarios by returning NULL. Looks fine to me. 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 Oct 31 13:25:32 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 31 Oct 2019 13:25:32 +0000 Subject: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len 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: <260788c0-207d-8cfd-5492-8750d02e42d7@redhat.com> On 25/09/2019 07:25, Denghui Dong wrote: > 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 > I'm concerned that this alters the HPROF format used for dumps under 2GB [0] Is there no other way of fixing the bug without altering this, which may have an impact on tools expecting to parse HPROF 1.0.1 format data. I guess HPROF 1.0.2 support was already required for larger dumps, so I'm not sure how much of an issue this is, but it's definitely a compatibility change. [0] https://bugs.openjdk.java.net/browse/JDK-8174881 -- 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 verghese at amazon.com Thu Oct 31 16:59:01 2019 From: verghese at amazon.com (Verghese, Clive) Date: Thu, 31 Oct 2019 16:59:01 +0000 Subject: [8u] RFR: 8218580: endpoint identification algorithm should be case-insensitive Message-ID: <7B408184-7E67-4185-A595-8C92303D2B0D@amazon.com> Hi, I am requesting review for backport of JDK-8218580 Webrev : http://cr.openjdk.java.net/~phh/8218580/webrev.8u.00/ JBS Bug : https://bugs.openjdk.java.net/browse/JDK-8218580 Original Change : http://hg.openjdk.java.net/jdk/jdk/rev/c34acb3a3330 Change Set for JDK 11 : http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/148957581f5c The JBS Bug marks the issue as Introduced in 11. But checking the 8u code, it looks like the bug is effecting 8u as well. The backport to 8u did not apply cleanly. Other than the filename changes and line number changes, one of the notable changes is that only 2 of the 3 hunks applied in ClientHandshaker.java. The patch has passed tier-1 in Linux and no new regressions were found. Regards, Clive Verghese From shade at redhat.com Thu Oct 31 18:38:40 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 31 Oct 2019 19:38:40 +0100 Subject: [8u] RFR (XS) 8231398: Add time tracing for gc log rotation at safepoint cleanup In-Reply-To: References: <6528b956-d168-a8cf-de96-4bdf708e8632@redhat.com> Message-ID: <7589b2c0-ff17-37e6-c86c-996b284af063@redhat.com> On 10/31/19 1:42 PM, Andrew John Hughes wrote: > I was expecting this to be more convoluted from the description, but > certainly have no problem with this one-liner :) Yes, it is the absence of fixable little things that is sad. > Looks good and approved. Pushed! -- Thanks, -Aleksey