From goetz.lindenmaier at sap.com Tue Oct 1 06:44:15 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 1 Oct 2019 06:44:15 +0000 Subject: Bad push for JDK-8230728: Thin stroked shapes are not rendered if affine transform has flip bit In-Reply-To: References: Message-ID: Hi Laurent, please open a JBS Issue 'Backout "8230728: Thin stroked shapes are not rendered if affine transform has flip bit" from jdk11u' and send a RFR with the backout change. Tag it as jdk11u-critical-request. Also, I see crashes in our tests that were triggered by your push. I didn't investigate, but they are in the fonts area. The following jtreg tests crashed on AIX: javax/swing/Headless/HeadlessJMenuBar.java javax/swing/Headless/HeadlessJSlider.java javax/swing/Headless/HeadlessJTextArea.java javax/swing/Headless/HeadlessJToolBar_Separator.java javax/swing/Headless/HeadlessJToolBar.java # # A fatal error has been detected by the Java Runtime Environment: # # SIGBUS (0xa) at pc=0x0900000006f917b8, pid=13959206, tid=5141 # # JRE version: OpenJDK Runtime Environment (11.0.5) (build 11.0.5-internal+0-adhoc.openjdk.jdk11u) # Java VM: OpenJDK 64-Bit Server VM (11.0.5-internal+0-adhoc.openjdk.jdk11u, mixed mode, tiered, compressed oops, g1 gc, aix-ppc64) # Problematic frame: # C 0x0900000006f917b8 # 0x0000000116b081d0 - 0x0900000006f8a094 (unknown module)::(unknown function)+? 0x0000000116b08260 - 0x0900000006f8a150 (unknown module)::(unknown function)+? 0x0000000116b082d0 - 0x0900000006f8ace0 (unknown module)::(unknown function)+? 0x0000000116b08340 - 0x090000000482e79c libawt_headless.so::Java_sun_font_FontConfigManager_getFontConfig+0x61c (C saves_cr saves_lr stores_bc gpr_saved:18 fixedparms:6 ) 0x0000000116b08580 - 0x0a0001000000ed7c (unknown module)::(unknown function)+? 0x0000000116b086a0 - 0x0a000100000085a8 (unknown module)::(unknown function)+? 0x0000000116b08770 - 0x0a000100000085a8 (unknown module)::(unknown function)+? 0x0000000116b08870 - 0x0a00010000008300 (unknown module)::(unknown function)+? 0x0000000116b08930 - 0x0a000100000009cc (unknown module)::(unknown function)+? 0x0000000116b08ae0 - 0x09000000050f9598 libjvm.so::JavaCalls::call_helper(JavaValue*,const methodHandle&,JavaCallArguments*,Thread*)+0x438 (C++ saves_lr stores_bc gpr_saved:15 fixedparms:4 ) 0x0000000116b08ca0 - 0x09000000049bb2f8 libjvm.so::os::os_exception_wrapper(void(*)(JavaValue*,const methodHandle&,JavaCallArguments*,Thread*),JavaValue*,const methodHandle&,JavaCallArguments*,Thread*)+0x38 (C++ saves_lr stores_bc fixedparms:5 ) 0x0000000116b08d10 - 0x09000000050fc834 libjvm.so::JavaCalls::call(JavaValue*,const methodHandle&,JavaCallArguments*,Thread*)+0x34 (C++ saves_lr stores_bc fixedparms:4 ) 0x0000000116b08d80 - 0x090000000494e994 libjvm.so::JVM_DoPrivileged+0xc14 (C++ saves_lr stores_bc gpr_saved:14 fixedparms:5 ) 0x0000000116b09750 - 0x090000000479a318 libjava.so::Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedAction_2+0x18 (C saves_lr stores_bc fixedparms:3 ) 0x0000000116b097c0 - 0x0a0001000000ed7c (unknown module)::(unknown function)+? 0x0000000116b098e0 - 0x0a00010000008300 (unknown module)::(unknown function)+? Crash on AIX in an SAP application we test: 0x0000000119327d30 - 0x0900000006f8a150 (unknown module)::(unknown function)+? 0x0000000119327da0 - 0x0900000006fb1970 (unknown module)::(unknown function)+? 0x0000000119327e20 - 0x0900000006f914e8 (unknown module)::(unknown function)+? 0x0000000119327eb0 - 0x0900000006914ee4 libawt_headless.so::getFontConfigLocations+0x1c4 (C saves_lr stores_bc gpr_saved:18 ) 0x0000000119327fc0 - 0x09000000069146c0 libawt_headless.so::getPlatformFontPathChars+0x20 (C saves_lr stores_bc gpr_saved:3 fixedparms:3 ) 0x0000000119328050 - 0x0900000006914618 libawt_headless.so::Java_sun_awt_FcFontManager_getFontPathNative+0x78 (C saves_lr stores_bc gpr_saved:1 fixedparms:4 ) 0x00000001193280e0 - 0x0a00010028fb28ec (unknown module)::(unknown function)+? 0x00000001193281a0 - 0x0a00010003c21b88 (unknown module)::(unknown function)+? So maybe we should investigate this before pushing to jdk11u-dev. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Laurent Bourg?s > Sent: Montag, 30. September 2019 18:13 > To: jdk-updates-dev at openjdk.java.net > Subject: Bad push for JDK-8230728: Thin stroked shapes are not rendered if > affine transform has flip bit > > Hi, > > I pushed by mistake on the jdk11u (11.0.5) repository, not on jdk11u-dev ! > Sorry, sorry, sorry. > Previously I only had to deal with 10u, 12u... > > See https://bugs.openjdk.java.net/browse/JDK-8231621 > > How can I (or you) revert that changeset ? What is the process ? > > PS: I will get rid of my local copy jdk11u (master), I already retrieved > the jdk11u-dev to use instead. > > Thanks for your help, > Laurent From christoph.langer at sap.com Tue Oct 1 07:12:39 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 1 Oct 2019 07:12:39 +0000 Subject: Bad push for JDK-8230728: Thin stroked shapes are not rendered if affine transform has flip bit In-Reply-To: References: Message-ID: Hi Goetz, Laurent, I had a look to the AIX test failures that we observe. It seems more likely to me that it is not related to the push of 8230728 but to another issue with fontconfig on AIX which we're chasing for several weeks now. So technically I think there's nothing wrong with the push. But since we're in the CPU phase of 11.0.5 the change should be reverted in 11u and be pushed to 11u-dev. So, @Laurent, please do the backout as outlined by Goetz and push your change to jdk11u-dev as well. Thanks Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Dienstag, 1. Oktober 2019 08:44 > To: Laurent Bourg?s ; jdk-updates- > dev at openjdk.java.net > Subject: [CAUTION] RE: Bad push for JDK-8230728: Thin stroked shapes are > not rendered if affine transform has flip bit > > Hi Laurent, > > please open a JBS Issue > 'Backout "8230728: Thin stroked shapes are not rendered if affine transform > has flip bit" from jdk11u' > and send a RFR with the backout change. Tag it as jdk11u-critical-request. > > Also, I see crashes in our tests that were triggered by your > push. I didn't investigate, but they are in the fonts area. > > The following jtreg tests crashed on AIX: > javax/swing/Headless/HeadlessJMenuBar.java > javax/swing/Headless/HeadlessJSlider.java > javax/swing/Headless/HeadlessJTextArea.java > javax/swing/Headless/HeadlessJToolBar_Separator.java > javax/swing/Headless/HeadlessJToolBar.java > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGBUS (0xa) at pc=0x0900000006f917b8, pid=13959206, tid=5141 > # > # JRE version: OpenJDK Runtime Environment (11.0.5) (build 11.0.5- > internal+0-adhoc.openjdk.jdk11u) > # Java VM: OpenJDK 64-Bit Server VM (11.0.5-internal+0- > adhoc.openjdk.jdk11u, mixed mode, tiered, compressed oops, g1 gc, aix- > ppc64) > # Problematic frame: > # C 0x0900000006f917b8 > # > > 0x0000000116b081d0 - 0x0900000006f8a094 (unknown module)::(unknown > function)+? > 0x0000000116b08260 - 0x0900000006f8a150 (unknown module)::(unknown > function)+? > 0x0000000116b082d0 - 0x0900000006f8ace0 (unknown module)::(unknown > function)+? > 0x0000000116b08340 - 0x090000000482e79c > libawt_headless.so::Java_sun_font_FontConfigManager_getFontConfig+0x6 > 1c (C saves_cr saves_lr stores_bc gpr_saved:18 fixedparms:6 ) > 0x0000000116b08580 - 0x0a0001000000ed7c (unknown module)::(unknown > function)+? > 0x0000000116b086a0 - 0x0a000100000085a8 (unknown module)::(unknown > function)+? > 0x0000000116b08770 - 0x0a000100000085a8 (unknown module)::(unknown > function)+? > 0x0000000116b08870 - 0x0a00010000008300 (unknown module)::(unknown > function)+? > 0x0000000116b08930 - 0x0a000100000009cc (unknown module)::(unknown > function)+? > 0x0000000116b08ae0 - 0x09000000050f9598 > libjvm.so::JavaCalls::call_helper(JavaValue*,const > methodHandle&,JavaCallArguments*,Thread*)+0x438 (C++ saves_lr > stores_bc gpr_saved:15 fixedparms:4 ) > 0x0000000116b08ca0 - 0x09000000049bb2f8 > libjvm.so::os::os_exception_wrapper(void(*)(JavaValue*,const > methodHandle&,JavaCallArguments*,Thread*),JavaValue*,const > methodHandle&,JavaCallArguments*,Thread*)+0x38 (C++ saves_lr > stores_bc fixedparms:5 ) > 0x0000000116b08d10 - 0x09000000050fc834 > libjvm.so::JavaCalls::call(JavaValue*,const > methodHandle&,JavaCallArguments*,Thread*)+0x34 (C++ saves_lr > stores_bc fixedparms:4 ) > 0x0000000116b08d80 - 0x090000000494e994 > libjvm.so::JVM_DoPrivileged+0xc14 (C++ saves_lr stores_bc gpr_saved:14 > fixedparms:5 ) > 0x0000000116b09750 - 0x090000000479a318 > libjava.so::Java_java_security_AccessController_doPrivileged__Ljava_securit > y_PrivilegedAction_2+0x18 (C saves_lr stores_bc fixedparms:3 ) > 0x0000000116b097c0 - 0x0a0001000000ed7c (unknown module)::(unknown > function)+? > 0x0000000116b098e0 - 0x0a00010000008300 (unknown module)::(unknown > function)+? > > Crash on AIX in an SAP application we test: > > 0x0000000119327d30 - 0x0900000006f8a150 (unknown module)::(unknown > function)+? > 0x0000000119327da0 - 0x0900000006fb1970 (unknown module)::(unknown > function)+? > 0x0000000119327e20 - 0x0900000006f914e8 (unknown module)::(unknown > function)+? > 0x0000000119327eb0 - 0x0900000006914ee4 > libawt_headless.so::getFontConfigLocations+0x1c4 (C saves_lr stores_bc > gpr_saved:18 ) > 0x0000000119327fc0 - 0x09000000069146c0 > libawt_headless.so::getPlatformFontPathChars+0x20 (C saves_lr stores_bc > gpr_saved:3 fixedparms:3 ) > 0x0000000119328050 - 0x0900000006914618 > libawt_headless.so::Java_sun_awt_FcFontManager_getFontPathNative+0x7 > 8 (C saves_lr stores_bc gpr_saved:1 fixedparms:4 ) > 0x00000001193280e0 - 0x0a00010028fb28ec (unknown module)::(unknown > function)+? > 0x00000001193281a0 - 0x0a00010003c21b88 (unknown module)::(unknown > function)+? > > So maybe we should investigate this before pushing to jdk11u-dev. > > Best regards, > Goetz. > > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Laurent Bourg?s > > Sent: Montag, 30. September 2019 18:13 > > To: jdk-updates-dev at openjdk.java.net > > Subject: Bad push for JDK-8230728: Thin stroked shapes are not rendered if > > affine transform has flip bit > > > > Hi, > > > > I pushed by mistake on the jdk11u (11.0.5) repository, not on jdk11u-dev ! > > Sorry, sorry, sorry. > > Previously I only had to deal with 10u, 12u... > > > > See https://bugs.openjdk.java.net/browse/JDK-8231621 > > > > How can I (or you) revert that changeset ? What is the process ? > > > > PS: I will get rid of my local copy jdk11u (master), I already retrieved > > the jdk11u-dev to use instead. > > > > Thanks for your help, > > Laurent From matthias.baesken at sap.com Tue Oct 1 08:18:57 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 1 Oct 2019 08:18:57 +0000 Subject: [11u] RFR: 8220528: [AIX] Fix basic Xinerama and Xrender functionality In-Reply-To: References: Message-ID: Hi Christoph, looks good to me . I think the naming ?xinerama_init_linux? is a bit misleading now , because the function is obviously not any more just for linux : 619 #if defined(__linux__) || defined(MACOSX) || defined(_AIX) 620 static void xinerama_init_linux() But this is out of scope of your downport change . Best regards, Matthias From: Langer, Christoph Sent: Dienstag, 24. September 2019 15:39 To: jdk-updates-dev at openjdk.java.net Cc: 2d-dev at openjdk.java.net Subject: [11u] RFR: 8220528: [AIX] Fix basic Xinerama and Xrender functionality Hi, please help reviewing this backport of the fix for AIX Xinerama/Xrender basic functionality to JDK11 Updates. Bug: https://bugs.openjdk.java.net/browse/JDK-8220528 Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/0223b7b8a1c5 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8220528.11u-dev.0/ The patch did not apply cleanly. I had to manually resolve the part around line 125 because the 11u version defines another function for Solaris that didn?t exist any more in the head version. Furthermore I needed to fix the #ifdef in line 1641 (new) to explicitly refer Solaris. Otherwise it would not build on AIX. Thanks Christoph From christoph.langer at sap.com Tue Oct 1 08:23:00 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 1 Oct 2019 08:23:00 +0000 Subject: [11u] RFR 8217362: Emergency dump does not work when disk=false is set In-Reply-To: References: <610de40c-95b4-4c64-9696-c6fd84815382.denghui.ddh@alibaba-inc.com> <7c2a9819-9559-470b-8226-e42f0bd0b164.denghui.ddh@alibaba-inc.com> Message-ID: Hi guys, sorry that I didn't get back to you earlier on this. I just looked at the webrevs and they are identical and look fine to me. I'll approve the backport request and run it through our testing queue. If everything looks fine, I'll push it tomorrow. As for the patch metadata: When I import from Jie's webrev, e.g. hg qimport https://cr.openjdk.java.net/~jkang/jdk-8217362/webrev.03/jdk11u-dev.changeset, the patch in my repository has the correct metadata. The imported patch from Denghui's webrev (hg qimport http://cr.openjdk.java.net/~wzhuo/8217362/webrev.00/jdk11u-dev.patch) is missing this. Don't know what's causing this, maybe different webrev versions? The individual file diffs show the information. So I'll go with Jie's version then ?? Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Jie Kang > Sent: Donnerstag, 26. September 2019 15:46 > To: Denghui Dong > Cc: jdk-updates-dev > Subject: Re: [11u] RFR 8217362: Emergency dump does not work when > disk=false is set > > Hey Denghui Dong, > > No worries, that is 100% my fault, not yours. > > Ah, I didn't see the information inside the patch file: > http://cr.openjdk.java.net/~wzhuo/8217362/webrev.00/jdk11u-dev.patch > but I do see it in the individual diffs. I was thinking it might be > easier to push your patch if the .patch file has the commit data; this > makes it so $ hg import works smoothly. But, maybe there > is a better way to grab the patch + info from webrev that I'm not > familiar with. > > > Regards, > > > On Thu, Sep 26, 2019 at 9:31 AM Denghui Dong > wrote: > > > > Hi Jie Kang, > > I'm sorry that I didn't browse the previous mail. > > By the way, I think that my webrev has already included the original > commit information, right ? > > > > Thanks, > > Denghui Dong > > > > ------------------------------------------------------------------ > > From:Jie Kang > > Send Time:2019?9?26?(???) 20:50 > > To:???(??) > > Cc:jdk-updates-dev > > Subject:Re: [11u] RFR 8217362: Emergency dump does not work when > disk=false is set > > > > On Thu, Sep 26, 2019 at 3:46 AM ???(??) inc.com> wrote: > > > > > > Hi all, > > > 11u has the same problem. Please review this backport, original patch > doesn't apply cleanly caused by Hunk FAILED > > > in test/jdk/jdk/jfr/jvm/TestDumpOnCrash.java and > src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp > > > > > > 11u-webrev: > > > http://cr.openjdk.java.net/~wzhuo/8217362/webrev.00/ > > > > > > Original bug: > > > https://bugs.openjdk.java.net/browse/JDK-8217362 > > > http://hg.openjdk.java.net/jdk/jdk/rev/3cabb47758c9 > > > > > > Testing: test/jdk/jdk/jfr/jvm/TestDumpOnCrash.java > > > > > > Hi, > > > > Looks like I forgot to update the bug and there was a duplicate of > > work [1] :( That's my fault, sorry for this mistake. > > > > In any case, the changes are identical to mine so I think it looks > > okay, but should include the original commit metadata like author and > > message. Of course I am not a reviewer so another will need to look. > > > > [1] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019- > September/001883.html > > > > Regards, > > > > > > > > Thanks, > > > Denghui Dong From adinn at redhat.com Tue Oct 1 08:33:46 2019 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 1 Oct 2019 09:33:46 +0100 Subject: [11u] RFR: 8228687: [TESTBUG] exclude Container tests from hotspot_misc group In-Reply-To: <37688aafbaab92740bb043efda894b78db56e5dd.camel@redhat.com> References: <37688aafbaab92740bb043efda894b78db56e5dd.camel@redhat.com> Message-ID: <74a3c54e-5763-4741-6148-8eed27907a4a@redhat.com> On 30/09/2019 17:53, Severin Gehwolf wrote: > Could I please get a review of this trivial test bug fix? It brings > OpenJDK 11u one step closer to what's in Oracle JDK 11.0.6. The patch > from JDK head didn't apply cleanly as JDK-8217666 isn't in OpenJDK 11. > I've recreated the patch manually. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8228687 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8228687/01/webrev/ > Original changeset: https://hg.openjdk.java.net/jdk/jdk/rev/a26bc1847594 Looks good. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Tue Oct 1 08:38:07 2019 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 1 Oct 2019 09:38:07 +0100 Subject: [11u] RFR: 8215449: Several tests failing when jtreg run with -vmoption:--illegal-access=deny In-Reply-To: <25825d9b67725f1e2dd5e6e447e8c9f47b3b485e.camel@redhat.com> References: <25825d9b67725f1e2dd5e6e447e8c9f47b3b485e.camel@redhat.com> Message-ID: <48aa813e-1b9c-2a03-2894-d714e93c9fbb@redhat.com> On 30/09/2019 16:24, Severin Gehwolf wrote: > Please review this Oracle JDK 11 partity patch. Some tests are failing > in JDK 11u when VM option --illegal-access=deny is being used. The only > test as mentioned in JDK-8215449 which also fails in JDK 11u is > RacyHandler.java. Other tests' status is as follows: > . . . > I'll also backport JDK-8210789 and JDK-8208364. JDK-8210789 applies > cleanly and fixes T8152616.java failure with --illegal-access=deny. > JDK-8208364 is a pre-requisite of this patch. It also applies cleanly. Yes, all of that looks fine. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From sgehwolf at redhat.com Tue Oct 1 08:46:39 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 01 Oct 2019 10:46:39 +0200 Subject: [11u] RFR: 8228687: [TESTBUG] exclude Container tests from hotspot_misc group In-Reply-To: <74a3c54e-5763-4741-6148-8eed27907a4a@redhat.com> References: <37688aafbaab92740bb043efda894b78db56e5dd.camel@redhat.com> <74a3c54e-5763-4741-6148-8eed27907a4a@redhat.com> Message-ID: <1141c706e24e2680569e2c3667bf9c4b148d42b2.camel@redhat.com> On Tue, 2019-10-01 at 09:33 +0100, Andrew Dinn wrote: > On 30/09/2019 17:53, Severin Gehwolf wrote: > > Could I please get a review of this trivial test bug fix? It brings > > OpenJDK 11u one step closer to what's in Oracle JDK 11.0.6. The patch > > from JDK head didn't apply cleanly as JDK-8217666 isn't in OpenJDK 11. > > I've recreated the patch manually. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8228687 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8228687/01/webrev/ > > Original changeset: https://hg.openjdk.java.net/jdk/jdk/rev/a26bc1847594 > > Looks good. Thanks for the review, Andrew! Cheers, Severin From sgehwolf at redhat.com Tue Oct 1 08:47:22 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 01 Oct 2019 10:47:22 +0200 Subject: [11u] RFR: 8215449: Several tests failing when jtreg run with -vmoption:--illegal-access=deny In-Reply-To: <48aa813e-1b9c-2a03-2894-d714e93c9fbb@redhat.com> References: <25825d9b67725f1e2dd5e6e447e8c9f47b3b485e.camel@redhat.com> <48aa813e-1b9c-2a03-2894-d714e93c9fbb@redhat.com> Message-ID: <6fa149751fa4c27ffa12486b0ff8053523ea6f84.camel@redhat.com> On Tue, 2019-10-01 at 09:38 +0100, Andrew Dinn wrote: > On 30/09/2019 16:24, Severin Gehwolf wrote: > > Please review this Oracle JDK 11 partity patch. Some tests are failing > > in JDK 11u when VM option --illegal-access=deny is being used. The only > > test as mentioned in JDK-8215449 which also fails in JDK 11u is > > RacyHandler.java. Other tests' status is as follows: > > . . . > > I'll also backport JDK-8210789 and JDK-8208364. JDK-8210789 applies > > cleanly and fixes T8152616.java failure with --illegal-access=deny. > > JDK-8208364 is a pre-requisite of this patch. It also applies cleanly. > Yes, all of that looks fine. Thanks for the review! Cheers, Severin From christoph.langer at sap.com Tue Oct 1 09:03:22 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 1 Oct 2019 09:03:22 +0000 Subject: [11u] 8215913: [Test_bug]java/util/Locale/LocaleProvidersRun.java failed on de_DE and ja_JP locale. In-Reply-To: <20b83df9a70a1f6651a6b56f89cf3c05766409a6.camel@redhat.com> References: <20b83df9a70a1f6651a6b56f89cf3c05766409a6.camel@redhat.com> Message-ID: Hi Severin, thanks for doing this backport. I think we should definitely do this for keeping parity. Your webrev looks fine but doesn't contain the change below to LocaleProviders.sh. This should definitely be done since it is an important part of the original change although being part of LocaleProvidersRun.java instead of LocaleProviders.sh. Can you update the webrev? Then I can put it into our queue for regression testing. Thanks Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Severin Gehwolf > Sent: Montag, 30. September 2019 13:49 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] 8215913: [Test_bug]java/util/Locale/LocaleProvidersRun.java > failed on de_DE and ja_JP locale. > > Hi, > > Please review this test stabilization patch. The issue doesn't actually > reproduce in 11u without this patch: > > diff --git a/test/jdk/java/util/Locale/LocaleProviders.sh > b/test/jdk/java/util/Locale/LocaleProviders.sh > --- a/test/jdk/java/util/Locale/LocaleProviders.sh > +++ b/test/jdk/java/util/Locale/LocaleProviders.sh > @@ -352,7 +352,7 @@ > # testing 8027289 fix, if the platform format default is zh_CN > # this assumes Windows' currency symbol for zh_CN is \u00A5, the yen > # (yuan) sign. > -if [ "${DEFFMTLANG}" = "zh" ] && [ "${DEFFMTCTRY}" = "CN" ]; then > +if [ ! "${DEFFMTLANG}" = "en" ] && [ ! "${DEFFMTCTRY}" = "CN" ]; then > METHODNAME=bug8027289Test > PREFLIST=JRE,HOST > PARAM1=FFE5 > > With it it does, since the test is actually called (and fails) with > de_DE locale. The patch didn't apply cleanly due to copyright hunk > fails (upper bound year is already at 2019) and LocaleProvidersRun.java > being LocaleProviders.sh in JDK 11u. It's one of the Oracle JDK 11 > partity patches, if that helps gauge why I'm proposing this. > Personally, I wouldn't backport it, but I thought to get some feedback > whether we want this or not. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215913 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > 8215913/01/webrev/ > Original changeset: http://hg.openjdk.java.net/jdk/jdk/rev/76f7dbf458fe > > Thoughts? > > Thanks, > Severin From christoph.langer at sap.com Tue Oct 1 09:15:53 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 1 Oct 2019 09:15:53 +0000 Subject: [11u] RFR: 8215449: Several tests failing when jtreg run with -vmoption:--illegal-access=deny In-Reply-To: <25825d9b67725f1e2dd5e6e447e8c9f47b3b485e.camel@redhat.com> References: <25825d9b67725f1e2dd5e6e447e8c9f47b3b485e.camel@redhat.com> Message-ID: Hi Severin, I'm wondering if this issue with ReflectionCallerCacheTest also exists in jdk/jdk. If so, I suggest it should be fixed there first and that fix be backported. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Severin Gehwolf > Sent: Montag, 30. September 2019 17:25 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8215449: Several tests failing when jtreg run with - > vmoption:--illegal-access=deny > > Hi, > > Please review this Oracle JDK 11 partity patch. Some tests are failing > in JDK 11u when VM option --illegal-access=deny is being used. The only > test as mentioned in JDK-8215449 which also fails in JDK 11u is > RacyHandler.java. Other tests' status is as follows: > > * LocaleProvider.sh (equiv of LocaleProvidersRun.java) doesn't fail > with ?--illegal-access=deny > * CanHandleClassFilesTest.java doesn't exist in JDK 11u and isn't > appropriate. JDK-8207954 added that test, which makes no sense for > JDK 11u. > > However, I've noticed that other tests are failing in tier1 with -- > illegal-access=deny. Due to the above and those failures I've done > these changes to the original patch: > > * ReflectionCallerCacheTest.java fails with --illegal-access=deny in > OpenJDK 11u. Added 'java.base/java.lang.reflect:+open' to @modules > tag so that the test passes in JDK 11u as well. Requires JDK-8208364 > * Drop hunk to LocaleProvidersRun.java as it doesn't apply JDK 11u. > * Omit changes to CanHandleClassFilesTest.java as it doesn't apply to > JDK 11. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215449 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > 8215449/03/webrev/ > Original changeset: http://hg.openjdk.java.net/jdk/jdk/rev/9dd0a2fdec24 > > Testing: Relevant tests fail prior with option --illegal-access=deny > and pass after. > > I'll also backport JDK-8210789 and JDK-8208364. JDK-8210789 applies > cleanly and fixes T8152616.java failure with --illegal-access=deny. > JDK-8208364 is a pre-requisite of this patch. It also applies cleanly. > > Thoughts? > > Thanks, > Severin From sgehwolf at redhat.com Tue Oct 1 09:32:13 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 01 Oct 2019 11:32:13 +0200 Subject: [11u] 8215913: [Test_bug]java/util/Locale/LocaleProvidersRun.java failed on de_DE and ja_JP locale. In-Reply-To: References: <20b83df9a70a1f6651a6b56f89cf3c05766409a6.camel@redhat.com> Message-ID: <2ccffc50abdf43e9ca7e5895ab42be89fc54f86c.camel@redhat.com> Hi Christoph, On Tue, 2019-10-01 at 09:03 +0000, Langer, Christoph wrote: > Hi Severin, > > thanks for doing this backport. I think we should definitely do this for keeping parity. Maybe. It really is just adding a if (isWindows()) {...} conditional around the test code. > Your webrev looks fine but doesn't contain the change below to > LocaleProviders.sh. This should definitely be done since it is an > important part of the original change although being part of > LocaleProvidersRun.java instead of LocaleProviders.sh. Can you update > the webrev? Then I can put it into our queue for regression testing. The change below is the *antidelta* of what's been done in the original changeset. JDK 11u's version of LocaleProviders.sh already has the equivalent of LocaleProvidersRun.java change: if [ "${DEFFMTLANG}" = "zh" ] && [ "${DEFFMTCTRY}" = "CN" ]; then ... So no, I don't want to change it back. That's the reason why right now the issue doesn't reproduce on JDK 11u as bug8027289Test method is only called for zh_CN locale (you need the patch to reproduce). IMHO, if we wouldn't backport this fix at all we should be fine as well. This backport was a weird one. Thoughts? Thanks, Severin > Thanks > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Severin Gehwolf > > Sent: Montag, 30. September 2019 13:49 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [11u] 8215913: [Test_bug]java/util/Locale/LocaleProvidersRun.java > > failed on de_DE and ja_JP locale. > > > > Hi, > > > > Please review this test stabilization patch. The issue doesn't actually > > reproduce in 11u without this patch: > > > > diff --git a/test/jdk/java/util/Locale/LocaleProviders.sh > > b/test/jdk/java/util/Locale/LocaleProviders.sh > > --- a/test/jdk/java/util/Locale/LocaleProviders.sh > > +++ b/test/jdk/java/util/Locale/LocaleProviders.sh > > @@ -352,7 +352,7 @@ > > # testing 8027289 fix, if the platform format default is zh_CN > > # this assumes Windows' currency symbol for zh_CN is \u00A5, the yen > > # (yuan) sign. > > -if [ "${DEFFMTLANG}" = "zh" ] && [ "${DEFFMTCTRY}" = "CN" ]; then > > +if [ ! "${DEFFMTLANG}" = "en" ] && [ ! "${DEFFMTCTRY}" = "CN" ]; then > > METHODNAME=bug8027289Test > > PREFLIST=JRE,HOST > > PARAM1=FFE5 > > > > With it it does, since the test is actually called (and fails) with > > de_DE locale. The patch didn't apply cleanly due to copyright hunk > > fails (upper bound year is already at 2019) and LocaleProvidersRun.java > > being LocaleProviders.sh in JDK 11u. It's one of the Oracle JDK 11 > > partity patches, if that helps gauge why I'm proposing this. > > Personally, I wouldn't backport it, but I thought to get some feedback > > whether we want this or not. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215913 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > 8215913/01/webrev/ > > Original changeset: http://hg.openjdk.java.net/jdk/jdk/rev/76f7dbf458fe > > > > Thoughts? > > > > Thanks, > > Severin From sgehwolf at redhat.com Tue Oct 1 09:34:33 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 01 Oct 2019 11:34:33 +0200 Subject: [11u] RFR: 8215449: Several tests failing when jtreg run with -vmoption:--illegal-access=deny In-Reply-To: References: <25825d9b67725f1e2dd5e6e447e8c9f47b3b485e.camel@redhat.com> Message-ID: <1a32bf652072bbb609766f8ce2901cb2a58b7a8c.camel@redhat.com> Hi Christoph, On Tue, 2019-10-01 at 09:15 +0000, Langer, Christoph wrote: > Hi Severin, > > I'm wondering if this issue with ReflectionCallerCacheTest also > exists in jdk/jdk. If so, I suggest it should be fixed there first > and that fix be backported. I wasn't able to reproduce the test failure with jdk/jdk. Not sure why. It only fails on JDK 11u. Thoughts? Thanks, Severin > > Best regards > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Severin Gehwolf > > Sent: Montag, 30. September 2019 17:25 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [11u] RFR: 8215449: Several tests failing when jtreg run with - > > vmoption:--illegal-access=deny > > > > Hi, > > > > Please review this Oracle JDK 11 partity patch. Some tests are failing > > in JDK 11u when VM option --illegal-access=deny is being used. The only > > test as mentioned in JDK-8215449 which also fails in JDK 11u is > > RacyHandler.java. Other tests' status is as follows: > > > > * LocaleProvider.sh (equiv of LocaleProvidersRun.java) doesn't fail > > with --illegal-access=deny > > * CanHandleClassFilesTest.java doesn't exist in JDK 11u and isn't > > appropriate. JDK-8207954 added that test, which makes no sense for > > JDK 11u. > > > > However, I've noticed that other tests are failing in tier1 with -- > > illegal-access=deny. Due to the above and those failures I've done > > these changes to the original patch: > > > > * ReflectionCallerCacheTest.java fails with --illegal-access=deny in > > OpenJDK 11u. Added 'java.base/java.lang.reflect:+open' to @modules > > tag so that the test passes in JDK 11u as well. Requires JDK-8208364 > > * Drop hunk to LocaleProvidersRun.java as it doesn't apply JDK 11u. > > * Omit changes to CanHandleClassFilesTest.java as it doesn't apply to > > JDK 11. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215449 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > 8215449/03/webrev/ > > Original changeset: http://hg.openjdk.java.net/jdk/jdk/rev/9dd0a2fdec24 > > > > Testing: Relevant tests fail prior with option --illegal-access=deny > > and pass after. > > > > I'll also backport JDK-8210789 and JDK-8208364. JDK-8210789 applies > > cleanly and fixes T8152616.java failure with --illegal-access=deny. > > JDK-8208364 is a pre-requisite of this patch. It also applies cleanly. > > > > Thoughts? > > > > Thanks, > > Severin From bourges.laurent at gmail.com Tue Oct 1 10:07:40 2019 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 1 Oct 2019 12:07:40 +0200 Subject: Bad push for JDK-8230728: Thin stroked shapes are not rendered if affine transform has flip bit In-Reply-To: References: Message-ID: Hi, I will do it during lunch time. Laurent Le mar. 1 oct. 2019 ? 09:12, Langer, Christoph a ?crit : > Hi Goetz, Laurent, > > I had a look to the AIX test failures that we observe. It seems more > likely to me that it is not related to the push of 8230728 but to another > issue with fontconfig on AIX which we're chasing for several weeks now. So > technically I think there's nothing wrong with the push. > > But since we're in the CPU phase of 11.0.5 the change should be reverted > in 11u and be pushed to 11u-dev. > > So, @Laurent, please do the backout as outlined by Goetz and push your > change to jdk11u-dev as well. > > Thanks > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Lindenmaier, Goetz > > Sent: Dienstag, 1. Oktober 2019 08:44 > > To: Laurent Bourg?s ; jdk-updates- > > dev at openjdk.java.net > > Subject: [CAUTION] RE: Bad push for JDK-8230728: Thin stroked shapes are > > not rendered if affine transform has flip bit > > > > Hi Laurent, > > > > please open a JBS Issue > > 'Backout "8230728: Thin stroked shapes are not rendered if affine > transform > > has flip bit" from jdk11u' > > and send a RFR with the backout change. Tag it as > jdk11u-critical-request. > > > > Also, I see crashes in our tests that were triggered by your > > push. I didn't investigate, but they are in the fonts area. > > > > The following jtreg tests crashed on AIX: > > javax/swing/Headless/HeadlessJMenuBar.java > > javax/swing/Headless/HeadlessJSlider.java > > javax/swing/Headless/HeadlessJTextArea.java > > javax/swing/Headless/HeadlessJToolBar_Separator.java > > javax/swing/Headless/HeadlessJToolBar.java > > > > # > > # A fatal error has been detected by the Java Runtime Environment: > > # > > # SIGBUS (0xa) at pc=0x0900000006f917b8, pid=13959206, tid=5141 > > # > > # JRE version: OpenJDK Runtime Environment (11.0.5) (build 11.0.5- > > internal+0-adhoc.openjdk.jdk11u) > > # Java VM: OpenJDK 64-Bit Server VM (11.0.5-internal+0- > > adhoc.openjdk.jdk11u, mixed mode, tiered, compressed oops, g1 gc, aix- > > ppc64) > > # Problematic frame: > > # C 0x0900000006f917b8 > > # > > > > 0x0000000116b081d0 - 0x0900000006f8a094 (unknown module)::(unknown > > function)+? > > 0x0000000116b08260 - 0x0900000006f8a150 (unknown module)::(unknown > > function)+? > > 0x0000000116b082d0 - 0x0900000006f8ace0 (unknown module)::(unknown > > function)+? > > 0x0000000116b08340 - 0x090000000482e79c > > libawt_headless.so::Java_sun_font_FontConfigManager_getFontConfig+0x6 > > 1c (C saves_cr saves_lr stores_bc gpr_saved:18 fixedparms:6 ) > > 0x0000000116b08580 - 0x0a0001000000ed7c (unknown module)::(unknown > > function)+? > > 0x0000000116b086a0 - 0x0a000100000085a8 (unknown module)::(unknown > > function)+? > > 0x0000000116b08770 - 0x0a000100000085a8 (unknown module)::(unknown > > function)+? > > 0x0000000116b08870 - 0x0a00010000008300 (unknown module)::(unknown > > function)+? > > 0x0000000116b08930 - 0x0a000100000009cc (unknown module)::(unknown > > function)+? > > 0x0000000116b08ae0 - 0x09000000050f9598 > > libjvm.so::JavaCalls::call_helper(JavaValue*,const > > methodHandle&,JavaCallArguments*,Thread*)+0x438 (C++ saves_lr > > stores_bc gpr_saved:15 fixedparms:4 ) > > 0x0000000116b08ca0 - 0x09000000049bb2f8 > > libjvm.so::os::os_exception_wrapper(void(*)(JavaValue*,const > > methodHandle&,JavaCallArguments*,Thread*),JavaValue*,const > > methodHandle&,JavaCallArguments*,Thread*)+0x38 (C++ saves_lr > > stores_bc fixedparms:5 ) > > 0x0000000116b08d10 - 0x09000000050fc834 > > libjvm.so::JavaCalls::call(JavaValue*,const > > methodHandle&,JavaCallArguments*,Thread*)+0x34 (C++ saves_lr > > stores_bc fixedparms:4 ) > > 0x0000000116b08d80 - 0x090000000494e994 > > libjvm.so::JVM_DoPrivileged+0xc14 (C++ saves_lr stores_bc gpr_saved:14 > > fixedparms:5 ) > > 0x0000000116b09750 - 0x090000000479a318 > > > libjava.so::Java_java_security_AccessController_doPrivileged__Ljava_securit > > y_PrivilegedAction_2+0x18 (C saves_lr stores_bc fixedparms:3 ) > > 0x0000000116b097c0 - 0x0a0001000000ed7c (unknown module)::(unknown > > function)+? > > 0x0000000116b098e0 - 0x0a00010000008300 (unknown module)::(unknown > > function)+? > > > > Crash on AIX in an SAP application we test: > > > > 0x0000000119327d30 - 0x0900000006f8a150 (unknown module)::(unknown > > function)+? > > 0x0000000119327da0 - 0x0900000006fb1970 (unknown module)::(unknown > > function)+? > > 0x0000000119327e20 - 0x0900000006f914e8 (unknown module)::(unknown > > function)+? > > 0x0000000119327eb0 - 0x0900000006914ee4 > > libawt_headless.so::getFontConfigLocations+0x1c4 (C saves_lr stores_bc > > gpr_saved:18 ) > > 0x0000000119327fc0 - 0x09000000069146c0 > > libawt_headless.so::getPlatformFontPathChars+0x20 (C saves_lr stores_bc > > gpr_saved:3 fixedparms:3 ) > > 0x0000000119328050 - 0x0900000006914618 > > libawt_headless.so::Java_sun_awt_FcFontManager_getFontPathNative+0x7 > > 8 (C saves_lr stores_bc gpr_saved:1 fixedparms:4 ) > > 0x00000001193280e0 - 0x0a00010028fb28ec (unknown module)::(unknown > > function)+? > > 0x00000001193281a0 - 0x0a00010003c21b88 (unknown module)::(unknown > > function)+? > > > > So maybe we should investigate this before pushing to jdk11u-dev. > > > > Best regards, > > Goetz. > > > > > > > > > -----Original Message----- > > > From: jdk-updates-dev On > > > Behalf Of Laurent Bourg?s > > > Sent: Montag, 30. September 2019 18:13 > > > To: jdk-updates-dev at openjdk.java.net > > > Subject: Bad push for JDK-8230728: Thin stroked shapes are not > rendered if > > > affine transform has flip bit > > > > > > Hi, > > > > > > I pushed by mistake on the jdk11u (11.0.5) repository, not on > jdk11u-dev ! > > > Sorry, sorry, sorry. > > > Previously I only had to deal with 10u, 12u... > > > > > > See https://bugs.openjdk.java.net/browse/JDK-8231621 > > > > > > How can I (or you) revert that changeset ? What is the process ? > > > > > > PS: I will get rid of my local copy jdk11u (master), I already > retrieved > > > the jdk11u-dev to use instead. > > > > > > Thanks for your help, > > > Laurent > From bourges.laurent at gmail.com Tue Oct 1 11:34:07 2019 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 1 Oct 2019 13:34:07 +0200 Subject: RFR[11u]: Backout "8230728: Thin stroked shapes are not rendered if affine transform has flip bit" from jdk11u Message-ID: Hi, Please review this backout change to undo my push in jdk11u (11.0.5): bug: https://bugs.openjdk.java.net/browse/JDK-8231693 webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-11u-8231693.0/ Thanks, Laurent From bourges.laurent at gmail.com Tue Oct 1 11:44:09 2019 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 1 Oct 2019 13:44:09 +0200 Subject: Bad push for JDK-8230728: Thin stroked shapes are not rendered if affine transform has flip bit In-Reply-To: References: Message-ID: Hi Christoph, Le mar. 1 oct. 2019 ? 09:12, Langer, Christoph a ?crit : > Hi Goetz, Laurent, > > I had a look to the AIX test failures that we observe. It seems more > likely to me that it is not related to the push of 8230728 but to another > issue with fontconfig on AIX which we're chasing for several weeks now. So > technically I think there's nothing wrong with the push. > I think so, as my patch concerns only pure Java code related to Path rendering, so it should not impact Font rendering on a specific port nor native code. > But since we're in the CPU phase of 11.0.5 the change should be reverted > in 11u and be pushed to 11u-dev. > > So, @Laurent, please do the backout as outlined by Goetz and push your > change to jdk11u-dev as well. > I create the bug and submitted the RFR (simple hg backout --no-commit), so I am waiting for approval. I will wait a bit before pushing the patch into jdk11u-dev. Thanks for your help, Laurent > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Lindenmaier, Goetz > > Sent: Dienstag, 1. Oktober 2019 08:44 > > To: Laurent Bourg?s ; jdk-updates- > > dev at openjdk.java.net > > Subject: [CAUTION] RE: Bad push for JDK-8230728: Thin stroked shapes are > > not rendered if affine transform has flip bit > > > > Hi Laurent, > > > > please open a JBS Issue > > 'Backout "8230728: Thin stroked shapes are not rendered if affine > transform > > has flip bit" from jdk11u' > > and send a RFR with the backout change. Tag it as > jdk11u-critical-request. > > > > Also, I see crashes in our tests that were triggered by your > > push. I didn't investigate, but they are in the fonts area. > > > > The following jtreg tests crashed on AIX: > > javax/swing/Headless/HeadlessJMenuBar.java > > javax/swing/Headless/HeadlessJSlider.java > > javax/swing/Headless/HeadlessJTextArea.java > > javax/swing/Headless/HeadlessJToolBar_Separator.java > > javax/swing/Headless/HeadlessJToolBar.java > > > > # > > # A fatal error has been detected by the Java Runtime Environment: > > # > > # SIGBUS (0xa) at pc=0x0900000006f917b8, pid=13959206, tid=5141 > > # > > # JRE version: OpenJDK Runtime Environment (11.0.5) (build 11.0.5- > > internal+0-adhoc.openjdk.jdk11u) > > # Java VM: OpenJDK 64-Bit Server VM (11.0.5-internal+0- > > adhoc.openjdk.jdk11u, mixed mode, tiered, compressed oops, g1 gc, aix- > > ppc64) > > # Problematic frame: > > # C 0x0900000006f917b8 > > # > > > > 0x0000000116b081d0 - 0x0900000006f8a094 (unknown module)::(unknown > > function)+? > > 0x0000000116b08260 - 0x0900000006f8a150 (unknown module)::(unknown > > function)+? > > 0x0000000116b082d0 - 0x0900000006f8ace0 (unknown module)::(unknown > > function)+? > > 0x0000000116b08340 - 0x090000000482e79c > > libawt_headless.so::Java_sun_font_FontConfigManager_getFontConfig+0x6 > > 1c (C saves_cr saves_lr stores_bc gpr_saved:18 fixedparms:6 ) > > 0x0000000116b08580 - 0x0a0001000000ed7c (unknown module)::(unknown > > function)+? > > 0x0000000116b086a0 - 0x0a000100000085a8 (unknown module)::(unknown > > function)+? > > 0x0000000116b08770 - 0x0a000100000085a8 (unknown module)::(unknown > > function)+? > > 0x0000000116b08870 - 0x0a00010000008300 (unknown module)::(unknown > > function)+? > > 0x0000000116b08930 - 0x0a000100000009cc (unknown module)::(unknown > > function)+? > > 0x0000000116b08ae0 - 0x09000000050f9598 > > libjvm.so::JavaCalls::call_helper(JavaValue*,const > > methodHandle&,JavaCallArguments*,Thread*)+0x438 (C++ saves_lr > > stores_bc gpr_saved:15 fixedparms:4 ) > > 0x0000000116b08ca0 - 0x09000000049bb2f8 > > libjvm.so::os::os_exception_wrapper(void(*)(JavaValue*,const > > methodHandle&,JavaCallArguments*,Thread*),JavaValue*,const > > methodHandle&,JavaCallArguments*,Thread*)+0x38 (C++ saves_lr > > stores_bc fixedparms:5 ) > > 0x0000000116b08d10 - 0x09000000050fc834 > > libjvm.so::JavaCalls::call(JavaValue*,const > > methodHandle&,JavaCallArguments*,Thread*)+0x34 (C++ saves_lr > > stores_bc fixedparms:4 ) > > 0x0000000116b08d80 - 0x090000000494e994 > > libjvm.so::JVM_DoPrivileged+0xc14 (C++ saves_lr stores_bc gpr_saved:14 > > fixedparms:5 ) > > 0x0000000116b09750 - 0x090000000479a318 > > > libjava.so::Java_java_security_AccessController_doPrivileged__Ljava_securit > > y_PrivilegedAction_2+0x18 (C saves_lr stores_bc fixedparms:3 ) > > 0x0000000116b097c0 - 0x0a0001000000ed7c (unknown module)::(unknown > > function)+? > > 0x0000000116b098e0 - 0x0a00010000008300 (unknown module)::(unknown > > function)+? > > > > Crash on AIX in an SAP application we test: > > > > 0x0000000119327d30 - 0x0900000006f8a150 (unknown module)::(unknown > > function)+? > > 0x0000000119327da0 - 0x0900000006fb1970 (unknown module)::(unknown > > function)+? > > 0x0000000119327e20 - 0x0900000006f914e8 (unknown module)::(unknown > > function)+? > > 0x0000000119327eb0 - 0x0900000006914ee4 > > libawt_headless.so::getFontConfigLocations+0x1c4 (C saves_lr stores_bc > > gpr_saved:18 ) > > 0x0000000119327fc0 - 0x09000000069146c0 > > libawt_headless.so::getPlatformFontPathChars+0x20 (C saves_lr stores_bc > > gpr_saved:3 fixedparms:3 ) > > 0x0000000119328050 - 0x0900000006914618 > > libawt_headless.so::Java_sun_awt_FcFontManager_getFontPathNative+0x7 > > 8 (C saves_lr stores_bc gpr_saved:1 fixedparms:4 ) > > 0x00000001193280e0 - 0x0a00010028fb28ec (unknown module)::(unknown > > function)+? > > 0x00000001193281a0 - 0x0a00010003c21b88 (unknown module)::(unknown > > function)+? > > > > So maybe we should investigate this before pushing to jdk11u-dev. > > > > Best regards, > > Goetz. > > > > > > > > > -----Original Message----- > > > From: jdk-updates-dev On > > > Behalf Of Laurent Bourg?s > > > Sent: Montag, 30. September 2019 18:13 > > > To: jdk-updates-dev at openjdk.java.net > > > Subject: Bad push for JDK-8230728: Thin stroked shapes are not > rendered if > > > affine transform has flip bit > > > > > > Hi, > > > > > > I pushed by mistake on the jdk11u (11.0.5) repository, not on > jdk11u-dev ! > > > Sorry, sorry, sorry. > > > Previously I only had to deal with 10u, 12u... > > > > > > See https://bugs.openjdk.java.net/browse/JDK-8231621 > > > > > > How can I (or you) revert that changeset ? What is the process ? > > > > > > PS: I will get rid of my local copy jdk11u (master), I already > retrieved > > > the jdk11u-dev to use instead. > > > > > > Thanks for your help, > > > Laurent > -- -- Laurent Bourg?s From sgehwolf at redhat.com Tue Oct 1 11:57:37 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 01 Oct 2019 13:57:37 +0200 Subject: RFR[11u]: Backout "8230728: Thin stroked shapes are not rendered if affine transform has flip bit" from jdk11u In-Reply-To: References: Message-ID: <3c5f89e62cffcfd4ccd571fd8298ed52205318ed.camel@redhat.com> Hi Laurent, On Tue, 2019-10-01 at 13:34 +0200, Laurent Bourg?s wrote: > Hi, > > Please review this backout change to undo my push in jdk11u (11.0.5): > bug: https://bugs.openjdk.java.net/browse/JDK-8231693 > webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-11u-8231693.0/ Looks fine to me. I've done a manual backout and compared patches. No difference. Thumbs up! Thanks for being proactive about this accidental push! Cheers, Severin From christoph.langer at sap.com Tue Oct 1 12:23:39 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 1 Oct 2019 12:23:39 +0000 Subject: Bad push for JDK-8230728: Thin stroked shapes are not rendered if affine transform has flip bit In-Reply-To: References: Message-ID: Hi Laurent, > I create the bug and submitted the RFR (simple hg backout --no-commit), so I > am waiting for approval. I added the approval labels in JBS. > I will wait a bit before pushing the patch into jdk11u-dev. If you want, I can take your jdk11u commit, run it through our testing for 11u-dev and push it afterwards? Best regards Christoph From bourges.laurent at gmail.com Tue Oct 1 12:44:15 2019 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 1 Oct 2019 14:44:15 +0200 Subject: RFR[11u]: Backout "8230728: Thin stroked shapes are not rendered if affine transform has flip bit" from jdk11u In-Reply-To: <3c5f89e62cffcfd4ccd571fd8298ed52205318ed.camel@redhat.com> References: <3c5f89e62cffcfd4ccd571fd8298ed52205318ed.camel@redhat.com> Message-ID: Thanks for the review, Pushed: http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/3bf13d471753 Sorry one more time, Laurent Le mar. 1 oct. 2019 ? 13:57, Severin Gehwolf a ?crit : > Hi Laurent, > > On Tue, 2019-10-01 at 13:34 +0200, Laurent Bourg?s wrote: > > Hi, > > > > Please review this backout change to undo my push in jdk11u (11.0.5): > > bug: https://bugs.openjdk.java.net/browse/JDK-8231693 > > webrev: > http://cr.openjdk.java.net/~lbourges/marlin/marlin-11u-8231693.0/ > > Looks fine to me. I've done a manual backout and compared patches. No > difference. Thumbs up! > > Thanks for being proactive about this accidental push! > > Cheers, > Severin > > -- -- Laurent Bourg?s From bourges.laurent at gmail.com Tue Oct 1 12:46:35 2019 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 1 Oct 2019 14:46:35 +0200 Subject: Bad push for JDK-8230728: Thin stroked shapes are not rendered if affine transform has flip bit In-Reply-To: References: Message-ID: Hi Christoph, Le mar. 1 oct. 2019 ? 14:23, Langer, Christoph a ?crit : > Hi Laurent, > > > I create the bug and submitted the RFR (simple hg backout --no-commit), > so I > > am waiting for approval. > > I added the approval labels in JBS. > > > I will wait a bit before pushing the patch into jdk11u-dev. > > If you want, I can take your jdk11u commit, run it through our testing for > 11u-dev and push it afterwards? > Thanks for your proposal, please do. We will be sure that this patch do not cause another regression. Thanks, Laurent From denghui.ddh at alibaba-inc.com Tue Oct 1 14:01:48 2019 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Tue, 01 Oct 2019 22:01:48 +0800 Subject: =?UTF-8?B?UmU6IFsxMXVdIFJGUiA4MjE3MzYyOiBFbWVyZ2VuY3kgZHVtcCBkb2VzIG5vdCB3b3JrIHdo?= =?UTF-8?B?ZW4gZGlzaz1mYWxzZSBpcyBzZXQ=?= In-Reply-To: References: <610de40c-95b4-4c64-9696-c6fd84815382.denghui.ddh@alibaba-inc.com> <7c2a9819-9559-470b-8226-e42f0bd0b164.denghui.ddh@alibaba-inc.com> , Message-ID: <5a79d8cb-a2a6-4897-8139-592c32dc657c.denghui.ddh@alibaba-inc.com> Hi Jei kang and Christoph, Thank you for your reply. I will check my webrev version, sorry again for duplicate work. By the way, Christoph, can you help me to review two patches: on for 11u: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-September/001939.html on for 8u: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-September/010351.html Maybe they miss metadata, I will check them later. Thanks Denghui Dong ------------------------------------------------------------------ From:Langer, Christoph Send Time:2019?10?1?(???) 16:23 To:Jie Kang ; ???(??) Cc:jdk-updates-dev Subject:RE: [11u] RFR 8217362: Emergency dump does not work when disk=false is set Hi guys, sorry that I didn't get back to you earlier on this. I just looked at the webrevs and they are identical and look fine to me. I'll approve the backport request and run it through our testing queue. If everything looks fine, I'll push it tomorrow. As for the patch metadata: When I import from Jie's webrev, e.g. hg qimport https://cr.openjdk.java.net/~jkang/jdk-8217362/webrev.03/jdk11u-dev.changeset, the patch in my repository has the correct metadata. The imported patch from Denghui's webrev (hg qimport http://cr.openjdk.java.net/~wzhuo/8217362/webrev.00/jdk11u-dev.patch) is missing this. Don't know what's causing this, maybe different webrev versions? The individual file diffs show the information. So I'll go with Jie's version then ?? Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Jie Kang > Sent: Donnerstag, 26. September 2019 15:46 > To: Denghui Dong > Cc: jdk-updates-dev > Subject: Re: [11u] RFR 8217362: Emergency dump does not work when > disk=false is set > > Hey Denghui Dong, > > No worries, that is 100% my fault, not yours. > > Ah, I didn't see the information inside the patch file: > http://cr.openjdk.java.net/~wzhuo/8217362/webrev.00/jdk11u-dev.patch > but I do see it in the individual diffs. I was thinking it might be > easier to push your patch if the .patch file has the commit data; this > makes it so $ hg import works smoothly. But, maybe there > is a better way to grab the patch + info from webrev that I'm not > familiar with. > > > Regards, > > > On Thu, Sep 26, 2019 at 9:31 AM Denghui Dong > wrote: > > > > Hi Jie Kang, > > I'm sorry that I didn't browse the previous mail. > > By the way, I think that my webrev has already included the original > commit information, right ? > > > > Thanks, > > Denghui Dong > > > > ------------------------------------------------------------------ > > From:Jie Kang > > Send Time:2019?9?26?(???) 20:50 > > To:???(??) > > Cc:jdk-updates-dev > > Subject:Re: [11u] RFR 8217362: Emergency dump does not work when > disk=false is set > > > > On Thu, Sep 26, 2019 at 3:46 AM ???(??) inc.com> wrote: > > > > > > Hi all, > > > 11u has the same problem. Please review this backport, original patch > doesn't apply cleanly caused by Hunk FAILED > > > in test/jdk/jdk/jfr/jvm/TestDumpOnCrash.java and > src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp > > > > > > 11u-webrev: > > > http://cr.openjdk.java.net/~wzhuo/8217362/webrev.00/ > > > > > > Original bug: > > > https://bugs.openjdk.java.net/browse/JDK-8217362 > > > http://hg.openjdk.java.net/jdk/jdk/rev/3cabb47758c9 > > > > > > Testing: test/jdk/jdk/jfr/jvm/TestDumpOnCrash.java > > > > > > Hi, > > > > Looks like I forgot to update the bug and there was a duplicate of > > work [1] :( That's my fault, sorry for this mistake. > > > > In any case, the changes are identical to mine so I think it looks > > okay, but should include the original commit metadata like author and > > message. Of course I am not a reviewer so another will need to look. > > > > [1] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019- > September/001883.html > > > > Regards, > > > > > > > > Thanks, > > > Denghui Dong From sgehwolf at redhat.com Tue Oct 1 14:20:15 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 01 Oct 2019 16:20:15 +0200 Subject: [11u] RFR: 8215449: Several tests failing when jtreg run with -vmoption:--illegal-access=deny In-Reply-To: References: <25825d9b67725f1e2dd5e6e447e8c9f47b3b485e.camel@redhat.com> Message-ID: Hi Christoph, On Tue, 2019-10-01 at 09:15 +0000, Langer, Christoph wrote: > Hi Severin, > > I'm wondering if this issue with ReflectionCallerCacheTest also > exists in jdk/jdk. If so, I suggest it should be fixed there first > and that fix be backported. The reason for this is that the test code is different between JDK 11u and JDK head. In particular, AccessTest.java is different. The stack trace with --illegal-access=deny in JDK 11u looks like this: test ReflectionCallerCacheTest.load("AccessTest$PublicFinalField"): failure java.lang.reflect.InaccessibleObjectException: Unable to make field private int java.lang.reflect.Field.modifiers accessible: module java.base does not "opens java.lang.reflect" to unnamed module @8cbf8a2 at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:340) at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:280) at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:176) at java.base/java.lang.reflect.Field.setAccessible(Field.java:170) at testloader//AccessTest.makeFinalNonFinal(AccessTest.java:163) at testloader//AccessTest$FinalField.(AccessTest.java:116) at testloader//AccessTest$PublicFinalField.(AccessTest.java:139) So in JDK 11u it goes through AccessTest.makeFinalNonFinal() which triggers the issue. That method is no longer there in jdk/jdk due to JDK-8210496[1] which happened for JDK 12. Thus, for jdk/jdk we don't have the path of AccessTest.makeFinalNonFinal[2], and as such no IOE is being thrown. Therefore, it's a JDK 11-only issue at this point. Does that make sense? Thanks, Severin [1] https://bugs.openjdk.java.net/browse/JDK-8210496 [2] http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/file/2201ae271c28/test/jdk/java/lang/reflect/callerCache/AccessTest.java#l116 > Best regards > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Severin Gehwolf > > Sent: Montag, 30. September 2019 17:25 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [11u] RFR: 8215449: Several tests failing when jtreg run with - > > vmoption:--illegal-access=deny > > > > Hi, > > > > Please review this Oracle JDK 11 partity patch. Some tests are failing > > in JDK 11u when VM option --illegal-access=deny is being used. The only > > test as mentioned in JDK-8215449 which also fails in JDK 11u is > > RacyHandler.java. Other tests' status is as follows: > > > > * LocaleProvider.sh (equiv of LocaleProvidersRun.java) doesn't fail > > with --illegal-access=deny > > * CanHandleClassFilesTest.java doesn't exist in JDK 11u and isn't > > appropriate. JDK-8207954 added that test, which makes no sense for > > JDK 11u. > > > > However, I've noticed that other tests are failing in tier1 with -- > > illegal-access=deny. Due to the above and those failures I've done > > these changes to the original patch: > > > > * ReflectionCallerCacheTest.java fails with --illegal-access=deny in > > OpenJDK 11u. Added 'java.base/java.lang.reflect:+open' to @modules > > tag so that the test passes in JDK 11u as well. Requires JDK-8208364 > > * Drop hunk to LocaleProvidersRun.java as it doesn't apply JDK 11u. > > * Omit changes to CanHandleClassFilesTest.java as it doesn't apply to > > JDK 11. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215449 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > 8215449/03/webrev/ > > Original changeset: http://hg.openjdk.java.net/jdk/jdk/rev/9dd0a2fdec24 > > > > Testing: Relevant tests fail prior with option --illegal-access=deny > > and pass after. > > > > I'll also backport JDK-8210789 and JDK-8208364. JDK-8210789 applies > > cleanly and fixes T8152616.java failure with --illegal-access=deny. > > JDK-8208364 is a pre-requisite of this patch. It also applies cleanly. > > > > Thoughts? > > > > Thanks, > > Severin From christoph.langer at sap.com Tue Oct 1 14:22:49 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 1 Oct 2019 14:22:49 +0000 Subject: [11u] RFR: 8215449: Several tests failing when jtreg run with -vmoption:--illegal-access=deny In-Reply-To: References: <25825d9b67725f1e2dd5e6e447e8c9f47b3b485e.camel@redhat.com> Message-ID: Hi Severin, thanks for the explanation, makes sense. So +1 from me for the webrev ?? Best regards Christoph > -----Original Message----- > From: Severin Gehwolf > Sent: Dienstag, 1. Oktober 2019 16:20 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net > Subject: Re: [11u] RFR: 8215449: Several tests failing when jtreg run with - > vmoption:--illegal-access=deny > > Hi Christoph, > > On Tue, 2019-10-01 at 09:15 +0000, Langer, Christoph wrote: > > Hi Severin, > > > > I'm wondering if this issue with ReflectionCallerCacheTest also > > exists in jdk/jdk. If so, I suggest it should be fixed there first > > and that fix be backported. > > The reason for this is that the test code is different between JDK 11u > and JDK head. In particular, AccessTest.java is different. > > The stack trace with --illegal-access=deny in JDK 11u looks like this: > > test ReflectionCallerCacheTest.load("AccessTest$PublicFinalField"): failure > java.lang.reflect.InaccessibleObjectException: Unable to make field private > int java.lang.reflect.Field.modifiers accessible: module java.base does not > "opens java.lang.reflect" to unnamed module @8cbf8a2 > at > java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(Accessi > bleObject.java:340) > at > java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(Accessi > bleObject.java:280) > at > java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:176) > at java.base/java.lang.reflect.Field.setAccessible(Field.java:170) > at testloader//AccessTest.makeFinalNonFinal(AccessTest.java:163) > at testloader//AccessTest$FinalField.(AccessTest.java:116) > at testloader//AccessTest$PublicFinalField.(AccessTest.java:139) > > So in JDK 11u it goes through AccessTest.makeFinalNonFinal() which > triggers the issue. That method is no longer there in jdk/jdk due to > JDK-8210496[1] which happened for JDK 12. Thus, for jdk/jdk we don't > have the path of AccessTest.makeFinalNonFinal[2], and as such no IOE is > being thrown. Therefore, it's a JDK 11-only issue at this point. Does > that make sense? > > Thanks, > Severin > > [1] https://bugs.openjdk.java.net/browse/JDK-8210496 > [2] http://hg.openjdk.java.net/jdk-updates/jdk11u- > dev/file/2201ae271c28/test/jdk/java/lang/reflect/callerCache/AccessTest.ja > va#l116 > > > > Best regards > > Christoph > > > > > -----Original Message----- > > > From: jdk-updates-dev > On > > > Behalf Of Severin Gehwolf > > > Sent: Montag, 30. September 2019 17:25 > > > To: jdk-updates-dev at openjdk.java.net > > > Subject: [11u] RFR: 8215449: Several tests failing when jtreg run with - > > > vmoption:--illegal-access=deny > > > > > > Hi, > > > > > > Please review this Oracle JDK 11 partity patch. Some tests are failing > > > in JDK 11u when VM option --illegal-access=deny is being used. The only > > > test as mentioned in JDK-8215449 which also fails in JDK 11u is > > > RacyHandler.java. Other tests' status is as follows: > > > > > > * LocaleProvider.sh (equiv of LocaleProvidersRun.java) doesn't fail > > > with --illegal-access=deny > > > * CanHandleClassFilesTest.java doesn't exist in JDK 11u and isn't > > > appropriate. JDK-8207954 added that test, which makes no sense for > > > JDK 11u. > > > > > > However, I've noticed that other tests are failing in tier1 with -- > > > illegal-access=deny. Due to the above and those failures I've done > > > these changes to the original patch: > > > > > > * ReflectionCallerCacheTest.java fails with --illegal-access=deny in > > > OpenJDK 11u. Added 'java.base/java.lang.reflect:+open' to @modules > > > tag so that the test passes in JDK 11u as well. Requires JDK-8208364 > > > * Drop hunk to LocaleProvidersRun.java as it doesn't apply JDK 11u. > > > * Omit changes to CanHandleClassFilesTest.java as it doesn't apply to > > > JDK 11. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215449 > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > > 8215449/03/webrev/ > > > Original changeset: > http://hg.openjdk.java.net/jdk/jdk/rev/9dd0a2fdec24 > > > > > > Testing: Relevant tests fail prior with option --illegal-access=deny > > > and pass after. > > > > > > I'll also backport JDK-8210789 and JDK-8208364. JDK-8210789 applies > > > cleanly and fixes T8152616.java failure with --illegal-access=deny. > > > JDK-8208364 is a pre-requisite of this patch. It also applies cleanly. > > > > > > Thoughts? > > > > > > Thanks, > > > Severin From christoph.langer at sap.com Tue Oct 1 14:26:05 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 1 Oct 2019 14:26:05 +0000 Subject: [11u] RFR 8217362: Emergency dump does not work when disk=false is set In-Reply-To: <5a79d8cb-a2a6-4897-8139-592c32dc657c.denghui.ddh@alibaba-inc.com> References: <610de40c-95b4-4c64-9696-c6fd84815382.denghui.ddh@alibaba-inc.com> <7c2a9819-9559-470b-8226-e42f0bd0b164.denghui.ddh@alibaba-inc.com> , <5a79d8cb-a2a6-4897-8139-592c32dc657c.denghui.ddh@alibaba-inc.com> Message-ID: Hi Denghui, I?ll look at the backport for JDK-8185525 in due course. It just seems to be a little larger item ? so it needs more time ??. Best regards Christoph From: Denghui Dong Sent: Dienstag, 1. Oktober 2019 16:02 To: Jie Kang ; Langer, Christoph Cc: jdk-updates-dev Subject: Re: [11u] RFR 8217362: Emergency dump does not work when disk=false is set Hi Jei kang and Christoph, Thank you for your reply. I will check my webrev version, sorry again for duplicate work. By the way, Christoph, can you help me to review two patches: on for 11u: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-September/001939.html on for 8u: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-September/010351.html Maybe they miss metadata, I will check them later. Thanks Denghui Dong ------------------------------------------------------------------ From:Langer, Christoph > Send Time:2019?10?1?(???) 16:23 To:Jie Kang >; ???(??) > Cc:jdk-updates-dev > Subject:RE: [11u] RFR 8217362: Emergency dump does not work when disk=false is set Hi guys, sorry that I didn't get back to you earlier on this. I just looked at the webrevs and they are identical and look fine to me. I'll approve the backport request and run it through our testing queue. If everything looks fine, I'll push it tomorrow. As for the patch metadata: When I import from Jie's webrev, e.g. hg qimport https://cr.openjdk.java.net/~jkang/jdk-8217362/webrev.03/jdk11u-dev.changeset, the patch in my repository has the correct metadata. The imported patch from Denghui's webrev (hg qimport http://cr.openjdk.java.net/~wzhuo/8217362/webrev.00/jdk11u-dev.patch) is missing this. Don't know what's causing this, maybe different webrev versions? The individual file diffs show the information. So I'll go with Jie's version then ?? Best regards Christoph > -----Original Message----- > From: jdk-updates-dev > On > Behalf Of Jie Kang > Sent: Donnerstag, 26. September 2019 15:46 > To: Denghui Dong > > Cc: jdk-updates-dev > > Subject: Re: [11u] RFR 8217362: Emergency dump does not work when > disk=false is set > > Hey Denghui Dong, > > No worries, that is 100% my fault, not yours. > > Ah, I didn't see the information inside the patch file: > http://cr.openjdk.java.net/~wzhuo/8217362/webrev.00/jdk11u-dev.patch > but I do see it in the individual diffs. I was thinking it might be > easier to push your patch if the .patch file has the commit data; this > makes it so $ hg import works smoothly. But, maybe there > is a better way to grab the patch + info from webrev that I'm not > familiar with. > > > Regards, > > > On Thu, Sep 26, 2019 at 9:31 AM Denghui Dong > > wrote: > > > > Hi Jie Kang, > > I'm sorry that I didn't browse the previous mail. > > By the way, I think that my webrev has already included the original > commit information, right ? > > > > Thanks, > > Denghui Dong > > > > ------------------------------------------------------------------ > > From:Jie Kang > > > Send Time:2019?9?26?(???) 20:50 > > To:???(??) > > > Cc:jdk-updates-dev > > > Subject:Re: [11u] RFR 8217362: Emergency dump does not work when > disk=false is set > > > > On Thu, Sep 26, 2019 at 3:46 AM ???(??) > inc.com> wrote: > > > > > > Hi all, > > > 11u has the same problem. Please review this backport, original patch > doesn't apply cleanly caused by Hunk FAILED > > > in test/jdk/jdk/jfr/jvm/TestDumpOnCrash.java and > src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp > > > > > > 11u-webrev: > > > http://cr.openjdk.java.net/~wzhuo/8217362/webrev.00/ > > > > > > Original bug: > > > https://bugs.openjdk.java.net/browse/JDK-8217362 > > > http://hg.openjdk.java.net/jdk/jdk/rev/3cabb47758c9 > > > > > > Testing: test/jdk/jdk/jfr/jvm/TestDumpOnCrash.java > > > > > > Hi, > > > > Looks like I forgot to update the bug and there was a duplicate of > > work [1] :( That's my fault, sorry for this mistake. > > > > In any case, the changes are identical to mine so I think it looks > > okay, but should include the original commit metadata like author and > > message. Of course I am not a reviewer so another will need to look. > > > > [1] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019- > September/001883.html > > > > Regards, > > > > > > > > Thanks, > > > Denghui Dong From gnu.andrew at redhat.com Tue Oct 1 19:26:15 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 1 Oct 2019 20:26:15 +0100 Subject: [13u] RFR: 8212970: TZ database in "vanguard" format support In-Reply-To: <91d56aa4-bb65-4aea-b8f5-6e5aa2d79989@default> References: <91d56aa4-bb65-4aea-b8f5-6e5aa2d79989@default> Message-ID: On 26/09/2019 10:45, Ramanand Patil wrote: > Hi all, > Please review this backport to JDK13 updates: > Bug: https://bugs.openjdk.java.net/browse/JDK-8212970 > Webrev: http://cr.openjdk.java.net/~rpatil/8212970/webrev.00/ > Original Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/99d2dd7b84a8 > > The patch from jdk14 was not applied cleanly. Here is the change summary: > - All the deletions in test/jdk/sun/util/calendar/zi/tzdata and test/jdk/sun/util/calendar/zi/tzdata_jdk are done manually. > - The original patch(jdk14) had tzdata2019a vanguard format, but since the jdk13u is already patched with tzdata2019b rearguard format, in this patch tzdata files used are from tzdata2019b vanguard format. > Post this backport, it will be easy to backport future tzdata versions starting tzdata2019c(JDK-8231098). > > All the related tests including JCK are passed. > > > Regards, > Ramanand. > Looks good to me. The only difference between the 13u & 14u patches are those expected from the tzdata2019b rearguard update to jdk13; rearguard format Morocco offsets being removed and tzdata2019b data being removed from the test tree rather than tzdata2019a. Out of interest, why was the test data removed rather than being switched to vanguard format versions? FWIW, tzdata2019c should be a clean backport either way, as the changes are no different in vanguard or rearguard format. We already backported it to 8u. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From naoto.sato at oracle.com Wed Oct 2 17:16:07 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 2 Oct 2019 10:16:07 -0700 Subject: [13u] RFR: 8212970: TZ database in "vanguard" format support In-Reply-To: References: <91d56aa4-bb65-4aea-b8f5-6e5aa2d79989@default> Message-ID: <94bd803a-6d5f-a87b-c87c-1f4686ec8234@oracle.com> Hi Andrew, On 10/1/19 12:26 PM, Andrew John Hughes wrote: > Out of interest, why was the test data removed rather than being > switched to vanguard format versions? The removal was done in the original vanguard support changeset. The duplicated tz data in the test directory is unnecessary, as the test case (TestZone310.java) now refers to the tz data in the "make" directory. HTH, Naoto From ramanand.patil at oracle.com Thu Oct 3 08:41:24 2019 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Thu, 3 Oct 2019 01:41:24 -0700 (PDT) Subject: [13u] RFR: 8212970: TZ database in "vanguard" format support In-Reply-To: <94bd803a-6d5f-a87b-c87c-1f4686ec8234@oracle.com> References: <91d56aa4-bb65-4aea-b8f5-6e5aa2d79989@default> <94bd803a-6d5f-a87b-c87c-1f4686ec8234@oracle.com> Message-ID: <7f80a043-32ff-4e75-b9e8-f04650167166@default> Thank you Naoto for the explanation. Thank you Naoto and Andrew for your reviews. And yes, after pushing this fix, tzdata2019c(JDK-8231098) will be a clean backport. Regards, Ramanand. > -----Original Message----- > From: Naoto Sato > Sent: Wednesday, October 2, 2019 10:46 PM > To: Andrew John Hughes ; Ramanand Patil > ; jdk-updates-dev at openjdk.java.net > Subject: Re: [13u] RFR: 8212970: TZ database in "vanguard" format support > > Hi Andrew, > > On 10/1/19 12:26 PM, Andrew John Hughes wrote: > > Out of interest, why was the test data removed rather than being > > switched to vanguard format versions? > > The removal was done in the original vanguard support changeset. The > duplicated tz data in the test directory is unnecessary, as the test case > (TestZone310.java) now refers to the tz data in the "make" directory. > > HTH, > Naoto From adam.farley at uk.ibm.com Thu Oct 3 14:53:22 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Thu, 3 Oct 2019 15:53:22 +0100 Subject: RFR: JDK-8227715: GPLv2 files missing Classpath Exception Message-ID: 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 jianglizhou at google.com Thu Oct 3 20:41:41 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Thu, 3 Oct 2019 13:41:41 -0700 Subject: [11u] RFR: Backport JDK-8209657: Refactor filemap.hpp to simplify integration with Serviceability Agent Message-ID: Please review the backport of JDK-8209657: Refactor filemap.hpp to simplify integration with Serviceability Agent. webrev: http://cr.openjdk.java.net/~jiangli/backport-8209657/webrev.00/ The backport applied 99% cleanly. The only manual part involved was to apply the following diff in filemap.hpp: 311 312 CDSFileMapRegion* space_at(int i) { 313 assert(i >= 0 && i < NUM_CDS_REGIONS, "invalid region"); 314 return &_header->_space[i]; 315 } 316 }; The backport was done with the intention to downporting additional CDS bug fixes and improvements that are depending on this one. Best, Jiangli From fw at deneb.enyo.de Thu Oct 3 20:42:52 2019 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 03 Oct 2019 22:42:52 +0200 Subject: RFR: JDK-8227715: GPLv2 files missing Classpath Exception In-Reply-To: (Adam Farley8's message of "Thu, 3 Oct 2019 15:53:22 +0100") References: Message-ID: <87mueh5zn7.fsf@mid.deneb.enyo.de> * Adam Farley8: > 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/ All these files are not used at run time, so this could be deliberate. From joe.darcy at oracle.com Thu Oct 3 22:30:14 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 3 Oct 2019 15:30:14 -0700 Subject: RFR: JDK-8227715: GPLv2 files missing Classpath Exception In-Reply-To: <87mueh5zn7.fsf@mid.deneb.enyo.de> References: <87mueh5zn7.fsf@mid.deneb.enyo.de> Message-ID: It is customary to have the license of a file be updated from someone affiliated with the copyright holder of the file. -Joe On 10/3/2019 1:42 PM, Florian Weimer wrote: > * Adam Farley8: > >> 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/ > All these files are not used at run time, so this could be deliberate. From bourges.laurent at gmail.com Fri Oct 4 07:45:02 2019 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 4 Oct 2019 09:45:02 +0200 Subject: Bad push for JDK-8230728: Thin stroked shapes are not rendered if affine transform has flip bit In-Reply-To: References: Message-ID: Hi Christoph, Did you tests pass ? Is it OK to push this patch to 11u-dev now ? Cheers, Laurent Le mar. 1 oct. 2019 ? 14:46, Laurent Bourg?s a ?crit : > Hi Christoph, > > Le mar. 1 oct. 2019 ? 14:23, Langer, Christoph > a ?crit : > >> Hi Laurent, >> >> > I create the bug and submitted the RFR (simple hg backout --no-commit), >> so I >> > am waiting for approval. >> >> I added the approval labels in JBS. >> >> > I will wait a bit before pushing the patch into jdk11u-dev. >> >> If you want, I can take your jdk11u commit, run it through our testing >> for 11u-dev and push it afterwards? >> > > Thanks for your proposal, please do. > We will be sure that this patch do not cause another regression. > > Thanks, > Laurent > From christoph.langer at sap.com Fri Oct 4 08:00:18 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 4 Oct 2019 08:00:18 +0000 Subject: Bad push for JDK-8230728: Thin stroked shapes are not rendered if affine transform has flip bit In-Reply-To: References: Message-ID: Hi Laurent, tests went all fine. I have already pushed it yesterday. Best regards Christoph From: Laurent Bourg?s Sent: Freitag, 4. Oktober 2019 09:45 To: Langer, Christoph Cc: Lindenmaier, Goetz ; jdk-updates-dev at openjdk.java.net Subject: Re: Bad push for JDK-8230728: Thin stroked shapes are not rendered if affine transform has flip bit Hi Christoph, Did you tests pass ? Is it OK to push this patch to 11u-dev now ? Cheers, Laurent Le mar. 1 oct. 2019 ? 14:46, Laurent Bourg?s > a ?crit : Hi Christoph, Le mar. 1 oct. 2019 ? 14:23, Langer, Christoph > a ?crit : Hi Laurent, > I create the bug and submitted the RFR (simple hg backout --no-commit), so I > am waiting for approval. I added the approval labels in JBS. > I will wait a bit before pushing the patch into jdk11u-dev. If you want, I can take your jdk11u commit, run it through our testing for 11u-dev and push it afterwards? Thanks for your proposal, please do. We will be sure that this patch do not cause another regression. Thanks, Laurent From adam.farley at uk.ibm.com Fri Oct 4 09:11:08 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Fri, 4 Oct 2019 10:11:08 +0100 Subject: RFR: JDK-8227715: GPLv2 files missing Classpath Exception In-Reply-To: <87mueh5zn7.fsf@mid.deneb.enyo.de> References: <87mueh5zn7.fsf@mid.deneb.enyo.de> Message-ID: Heya Florian Thanks for your thoughts. My understanding of the nuances of GPLv2 is limited, but a layman's summary could describe GPLv2 as "contagious", so it seems best to have all the GPLv2-licensed code tagged as having Classpath Exception just in case they end up "infecting" code that does wind up going into the build, now or in the future. Also, I noticed EquivMapsGenerator.java had the ClasspathException added in JDK10 (in JDK-8193758), so I took that as confirmation of my "best to have it just in case" theory. Best Regards Adam Farley IBM Runtimes Florian Weimer wrote on 03/10/2019 21:42:52: > From: Florian Weimer > To: Adam Farley8 > Cc: "Java Core Libs" , jdk-updates- > dev at openjdk.java.net > Date: 03/10/2019 21:43 > Subject: Re: RFR: JDK-8227715: GPLv2 files missing Classpath Exception > > * Adam Farley8: > > > Four GPLv2 files in 8u seem to be missing the classpath exception from the > > copyright section. > > > > Requesting reviews and a sponsor. > > > > Bug: https://urldefense.proofpoint.com/v2/url? > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227715&d=DwIBAg&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=Y8tDGK7rXbdaljgwaK8pn- > poy8EHnM_ejjnBOmRkAhg&s=AnbS5uD9ZZ2e2vebZ9xoQJN_mL5ADEPBVQed5001LsM&e= > > > > Webrev: https://urldefense.proofpoint.com/v2/url? > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227715_webrev_&d=DwIBAg&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=Y8tDGK7rXbdaljgwaK8pn- > poy8EHnM_ejjnBOmRkAhg&s=5CCzOuLThZf0dIwnNaR8-FkIAM_6di17eHkNT57vbbA&e= > > All these files are not used at run time, so this could be deliberate. > 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 adam.farley at uk.ibm.com Fri Oct 4 09:12:42 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Fri, 4 Oct 2019 10:12:42 +0100 Subject: RFR: JDK-8227715: GPLv2 files missing Classpath Exception In-Reply-To: References: <87mueh5zn7.fsf@mid.deneb.enyo.de> Message-ID: Hi Joe, That sounds reasonable. Would you, or another Oracle employee, mind sponsoring the change? Best Regards Adam Farley IBM Runtimes Joe Darcy wrote on 03/10/2019 23:30:14: > From: Joe Darcy > To: Florian Weimer , Adam Farley8 > Cc: jdk-updates-dev at openjdk.java.net, Java Core Libs dev at openjdk.java.net> > Date: 03/10/2019 23:32 > Subject: Re: RFR: JDK-8227715: GPLv2 files missing Classpath Exception > > It is customary to have the license of a file be updated from someone > affiliated with the copyright holder of the file. > > -Joe > > On 10/3/2019 1:42 PM, Florian Weimer wrote: > > * Adam Farley8: > > > >> Four GPLv2 files in 8u seem to be missing the classpath exception from the > >> copyright section. > >> > >> Requesting reviews and a sponsor. > >> > >> Bug: https://urldefense.proofpoint.com/v2/url? > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227715&d=DwICaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=jo4J6W8_4sPdQyNGe-2X5R1x2eVgCKicxn2kjVwOUAQ&s=wcAkx_ZeKWB613imZ6cEieXyslKznP3D1_RhlLl9uyc&e= > >> > >> Webrev: https://urldefense.proofpoint.com/v2/url? > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227715_webrev_&d=DwICaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=jo4J6W8_4sPdQyNGe-2X5R1x2eVgCKicxn2kjVwOUAQ&s=kS- > rJ0RYE_QlLRThKVPu5A3mooj1xWNheeAy1HLxTVs&e= > > All these files are not used at run time, so this could be deliberate. > 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 bourges.laurent at gmail.com Fri Oct 4 09:58:26 2019 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 4 Oct 2019 11:58:26 +0200 Subject: Bad push for JDK-8230728: Thin stroked shapes are not rendered if affine transform has flip bit In-Reply-To: References: Message-ID: Thanks Christoph, FYI I did not get any JBS notification. Laurent Le ven. 4 oct. 2019 ? 10:00, Langer, Christoph a ?crit : > Hi Laurent, > > > > tests went all fine. I have already pushed it yesterday. > > > > Best regards > > Christoph > > > > *From:* Laurent Bourg?s > *Sent:* Freitag, 4. Oktober 2019 09:45 > *To:* Langer, Christoph > *Cc:* Lindenmaier, Goetz ; > jdk-updates-dev at openjdk.java.net > *Subject:* Re: Bad push for JDK-8230728: Thin stroked shapes are not > rendered if affine transform has flip bit > > > > Hi Christoph, > > > > Did you tests pass ? > > > > Is it OK to push this patch to 11u-dev now ? > > > > Cheers, > > Laurent > > Le mar. 1 oct. 2019 ? 14:46, Laurent Bourg?s > a ?crit : > > Hi Christoph, > > > > Le mar. 1 oct. 2019 ? 14:23, Langer, Christoph > a ?crit : > > Hi Laurent, > > > I create the bug and submitted the RFR (simple hg backout --no-commit), > so I > > am waiting for approval. > > I added the approval labels in JBS. > > > I will wait a bit before pushing the patch into jdk11u-dev. > > If you want, I can take your jdk11u commit, run it through our testing for > 11u-dev and push it afterwards? > > > > Thanks for your proposal, please do. > > We will be sure that this patch do not cause another regression. > > > > Thanks, > > Laurent > > -- -- Laurent Bourg?s From christoph.langer at sap.com Fri Oct 4 12:07:28 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 4 Oct 2019 12:07:28 +0000 Subject: Bad push for JDK-8230728: Thin stroked shapes are not rendered if affine transform has flip bit In-Reply-To: References: Message-ID: Hi Laurent, welcome. The reason that you didn?t get a notification is that I assigned the backport JBS bug JDK-8231621 to me and also didn?t add you as a watcher. So obviously only I got notified by a JBS mail. /Christoph From: Laurent Bourg?s Sent: Freitag, 4. Oktober 2019 11:58 To: Langer, Christoph Cc: Lindenmaier, Goetz ; jdk-updates-dev at openjdk.java.net Subject: Re: Bad push for JDK-8230728: Thin stroked shapes are not rendered if affine transform has flip bit Thanks Christoph, FYI I did not get any JBS notification. Laurent Le ven. 4 oct. 2019 ? 10:00, Langer, Christoph > a ?crit : Hi Laurent, tests went all fine. I have already pushed it yesterday. Best regards Christoph From: Laurent Bourg?s > Sent: Freitag, 4. Oktober 2019 09:45 To: Langer, Christoph > Cc: Lindenmaier, Goetz >; jdk-updates-dev at openjdk.java.net Subject: Re: Bad push for JDK-8230728: Thin stroked shapes are not rendered if affine transform has flip bit Hi Christoph, Did you tests pass ? Is it OK to push this patch to 11u-dev now ? Cheers, Laurent Le mar. 1 oct. 2019 ? 14:46, Laurent Bourg?s > a ?crit : Hi Christoph, Le mar. 1 oct. 2019 ? 14:23, Langer, Christoph > a ?crit : Hi Laurent, > I create the bug and submitted the RFR (simple hg backout --no-commit), so I > am waiting for approval. I added the approval labels in JBS. > I will wait a bit before pushing the patch into jdk11u-dev. If you want, I can take your jdk11u commit, run it through our testing for 11u-dev and push it afterwards? Thanks for your proposal, please do. We will be sure that this patch do not cause another regression. Thanks, Laurent -- -- Laurent Bourg?s From shade at redhat.com Fri Oct 4 12:52:07 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 4 Oct 2019 14:52:07 +0200 Subject: [11u] RFR (S) 8230061: # assert(mode == ControlAroundStripMined && use == sfpt) failed: missed a node Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8230061 Patch applies to 11u cleanly, but does not compile, because RootNode is incomplete type, and so comparisons of (Node*) == (RootNode*) fails. It does not fail in jdk/jdk, because JDK-8214862 had added it. I opted to pick up the include separately, and marked JDK-8214862 for later backports. 11u webrev: https://cr.openjdk.java.net/~shade/8230061/webrev.11u.01/ Testing: new test (fails without fix, passes with it), tier1, tier2, ctw {c1, c2} -- Thanks, -Aleksey From rwestrel at redhat.com Fri Oct 4 13:10:10 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 04 Oct 2019 15:10:10 +0200 Subject: [11u] RFR (S) 8230061: # assert(mode == ControlAroundStripMined && use == sfpt) failed: missed a node In-Reply-To: References: Message-ID: <87a7ag3bd9.fsf@redhat.com> > https://cr.openjdk.java.net/~shade/8230061/webrev.11u.01/ Looks good to me. Roland. From shade at redhat.com Fri Oct 4 14:12:20 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 4 Oct 2019 16:12:20 +0200 Subject: [11u] RFR (S) 8230061: # assert(mode == ControlAroundStripMined && use == sfpt) failed: missed a node In-Reply-To: <87a7ag3bd9.fsf@redhat.com> References: <87a7ag3bd9.fsf@redhat.com> Message-ID: On 10/4/19 3:10 PM, Roland Westrelin wrote: >> https://cr.openjdk.java.net/~shade/8230061/webrev.11u.01/ > > Looks good to me. Thanks! I've got the approval, so I would push once testing completes. -- Thanks, -Aleksey From shade at redhat.com Fri Oct 4 14:15:13 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 4 Oct 2019 16:15:13 +0200 Subject: [11u] RFR (XS) 8229022: BufferedReader performance can be improved by using StringBuilder Message-ID: <48eeb0a5-b3a9-16bf-0e6a-2a84103c88a2@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8229022 https://hg.openjdk.java.net/jdk/jdk/rev/ed0058d06107 This is a tiny RFE that does substantial performance improvement. The patch does not apply cleanly, because the context is a bit different. (Mostly because JDK-823042 LineNumberReader fixes, which I have questions about, so it is not really backportable at the moment). 11u patch: --- old/src/java.base/share/classes/java/io/BufferedReader.java 2019-10-04 16:09:45.826490807 +0200 +++ new/src/java.base/share/classes/java/io/BufferedReader.java 2019-10-04 16:09:45.674492392 +0200 @@ -312,7 +312,7 @@ * @exception IOException If an I/O error occurs */ String readLine(boolean ignoreLF) throws IOException { - StringBuffer s = null; + StringBuilder s = null; int startChar; synchronized (lock) { @@ -368,7 +368,7 @@ } if (s == null) - s = new StringBuffer(defaultExpectedLineLength); + s = new StringBuilder(defaultExpectedLineLength); s.append(cb, startChar, i - startChar); } } Testing: tier1, tier2 -- Thanks, -Aleksey From joe.darcy at oracle.com Fri Oct 4 16:28:59 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 4 Oct 2019 09:28:59 -0700 Subject: RFR: JDK-8227715: GPLv2 files missing Classpath Exception In-Reply-To: References: <87mueh5zn7.fsf@mid.deneb.enyo.de> Message-ID: <3042a38b-459e-b496-7dbd-418cd102ced1@oracle.com> Hi Adam, Someone familiar with the history and usage of these files needs to be involved with changing the license? and that doesn't include me. Cheers, -Joe On 10/4/2019 2:12 AM, Adam Farley8 wrote: > Hi Joe, > > That sounds reasonable. > > Would you, or another Oracle employee, mind sponsoring the change? > > Best Regards > > Adam Farley > IBM Runtimes > > > Joe Darcy wrote on 03/10/2019 23:30:14: > > > From: Joe Darcy > > To: Florian Weimer , Adam Farley8 > > Cc: jdk-updates-dev at openjdk.java.net, Java Core Libs > dev at openjdk.java.net> > > Date: 03/10/2019 23:32 > > Subject: Re: RFR: JDK-8227715: GPLv2 files missing Classpath Exception > > > > It is customary to have the license of a file be updated from someone > > affiliated with the copyright holder of the file. > > > > -Joe > > > > On 10/3/2019 1:42 PM, Florian Weimer wrote: > > > * Adam Farley8: > > > > > >> Four GPLv2 files in 8u seem to be missing the classpath exception > from the > > >> copyright section. > > >> > > >> Requesting reviews and a sponsor. > > >> > > >> Bug: https://urldefense.proofpoint.com/v2/url? > > > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227715&d=DwICaQ&c=jf_iaSHvJObTbx- > > siA1ZOg&r=P5m8KWUXJf- > > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=jo4J6W8_4sPdQyNGe-2X5R1x2eVgCKicxn2kjVwOUAQ&s=wcAkx_ZeKWB613imZ6cEieXyslKznP3D1_RhlLl9uyc&e= > > >> > > >> Webrev: https://urldefense.proofpoint.com/v2/url? > > > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227715_webrev_&d=DwICaQ&c=jf_iaSHvJObTbx- > > siA1ZOg&r=P5m8KWUXJf- > > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=jo4J6W8_4sPdQyNGe-2X5R1x2eVgCKicxn2kjVwOUAQ&s=kS- > > rJ0RYE_QlLRThKVPu5A3mooj1xWNheeAy1HLxTVs&e= > > > All these files are not used at run time, so this could be deliberate. > > > > 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 adam.farley at uk.ibm.com Mon Oct 7 12:51:18 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Mon, 7 Oct 2019 13:51:18 +0100 Subject: RFR: JDK-8227715: GPLv2 files missing Classpath Exception In-Reply-To: <3042a38b-459e-b496-7dbd-418cd102ced1@oracle.com> References: <87mueh5zn7.fsf@mid.deneb.enyo.de> <3042a38b-459e-b496-7dbd-418cd102ced1@oracle.com> Message-ID: Good idea Joe. :) I've added Sergey, Lana, Magnus, and Alan, all of whom seem to have at least a passing connection to these files in terms of commits. Sergey, Lana, Magnus, and Alan: Four of the files in jdk8u appear to have a GPLv2 header without the usual Classpath Exception. -- jdk/make/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java -- jdk/make/src/native/add_gnu_debuglink/add_gnu_debuglink.c -- jdk/make/src/native/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c -- jdk/src/macosx/native/jobjc/JObjC.xcodeproj/default.pbxuser Can we please ask for your opinions on whether the CE should be added for some/all of these files in 8u, and whether you'd be prepared to review/sponsor such a change? The points raised thus far: - The Oracle nature of the header means an Oracle employee should approve of any change. - Not all of these files wind up in a build, so some may only need to be considered as source. Bug: https://bugs.openjdk.java.net/browse/JDK-8227715 Webrev: http://cr.openjdk.java.net/~afarley/8227715/webrev/ Best Regards Adam Farley IBM Runtimes Joe Darcy wrote on 04/10/2019 17:28:59: > From: Joe Darcy > To: Adam Farley8 > Cc: Java Core Libs , Florian Weimer > , jdk-updates-dev at openjdk.java.net > Date: 04/10/2019 17:29 > Subject: Re: RFR: JDK-8227715: GPLv2 files missing Classpath Exception > > Hi Adam, > Someone familiar with the history and usage of these files needs to > be involved with changing the license and that doesn't include me. > Cheers, > -Joe > On 10/4/2019 2:12 AM, Adam Farley8 wrote: > Hi Joe, > > That sounds reasonable. > > Would you, or another Oracle employee, mind sponsoring the change? > > Best Regards > > Adam Farley > IBM Runtimes > > > Joe Darcy wrote on 03/10/2019 23:30:14: > > > From: Joe Darcy > > To: Florian Weimer , Adam Farley8 > > Cc: jdk-updates-dev at openjdk.java.net, Java Core Libs > dev at openjdk.java.net> > > Date: 03/10/2019 23:32 > > Subject: Re: RFR: JDK-8227715: GPLv2 files missing Classpath Exception > > > > It is customary to have the license of a file be updated from someone > > affiliated with the copyright holder of the file. > > > > -Joe > > > > On 10/3/2019 1:42 PM, Florian Weimer wrote: > > > * Adam Farley8: > > > > > >> Four GPLv2 files in 8u seem to be missing the classpath > exception from the > > >> copyright section. > > >> > > >> Requesting reviews and a sponsor. > > >> > > >> Bug: https://urldefense.proofpoint.com/v2/url? > > > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227715&d=DwICaQ&c=jf_iaSHvJObTbx- > > siA1ZOg&r=P5m8KWUXJf- > > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=jo4J6W8_4sPdQyNGe-2X5R1x2eVgCKicxn2kjVwOUAQ&s=wcAkx_ZeKWB613imZ6cEieXyslKznP3D1_RhlLl9uyc&e= > > >> > > >> Webrev: https://urldefense.proofpoint.com/v2/url? > > > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227715_webrev_&d=DwICaQ&c=jf_iaSHvJObTbx- > > siA1ZOg&r=P5m8KWUXJf- > > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=jo4J6W8_4sPdQyNGe-2X5R1x2eVgCKicxn2kjVwOUAQ&s=kS- > > rJ0RYE_QlLRThKVPu5A3mooj1xWNheeAy1HLxTVs&e= > > > All these files are not used at run time, so this could be deliberate. > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From Alan.Bateman at oracle.com Mon Oct 7 12:57:53 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 7 Oct 2019 13:57:53 +0100 Subject: RFR: JDK-8227715: GPLv2 files missing Classpath Exception In-Reply-To: References: <87mueh5zn7.fsf@mid.deneb.enyo.de> <3042a38b-459e-b496-7dbd-418cd102ced1@oracle.com> Message-ID: <84c2563e-752c-bc35-7033-55bfd31e41f2@oracle.com> On 07/10/2019 13:51, Adam Farley8 wrote: > : > -- jdk/src/macosx/native/jobjc/JObjC.xcodeproj/default.pbxuser It might be simpler to just get rid of the JObjC bits. If you dig through the JDK 8 history then you should see that JObjC.jar was dropped from the boot class path (it should never have been there in the first place). The remaining left overs were removed in JDK 9. -Alan From christoph.langer at sap.com Mon Oct 7 14:33:05 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 7 Oct 2019 14:33:05 +0000 Subject: [11u] RFR (XS) 8229022: BufferedReader performance can be improved by using StringBuilder In-Reply-To: <48eeb0a5-b3a9-16bf-0e6a-2a84103c88a2@redhat.com> References: <48eeb0a5-b3a9-16bf-0e6a-2a84103c88a2@redhat.com> Message-ID: Hi Aleksey, this looks good to me. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Aleksey Shipilev > Sent: Freitag, 4. Oktober 2019 16:15 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR (XS) 8229022: BufferedReader performance can be > improved by using StringBuilder > > RFE: > https://bugs.openjdk.java.net/browse/JDK-8229022 > https://hg.openjdk.java.net/jdk/jdk/rev/ed0058d06107 > > This is a tiny RFE that does substantial performance improvement. The patch > does not apply cleanly, > because the context is a bit different. (Mostly because JDK-823042 > LineNumberReader fixes, which I > have questions about, so it is not really backportable at the moment). > > 11u patch: > > --- old/src/java.base/share/classes/java/io/BufferedReader.java 2019- > 10-04 16:09:45.826490807 +0200 > +++ new/src/java.base/share/classes/java/io/BufferedReader.java 2019- > 10-04 16:09:45.674492392 +0200 > @@ -312,7 +312,7 @@ > * @exception IOException If an I/O error occurs > */ > String readLine(boolean ignoreLF) throws IOException { > - StringBuffer s = null; > + StringBuilder s = null; > int startChar; > > synchronized (lock) { > @@ -368,7 +368,7 @@ > } > > if (s == null) > - s = new StringBuffer(defaultExpectedLineLength); > + s = new StringBuilder(defaultExpectedLineLength); > s.append(cb, startChar, i - startChar); > } > } > > Testing: tier1, tier2 > > -- > Thanks, > -Aleksey From christoph.langer at sap.com Mon Oct 7 14:46:50 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 7 Oct 2019 14:46:50 +0000 Subject: [11u] 8215913: [Test_bug]java/util/Locale/LocaleProvidersRun.java failed on de_DE and ja_JP locale. In-Reply-To: <2ccffc50abdf43e9ca7e5895ab42be89fc54f86c.camel@redhat.com> References: <20b83df9a70a1f6651a6b56f89cf3c05766409a6.camel@redhat.com> <2ccffc50abdf43e9ca7e5895ab42be89fc54f86c.camel@redhat.com> Message-ID: Hi Severin, > > Your webrev looks fine but doesn't contain the change below to > > LocaleProviders.sh. This should definitely be done since it is an > > important part of the original change although being part of > > LocaleProvidersRun.java instead of LocaleProviders.sh. Can you update > > the webrev? Then I can put it into our queue for regression testing. > > The change below is the *antidelta* of what's been done in the original > changeset. JDK 11u's version of LocaleProviders.sh already has the > equivalent of LocaleProvidersRun.java change: > > if [ "${DEFFMTLANG}" = "zh" ] && [ "${DEFFMTCTRY}" = "CN" ]; then > ... > You're right, sorry - I was to blind to see ?? So from my end, your patch is ok as proposed. We should push it for parity. Thanks Christoph From shade at redhat.com Mon Oct 7 15:18:02 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 7 Oct 2019 17:18:02 +0200 Subject: [11u] RFR (XS) 8229022: BufferedReader performance can be improved by using StringBuilder In-Reply-To: References: <48eeb0a5-b3a9-16bf-0e6a-2a84103c88a2@redhat.com> Message-ID: <3e1dc1be-13da-f903-677e-5eabe3fbb84e@redhat.com> On 10/7/19 4:33 PM, Langer, Christoph wrote: > this looks good to me. Thanks, I see the approval tag, and going to push this shortly. -- -Aleksey From christoph.langer at sap.com Tue Oct 8 07:57:46 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 8 Oct 2019 07:57:46 +0000 Subject: [11u] Backports for OpenJDK 11.0.6 Message-ID: Hi all, as the community work for OpenJDK 11.0.5 is done and we're expecting its final release with security fixes, it's a good time now to have a look at backporting items for 11.0.6. You can find a list of JBS bugs that need backporting because Oracle picked them already for 11.0.6 here: https://bugs.openjdk.java.net/issues/?filter=37083 Or, if you don't have a JBS account, you can look here: https://builds.shipilev.net/backports-monitor/filter-openjdk-missing-11.0.6.txt Please feel encouraged to pick any issue from this list and work on its backport. If you've never done that before or are unsure of what to do, this is a good start to read: https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix To avoid duplicate work, it's a good practice to add a comment to the JBS bug, stating that you're working on an 11u backport. Eventually, you can turn this comment into a Fix request comment. Thanks everybody in advance for your help, it's much appreciated. Best regards Christoph From denghui.ddh at alibaba-inc.com Tue Oct 8 09:13:39 2019 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Tue, 08 Oct 2019 17:13:39 +0800 Subject: =?UTF-8?B?WzExdV0gUkZSIDgyMjQyMTc6IFJlY29yZGluZ0luZm8gc2hvdWxkIHVzZSB0ZXh0dWFsIHJl?= =?UTF-8?B?cHJlc2VudGF0aW9uIG9mIHBhdGg=?= Message-ID: <8dbcd7d4-6454-4049-96e0-fb7ac81220f4.denghui.ddh@alibaba-inc.com> Hi all, Please review this backport, original patch apply cleanly, but will break build, it's need to do a little change in DCmdDump.java. 11u-webrev: http://cr.openjdk.java.net/~ddong/8224217/webrev.00/ Original bug: https://bugs.openjdk.java.net/browse/JDK-8224217 http://hg.openjdk.java.net/jdk/jdk/rev/3b22c7e00573 Thanks, Denghui Dong From sgehwolf at redhat.com Tue Oct 8 09:56:24 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 08 Oct 2019 11:56:24 +0200 Subject: [11u] RFR 8224217: RecordingInfo should use textual representation of path In-Reply-To: <8dbcd7d4-6454-4049-96e0-fb7ac81220f4.denghui.ddh@alibaba-inc.com> References: <8dbcd7d4-6454-4049-96e0-fb7ac81220f4.denghui.ddh@alibaba-inc.com> Message-ID: <49d6786bfbff4f5b98c350aedf39f5cb0a19f8e8.camel@redhat.com> Hi, On Tue, 2019-10-08 at 17:13 +0800, Denghui Dong wrote: > Hi all, > Please review this backport, original patch apply cleanly, but will break build, it's need to > do a little change in DCmdDump.java. Next time, please expand *what* the nature of the "little change" in DCmdDump.java is. It makes lives of Reviewers easier. It looks like the change was originally part of JDK-8220657, but the backport to 11, didn't have it, because this patch adds getRealPathText() to WriteableUserPath.java which wasn't present when JDK-8220657 got backported to JDK 11u. > 11u-webrev: > http://cr.openjdk.java.net/~ddong/8224217/webrev.00/ Looks good. Only difference to the jdk/jdk patch is the retroactive addition of the change done via JDK-8220657 in jdk/jdk. I've added a comment on the bug that although it applies cleanly, it does not build. Hence a review was needed. Previous comments suggested the patch wouldn't need a review. Thanks, Severin > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8224217 > http://hg.openjdk.java.net/jdk/jdk/rev/3b22c7e00573 > > Thanks, > Denghui Dong From christoph.langer at sap.com Tue Oct 8 14:34:14 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 8 Oct 2019 14:34:14 +0000 Subject: [11u] RFR 8185525: Add JFR event for DictionarySizes In-Reply-To: <26f8d18c-17d7-45a1-adeb-f4cef393f61f.denghui.ddh@alibaba-inc.com> References: <26f8d18c-17d7-45a1-adeb-f4cef393f61f.denghui.ddh@alibaba-inc.com> Message-ID: Hi Denghui, this is quite a large JFR enhancement. Looking at the 11u webrev, I didn't see any obvious issues although there are obviously quite some alterations from the original patch. I'll run it through our regression testing. However, in any case, we need to carefully decide if and when we allow this patch to jdk11u-dev. I'll get back to you soon. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Denghui Dong > Sent: Donnerstag, 26. September 2019 17:03 > To: jdk-updates-dev > Subject: [11u] RFR 8185525: Add JFR event for DictionarySizes > > Hi all, > Please review this backport, original patch doesn't apply cleanly, because > SymbolTable has made some changes in upstream (I think it's not necessary > to backport those changes) > and class ClassLoaderDataGraph is located in different files. > 11u-webrev: > http://cr.openjdk.java.net/~wzhuo/8185525/webrev.00/ > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8185525 > http://hg.openjdk.java.net/jdk/jdk/rev/865ec913f916 > Testing: test/jdk/jdk/jfr/event/runtime/TestTableStatisticsEvent.java > > Thanks, > Denghui Dong From adam.farley at uk.ibm.com Tue Oct 8 15:06:16 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Tue, 8 Oct 2019 16:06:16 +0100 Subject: RFR: JDK-8227715: GPLv2 files missing Classpath Exception In-Reply-To: <84c2563e-752c-bc35-7033-55bfd31e41f2@oracle.com> References: <87mueh5zn7.fsf@mid.deneb.enyo.de> <3042a38b-459e-b496-7dbd-418cd102ced1@oracle.com> <84c2563e-752c-bc35-7033-55bfd31e41f2@oracle.com> Message-ID: Hi Alan, Removing jobjc will require changes to a bunch of files. If there's support for it, I can do the work, but we should split it into a seperate bug. So the questions are: 1) Can I get a second opinion on the complete removal of everything jobjc (in a seperate bug)? 2) What are peoples' thoughts on having the Classpath Exception added to the remaining three files? -- jdk/make/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java -- jdk/make/src/native/add_gnu_debuglink/add_gnu_debuglink.c -- jdk/make/src/native/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c Best Regards Adam Farley IBM Runtimes Alan Bateman wrote on 07/10/2019 13:57:53: > From: Alan Bateman > To: Adam Farley8 , Joe Darcy > , Sergey.Bylokhov at oracle.com, > lana.steuck at oracle.com, magnus.ihse.bursie at oracle.com > Cc: Java Core Libs , Florian Weimer > , jdk-updates-dev at openjdk.java.net > Date: 07/10/2019 13:58 > Subject: Re: RFR: JDK-8227715: GPLv2 files missing Classpath Exception > > On 07/10/2019 13:51, Adam Farley8 wrote: > : > -- jdk/src/macosx/native/jobjc/JObjC.xcodeproj/default.pbxuser > It might be simpler to just get rid of the JObjC bits. If you dig > through the JDK 8 history then you should see that JObjC.jar was > dropped from the boot class path (it should never have been there in > the first place). The remaining left overs were removed in JDK 9. > > -Alan 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 rkennke at redhat.com Wed Oct 9 13:45:15 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 9 Oct 2019 15:45:15 +0200 Subject: [11u]: 8048556: Unnecessary GCLocker-initiated young GCs Message-ID: <99781e7c-0d41-4dec-a88b-52874a794b41@redhat.com> I'd like to backport the change to 11u. Original bug: https://bugs.openjdk.java.net/browse/JDK-8048556 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/8d3886985964 11u backport: http://cr.openjdk.java.net/~rkennke/JDK-8048556/webrev-11.00/ Differences to original change are: - Renamed files (e.g. vmGCOperations vs. gcVMOperations) - In g1CollectedHeap.cpp, instead of "return false" only "return" because that method is void in 11u. Functionally it should be equivalent. The supplied testcase fails without the patch, and passes with the patch. tier1 and tier2 are looking good here, without regressions. Can I please get a review? Thanks, Roman From hohensee at amazon.com Wed Oct 9 15:49:43 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 9 Oct 2019 15:49:43 +0000 Subject: [11u]: 8048556: Unnecessary GCLocker-initiated young GCs In-Reply-To: <99781e7c-0d41-4dec-a88b-52874a794b41@redhat.com> References: <99781e7c-0d41-4dec-a88b-52874a794b41@redhat.com> Message-ID: Looks good. Paul ?On 10/9/19, 6:49 AM, "jdk-updates-dev on behalf of Roman Kennke" wrote: I'd like to backport the change to 11u. Original bug: https://bugs.openjdk.java.net/browse/JDK-8048556 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/8d3886985964 11u backport: http://cr.openjdk.java.net/~rkennke/JDK-8048556/webrev-11.00/ Differences to original change are: - Renamed files (e.g. vmGCOperations vs. gcVMOperations) - In g1CollectedHeap.cpp, instead of "return false" only "return" because that method is void in 11u. Functionally it should be equivalent. The supplied testcase fails without the patch, and passes with the patch. tier1 and tier2 are looking good here, without regressions. Can I please get a review? Thanks, Roman From christoph.langer at sap.com Thu Oct 10 09:49:49 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 10 Oct 2019 09:49:49 +0000 Subject: [11u] RFR 8224217: RecordingInfo should use textual representation of path In-Reply-To: <49d6786bfbff4f5b98c350aedf39f5cb0a19f8e8.camel@redhat.com> References: <8dbcd7d4-6454-4049-96e0-fb7ac81220f4.denghui.ddh@alibaba-inc.com> <49d6786bfbff4f5b98c350aedf39f5cb0a19f8e8.camel@redhat.com> Message-ID: Hi, thanks for running the review on this. I pushed the fix now after running it through our testing. Cheers Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Severin Gehwolf > Sent: Dienstag, 8. Oktober 2019 11:56 > To: Denghui Dong ; jdk-updates- > dev at openjdk.java.net > Subject: Re: [11u] RFR 8224217: RecordingInfo should use textual > representation of path > > Hi, > > On Tue, 2019-10-08 at 17:13 +0800, Denghui Dong wrote: > > Hi all, > > Please review this backport, original patch apply cleanly, but will break > build, it's need to > > do a little change in DCmdDump.java. > > Next time, please expand *what* the nature of the "little change" in > DCmdDump.java is. It makes lives of Reviewers easier. > > It looks like the change was originally part of JDK-8220657, but the > backport to 11, didn't have it, because this patch adds > getRealPathText() to WriteableUserPath.java which wasn't present when > JDK-8220657 got backported to JDK 11u. > > > 11u-webrev: > > http://cr.openjdk.java.net/~ddong/8224217/webrev.00/ > > Looks good. > > Only difference to the jdk/jdk patch is the retroactive addition of the > change done via JDK-8220657 in jdk/jdk. > > I've added a comment on the bug that although it applies cleanly, it > does not build. Hence a review was needed. Previous comments suggested > the patch wouldn't need a review. > > Thanks, > Severin > > > Original bug: > > https://bugs.openjdk.java.net/browse/JDK-8224217 > > http://hg.openjdk.java.net/jdk/jdk/rev/3b22c7e00573 > > > > Thanks, > > Denghui Dong From christoph.langer at sap.com Thu Oct 10 10:14:00 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 10 Oct 2019 10:14:00 +0000 Subject: [11u] RFR: Backport JDK-8209657: Refactor filemap.hpp to simplify integration with Serviceability Agent In-Reply-To: References: Message-ID: Hi Jiangli, the webrev looks good to me and I ran it together with the other CDS related backports that you requested through our test system. We didn't see regressions. Please allow some time to consult with Andrew on whether to approve the backports for pushing. Thanks Christoph > -----Original Message----- > From: hotspot-runtime-dev bounces at openjdk.java.net> On Behalf Of Jiangli Zhou > Sent: Donnerstag, 3. Oktober 2019 22:42 > To: jdk-updates-dev at openjdk.java.net; hotspot-runtime-dev runtime-dev at openjdk.java.net> > Subject: [11u] RFR: Backport JDK-8209657: Refactor filemap.hpp to simplify > integration with Serviceability Agent > > Please review the backport of JDK-8209657: Refactor filemap.hpp to > simplify integration with Serviceability Agent. > > webrev: http://cr.openjdk.java.net/~jiangli/backport-8209657/webrev.00/ > > The backport applied 99% cleanly. The only manual part involved was to > apply the following diff in filemap.hpp: > > 311 > 312 CDSFileMapRegion* space_at(int i) { > 313 assert(i >= 0 && i < NUM_CDS_REGIONS, "invalid region"); > 314 return &_header->_space[i]; > 315 } > 316 }; > > The backport was done with the intention to downporting additional CDS > bug fixes and improvements that are depending on this one. > > Best, > > Jiangli From christoph.langer at sap.com Thu Oct 10 12:16:25 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 10 Oct 2019 12:16:25 +0000 Subject: [11u] RFR: 8212028: Use run-test makefile framework for testing in Oracle's Mach5 Message-ID: Hi, please help reviewing this backport of a build infrastructure change to jdk11u. One reason for doing this is parity with Oracle's 11.0.6 but the patch also contains some test improvements which will help stabilizing 11u testing. This mainly means increasing some test timeouts for a few tests that tend to timeout on slow or busy test hardware. The patch mostly applies, apart from these two rejects: make/RunTests.gmk: http://cr.openjdk.java.net/~clanger/webrevs/8212028.11u-dev.0/8212028-RunTests.gmk.rej make/RunTestsPrebuilt.gmk: http://cr.openjdk.java.net/~clanger/webrevs/8212028.11u-dev.0/8212028-RunTestsPrebuilt.gmk.rej So, when reviewing, please have the most thorough look at these places. I ran the fix through our nightly tests and didn't find regressions. I'm planning to push backport JDK-8213005 together with this change, as it fixes a regression for it. Bug: https://bugs.openjdk.java.net/browse/JDK-8212028 Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/28375a1de254 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8212028.11u-dev.0/ Thanks Christoph From ralf.schmelter at sap.com Thu Oct 10 12:25:20 2019 From: ralf.schmelter at sap.com (Schmelter, Ralf) Date: Thu, 10 Oct 2019 12:25:20 +0000 Subject: [13u] RFR (S) Backport JDK-8191521: handle long relative path specified in -Xbootclasspath/a on windows Message-ID: I'd like to backport the change to 13u. Original bug: https://bugs.openjdk.java.net/browse/JDK-8191521 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/ed5e399d967d 11u backport: http://cr.openjdk.java.net/~rschmelter/webrevs/8191521/webrev.jdku13.01/ The patch had to be modified since it also adjusted the os:: same_files() method, which is not present in JDK13. Otherwise it applied cleanly. Best regards, Ralf From sgehwolf at redhat.com Thu Oct 10 13:14:32 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 10 Oct 2019 15:14:32 +0200 Subject: [11u] RFR: 8212028: Use run-test makefile framework for testing in Oracle's Mach5 In-Reply-To: References: Message-ID: <944b97e0ea1b85db6b6a3c9cb36ef3ac3973b728.camel@redhat.com> Hi Christoph, On Thu, 2019-10-10 at 12:16 +0000, Langer, Christoph wrote: > Hi, > > please help reviewing this backport of a build infrastructure change to jdk11u. > > One reason for doing this is parity with Oracle's 11.0.6 but the patch also contains some test improvements which will help stabilizing 11u testing. This mainly means increasing some test timeouts for a few tests that tend to timeout on slow or busy test hardware. > > The patch mostly applies, apart from these two rejects: > make/RunTests.gmk: http://cr.openjdk.java.net/~clanger/webrevs/8212028.11u-dev.0/8212028-RunTests.gmk.rej > make/RunTestsPrebuilt.gmk: http://cr.openjdk.java.net/~clanger/webrevs/8212028.11u-dev.0/8212028-RunTestsPrebuilt.gmk.rej > So, when reviewing, please have the most thorough look at these places. > > I ran the fix through our nightly tests and didn't find regressions. I'm planning to push backport JDK-8213005 together with this change, as it fixes a regression for it. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212028 > Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/28375a1de254 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8212028.11u-dev.0/ 222 langtools_JTREG_MAX_MEM := 768m 223 224 langtools_JTREG_MAX_MEM := 768m Lines 222 and 224 in RunTests.gmk are duplicates. Otherwise seems fine. Thanks, Severin From christoph.langer at sap.com Thu Oct 10 13:47:40 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 10 Oct 2019 13:47:40 +0000 Subject: [11u] RFR: 8212028: Use run-test makefile framework for testing in Oracle's Mach5 In-Reply-To: <944b97e0ea1b85db6b6a3c9cb36ef3ac3973b728.camel@redhat.com> References: <944b97e0ea1b85db6b6a3c9cb36ef3ac3973b728.camel@redhat.com> Message-ID: Hi Severin, good catch, thank you. Adjusted webrev: http://cr.openjdk.java.net/~clanger/webrevs/8212028.11u-dev.1/ Best regards Christoph > -----Original Message----- > From: Severin Gehwolf > Sent: Donnerstag, 10. Oktober 2019 15:15 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net; build-dev > Subject: Re: [11u] RFR: 8212028: Use run-test makefile framework for testing > in Oracle's Mach5 > > Hi Christoph, > > On Thu, 2019-10-10 at 12:16 +0000, Langer, Christoph wrote: > > Hi, > > > > please help reviewing this backport of a build infrastructure change to > jdk11u. > > > > One reason for doing this is parity with Oracle's 11.0.6 but the patch also > contains some test improvements which will help stabilizing 11u testing. This > mainly means increasing some test timeouts for a few tests that tend to > timeout on slow or busy test hardware. > > > > The patch mostly applies, apart from these two rejects: > > make/RunTests.gmk: > http://cr.openjdk.java.net/~clanger/webrevs/8212028.11u-dev.0/8212028- > RunTests.gmk.rej > > make/RunTestsPrebuilt.gmk: > http://cr.openjdk.java.net/~clanger/webrevs/8212028.11u-dev.0/8212028- > RunTestsPrebuilt.gmk.rej > > So, when reviewing, please have the most thorough look at these places. > > > > I ran the fix through our nightly tests and didn't find regressions. I'm > planning to push backport JDK-8213005 together with this change, as it fixes a > regression for it. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212028 > > Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/28375a1de254 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8212028.11u- > dev.0/ > > 222 langtools_JTREG_MAX_MEM := 768m > 223 > 224 langtools_JTREG_MAX_MEM := 768m > > Lines 222 and 224 in RunTests.gmk are duplicates. > > Otherwise seems fine. > > Thanks, > Severin From christoph.langer at sap.com Thu Oct 10 13:58:42 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 10 Oct 2019 13:58:42 +0000 Subject: [13u] RFR (S) Backport JDK-8191521: handle long relative path specified in -Xbootclasspath/a on windows In-Reply-To: References: Message-ID: Hi Ralf, your patch looks good to me, seems correctly resolved to jdk13u. I see that you have inlined both, "8231885: Fix/remove malformed assert in os_windows.cpp" and "8231930: Windows build fails after JDK-8191521", which makes sense to me. I've added jdk13u-fix-request labels to these bugs as well. As you've already put it through SAP's nightly regression testing, I can also confirm that there are no new regressions and the test cases where we saw failures without the patch don't have an error any longer. These are: vmTestbase/nsk/jvmti/AddToBootstrapClassLoaderSearch/bootclssearch001/TestDescription.java vmTestbase/nsk/jvmti/AddToBootstrapClassLoaderSearch/bootclssearch002/TestDescription.java vmTestbase/nsk/jvmti/AddToBootstrapClassLoaderSearch/bootclssearch003/TestDescription.java vmTestbase/nsk/jvmti/AddToBootstrapClassLoaderSearch/bootclssearch004/TestDescription.java vmTestbase/nsk/jvmti/AddToBootstrapClassLoaderSearch/bootclssearch007/TestDescription.java vmTestbase/nsk/jvmti/AddToBootstrapClassLoaderSearch/bootclssearch010/TestDescription.java vmTestbase/nsk/jvmti/unit/functions/AddToBootstrapClassLoaderSearch/JvmtiTest/TestDescription.java Thanks Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Schmelter, Ralf > Sent: Donnerstag, 10. Oktober 2019 14:25 > To: jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] [13u] RFR (S) Backport JDK-8191521: handle long relative > path specified in -Xbootclasspath/a on windows > > I'd like to backport the change to 13u. > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8191521 > > Original change: > https://hg.openjdk.java.net/jdk/jdk/rev/ed5e399d967d > > 11u backport: > http://cr.openjdk.java.net/~rschmelter/webrevs/8191521/webrev.jdku13.0 > 1/ > > The patch had to be modified since it also adjusted the os:: same_files() > method, which is not present in JDK13. > Otherwise it applied cleanly. > > Best regards, > Ralf From jianglizhou at google.com Thu Oct 10 14:36:39 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Thu, 10 Oct 2019 07:36:39 -0700 Subject: [11u] RFR: Backport JDK-8209657: Refactor filemap.hpp to simplify integration with Serviceability Agent In-Reply-To: References: Message-ID: Thank you so much, Christoph! Will wait. Best regards, Jiangli On Thu, Oct 10, 2019 at 3:14 AM Langer, Christoph wrote: > > Hi Jiangli, > > the webrev looks good to me and I ran it together with the other CDS related backports that you requested through our test system. We didn't see regressions. > > Please allow some time to consult with Andrew on whether to approve the backports for pushing. > > Thanks > Christoph > > > -----Original Message----- > > From: hotspot-runtime-dev > bounces at openjdk.java.net> On Behalf Of Jiangli Zhou > > Sent: Donnerstag, 3. Oktober 2019 22:42 > > To: jdk-updates-dev at openjdk.java.net; hotspot-runtime-dev > runtime-dev at openjdk.java.net> > > Subject: [11u] RFR: Backport JDK-8209657: Refactor filemap.hpp to simplify > > integration with Serviceability Agent > > > > Please review the backport of JDK-8209657: Refactor filemap.hpp to > > simplify integration with Serviceability Agent. > > > > webrev: http://cr.openjdk.java.net/~jiangli/backport-8209657/webrev.00/ > > > > The backport applied 99% cleanly. The only manual part involved was to > > apply the following diff in filemap.hpp: > > > > 311 > > 312 CDSFileMapRegion* space_at(int i) { > > 313 assert(i >= 0 && i < NUM_CDS_REGIONS, "invalid region"); > > 314 return &_header->_space[i]; > > 315 } > > 316 }; > > > > The backport was done with the intention to downporting additional CDS > > bug fixes and improvements that are depending on this one. > > > > Best, > > > > Jiangli From dalibor.topic at oracle.com Thu Oct 10 15:35:31 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 10 Oct 2019 17:35:31 +0200 Subject: ea tags for the short lived jdk versions? In-Reply-To: References: Message-ID: Second try. On 10.10.2019 16:07, Dalibor Topic wrote: > Hi Matthias, > > Since your question is about JDK updates, bcc:ing jdk-dev and passing it > on to jdk-updates-dev. > > cheers, > dalibor topic > > On 10.10.2019 12:06, Matthias Klose wrote: >> With the LTS branches, you have a new well defined pre-release >> process, leading to the release.? With the development branch (14), >> you have weekly tags. However with the short lived jdk versions (13 in >> this case), there is nothing comparable.? The current tip of >> jdk-updates/jdk13 still has the release settings on the branch, and no >> version different from the release.? Would it be possible to have such >> ea tags on the short lived branches as well? >> >> Thanks, Matthias > -- Dalibor Topic | Consulting Product Manager Phone: +494089091214 | Mobile: +491737185961 | Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann Oracle is committed to developing practices and products that help protect the environment From rob.mckenna at oracle.com Thu Oct 10 21:39:11 2019 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 10 Oct 2019 22:39:11 +0100 Subject: [13u Communication] 13.0.2 entering RDP2 soon Message-ID: <20191010213911.GC5583@vimes> Hi folks, Just a heads up that 13.0.2 will be in RDP2 after next week. (from the 21st) If you have outstanding changes it would be better to push them sooner rather than later. Fix request justifications beyond that point will endure significantly more scrutiny. Thanks, -Rob From christoph.langer at sap.com Thu Oct 10 21:52:52 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 10 Oct 2019 21:52:52 +0000 Subject: ea tags for the short lived jdk versions? In-Reply-To: References: Message-ID: Hi Matthias, which repository exactly do you mean for jdk13? If you look at http://hg.openjdk.java.net/jdk-updates/jdk13u/, you'll definitely find a lot of differences compared to the jdk13 release repo http://hg.openjdk.java.net/jdk/jdk13/. But the tip of jdk-updates/jdk13u is on a 13.0.2 development level currently and it's hard to tell what the baseline for 13.0.1 was (e.g. there is no tag). You can refer to this mail for figuring out the closest commit to the upcoming 13.0.1: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-September/001814.html Unfortunately, there are no build tags (yet) for certain update releases, e.g. 13.0.1-n or 13.0.2-n. They'll only be merged back from the internal Oracle repositories that are used to build the update releases after GA of an update release. I, however, agree that it would be nicer if OpenJDK Update release development could be done more in the open by Oracle and we could see regular tags (just as we have in 8u and 11u OpenJDK projects). But I guess Oracle would need to change their processes a bit for that. Maybe Rob wants to comment on it... Best regards Christoph > -----Original Message----- > From: jdk-dev On Behalf Of Matthias > Klose > Sent: Donnerstag, 10. Oktober 2019 12:06 > To: jdk-dev > Subject: ea tags for the short lived jdk versions? > > With the LTS branches, you have a new well defined pre-release process, > leading > to the release. With the development branch (14), you have weekly tags. > However with the short lived jdk versions (13 in this case), there is nothing > comparable. The current tip of jdk-updates/jdk13 still has the release > settings > on the branch, and no version different from the release. Would it be > possible > to have such ea tags on the short lived branches as well? > > Thanks, Matthias From dalibor.topic at oracle.com Thu Oct 10 14:07:06 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 10 Oct 2019 16:07:06 +0200 Subject: ea tags for the short lived jdk versions? In-Reply-To: References: Message-ID: Hi Matthias, Since your question is about JDK updates, bcc:ing jdk-dev and passing it on to jdk-updates-dev. cheers, dalibor topic On 10.10.2019 12:06, Matthias Klose wrote: > With the LTS branches, you have a new well defined pre-release process, > leading to the release.? With the development branch (14), you have > weekly tags. However with the short lived jdk versions (13 in this > case), there is nothing comparable.? The current tip of > jdk-updates/jdk13 still has the release settings on the branch, and no > version different from the release.? Would it be possible to have such > ea tags on the short lived branches as well? > > Thanks, Matthias -- Dalibor Topic | Consulting Product Manager Phone: +494089091214 | Mobile: +491737185961 | Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann Oracle is committed to developing practices and products that help protect the environment From sgehwolf at redhat.com Fri Oct 11 08:04:07 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 11 Oct 2019 10:04:07 +0200 Subject: [11u] RFR: 8212028: Use run-test makefile framework for testing in Oracle's Mach5 In-Reply-To: References: <944b97e0ea1b85db6b6a3c9cb36ef3ac3973b728.camel@redhat.com> Message-ID: <1ef3f2176ca444c7cf8f3c54b835d084bc51afa5.camel@redhat.com> On Thu, 2019-10-10 at 13:47 +0000, Langer, Christoph wrote: > Adjusted webrev: http://cr.openjdk.java.net/~clanger/webrevs/8212028.11u-dev.1/ Seems OK to me. Thanks, Severin From dalibor.topic at oracle.com Fri Oct 11 13:33:49 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 11 Oct 2019 15:33:49 +0200 Subject: ea tags for the short lived jdk versions? In-Reply-To: References: Message-ID: On 10.10.2019 23:52, Langer, Christoph wrote: > Unfortunately, there are no build tags (yet) for certain update releases, e.g. 13.0.1-n or 13.0.2-n. They'll only be merged back from the internal Oracle repositories that are used to build the update releases after GA of an update release. I, however, agree that it would be nicer if OpenJDK Update release development could be done more in the open by Oracle and we could see regular tags (just as we have in 8u and 11u OpenJDK projects). But I guess Oracle would need to change their processes a bit for that. Maybe Rob wants to comment on it... We don't publish EA builds of JDK 13 CPU updates so there wouldn't be anything really meaningful to tag in the repo. cheers, dalibor topic -- Dalibor Topic | Consulting Product Manager Phone: +494089091214 | Mobile: +491737185961 | Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann Oracle is committed to developing practices and products that help protect the environment From doko at ubuntu.com Fri Oct 11 16:34:10 2019 From: doko at ubuntu.com (Matthias Klose) Date: Fri, 11 Oct 2019 18:34:10 +0200 Subject: ea tags for the short lived jdk versions? In-Reply-To: References: Message-ID: On 11.10.19 15:33, Dalibor Topic wrote: > On 10.10.2019 23:52, Langer, Christoph wrote: >> Unfortunately, there are no build tags (yet) for certain update releases, e.g. >> 13.0.1-n or 13.0.2-n. They'll only be merged back from the internal Oracle >> repositories that are used to build the update releases after GA of an update >> release. I, however, agree that it would be nicer if OpenJDK Update release >> development could be done more in the open by Oracle and we could see regular >> tags (just as we have in 8u and 11u OpenJDK projects). But I guess Oracle >> would need to change their processes a bit for that. Maybe Rob wants to >> comment on it... > > We don't publish EA builds of JDK 13 CPU updates so there wouldn't be anything > really meaningful to tag in the repo. well, yes, that's what I see today. No need to re-state the obvious ;) If I do an ea build from the tip, then I get a build with the very same version, as the ga tag. Which version should I use for that, inventing a mystery meat version? Just removing the ga flag? Should I assume the version for the next release, and inventing one? It's always good to test a build with all the stuff just before the security release. Matthias From zgu at redhat.com Fri Oct 11 17:17:20 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 11 Oct 2019 13:17:20 -0400 Subject: [11u] RFR 8229020: Failure on CPUs allowing loads reordering: assert(_tasks[t] == 1) failed: What else? Message-ID: <3c7260f8-6591-dc47-2797-11c9d26e68fd@redhat.com> Hi, Please review this one line patch. It removes a paranoid assertion, that may trigger false alarm on weak memory systems. The original patch does not apply cleanly, mainly just due to line shifts. Original patch:http://cr.openjdk.java.net/~jiefu/8229020/webrev.02/ Original code review thread: https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-August/026643.html Bug: https://bugs.openjdk.java.net/browse/JDK-8229020 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8229020-11u/webrev.00/ Thanks, -Zhengyu From hohensee at amazon.com Fri Oct 11 21:59:20 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 11 Oct 2019 21:59:20 +0000 Subject: [11u] RFR 8229020: Failure on CPUs allowing loads reordering: assert(_tasks[t] == 1) failed: What else? In-Reply-To: <3c7260f8-6591-dc47-2797-11c9d26e68fd@redhat.com> References: <3c7260f8-6591-dc47-2797-11c9d26e68fd@redhat.com> Message-ID: <06C3964B-EE2D-4329-933D-00949E85654D@amazon.com> Lgtm. Also, you don't have to request a review if a patch applies cleanly net of file name/location/line number changes. Just note that is the case in your JBS issue comment when you tag the bug with jdk11u-fix-request. Paul ?On 10/11/19, 10:24 AM, "jdk-updates-dev on behalf of Zhengyu Gu" wrote: Hi, Please review this one line patch. It removes a paranoid assertion, that may trigger false alarm on weak memory systems. The original patch does not apply cleanly, mainly just due to line shifts. Original patch:http://cr.openjdk.java.net/~jiefu/8229020/webrev.02/ Original code review thread: https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-August/026643.html Bug: https://bugs.openjdk.java.net/browse/JDK-8229020 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8229020-11u/webrev.00/ Thanks, -Zhengyu From dalibor.topic at oracle.com Mon Oct 14 10:48:17 2019 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Mon, 14 Oct 2019 12:48:17 +0200 Subject: ea tags for the short lived jdk versions? In-Reply-To: References: Message-ID: <984a1bd5-49c2-ddd2-e54c-8444b5e3a72f@oracle.com> On 11.10.2019 18:34, Matthias Klose wrote: > On 11.10.19 15:33, Dalibor Topic wrote: >> On 10.10.2019 23:52, Langer, Christoph wrote: >>> Unfortunately, there are no build tags (yet) for certain update >>> releases, e.g. 13.0.1-n or 13.0.2-n. They'll only be merged back from >>> the internal Oracle repositories that are used to build the update >>> releases after GA of an update release. I, however, agree that it >>> would be nicer if OpenJDK Update release development could be done >>> more in the open by Oracle and we could see regular tags (just as we >>> have in 8u and 11u OpenJDK projects). But I guess Oracle would need >>> to change their processes a bit for that. Maybe Rob wants to comment >>> on it... >> >> We don't publish EA builds of JDK 13 CPU updates so there wouldn't be >> anything really meaningful to tag in the repo. > > well, yes, that's what I see today.? No need to re-state the obvious ;) > > If I do an ea build from the tip, then I get a build with the very same > version, as the ga tag.? Which version should I use for that, inventing > a mystery meat version? Just removing the ga flag?? Should I assume the > version for the next release, and inventing one?? It's always good to > test a build with all the stuff just before the security release. > I think that's mostly answered by https://openjdk.java.net/jeps/322 "Version strings The overall format of version strings is the same as that defined in JEP 223. A version string is a version number, $VNUM, possibly followed by pre-release, build, and other optional information, one of: $VNUM(-$PRE)?\+$BUILD(-$OPT)? $VNUM-$PRE(-$OPT)? $VNUM(+-$OPT)? where $PRE is a pre-release identifier (e.g., ea), $BUILD is a build number, and $OPT is optional build information." So, for example, 13.0.2-ea-55626 could be a way to indicate an EA build of 13.0.2 that is built with the tip at the 55626'th changeset. Keep in mind that there is more relevant stuff in that JEP than just this snippet, like new properties you may want to look at. cheers, dalibor topic -- Dalibor Topic | Consulting Product Manager Phone: +494089091214 | Mobile: +491737185961 | Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann Oracle is committed to developing practices and products that help protect the environment From zgu at redhat.com Tue Oct 15 12:08:33 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 15 Oct 2019 08:08:33 -0400 Subject: [11u] RFR 8229020: Failure on CPUs allowing loads reordering: assert(_tasks[t] == 1) failed: What else? In-Reply-To: <06C3964B-EE2D-4329-933D-00949E85654D@amazon.com> References: <3c7260f8-6591-dc47-2797-11c9d26e68fd@redhat.com> <06C3964B-EE2D-4329-933D-00949E85654D@amazon.com> Message-ID: <1cda13bf-8e04-df8f-ada0-4f56495cd15e@redhat.com> Thanks for reviewing, Paul. On 10/11/19 5:59 PM, Hohensee, Paul wrote: > Lgtm. Also, you don't have to request a review if a patch applies cleanly net of file name/location/line number changes. Just note that is the case in your JBS issue comment when you tag the bug with jdk11u-fix-request. Well, it is not always the case. I was asked to submit code review request in similar scenario before. So, I figured just sent code review request anyway :-) -Zhengyu > > Paul > > ?On 10/11/19, 10:24 AM, "jdk-updates-dev on behalf of Zhengyu Gu" wrote: > > Hi, > > Please review this one line patch. > > It removes a paranoid assertion, that may trigger false alarm on weak > memory systems. > > The original patch does not apply cleanly, mainly just due to line shifts. > > Original patch:http://cr.openjdk.java.net/~jiefu/8229020/webrev.02/ > Original code review thread: > https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-August/026643.html > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8229020 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8229020-11u/webrev.00/ > > Thanks, > > -Zhengyu > > > From shade at redhat.com Tue Oct 15 18:40:54 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 15 Oct 2019 20:40:54 +0200 Subject: [11] RFR 8232051: Epsilon should warn about Xms/Xmx/AlwaysPreTouch configuration Message-ID: <0890f008-b606-e898-cc4b-8cc6d92ea1ec@redhat.com> Original RFE: https://bugs.openjdk.java.net/browse/JDK-8232051 https://hg.openjdk.java.net/jdk/jdk/rev/10db6989907f Patch does not apply to 11u cleanly, because global package declaration in tests (JDK-8214799) is not done in 11u. Only test is affected. 11u webrev: https://cr.openjdk.java.net/~shade/8232051/webrev.11u.01/ Testing: gc/epsilon {fastdebug,release}, adhoc tests -- Thanks, -Aleksey From gnu.andrew at redhat.com Tue Oct 15 20:34:14 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 15 Oct 2019 21:34:14 +0100 Subject: [RFR] [11u] 11.0.5+10 Message-ID: <9c3e673e-f3a3-8701-686e-39925a4fb1be@redhat.com> Here are the remaining changes for the jdk11u repository: Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/11.0.5/ Changes: - S8209901: Canonical file handling - S8213429, CVE-2019-2933: Windows file handling redux - S8218573, CVE-2019-2945: Better socket support - S8218877: Help transform transformers - S8219914: Change the environment variable for Java Access Bridge logging to have a directory. - 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 - S8223886: Add in font table referene - S8223892, CVE-2019-2978: Improved handling of jar files - S8224025: Fix for JDK-8220302 is not complete - S8224062, CVE-2019-2977: Improve String index handling - 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 - S8227601: Better collection of references - S8228825, CVE-2019-2894: Enhance ECDSA operations The result is tagged 11.0.5+10 and 11.0.5-ga. Ok to push? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Tue Oct 15 20:43:55 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 15 Oct 2019 22:43:55 +0200 Subject: [RFR] [11u] 11.0.5+10 In-Reply-To: <9c3e673e-f3a3-8701-686e-39925a4fb1be@redhat.com> References: <9c3e673e-f3a3-8701-686e-39925a4fb1be@redhat.com> Message-ID: On 10/15/19 10:34 PM, Andrew John Hughes wrote: > Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/11.0.5/ Looks good. There are many indenting and whitespace changes that are confusing and not necessary, but I guess there is no point in editing them here, as the same is probably done in all release trains. -- Thanks, -Aleksey From gnu.andrew at redhat.com Tue Oct 15 21:03:36 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 15 Oct 2019 22:03:36 +0100 Subject: [RFR] [11u] 11.0.5+10 In-Reply-To: References: <9c3e673e-f3a3-8701-686e-39925a4fb1be@redhat.com> Message-ID: On 15/10/2019 21:43, Aleksey Shipilev wrote: > On 10/15/19 10:34 PM, Andrew John Hughes wrote: >> Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/11.0.5/ > > Looks good. > > There are many indenting and whitespace changes that are confusing and not necessary, but I guess > there is no point in editing them here, as the same is probably done in all release trains. > Yeah, a patch for HEAD, then backported would be a better idea. Pushed (after an empty merge of the backed out changeset...) -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From christoph.langer at sap.com Wed Oct 16 06:26:01 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 16 Oct 2019 06:26:01 +0000 Subject: [RFR] [11u] 11.0.5+10 In-Reply-To: References: <9c3e673e-f3a3-8701-686e-39925a4fb1be@redhat.com> Message-ID: Looks good. Thanks Andrew ?? > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Andrew John Hughes > Sent: Dienstag, 15. Oktober 2019 23:04 > To: Aleksey Shipilev ; 'jdk-updates- > dev at openjdk.java.net' > Subject: Re: [RFR] [11u] 11.0.5+10 > > > > On 15/10/2019 21:43, Aleksey Shipilev wrote: > > On 10/15/19 10:34 PM, Andrew John Hughes wrote: > >> Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/11.0.5/ > > > > Looks good. > > > > There are many indenting and whitespace changes that are confusing and > not necessary, but I guess > > there is no point in editing them here, as the same is probably done in all > release trains. > > > > Yeah, a patch for HEAD, then backported would be a better idea. > > Pushed (after an empty merge of the backed out changeset...) > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew From shade at redhat.com Wed Oct 16 08:01:41 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 16 Oct 2019 10:01:41 +0200 Subject: CPU pushes for 13.0.1, 13.0.2 Message-ID: Hi Rob, Just checking: are you planning to push CPU changes to jdk-updates/jdk13u? Downstream builders would appreciate that :) -- Thanks, -Aleksey From ralf.schmelter at sap.com Wed Oct 16 10:35:07 2019 From: ralf.schmelter at sap.com (Schmelter, Ralf) Date: Wed, 16 Oct 2019 10:35:07 +0000 Subject: [11u] RFR 8190737:use unicode version of the canonicalize() function to handle long path on windows Message-ID: Hello, please review this fix. The patch itself applied cleanly, but the LongBCP.java test needed an additional import statement. Original bugreport: https://bugs.openjdk.java.net/browse/JDK-8190737 Original change: http://hg.openjdk.java.net/jdk/jdk/rev/9151fde080e6 Webrev of downport: http://cr.openjdk.java.net/~rschmelter/webrevs/8190737/webrev.jdk11u-dev.1/index.html Best regards, Ralf From gnu.andrew at redhat.com Wed Oct 16 13:10:20 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 16 Oct 2019 14:10:20 +0100 Subject: OpenJDK 11.0.5 Released Message-ID: <3d7e7639-8d62-8c93-652a-34383d32ac33@redhat.com> We are pleased to announce the release of OpenJDK 11.0.5. The source tarball is available from: * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.5-ga.tar.xz The tarball is accompanied by a digital signature available at: * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.5-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: 8115a984eec702b60715c7e9af895706b649b4b574ca213162a0cc8e978120dc openjdk-11.0.5-ga.tar.xz 72e68616df0acc120142ce07dea32798944ddf59c7c9e0e0c61c0f74cc18feb8 openjdk-11.0.5-ga.tar.xz.sig The checksums can be downloaded from: * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.5-ga.sha256 What's New? =========== * Security fixes - S8209901: Canonical file handling - 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 - S8223886: Add in font table referene - S8223892, CVE-2019-2978: Improved handling of jar files - S8224025: Fix for JDK-8220302 is not complete - S8224062, CVE-2019-2977: Improve String index handling - 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 - S8227601: Better collection of references - S8228825, CVE-2019-2894: Enhance ECDSA operations * Other changes - S6996807: FieldReflectorKey hash code computation can be improved - S8076988: reevaluate trivial method policy - S8087128: C2: Disallow definition split on MachCopySpill nodes - S8133489: Better messaging for PKIX path validation matching - S8139965: Hang seen when using com.sun.jndi.ldap.search.replyQueueSize - S8147502: Digest is incorrectly truncated for ECDSA signatures when the bit length of n is less than the field size - S8148188: Enhance the security libraries to record events of interest - S8163363: AArch64: Stack size in tools/launcher/Settings.java needs to be adjusted - S8163511: Allocation of compile task fails with assert: "Leaking compilation tasks?" - S8170639: [Linux] jsig is limited to a maximum of 64 signals - S8177899: Tests fail due to code cache exhaustion on machines with many cores - S8180901: Transformer.reset() resets the state only once - S8193234: When using -Xcheck:jni an internally allocated buffer can leak - S8194231: java/net/DatagramSocket/ReuseAddressTest.java failed with java.net.BindException: Address already in use: Cannot bind - S8196681: Java Access Bridge logging and debug flags dynamically controlled - S8198411: [TEST_BUG] Two java2d tests are unstable in mach5 - S8200365: TestOptionsWithRanges.java of '-XX:TLABWasteTargetPercent=100' fails intermittently - S8200400: Restrict Sasl mechanisms - S8202035: Archive the set of ModuleDescriptor and ModuleReference objects for observable system modules with unnamed initial module. - S8202252: (aio) Closed AsynchronousSocketChannel keeps completion handler alive - S8202952: C2: Unexpected dead nodes after matching - S8203629: Produce events in the JDK without a dependency on jdk.jfr - S8204203: Many pkcs11 tests failed in Provider initialization, after compiler on Windows changed - S8204521: compiler/jsr292/RedefineMethodUsedByMultipleMethodHandles.java fails trying to delete temp file - S8205421: AARCH64: StubCodeMark should be placed after alignment - S8205654: serviceability/dcmd/framework/HelpTest.java timed out - S8206074: nsk/jdi/EventRequestManager/createStepRequest/crstepreq001/TestDescription.java is timing out - S8206879: Currency decimal marker incorrect for Peru - S8207965: C2-only debug build fails - S8208269: Javadoc does not support module-info in a multi-release jar - S8208499: NMT: Missing memory tag for Safepoint polling page - S8208655: use JTreg skipped status in hotspot tests - S8208701: Fix for JDK-8208655 causes test failures in CI tier1 - S8208706: compiler/tiered/ConstantGettersTransitionsTest.java fails to compile - S8208780: (se) test SelectWithConsumer.testReadableAndWriteable(): failure - S8209186: Rename SimpleThresholdPolicy to TieredThresholdPolicy - S8209413: AArch64: NPE in clhsdb jstack command - S8209420: Track membars for volatile accesses so they can be properly optimized - S8209684: Intrinsics that assume some input non null should use GraphKit::must_be_not_null() - S8209939: [testbug][ppc] Test SafepointPollingPages fails after 8208499 with UseSIGTRAP on. - S8210063: ZGC: Enable load barriers for IN_NATIVE runtime barriers - S8210130: java/net/httpclient/UnknownBodyLengthTest.java failed - S8210314: [aix] NMT does not show "Safepoint" memory type - S8210389: C2: assert(n->outcnt() != 0 || C->top() == n || n->is_Proj()) failed: No dead instructions after post-alloc - S8210390: C2 still crashes with "assert(mode == ControlAroundStripMined && use == sfpt) failed: missed a node" - S8210408: Refactor java.util.ResourceBundle:i18n shell tests to plain java tests - S8210729: Clean up macosx static library handling - S8210919: Remove statically linked libjli on Windows - S8210926: vmTestbase/nsk/jvmti/scenarios/allocation/AP11/ap11t001/TestDescription.java failed with JVMTI_ERROR_INVALID_CLASS in CDS mode - S8210985: Update the default SSL session cache size to 20480 - S8211097: aix: fix build after JDK-8210919 - S8211232: GraphKit::make_runtime_call() sometimes attaches wrong memory state to call - S8211233: MemBarNode::trailing_membar() and MemBarNode::leading_membar() need to handle dying subgraphs better - S8211727: Adjust default concurrency settings for running tests on Sparc - S8212528: Wrong cgroup subsystem being used for some CPU Container Metrics - S8212970: TZ database in "vanguard" format support - S8212992: Change mirror accessor in Klass::verify_on() to use AS_NO_KEEPALIVE - S8213017: jspawnhelper: need to handle pipe write failure when sending return code - S8213117: adoptNode corrupts attribute values - S8213134: AArch64: vector shift failed with MaxVectorSize=8 - S8213172: CDS and JFR tests fail with assert(JdkJfrEvent::is(klass)) failed: invariant - S8213325: (props) Properties.loadFromXML does not fully comply with the spec - S8213406: (fs) More than one instance of built-in FileSystem observed in heap - S8213561: ZipFile/MultiThreadedReadTest.java timed out in tier1 - S8213734: SAXParser.parse(File, ..) does not close resources when Exception occurs. - S8214003: Limit default test jobs based on memory size - S8214096: sun.security.util.SignatureUtil passes null parameter, so JCE validation fails - S8214161: java.lang.IllegalAccessError: class jdk.internal.event.X509CertificateEvent (in module java.base) cannot access class jdk.jfr.internal.handlers.EventHandler (in module jdk.jfr) because module java.base does not read module jdk.jfr - S8214287: SpecJbb2005StressModule got uncaught exception - S8214579: JFrame does not paint content in XVFB / X11vnc environment - S8214687: Optimize Collections.nCopies().hashCode() and equals() - S8214702: Wrong text position for whitespaced string in printing Swing text - S8214770: java/time/test/java/time/format/TestNonIsoFormatter.java failed in non-english locales. - S8214777: Avoid some GCC 8.X strncpy() errors in HotSpot - S8214857: "bad trailing membar" assert failure at memnode.cpp:3220 - S8215044: C2 crash in loopTransform.cpp with assert(cl->trip_count() > 0) failed: peeling a fully unrolled loop - S8215130: Fix errors in LittleCMS 2.9 reported by GCC 8 - S8215265: C2: range check elimination may allow illegal out of bound access - S8215281: Use String.isEmpty() when applicable in java.base - S8215380: Backout accidental change to String::length - S8215451: JNI IsSameObject should not keep objects alive - S8215483: Off heap memory accesses should be vectorized - S8215505: Cleanup jvm.cpp obsolete code after JDK-8210094: Better loading of classloader classes - S8215534: [testbug] some jfr test don't check @requires vm.hasJFR - S8215694: keytool cannot generate RSASSA-PSS certificates - S8215756: Memory leaks in the AWT on macOS - S8215792: AArch64: String.indexOf generates incorrect result - S8215879: AArch64: ReservedStackAccess may leave stack guard in inconsistent state - S8215901: [TESTBUG] TestCheckedEnsureLocalCapacity.java fails intermittently - S8215961: jdk/jfr/event/os/TestCPUInformation.java fails on AArch64 - S8215982: (tz) Upgrade time-zone data to tzdata2018i - S8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange - S8216046: test/jdk/java/beans/PropertyEditor/Test6397609.java failing - S8216155: C4819 warning at libfreetype sources on Windows - S8216199: Local variable arg defined but never used in BCEscapeAnalyzer::compute_escape_for_intrinsic() - S8216205: Java API documentation formatting error in System.getEnv - S8216261: Javap ignores default modifier on interfaces - S8216326: SSLSocket stream close() does not close the associated socket - S8216375: Revert JDK-8145579 after JDK-8076988 is resolved - S8216401: Allow "file:" URLs in Class-Path of local JARs - S8216427: ciMethodData::load_extra_data() does not always unpack the last entry - S8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp - S8216549: Mismatched unsafe access to non escaping object fails - S8216562: UnknownBodyLength sometimes fails due to "Connection reset by peer" - S8216987: ciMethodData::load_data() unpacks MDOs with non-atomic copy - S8216989: CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does not check for zero length on AARCH64 - S8217093: Support extended-length paths in parse_manifest.c on windows - S8217344: Make comparison overflow-aware in ECDHKeyAgreement.engineGenerateSecret() - S8217359: C2 compiler triggers SIGSEGV after transformation in ConvI2LNode::Ideal - S8217364: Custom URLStreamHandler for jrt or file protocol can override default handler - S8217366: ZoneStrings are not populated for all the Locales - S8217368: AArch64: C2 recursive stack locking optimisation not triggered - S8217371: Incorrect LP64 guard in x86.ad after JDK-8210764 (Update avx512 implementation) - S8217576: C1 atomic access handlers use incorrect decorators - S8217676: Upgrade libpng to 1.6.37 - S8217760: C2: Missing symbolic info on a call from intrinsics when invoked through MethodHandle - S8217766: Container Support doesn't work for some Join Controllers combinations - S8217785: Padding ParallelTaskTerminator::_offered_termination variable - S8217896: Make better use of LCPUs when building on AIX - S8217990: C2 UseOptoBiasInlining: load of markword optimized to 0 if running with -XX:-EliminateLocks - S8218163: C2: Continuous deoptimization w/ Reason_speculate_class_check and Action_none - S8218185: aarch64: missing LoadStore barrier in TemplateTable::putfield_or_static - S8218201: Failures when vmIntrinsics::_getClass is not inlined - S8218280: LineNumberReader throws "Mark invalid" exception if CRLF straddles buffer. - S8218553: Enhance keystore load debug output - S8218558: NMT stack traces in output should show mt component for virtual memory allocations - S8218566: NMT: missing memory tag for assert poison page - S8218581: Incorrect exception message generation - S8218682: [TEST_BUG] DashOffset fails in mach5 - S8218705: Test sun/tools/jcmd/TestJcmdDefaults.java fails on Linux - S8218715: [TESTBUG] TestUseOptoBiasInliningWithoutEliminateLocks needs to unlock WhiteBoxAPI - S8218721: C1's CEE optimization produces safepoint poll with invalid debug information - S8218723: Use SunJCE Mac in SecretKeyFactory PBKDF2 implementation - S8218780: Update MUSCLE PCSC-Lite header files - S8218879: Keep track of memory accesses originated from Unsafe - S8218966: AArch64: String.compareTo() can read memory after string - S8219013: Update Apache Santuario (XML Signature) to version 2.1.3 - S8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64 - S8219244: NMT: Change ThreadSafepointState's allocation type from mtInternal to mtThread - S8219370: NMT: Move synchronization primitives from mtInternal to mtSynchronizer - S8219513: compiler/codegen/aes/TestCipherBlockChainingEncrypt.java timeout on Solaris-sparc - S8219517: assert(false) failed: infinite loop in PhaseIterGVN::optimize - S8219562: Line of code in osContainer_linux.cpp L102 appears unreachable - S8219583: Windows build failure after JDK-8214777 (Avoid some GCC 8.X strncpy() errors in HotSpot) - S8219635: aarch64: missing LoadStore barrier in TemplateTable::fast_storefield - S8219807: C2 crash in IfNode::up_one_dom(Node*, bool) - S8219914: Change the environment variable for Java Access Bridge logging to have a directory. - S8219919: RuntimeStub name lost with PrintFrameConverterAssembly - S8219993: AArch64: Compiled CI stubs are unsafely modified - S8219997: [TESTBUG] Create test for JFR events in Docker container: CPU, Memory and Process Info - S8220037: Inconsistencies of generated timezone files between Windows and Linux - S8220072: GCC 8.3 reports errors in java.base - S8220173: assert(_handle_mark_nesting > 1) failed: memory leak: allocating handle outside HandleMark - S8220227: Host Locale Provider getDisplayCountry returns error message under non-English Win10 - S8220313: [TESTBUG] Update base image for Docker testing to OL 7.6 - S8220341: Class redefinition fails with assert(!is_unloaded()) failed: unloaded method on the stack - S8220355: Improve assertion texts and exception messages in eventHandlerVMInit - S8220570: Additonal trace when native thread creation fails - S8220579: [Containers] SubSystem.java out of sync with osContainer_linux.cpp - S8220657: JFR.dump does not work when filename is set - S8220672: [TESTBUG] TestCPUSets should check that cpuset does not exceed available cores - S8220674: [TESTBUG] MetricsMemoryTester failcount test in docker container only works with debug JVMs - S8220682: Heap dumping and inspection fails with JDK-8214712 - S8220690: ATTRIBUTE_ALIGNED requires GNU extensions enabled - S8221120: CopyOnWriteArrayList.set should always have volatile write semantics - S8221220: AArch64: Add StoreStore membar explicitly for Volatile Writes in TemplateTable - S8221253: TLSv1.3 may generate TLSInnerPlainText longer than 2^14+1 bytes - S8221325: Add information about swap space to print_memory_info() on MacOS - S8221340: [TESTBUG] TestCgroupMetrics.java fails after fix for JDK-8219562 - S8221342: [TESTBUG] Generate Dockerfile for docker testing - S8221407: Windows 32bit build error in libsunmscapi/security.cpp - S8221408: Windows 32bit build build errors/warnings in hotspot - S8221411: NullPointerException in RasterPrinterJob without PrinterResolution - S8221434: Fix typo in lib-x11 autoconf error message about missing headers - S8221480: jcmd VM.metaspace shall print limits in basic mode - S8221527: [TESTBUG] DockerBasicTest.java contains hard-coded reference to JDK 10 - S8221529: [TESTBUG] Docker tests use old/deprecated image on AArch64 - S8221710: [TESTBUG] more configurable parameters for docker testing - S8221725: AArch64 build failures after JDK-8221408 (Windows 32bit build build errors/warnings in hotspot) - S8221730: jcmd process name matching broken - S8221801: Update src/java.base/share/legal/public_suffix.md - S8221892: ThreadPoolExecutor: Thread.isAlive() is not equivalent to not being startable - S8221894: Add comments for docker tests in the test doc - S8222108: Reduce minRefreshTime for updating remote printer list on Windows - S8222154: upgrade gtest to 1.8.1 - S8222280: Provide virtualization related info in the hs_error file on AIX - S8222299: [TESTBUG] move hotspot container tests to hotspot/containers - S8222362: Upgrade to Freetype 2.10.0 - S8222387: Out-of-bounds access to CPU _family_id_xxx array - S8222415: Xerces 2.12.0: Parsing Configuration - S8222670: pathological case of JIT recompilation and code cache bloat - S8222720: Provide extended VMWare/vSphere virtualization related info in the hs_error file on linux/windows x86_64 - S8222743: Xerces 2.12.0: DOM Implementation - S8222914: Partial backport of JDK-8218266 - S8222968: ByteArrayPublisher is not thread-safe resulting in broken re-use of HttpRequests - S8222980: Upgrade IANA Language Subtag Registry to Version 2019-04-03 - S8222987: sun/security/tools/keytool/PSS.java times out on Solaris-SPARC - S8222991: Xerces 2.12.0: Validation - S8223177: Data race on JvmtiEnvBase::_tag_map in double-checked locking - S8223227: Rename acquire_tag_map() to tag_map_acquire() in jvmtiEnvBase - S8223244: Fix usage of ARRAYCOPY_DISJOINT decorator - S8223336: Assert in VirtualMemoryTracker::remove_released_region when running the SharedArchiveConsistency.java test with -XX:NativeMemoryTracking=detail - S8223482: Unsupported ciphersuites may be offered by a TLS client - S8223537: testlibrary_tests/ctw/ClassesListTest.java fails with Agent timeout frequently - S8223553: Fix code constructs that do not compile with the Eclipse Java Compiler - S8223572: ~ThreadInVMForHandshake() should call handle_special_runtime_exit_condition() - S8223574: add more thread-related system settings info to hs_error file on AIX - S8223660: jtreg: Decouple Unsafe from RTM tests - S8223814: SA: jhsdb common help needs to be more detailed - S8224033: os::snprintf should be used in virtualizationSupport.cpp - S8224034: [TESTBUG] runtime/ErrorHandlerTest/ErrorHandler fails intermittently for case 13 on Windows - S8224090: [PPC64] Fix SLP patterns for filling an array with double float literals - S8224165: [TESTBUG] Docker tests produce excessive output - S8224181: On child process spawn, child may write to random file descriptor instead of the fail pipe - S8224202: Speed up Properties.load - S8224221: add memprotect calls to event log - S8224230: [PPC64, s390] Support AsyncGetCallTrace - S8224252: [TESTBUG] hotspot/test/serviceability/sa/sadebugd/SADebugDTest.java is timing out again after fix for JDK-8163805 - S8224487: outputStream should not be copyable - S8224531: SEGV while collecting Klass statistics - S8224558: Fix replicateB encoding - S8224560: (tz) Upgrade time-zone data to tzdata2019a - S8224580: Matcher can cause oop field/array element to be reloaded - S8224589: Improve startup behavior of SecurityProperties - S8224658: Unsafe access C2 compile fails with assert(flat != TypePtr::BOTTOM) failed: cannot alias-analyze an untyped ptr: adr_type = NULL - S8224698: ConcurrentSkipListMap.java does not compile with the Eclipse Java Compiler - S8224825: java/awt/Color/AlphaColorTest.java fails in linux-x64 system - S8224838: Bump update version for OpenJDK: jdk-11.0.5 - S8224991: Problemlist javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java - S8225005: Xerces 2.12.0: License file - S8225141: Better handling of classes in error state in fast class initialization checks - S8225178: [Solaris] os::signal() should call sigaction() with SA_SIGINFO - S8225189: Multiple JNI calls within critical region in ZIP Library - S8225257: sun/security/tools/keytool/PSS.java timed out - S8225347: [s390] Unexpected exit from stack overflow test - S8225386: test for JDK-8216261 fails in Windows - S8225388: Running jcmd Compiler.CodeHeap_Analytics all 0 cause crash. - S8225390: ProblemList sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java due to JDK-8161536 - S8225423: GTK L&F: JSplitPane: There is no divider shown - S8225425: java.lang.UnsatisfiedLinkError: net.dll: Can't find dependent libraries - S8225543: Jcmd fails to attach to the Java process on Linux using the main class name if whitespace options were used to launch the process - S8225580: tzdata2018i integration causes test failures on jdk-13 - S8225636: SA can't handle prelinked libraries - S8225644: C1 dumps incorrect class name in ClassCastException message - S8225663: [testbug] Missing JNIEXPORT in XAbortProvoker native function - S8225715: jhsdb jmap fails to write binary heap dump of a jshell process - S8226409: Enable argument profiling for sun.misc.Unsafe.put*/get* - S8226468: [aix] loadquery failed error message displayed - S8226530: ZipFile reads wrong entry size from ZIP64 entries - 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*) - S8226964: [Yaru] GTK L&F: There is no difference between menu selected and de-selected - S8227011: Starting a JFR recording in response to JVMTI VMInit and / or Java agent premain corrupts memory - S8227041: runtime/memory/RunUnitTestsConcurrently.java has a memory leak - S8227117: normal interpreter table is not restored after single stepping with TLH - S8227247: tools/sjavac/IdleShutdown.java fails with AssertionError: Error too big on windows - S8227277: HeapInspection::find_instances_at_safepoint walks dead objects - S8227392: Colors with alpha are painted incorrectly on Linux, after JDK-8214579 - S8227594: sadebugd/DebugdConnectTest.java fails due to "java.rmi.NotBoundException: SARemoteDebugger" - S8227630: adjust format specifiers in loadlib_aix.cpp - S8227834: build.log output from failing commands : include the hs_error file path in case of crashes in build - S8227869: fix wrong format specifiers in os_aix.cpp - S8227919: 8213232 causes crashes on solaris sparc64 - S8228337: problemList failing/ignored manual tests in security-libs - S8228400: Remove built-in AArch64 simulator - S8228469: (tz) Upgrade time-zone data to tzdata2019b - S8228485: JVM crashes when bootstrap method for condy triggers loading of class whose static initializer throws exception - S8228501: java_props_macosx.c - provide missing CFRelease for CFLocaleCopyCurrent - S8228578: fix CFData object leak in macosx KeystoreImpl.m - S8228585: jdk/internal/platform/cgroup/TestCgroupMetrics.java - NumberFormatException because of large long values (memory limit_in_bytes) - S8228596: Class redefinition fails when condy instructions are removed - S8228601: AArch64: Fix interpreter code at JVMCI deoptimization entry - S8228618: s390: c1/c2 fail to add a metadata relocation in the static call stub. - S8228649: [PPC64] SA reads wrong slots from interpreter frames - S8228658: test GetTotalSafepointTime.java fails on fast Linux machines with Total safepoint time 0 ms - S8228711: Path rendered incorrectly when it goes outside the clipping region - S8228725: AArch64: Purge method call format support - S8228764: New library dependencies due to JDK-8222720 - S8229118: [TESTBUG] serviceability/sa/ClhsdbFindPC fails on AArch64 - S8229352: Use of an uninitialized register in 32-bit ARM template interpreter - S8229406: ZGC: Fix incorrect statistics - S8229767: Typo in java.security: Sasl.createClient and Sasl.createServer - S8229773: Resolve permissions for code source URLs lazily - S8229887: (zipfs) zip file corruption when replacing an existing STORED entry - S8229925: [s390, PPC64] Exception check missing in interpreter - S8230085: (fs) FileStore::isReadOnly is always true on macOS Catalina - S8230099: Prepare for backport of JDK-8217368 More details: https://builds.shipilev.net/backports-monitor/release-notes-11.0.5.txt -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From sgehwolf at redhat.com Wed Oct 16 14:06:17 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 16 Oct 2019 16:06:17 +0200 Subject: OpenJDK 11.0.5 Released In-Reply-To: <3d7e7639-8d62-8c93-652a-34383d32ac33@redhat.com> References: <3d7e7639-8d62-8c93-652a-34383d32ac33@redhat.com> Message-ID: On Wed, 2019-10-16 at 14:10 +0100, Andrew John Hughes wrote: > We are pleased to announce the release of OpenJDK 11.0.5. > > The source tarball is available from: > > * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.5-ga.tar.xz > > The tarball is accompanied by a digital signature available at: > > * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.5-ga.tar.xz.sig OpenJDK Project Builds to to with it are available here (11.0.5+10): https://adoptopenjdk.net/upstream.html Thanks, Severin > 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: > > 8115a984eec702b60715c7e9af895706b649b4b574ca213162a0cc8e978120dc > openjdk-11.0.5-ga.tar.xz > 72e68616df0acc120142ce07dea32798944ddf59c7c9e0e0c61c0f74cc18feb8 > openjdk-11.0.5-ga.tar.xz.sig > > The checksums can be downloaded from: > > * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.5-ga.sha256 > > What's New? > =========== > * Security fixes > - S8209901: Canonical file handling > - 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 > - S8223886: Add in font table referene > - S8223892, CVE-2019-2978: Improved handling of jar files > - S8224025: Fix for JDK-8220302 is not complete > - S8224062, CVE-2019-2977: Improve String index handling > - 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 > - S8227601: Better collection of references > - S8228825, CVE-2019-2894: Enhance ECDSA operations > * Other changes > - S6996807: FieldReflectorKey hash code computation can be improved > - S8076988: reevaluate trivial method policy > - S8087128: C2: Disallow definition split on MachCopySpill nodes > - S8133489: Better messaging for PKIX path validation matching > - S8139965: Hang seen when using com.sun.jndi.ldap.search.replyQueueSize > - S8147502: Digest is incorrectly truncated for ECDSA signatures when > the bit length of n is less than the field size > - S8148188: Enhance the security libraries to record events of interest > - S8163363: AArch64: Stack size in tools/launcher/Settings.java needs > to be adjusted > - S8163511: Allocation of compile task fails with assert: "Leaking > compilation tasks?" > - S8170639: [Linux] jsig is limited to a maximum of 64 signals > - S8177899: Tests fail due to code cache exhaustion on machines with > many cores > - S8180901: Transformer.reset() resets the state only once > - S8193234: When using -Xcheck:jni an internally allocated buffer can leak > - S8194231: java/net/DatagramSocket/ReuseAddressTest.java failed with > java.net.BindException: Address already in use: Cannot bind > - S8196681: Java Access Bridge logging and debug flags dynamically > controlled > - S8198411: [TEST_BUG] Two java2d tests are unstable in mach5 > - S8200365: TestOptionsWithRanges.java of > '-XX:TLABWasteTargetPercent=100' fails intermittently > - S8200400: Restrict Sasl mechanisms > - S8202035: Archive the set of ModuleDescriptor and ModuleReference > objects for observable system modules with unnamed initial module. > - S8202252: (aio) Closed AsynchronousSocketChannel keeps completion > handler alive > - S8202952: C2: Unexpected dead nodes after matching > - S8203629: Produce events in the JDK without a dependency on jdk.jfr > - S8204203: Many pkcs11 tests failed in Provider initialization, after > compiler on Windows changed > - S8204521: > compiler/jsr292/RedefineMethodUsedByMultipleMethodHandles.java fails > trying to delete temp file > - S8205421: AARCH64: StubCodeMark should be placed after alignment > - S8205654: serviceability/dcmd/framework/HelpTest.java timed out > - S8206074: > nsk/jdi/EventRequestManager/createStepRequest/crstepreq001/TestDescription.java > is timing out > - S8206879: Currency decimal marker incorrect for Peru > - S8207965: C2-only debug build fails > - S8208269: Javadoc does not support module-info in a multi-release jar > - S8208499: NMT: Missing memory tag for Safepoint polling page > - S8208655: use JTreg skipped status in hotspot tests > - S8208701: Fix for JDK-8208655 causes test failures in CI tier1 > - S8208706: compiler/tiered/ConstantGettersTransitionsTest.java fails > to compile > - S8208780: (se) test SelectWithConsumer.testReadableAndWriteable(): > failure > - S8209186: Rename SimpleThresholdPolicy to TieredThresholdPolicy > - S8209413: AArch64: NPE in clhsdb jstack command > - S8209420: Track membars for volatile accesses so they can be > properly optimized > - S8209684: Intrinsics that assume some input non null should use > GraphKit::must_be_not_null() > - S8209939: [testbug][ppc] Test SafepointPollingPages fails after > 8208499 with UseSIGTRAP on. > - S8210063: ZGC: Enable load barriers for IN_NATIVE runtime barriers > - S8210130: java/net/httpclient/UnknownBodyLengthTest.java failed > - S8210314: [aix] NMT does not show "Safepoint" memory type > - S8210389: C2: assert(n->outcnt() != 0 || C->top() == n || > n->is_Proj()) failed: No dead instructions after post-alloc > - S8210390: C2 still crashes with "assert(mode == > ControlAroundStripMined && use == sfpt) failed: missed a node" > - S8210408: Refactor java.util.ResourceBundle:i18n shell tests to > plain java tests > - S8210729: Clean up macosx static library handling > - S8210919: Remove statically linked libjli on Windows > - S8210926: > vmTestbase/nsk/jvmti/scenarios/allocation/AP11/ap11t001/TestDescription.java > failed with JVMTI_ERROR_INVALID_CLASS in CDS mode > - S8210985: Update the default SSL session cache size to 20480 > - S8211097: aix: fix build after JDK-8210919 > - S8211232: GraphKit::make_runtime_call() sometimes attaches wrong > memory state to call > - S8211233: MemBarNode::trailing_membar() and > MemBarNode::leading_membar() need to handle dying subgraphs better > - S8211727: Adjust default concurrency settings for running tests on Sparc > - S8212528: Wrong cgroup subsystem being used for some CPU Container > Metrics > - S8212970: TZ database in "vanguard" format support > - S8212992: Change mirror accessor in Klass::verify_on() to use > AS_NO_KEEPALIVE > - S8213017: jspawnhelper: need to handle pipe write failure when > sending return code > - S8213117: adoptNode corrupts attribute values > - S8213134: AArch64: vector shift failed with MaxVectorSize=8 > - S8213172: CDS and JFR tests fail with assert(JdkJfrEvent::is(klass)) > failed: invariant > - S8213325: (props) Properties.loadFromXML does not fully comply with > the spec > - S8213406: (fs) More than one instance of built-in FileSystem > observed in heap > - S8213561: ZipFile/MultiThreadedReadTest.java timed out in tier1 > - S8213734: SAXParser.parse(File, ..) does not close resources when > Exception occurs. > - S8214003: Limit default test jobs based on memory size > - S8214096: sun.security.util.SignatureUtil passes null parameter, so > JCE validation fails > - S8214161: java.lang.IllegalAccessError: class > jdk.internal.event.X509CertificateEvent (in module java.base) cannot > access class jdk.jfr.internal.handlers.EventHandler (in module jdk.jfr) > because module java.base does not read module jdk.jfr > - S8214287: SpecJbb2005StressModule got uncaught exception > - S8214579: JFrame does not paint content in XVFB / X11vnc environment > - S8214687: Optimize Collections.nCopies().hashCode() and equals() > - S8214702: Wrong text position for whitespaced string in printing > Swing text > - S8214770: java/time/test/java/time/format/TestNonIsoFormatter.java > failed in non-english locales. > - S8214777: Avoid some GCC 8.X strncpy() errors in HotSpot > - S8214857: "bad trailing membar" assert failure at memnode.cpp:3220 > - S8215044: C2 crash in loopTransform.cpp with assert(cl->trip_count() > > 0) failed: peeling a fully unrolled loop > - S8215130: Fix errors in LittleCMS 2.9 reported by GCC 8 > - S8215265: C2: range check elimination may allow illegal out of bound > access > - S8215281: Use String.isEmpty() when applicable in java.base > - S8215380: Backout accidental change to String::length > - S8215451: JNI IsSameObject should not keep objects alive > - S8215483: Off heap memory accesses should be vectorized > - S8215505: Cleanup jvm.cpp obsolete code after JDK-8210094: Better > loading of classloader classes > - S8215534: [testbug] some jfr test don't check @requires vm.hasJFR > - S8215694: keytool cannot generate RSASSA-PSS certificates > - S8215756: Memory leaks in the AWT on macOS > - S8215792: AArch64: String.indexOf generates incorrect result > - S8215879: AArch64: ReservedStackAccess may leave stack guard in > inconsistent state > - S8215901: [TESTBUG] TestCheckedEnsureLocalCapacity.java fails > intermittently > - S8215961: jdk/jfr/event/os/TestCPUInformation.java fails on AArch64 > - S8215982: (tz) Upgrade time-zone data to tzdata2018i > - S8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange > - S8216046: test/jdk/java/beans/PropertyEditor/Test6397609.java failing > - S8216155: C4819 warning at libfreetype sources on Windows > - S8216199: Local variable arg defined but never used in > BCEscapeAnalyzer::compute_escape_for_intrinsic() > - S8216205: Java API documentation formatting error in System.getEnv > - S8216261: Javap ignores default modifier on interfaces > - S8216326: SSLSocket stream close() does not close the associated socket > - S8216375: Revert JDK-8145579 after JDK-8076988 is resolved > - S8216401: Allow "file:" URLs in Class-Path of local JARs > - S8216427: ciMethodData::load_extra_data() does not always unpack the > last entry > - S8216528: > test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java > failing with Xcomp > - S8216549: Mismatched unsafe access to non escaping object fails > - S8216562: UnknownBodyLength sometimes fails due to "Connection reset > by peer" > - S8216987: ciMethodData::load_data() unpacks MDOs with non-atomic copy > - S8216989: > CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does > not check for zero length on AARCH64 > - S8217093: Support extended-length paths in parse_manifest.c on windows > - S8217344: Make comparison overflow-aware in > ECDHKeyAgreement.engineGenerateSecret() > - S8217359: C2 compiler triggers SIGSEGV after transformation in > ConvI2LNode::Ideal > - S8217364: Custom URLStreamHandler for jrt or file protocol can > override default handler > - S8217366: ZoneStrings are not populated for all the Locales > - S8217368: AArch64: C2 recursive stack locking optimisation not triggered > - S8217371: Incorrect LP64 guard in x86.ad after JDK-8210764 (Update > avx512 implementation) > - S8217576: C1 atomic access handlers use incorrect decorators > - S8217676: Upgrade libpng to 1.6.37 > - S8217760: C2: Missing symbolic info on a call from intrinsics when > invoked through MethodHandle > - S8217766: Container Support doesn't work for some Join Controllers > combinations > - S8217785: Padding ParallelTaskTerminator::_offered_termination variable > - S8217896: Make better use of LCPUs when building on AIX > - S8217990: C2 UseOptoBiasInlining: load of markword optimized to 0 if > running with -XX:-EliminateLocks > - S8218163: C2: Continuous deoptimization w/ > Reason_speculate_class_check and Action_none > - S8218185: aarch64: missing LoadStore barrier in > TemplateTable::putfield_or_static > - S8218201: Failures when vmIntrinsics::_getClass is not inlined > - S8218280: LineNumberReader throws "Mark invalid" exception if CRLF > straddles buffer. > - S8218553: Enhance keystore load debug output > - S8218558: NMT stack traces in output should show mt component for > virtual memory allocations > - S8218566: NMT: missing memory tag for assert poison page > - S8218581: Incorrect exception message generation > - S8218682: [TEST_BUG] DashOffset fails in mach5 > - S8218705: Test sun/tools/jcmd/TestJcmdDefaults.java fails on Linux > - S8218715: [TESTBUG] TestUseOptoBiasInliningWithoutEliminateLocks > needs to unlock WhiteBoxAPI > - S8218721: C1's CEE optimization produces safepoint poll with invalid > debug information > - S8218723: Use SunJCE Mac in SecretKeyFactory PBKDF2 implementation > - S8218780: Update MUSCLE PCSC-Lite header files > - S8218879: Keep track of memory accesses originated from Unsafe > - S8218966: AArch64: String.compareTo() can read memory after string > - S8219013: Update Apache Santuario (XML Signature) to version 2.1.3 > - S8219241: Provide basic virtualization related info in the hs_error > file on linux/windows x86_64 > - S8219244: NMT: Change ThreadSafepointState's allocation type from > mtInternal to mtThread > - S8219370: NMT: Move synchronization primitives from mtInternal to > mtSynchronizer > - S8219513: compiler/codegen/aes/TestCipherBlockChainingEncrypt.java > timeout on Solaris-sparc > - S8219517: assert(false) failed: infinite loop in PhaseIterGVN::optimize > - S8219562: Line of code in osContainer_linux.cpp L102 appears unreachable > - S8219583: Windows build failure after JDK-8214777 (Avoid some GCC > 8.X strncpy() errors in HotSpot) > - S8219635: aarch64: missing LoadStore barrier in > TemplateTable::fast_storefield > - S8219807: C2 crash in IfNode::up_one_dom(Node*, bool) > - S8219914: Change the environment variable for Java Access Bridge > logging to have a directory. > - S8219919: RuntimeStub name lost with PrintFrameConverterAssembly > - S8219993: AArch64: Compiled CI stubs are unsafely modified > - S8219997: [TESTBUG] Create test for JFR events in Docker container: > CPU, Memory and Process Info > - S8220037: Inconsistencies of generated timezone files between > Windows and Linux > - S8220072: GCC 8.3 reports errors in java.base > - S8220173: assert(_handle_mark_nesting > 1) failed: memory leak: > allocating handle outside HandleMark > - S8220227: Host Locale Provider getDisplayCountry returns error > message under non-English Win10 > - S8220313: [TESTBUG] Update base image for Docker testing to OL 7.6 > - S8220341: Class redefinition fails with assert(!is_unloaded()) > failed: unloaded method on the stack > - S8220355: Improve assertion texts and exception messages in > eventHandlerVMInit > - S8220570: Additonal trace when native thread creation fails > - S8220579: [Containers] SubSystem.java out of sync with > osContainer_linux.cpp > - S8220657: JFR.dump does not work when filename is set > - S8220672: [TESTBUG] TestCPUSets should check that cpuset does not > exceed available cores > - S8220674: [TESTBUG] MetricsMemoryTester failcount test in docker > container only works with debug JVMs > - S8220682: Heap dumping and inspection fails with JDK-8214712 > - S8220690: ATTRIBUTE_ALIGNED requires GNU extensions enabled > - S8221120: CopyOnWriteArrayList.set should always have volatile write > semantics > - S8221220: AArch64: Add StoreStore membar explicitly for Volatile > Writes in TemplateTable > - S8221253: TLSv1.3 may generate TLSInnerPlainText longer than 2^14+1 > bytes > - S8221325: Add information about swap space to print_memory_info() on > MacOS > - S8221340: [TESTBUG] TestCgroupMetrics.java fails after fix for > JDK-8219562 > - S8221342: [TESTBUG] Generate Dockerfile for docker testing > - S8221407: Windows 32bit build error in libsunmscapi/security.cpp > - S8221408: Windows 32bit build build errors/warnings in hotspot > - S8221411: NullPointerException in RasterPrinterJob without > PrinterResolution > - S8221434: Fix typo in lib-x11 autoconf error message about missing > headers > - S8221480: jcmd VM.metaspace shall print limits in basic mode > - S8221527: [TESTBUG] DockerBasicTest.java contains hard-coded > reference to JDK 10 > - S8221529: [TESTBUG] Docker tests use old/deprecated image on AArch64 > - S8221710: [TESTBUG] more configurable parameters for docker testing > - S8221725: AArch64 build failures after JDK-8221408 (Windows 32bit > build build errors/warnings in hotspot) > - S8221730: jcmd process name matching broken > - S8221801: Update src/java.base/share/legal/public_suffix.md > - S8221892: ThreadPoolExecutor: Thread.isAlive() is not equivalent to > not being startable > - S8221894: Add comments for docker tests in the test doc > - S8222108: Reduce minRefreshTime for updating remote printer list on > Windows > - S8222154: upgrade gtest to 1.8.1 > - S8222280: Provide virtualization related info in the hs_error file > on AIX > - S8222299: [TESTBUG] move hotspot container tests to hotspot/containers > - S8222362: Upgrade to Freetype 2.10.0 > - S8222387: Out-of-bounds access to CPU _family_id_xxx array > - S8222415: Xerces 2.12.0: Parsing Configuration > - S8222670: pathological case of JIT recompilation and code cache bloat > - S8222720: Provide extended VMWare/vSphere virtualization related > info in the hs_error file on linux/windows x86_64 > - S8222743: Xerces 2.12.0: DOM Implementation > - S8222914: Partial backport of JDK-8218266 > - S8222968: ByteArrayPublisher is not thread-safe resulting in broken > re-use of HttpRequests > - S8222980: Upgrade IANA Language Subtag Registry to Version 2019-04-03 > - S8222987: sun/security/tools/keytool/PSS.java times out on Solaris-SPARC > - S8222991: Xerces 2.12.0: Validation > - S8223177: Data race on JvmtiEnvBase::_tag_map in double-checked locking > - S8223227: Rename acquire_tag_map() to tag_map_acquire() in jvmtiEnvBase > - S8223244: Fix usage of ARRAYCOPY_DISJOINT decorator > - S8223336: Assert in VirtualMemoryTracker::remove_released_region > when running the SharedArchiveConsistency.java test with > -XX:NativeMemoryTracking=detail > - S8223482: Unsupported ciphersuites may be offered by a TLS client > - S8223537: testlibrary_tests/ctw/ClassesListTest.java fails with > Agent timeout frequently > - S8223553: Fix code constructs that do not compile with the Eclipse > Java Compiler > - S8223572: ~ThreadInVMForHandshake() should call > handle_special_runtime_exit_condition() > - S8223574: add more thread-related system settings info to hs_error > file on AIX > - S8223660: jtreg: Decouple Unsafe from RTM tests > - S8223814: SA: jhsdb common help needs to be more detailed > - S8224033: os::snprintf should be used in virtualizationSupport.cpp > - S8224034: [TESTBUG] runtime/ErrorHandlerTest/ErrorHandler fails > intermittently for case 13 on Windows > - S8224090: [PPC64] Fix SLP patterns for filling an array with double > float literals > - S8224165: [TESTBUG] Docker tests produce excessive output > - S8224181: On child process spawn, child may write to random file > descriptor instead of the fail pipe > - S8224202: Speed up Properties.load > - S8224221: add memprotect calls to event log > - S8224230: [PPC64, s390] Support AsyncGetCallTrace > - S8224252: [TESTBUG] > hotspot/test/serviceability/sa/sadebugd/SADebugDTest.java is timing out > again after fix for JDK-8163805 > - S8224487: outputStream should not be copyable > - S8224531: SEGV while collecting Klass statistics > - S8224558: Fix replicateB encoding > - S8224560: (tz) Upgrade time-zone data to tzdata2019a > - S8224580: Matcher can cause oop field/array element to be reloaded > - S8224589: Improve startup behavior of SecurityProperties > - S8224658: Unsafe access C2 compile fails with assert(flat != > TypePtr::BOTTOM) failed: cannot alias-analyze an untyped ptr: adr_type = > NULL > - S8224698: ConcurrentSkipListMap.java does not compile with the > Eclipse Java Compiler > - S8224825: java/awt/Color/AlphaColorTest.java fails in linux-x64 system > - S8224838: Bump update version for OpenJDK: jdk-11.0.5 > - S8224991: Problemlist > javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java > - S8225005: Xerces 2.12.0: License file > - S8225141: Better handling of classes in error state in fast class > initialization checks > - S8225178: [Solaris] os::signal() should call sigaction() with SA_SIGINFO > - S8225189: Multiple JNI calls within critical region in ZIP Library > - S8225257: sun/security/tools/keytool/PSS.java timed out > - S8225347: [s390] Unexpected exit from stack overflow test > - S8225386: test for JDK-8216261 fails in Windows > - S8225388: Running jcmd Compiler.CodeHeap_Analytics all 0 cause crash. > - S8225390: ProblemList > sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java due to JDK-8161536 > - S8225423: GTK L&F: JSplitPane: There is no divider shown > - S8225425: java.lang.UnsatisfiedLinkError: net.dll: Can't find > dependent libraries > - S8225543: Jcmd fails to attach to the Java process on Linux using > the main class name if whitespace options were used to launch the process > - S8225580: tzdata2018i integration causes test failures on jdk-13 > - S8225636: SA can't handle prelinked libraries > - S8225644: C1 dumps incorrect class name in ClassCastException message > - S8225663: [testbug] Missing JNIEXPORT in XAbortProvoker native function > - S8225715: jhsdb jmap fails to write binary heap dump of a jshell process > - S8226409: Enable argument profiling for sun.misc.Unsafe.put*/get* > - S8226468: [aix] loadquery failed error message displayed > - S8226530: ZipFile reads wrong entry size from ZIP64 entries > - 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*) > - S8226964: [Yaru] GTK L&F: There is no difference between menu > selected and de-selected > - S8227011: Starting a JFR recording in response to JVMTI VMInit and / > or Java agent premain corrupts memory > - S8227041: runtime/memory/RunUnitTestsConcurrently.java has a memory leak > - S8227117: normal interpreter table is not restored after single > stepping with TLH > - S8227247: tools/sjavac/IdleShutdown.java fails with AssertionError: > Error too big on windows > - S8227277: HeapInspection::find_instances_at_safepoint walks dead objects > - S8227392: Colors with alpha are painted incorrectly on Linux, after > JDK-8214579 > - S8227594: sadebugd/DebugdConnectTest.java fails due to > "java.rmi.NotBoundException: SARemoteDebugger" > - S8227630: adjust format specifiers in loadlib_aix.cpp > - S8227834: build.log output from failing commands : include the > hs_error file path in case of crashes in build > - S8227869: fix wrong format specifiers in os_aix.cpp > - S8227919: 8213232 causes crashes on solaris sparc64 > - S8228337: problemList failing/ignored manual tests in security-libs > - S8228400: Remove built-in AArch64 simulator > - S8228469: (tz) Upgrade time-zone data to tzdata2019b > - S8228485: JVM crashes when bootstrap method for condy triggers > loading of class whose static initializer throws exception > - S8228501: java_props_macosx.c - provide missing CFRelease for > CFLocaleCopyCurrent > - S8228578: fix CFData object leak in macosx KeystoreImpl.m > - S8228585: jdk/internal/platform/cgroup/TestCgroupMetrics.java - > NumberFormatException because of large long values (memory limit_in_bytes) > - S8228596: Class redefinition fails when condy instructions are removed > - S8228601: AArch64: Fix interpreter code at JVMCI deoptimization entry > - S8228618: s390: c1/c2 fail to add a metadata relocation in the > static call stub. > - S8228649: [PPC64] SA reads wrong slots from interpreter frames > - S8228658: test GetTotalSafepointTime.java fails on fast Linux > machines with Total safepoint time 0 ms > - S8228711: Path rendered incorrectly when it goes outside the > clipping region > - S8228725: AArch64: Purge method call format support > - S8228764: New library dependencies due to JDK-8222720 > - S8229118: [TESTBUG] serviceability/sa/ClhsdbFindPC fails on AArch64 > - S8229352: Use of an uninitialized register in 32-bit ARM template > interpreter > - S8229406: ZGC: Fix incorrect statistics > - S8229767: Typo in java.security: Sasl.createClient and Sasl.createServer > - S8229773: Resolve permissions for code source URLs lazily > - S8229887: (zipfs) zip file corruption when replacing an existing > STORED entry > - S8229925: [s390, PPC64] Exception check missing in interpreter > - S8230085: (fs) FileStore::isReadOnly is always true on macOS Catalina > - S8230099: Prepare for backport of JDK-8217368 > > More details: > https://builds.shipilev.net/backports-monitor/release-notes-11.0.5.txt From martin.doerr at sap.com Wed Oct 16 14:46:56 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 16 Oct 2019 14:46:56 +0000 Subject: [11u] RFR 8190737:use unicode version of the canonicalize() function to handle long path on windows In-Reply-To: References: Message-ID: Hi Ralf, looks good. Thanks for backporting. Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Schmelter, Ralf > Sent: Mittwoch, 16. Oktober 2019 12:35 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR 8190737:use unicode version of the > canonicalize() function to handle long path on windows > > Hello, > > please review this fix. The patch itself applied cleanly, but the LongBCP.java > test needed an additional import statement. > > Original bugreport: https://bugs.openjdk.java.net/browse/JDK-8190737 > Original change: http://hg.openjdk.java.net/jdk/jdk/rev/9151fde080e6 > > Webrev of downport: > http://cr.openjdk.java.net/~rschmelter/webrevs/8190737/webrev.jdk11u- > dev.1/index.html > > Best regards, > Ralf From calvin.cheung at oracle.com Wed Oct 16 17:34:29 2019 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 16 Oct 2019 10:34:29 -0700 Subject: [11u] RFR 8190737:use unicode version of the canonicalize() function to handle long path on windows In-Reply-To: References: Message-ID: <27e27e33-626c-bed5-2bbb-ffb53901b3bd@oracle.com> Hi Ralf, The backport looks good. thanks, Calvin On 10/16/19 3:35 AM, Schmelter, Ralf wrote: > Hello, > > please review this fix. The patch itself applied cleanly, but the LongBCP.java test needed an additional import statement. > > Original bugreport: https://bugs.openjdk.java.net/browse/JDK-8190737 > Original change: http://hg.openjdk.java.net/jdk/jdk/rev/9151fde080e6 > > Webrev of downport: http://cr.openjdk.java.net/~rschmelter/webrevs/8190737/webrev.jdk11u-dev.1/index.html > > Best regards, > Ralf From rob.mckenna at oracle.com Wed Oct 16 21:21:14 2019 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 16 Oct 2019 22:21:14 +0100 Subject: [Updates Communication] 13.0.1 security patches pushed Message-ID: <20191016185707.GA7038@vimes> Apologies, there was a delay due to an unforseen infrastructure bottleneck. 13.0.1 patches have been pushed to: http://hg.openjdk.java.net/jdk-updates/jdk13u/ -Rob From christoph.langer at sap.com Mon Oct 21 07:15:25 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 21 Oct 2019 07:15:25 +0000 Subject: [11] RFR 8232051: Epsilon should warn about Xms/Xmx/AlwaysPreTouch configuration In-Reply-To: <0890f008-b606-e898-cc4b-8cc6d92ea1ec@redhat.com> References: <0890f008-b606-e898-cc4b-8cc6d92ea1ec@redhat.com> Message-ID: Hi Aleksey, looks good to me ?? Cheers Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Aleksey Shipilev > Sent: Dienstag, 15. Oktober 2019 20:41 > To: jdk-updates-dev at openjdk.java.net > Subject: [11] RFR 8232051: Epsilon should warn about > Xms/Xmx/AlwaysPreTouch configuration > > Original RFE: > https://bugs.openjdk.java.net/browse/JDK-8232051 > https://hg.openjdk.java.net/jdk/jdk/rev/10db6989907f > > Patch does not apply to 11u cleanly, because global package declaration in > tests (JDK-8214799) is > not done in 11u. Only test is affected. 11u webrev: > https://cr.openjdk.java.net/~shade/8232051/webrev.11u.01/ > > Testing: gc/epsilon {fastdebug,release}, adhoc tests > > -- > Thanks, > -Aleksey From mbalao at redhat.com Mon Oct 21 20:56:16 2019 From: mbalao at redhat.com (Martin Balao) Date: Mon, 21 Oct 2019 17:56:16 -0300 Subject: [11u] RFR 8215032: Support Kerberos cross-realm referrals (RFC 6806) In-Reply-To: References: <57d1dd6b-3395-cb87-de91-690893332468@redhat.com> Message-ID: <8285a00c-9e6e-6b63-eb9d-660dd09d9266@redhat.com> Hi Christoph, Can you please have a look at the CSR [1] so we move it from Provisional to Finalized? Now that 8224589 is in 11u, patch applies cleanly net copyright. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8230496 From denghui.ddh at alibaba-inc.com Tue Oct 22 02:09:26 2019 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Tue, 22 Oct 2019 10:09:26 +0800 Subject: =?UTF-8?B?UmU6IFsxMXVdIFJGUiA4MTg1NTI1OiBBZGQgSkZSIGV2ZW50IGZvciBEaWN0aW9uYXJ5U2l6?= =?UTF-8?B?ZXM=?= In-Reply-To: References: <26f8d18c-17d7-45a1-adeb-f4cef393f61f.denghui.ddh@alibaba-inc.com>, Message-ID: <5b77b5a5-2ec4-4b16-99c2-774b0ec0a100.denghui.ddh@alibaba-inc.com> Hi Christoph, What's the status of this backport ? By the way, the previous webrev didn't contain the original commit, so I uploaded a new one in http://cr.openjdk.java.net/~ddong/8185525/webrev/ Thanks, Denghui Dong ------------------------------------------------------------------ From:Langer, Christoph Send Time:2019?10?8?(???) 22:34 To:???(??) ; jdk-updates-dev Subject:RE: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi Denghui, this is quite a large JFR enhancement. Looking at the 11u webrev, I didn't see any obvious issues although there are obviously quite some alterations from the original patch. I'll run it through our regression testing. However, in any case, we need to carefully decide if and when we allow this patch to jdk11u-dev. I'll get back to you soon. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Denghui Dong > Sent: Donnerstag, 26. September 2019 17:03 > To: jdk-updates-dev > Subject: [11u] RFR 8185525: Add JFR event for DictionarySizes > > Hi all, > Please review this backport, original patch doesn't apply cleanly, because > SymbolTable has made some changes in upstream (I think it's not necessary > to backport those changes) > and class ClassLoaderDataGraph is located in different files. > 11u-webrev: > http://cr.openjdk.java.net/~wzhuo/8185525/webrev.00/ > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8185525 > http://hg.openjdk.java.net/jdk/jdk/rev/865ec913f916 > Testing: test/jdk/jdk/jfr/event/runtime/TestTableStatisticsEvent.java > > Thanks, > Denghui Dong From shade at redhat.com Tue Oct 22 09:57:21 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 22 Oct 2019 11:57:21 +0200 Subject: [11] RFR 8232051: Epsilon should warn about Xms/Xmx/AlwaysPreTouch configuration In-Reply-To: References: <0890f008-b606-e898-cc4b-8cc6d92ea1ec@redhat.com> Message-ID: <3b3f103b-78ea-49f3-256e-e47e653f773b@redhat.com> On 10/21/19 9:15 AM, Langer, Christoph wrote: > looks good to me ?? Thanks! -- Thanks, -Aleksey From ralf.schmelter at sap.com Tue Oct 22 11:50:50 2019 From: ralf.schmelter at sap.com (Schmelter, Ralf) Date: Tue, 22 Oct 2019 11:50:50 +0000 Subject: [11u] RFR 8191521: handle long relative path specified in -Xbootclasspath/a on windows Message-ID: I'd like to backport the change to 11u-dev: bugreport: https://bugs.openjdk.java.net/browse/JDK-8191521 change: https://hg.openjdk.java.net/jdk/jdk/rev/ed5e399d967d webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8191521/webrev.jdk11u-dev.01/ The patch had to be modified since it also adjusted the os:: same_files() method, which is not present in JDK11. Otherwise it applied cleanly. This change includes the following fixes too: bugreport fix 1: https://bugs.openjdk.java.net/browse/JDK-8231930 change fix 1: https://hg.openjdk.java.net/jdk/jdk/rev/74094a60d018 bugreport fix 2: https://bugs.openjdk.java.net/browse/JDK-8231885 change fix 2: https://hg.openjdk.java.net/jdk/jdk/rev/b1da055915ef Best regards, Ralf From shade at redhat.com Wed Oct 23 10:44:19 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 23 Oct 2019 12:44:19 +0200 Subject: Pick up 11.0.6 (-ea) to jdk-updates/jdk11u? Message-ID: Hi, Is there a plan to pick up some stable snapshot of jdk-updates/jdk11u-dev to to jdk-updates/jdk11u? That would signal the downstream builders it is time to start testing 11.0.6 EA :) -- Thanks, -Aleksey From goetz.lindenmaier at sap.com Wed Oct 23 10:57:12 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 23 Oct 2019 10:57:12 +0000 Subject: Pick up 11.0.6 (-ea) to jdk-updates/jdk11u? In-Reply-To: References: Message-ID: Hi, As before, I wanted to start with this two weeks after the release of 11.0.5, which is October 28th. Then I'll apply tag 11.0.6+1 to jdk11u-dev, and pull the tag to jdk11u. Maybe we should list this on the jdk11u page again? https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u At some point, it was decided not to list this date any more. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Aleksey Shipilev > Sent: Wednesday, October 23, 2019 12:44 PM > To: jdk-updates-dev at openjdk.java.net > Subject: Pick up 11.0.6 (-ea) to jdk-updates/jdk11u? > > Hi, > > Is there a plan to pick up some stable snapshot of jdk-updates/jdk11u-dev to > to jdk-updates/jdk11u? > That would signal the downstream builders it is time to start testing 11.0.6 > EA :) > > -- > Thanks, > -Aleksey From shade at redhat.com Wed Oct 23 10:59:39 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 23 Oct 2019 12:59:39 +0200 Subject: Pick up 11.0.6 (-ea) to jdk-updates/jdk11u? In-Reply-To: References: Message-ID: <9a988cd4-0bba-2dff-abde-666f4c086bb2@redhat.com> On 10/23/19 12:57 PM, Lindenmaier, Goetz wrote: > As before, I wanted to start with this two weeks after > the release of 11.0.5, which is October 28th. Then I'll > apply tag 11.0.6+1 to jdk11u-dev, and pull the tag to > jdk11u. Ah, that would be handy; thanks. > Maybe we should list this on the jdk11u page again? > https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u > At some point, it was decided not to list this date any > more. I think it makes sense to list that date, at least provisionally. -- Thanks, -Aleksey From rkennke at redhat.com Wed Oct 23 14:29:29 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 23 Oct 2019 16:29:29 +0200 Subject: [11u] RFR: 8231085: C2/GC: Better GC-interface for expanding clone Message-ID: <582a0140-7b8e-cdd6-d0d3-d58c0964ccb0@redhat.com> I would like to backport the recent GC interface for expanding clones to jdk11u. This is a prerequisite to backport related Shenandoah changes to 11u without making a mess. The change differs from the original jdk14 change because it basically skips the intermediate GC interface for the same thing that's been introduced in jdk12. This one wholly replaces that. Bug: https://bugs.openjdk.java.net/browse/JDK-8231085 Original webrev: http://cr.openjdk.java.net/~rkennke/JDK-8231085/webrev.00/ JDK11u webrev: http://cr.openjdk.java.net/~rkennke/JDK-8231085/webrev.00.jdk11u/ Testing: tier1 and tier2 no regressions Good? Roman From jkang at redhat.com Wed Oct 23 20:15:23 2019 From: jkang at redhat.com (Jie Kang) Date: Wed, 23 Oct 2019 16:15:23 -0400 Subject: [11u] RFR: JDK-8223697 jfr tool can't format duration values greater than 1 minute Message-ID: Hi, Please review this backport for [1]. The fix did not apply cleanly due to line differences from missing backport of [2]. The additions are the same but at different lines than in jdk/jdk. This fix is quite small and useful for the jfr tool in jdk 11. The tier one and jfr tests ran successfully on my machine. Webrev: http://cr.openjdk.java.net/~jkang/JDK-8223697/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8223697 [1] https://bugs.openjdk.java.net/browse/JDK-8223697 [2] https://bugs.openjdk.java.net/browse/JDK-8215771 Regards, Jie Kang From hohensee at amazon.com Wed Oct 23 20:37:35 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 23 Oct 2019 20:37:35 +0000 Subject: [11u] RFR: 8231085: C2/GC: Better GC-interface for expanding clone In-Reply-To: <582a0140-7b8e-cdd6-d0d3-d58c0964ccb0@redhat.com> References: <582a0140-7b8e-cdd6-d0d3-d58c0964ccb0@redhat.com> Message-ID: <360A0C79-6CBF-467A-AF49-EB9F9CD003AC@amazon.com> Ok. Still a tiny skipped change. Paul ?On 10/23/19, 7:30 AM, "hotspot-compiler-dev on behalf of Roman Kennke" wrote: I would like to backport the recent GC interface for expanding clones to jdk11u. This is a prerequisite to backport related Shenandoah changes to 11u without making a mess. The change differs from the original jdk14 change because it basically skips the intermediate GC interface for the same thing that's been introduced in jdk12. This one wholly replaces that. Bug: https://bugs.openjdk.java.net/browse/JDK-8231085 Original webrev: http://cr.openjdk.java.net/~rkennke/JDK-8231085/webrev.00/ JDK11u webrev: http://cr.openjdk.java.net/~rkennke/JDK-8231085/webrev.00.jdk11u/ Testing: tier1 and tier2 no regressions Good? Roman From hohensee at amazon.com Wed Oct 23 20:48:23 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 23 Oct 2019 20:48:23 +0000 Subject: [11u] RFR: JDK-8223697 jfr tool can't format duration values greater than 1 minute In-Reply-To: References: Message-ID: <345F26CE-0EE7-42E2-B30B-D3DFB6DB5395@amazon.com> Looks good. Paul ?On 10/23/19, 1:18 PM, "jdk-updates-dev on behalf of Jie Kang" wrote: Hi, Please review this backport for [1]. The fix did not apply cleanly due to line differences from missing backport of [2]. The additions are the same but at different lines than in jdk/jdk. This fix is quite small and useful for the jfr tool in jdk 11. The tier one and jfr tests ran successfully on my machine. Webrev: http://cr.openjdk.java.net/~jkang/JDK-8223697/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8223697 [1] https://bugs.openjdk.java.net/browse/JDK-8223697 [2] https://bugs.openjdk.java.net/browse/JDK-8215771 Regards, Jie Kang From christoph.langer at sap.com Wed Oct 23 20:48:56 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 23 Oct 2019 20:48:56 +0000 Subject: [11u] RFR 8191521: handle long relative path specified in -Xbootclasspath/a on windows In-Reply-To: References: Message-ID: Hi Ralf, this backport looks good to me. I'll approve and sponsor this for you. Cheers Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Schmelter, Ralf > Sent: Dienstag, 22. Oktober 2019 13:51 > To: jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] [11u] RFR 8191521: handle long relative path specified in > -Xbootclasspath/a on windows > > I'd like to backport the change to 11u-dev: > > bugreport: https://bugs.openjdk.java.net/browse/JDK-8191521 > change: https://hg.openjdk.java.net/jdk/jdk/rev/ed5e399d967d > webrev: > http://cr.openjdk.java.net/~rschmelter/webrevs/8191521/webrev.jdk11u- > dev.01/ > > The patch had to be modified since it also adjusted the os:: same_files() > method, which is not present in JDK11. > Otherwise it applied cleanly. > > This change includes the following fixes too: > > bugreport fix 1: https://bugs.openjdk.java.net/browse/JDK-8231930 > change fix 1: https://hg.openjdk.java.net/jdk/jdk/rev/74094a60d018 > bugreport fix 2: https://bugs.openjdk.java.net/browse/JDK-8231885 > change fix 2: https://hg.openjdk.java.net/jdk/jdk/rev/b1da055915ef > > Best regards, > Ralf From sgehwolf at redhat.com Thu Oct 24 07:49:11 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 24 Oct 2019 09:49:11 +0200 Subject: [11u] RFR: JDK-8223697 jfr tool can't format duration values greater than 1 minute In-Reply-To: References: Message-ID: Hi Jie, On Wed, 2019-10-23 at 16:15 -0400, Jie Kang wrote: > Hi, > > Please review this backport for [1]. The fix did not apply cleanly due > to line differences from missing backport of [2]. The additions are > the same but at different lines than in jdk/jdk. > > This fix is quite small and useful for the jfr tool in jdk 11. The > tier one and jfr tests ran successfully on my machine. Is there a good reason NOT to backport JDK-8215771 as well? Then this patch would apply cleanly AFAUI and JDK-8215771 seems useful in itself. JDK-8215771 seems small enough. Thoughts? Thanks, Severin > Webrev: > http://cr.openjdk.java.net/~jkang/JDK-8223697/webrev.01/ > Bug: > https://bugs.openjdk.java.net/browse/JDK-8223697 > > [1] https://bugs.openjdk.java.net/browse/JDK-8223697 > [2] https://bugs.openjdk.java.net/browse/JDK-8215771 > > > Regards, > Jie Kang > From jkang at redhat.com Thu Oct 24 14:35:08 2019 From: jkang at redhat.com (Jie Kang) Date: Thu, 24 Oct 2019 10:35:08 -0400 Subject: [11u] RFR: JDK-8223697 jfr tool can't format duration values greater than 1 minute In-Reply-To: References: Message-ID: On Thu, Oct 24, 2019 at 3:49 AM Severin Gehwolf wrote: > > Hi Jie, > > On Wed, 2019-10-23 at 16:15 -0400, Jie Kang wrote: > > Hi, > > > > Please review this backport for [1]. The fix did not apply cleanly due > > to line differences from missing backport of [2]. The additions are > > the same but at different lines than in jdk/jdk. > > > > This fix is quite small and useful for the jfr tool in jdk 11. The > > tier one and jfr tests ran successfully on my machine. > > Is there a good reason NOT to backport JDK-8215771 as well? Then this > patch would apply cleanly AFAUI and JDK-8215771 seems useful in itself. > JDK-8215771 seems small enough. Thoughts? Hi Severin, I considered JDK-8215771 to be of the 'feature enhancement' type, while this (JDK-8223697) is of 'bug fix' type. This was my thinking for the backport request of this but not of JDK-8215771. However, I realize I can request a fix for JDK-8215771 to see if it is acceptable to the 11u maintainers. It will indeed make this a clean backport and bring in useful changes. I will proceed as such; thanks for bringing this up! Regards, Jie Kang > > Thanks, > Severin > > > Webrev: > > http://cr.openjdk.java.net/~jkang/JDK-8223697/webrev.01/ > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8223697 > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8223697 > > [2] https://bugs.openjdk.java.net/browse/JDK-8215771 > > > > > > Regards, > > Jie Kang > > > From hohensee at amazon.com Thu Oct 24 18:22:54 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 24 Oct 2019 18:22:54 +0000 Subject: [11u] RFR: JDK-8223697 jfr tool can't format duration values greater than 1 minute In-Reply-To: References: Message-ID: <7AA95598-0D3C-4CAB-A840-B43E1C955778@amazon.com> This is an instance of a fanout problem that will become more common as tip's code base diverges from that of 11u. Maintainers, shall we make it a policy to do predecessor backports such that we can get clean 'master' backports? Thanks, Paul ?On 10/24/19, 7:36 AM, "jdk-updates-dev on behalf of Jie Kang" wrote: On Thu, Oct 24, 2019 at 3:49 AM Severin Gehwolf wrote: > > Hi Jie, > > On Wed, 2019-10-23 at 16:15 -0400, Jie Kang wrote: > > Hi, > > > > Please review this backport for [1]. The fix did not apply cleanly due > > to line differences from missing backport of [2]. The additions are > > the same but at different lines than in jdk/jdk. > > > > This fix is quite small and useful for the jfr tool in jdk 11. The > > tier one and jfr tests ran successfully on my machine. > > Is there a good reason NOT to backport JDK-8215771 as well? Then this > patch would apply cleanly AFAUI and JDK-8215771 seems useful in itself. > JDK-8215771 seems small enough. Thoughts? Hi Severin, I considered JDK-8215771 to be of the 'feature enhancement' type, while this (JDK-8223697) is of 'bug fix' type. This was my thinking for the backport request of this but not of JDK-8215771. However, I realize I can request a fix for JDK-8215771 to see if it is acceptable to the 11u maintainers. It will indeed make this a clean backport and bring in useful changes. I will proceed as such; thanks for bringing this up! Regards, Jie Kang > > Thanks, > Severin > > > Webrev: > > http://cr.openjdk.java.net/~jkang/JDK-8223697/webrev.01/ > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8223697 > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8223697 > > [2] https://bugs.openjdk.java.net/browse/JDK-8215771 > > > > > > Regards, > > Jie Kang > > > From sgehwolf at redhat.com Fri Oct 25 08:27:15 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 25 Oct 2019 10:27:15 +0200 Subject: [11u] RFR: JDK-8223697 jfr tool can't format duration values greater than 1 minute In-Reply-To: <7AA95598-0D3C-4CAB-A840-B43E1C955778@amazon.com> References: <7AA95598-0D3C-4CAB-A840-B43E1C955778@amazon.com> Message-ID: <35bbee132daccfb509ad34829c262c0453e666e1.camel@redhat.com> On Thu, 2019-10-24 at 18:22 +0000, Hohensee, Paul wrote: > This is an instance of a fanout problem that will become more common > as tip's code base diverges from that of 11u. True. FWIW, we have that problem in JDK 8u already (diverged code base). > Maintainers, shall we make it a policy to do predecessor backports > such that we can get clean 'master' backports? I wouldn't go as far as making it policy, but rather investigate this on a case-by-case basis. Perhaps it should indeed be the first attempt to investigate what it would take for a backport to apply cleanly. However, we need to assess risk involved getting dependencies backported too. In this particular case, I believe, the risk of backporting the dep as well is acceptable since it's small enough, contained to JFR tool code, no API change and adds some value on its own. Hence, I'd opt to downport the dep (JDK-8215771) too. This would be very different if the dependency would be a massive patch, possible not even API compatible. That's my $0.02 anyway. Thanks, Severin > > ?On 10/24/19, 7:36 AM, "jdk-updates-dev on behalf of Jie Kang" wrote: > > On Thu, Oct 24, 2019 at 3:49 AM Severin Gehwolf wrote: > > > > Hi Jie, > > > > On Wed, 2019-10-23 at 16:15 -0400, Jie Kang wrote: > > > Hi, > > > > > > Please review this backport for [1]. The fix did not apply cleanly due > > > to line differences from missing backport of [2]. The additions are > > > the same but at different lines than in jdk/jdk. > > > > > > This fix is quite small and useful for the jfr tool in jdk 11. The > > > tier one and jfr tests ran successfully on my machine. > > > > Is there a good reason NOT to backport JDK-8215771 as well? Then this > > patch would apply cleanly AFAUI and JDK-8215771 seems useful in itself. > > JDK-8215771 seems small enough. Thoughts? > > Hi Severin, > > I considered JDK-8215771 to be of the 'feature enhancement' type, > while this (JDK-8223697) is of 'bug fix' type. This was my thinking > for the backport request of this but not of JDK-8215771. However, I > realize I can request a fix for JDK-8215771 to see if it is acceptable > to the 11u maintainers. It will indeed make this a clean backport and > bring in useful changes. I will proceed as such; thanks for bringing > this up! > > > Regards, > Jie Kang > > > > > Thanks, > > Severin > > > > > Webrev: > > > http://cr.openjdk.java.net/~jkang/JDK-8223697/webrev.01/ > > > Bug: > > > https://bugs.openjdk.java.net/browse/JDK-8223697 > > > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8223697 > > > [2] https://bugs.openjdk.java.net/browse/JDK-8215771 > > > > > > > > > Regards, > > > Jie Kang > > > > > > > From christoph.langer at sap.com Mon Oct 28 14:04:49 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 28 Oct 2019 14:04:49 +0000 Subject: [11u] RFR: JDK-8223697 jfr tool can't format duration values greater than 1 minute In-Reply-To: <7AA95598-0D3C-4CAB-A840-B43E1C955778@amazon.com> References: <7AA95598-0D3C-4CAB-A840-B43E1C955778@amazon.com> Message-ID: Hi Paul, > This is an instance of a fanout problem that will become more common as > tip's code base diverges from that of 11u. Maintainers, shall we make it a > policy to do predecessor backports such that we can get clean 'master' > backports? I think we had this discussion here already. I pretty much completely agree to what Severin has written. We should not make it a general policy but have a look on a case by case basis. In that case, the backport of the predecessor change probably is the best thing to do but there are cases where the situation is different. Cheers Christoph From adam.farley at uk.ibm.com Mon Oct 28 17:18:18 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Mon, 28 Oct 2019 17:18:18 +0000 Subject: RFR: JDK-8227715: GPLv2 files missing Classpath Exception Message-ID: Hi All, I'm asking for reviewers, sponsors, and opinions on the changes proposed below. Right now, there are four files in OpenJDK 8 that have a GPL V2 License, with no Classpath Exception. Based on the conversation so far, here's a summary of the proposed actions: 1) Remove this file, along with all the other JObjC files, in a new bug: - jdk/src/macosx/native/jobjc/JObjC.xcodeproj/default.pbxuser 2) Add the ClassPath Exception to the licence for this file, because later versions of OpenJDK have made this change: - jdk/make/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java 3) Add the ClassPath Exception to the licence for these files, because it seems the code is used in the final build despite the directory implying otherwise. - jdk/make/src/native/add_gnu_debuglink/add_gnu_debuglink.c - jdk/make/src/native/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c 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 hohensee at amazon.com Mon Oct 28 17:44:24 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 28 Oct 2019 17:44:24 +0000 Subject: [11u] RFR: JDK-8223697 jfr tool can't format duration values greater than 1 minute In-Reply-To: References: <7AA95598-0D3C-4CAB-A840-B43E1C955778@amazon.com> Message-ID: <038ECCE5-1DAB-4318-9EEB-9B07D66F7C05@amazon.com> Thanks for clarifying. :) Paul ?On 10/28/19, 7:05 AM, "Langer, Christoph" wrote: Hi Paul, > This is an instance of a fanout problem that will become more common as > tip's code base diverges from that of 11u. Maintainers, shall we make it a > policy to do predecessor backports such that we can get clean 'master' > backports? I think we had this discussion here already. I pretty much completely agree to what Severin has written. We should not make it a general policy but have a look on a case by case basis. In that case, the backport of the predecessor change probably is the best thing to do but there are cases where the situation is different. Cheers Christoph From sgehwolf at redhat.com Tue Oct 29 18:19:20 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 29 Oct 2019 19:19:20 +0100 Subject: [11u] RFR: 8214311: dtrace gensrc has missing dependencies Message-ID: <83a5cb7fc463fc89516d7de8e8706577afc9461f.camel@redhat.com> Hi, Please review this OpenJDK 11u backport of JDK-8214311. It's an Oracle JDK 11.0.6 feature parity patch. The jdk/jdk patch didn't apply cleanly due to context differences in make/hotspot/gensrc/GensrcDtrace.gmk. That is due to JDK-8211029 not being present in OpenJDK 11u code-base. I have fixed the patch manually, which was quite trivial. Bug: https://bugs.openjdk.java.net/browse/JDK-8214311 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214311/jdk11/01/webrev/ Original changeset: http://hg.openjdk.java.net/jdk/jdk/rev/7b757120a053 Testing: Building on Linux x86_64 with dtrace enabled. Still works. Unfortunately I don't have a Solaris machine available. Thoughts? Thanks, Severin From christoph.langer at sap.com Wed Oct 30 05:48:10 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 30 Oct 2019 05:48:10 +0000 Subject: [11u] RFR: 8214311: dtrace gensrc has missing dependencies In-Reply-To: <83a5cb7fc463fc89516d7de8e8706577afc9461f.camel@redhat.com> References: <83a5cb7fc463fc89516d7de8e8706577afc9461f.camel@redhat.com> Message-ID: Hi Severin, backport looks good. Thanks for doing it. Cheers Christoph > -----Original Message----- > From: build-dev On Behalf Of > Severin Gehwolf > Sent: Dienstag, 29. Oktober 2019 19:19 > To: jdk-updates-dev > Cc: build-dev > Subject: [11u] RFR: 8214311: dtrace gensrc has missing dependencies > > Hi, > > Please review this OpenJDK 11u backport of JDK-8214311. It's an Oracle > JDK 11.0.6 feature parity patch. The jdk/jdk patch didn't apply cleanly > due to context differences in make/hotspot/gensrc/GensrcDtrace.gmk. > That is due to JDK-8211029 not being present in OpenJDK 11u code-base. > I have fixed the patch manually, which was quite trivial. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214311 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > 8214311/jdk11/01/webrev/ > Original changeset: http://hg.openjdk.java.net/jdk/jdk/rev/7b757120a053 > > Testing: Building on Linux x86_64 with dtrace enabled. Still works. > Unfortunately I don't have a Solaris machine available. > > Thoughts? > > Thanks, > Severin From sgehwolf at redhat.com Wed Oct 30 09:08:50 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 30 Oct 2019 10:08:50 +0100 Subject: [11u] RFR: 8214311: dtrace gensrc has missing dependencies In-Reply-To: References: <83a5cb7fc463fc89516d7de8e8706577afc9461f.camel@redhat.com> Message-ID: <3a8e3d76ca105da99493a47adf8c188e685eee09.camel@redhat.com> Hi Christoph, On Wed, 2019-10-30 at 05:48 +0000, Langer, Christoph wrote: > Hi Severin, > > backport looks good. Thanks for doing it. Thanks for the review! Cheers, Severin > Cheers > Christoph > > > -----Original Message----- > > From: build-dev On Behalf Of > > Severin Gehwolf > > Sent: Dienstag, 29. Oktober 2019 19:19 > > To: jdk-updates-dev > > Cc: build-dev > > Subject: [11u] RFR: 8214311: dtrace gensrc has missing dependencies > > > > Hi, > > > > Please review this OpenJDK 11u backport of JDK-8214311. It's an > > Oracle > > JDK 11.0.6 feature parity patch. The jdk/jdk patch didn't apply > > cleanly > > due to context differences in make/hotspot/gensrc/GensrcDtrace.gmk. > > That is due to JDK-8211029 not being present in OpenJDK 11u code- > > base. > > I have fixed the patch manually, which was quite trivial. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214311 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > 8214311/jdk11/01/webrev/ > > Original changeset: > > http://hg.openjdk.java.net/jdk/jdk/rev/7b757120a053 > > > > Testing: Building on Linux x86_64 with dtrace enabled. Still works. > > Unfortunately I don't have a Solaris machine available. > > > > Thoughts? > > > > Thanks, > > Severin From christoph.langer at sap.com Wed Oct 30 11:03:48 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 30 Oct 2019 11:03:48 +0000 Subject: [11u] Discussion: Backporting features and larger fixes for JFR to JDK 11 Update releases Message-ID: Dear all, Andrew and I have been discussing what we should do regarding incoming requests to backport JFR features to JDK 11 Updates. For example, there are currently wishes to backport: JDK-8185525: Add JFR event for DictionarySizes [0] JDK-8225797: OldObjectSample event creates unexpected amount of checkpoint data [1] While the first one introduces a new (probably useful) JFR event, the second one makes the existing 'Old Object Sample ' usable at all for memory leak analysis. Bot have in common that the changes are quite extensive and need manual modifications. Especially the latter one also has quite some prerequisite changes which ought to be backported as well. So, apart from the decision about letting these very bugfixes into jdk11u, there's a general question about how to handle incoming JFR related backport requests that go beyond simple bugfixes. Shall we rather try to pull in more stuff to make the JFR tooling more usable while putting stability of JDK updates at higher risk? Or shall we be conservative here and rather reject things if in doubt? Any thoughts or comments from the community? Thanks Christoph [0] https://bugs.openjdk.java.net/browse/JDK-8185525 [1] https://bugs.openjdk.java.net/browse/JDK-8225797 From neugens at redhat.com Wed Oct 30 12:50:42 2019 From: neugens at redhat.com (Mario Torre) Date: Wed, 30 Oct 2019 13:50:42 +0100 Subject: RFR: Backport of JDK-8212071 to jdk11u-dev Message-ID: Hi all, I would like to backport the following bug to jdk11u-dev: https://bugs.openjdk.java.net/browse/JDK-8212071 Apart from the usual patch changes, the patch needed a minor tweak due to the presence of JDK-8217731 which confused the import: 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 matthias.baesken at sap.com Wed Oct 30 14:37:46 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 30 Oct 2019 14:37:46 +0000 Subject: RFR [XS] [jdk11] : 8233203: fix non-product build on AIX when compiling with xlc16/legacy-xlc Message-ID: Hello, please review the following small AIX related fix. It is a JDK11 only change , and fixes issues when building JDK11 with xlc16/legacy xlc . Currently the product build of jdk11 already works with xlc16 ; however without this change , the (fast)debug build still fails because we call into operator new ( operator_new.cpp) from Iostream_init::Iostream_init()() and this leads to a failing build . ( The described issue was not seen when using the old xlc12 for the build . ) Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8233203 http://cr.openjdk.java.net/~mbaesken/webrevs/8233203.0/ Thanks, Matthias From christoph.langer at sap.com Wed Oct 30 14:40:48 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 30 Oct 2019 14:40:48 +0000 Subject: [11u] RFR 8185525: Add JFR event for DictionarySizes In-Reply-To: <5b77b5a5-2ec4-4b16-99c2-774b0ec0a100.denghui.ddh@alibaba-inc.com> References: <26f8d18c-17d7-45a1-adeb-f4cef393f61f.denghui.ddh@alibaba-inc.com>, <5b77b5a5-2ec4-4b16-99c2-774b0ec0a100.denghui.ddh@alibaba-inc.com> Message-ID: Hi Denghui, sorry for the late reply. I was discussing with Andrew Haley about JFR backports. He encouraged to do a general discussion on the mailing list about the policy regarding non-trivial JFR related backports, which I started just today: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-October/002053.html Let?s see if there?s any feedback? Best regards Christoph From: Denghui Dong Sent: Dienstag, 22. Oktober 2019 04:09 To: jdk-updates-dev ; Langer, Christoph Subject: Re: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi Christoph, What's the status of this backport ? By the way, the previous webrev didn't contain the original commit, so I uploaded a new one in http://cr.openjdk.java.net/~ddong/8185525/webrev/ Thanks, Denghui Dong ------------------------------------------------------------------ From:Langer, Christoph > Send Time:2019?10?8?(???) 22:34 To:???(??) >; jdk-updates-dev > Subject:RE: [11u] RFR 8185525: Add JFR event for DictionarySizes Hi Denghui, this is quite a large JFR enhancement. Looking at the 11u webrev, I didn't see any obvious issues although there are obviously quite some alterations from the original patch. I'll run it through our regression testing. However, in any case, we need to carefully decide if and when we allow this patch to jdk11u-dev. I'll get back to you soon. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev > On > Behalf Of Denghui Dong > Sent: Donnerstag, 26. September 2019 17:03 > To: jdk-updates-dev > > Subject: [11u] RFR 8185525: Add JFR event for DictionarySizes > > Hi all, > Please review this backport, original patch doesn't apply cleanly, because > SymbolTable has made some changes in upstream (I think it's not necessary > to backport those changes) > and class ClassLoaderDataGraph is located in different files. > 11u-webrev: > http://cr.openjdk.java.net/~wzhuo/8185525/webrev.00/ > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8185525 > http://hg.openjdk.java.net/jdk/jdk/rev/865ec913f916 > Testing: test/jdk/jdk/jfr/event/runtime/TestTableStatisticsEvent.java > > Thanks, > Denghui Dong From martin.doerr at sap.com Wed Oct 30 14:43:25 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 30 Oct 2019 14:43:25 +0000 Subject: RFR [XS] [jdk11] : 8233203: fix non-product build on AIX when compiling with xlc16/legacy-xlc In-Reply-To: References: Message-ID: Hi Matthias, thanks for fixing xlc16 support for jdk11u. I appreciate it. Fix looks good to me. Best regards, Martin From: Baesken, Matthias Sent: Mittwoch, 30. Oktober 2019 15:38 To: jdk-updates-dev at openjdk.java.net; 'build-dev at openjdk.java.net' Cc: Langer, Christoph ; Doerr, Martin Subject: RFR [XS] [jdk11] : 8233203: fix non-product build on AIX when compiling with xlc16/legacy-xlc Hello, please review the following small AIX related fix. It is a JDK11 only change , and fixes issues when building JDK11 with xlc16/legacy xlc . Currently the product build of jdk11 already works with xlc16 ; however without this change , the (fast)debug build still fails because we call into operator new ( operator_new.cpp) from Iostream_init::Iostream_init()() and this leads to a failing build . ( The described issue was not seen when using the old xlc12 for the build . ) Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8233203 http://cr.openjdk.java.net/~mbaesken/webrevs/8233203.0/ Thanks, Matthias From christoph.langer at sap.com Wed Oct 30 14:48:38 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 30 Oct 2019 14:48:38 +0000 Subject: RFR [XS] [jdk11] : 8233203: fix non-product build on AIX when compiling with xlc16/legacy-xlc In-Reply-To: References: Message-ID: Hi Matthias, the change looks ok-ish to me. However, I?d encourage to have another look whether there are newer versions of C++ runtimes for the systems where we see this issue which would maybe fix that? But I won?t object to that patch, though. ?? Cheers Christoph From: Baesken, Matthias Sent: Mittwoch, 30. Oktober 2019 15:38 To: jdk-updates-dev at openjdk.java.net; 'build-dev at openjdk.java.net' Cc: Langer, Christoph ; Doerr, Martin Subject: RFR [XS] [jdk11] : 8233203: fix non-product build on AIX when compiling with xlc16/legacy-xlc Hello, please review the following small AIX related fix. It is a JDK11 only change , and fixes issues when building JDK11 with xlc16/legacy xlc . Currently the product build of jdk11 already works with xlc16 ; however without this change , the (fast)debug build still fails because we call into operator new ( operator_new.cpp) from Iostream_init::Iostream_init()() and this leads to a failing build . ( The described issue was not seen when using the old xlc12 for the build . ) Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8233203 http://cr.openjdk.java.net/~mbaesken/webrevs/8233203.0/ Thanks, Matthias From christoph.langer at sap.com Wed Oct 30 14:51:06 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 30 Oct 2019 14:51:06 +0000 Subject: RFR: Backport of JDK-8212071 to jdk11u-dev In-Reply-To: References: Message-ID: Hi Mario, looks good and trivial ?? Thanks Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Mario Torre > Sent: Mittwoch, 30. Oktober 2019 13:51 > To: jdk-updates-dev at openjdk.java.net > Subject: RFR: Backport of JDK-8212071 to jdk11u-dev > > Hi all, > > I would like to backport the following bug to jdk11u-dev: > > https://bugs.openjdk.java.net/browse/JDK-8212071 > > Apart from the usual patch changes, the patch needed a minor tweak due > to the presence of JDK-8217731 which confused the import: > > 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 neugens at redhat.com Wed Oct 30 15:05:40 2019 From: neugens at redhat.com (Mario Torre) Date: Wed, 30 Oct 2019 16:05:40 +0100 Subject: RFR: Backport of JDK-8212071 to jdk11u-dev In-Reply-To: References: Message-ID: Thanks! I submitted a similar request for 8u too. Thanks again, Mario On Wed, Oct 30, 2019 at 3:51 PM Langer, Christoph wrote: > > Hi Mario, > > looks good and trivial > > Thanks > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Mario Torre > > Sent: Mittwoch, 30. Oktober 2019 13:51 > > To: jdk-updates-dev at openjdk.java.net > > Subject: RFR: Backport of JDK-8212071 to jdk11u-dev > > > > Hi all, > > > > I would like to backport the following bug to jdk11u-dev: > > > > https://bugs.openjdk.java.net/browse/JDK-8212071 > > > > Apart from the usual patch changes, the patch needed a minor tweak due > > to the presence of JDK-8217731 which confused the import: > > > > 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 > -- 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 15:28:44 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 30 Oct 2019 15:28:44 +0000 Subject: [11u] RFR 8215032: Support Kerberos cross-realm referrals (RFC 6806) In-Reply-To: <8285a00c-9e6e-6b63-eb9d-660dd09d9266@redhat.com> References: <57d1dd6b-3395-cb87-de91-690893332468@redhat.com> <8285a00c-9e6e-6b63-eb9d-660dd09d9266@redhat.com> Message-ID: Hi Martin, Sorry for the late reply... been rather busy the last days. You're asking me to review the CSR for backporting JDK8215032. I, however, am not an expert in that area and could probably only check whether you copied the content correctly from the original CSR. So, I'd like to refer this to the original CSR reviewer. @Weijun Wang, can you please have a look at CSR https://bugs.openjdk.java.net/browse/JDK-8230496 and add yourself as reviewer once you find everything is ok and it's a thing feasible to backport to JDK11? Thanks Christoph > -----Original Message----- > From: Martin Balao > Sent: Montag, 21. Oktober 2019 22:56 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net > Subject: Re: [11u] RFR 8215032: Support Kerberos cross-realm referrals (RFC > 6806) > > Hi Christoph, > > Can you please have a look at the CSR [1] so we move it from Provisional > to Finalized? > > Now that 8224589 is in 11u, patch applies cleanly net copyright. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8230496 From hohensee at amazon.com Wed Oct 30 15:58:42 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 30 Oct 2019 15:58:42 +0000 Subject: [11u] Discussion: Backporting features and larger fixes for JFR to JDK 11 Update releases In-Reply-To: References: Message-ID: <6A07D13B-08F9-4D13-9355-3C02223FD20B@amazon.com> I'm generally not in favor of extensive feature backports, especially those that require manual modification and prerequisite backports. The stability risk is too high. The end game is a stream of prerequisite backports that amount to an ad-hoc global upgrade to a later release. The result will almost certainly be missing necessary patches. It should also be tested to the same degree as the later release, but we (the OpenJDK development community) don't have the QA resources/regime to do that. E.g., the reason we're ok with taking Oracle backports en masse is that we depend on Oracle's update release development and QA regime to verify their stability. Exceptions to the above are features that already exist in a fork of an update release, are supported in production, and are fairly isolated (i.e., are strict extensions and don't modify how existing code works). For 8u, examples are JFR, the aarch64 port, and Shenandoah. For 11u, an example is Shenandoah. But, once they're upstreamed and stable, upgrading them in a major way to be equivalent to later releases is imo ill-advised. Using the above paradigm, in this particular case I'd likely reject the request. Thanks, Paul ?On 10/30/19, 4:05 AM, "jdk-updates-dev on behalf of Langer, Christoph" wrote: Dear all, Andrew and I have been discussing what we should do regarding incoming requests to backport JFR features to JDK 11 Updates. For example, there are currently wishes to backport: JDK-8185525: Add JFR event for DictionarySizes [0] JDK-8225797: OldObjectSample event creates unexpected amount of checkpoint data [1] While the first one introduces a new (probably useful) JFR event, the second one makes the existing 'Old Object Sample ' usable at all for memory leak analysis. Bot have in common that the changes are quite extensive and need manual modifications. Especially the latter one also has quite some prerequisite changes which ought to be backported as well. So, apart from the decision about letting these very bugfixes into jdk11u, there's a general question about how to handle incoming JFR related backport requests that go beyond simple bugfixes. Shall we rather try to pull in more stuff to make the JFR tooling more usable while putting stability of JDK updates at higher risk? Or shall we be conservative here and rather reject things if in doubt? Any thoughts or comments from the community? Thanks Christoph [0] https://bugs.openjdk.java.net/browse/JDK-8185525 [1] https://bugs.openjdk.java.net/browse/JDK-8225797 From jaroslav.bachorik at datadoghq.com Wed Oct 30 16:57:13 2019 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Wed, 30 Oct 2019 17:57:13 +0100 Subject: [11u] Discussion: Backporting features and larger fixes for JFR to JDK 11 Update releases In-Reply-To: <6A07D13B-08F9-4D13-9355-3C02223FD20B@amazon.com> References: <6A07D13B-08F9-4D13-9355-3C02223FD20B@amazon.com> Message-ID: Hello, see my replies inline below On Wed, Oct 30, 2019 at 4:59 PM Hohensee, Paul wrote: > I'm generally not in favor of extensive feature backports, especially > those that require manual modification and prerequisite backports. The > stability risk is too high. The end game is a stream of prerequisite > backports that amount to an ad-hoc global upgrade to a later release. The > result will almost certainly be missing necessary patches. It should also > be tested to the same degree as the later release, but we (the OpenJDK > development community) don't have the QA resources/regime to do that. E.g.,. the reason we're ok with taking Oracle backports en masse is that we depend > on Oracle's update release development and QA regime to verify their > stability. > > Exceptions to the above are features that already exist in a fork of an > update release, are supported in production, and are fairly isolated (i.e., > are strict extensions and don't modify how existing code works). For 8u, > examples are JFR, the aarch64 port, and Shenandoah. For 11u, an example is > Shenandoah. But, once they're upstreamed and stable, upgrading them in a > major way to be equivalent to later releases is imo ill-advised. > > Using the above paradigm, in this particular case I'd likely reject the > request. > I agree with feature work being mostly rejected for backports. But, unfortunately, some of the more complex backports are bug fixes for features already present in JDK 11 but not working correctly. There, the motivation is only to offer a bug-free experience and not to bring new features from later releases. Of course, we can specify that only P1 and P2 bugs should be backported etc. But it would be good to know the rules beforehand such that a backporter does not spend a lot of time preparing the backport just to have it rejected on the grounds of being too complex and not critical enough. Cheers, -JB- > Thanks, > > Paul > > ?On 10/30/19, 4:05 AM, "jdk-updates-dev on behalf of Langer, Christoph" < > jdk-updates-dev-bounces at openjdk.java.net on behalf of > christoph.langer at sap.com> wrote: > > Dear all, > > Andrew and I have been discussing what we should do regarding incoming > requests to backport JFR features to JDK 11 Updates. > > For example, there are currently wishes to backport: > JDK-8185525: Add JFR event for DictionarySizes [0] > JDK-8225797: OldObjectSample event creates unexpected amount of > checkpoint data [1] > > While the first one introduces a new (probably useful) JFR event, the > second one makes the existing 'Old Object Sample ' usable at all for memory > leak analysis. > > Bot have in common that the changes are quite extensive and need > manual modifications. Especially the latter one also has quite some > prerequisite changes which ought to be backported as well. > > So, apart from the decision about letting these very bugfixes into > jdk11u, there's a general question about how to handle incoming JFR related > backport requests that go beyond simple bugfixes. Shall we rather try to > pull in more stuff to make the JFR tooling more usable while putting > stability of JDK updates at higher risk? Or shall we be conservative here > and rather reject things if in doubt? Any thoughts or comments from the > community? > > Thanks > Christoph > > [0] https://bugs.openjdk.java.net/browse/JDK-8185525 > [1] https://bugs.openjdk.java.net/browse/JDK-8225797 > > > > From bevans at newrelic.com Thu Oct 31 07:46:17 2019 From: bevans at newrelic.com (Ben Evans) Date: Thu, 31 Oct 2019 08:46:17 +0100 Subject: [11u] Discussion: Backporting features and larger fixes for JFR to JDK 11 Update releases In-Reply-To: <6A07D13B-08F9-4D13-9355-3C02223FD20B@amazon.com> References: <6A07D13B-08F9-4D13-9355-3C02223FD20B@amazon.com> Message-ID: I think that's an excellent summary, Paul. I'd like to call out what I think is a special case, though. JFR as it stands in 8 and 11 is pretty good. However it is not particularly well-suited to containerized environments. Some of the later JFR features, including the upcoming JEP 349, substantially mitigate this issue. Given that we expect 8 and 11 to be around for a long time (and the amount of 8 and 11 running in containers seems likely to only ramp up over time) this amount of future-proofing for OpenJDK users makes sense to me. They aren't super-critical features outside of their use case so we can afford to take more time and care over them and only release them when we're sure they're fully baked. At New Relic, we're already testing the JFR 8 backport and would be happy to help with other QA efforts for these types of features if it would help. I'd be in favour of taking these JFR features, but I'm also in favour of a strictly-worded policy about not accepting extensive feature backports in general. Thanks, Ben On Wed, Oct 30, 2019 at 5:00 PM Hohensee, Paul wrote: > I'm generally not in favor of extensive feature backports, especially > those that require manual modification and prerequisite backports. The > stability risk is too high. The end game is a stream of prerequisite > backports that amount to an ad-hoc global upgrade to a later release. The > result will almost certainly be missing necessary patches. It should also > be tested to the same degree as the later release, but we (the OpenJDK > development community) don't have the QA resources/regime to do that. E.g., > the reason we're ok with taking Oracle backports en masse is that we depend > on Oracle's update release development and QA regime to verify their > stability. > > Exceptions to the above are features that already exist in a fork of an > update release, are supported in production, and are fairly isolated (i.e., > are strict extensions and don't modify how existing code works). For 8u, > examples are JFR, the aarch64 port, and Shenandoah. For 11u, an example is > Shenandoah. But, once they're upstreamed and stable, upgrading them in a > major way to be equivalent to later releases is imo ill-advised. > > Using the above paradigm, in this particular case I'd likely reject the > request. > > Thanks, > > Paul > > ?On 10/30/19, 4:05 AM, "jdk-updates-dev on behalf of Langer, Christoph" < > jdk-updates-dev-bounces at openjdk.java.net on behalf of > christoph.langer at sap.com> wrote: > > Dear all, > > Andrew and I have been discussing what we should do regarding incoming > requests to backport JFR features to JDK 11 Updates. > > For example, there are currently wishes to backport: > JDK-8185525: Add JFR event for DictionarySizes [0] > JDK-8225797: OldObjectSample event creates unexpected amount of > checkpoint data [1] > > While the first one introduces a new (probably useful) JFR event, the > second one makes the existing 'Old Object Sample ' usable at all for memory > leak analysis. > > Bot have in common that the changes are quite extensive and need > manual modifications. Especially the latter one also has quite some > prerequisite changes which ought to be backported as well. > > So, apart from the decision about letting these very bugfixes into > jdk11u, there's a general question about how to handle incoming JFR related > backport requests that go beyond simple bugfixes. Shall we rather try to > pull in more stuff to make the JFR tooling more usable while putting > stability of JDK updates at higher risk? Or shall we be conservative here > and rather reject things if in doubt? Any thoughts or comments from the > community? > > Thanks > Christoph > > [0] https://bugs.openjdk.java.net/browse/JDK-8185525 > [1] https://bugs.openjdk.java.net/browse/JDK-8225797 > > > > From mbalao at redhat.com Thu Oct 31 14:34:19 2019 From: mbalao at redhat.com (Martin Balao) Date: Thu, 31 Oct 2019 11:34:19 -0300 Subject: [11u] RFR 8215032: Support Kerberos cross-realm referrals (RFC 6806) In-Reply-To: References: <57d1dd6b-3395-cb87-de91-690893332468@redhat.com> <8285a00c-9e6e-6b63-eb9d-660dd09d9266@redhat.com> Message-ID: <10ec73ce-2b97-fa0c-0efe-8e80325dc424@redhat.com> Hi Christoph, Now that the CSR has been reviewed [1], can I have a jdk11u-fix-yes tag in 8215032 [2]? Unless you have any objection, I'll proceed to commit once you approve -as the review process looks finished to me-. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8230496 [2] - https://bugs.openjdk.java.net/browse/JDK-8215032 On 10/30/19 12:28 PM, Langer, Christoph wrote: > Hi Martin, > > Sorry for the late reply... been rather busy the last days. > > You're asking me to review the CSR for backporting JDK8215032. I, however, am not an expert in that area and could probably only check whether you copied the content correctly from the original CSR. So, I'd like to refer this to the original CSR reviewer. > > @Weijun Wang, can you please have a look at CSR https://bugs.openjdk.java.net/browse/JDK-8230496 and add yourself as reviewer once you find everything is ok and it's a thing feasible to backport to JDK11? > > Thanks > Christoph From sgehwolf at redhat.com Thu Oct 3 15:02:46 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 03 Oct 2019 15:02:46 -0000 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 johnc at azul.com Wed Oct 9 16:25:21 2019 From: johnc at azul.com (John Cuthbertson) Date: Wed, 09 Oct 2019 16:25:21 -0000 Subject: [11u]: 8048556: Unnecessary GCLocker-initiated young GCs Message-ID: Hi Roman, I was going to contribute a back port patch for this bug for jdk8-dev but it looks like you?ve already done the back port. So I can review if you wish. I think I?m still listed as a reviewer for some projects. I actually changed Kim?s test to to use GC MXBeans to get the eden memory use before GC, write it out in a standard form, and check that the eden use was above 40%. JohnC