From denghui.ddh at alibaba-inc.com Mon Feb 3 12:48:42 2020 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Mon, 03 Feb 2020 20:48:42 +0800 Subject: =?UTF-8?B?WzExdV0gUkZSOiBCYWNrcG9ydCBvZiBKREstODIzMDQwMDogTWlzc2luZyBjb25zdGFudCBw?= =?UTF-8?B?b29sIGVudHJ5IGZvciBhIG1ldGhvZCBpbiBzdGFja3RyYWNl?= Message-ID: <27dcd62c-9cc9-433a-b269-7c86e0ea2f2a.denghui.ddh@alibaba-inc.com> Hi team, Please review this backport, original patch doesn't apply cleanly, because: - some different code structures, such as the different name of JfrStump in jfrTypeSetUtils.hpp - JDK-8209301 (JVM rename is_anonymous, host_klass to unsafe specific terminology ahead of Unsafe.defineAnonymousClass deprecation) has not been ported to 11u, and I think it's not necessary. Bug: https://bugs.openjdk.java.net/browse/JDK-8230400 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/31ec3e55fa3d Webrev: http://cr.openjdk.java.net/~ddong/8230400/ Thanks, Denghui Dong From shade at redhat.com Tue Feb 4 13:06:52 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 4 Feb 2020 14:06:52 +0100 Subject: [11u] Multiple JarUtils.java? Message-ID: <7352a03d-ab80-d610-44fc-1e6c31fdac6a@redhat.com> See: jdk-jdk $ find | grep JarUtils.java$ ./test/lib/jdk/test/lib/util/JarUtils.java jdk-updates-jdk11u-dev $ find | grep JarUtils.java ./test/jdk/lib/testlibrary/JarUtils.java ./test/lib/jdk/test/lib/util/JarUtils.java ./test/jaxp/javax/xml/jaxp/libs/jaxp/library/JarUtils.java Would anyone like to untangle what had happened here, and whether we want to actually have a single JarUtils? -- Thanks, -Aleksey From shade at redhat.com Tue Feb 4 13:10:42 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 4 Feb 2020 14:10:42 +0100 Subject: [11u] RFR 8234466: Class loading deadlock involving X509Factory#commitEvent() Message-ID: <4162a464-dded-53a1-bf8c-32b491dacb71@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8234466 https://hg.openjdk.java.net/jdk/jdk/rev/6d386d360955 The patch does not apply cleanly to 11u, because of two things: a) The move jdk.internal.misc -> jdk.internal.access happens in JDK-8211122, and that one is already rejected from 11u backports. So, I had to rewrite the uses back to jdk.internal.misc.*. b) Test fails to compile due to the ambiguity in JarUtils: createJarFile(Path,Path,Path...) and method createJarFile(Path,Path,String...). I believe it is caused by referencing one of the non-updated JarUtils [2]. Instead of choosing the another testlibary (which probably has the impact on the signing code), I opted to call the method that was available: - JarUtils.createJarFile(Path.of(TEST_CLASS_PATH, jar.getFileName().toString()), xdir); + JarUtils.createJarFile(Path.of(TEST_CLASS_PATH, jar.getFileName().toString()), xdir, Paths.get(".")); 11u webrev: https://cr.openjdk.java.net/~shade/8234466/webrev.11u.01/ Testing: new test (still passes), tier1, tier2, tier3 -- Thanks, -Aleksey [1] https://bugs.openjdk.java.net/browse/JDK-8211122 [2] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-February/002445.html From shade at redhat.com Tue Feb 4 13:13:16 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 4 Feb 2020 14:13:16 +0100 Subject: [11u] RFR 8237508: Simplify JarFile.isInitializing Message-ID: <159b29fe-e956-62aa-975d-66b9bf783601@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8237508 https://hg.openjdk.java.net/jdk/jdk/rev/c5203b158ec8 This is the follow up after JDK-8234466. Patch does not apply cleanly to 11u, because of minor context changes. 11u webrev: https://cr.openjdk.java.net/~shade/8237508/webrev.11u.01/ Testing: tier1, tier2, tier3 -- Thanks, -Aleksey [1] https://bugs.openjdk.java.net/browse/JDK-8234466 From shade at redhat.com Tue Feb 4 13:16:56 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 4 Feb 2020 14:16:56 +0100 Subject: [11u] RFR 8233019: java.lang.Class.isPrimitive() (C1) returns wrong result if Klass* is aligned to 32bit Message-ID: Original fix: https://bugs.openjdk.java.net/browse/JDK-8233019 https://hg.openjdk.java.net/jdk/jdk/rev/9bbe560e8131 Patch does not apply to 11u cleanly, because the context is a bit different due to later introduction of is_reference_type helper in JDK-8230505 [1]. I re-added the hunks in c1_LIRAssembler_s390.cpp and c1_LIRAssembler_x86.cpp by hand. 11u webrev: https://cr.openjdk.java.net/~shade/8233019/webrev.11u.01/ Testing: tier1, tier2, tier3 -- Thanks, -Aleksey [1] https://bugs.openjdk.java.net/browse/JDK-8230505 From thomas.stuefe at gmail.com Tue Feb 4 13:28:40 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 4 Feb 2020 14:28:40 +0100 Subject: [11u] RFR 8233019: java.lang.Class.isPrimitive() (C1) returns wrong result if Klass* is aligned to 32bit In-Reply-To: References: Message-ID: Hi Aleksey, looks good to me. ..Thomas On Tue, Feb 4, 2020 at 2:19 PM Aleksey Shipilev wrote: > Original fix: > https://bugs.openjdk.java.net/browse/JDK-8233019 > https://hg.openjdk.java.net/jdk/jdk/rev/9bbe560e8131 > > Patch does not apply to 11u cleanly, because the context is a bit > different due to later > introduction of is_reference_type helper in JDK-8230505 [1]. I re-added > the hunks in > c1_LIRAssembler_s390.cpp and c1_LIRAssembler_x86.cpp by hand. > > 11u webrev: > https://cr.openjdk.java.net/~shade/8233019/webrev.11u.01/ > > Testing: tier1, tier2, tier3 > > -- > Thanks, > -Aleksey > > [1] https://bugs.openjdk.java.net/browse/JDK-8230505 > > From goetz.lindenmaier at sap.com Tue Feb 4 17:40:06 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 4 Feb 2020 17:40:06 +0000 Subject: [11u] RFR: 8226406: JVM fails to detect mismatched or corrupt CDS archive In-Reply-To: References: Message-ID: Hi Jiangli, thanks for the testing! Best regards, Goez > -----Original Message----- > From: Jiangli Zhou > Sent: Donnerstag, 30. Januar 2020 19:36 > To: Lindenmaier, Goetz > Cc: jdk-updates-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > Subject: Re: [11u] RFR: 8226406: JVM fails to detect mismatched or corrupt > CDS archive > > Hi Goetz, > > My testing result looks good. > > On Wed, Jan 29, 2020 at 10:51 AM Lindenmaier, Goetz > wrote: > > > > Hi Jiangli, > > > > thanks for your review! I will add a comment. > > I thought better leave this in, in case the other functionality > > will be downported one can see this is needed, too. > > SGTM. > > Best regards, > Jiangli > > > > Best regards, > > Goetz > > > > > -----Original Message----- > > > From: Jiangli Zhou > > > Sent: Mittwoch, 29. Januar 2020 00:20 > > > To: Lindenmaier, Goetz > > > Cc: jdk-updates-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > > > Subject: Re: [11u] RFR: 8226406: JVM fails to detect mismatched or corrupt > > > CDS archive > > > > > > Hi Goetz, > > > > > > The backport and modifications in filemap.cpp look good. Would it be > > > good to also add a comment noting the code below is backported from > > > JDK 13 and not compatible/needed for 11? > > > > > > 527 //if (_header->_header_size != sz) { > > > 528 // log_info(cds)("_header_size expected: " SIZE_FORMAT, sz); > > > 529 // log_info(cds)(" actual: " SIZE_FORMAT, > > > _header->_header_size); > > > 530 // FileMapInfo::fail_continue("The shared archive file has an > > > incorrect header size."); > > > 531 // return false; > > > 532 // } > > > > > > I'll also run some tests on my side with your patch applied. > > > > > > Best regards, > > > > > > Jiangli > > > > > > On Tue, Jan 28, 2020 at 7:07 AM Lindenmaier, Goetz > > > wrote: > > > > > > > > Hi > > > > > > > > I would like to downport gthis change for parity with 11.0.7-oracle. > > > > > > > > I had to do several adaptions of the change to get the code into 11u. > > > > > > > > In filemap.cpp jdk13 distinguishes CDS_ARCHIVE_MAGIC and > > > CDS_DYNAMIC_ARCHIVE_MAGIC. Also, 13 checks field _header_size which > is > > > not in 11. > > > > > > > > I simplified this to check only for CDS_ARCHIVE_MAGIC which is known in > 11. > > > I removed the checks for _header_size. > > > > > > > > The test too varies a lot between 11 and 13. > > > > > > > > Ran it through our testing, and ran the test manually. Both passed. > > > > > > > > http://cr.openjdk.java.net/~goetz/wr20/8226406-corrupt_CDS_archive- > > > jdk11/01/ > > > > > > > > Best regards, > > > > Goetz From shade at redhat.com Wed Feb 5 10:36:37 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 5 Feb 2020 11:36:37 +0100 Subject: [11u] RFR 8233019: java.lang.Class.isPrimitive() (C1) returns wrong result if Klass* is aligned to 32bit In-Reply-To: References: Message-ID: <4afd19e6-2bf1-c89d-dc97-4136a1da9af2@redhat.com> On 2/4/20 2:28 PM, Thomas St?fe wrote: > looks good to me. Thanks, added backport request tag. -- Thanks, -Aleksey From neugens at redhat.com Wed Feb 5 12:19:46 2020 From: neugens at redhat.com (Mario Torre) Date: Wed, 05 Feb 2020 13:19:46 +0100 Subject: [11u] Request for Approval: https://bugs.openjdk.java.net/browse/JDK-8235904 Message-ID: <023f508f2b1c956d7ae0e68cf4cdc8e3e2442ce5.camel@redhat.com> Hi all! Can someone please approve this for backport into 11u? https://bugs.openjdk.java.net/browse/JDK-8235904 It applies cleanly, no changes required. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From thomas.stuefe at gmail.com Wed Feb 5 15:29:54 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 5 Feb 2020 16:29:54 +0100 Subject: [11u] RFR: 8238531: Create new switch to redirect error reporting output to stdout or stderr Message-ID: Hi all, would like to backport this enhancement since it comes in very handy in cloud environments without any file systems. original issue: https://bugs.openjdk.java.net/browse/JDK-8220786 original patch: http://hg.openjdk.java.net/jdk/jdk/rev/cf75ea6af695 Please note that the issue is accompanied by a CSR [1] for which I have created a backport CSR [2] according to the rules laid out in [3]. CSR will be approved separately I think. ---- The patch does not apply cleanly since 8209856 [4] removed some coding which is still present in jdk11. This is limited to one hunk in vmError.cpp, which I modified: --- a/src/hotspot/share/utilities/vmError.cpp Mon Mar 25 09:35:40 2019 +0100 +++ b/src/hotspot/share/utilities/vmError.cpp Wed Feb 05 15:41:51 2020 +0100 @@ -1458,24 +1458,31 @@ _current_step_info = ""; } + // Part 2: print a full error log file (optionally to stdout or stderr). // print to error log file if (!log_done) { // see if log file is already open if (!log.is_open()) { // open log file - fd_log = prepare_log_file(ErrorFile, "hs_err_pid%p.log", buffer, sizeof(buffer)); - if (fd_log != -1) { - out.print_raw("# An error report file with more information is saved as:\n# "); - out.print_raw_cr(buffer); + if (ErrorFileToStdout) { + fd_log = 1; + } else if (ErrorFileToStderr) { + fd_log = 2; + } else { + fd_log = prepare_log_file(ErrorFile, "hs_err_pid%p.log", buffer, sizeof(buffer)); + if (fd_log != -1) { + out.print_raw("# An error report file with more information is saved as:\n# "); + out.print_raw_cr(buffer); - log.set_fd(fd_log); - } else { - out.print_raw_cr("# Can not save log file, dump to screen.."); - log.set_fd(fd_out); - /* Error reporting currently needs dumpfile. - * Maybe implement direct streaming in the future.*/ - transmit_report_done = true; + } else { + out.print_raw_cr("# Can not save log file, dump to screen.."); + fd_log = 1; + /* Error reporting currently needs dumpfile. + * Maybe implement direct streaming in the future.*/ + transmit_report_done = true; + } } + log.set_fd(fd_log); } ---- Tests: manually and SAP nightlies, no issues. Thank you, Thomas ---- [1] https://bugs.openjdk.java.net/browse/JDK-8220787 [2] https://bugs.openjdk.java.net/browse/JDK-8238532 [3] https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix [4] https://bugs.openjdk.java.net/browse/JDK-8209856 From hohensee at amazon.com Wed Feb 5 17:47:49 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 5 Feb 2020 17:47:49 +0000 Subject: [11u] Request for Approval: https://bugs.openjdk.java.net/browse/JDK-8235904 In-Reply-To: <023f508f2b1c956d7ae0e68cf4cdc8e3e2442ce5.camel@redhat.com> References: <023f508f2b1c956d7ae0e68cf4cdc8e3e2442ce5.camel@redhat.com> Message-ID: Then you can just tag the issue with 'jdk11u-fix-request' and say that in a comment, which you've done. No need for a review request. :) Paul ?On 2/5/20, 4:20 AM, "jdk-updates-dev on behalf of Mario Torre" wrote: Hi all! Can someone please approve this for backport into 11u? https://bugs.openjdk.java.net/browse/JDK-8235904 It applies cleanly, no changes required. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From hohensee at amazon.com Wed Feb 5 17:56:46 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 5 Feb 2020 17:56:46 +0000 Subject: [11u] RFR 8237508: Simplify JarFile.isInitializing In-Reply-To: <159b29fe-e956-62aa-975d-66b9bf783601@redhat.com> References: <159b29fe-e956-62aa-975d-66b9bf783601@redhat.com> Message-ID: <38534A30-D241-4D22-B2DA-641D07F91F5D@amazon.com> Lgtm. Paul ?On 2/4/20, 5:15 AM, "jdk-updates-dev on behalf of Aleksey Shipilev" wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8237508 https://hg.openjdk.java.net/jdk/jdk/rev/c5203b158ec8 This is the follow up after JDK-8234466. Patch does not apply cleanly to 11u, because of minor context changes. 11u webrev: https://cr.openjdk.java.net/~shade/8237508/webrev.11u.01/ Testing: tier1, tier2, tier3 -- Thanks, -Aleksey [1] https://bugs.openjdk.java.net/browse/JDK-8234466 From neugens at redhat.com Wed Feb 5 17:59:48 2020 From: neugens at redhat.com (Mario Torre) Date: Wed, 5 Feb 2020 18:59:48 +0100 Subject: [11u] Request for Approval: https://bugs.openjdk.java.net/browse/JDK-8235904 In-Reply-To: References: <023f508f2b1c956d7ae0e68cf4cdc8e3e2442ce5.camel@redhat.com> Message-ID: On Wed, Feb 5, 2020 at 6:48 PM Hohensee, Paul wrote: > > Then you can just tag the issue with 'jdk11u-fix-request' and say that in a comment, which you've done. No need for a review request. :) Hi Paul, Thanks! Yes, I initially mistyped it as jdk11-fix-request (notice the missing 'u'). I set the correct label now. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From hohensee at amazon.com Wed Feb 5 18:14:50 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 5 Feb 2020 18:14:50 +0000 Subject: [11u] RFR 8234466: Class loading deadlock involving X509Factory#commitEvent() In-Reply-To: <4162a464-dded-53a1-bf8c-32b491dacb71@redhat.com> References: <4162a464-dded-53a1-bf8c-32b491dacb71@redhat.com> Message-ID: Lgtm. Paul ?On 2/4/20, 5:12 AM, "jdk-updates-dev on behalf of Aleksey Shipilev" wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8234466 https://hg.openjdk.java.net/jdk/jdk/rev/6d386d360955 The patch does not apply cleanly to 11u, because of two things: a) The move jdk.internal.misc -> jdk.internal.access happens in JDK-8211122, and that one is already rejected from 11u backports. So, I had to rewrite the uses back to jdk.internal.misc.*. b) Test fails to compile due to the ambiguity in JarUtils: createJarFile(Path,Path,Path...) and method createJarFile(Path,Path,String...). I believe it is caused by referencing one of the non-updated JarUtils [2]. Instead of choosing the another testlibary (which probably has the impact on the signing code), I opted to call the method that was available: - JarUtils.createJarFile(Path.of(TEST_CLASS_PATH, jar.getFileName().toString()), xdir); + JarUtils.createJarFile(Path.of(TEST_CLASS_PATH, jar.getFileName().toString()), xdir, Paths.get(".")); 11u webrev: https://cr.openjdk.java.net/~shade/8234466/webrev.11u.01/ Testing: new test (still passes), tier1, tier2, tier3 -- Thanks, -Aleksey [1] https://bugs.openjdk.java.net/browse/JDK-8211122 [2] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-February/002445.html From shade at redhat.com Thu Feb 6 10:03:15 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 6 Feb 2020 11:03:15 +0100 Subject: [11u] RFR 8234466: Class loading deadlock involving X509Factory#commitEvent() In-Reply-To: References: <4162a464-dded-53a1-bf8c-32b491dacb71@redhat.com> Message-ID: Thanks Paul, I added the approval request tag for this and the follow-up (8237508). -Aleksey On 2/5/20 7:14 PM, Hohensee, Paul wrote: > Lgtm. > > Paul > > ?On 2/4/20, 5:12 AM, "jdk-updates-dev on behalf of Aleksey Shipilev" wrote: > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8234466 > https://hg.openjdk.java.net/jdk/jdk/rev/6d386d360955 > > The patch does not apply cleanly to 11u, because of two things: > > a) The move jdk.internal.misc -> jdk.internal.access happens in JDK-8211122, and that one is > already rejected from 11u backports. So, I had to rewrite the uses back to jdk.internal.misc.*. > > b) Test fails to compile due to the ambiguity in JarUtils: createJarFile(Path,Path,Path...) and > method createJarFile(Path,Path,String...). I believe it is caused by referencing one of the > non-updated JarUtils [2]. Instead of choosing the another testlibary (which probably has the impact > on the signing code), I opted to call the method that was available: > - JarUtils.createJarFile(Path.of(TEST_CLASS_PATH, jar.getFileName().toString()), xdir); > + JarUtils.createJarFile(Path.of(TEST_CLASS_PATH, jar.getFileName().toString()), xdir, Paths.get(".")); > > 11u webrev: > https://cr.openjdk.java.net/~shade/8234466/webrev.11u.01/ > > Testing: new test (still passes), tier1, tier2, tier3 > > -- > Thanks, > -Aleksey > > [1] https://bugs.openjdk.java.net/browse/JDK-8211122 > [2] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-February/002445.html From shade at redhat.com Thu Feb 6 10:06:19 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 6 Feb 2020 11:06:19 +0100 Subject: [11u] RFR: 8238531: Create new switch to redirect error reporting output to stdout or stderr In-Reply-To: References: Message-ID: Hi Thomas, On 2/5/20 4:29 PM, Thomas St?fe wrote: > original issue: https://bugs.openjdk.java.net/browse/JDK-8220786 > original patch: http://hg.openjdk.java.net/jdk/jdk/rev/cf75ea6af695 This seems easy to accept. > The patch does not apply cleanly since 8209856 [4] removed some coding > which is still present in jdk11. This is limited to one hunk in > vmError.cpp, which I modified: Could you show the final 11u webrev for this, please? -- Thanks, -Aleksey From thomas.stuefe at gmail.com Thu Feb 6 10:15:33 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 6 Feb 2020 11:15:33 +0100 Subject: [11u] RFR: 8238531: Create new switch to redirect error reporting output to stdout or stderr In-Reply-To: References: Message-ID: Hi Aleksey, Man, forgot the most important part :) full webrev for 11u: http://cr.openjdk.java.net/~stuefe/webrevs/8220786--create-new-switch-to-redirect-error-reporting-output-to-stdout-or-stderr-11u/webrev.00/webrev/ Thanks! ..Thomas On Thu, Feb 6, 2020 at 11:06 AM Aleksey Shipilev wrote: > Hi Thomas, > > On 2/5/20 4:29 PM, Thomas St?fe wrote: > > original issue: https://bugs.openjdk.java.net/browse/JDK-8220786 > > original patch: http://hg.openjdk.java.net/jdk/jdk/rev/cf75ea6af695 > > This seems easy to accept. > > > The patch does not apply cleanly since 8209856 [4] removed some coding > > which is still present in jdk11. This is limited to one hunk in > > vmError.cpp, which I modified: > > Could you show the final 11u webrev for this, please? > > -- > Thanks, > -Aleksey > > From shade at redhat.com Thu Feb 6 10:22:10 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 6 Feb 2020 11:22:10 +0100 Subject: [11u] RFR: 8238531: Create new switch to redirect error reporting output to stdout or stderr In-Reply-To: References: Message-ID: On 2/6/20 11:15 AM, Thomas St?fe wrote: > http://cr.openjdk.java.net/~stuefe/webrevs/8220786--create-new-switch-to-redirect-error-reporting-output-to-stdout-or-stderr-11u/webrev.00/webrev/ Thanks, this backport looks good to me. -- -Aleksey From thomas.stuefe at gmail.com Thu Feb 6 10:24:08 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 6 Feb 2020 11:24:08 +0100 Subject: [11u] RFR: 8238531: Create new switch to redirect error reporting output to stdout or stderr In-Reply-To: References: Message-ID: Thank you Aleksey. On Thu, Feb 6, 2020 at 11:22 AM Aleksey Shipilev wrote: > On 2/6/20 11:15 AM, Thomas St?fe wrote: > > > http://cr.openjdk.java.net/~stuefe/webrevs/8220786--create-new-switch-to-redirect-error-reporting-output-to-stdout-or-stderr-11u/webrev.00/webrev/ > Thanks, this backport looks good to me. > > -- > -Aleksey > > From rkennke at redhat.com Thu Feb 6 10:47:07 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 6 Feb 2020 11:47:07 +0100 Subject: RFR: Backport of JDK-8209686: cleanup arguments to PhaseIdealLoop() constructor Message-ID: I'd like to backport the change for JDK-8209686, originally done in jdk12, to jdk11u. It cleans up some code paths in C2. It makes the backport for Shenandoah touch much less shared code. The original patch applies cleanly on jdk11u-dev, except for some very minor changes that I needed to make in loopnode.hpp because surrounding comments/code did not match. Bug: https://bugs.openjdk.java.net/browse/JDK-8209686 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8209686-jdk11u/webrev.00/ Testing: tier1, tier2 Can I please get a review? Thanks, Roman From shade at redhat.com Thu Feb 6 10:56:08 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 6 Feb 2020 11:56:08 +0100 Subject: RFR: Backport of JDK-8209686: cleanup arguments to PhaseIdealLoop() constructor In-Reply-To: References: Message-ID: On 2/6/20 11:47 AM, Roman Kennke wrote: > The original patch applies cleanly on jdk11u-dev, except for some very > minor changes that I needed to make in loopnode.hpp because surrounding > comments/code did not match. The changes are not in the code, though, right? I cannot spot any. I presume you just needed to reapply some hunks by hand? > Bug: > https://bugs.openjdk.java.net/browse/JDK-8209686 > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8209686-jdk11u/webrev.00/ > Testing: tier1, tier2 The backport looks good. -- Thanks, -Aleksey From rkennke at redhat.com Thu Feb 6 11:14:58 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 6 Feb 2020 12:14:58 +0100 Subject: RFR: Backport of JDK-8209686: cleanup arguments to PhaseIdealLoop() constructor In-Reply-To: References: Message-ID: <02a8ebe1-4bf0-17d7-edbc-cfc1335afd87@redhat.com> Hi Aleksey, >> The original patch applies cleanly on jdk11u-dev, except for some very >> minor changes that I needed to make in loopnode.hpp because surrounding >> comments/code did not match. > > The changes are not in the code, though, right? I cannot spot any. I presume you just needed to > reapply some hunks by hand? Yes. I did hg transplant to transplant the original change and then re-applied the changes. It didn't apply due to surrounding changes like here: _dom_lca_tags(arena()), // Thread::resource_area _verify_me(NULL), _verify_only(true) { - build_and_optimize(false, false); + build_and_optimize(LoopOptsVerify); } _verify_me(NULL), _verify_only(true), _dom_lca_tags(arena()) { // Thread::resource_area - build_and_optimize(false, false); + build_and_optimize(LoopOptsVerify); } I.e. the changed constructor args order. >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8209686 >> Webrev: >> http://cr.openjdk.java.net/~rkennke/JDK-8209686-jdk11u/webrev.00/ >> Testing: tier1, tier2 > > The backport looks good. Thanks for reviewing! Roman From christoph.langer at sap.com Thu Feb 6 13:07:47 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 6 Feb 2020 13:07:47 +0000 Subject: RFR: Backport of JDK-8209686: cleanup arguments to PhaseIdealLoop() constructor In-Reply-To: <02a8ebe1-4bf0-17d7-edbc-cfc1335afd87@redhat.com> References: <02a8ebe1-4bf0-17d7-edbc-cfc1335afd87@redhat.com> Message-ID: Hi Roman, I've approved this backport. Does that mean your Shenandoah patch for 11u needs to be rebased? Cheers Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Roman Kennke > Sent: Donnerstag, 6. Februar 2020 12:15 > To: Aleksey Shipilev ; jdk-updates-dev dev at openjdk.java.net> > Subject: Re: RFR: Backport of JDK-8209686: cleanup arguments to > PhaseIdealLoop() constructor > > Hi Aleksey, > > >> The original patch applies cleanly on jdk11u-dev, except for some very > >> minor changes that I needed to make in loopnode.hpp because > surrounding > >> comments/code did not match. > > > > The changes are not in the code, though, right? I cannot spot any. I > presume you just needed to > > reapply some hunks by hand? > > Yes. I did hg transplant to transplant the original change and then > re-applied the changes. It didn't apply due to surrounding changes like > here: > > _dom_lca_tags(arena()), // Thread::resource_area > _verify_me(NULL), > _verify_only(true) { > - build_and_optimize(false, false); > + build_and_optimize(LoopOptsVerify); > } > > > _verify_me(NULL), > _verify_only(true), > _dom_lca_tags(arena()) { // Thread::resource_area > - build_and_optimize(false, false); > + build_and_optimize(LoopOptsVerify); > } > > I.e. the changed constructor args order. > > >> Bug: > >> https://bugs.openjdk.java.net/browse/JDK-8209686 > >> Webrev: > >> http://cr.openjdk.java.net/~rkennke/JDK-8209686-jdk11u/webrev.00/ > >> Testing: tier1, tier2 > > > > The backport looks good. > > Thanks for reviewing! > Roman From rkennke at redhat.com Thu Feb 6 13:30:31 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 6 Feb 2020 14:30:31 +0100 Subject: RFR: Backport of JDK-8209686: cleanup arguments to PhaseIdealLoop() constructor In-Reply-To: References: <02a8ebe1-4bf0-17d7-edbc-cfc1335afd87@redhat.com> Message-ID: <57998e9a-d9b9-8f0c-c525-c2476c36e8d2@redhat.com> Hi Christoph, > Hi Roman, > > I've approved this backport. Does that mean your Shenandoah patch for 11u needs to be rebased? Thank you! Yes, I will send the re-based patch later today (hopefully). Roman > > Cheers > Christoph > >> -----Original Message----- >> From: jdk-updates-dev On >> Behalf Of Roman Kennke >> Sent: Donnerstag, 6. Februar 2020 12:15 >> To: Aleksey Shipilev ; jdk-updates-dev > dev at openjdk.java.net> >> Subject: Re: RFR: Backport of JDK-8209686: cleanup arguments to >> PhaseIdealLoop() constructor >> >> Hi Aleksey, >> >>>> The original patch applies cleanly on jdk11u-dev, except for some very >>>> minor changes that I needed to make in loopnode.hpp because >> surrounding >>>> comments/code did not match. >>> >>> The changes are not in the code, though, right? I cannot spot any. I >> presume you just needed to >>> reapply some hunks by hand? >> >> Yes. I did hg transplant to transplant the original change and then >> re-applied the changes. It didn't apply due to surrounding changes like >> here: >> >> _dom_lca_tags(arena()), // Thread::resource_area >> _verify_me(NULL), >> _verify_only(true) { >> - build_and_optimize(false, false); >> + build_and_optimize(LoopOptsVerify); >> } >> >> >> _verify_me(NULL), >> _verify_only(true), >> _dom_lca_tags(arena()) { // Thread::resource_area >> - build_and_optimize(false, false); >> + build_and_optimize(LoopOptsVerify); >> } >> >> I.e. the changed constructor args order. >> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8209686 >>>> Webrev: >>>> http://cr.openjdk.java.net/~rkennke/JDK-8209686-jdk11u/webrev.00/ >>>> Testing: tier1, tier2 >>> >>> The backport looks good. >> >> Thanks for reviewing! >> Roman > From christoph.langer at sap.com Thu Feb 6 17:30:27 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 6 Feb 2020 17:30:27 +0000 Subject: [11u] Multiple JarUtils.java? In-Reply-To: <7352a03d-ab80-d610-44fc-1e6c31fdac6a@redhat.com> References: <7352a03d-ab80-d610-44fc-1e6c31fdac6a@redhat.com> Message-ID: Hi Aleksey, the unification of these 3 files was done some time in JDK 12 timeframe by https://bugs.openjdk.java.net/browse/JDK-8211171 (http://hg.openjdk.java.net/jdk/jdk/rev/a8862960c19f). It's certainly something that could be brought back to 11 if we find it'll ease backporting. After all, it's just a change in auxillary libraries for testing. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Aleksey Shipilev > Sent: Dienstag, 4. Februar 2020 14:07 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] Multiple JarUtils.java? > > See: > > jdk-jdk $ find | grep JarUtils.java$ > ./test/lib/jdk/test/lib/util/JarUtils.java > > jdk-updates-jdk11u-dev $ find | grep JarUtils.java > ./test/jdk/lib/testlibrary/JarUtils.java > ./test/lib/jdk/test/lib/util/JarUtils.java > ./test/jaxp/javax/xml/jaxp/libs/jaxp/library/JarUtils.java > > Would anyone like to untangle what had happened here, and whether we > want to actually have a single > JarUtils? > > -- > Thanks, > -Aleksey From christoph.langer at sap.com Thu Feb 6 18:00:41 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 6 Feb 2020 18:00:41 +0000 Subject: Issue with 13.0.2 release (was: [Updates Communication] 13.0.2 security patches pushed) In-Reply-To: <20200129140057.GA13559@yoga> References: <20200129140057.GA13559@yoga> Message-ID: Hi Rob, thanks for fixing the backport records to show 13u-open instead of 13.0.2. This seems correct now. For 14u you should try to switch hgupdater on the open "jdk-updates/jdk14u" repository to 14u-open at the time when you don't plan to do merges into 14.0.2 anymore. Then we'd avoid such a situation. Thanks Christoph > -----Original Message----- > From: Rob McKenna > Sent: Mittwoch, 29. Januar 2020 15:01 > To: Langer, Christoph > Cc: jdk-updates-dev at openjdk.java.net > Subject: Re: Issue with 13.0.2 release (was: [Updates Communication] 13.0.2 > security patches pushed) > > Hi Christoph, > > These patches did not make the ga build of OpenJDK 13.0.2, however the > patches were pushed to the repo (post-ga tag) in order to give the > option to downstream builders to include them in their own builds if > they wanted. > > Those 13.0.2 records are incorrect however, thanks for pointing that > out. I'll change the fix version to jdk13u. > > -Rob > > On 24/01/20 15:21, Langer, Christoph wrote: > > Hi Rob, > > > > first of all, thanks for pushing the security patches to 13.0.2 and setting the > tags. > > > > I have, however, found a little issue. The tag 13.0.2-ga points to this > change: http://hg.openjdk.java.net/jdk-updates/jdk13u/rev/7b8ce94cc932 > > > > If you look at the repository tree, you'll see however that this change is > below the merge of this branch and another line in jdk13u which contains the > last 6 public pushes: > > > > 8233223: Add Amazon Root CA certificates8 weeks ago, by rhalade - > http://hg.openjdk.java.net/jdk-updates/jdk13u/rev/459a2f735b99 > > 8234245: sun/security/lib/cacerts/VerifyCACerts.java fails due to wrong > checksum2 months ago, by jiefu - http://hg.openjdk.java.net/jdk- > updates/jdk13u/rev/b2305a0a3146 > > 8233219: NMT output on AIX misses some categories2 months ago, by > mbaesken - http://hg.openjdk.java.net/jdk- > updates/jdk13u/rev/0919082b7634 > > 8232019: Add LuxTrust certificate updates to the existing root program2 > months ago, by rhalade - http://hg.openjdk.java.net/jdk- > updates/jdk13u/rev/e69aa0686696 > > 8234107: Several AWT modal dialog tests failing on Linux after JDK-82319912 > months ago, by neugens - http://hg.openjdk.java.net/jdk- > updates/jdk13u/rev/486735e93d55 > > 8231991: Mouse wheel change focus on awt/swing windows - > http://hg.openjdk.java.net/jdk-updates/jdk13u/rev/743b29c2372f > > > > So, these 6 changesets are not contained in 13.0.2-ga! > > > > Looking at the corresponding JBS items, you'll find resolved backports of > these for 13.0.2 and 13u-cpu. I think since we see 13.0.2 here, those should > be under the 13.0.2-ga tag. > > > > For the LuxTrust and Amazon Root CA changes, there have been separate > pushes in your internal repository as well which are in 13.0.2-ga. And I believe > 8234245 was contained in your internal 8233223 push. So, effectively 13.0.2 > OpenJDK is missing these items: > > 8233219: NMT output on AIX misses some categories > > 8234107: Several AWT modal dialog tests failing on Linux after JDK-8231991 > > 8231991: Mouse wheel change focus on awt/swing windows > > > > I don't know whether we should move the 13.0.2-ga tag to the merge > commit or just leave it as is, given the importance of JDK13 and the priority of > these fixes. But in any case, this shouldn't happen again with 14.0.1 and > later... > > > > Best regards > > Christoph > > > > > -----Original Message----- > > > From: jdk-updates-dev > On > > > Behalf Of Rob McKenna > > > Sent: Donnerstag, 16. Januar 2020 16:18 > > > To: Severin Gehwolf > > > Cc: jdk-updates-dev at openjdk.java.net > > > Subject: Re: [Updates Communication] 13.0.2 security patches pushed > > > > > > Just pushed - apologies for the delay. > > > > > > -Rob > > > > > > On 15/01/20 18:06, Severin Gehwolf wrote: > > > > On Wed, 2020-01-15 at 16:05 +0000, Rob McKenna wrote: > > > > > 13.0.2 patches have been pushed to: > > > > > > > > > > http://hg.openjdk.java.net/jdk-updates/jdk13u/ > > > > > > > > Thanks, Rob! Is there going to be a jdk-13.0.2-ga tag? > > > > > > > > Cheers, > > > > Severin > > > > From rkennke at redhat.com Thu Feb 6 19:43:34 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 6 Feb 2020 20:43:34 +0100 Subject: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u In-Reply-To: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> Message-ID: <85327ce1-2336-8950-871e-ac0af1856701@redhat.com> Hello all, This is an update on the proposed patch. - It is rebased on latest jdk11u-dev, and in particular on the backport of: https://bugs.openjdk.java.net/browse/JDK-8209686 ... which considerably improves C2 shared-code-changes. - Includes the latest bunch of Shenandoah/jdk11u backports by Aleksey: https://mail.openjdk.java.net/pipermail/shenandoah-dev/2020-February/011417.html Full webrev: http://cr.openjdk.java.net/~rkennke/shenandoah-jdk11u-upstream/webrev.03-all/ Shared-code webrev: http://cr.openjdk.java.net/~rkennke/shenandoah-jdk11u-upstream/webrev.03-shared/ Please review/test that instead of the previous patches. Thanks, Roman > Hello, > > The Shenandoah GC has been integrated into jdk12 a little over a year ago: > > http://hg.openjdk.java.net/jdk/jdk/rev/9c18c9d839d3 > > The Shenandoah team has been maintaining the Shenandoah-enabled jdk11u > downstream repository since the inception of jdk11 under: > > http://hg.openjdk.java.net/shenandoah/jdk11 > > In order to make it more useful and accessible for users, we would like > to make it available in upstream jdk11u. The Shenandoah team at Red Hat > intends to maintain it the same way it had been maintained in > shenandoah/jdk11, in the course of regular jdk11u maintenance Red Hat > already does. > > Thanks to recent changes in Shenandoah over the last year, we are now > able to fit the GC interface in jdk11 almost exactly. There are a few > exceptions though. We tried to follow the following pattern for all > shared-code changes where it made sense: > > #if INCLUDE_SHENANDOAH_GC > if (UseShenandoahGC) { > ... > } > #endif > > This ensures that the Shenandoah-specific changes are cut out of the > build when building without Shenandoah, and avoid those code paths at > runtime when running without Shenandoah. > > Also, there are a few places where this was not possible or where it > didn't seem feasible, but we tried to keep them few and obvious. > Whenever this is the case, we are mirroring as close as possible what we > have in jdk/jdk. > > Architecture-wise, Shenandoah runs on x86_64, aarch64, x86_32. Other > architectures still build fine, and Shenandoah gets automatically > disabled during configure if not supported. OS-wise, Shenandoah runs on > Linux, Windows, and is known to run on MacOS X and Solaris too. > > I wasn't sure which form this should take. I decided to start with the > easiest possible form this could take: a simple patch/webrev and an RFR. > Let me know if you need a JIRA issue or any other formalities to track that. > > Full webrev: > https://cr.openjdk.java.net/~rkennke/shenandoah-jdk11u-upstream/webrev.02-all/ > > Webrev only for shared-code changes: > https://cr.openjdk.java.net/~rkennke/shenandoah-jdk11u-upstream/webrev.02-shared/ > > The webrevs are based on and depend on the arraycopy patch proposed for > review here: > > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-January/002396.html > > Testing: > The code has been tested many many times, continuously while maintaining > it. It has also served as the basis for RPMs and shipped to customers. > We are running all sorts of tests of the hotspot/jtreg testsuite, in > particular hotspot_gc_shenandoah, CTW tests, the regular tier* tests, > several popular benchmarks (specjvm, specjbb on a regular basis), on a > nightly basis. > > Please let me know what you think. > > Thanks, > Roman > > > > > > > From mbalao at redhat.com Thu Feb 6 19:45:18 2020 From: mbalao at redhat.com (Martin Balao) Date: Thu, 6 Feb 2020 16:45:18 -0300 Subject: [11u] RFR 8237600: Test SunJSSEFIPSInit fails on Ubuntu Message-ID: <5a92da7f-f913-68da-4453-8f5eb4898b96@redhat.com> Hi, I'd like to propose a fix for 8237600 [1]. Webrev.00: * http://cr.openjdk.java.net/~mbalao/webrevs/8237600/8237600.webrev.00/ Change removes a hardcoded library path on the NSS configuration and lets the system decide. @Boris Ulasevich has confirmed that the patch fixes the test on Ubuntu 16.04.5 LTS and Ubuntu 18.04.3 LTS. I can confirm that the test continues working on Fedora x86-64. This change applies to 11u-only, as it fixes a test introduced by 8230923 [2] which is 11u-only. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8237600 [2] - https://bugs.openjdk.java.net/browse/JDK-8230923 From shade at redhat.com Thu Feb 6 19:51:08 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 6 Feb 2020 20:51:08 +0100 Subject: [11u] RFR 8237600: Test SunJSSEFIPSInit fails on Ubuntu In-Reply-To: <5a92da7f-f913-68da-4453-8f5eb4898b96@redhat.com> References: <5a92da7f-f913-68da-4453-8f5eb4898b96@redhat.com> Message-ID: <6050a441-c34c-c546-251a-5e140111159e@redhat.com> On 2/6/20 8:45 PM, Martin Balao wrote: > Webrev.00: > * http://cr.openjdk.java.net/~mbalao/webrevs/8237600/8237600.webrev.00/ Looks good. > Change removes a hardcoded library path on the NSS configuration and > lets the system decide. > > @Boris Ulasevich has confirmed that the patch fixes the test on Ubuntu > 16.04.5 LTS and Ubuntu 18.04.3 LTS. I can confirm that the test > continues working on Fedora x86-64. Oh, thank you. My Ubuntu nodes are also happy now. -- -Aleksey From mbalao at redhat.com Thu Feb 6 20:01:52 2020 From: mbalao at redhat.com (Martin Balao) Date: Thu, 6 Feb 2020 17:01:52 -0300 Subject: [11u] RFR 8237600: Test SunJSSEFIPSInit fails on Ubuntu In-Reply-To: <6050a441-c34c-c546-251a-5e140111159e@redhat.com> References: <5a92da7f-f913-68da-4453-8f5eb4898b96@redhat.com> <6050a441-c34c-c546-251a-5e140111159e@redhat.com> Message-ID: On 2/6/20 4:51 PM, Aleksey Shipilev wrote: > On 2/6/20 8:45 PM, Martin Balao wrote: >> Webrev.00: >> * http://cr.openjdk.java.net/~mbalao/webrevs/8237600/8237600.webrev.00/ > > Looks good. > >> Change removes a hardcoded library path on the NSS configuration and >> lets the system decide. >> >> @Boris Ulasevich has confirmed that the patch fixes the test on Ubuntu >> 16.04.5 LTS and Ubuntu 18.04.3 LTS. I can confirm that the test >> continues working on Fedora x86-64. > > Oh, thank you. My Ubuntu nodes are also happy now. > -- > -Aleksey > Thanks Aleksey for having a look. Fix approval request here: https://bugs.openjdk.java.net/browse/JDK-8237600?focusedCommentId=14316023&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14316023 From gil at azul.com Thu Feb 6 22:55:20 2020 From: gil at azul.com (Gil Tene) Date: Thu, 6 Feb 2020 22:55:20 +0000 Subject: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u In-Reply-To: <85327ce1-2336-8950-871e-ac0af1856701@redhat.com> References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <85327ce1-2336-8950-871e-ac0af1856701@redhat.com> Message-ID: Roman, As this is proposing a pretty significant backport of an experimental feature that is in-development in upstream versions, can you comment on how you expect it to progress and evolve after initial integration into the stable, in-maintenance-mode 11u? E.g. here are some specifics: - Do you expect that the 11u implementation will start diverging from the upstream path and start following a separate path towards a non-experimental form? Or will it closely match the upstream progress and changes, moving to non-experimental form only when an upstream version includes a non-experimental version? - Do you expect to advocate for porting of bug fixes only, or also of features and improvements from upstream versions? [In my terminology, a bug fix is something like "no longer crashes when X happens", an improvement is something like "runs twice as fast" or "has generational collection", and a feature is something like e.g. "can be configured with new flag X to proactively adjust heap size over time". E.g. if the redesign from Shenandoah 1.0 to Shenandoah 2.0 had happened after this initial backport was integrated, would you later be advocating for a backport of the redesign to 11u? - If it is more than just bug fixes that you propose tracking, then for how long? e.g. once 17u comes out in Sep. 2021 (19 months from now), will you advocate that new Shenandoah improvements or features being worked on in OpenJDK 18u be backported top 11u? Or will there be some sunset where we say "11 has what 11 has, if you want new improvements and features, move to new version X"? - Would you advocate for backporting from upstream versions to all intermediate versions? e.g. from a 16EA to 15.0.2 in Jan 2021, or to an 13.0.6 if one was still being built?, or just to 11u? - Do you expect to start backporting other upstream features or redesigns aimed at supporting the maturation of Shenandoah in 11u, but that would not be needed in 11u for other reasons? The example of https://bugs.openjdk.java.net/browse/JDK-8230565 comes to mind, as I expect the new LRB might be similarly susceptible to C2 scheduling load barriers across safepoints, and may need a similar redesign of the C2 load barrier in order to stabilize an LRB-based Shenandoah implementation. Would you advocate for such a redesign to be backported into the stable 11u C2 as well? Would it make sense to introduce the Shenandoah backport if we do not intend to later follow through with such supporting (but wider impacting on 11u) items? - Do you expect that the initial backport, or it's later evolution, will require changes to critical shared code components in 11u that would not be needed otherwise in 11u, and are not yet included in e.g. any upstream LTS version? E.g. your suggetions for https://bugs.openjdk.java.net/browse/JDK-8209686 seems like a reasonable and not-too-big change, but one that 11u has no need for and would likely not bring in to C2 for any other reason. How to we choose if and when to add such things to the stable, in-maintenance-mode 11u (and risk destabilizing its core functionality inadvertently)? ? Gil. > On Feb 6, 2020, at 11:43 AM, Roman Kennke wrote: > > Hello all, > > This is an update on the proposed patch. > > - It is rebased on latest jdk11u-dev, and in particular on the backport of: > https://bugs.openjdk.java.net/browse/JDK-8209686 > > ... which considerably improves C2 shared-code-changes. > > - Includes the latest bunch of Shenandoah/jdk11u backports by Aleksey: > https://mail.openjdk.java.net/pipermail/shenandoah-dev/2020-February/011417.html > > Full webrev: > http://cr.openjdk.java.net/~rkennke/shenandoah-jdk11u-upstream/webrev.03-all/ > > Shared-code webrev: > http://cr.openjdk.java.net/~rkennke/shenandoah-jdk11u-upstream/webrev.03-shared/ > > Please review/test that instead of the previous patches. > > Thanks, > Roman > >> Hello, >> >> The Shenandoah GC has been integrated into jdk12 a little over a year ago: >> >> http://hg.openjdk.java.net/jdk/jdk/rev/9c18c9d839d3 >> >> The Shenandoah team has been maintaining the Shenandoah-enabled jdk11u >> downstream repository since the inception of jdk11 under: >> >> http://hg.openjdk.java.net/shenandoah/jdk11 >> >> In order to make it more useful and accessible for users, we would like >> to make it available in upstream jdk11u. The Shenandoah team at Red Hat >> intends to maintain it the same way it had been maintained in >> shenandoah/jdk11, in the course of regular jdk11u maintenance Red Hat >> already does. >> >> Thanks to recent changes in Shenandoah over the last year, we are now >> able to fit the GC interface in jdk11 almost exactly. There are a few >> exceptions though. We tried to follow the following pattern for all >> shared-code changes where it made sense: >> >> #if INCLUDE_SHENANDOAH_GC >> if (UseShenandoahGC) { >> ... >> } >> #endif >> >> This ensures that the Shenandoah-specific changes are cut out of the >> build when building without Shenandoah, and avoid those code paths at >> runtime when running without Shenandoah. >> >> Also, there are a few places where this was not possible or where it >> didn't seem feasible, but we tried to keep them few and obvious. >> Whenever this is the case, we are mirroring as close as possible what we >> have in jdk/jdk. >> >> Architecture-wise, Shenandoah runs on x86_64, aarch64, x86_32. Other >> architectures still build fine, and Shenandoah gets automatically >> disabled during configure if not supported. OS-wise, Shenandoah runs on >> Linux, Windows, and is known to run on MacOS X and Solaris too. >> >> I wasn't sure which form this should take. I decided to start with the >> easiest possible form this could take: a simple patch/webrev and an RFR. >> Let me know if you need a JIRA issue or any other formalities to track that. >> >> Full webrev: >> https://cr.openjdk.java.net/~rkennke/shenandoah-jdk11u-upstream/webrev.02-all/ >> >> Webrev only for shared-code changes: >> https://cr.openjdk.java.net/~rkennke/shenandoah-jdk11u-upstream/webrev.02-shared/ >> >> The webrevs are based on and depend on the arraycopy patch proposed for >> review here: >> >> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-January/002396.html >> >> Testing: >> The code has been tested many many times, continuously while maintaining >> it. It has also served as the basis for RPMs and shipped to customers. >> We are running all sorts of tests of the hotspot/jtreg testsuite, in >> particular hotspot_gc_shenandoah, CTW tests, the regular tier* tests, >> several popular benchmarks (specjvm, specjbb on a regular basis), on a >> nightly basis. >> >> Please let me know what you think. >> >> Thanks, >> Roman >> >> >> >> >> >> >> From christoph.langer at sap.com Fri Feb 7 11:12:22 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 7 Feb 2020 11:12:22 +0000 Subject: RFR(14u): 8237375: SimpleThresholdPolicy misses CounterDecay timestamp initialization Message-ID: Hi, please help reviewing the backport of the following change to jdk14u: Bug: https://bugs.openjdk.java.net/browse/JDK-8237375 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/2a0e2304e68b Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8237375.14u/ The original change would not apply due to its predecessor "8235741: Inappropriate uses of os::javaTimeMillis()" which isn't backported. I had to do some context shifting and replace usage of method nanos_to_millis, since this was only introduced with 8235741. Thanks Christoph From christoph.langer at sap.com Fri Feb 7 11:16:19 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 7 Feb 2020 11:16:19 +0000 Subject: [11u] RFR: 8237375: SimpleThresholdPolicy misses CounterDecay timestamp initialization Message-ID: Hi, please help reviewing the backport of the following change to jdk11u: Bug: https://bugs.openjdk.java.net/browse/JDK-8237375 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/2a0e2304e68b Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8237375.11u/ Between 11 and head, src/hotspot/share/runtime/compilationPolicy.cpp was moved to src/hotspot/share/compiler/compilationPolicy.cpp. So, the backport goes to src/hotspot/share/runtime/compilationPolicy.cpp. The original change would furthermore not apply due to its predecessor "8235741: Inappropriate uses of os::javaTimeMillis()" which isn't backported. I had to do some context shifting and replace usage of method nanos_to_millis, since this was only introduced with 8235741. Thanks Christoph From volker.simonis at gmail.com Fri Feb 7 11:31:01 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 7 Feb 2020 03:31:01 -0800 Subject: RFR(14u): 8237375: SimpleThresholdPolicy misses CounterDecay timestamp initialization In-Reply-To: References: Message-ID: Looks good except that I'd rather use: + return ((os::javaTimeNanos() - _last_timestamp) / NANOUNITS_PER_MILLIUNIT) > CounterDecayMinIntervalLength; instead of: + return ((os::javaTimeNanos() - _last_timestamp) / NANOUNITS * MILLIUNITS) > CounterDecayMinIntervalLength; because it looks clearer (and is exactly what nanos_to_millis() also does). On Fri, Feb 7, 2020 at 3:12 AM Langer, Christoph wrote: > > Hi, > > please help reviewing the backport of the following change to jdk14u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8237375 > Original change: https://hg.openjdk.java.net/jdk/jdk/rev/2a0e2304e68b > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8237375.14u/ > > The original change would not apply due to its predecessor "8235741: Inappropriate uses of os::javaTimeMillis()" which isn't backported. I had to do some context shifting and replace usage of method nanos_to_millis, since this was only introduced with 8235741. > > Thanks > Christoph > From rkennke at redhat.com Fri Feb 7 12:28:52 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 7 Feb 2020 13:28:52 +0100 Subject: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u In-Reply-To: References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <85327ce1-2336-8950-871e-ac0af1856701@redhat.com> Message-ID: Hi Gil, Find my replies to your questions inline, below: > As this is proposing a pretty significant backport of an experimental > feature > that is?in-development?in upstream versions, can you comment on how you > expect it to progress and evolve after initial integration into the stable,? > in-maintenance-mode 11u? > > E.g. here are some specifics: > > - Do you expect that the 11u implementation will start diverging from > the upstream > path and start following a separate path towards a non-experimental > form? Or will it > closely match the upstream progress and changes, moving to non-experimental > form only when an upstream version includes a non-experimental version? We intend to keep our current development practice around Shenandoah: keep the Shenandoah codebase synced across the 8u, 11u, and latest dev, as much as reasonably possible. Our experience with doing this for years already shows that the vast majority of the changes touch Shenandoah code only, and do not require changing any shared code. In the cases it did require changes in shared code, we erred on the side of caution, and either reworked (diverged from Shenandoah dev) to limit 8u/11u exposure, or made sure the changes are protected by UseShenandoahGC. That is a hard rule for our downstream repositories, and we intend to follow it in upstream as well. Since codebases are more or less in sync, we think it would become non-experimental pretty much when upstream becomes non-experimental. > - Do you expect to advocate for porting of bug fixes only, or also of > features and > improvements from upstream versions? [In my terminology, a bug fix is > something > like "no longer crashes when X happens", an improvement is something > like ?"runs > twice as fast" or "has generational collection", and a feature is > something like e.g. > "can be configured with new flag X to proactively adjust heap size over > time". > E.g. if the redesign from Shenandoah 1.0 to Shenandoah 2.0 had happened > after > this?initial backport was integrated, would you later be advocating for > a backport of > the redesign to 11u? Until now, we backported everything, including new features, as long as we can do so without touching shared code. But there are large items that require lots of fiddling with shared code. Two prominent examples are: a) concurrent class unloading in jdk14, which requires a lot of VM infrastructure to support; b) loop strip mining in jdk11, which required significant work in C2. Both are deemed too risky to backport to previous releases. The LRB rework was special. While it required a massive amount of shared code changes (in our shenandoah/jdk11 tree), most of them reduced overall shared code exposure. The patch we have presented for integration to 11u already includes it, and this is indeed why the shared code exposure is quite low. There is a technical advantage of backporting most of the stuff: the backporting process is simplified. The vast majority of Shenandoah dev -> 11u backports applies cleanly and requires minimum review and retesting. > - If it is more than just bug fixes that you propose tracking, then for > how long??e.g. > once 17u comes out in Sep. 2021 (19 months from now), will you advocate that > new Shenandoah?improvements or features being worked on in OpenJDK 18u > be backported top 11u??Or will there be some sunset where we say "11 has > what > 11 has, if you want new?improvements?and features, move to new version X"? See above, it is judged on ad-hoc basis. If it can be done without touching shared code, then we'd probably backport it to 11u after reasonable baking time in upstream. > - Would you advocate for backporting from upstream versions to all > intermediate > versions? e.g. from a 16EA ?to 15.0.2 in Jan 2021, or to an 13.0.6 if > one was still > being built?, or just to 11u?? We have not made a firm decision regarding intermediate versions. Our soft policy is to backport critical issues to STS releases, so that users would get them earlier than next STS releases. Then we basically relied on 6-month switchover to the new STS. If any STS continues to deliver releases after next STS is available, we can indeed consider extending that soft policy to "previous" STS releases. But the priority for that work would be rather low. > - Do you expect to start backporting other upstream features or > redesigns aimed at > supporting the maturation of Shenandoah in 11u, but that would not be > needed in 11u > for other reasons? The example of > https://bugs.openjdk.java.net/browse/JDK-8230565 > comes to mind, as I expect the new LRB might be similarly susceptible to C2 > scheduling load barriers across safepoints, and may need a similar > redesign of > the C2 load barrier in order to stabilize an LRB-based Shenandoah > implementation. > Would you advocate for such a redesign to be backported into the stable > 11u C2 > as well? Would it make sense to introduce the Shenandoah backport if we > do not > intend to later follow through with such supporting (but wider impacting > on 11u) items? Since the primary mandate for LTS releases is to avoid destabilizing changes, any problem with it would have to be band-aided in one way or the other. It is not very different from discovering the bugs after the initial integration to 11u: since that is LTS version, you do what you can to make it work. Re: JDK-8230565, we do not intend to either use or backport it, as our C2 barriers work differently. > - Do you expect that the initial backport, or it's later evolution, will > require changes > to critical shared code components in 11u that would not be needed > otherwise in > 11u, and are not yet included in e.g. any upstream LTS version? E.g. > your suggetions > for https://bugs.openjdk.java.net/browse/JDK-8209686 seems like a > reasonable and > not-too-big change, but one that 11u has no need for and would likely > not bring in to > C2 for any other reason. How to we choose if and when to add such things > to the > stable, in-maintenance-mode 11u (and risk destabilizing its core > functionality > inadvertently)? JDK-8209686 was a preparatory change. It was pretty much contained in the big Shenandoah patch, and I thought it makes sense to review and push that part separately. It follows the established practice in JDK Updates Project: if we can, we backport simple stuff that makes subsequent backports much cleaner. Best regards, Roman > ? Gil. > >> On Feb 6, 2020, at 11:43 AM, Roman Kennke > > wrote: >> >> Hello all, >> >> This is an update on the proposed patch. >> >> - It is rebased on latest jdk11u-dev, and in particular on the >> backport of: >> https://bugs.openjdk.java.net/browse/JDK-8209686 >> >> ... which considerably improves C2 shared-code-changes. >> >> - Includes the latest bunch of Shenandoah/jdk11u backports by Aleksey: >> https://mail.openjdk.java.net/pipermail/shenandoah-dev/2020-February/011417.html >> >> Full webrev: >> http://cr.openjdk.java.net/~rkennke/shenandoah-jdk11u-upstream/webrev.03-all/ >> >> Shared-code webrev: >> http://cr.openjdk.java.net/~rkennke/shenandoah-jdk11u-upstream/webrev.03-shared/ >> >> Please review/test that instead of the previous patches. >> >> Thanks, >> Roman >> >>> Hello, >>> >>> The Shenandoah GC has been integrated into jdk12 a little over a year >>> ago: >>> >>> http://hg.openjdk.java.net/jdk/jdk/rev/9c18c9d839d3 >>> >>> The Shenandoah team has been maintaining the Shenandoah-enabled jdk11u >>> downstream repository since the inception of jdk11 under: >>> >>> http://hg.openjdk.java.net/shenandoah/jdk11 >>> >>> In order to make it more useful and accessible for users, we would like >>> to make it available in upstream jdk11u. The Shenandoah team at Red Hat >>> intends to maintain it the same way it had been maintained in >>> shenandoah/jdk11, in the course of regular jdk11u maintenance Red Hat >>> already does. >>> >>> Thanks to recent changes in Shenandoah over the last year, we are now >>> able to fit the GC interface in jdk11 almost exactly. There are a few >>> exceptions though. We tried to follow the following pattern for all >>> shared-code changes where it made sense: >>> >>> #if INCLUDE_SHENANDOAH_GC >>> ?if (UseShenandoahGC) { >>> ???... >>> ?} >>> #endif >>> >>> This ensures that the Shenandoah-specific changes are cut out of the >>> build when building without Shenandoah, and avoid those code paths at >>> runtime when running without Shenandoah. >>> >>> Also, there are a few places where this was not possible or where it >>> didn't seem feasible, but we tried to keep them few and obvious. >>> Whenever this is the case, we are mirroring as close as possible what we >>> have in jdk/jdk. >>> >>> Architecture-wise, Shenandoah runs on x86_64, aarch64, x86_32. Other >>> architectures still build fine, and Shenandoah gets automatically >>> disabled during configure if not supported. OS-wise, Shenandoah runs on >>> Linux, Windows, and is known to run on MacOS X and Solaris too. >>> >>> I wasn't sure which form this should take. I decided to start with the >>> easiest possible form this could take: a simple patch/webrev and an RFR. >>> Let me know if you need a JIRA issue or any other formalities to >>> track that. >>> >>> Full webrev: >>> https://cr.openjdk.java.net/~rkennke/shenandoah-jdk11u-upstream/webrev.02-all/ >>> >>> Webrev only for shared-code changes: >>> https://cr.openjdk.java.net/~rkennke/shenandoah-jdk11u-upstream/webrev.02-shared/ >>> >>> The webrevs are based on and depend on the arraycopy patch proposed for >>> review here: >>> >>> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-January/002396.html >>> >>> Testing: >>> The code has been tested many many times, continuously while maintaining >>> it. It has also served as the basis for RPMs and shipped to customers. >>> We are running all sorts of tests of the hotspot/jtreg testsuite, in >>> particular hotspot_gc_shenandoah, CTW tests, the regular tier* tests, >>> several popular benchmarks (specjvm, specjbb on a regular basis), on a >>> nightly basis. >>> >>> Please let me know what you think. >>> >>> Thanks, >>> Roman >>> >>> >>> >>> >>> >>> >>> > From christoph.langer at sap.com Fri Feb 7 12:46:38 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 7 Feb 2020 12:46:38 +0000 Subject: RFR(14u): 8237375: SimpleThresholdPolicy misses CounterDecay timestamp initialization In-Reply-To: References: Message-ID: Hi Volker, thanks for having a look here. > Looks good except that I'd rather use: > > + return ((os::javaTimeNanos() - _last_timestamp) / > NANOUNITS_PER_MILLIUNIT) > CounterDecayMinIntervalLength; > > instead of: > > + return ((os::javaTimeNanos() - _last_timestamp) / NANOUNITS * > MILLIUNITS) > CounterDecayMinIntervalLength; > > because it looks clearer (and is exactly what nanos_to_millis() also does). You're right and I would have done that - but unfortunately NANOUNITS_PER_MILLIUNIT was only introduced with 8235741 and I don't want to pull this into my backport here. So, is the change for 11u also ok? Thanks Christoph From gil at azul.com Fri Feb 7 16:19:53 2020 From: gil at azul.com (Gil Tene) Date: Fri, 7 Feb 2020 16:19:53 +0000 Subject: Backporting features [was Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u] In-Reply-To: References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <85327ce1-2336-8950-871e-ac0af1856701@redhat.com> Message-ID: <212BBD26-93B9-46FD-A36E-1E4ED4319D18@azul.com> I think this is a discussion about the core of what an OpenJDK XXu update project is intended to do and produce, and what it's primary directives are. Let explain my opinion on the subject. Others' opinion will likely differ. As I see it, the overriding purpose of an OpenJDK XXu project is to stabilize and maintain the associated Java SE release implementation as it is, with no intent to add any improvements or features. It is about applying bug fixes and security updates to a given OpenJDK Java version, in order to keep it's current use rock solid. It is not about "making it even better:". The place to make things "even better" is in upstream versions. We have one of those leaving the station every 6 months, with an LTS every three years, and those provide plenty of opportunities to bring better-ness to the community. While it may be tempting to try to improve things under the hood (e.g. by making stuff faster, smaller, or better on some metric) or in visible ways (e.g. by adding options, features, etc.) in stable or in just-now-released versions, doing so will inherently risk the stability of the existing version, and put the main purpose of the updates project at risk. The cut off date for adding new things is (IMO) the XX.0.0 version. After that the only things we bring in should be bug fixes and security updates, unless a VERY high bar can be crossed. That bar is, IMO, "something is missing" in the release. The only two examples that I have seen rise above that bar so far are: 1. TLS 1.3 work: with the Java SE 8 spec updated via a maintenance release with the specific intent of enabling support for TLS1.3 and ALPN in Java SE 8, and with Oracle making it clear that they intend to update Oracle Java 8 to include such support, I think that updating OpenJDK 8u accordingly with new features is appropriate. It is a risky thing, but not one we have a real option of avoiding. If we do not update OpenJDK 8u, it will be missing TLS 1.3 support. 2. JFR: As Oracle Java 8 JDKs have included JFR capability from the very start of JDK 8. This capability was available to Java 8 developers in the free Oracle JDK downloads from March 2014 until April 2019, and many users have grown fond of using it in the field. The lack of JFR in OpenJDK 8 was "a missing feature" and was something people "lost" when moving from Oracle JDK 8 to OpenJDK 8. The inclusion of JFR sources in upstream OpenJDK 11 presented us with the opportunity to finally include that missing feature to OpenJDK 8u. For things that do not rise above the ""something is missing" bar in the main updates project, curation choices about back-porting or adding features and improvements to older versions can (and should) still be independently made in downstream distributions and projects (e.g. Zulu, Corretto , DragonWell RedHat's OpenJDK builds, Liberica, AOJ, and even Zing are all examples of downstream distros that make such choices every day, and so do e.g. shenandoah/jdk11). A choice to do that comes with the burden of maintainine the difference over time and on an ongoing bases, and accepting the risk of destabilization and additional complexity of backports that this may add. It is a choice made independently by the group maintaining the specific downstream distribution. It does not (and should not) affect the common OpenJDK XXu project, or other downstream distributions that do not wish to take on the same risks and burdens. If we had a "HotSpot express" development model upstream (or even in or across updates projects), I would view this quite differently. That model (which was attempted for a short sliver of time in OpenJDK [1] but to my disappointment did not stick) was meant to address the exact need here, and would have allowed us to bring new HotSpot features (that do not affect the Java SE spec or version) to older Java SE releases on a regular basis, such that e.g. improvements in JITs, GCs, runtime features, platform support, and [jvm] bugfixes would flow to all actively maintained versions. But we are not running with such a model, and the current one clearly calls for code to be fixed but not improved once an OpenJDK version has been released. In this specific case, I see a clear and default path within OpenJDK: Focus on stabilizing Shenandoah 2.0 in 15u & 16u to the point where it is no longer an experimental feature. Getting it into 17u LTS (a mere 19 months from now) will be a much more important and useful achievement then backporting it into 11u in an experimental state. [1] http://mail.openjdk.java.net/pipermail/jdk7u-dev/2011-August/000160.html ? Gil. > On Feb 7, 2020, at 4:28 AM, Roman Kennke wrote: > > Hi Gil, > > Find my replies to your questions inline, below: > >> As this is proposing a pretty significant backport of an experimental >> feature >> that is in-development in upstream versions, can you comment on how you >> expect it to progress and evolve after initial integration into the stable, >> in-maintenance-mode 11u? >> >> E.g. here are some specifics: >> >> - Do you expect that the 11u implementation will start diverging from >> the upstream >> path and start following a separate path towards a non-experimental >> form? Or will it >> closely match the upstream progress and changes, moving to non-experimental >> form only when an upstream version includes a non-experimental version? > > We intend to keep our current development practice around Shenandoah: > keep the Shenandoah codebase synced across the 8u, 11u, and latest dev, > as much as reasonably possible. Our experience with doing this for years > already shows that the vast majority of the changes touch Shenandoah > code only, and do not require changing any shared code. In the cases it > did require changes in shared code, we erred on the side of caution, and > either reworked (diverged from Shenandoah dev) to limit 8u/11u exposure, > or made sure the changes are protected by UseShenandoahGC. That is a > hard rule for our downstream repositories, and we intend to follow it in > upstream as well. > > Since codebases are more or less in sync, we think it would become > non-experimental pretty much when upstream becomes non-experimental. > >> - Do you expect to advocate for porting of bug fixes only, or also of >> features and >> improvements from upstream versions? [In my terminology, a bug fix is >> something >> like "no longer crashes when X happens", an improvement is something >> like "runs >> twice as fast" or "has generational collection", and a feature is >> something like e.g. >> "can be configured with new flag X to proactively adjust heap size over >> time". >> E.g. if the redesign from Shenandoah 1.0 to Shenandoah 2.0 had happened >> after >> this initial backport was integrated, would you later be advocating for >> a backport of >> the redesign to 11u? > > Until now, we backported everything, including new features, as long as > we can do so without touching shared code. But there are large items > that require lots of fiddling with shared code. Two prominent examples > are: a) concurrent class unloading in jdk14, which requires a lot of VM > infrastructure to support; b) loop strip mining in jdk11, which required > significant work in C2. Both are deemed too risky to backport to > previous releases. > > The LRB rework was special. While it required a massive amount of shared > code changes (in our shenandoah/jdk11 tree), most of them reduced > overall shared code exposure. The patch we have presented for > integration to 11u already includes it, and this is indeed why the > shared code exposure is quite low. > > There is a technical advantage of backporting most of the stuff: the > backporting process is simplified. The vast majority of Shenandoah dev > -> 11u backports applies cleanly and requires minimum review and retesting. > >> - If it is more than just bug fixes that you propose tracking, then for >> how long? e.g. >> once 17u comes out in Sep. 2021 (19 months from now), will you advocate that >> new Shenandoah improvements or features being worked on in OpenJDK 18u >> be backported top 11u? Or will there be some sunset where we say "11 has >> what >> 11 has, if you want new improvements and features, move to new version X"? > > See above, it is judged on ad-hoc basis. If it can be done without > touching shared code, then we'd probably backport it to 11u after > reasonable baking time in upstream. > >> - Would you advocate for backporting from upstream versions to all >> intermediate >> versions? e.g. from a 16EA to 15.0.2 in Jan 2021, or to an 13.0.6 if >> one was still >> being built?, or just to 11u? > > We have not made a firm decision regarding intermediate versions. Our > soft policy is to backport critical issues to STS releases, so that > users would get them earlier than next STS releases. Then we basically > relied on 6-month switchover to the new STS. If any STS continues to > deliver releases after next STS is available, we can indeed consider > extending that soft policy to "previous" STS releases. But the priority > for that work would be rather low. > >> - Do you expect to start backporting other upstream features or >> redesigns aimed at >> supporting the maturation of Shenandoah in 11u, but that would not be >> needed in 11u >> for other reasons? The example of >> https://bugs.openjdk.java.net/browse/JDK-8230565 >> comes to mind, as I expect the new LRB might be similarly susceptible to C2 >> scheduling load barriers across safepoints, and may need a similar >> redesign of >> the C2 load barrier in order to stabilize an LRB-based Shenandoah >> implementation. >> Would you advocate for such a redesign to be backported into the stable >> 11u C2 >> as well? Would it make sense to introduce the Shenandoah backport if we >> do not >> intend to later follow through with such supporting (but wider impacting >> on 11u) items? > > Since the primary mandate for LTS releases is to avoid destabilizing > changes, any problem with it would have to be band-aided in one way or > the other. It is not very different from discovering the bugs after the > initial integration to 11u: since that is LTS version, you do what you > can to make it work. Re: JDK-8230565, we do not intend to either use or > backport it, as our C2 barriers work differently. > >> - Do you expect that the initial backport, or it's later evolution, will >> require changes >> to critical shared code components in 11u that would not be needed >> otherwise in >> 11u, and are not yet included in e.g. any upstream LTS version? E.g. >> your suggetions >> for https://bugs.openjdk.java.net/browse/JDK-8209686 seems like a >> reasonable and >> not-too-big change, but one that 11u has no need for and would likely >> not bring in to >> C2 for any other reason. How to we choose if and when to add such things >> to the >> stable, in-maintenance-mode 11u (and risk destabilizing its core >> functionality >> inadvertently)? > > JDK-8209686 was a preparatory change. It was pretty much contained in > the big Shenandoah patch, and I thought it makes sense to review and > push that part separately. It follows the established practice in JDK > Updates Project: if we can, we backport simple stuff that makes > subsequent backports much cleaner. > > Best regards, > Roman > >> ? Gil. >> >>> On Feb 6, 2020, at 11:43 AM, Roman Kennke >> > wrote: >>> >>> Hello all, >>> >>> This is an update on the proposed patch. >>> >>> - It is rebased on latest jdk11u-dev, and in particular on the >>> backport of: >>> https://bugs.openjdk.java.net/browse/JDK-8209686 >>> >>> ... which considerably improves C2 shared-code-changes. >>> >>> - Includes the latest bunch of Shenandoah/jdk11u backports by Aleksey: >>> https://mail.openjdk.java.net/pipermail/shenandoah-dev/2020-February/011417.html >>> >>> Full webrev: >>> http://cr.openjdk.java.net/~rkennke/shenandoah-jdk11u-upstream/webrev.03-all/ >>> >>> Shared-code webrev: >>> http://cr.openjdk.java.net/~rkennke/shenandoah-jdk11u-upstream/webrev.03-shared/ >>> >>> Please review/test that instead of the previous patches. >>> >>> Thanks, >>> Roman >>> >>>> Hello, >>>> >>>> The Shenandoah GC has been integrated into jdk12 a little over a year >>>> ago: >>>> >>>> http://hg.openjdk.java.net/jdk/jdk/rev/9c18c9d839d3 >>>> >>>> The Shenandoah team has been maintaining the Shenandoah-enabled jdk11u >>>> downstream repository since the inception of jdk11 under: >>>> >>>> http://hg.openjdk.java.net/shenandoah/jdk11 >>>> >>>> In order to make it more useful and accessible for users, we would like >>>> to make it available in upstream jdk11u. The Shenandoah team at Red Hat >>>> intends to maintain it the same way it had been maintained in >>>> shenandoah/jdk11, in the course of regular jdk11u maintenance Red Hat >>>> already does. >>>> >>>> Thanks to recent changes in Shenandoah over the last year, we are now >>>> able to fit the GC interface in jdk11 almost exactly. There are a few >>>> exceptions though. We tried to follow the following pattern for all >>>> shared-code changes where it made sense: >>>> >>>> #if INCLUDE_SHENANDOAH_GC >>>> if (UseShenandoahGC) { >>>> ... >>>> } >>>> #endif >>>> >>>> This ensures that the Shenandoah-specific changes are cut out of the >>>> build when building without Shenandoah, and avoid those code paths at >>>> runtime when running without Shenandoah. >>>> >>>> Also, there are a few places where this was not possible or where it >>>> didn't seem feasible, but we tried to keep them few and obvious. >>>> Whenever this is the case, we are mirroring as close as possible what we >>>> have in jdk/jdk. >>>> >>>> Architecture-wise, Shenandoah runs on x86_64, aarch64, x86_32. Other >>>> architectures still build fine, and Shenandoah gets automatically >>>> disabled during configure if not supported. OS-wise, Shenandoah runs on >>>> Linux, Windows, and is known to run on MacOS X and Solaris too. >>>> >>>> I wasn't sure which form this should take. I decided to start with the >>>> easiest possible form this could take: a simple patch/webrev and an RFR. >>>> Let me know if you need a JIRA issue or any other formalities to >>>> track that. >>>> >>>> Full webrev: >>>> https://cr.openjdk.java.net/~rkennke/shenandoah-jdk11u-upstream/webrev.02-all/ >>>> >>>> Webrev only for shared-code changes: >>>> https://cr.openjdk.java.net/~rkennke/shenandoah-jdk11u-upstream/webrev.02-shared/ >>>> >>>> The webrevs are based on and depend on the arraycopy patch proposed for >>>> review here: >>>> >>>> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-January/002396.html >>>> >>>> Testing: >>>> The code has been tested many many times, continuously while maintaining >>>> it. It has also served as the basis for RPMs and shipped to customers. >>>> We are running all sorts of tests of the hotspot/jtreg testsuite, in >>>> particular hotspot_gc_shenandoah, CTW tests, the regular tier* tests, >>>> several popular benchmarks (specjvm, specjbb on a regular basis), on a >>>> nightly basis. >>>> >>>> Please let me know what you think. >>>> >>>> Thanks, >>>> Roman >>>> >>>> >>>> >>>> >>>> >>>> >>>> >> > From aph at redhat.com Fri Feb 7 18:13:51 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 7 Feb 2020 18:13:51 +0000 Subject: Backporting features [was Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u] In-Reply-To: <212BBD26-93B9-46FD-A36E-1E4ED4319D18@azul.com> References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <85327ce1-2336-8950-871e-ac0af1856701@redhat.com> <212BBD26-93B9-46FD-A36E-1E4ED4319D18@azul.com> Message-ID: First, let me state that in this discussion I am doing my best to ensure that I am not biased by my job at Red Hat: despite my signature below, I am writing as the JDK 11 Updates maintainer. I will try to remain neutral and act in the best interests of the project, as I hope will everyone else in this discussion. On 2/7/20 4:19 PM, Gil Tene wrote: > I think this is a discussion about the core of what an OpenJDK XXu update > project is intended to do and produce, and what it's primary directives are. > > Let explain my opinion on the subject. Others' opinion will likely differ. Probably. > As I see it, the overriding purpose of an OpenJDK XXu project is to > stabilize and maintain the associated Java SE release implementation > as it is, with no intent to add any improvements or features. It is > about applying bug fixes and security updates to a given OpenJDK > Java version, in order to keep it's current use rock solid. It is > not about "making it even better:". The place to make things "even > better" is in upstream versions. We have one of those leaving the > station every 6 months, with an LTS every three years, and those > provide plenty of opportunities to bring better-ness to the > community. Well, yes, kinda sorta: we must not be foolhardy, because the safety of our users and the reputation of OpenJDK is at stake. However, OpenJDK is free software, so another issue at stake is freedom: we want people to have a choice. Therefore, we should ensure, as much as we can, that our users are not forced into the arms of proprietary software vendors because of features lacking in equivalent OpenJDK releases. > While it may be tempting to try to improve things under the hood > (e.g. by making stuff faster, smaller, or better on some metric) or > in visible ways (e.g. by adding options, features, etc.) in stable > or in just-now-released versions, doing so will inherently risk the > stability of the existing version, and put the main purpose of the > updates project at risk. I understand. However, if we can determine that a feature backport is a. Desired by a number of downstream distributors (and their users), and b. Sufficiently guarded by flags (e.g. #ifdef) that we can determine statically that a feature has no effect if not enabled/configured ... I believe we will not be taking undue risks. Downstream distributors can take the decision to enable features or not. You might argue that even when not configured there is some slight risk, but surely a risk has to be plausible, not just theoretically possible. > For things that do not rise above the ""something is missing" bar in > the main updates project, curation choices about back-porting or > adding features and improvements to older versions can (and should) > still be independently made in downstream distributions and projects > (e.g. Zulu, Corretto , DragonWell RedHat's OpenJDK builds, Liberica, > AOJ, and even Zing are all examples of downstream distros that make > such choices every day, and so do e.g. shenandoah/jdk11). Certainly, this happens. However, we are at some risk of Balkanization of JDK 11 distributions, with downstream vendors independently packaging extensions. This is a Bad Thing and a waste of effort. If we can share resources without risking our users' stability then everyone benefits. > In this specific case, I see a clear and default path within > OpenJDK: Focus on stabilizing Shenandoah 2.0 in 15u & 16u to the > point where it is no longer an experimental feature. Getting it into > 17u LTS (a mere 19 months from now) will be a much more important > and useful achievement then backporting it into 11u in an > experimental state. Here, I think you may have a point: there is a question about whether experimental features should be back-ported. However, there are already experimental features in JDK 11, so it's not as if they're completely verboten in LTS releases. We should decide on the actual demand (the benefit) versus the actual intrusiveness (the cost) rather than in-principle arguments which may have more to do with theology than engineering. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Sun Feb 9 21:44:41 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Sun, 9 Feb 2020 21:44:41 +0000 Subject: [11u]: RFR: 8238225: Issues reported after replacing symlink at Contents/MacOS/libjli.dylib with binary Message-ID: Hi, the fix for "8235687: Contents/MacOS/libjli.dylib cannot be a symlink" [0], which had been backported to 11.0.6, has introduced an issue for custom launchers that try to start a JVM from a MacOS bundle. This has been fixed and we should take this fix back to 11u as well. Please help to review: Bug: https://bugs.openjdk.java.net/browse/JDK-8238225 Original Patch: https://hg.openjdk.java.net/jdk/jdk/rev/023df178388e Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8238225.11u/ The actual fix in src/java.base/macosx/native/libjli/java_md_macosx.c is quite straightforward, except that the file was renamed to src/java.base/macosx/native/libjli/java_md_macosx.m in head revision which caused the need for a little reshuffling. However, I also wanted to take the test along which didn't exist yet in jdk11u, so I had to borrow parts from JDK-8213362 [1], which introduced the test and subsequent changes JDK-8215000 [2] and JDK-8216265 [3]. These changes however don't qualify for a full backport, so I decided for carveouts. I also had to account for the fact that in 11u libjli is located in subfolder lib/jli for non-windows platforms, so I made a few additional modifications in make/test/JtregNativeJdk.gmk and test/jdk/tools/launcher/JliLaunchTest.java. Thanks Christoph [0] https://bugs.openjdk.java.net/browse/JDK-8235687 [1] https://bugs.openjdk.java.net/browse/JDK-8213362 [2] https://bugs.openjdk.java.net/browse/JDK-8215000 [3] https://bugs.openjdk.java.net/browse/JDK-8216265 From christoph.langer at sap.com Sun Feb 9 22:04:41 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Sun, 9 Feb 2020 22:04:41 +0000 Subject: [11u] RFR: Backport of JDK-8230400: Missing constant pool entry for a method in stacktrace In-Reply-To: <27dcd62c-9cc9-433a-b269-7c86e0ea2f2a.denghui.ddh@alibaba-inc.com> References: <27dcd62c-9cc9-433a-b269-7c86e0ea2f2a.denghui.ddh@alibaba-inc.com> Message-ID: Hi Denghui, I looked at your backport and it seems correct to me. If you want, I can run it through our testing and then sponsor it for you. Please let me know. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Denghui Dong > Sent: Montag, 3. Februar 2020 13:49 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: Backport of JDK-8230400: Missing constant pool entry for > a method in stacktrace > > Hi team, > Please review this backport, original patch doesn't apply cleanly, because: > - some different code structures, such as the different name of JfrStump in > jfrTypeSetUtils.hpp > - JDK-8209301 (JVM rename is_anonymous, host_klass to unsafe specific > terminology ahead of Unsafe.defineAnonymousClass deprecation) has not > been ported to 11u, and I think it's not necessary. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8230400 > Original change: https://hg.openjdk.java.net/jdk/jdk/rev/31ec3e55fa3d > Webrev: http://cr.openjdk.java.net/~ddong/8230400/ > > Thanks, > Denghui Dong From christoph.langer at sap.com Sun Feb 9 22:17:05 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Sun, 9 Feb 2020 22:17:05 +0000 Subject: [11u] RFR: 8216472: (se) Stack overflow during selection operation leads to crash (win) In-Reply-To: References: Message-ID: Hi Alex, I think this looks good for 11u. Best regards Christoph > -----Original Message----- > From: nio-dev On Behalf Of Alex > Kashchenko > Sent: Freitag, 24. Januar 2020 12:00 > To: jdk-updates-dev at openjdk.java.net > Cc: nio-dev at openjdk.java.net > Subject: [11u] RFR: 8216472: (se) Stack overflow during selection operation > leads to crash (win) > > Hi, > > Please review the backport of JDK-8216472 to 11u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8216472 > > Original review thread: > https://mail.openjdk.java.net/pipermail/nio-dev/2019-October/006684.html > > Original review thread (continuation): > https://mail.openjdk.java.net/pipermail/nio-dev/2019- > November/006777.html > > Original change: https://hg.openjdk.java.net/jdk/jdk/rev/6bc29ebe053e > > 11u webrev: > http://cr.openjdk.java.net/~akasko/jdk11u/8216472/webrev.00/ > > Please note, that original change, besides moving structs off the stack, > additionally removes the logic for the case, when select() call returns > SOCKET_ERROR: > > - starting here: > https://hg.openjdk.java.net/jdk/jdk/rev/6bc29ebe053e#l2.58 > - explanation (point 1 there): > https://mail.openjdk.java.net/pipermail/nio-dev/2019-October/006708.html > > To stay on the safe side with LTS versions, this 11u backport keeps > select() failure logic intact and allocates the space for 6 fd_set > structs (instead of 3 in original change). It is proposed to have the > change added to 11u in this "fix only" form. And, if necessary, to > remove select() failure logic in a follow-up change. > > Testing: 11u change in this form was included with Red Hat > 11.0.6-windows release and passed usual release testing. > > -- > -Alex From denghui.ddh at alibaba-inc.com Mon Feb 10 00:38:21 2020 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Mon, 10 Feb 2020 08:38:21 +0800 Subject: =?UTF-8?B?5Zue5aSN77yaIFsxMXVdIFJGUjogQmFja3BvcnQgb2YgSkRLLTgyMzA0MDA6IE1pc3Npbmcg?= =?UTF-8?B?Y29uc3RhbnQgcG9vbCBlbnRyeSBmb3IgYSBtZXRob2QgaW4gc3RhY2t0cmFjZQ==?= In-Reply-To: References: <27dcd62c-9cc9-433a-b269-7c86e0ea2f2a.denghui.ddh@alibaba-inc.com>, Message-ID: <9dcd1feb-464d-4f78-b82d-d3f52808d23a.denghui.ddh@alibaba-inc.com> Yes, please help me. ??????????------------------------------------------------------------------ ????Langer, Christoph ????2020?02?10? 06:04:41 ????Denghui Dong; jdk-updates-dev at openjdk.java.net ????RE: [11u] RFR: Backport of JDK-8230400: Missing constant pool entry for a method in stacktrace Hi Denghui, I looked at your backport and it seems correct to me. If you want, I can run it through our testing and then sponsor it for you. Please let me know. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Denghui Dong > Sent: Montag, 3. Februar 2020 13:49 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: Backport of JDK-8230400: Missing constant pool entry for > a method in stacktrace > > Hi team, > Please review this backport, original patch doesn't apply cleanly, because: > - some different code structures, such as the different name of JfrStump in > jfrTypeSetUtils.hpp > - JDK-8209301 (JVM rename is_anonymous, host_klass to unsafe specific > terminology ahead of Unsafe.defineAnonymousClass deprecation) has not > been ported to 11u, and I think it's not necessary. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8230400 > Original change: https://hg.openjdk.java.net/jdk/jdk/rev/31ec3e55fa3d > Webrev: http://cr.openjdk.java.net/~ddong/8230400/ > > Thanks, > Denghui Dong From christoph.langer at sap.com Mon Feb 10 07:13:09 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 10 Feb 2020 07:13:09 +0000 Subject: =?utf-8?B?UkU6IOWbnuWkje+8miBbMTF1XSBSRlI6IEJhY2twb3J0IG9mIEpESy04MjMw?= =?utf-8?B?NDAwOiBNaXNzaW5nIGNvbnN0YW50IHBvb2wgZW50cnkgZm9yIGEgbWV0aG9k?= =?utf-8?Q?_in_stacktrace?= In-Reply-To: <9dcd1feb-464d-4f78-b82d-d3f52808d23a.denghui.ddh@alibaba-inc.com> References: <27dcd62c-9cc9-433a-b269-7c86e0ea2f2a.denghui.ddh@alibaba-inc.com>, <9dcd1feb-464d-4f78-b82d-d3f52808d23a.denghui.ddh@alibaba-inc.com> Message-ID: Ok, I?ll run the patch through our testing. If no regressions occur, I?ll approve and push it later this week. Cheers Christoph From: Denghui Dong Sent: Montag, 10. Februar 2020 01:38 To: Langer, Christoph ; jdk-updates-dev at openjdk.java.net Subject: ??? [11u] RFR: Backport of JDK-8230400: Missing constant pool entry for a method in stacktrace Yes, please help me. ??????????<(null)> ------------------------------------------------------------------ ????Langer, Christoph> ????2020?02?10? 06:04:41 ????Denghui Dong>; jdk-updates-dev at openjdk.java.net> ????RE: [11u] RFR: Backport of JDK-8230400: Missing constant pool entry for a method in stacktrace Hi Denghui, I looked at your backport and it seems correct to me. If you want, I can run it through our testing and then sponsor it for you. Please let me know. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev > On > Behalf Of Denghui Dong > Sent: Montag, 3. Februar 2020 13:49 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: Backport of JDK-8230400: Missing constant pool entry for > a method in stacktrace > > Hi team, > Please review this backport, original patch doesn't apply cleanly, because: > - some different code structures, such as the different name of JfrStump in > jfrTypeSetUtils.hpp > - JDK-8209301 (JVM rename is_anonymous, host_klass to unsafe specific > terminology ahead of Unsafe.defineAnonymousClass deprecation) has not > been ported to 11u, and I think it's not necessary. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8230400 > Original change: https://hg.openjdk.java.net/jdk/jdk/rev/31ec3e55fa3d > Webrev: http://cr.openjdk.java.net/~ddong/8230400/ > > Thanks, > Denghui Dong From christoph.langer at sap.com Mon Feb 10 07:15:40 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 10 Feb 2020 07:15:40 +0000 Subject: [11u]: 8213906: Update arm devkits with libXrandr headers Message-ID: Hi, please review this tiny backport changeset: Bug: https://bugs.openjdk.java.net/browse/JDK-8213906 Original change: http://hg.openjdk.java.net/jdk/jdk/rev/a41566ad8756 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213906.11u/ It's one of these parity changes. The change didn't apply so I tried to resolve it manually. Thanks Christoph From christoph.langer at sap.com Mon Feb 10 07:31:05 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 10 Feb 2020 07:31:05 +0000 Subject: [11u] RFR: 8226381: ProblemList java/lang/reflect/PublicMethods/PublicMethodsTest.java Message-ID: Hi, please review the next small Oracle parity backport: Bug: https://bugs.openjdk.java.net/browse/JDK-8226381 Original change: http://hg.openjdk.java.net/jdk/jdk/rev/3dcfa209f769 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8226381.11u/ The problem here is that test/jdk/ProblemList-aot.txt doesn't exist in 11u so far. The change that created it, hasn't been backported, so I have to create test/jdk/ProblemList-aot.txt with this backport. Thanks Christoph From akashche at redhat.com Mon Feb 10 07:59:15 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Mon, 10 Feb 2020 07:59:15 +0000 Subject: [11u] RFR: 8216472: (se) Stack overflow during selection operation leads to crash (win) In-Reply-To: References: Message-ID: <0ecd82f5-3a3b-a46e-c80d-fe89eec95f30@redhat.com> Hi Christoph, On 02/09/2020 10:17 PM, Langer, Christoph wrote: > Hi Alex, > > I think this looks good for 11u. Thanks for the review! I've added 11u fix request to the issue. > > Best regards > Christoph > >> -----Original Message----- >> From: nio-dev On Behalf Of Alex >> Kashchenko >> Sent: Freitag, 24. Januar 2020 12:00 >> To: jdk-updates-dev at openjdk.java.net >> Cc: nio-dev at openjdk.java.net >> Subject: [11u] RFR: 8216472: (se) Stack overflow during selection operation >> leads to crash (win) >> >> Hi, >> >> Please review the backport of JDK-8216472 to 11u: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8216472 >> >> Original review thread: >> https://mail.openjdk.java.net/pipermail/nio-dev/2019-October/006684.html >> >> Original review thread (continuation): >> https://mail.openjdk.java.net/pipermail/nio-dev/2019- >> November/006777.html >> >> Original change: https://hg.openjdk.java.net/jdk/jdk/rev/6bc29ebe053e >> >> 11u webrev: >> http://cr.openjdk.java.net/~akasko/jdk11u/8216472/webrev.00/ >> >> Please note, that original change, besides moving structs off the stack, >> additionally removes the logic for the case, when select() call returns >> SOCKET_ERROR: >> >> - starting here: >> https://hg.openjdk.java.net/jdk/jdk/rev/6bc29ebe053e#l2.58 >> - explanation (point 1 there): >> https://mail.openjdk.java.net/pipermail/nio-dev/2019-October/006708.html >> >> To stay on the safe side with LTS versions, this 11u backport keeps >> select() failure logic intact and allocates the space for 6 fd_set >> structs (instead of 3 in original change). It is proposed to have the >> change added to 11u in this "fix only" form. And, if necessary, to >> remove select() failure logic in a follow-up change. >> >> Testing: 11u change in this form was included with Red Hat >> 11.0.6-windows release and passed usual release testing. >> >> -- >> -Alex > -- -Alex From thomas.stuefe at gmail.com Mon Feb 10 11:12:08 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 10 Feb 2020 12:12:08 +0100 Subject: [11u]: RFR: 8238225: Issues reported after replacing symlink at Contents/MacOS/libjli.dylib with binary In-Reply-To: References: Message-ID: Looks good. ..Thomas On Sun, Feb 9, 2020 at 10:44 PM Langer, Christoph wrote: > Hi, > > the fix for "8235687: Contents/MacOS/libjli.dylib cannot be a symlink" > [0], which had been backported to 11.0.6, has introduced an issue for > custom launchers that try to start a JVM from a MacOS bundle. This has been > fixed and we should take this fix back to 11u as well. > > Please help to review: > Bug: https://bugs.openjdk.java.net/browse/JDK-8238225 > Original Patch: https://hg.openjdk.java.net/jdk/jdk/rev/023df178388e > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8238225.11u/ > > The actual fix in src/java.base/macosx/native/libjli/java_md_macosx.c is > quite straightforward, except that the file was renamed to > src/java.base/macosx/native/libjli/java_md_macosx.m in head revision which > caused the need for a little reshuffling. However, I also wanted to take > the test along which didn't exist yet in jdk11u, so I had to borrow parts > from JDK-8213362 [1], which introduced the test and subsequent changes > JDK-8215000 [2] and JDK-8216265 [3]. These changes however don't qualify > for a full backport, so I decided for carveouts. I also had to account for > the fact that in 11u libjli is located in subfolder lib/jli for non-windows > platforms, so I made a few additional modifications in > make/test/JtregNativeJdk.gmk and test/jdk/tools/launcher/JliLaunchTest.java. > > Thanks > Christoph > > [0] https://bugs.openjdk.java.net/browse/JDK-8235687 > [1] https://bugs.openjdk.java.net/browse/JDK-8213362 > [2] https://bugs.openjdk.java.net/browse/JDK-8215000 > [3] https://bugs.openjdk.java.net/browse/JDK-8216265 > > From aph at redhat.com Mon Feb 10 15:26:34 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 10 Feb 2020 15:26:34 +0000 Subject: New JDK 11u maintainer: Severin Gehwolf Message-ID: <977af0ed-678e-d757-e30e-3117ba2671f0@redhat.com> An announcement: Severin Gehwolf is now a maintainer of JDK 11u. He joins Christoph Langer in this role. I've been working with Severin for a long while and I'm confident he'll make a good job of this. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gil at azul.com Mon Feb 10 16:30:27 2020 From: gil at azul.com (Gil Tene) Date: Mon, 10 Feb 2020 16:30:27 +0000 Subject: Backporting features [was Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u] In-Reply-To: References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <85327ce1-2336-8950-871e-ac0af1856701@redhat.com> <212BBD26-93B9-46FD-A36E-1E4ED4319D18@azul.com> Message-ID: <8A7C69A5-ED60-4E59-89EF-CD534BBAB6B8@azul.com> > On Feb 7, 2020, at 10:13 AM, Andrew Haley wrote: > > First, let me state that in this discussion I am doing my best to > ensure that I am not biased by my job at Red Hat: despite my signature > below, I am writing as the JDK 11 Updates maintainer. I will try to > remain neutral and act in the best interests of the project, as I hope > will everyone else in this discussion. Agreed. While we all wear multiple hats, I would hope and assume that the discussions here relating to OpenJDK updates are driven by our opinions on what is best for the community that consumes those updates. I know mine is. > > On 2/7/20 4:19 PM, Gil Tene wrote: >> I think this is a discussion about the core of what an OpenJDK XXu update >> project is intended to do and produce, and what it's primary directives are. >> >> Let explain my opinion on the subject. Others' opinion will likely differ. > > Probably. > >> As I see it, the overriding purpose of an OpenJDK XXu project is to >> stabilize and maintain the associated Java SE release implementation >> as it is, with no intent to add any improvements or features. It is >> about applying bug fixes and security updates to a given OpenJDK >> Java version, in order to keep it's current use rock solid. It is >> not about "making it even better:". The place to make things "even >> better" is in upstream versions. We have one of those leaving the >> station every 6 months, with an LTS every three years, and those >> provide plenty of opportunities to bring better-ness to the >> community. > > Well, yes, kinda sorta: we must not be foolhardy, because the safety > of our users and the reputation of OpenJDK is at stake. > > However, OpenJDK is free software, so another issue at stake is > freedom: we want people to have a choice. Therefore, we should ensure, > as much as we can, that our users are not forced into the arms of > proprietary software vendors because of features lacking in equivalent > OpenJDK releases. Choice is good. But we are talking about two conflicting things: stability and evolution. And (as an opinion) I don't think that people need to be forced to choose evolution over stability, especially when alternatives for evolution are more readily available in OpenJDK than ever before (a new version comes out every 6 months). I would guess that for every OpenJDK user that wants to see 11u or 8u have new features (and is not willing to go to 13u or 14u for those), there are at least 10 that simply want 11u and 8u to remain rock-solid, and only take on changes that must be taken to improve stability and security. The historical cadence of Java and OpenJDK releases has been simple: - Versions (7, 8, 9, 10, 11, 12, 13?) bring new features and improvements - Within a version, updates bring bug fixes and add security updates, and make sure the current version is updated to run well on the latest/greatest versions of OSs. [** We have certainly had exceptions to the above, and I had already listed two examples of features that IMO closed a gap large enough to be clearly above the bar, but the bar is very high] I believe that the vast majority of Java users expect the same cadence and behavio to remainr, with stability increasing over time within a version, and capabilities improving over time across versions. It has been this way for decades. and it drives how and when people choose their jdk versions. If we are going to change that, and start offering a choice between evolution and stability within an OpenJDK versions, it should be a choice, and not a mandate that applies to all consumers of e.g. the 11u project. Such a choice would require two separate things: an 11u, and an 11uPlus. If some folks want to start and run with an OpenJDK 11u Plus project thing that goes far beyond maintaining OpenJDK 11u, and seeks to improve it with new features over time, I'm all for that. I may even contribute to it. But please please please don't do this as onl;y thing available in the 11u and 8u projects. If we do want to venture down the "let's bring features back to 11u (and maybe 8u)" path, I think that the hotspot-express model was the absolute right way to do this, and that we should consider starting a hotspot-express project for that purpose. The project would not be OpenJDK-version specific, but would instead build hotspot JVMs that are able to run any Java version (across a wide spectrum, e.g. starting with 11u or 8u). One would then be able to bundle a hotspot express JVM with an 11u, 13u, or 17u OpenJDK build (replacing the hotspot component within) and get the various JVM-only improvements, including new GCs, JIT improvements, runtime features, etc. (but no language features or class library/api changes) We could even change e.g. the 11u project build system allow one to choose between packaging the built-in hotspot (the one we primarily update for bug fixes and security reasons) or the hotspot-express jvm. And who knows: over time, if hotspot-express does well enough, and establishes a track record of evolution and stability at the same time, we may be able to drop the built-in hotspot altogether. But I would anticipate that to take several years top establish. > >> While it may be tempting to try to improve things under the hood >> (e.g. by making stuff faster, smaller, or better on some metric) or >> in visible ways (e.g. by adding options, features, etc.) in stable >> or in just-now-released versions, doing so will inherently risk the >> stability of the existing version, and put the main purpose of the >> updates project at risk. > > I understand. However, if we can determine that a feature backport is > > a. Desired by a number of downstream distributors (and their > users), and > > b. Sufficiently guarded by flags (e.g. #ifdef) that we can > determine statically that a feature has no effect if not > enabled/configured > > ... I believe we will not be taking undue risks. Downstream > distributors can take the decision to enable features or not. > > You might argue that even when not configured there is some slight > risk, but surely a risk has to be plausible, not just theoretically > possible. > >> For things that do not rise above the ""something is missing" bar in >> the main updates project, curation choices about back-porting or >> adding features and improvements to older versions can (and should) >> still be independently made in downstream distributions and projects >> (e.g. Zulu, Corretto , DragonWell RedHat's OpenJDK builds, Liberica, >> AOJ, and even Zing are all examples of downstream distros that make >> such choices every day, and so do e.g. shenandoah/jdk11). > > Certainly, this happens. However, we are at some risk of Balkanization > of JDK 11 distributions, with downstream vendors independently > packaging extensions. This is a Bad Thing and a waste of effort. If we > can share resources without risking our users' stability then everyone > benefits. > >> In this specific case, I see a clear and default path within >> OpenJDK: Focus on stabilizing Shenandoah 2.0 in 15u & 16u to the >> point where it is no longer an experimental feature. Getting it into >> 17u LTS (a mere 19 months from now) will be a much more important >> and useful achievement then backporting it into 11u in an >> experimental state. > > Here, I think you may have a point: there is a question about whether > experimental features should be back-ported. However, there are > already experimental features in JDK 11, so it's not as if they're > completely verboten in LTS releases. We should decide on the actual > demand (the benefit) versus the actual intrusiveness (the cost) rather > than in-principle arguments which may have more to do with theology > than engineering. I'd like to think that I'm a pragmatist, and that this is not a theological discussion in either direction. IMO the updates to an already released version of OpenJDK is not a place to introduce new experiments? We have plenty of places to evolve and mature experimental features, including side projects, as well as upstream versions. The only experimental things I know of in JDK11 (or later) releases were put there at version .0.0. AFAIK (I may be wrong), since Java 7, there have not been any experimental features added to a JDK after its initial .0 GA release. But my worries apply not only to experimental things. They also apply to fully baked ones as well. I believe that the bar for adding any new feature to a stable JDK updates project needs to be very high. It is not just a matter of balance between risk and benefit. It is a matter if the need being significant enough to warrant any risk at all. E.g. the non-experimental Dynamic CDS Archives feature is really cool. But I would not want to see it backported into an OpenJDK 11.0.8. E.g. when a fully baked, value-types supporting C2 change eventually mature upstream and is no longer experimental I will probably be strongly against back-porting those potentially destabilizing C2 changes to 11u. A hotspot-express model would allow us to box this, and provide a choice for users, between a "latest-greatest" jvm with new features, and a "same jvm that was initially shipped with the version" with stability and security improvements. But without such a choice, I think the default is obvious. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Mon Feb 10 16:47:13 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 10 Feb 2020 16:47:13 +0000 Subject: New JDK 11u maintainer: Severin Gehwolf In-Reply-To: <977af0ed-678e-d757-e30e-3117ba2671f0@redhat.com> References: <977af0ed-678e-d757-e30e-3117ba2671f0@redhat.com> Message-ID: Hi, this is great and will help to make sure important work won't be delayed unduly in the JDK11 updates project. I've updated the information on https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u. Welcome Severin ?? Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Andrew Haley > Sent: Montag, 10. Februar 2020 16:27 > To: jdk-updates-dev at openjdk.java.net > Subject: New JDK 11u maintainer: Severin Gehwolf > > An announcement: Severin Gehwolf is now a maintainer of JDK 11u. He > joins Christoph Langer in this role. I've been working with Severin > for a long while and I'm confident he'll make a good job of this. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From matthias.baesken at sap.com Tue Feb 11 09:24:15 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 11 Feb 2020 09:24:15 +0000 Subject: RFR [jdk11]: 8234525: enable link-time section-gc for linux s390x to remove unused code Message-ID: Hello , please review the downport of "8234525: enable link-time section-gc for linux s390x to remove unused code" to jdk11 . My change from jdk/jdk did not apply directly and I had to adjust it slightly . Bug and jdk/jdk change : https://bugs.openjdk.java.net/browse/JDK-8234525 https://hg.openjdk.java.net/jdk/jdk/rev/c04fa10636fd Adjusted change for jdk11u-dev : http://cr.openjdk.java.net/~mbaesken/webrevs/8234525.0_jdk11/ Original review thread : https://mail.openjdk.java.net/pipermail/build-dev/2019-November/026326.html Thanks, Matthias From matthias.baesken at sap.com Tue Feb 11 14:32:03 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 11 Feb 2020 14:32:03 +0000 Subject: [11u]: 8213906: Update arm devkits with libXrandr headers In-Reply-To: References: Message-ID: Hello Christoph, looks good to me ! From: Langer, Christoph Sent: Montag, 10. Februar 2020 08:16 To: jdk-updates-dev at openjdk.java.net Subject: [11u]: 8213906: Update arm devkits with libXrandr headers Hi, please review this tiny backport changeset: Bug: https://bugs.openjdk.java.net/browse/JDK-8213906 Original change: http://hg.openjdk.java.net/jdk/jdk/rev/a41566ad8756 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213906.11u/ It's one of these parity changes. The change didn't apply so I tried to resolve it manually. Thanks Christoph From volker.simonis at gmail.com Wed Feb 12 08:57:26 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 12 Feb 2020 09:57:26 +0100 Subject: RFR(14u): 8237375: SimpleThresholdPolicy misses CounterDecay timestamp initialization In-Reply-To: References: Message-ID: On Fri, Feb 7, 2020 at 1:46 PM Langer, Christoph wrote: > > Hi Volker, > > thanks for having a look here. > > > Looks good except that I'd rather use: > > > > + return ((os::javaTimeNanos() - _last_timestamp) / > > NANOUNITS_PER_MILLIUNIT) > CounterDecayMinIntervalLength; > > > > instead of: > > > > + return ((os::javaTimeNanos() - _last_timestamp) / NANOUNITS * > > MILLIUNITS) > CounterDecayMinIntervalLength; > > > > because it looks clearer (and is exactly what nanos_to_millis() also does). > > You're right and I would have done that - but unfortunately NANOUNITS_PER_MILLIUNIT was only introduced with 8235741 and I don't want to pull this into my backport here. > > So, is the change for 11u also ok? > I see. Then it's OK for me. You could use one more pair of parenthesis (i.e. (((os::javaTimeNanos() - _last_timestamp) / NANOUNITS) * MILLIUNITS) to make the expression more clear, but I leave that up to you. No new review required from my side. > Thanks > Christoph > From shade at redhat.com Wed Feb 12 10:53:22 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 12 Feb 2020 11:53:22 +0100 Subject: [11u] RFR 8238591: CTW: Split applications/ctw/modules/jdk_localedata.java Message-ID: Original bug: https://bugs.openjdk.java.net/browse/JDK-8238591 https://hg.openjdk.java.net/jdk/jdk/rev/b585d773ea0f Unfortunately, there are minor context differences: @module java.base/jdk.internal.access is not applicable due to missing JDK-8211122 (already rejected for 11u). So I had to drop that line from the new copy. 11u webrev: http://cr.openjdk.java.net/~shade/8238591/webrev.11u.01/ Testing: applications/ctw/modules (faster now!) -- Thanks, -Aleksey From hohensee at amazon.com Wed Feb 12 15:36:05 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 12 Feb 2020 15:36:05 +0000 Subject: [11u] RFR 8238591: CTW: Split applications/ctw/modules/jdk_localedata.java In-Reply-To: References: Message-ID: <446578C3-ACB6-476C-925E-7BA154FA7019@amazon.com> Hi, Aleksey, jdk_localdata_2.java is a new file, but the webrev seems to show it as a copy of jdk_localdata.java. Revise the webrev? Thanks, Paul ?On 2/12/20, 2:54 AM, "jdk-updates-dev on behalf of Aleksey Shipilev" wrote: Original bug: https://bugs.openjdk.java.net/browse/JDK-8238591 https://hg.openjdk.java.net/jdk/jdk/rev/b585d773ea0f Unfortunately, there are minor context differences: @module java.base/jdk.internal.access is not applicable due to missing JDK-8211122 (already rejected for 11u). So I had to drop that line from the new copy. 11u webrev: http://cr.openjdk.java.net/~shade/8238591/webrev.11u.01/ Testing: applications/ctw/modules (faster now!) -- Thanks, -Aleksey From shade at redhat.com Wed Feb 12 15:44:44 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 12 Feb 2020 16:44:44 +0100 Subject: [11u] RFR 8238591: CTW: Split applications/ctw/modules/jdk_localedata.java In-Reply-To: <446578C3-ACB6-476C-925E-7BA154FA7019@amazon.com> References: <446578C3-ACB6-476C-925E-7BA154FA7019@amazon.com> Message-ID: Hi Paul, On 2/12/20 4:36 PM, Hohensee, Paul wrote: > jdk_localdata_2.java is a new file, but the webrev seems to show it as a copy of jdk_localdata.java. Revise the webrev? jdk_localedata_2.java is a copy, and this is intentional! Mercurial tools are bad at showing this. If you go to jdk/jdk, then you would see "new file" has the history prior 8238591: $ hg log test/hotspot/jtreg/applications/ctw/modules/jdk_localedata_2.java -f changeset: 57976:b585d773ea0f user: shade date: Mon Feb 10 06:18:46 2020 +0100 summary: 8238591: CTW: Split applications/ctw/modules/jdk_localedata.java changeset: 54386:00fc7ba000b4 user: iignatyev date: Tue Apr 02 13:39:22 2019 -0700 summary: 8221870: use driver to run CtwRunner in applications/ctw tests ... ...or see the original webrev: https://cr.openjdk.java.net/~shade/8238591/webrev.01/ ...or see the metadata: "parents: test/hotspot/jtreg/applications/ctw/modules/jdk_localedata.java at 00fc7ba000b4" https://hg.openjdk.java.net/jdk/jdk/file/b585d773ea0f/test/hotspot/jtreg/applications/ctw/modules/jdk_localedata_2.java > ?On 2/12/20, 2:54 AM, "jdk-updates-dev on behalf of Aleksey Shipilev" wrote: > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8238591 > https://hg.openjdk.java.net/jdk/jdk/rev/b585d773ea0f > > Unfortunately, there are minor context differences: @module java.base/jdk.internal.access is not > applicable due to missing JDK-8211122 (already rejected for 11u). So I had to drop that line from > the new copy. > > 11u webrev: > http://cr.openjdk.java.net/~shade/8238591/webrev.11u.01/ -- Thanks, -Aleksey From hohensee at amazon.com Wed Feb 12 16:21:41 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 12 Feb 2020 16:21:41 +0000 Subject: [11u] RFR 8238591: CTW: Split applications/ctw/modules/jdk_localedata.java In-Reply-To: References: <446578C3-ACB6-476C-925E-7BA154FA7019@amazon.com> Message-ID: <196B5179-993B-4B75-B64B-E882AB46D712@amazon.com> I learn something new every day. :) Reviewed. Paul ?On 2/12/20, 7:45 AM, "Aleksey Shipilev" wrote: Hi Paul, On 2/12/20 4:36 PM, Hohensee, Paul wrote: > jdk_localdata_2.java is a new file, but the webrev seems to show it as a copy of jdk_localdata.java. Revise the webrev? jdk_localedata_2.java is a copy, and this is intentional! Mercurial tools are bad at showing this. If you go to jdk/jdk, then you would see "new file" has the history prior 8238591: $ hg log test/hotspot/jtreg/applications/ctw/modules/jdk_localedata_2.java -f changeset: 57976:b585d773ea0f user: shade date: Mon Feb 10 06:18:46 2020 +0100 summary: 8238591: CTW: Split applications/ctw/modules/jdk_localedata.java changeset: 54386:00fc7ba000b4 user: iignatyev date: Tue Apr 02 13:39:22 2019 -0700 summary: 8221870: use driver to run CtwRunner in applications/ctw tests ... ...or see the original webrev: https://cr.openjdk.java.net/~shade/8238591/webrev.01/ ...or see the metadata: "parents: test/hotspot/jtreg/applications/ctw/modules/jdk_localedata.java at 00fc7ba000b4" https://hg.openjdk.java.net/jdk/jdk/file/b585d773ea0f/test/hotspot/jtreg/applications/ctw/modules/jdk_localedata_2.java > ?On 2/12/20, 2:54 AM, "jdk-updates-dev on behalf of Aleksey Shipilev" wrote: > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8238591 > https://hg.openjdk.java.net/jdk/jdk/rev/b585d773ea0f > > Unfortunately, there are minor context differences: @module java.base/jdk.internal.access is not > applicable due to missing JDK-8211122 (already rejected for 11u). So I had to drop that line from > the new copy. > > 11u webrev: > http://cr.openjdk.java.net/~shade/8238591/webrev.11u.01/ -- Thanks, -Aleksey From shade at redhat.com Wed Feb 12 16:29:51 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 12 Feb 2020 17:29:51 +0100 Subject: [11u] RFR 8238591: CTW: Split applications/ctw/modules/jdk_localedata.java In-Reply-To: <196B5179-993B-4B75-B64B-E882AB46D712@amazon.com> References: <446578C3-ACB6-476C-925E-7BA154FA7019@amazon.com> <196B5179-993B-4B75-B64B-E882AB46D712@amazon.com> Message-ID: On 2/12/20 5:21 PM, Hohensee, Paul wrote: > I learn something new every day. :) Reviewed. Thanks, added the tag paraphernalia. -- -Aleksey From matthias.baesken at sap.com Thu Feb 13 11:48:04 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 13 Feb 2020 11:48:04 +0000 Subject: RFR [jdk11]: 8234525: enable link-time section-gc for linux s390x to remove unused code Message-ID: Ping - any reviews ? Thanks, Matthias From: Baesken, Matthias Sent: Dienstag, 11. Februar 2020 10:24 To: jdk-updates-dev at openjdk.java.net; 'build-dev at openjdk.java.net' Subject: RFR [jdk11]: 8234525: enable link-time section-gc for linux s390x to remove unused code Hello , please review the downport of "8234525: enable link-time section-gc for linux s390x to remove unused code" to jdk11 . My change from jdk/jdk did not apply directly and I had to adjust it slightly . Bug and jdk/jdk change : https://bugs.openjdk.java.net/browse/JDK-8234525 https://hg.openjdk.java.net/jdk/jdk/rev/c04fa10636fd Adjusted change for jdk11u-dev : http://cr.openjdk.java.net/~mbaesken/webrevs/8234525.0_jdk11/ Original review thread : https://mail.openjdk.java.net/pipermail/build-dev/2019-November/026326.html Thanks, Matthias From gnu.andrew at redhat.com Thu Feb 13 22:00:24 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 13 Feb 2020 22:00:24 +0000 Subject: Backporting features [was Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u] In-Reply-To: <8A7C69A5-ED60-4E59-89EF-CD534BBAB6B8@azul.com> References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <85327ce1-2336-8950-871e-ac0af1856701@redhat.com> <212BBD26-93B9-46FD-A36E-1E4ED4319D18@azul.com> <8A7C69A5-ED60-4E59-89EF-CD534BBAB6B8@azul.com> Message-ID: <5973b21b-2098-0231-e4fa-2303a744e84b@redhat.com> On 10/02/2020 16:30, Gil Tene wrote: > snip... >> >>> For things that do not rise above the ""something is missing" bar in >>> the main updates project, curation choices about back-porting or >>> adding features and improvements to older versions can (and should) >>> still be independently made in downstream distributions and projects >>> (e.g. Zulu, Corretto , DragonWell RedHat's OpenJDK builds, Liberica, >>> AOJ, and even Zing are all examples of downstream distros that make >>> such choices every day, and so do e.g. shenandoah/jdk11). >> >> Certainly, this happens. However, we are at some risk of Balkanization >> of JDK 11 distributions, with downstream vendors independently >> packaging extensions. This is a Bad Thing and a waste of effort. If we >> can share resources without risking our users' stability then everyone >> benefits. >> To me, this is the key point here and a far greater risk than the theoretical one of a backported feature causing instability. Having Shenandoah available in 11u is not a hypothetical. It is something that exists today and is being shipped to end users. This has now been the case for a number of years. For every such downstream, that is development and testing work that is being expended on a fork to the detriment of upstream OpenJDK. The stability (or lack thereof) of upstream OpenJDK becomes completely irrelevant if no-one is using it and is instead reliant on some downstream that works for them. In the case of Shenandoah specifically, our testing for the final release of 11u is currently split between builds based on the Shenandoah OpenJDK 11 backport and vanilla OpenJDK 11. To my mind, it would clearly be much preferable to be working solely on OpenJDK 11 itself, and healthier for this project. This is nothing new. OpenJDK 6 & 7 were both largely unused in their vanilla versions, with various GNU/Linux distributions downstream using various forks. This largely stemmed from the nascent nature of OpenJDK at the time, and there has been active effort since to move away from this model towards inclusion in OpenJDK projects, and eventually mainline, since. I can understand that the fear here comes from a feature being backported that is of no use to some, but then causes problems. OpenJDK is a big enough project that there will be elements like that for all of us. In my experience, the best way to resolve such fears is to have as many people as possible working and testing the *same* codebase. There are few things more annoying than discovering a bug, only to find someone already found and fixed that issue a long time ago in their downstream. I do find it strange that the TLS 1.3 and JFR backports to 8u are being considered to be exemptions here. Both of these are still very much a work-in-progress, when compared with Shenandoah. Personally, I am currently more concerned about both these backports causing disruption in 8u than Shenandoah in 11u, a backport of which has been available in a public repository for some time and has had widespread testing. In comparison, the JFR backport was, until recently, unable to be built using the standard bootstrap process with JDK n-1, and the TLS 1.3 backport is still in the planning stages. As to an "HotSpot Express" model, this has similar concerns to the existing problem of downstreams. In IcedTea for 8u, at present, we allow a choice of three different HotSpots (8u + AArch64 local to IcedTea, the aarch64/shenandoah-jdk8u HotSpot & the aarch32-port HotSpot) in the manner you seem to be suggesting. Doing so means triple the testing for every new build integration. Coupling the forked HotSpot to upstream OpenJDK's build system in some way doesn't remove the need to test the alternate configuration. Unless you intend to somehow start this process upstream, and make it again possible for a e.g. OpenJDK 15 HotSpot to be simply slotted in and used with 11u, I don't see how it reduces any of the additional work needed to maintain multiple forks. Even a HSX in OpenJDK 15 would require continuous maintenance, because I doubt Oracle want to maintain that. In short, while I appreciate the concerns, I think upstream integration is the best solution available, short of convincing the people who want these features not to use 11u at all and switch to the latest OpenJDK. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Thu Feb 13 22:18:17 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 13 Feb 2020 22:18:17 +0000 Subject: RFR [jdk11]: 8234525: enable link-time section-gc for linux s390x to remove unused code In-Reply-To: References: Message-ID: <4f702d14-8edb-4a49-5599-031ffedd74ac@redhat.com> On 13/02/2020 11:48, Baesken, Matthias wrote: > Ping - any reviews ? > > Thanks, Matthias > > From: Baesken, Matthias > Sent: Dienstag, 11. Februar 2020 10:24 > To: jdk-updates-dev at openjdk.java.net; 'build-dev at openjdk.java.net' > Subject: RFR [jdk11]: 8234525: enable link-time section-gc for linux s390x to remove unused code > > Hello , please review the downport of "8234525: enable link-time section-gc for linux s390x to remove unused code" to jdk11 . > > My change from jdk/jdk did not apply directly and I had to adjust it slightly . > > > > > Bug and jdk/jdk change : > > https://bugs.openjdk.java.net/browse/JDK-8234525 > https://hg.openjdk.java.net/jdk/jdk/rev/c04fa10636fd > > > Adjusted change for jdk11u-dev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8234525.0_jdk11/ > > > Original review thread : > > https://mail.openjdk.java.net/pipermail/build-dev/2019-November/026326.html > > > Thanks, Matthias > In the original patch, the lines are added after TOOLCHAIN_CFLAGS_JDK_CONLY. In the 11u version, they seem to have needlessly moved above it. Otherwise, looks good. Regarding the patch itself, are these flags only useful when the s390x port is present or would they be advantageous on older versions where s390x is still using the Zero assembler port? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From christoph.langer at sap.com Fri Feb 14 08:31:28 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 14 Feb 2020 08:31:28 +0000 Subject: RFR(14u): 8237375: SimpleThresholdPolicy misses CounterDecay timestamp initialization In-Reply-To: References: Message-ID: Hi Volker, > -----Original Message----- > From: Volker Simonis > Sent: Mittwoch, 12. Februar 2020 09:57 > To: Langer, Christoph > Cc: jdk-updates-dev at openjdk.java.net > Subject: Re: RFR(14u): 8237375: SimpleThresholdPolicy misses CounterDecay > timestamp initialization > > On Fri, Feb 7, 2020 at 1:46 PM Langer, Christoph > wrote: > > > > Hi Volker, > > > > thanks for having a look here. > > > > > Looks good except that I'd rather use: > > > > > > + return ((os::javaTimeNanos() - _last_timestamp) / > > > NANOUNITS_PER_MILLIUNIT) > CounterDecayMinIntervalLength; > > > > > > instead of: > > > > > > + return ((os::javaTimeNanos() - _last_timestamp) / NANOUNITS * > > > MILLIUNITS) > CounterDecayMinIntervalLength; > > > > > > because it looks clearer (and is exactly what nanos_to_millis() also does). > > > > You're right and I would have done that - but unfortunately > NANOUNITS_PER_MILLIUNIT was only introduced with 8235741 and I don't > want to pull this into my backport here. > > > > So, is the change for 11u also ok? > > > > I see. Then it's OK for me. You could use one more pair of parenthesis > (i.e. (((os::javaTimeNanos() - _last_timestamp) / NANOUNITS) * > MILLIUNITS) to make the expression more clear, but I leave that up to > you. No new review required from my side. Thanks for the review. I'll do that. Cheers Christoph From matthias.baesken at sap.com Fri Feb 14 08:54:32 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 14 Feb 2020 08:54:32 +0000 Subject: RFR [jdk11]: 8234525: enable link-time section-gc for linux s390x to remove unused code In-Reply-To: <4f702d14-8edb-4a49-5599-031ffedd74ac@redhat.com> References: <4f702d14-8edb-4a49-5599-031ffedd74ac@redhat.com> Message-ID: > > Hello , please review the downport of "8234525: enable link-time section- > gc for linux s390x to remove unused code" to jdk11 . > > > > My change from jdk/jdk did not apply directly and I had to adjust it slightly . > > > > > > > > > > Bug and jdk/jdk change : > > > > https://bugs.openjdk.java.net/browse/JDK-8234525 > > https://hg.openjdk.java.net/jdk/jdk/rev/c04fa10636fd > > > > > > Adjusted change for jdk11u-dev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8234525.0_jdk11/ > > > > > > Original review thread : > > > > https://mail.openjdk.java.net/pipermail/build-dev/2019- > November/026326.html > > > > > > Thanks, Matthias > > > > In the original patch, the lines are added after > TOOLCHAIN_CFLAGS_JDK_CONLY. In the 11u version, they seem to have > needlessly moved above it. > > Otherwise, looks good. > > Regarding the patch itself, are these flags only useful when the s390x > port is present or would they be advantageous on older versions where > s390x is still using the Zero assembler port? > Hello Andrew, thanks for the review . I did not check the zero based ports . However as long as gcc and ld support the flags used , it should work with zero too . Best regards, Matthias From sgehwolf at redhat.com Fri Feb 14 10:15:46 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 14 Feb 2020 11:15:46 +0100 Subject: [11u] RFR: 8226381: ProblemList java/lang/reflect/PublicMethods/PublicMethodsTest.java In-Reply-To: References: Message-ID: <18f2c3184db1f36160d031fbe3ea7232606c0255.camel@redhat.com> Hi Christoph, On Mon, 2020-02-10 at 07:31 +0000, Langer, Christoph wrote: > Hi, > > please review the next small Oracle parity backport: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8226381 > Original change: http://hg.openjdk.java.net/jdk/jdk/rev/3dcfa209f769 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8226381.11u/ > > The problem here is that test/jdk/ProblemList-aot.txt doesn't exist > in 11u so far. The change that created it, hasn't been backported, so > I have to create test/jdk/ProblemList-aot.txt with this backport. The change that created it, JDK-8225305, seems like a reasonable backport to do for this fix to apply cleanly, no? I think both fixes should apply fine omitting the need for a review. Thoughts? Thanks, Severin From christoph.langer at sap.com Fri Feb 14 10:27:08 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 14 Feb 2020 10:27:08 +0000 Subject: [11u] RFR: 8226381: ProblemList java/lang/reflect/PublicMethods/PublicMethodsTest.java In-Reply-To: <18f2c3184db1f36160d031fbe3ea7232606c0255.camel@redhat.com> References: <18f2c3184db1f36160d031fbe3ea7232606c0255.camel@redhat.com> Message-ID: Hi Severin, Good point. So I've also requested JDK-8225305 for backport. Please approve. Then I can just push the original changeset and this RFR is withdrawn. Cheers Christoph > -----Original Message----- > From: Severin Gehwolf > Sent: Freitag, 14. Februar 2020 11:16 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net > Subject: Re: [11u] RFR: 8226381: ProblemList > java/lang/reflect/PublicMethods/PublicMethodsTest.java > > Hi Christoph, > > On Mon, 2020-02-10 at 07:31 +0000, Langer, Christoph wrote: > > Hi, > > > > please review the next small Oracle parity backport: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8226381 > > Original change: http://hg.openjdk.java.net/jdk/jdk/rev/3dcfa209f769 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8226381.11u/ > > > > The problem here is that test/jdk/ProblemList-aot.txt doesn't exist > > in 11u so far. The change that created it, hasn't been backported, so > > I have to create test/jdk/ProblemList-aot.txt with this backport. > > The change that created it, JDK-8225305, seems like a reasonable > backport to do for this fix to apply cleanly, no? I think both fixes > should apply fine omitting the need for a review. > > Thoughts? > > Thanks, > Severin From aph at redhat.com Fri Feb 14 14:56:32 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 14 Feb 2020 14:56:32 +0000 Subject: Backporting features [was Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u] In-Reply-To: <5973b21b-2098-0231-e4fa-2303a744e84b@redhat.com> References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <85327ce1-2336-8950-871e-ac0af1856701@redhat.com> <212BBD26-93B9-46FD-A36E-1E4ED4319D18@azul.com> <8A7C69A5-ED60-4E59-89EF-CD534BBAB6B8@azul.com> <5973b21b-2098-0231-e4fa-2303a744e84b@redhat.com> Message-ID: On 2/13/20 10:00 PM, Andrew John Hughes wrote: > In short, while I appreciate the concerns, I think upstream > integration is the best solution available, short of convincing the > people who want these features not to use 11u at all and switch to > the latest OpenJDK. (TL/DR: I haven't yet decided.) When I applied to lead this project I wrote With regard to future plans, my Rule 0 is "first, do no harm": OpenJDK 11 is an increasingly important part of many organization's infrastructure, and we must not break it. I don't imagine that there will be many major feature backports, but I won't forbid them altogether. I don't intend to be a dictator: we should reach consensus on such decisions. Therefore, the default action when deciding on backporting a feature should be to say "no" because of Rule 0, but if there is a compelling reason to do the backport and we can do so without significant risk, we should. This is a very difficult call to make. While the argument about making JDK 11u as useful as to the majority as we reasonably can and to make it as well tested as possible is compelling, 11u is the upstream for everyone, not just the majority. IMO, if a significant downstream consumer feels that they cannot use a release because of the risk, the project will have failed. Therefore, we must seek a broad consensus. So what is a broad consensus? ISO defines it as General agreement, characterized by the absence of sustained opposition to substantial issues by any important part of the concerned interests and by a process that involves seeking to take into account the views of all parties concerned and to reconcile any conflicting arguments. Consensus need not imply unanimity. This is the definition I will use. It is in my view significant that we can guard the import of Shenandoah in such a way that we can statically analyse it and prove (beyond reasonable doubt) that, if not configured, it will have no effect. We can also show, albeit not quite as convincingly, that if it is not enabled with a runtime flag it will have no significant effect. For that reason I believe that the import of Shenandoah is less risky than many of the backport fixes that we do. With regard to the TLS 1.3 and JFR backports to 8u, unless there is a substantial risk we must do these because some proprietary Javas have them and our mission is to make sure that our end users have the choice of using free software. We don't want our users to be forced into using proprietary software because our releases are missing some important features. For that reason, although these backports are more risky than Shenandoah would be, there is a broad consensus in favour of them. I am not convinced by the "HotSpot Express" model: as far as I can see it does little more than replicating the effort that we have to make today, and increasing the testing effort. With regard to Gil Tene, I have to take it into account that he is, with one or two exceptions, the most experienced HotSpot and Java developer in this group. I do not believe that he is raising this objection in order to reduce the free competition for Azul's Zing product, but that he is solely motivated by the best interests of the project. Therefore, unless we reach a complete impasse that makes it impossible to proceed, I want to discuss this matter further in the hope that we can reach a consensus. Gil says that "or every OpenJDK user that wants to see 11u or 8u have new features (and is not willing to go to 13u or 14u for those), there are at least 10 that simply want 11u and 8u to remain rock-solid, and only take on changes that must be taken to improve stability and security." He may be right about that, but it is also important to minimize the workload and maximize the effective testing done by downstream developers. Finally, I believe that the underlying worry behind all of this is to some extent that Shenandoah represents the thin end of the wedge, and that if it is allowed in there will be a free-for-all. I don't think that will happen. The need for broad consensus makes such a situation unlikely, and I don't intend to allow it either. The question in the end, then, is just how compelling Shenandoah is, and how significant the risk is. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Mon Feb 17 08:45:11 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 17 Feb 2020 08:45:11 +0000 Subject: RFR [jdk11]: 8234525: enable link-time section-gc for linux s390x to remove unused code In-Reply-To: <4f702d14-8edb-4a49-5599-031ffedd74ac@redhat.com> References: <4f702d14-8edb-4a49-5599-031ffedd74ac@redhat.com> Message-ID: Hi Matthias, Backport looks good to me, too. But please move the new section before TOOLCHAIN_CFLAGS_JDK_CONLY in make/autoconf/flags-cflags.m4, as suggested by Andrew. No need for new webrev. Cheers Christoph > -----Original Message----- > From: build-dev On Behalf Of > Andrew John Hughes > Sent: Donnerstag, 13. Februar 2020 23:18 > To: Baesken, Matthias ; jdk-updates- > dev at openjdk.java.net; 'build-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: Re: RFR [jdk11]: 8234525: enable link-time section-gc for linux s390x > to remove unused code > > > > On 13/02/2020 11:48, Baesken, Matthias wrote: > > Ping - any reviews ? > > > > Thanks, Matthias > > > > From: Baesken, Matthias > > Sent: Dienstag, 11. Februar 2020 10:24 > > To: jdk-updates-dev at openjdk.java.net; 'build-dev at openjdk.java.net' > > > Subject: RFR [jdk11]: 8234525: enable link-time section-gc for linux s390x to > remove unused code > > > > Hello , please review the downport of "8234525: enable link-time section- > gc for linux s390x to remove unused code" to jdk11 . > > > > My change from jdk/jdk did not apply directly and I had to adjust it slightly . > > > > > > > > > > Bug and jdk/jdk change : > > > > https://bugs.openjdk.java.net/browse/JDK-8234525 > > https://hg.openjdk.java.net/jdk/jdk/rev/c04fa10636fd > > > > > > Adjusted change for jdk11u-dev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8234525.0_jdk11/ > > > > > > Original review thread : > > > > https://mail.openjdk.java.net/pipermail/build-dev/2019- > November/026326.html > > > > > > Thanks, Matthias > > > > In the original patch, the lines are added after > TOOLCHAIN_CFLAGS_JDK_CONLY. In the 11u version, they seem to have > needlessly moved above it. > > Otherwise, looks good. > > Regarding the patch itself, are these flags only useful when the s390x > port is present or would they be advantageous on older versions where > s390x is still using the Zero assembler port? > > 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 claes.redestad at oracle.com Mon Feb 17 14:42:35 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 17 Feb 2020 15:42:35 +0100 Subject: Backporting features [was Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u] In-Reply-To: References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <85327ce1-2336-8950-871e-ac0af1856701@redhat.com> <212BBD26-93B9-46FD-A36E-1E4ED4319D18@azul.com> <8A7C69A5-ED60-4E59-89EF-CD534BBAB6B8@azul.com> <5973b21b-2098-0231-e4fa-2303a744e84b@redhat.com> Message-ID: <239b0c43-c68c-f493-f11f-706003a5fbea@oracle.com> On 2020-02-14 15:56, Andrew Haley wrote: > With regard to the TLS 1.3 and JFR backports to 8u, unless there is a > substantial risk we must do these because some proprietary Javas have > them and our mission is to make sure that our end users have the > choice of using free software. We don't want our users to be forced > into using proprietary software because our releases are missing some > important features. For that reason, although these backports are more > risky than Shenandoah would be, there is a broad consensus in favour > of them. Except that the OpenJDK 11 implementation of JFR being backported to 8u is in fact not perfectly compatible with JFR as it exists in Oracle JDK 8. Apart from JFR in 11 being a major rewrite of the proprietary version in 8, the set of events is substantially different and the implementation in 11 relied on strong encapsulation to be correct and secure. The JFR in OpenJDK 11 is of course backwards compatible with Oracle's JFR 8, but tools built to deal with Oracle's JFR 8 are likely to not be compatible with the JFR being backported to OpenJDK 8u. So rather merely providing a plug-and-play free software alternative to a proprietary solution - which I think is in our common interest going forward - this backport is creating something new entirely that *will* contribute to fragmenting the JDK landscape. And this with a feature that is free software in OpenJDK from 11 and onwards. My personal opinion is that JFR should NOT be backported to 8u. TLS 1.3 is a different matter altogether, and also a much less risky proposition since it doesn't touch everything. /Claes From neugens at redhat.com Mon Feb 17 15:15:39 2020 From: neugens at redhat.com (Mario Torre) Date: Mon, 17 Feb 2020 16:15:39 +0100 Subject: Backporting features [was Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u] In-Reply-To: <239b0c43-c68c-f493-f11f-706003a5fbea@oracle.com> References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <85327ce1-2336-8950-871e-ac0af1856701@redhat.com> <212BBD26-93B9-46FD-A36E-1E4ED4319D18@azul.com> <8A7C69A5-ED60-4E59-89EF-CD534BBAB6B8@azul.com> <5973b21b-2098-0231-e4fa-2303a744e84b@redhat.com> <239b0c43-c68c-f493-f11f-706003a5fbea@oracle.com> Message-ID: On Mon, Feb 17, 2020 at 3:39 PM Claes Redestad wrote: > > On 2020-02-14 15:56, Andrew Haley wrote: > > With regard to the TLS 1.3 and JFR backports to 8u, unless there is a > > substantial risk we must do these because some proprietary Javas have > > them and our mission is to make sure that our end users have the > > choice of using free software. We don't want our users to be forced > > into using proprietary software because our releases are missing some > > important features. For that reason, although these backports are more > > risky than Shenandoah would be, there is a broad consensus in favour > > of them. > > Except that the OpenJDK 11 implementation of JFR being backported to 8u > is in fact not perfectly compatible with JFR as it exists in Oracle JDK > 8. Apart from JFR in 11 being a major rewrite of the proprietary version > in 8, the set of events is substantially different and the > implementation in 11 relied on strong encapsulation to be correct and > secure. > > The JFR in OpenJDK 11 is of course backwards compatible with Oracle's > JFR 8, but tools built to deal with Oracle's JFR 8 are likely to not be > compatible with the JFR being backported to OpenJDK 8u. JMC has been made aware of OpenJDK8u+JFR, and although there are still some issues we're fixing now, it works pretty well. I don't know other tools that would not work, but it doesn't really matter. If a tool doesn't recognise JFR in OpenJDK8u it's not different than now where there is no JFR. > So rather merely providing a plug-and-play free software alternative to > a proprietary solution - which I think is in our common interest going > forward - this backport is creating something new entirely that *will* > contribute to fragmenting the JDK landscape. And this with a feature > that is free software in OpenJDK from 11 and onwards. How can a common backport that is fully based on the code currently in 11 create fragmentation where in fact there exist an alternative proprietary JDK with a different JFR plus a variety of downstream distribution that are shipping with some form of support for JFR? We aim to cure fragmentation, not make it worse, we don't like fragmentation. > My personal opinion is that JFR should NOT be backported to 8u. I don't disagree with this, in fact, although I've been working on the backport I've made my opinion known that I prefer if this isn't backported, even before the backport started I suggested we shouldn't do it, but not for the reasons you highlighted. I think the only reason why JFR may not be desirable is the high complexity of this patch and the areas it touches, with risks of destabilisation of the OpenJDK8u. On the other hand, testing done by the aforementioned downstream distribution seems to suggest this is relatively safe. Having reviewed most of the patches we are backporting I know there's subtleties that need to be carefully assessed before we can call it done, but it's not necessarily something that we don't want, and speaking with a lot of the players involved has convinced me that it warrants at least a proper try. > TLS 1.3 is a different matter altogether, and also a much less risky > proposition since it doesn't touch everything. Well, yes. And no. The small area it touches is critical and we don't want to risk to break it either. What I'm getting at is that there is no proper one size fits all answer, each and every backport needs to be assessed, what we can do is to define general guidelines where a backport is desirable and when it's not. My personal opinion is that all backports should be done very carefully, in fact, for me we should also limit the number of single patches backported, let alone features, but not at the risk of fragmentation of the codebase. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From volker.simonis at gmail.com Mon Feb 17 15:38:50 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 17 Feb 2020 16:38:50 +0100 Subject: Backporting features [was Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u] In-Reply-To: References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <85327ce1-2336-8950-871e-ac0af1856701@redhat.com> <212BBD26-93B9-46FD-A36E-1E4ED4319D18@azul.com> <8A7C69A5-ED60-4E59-89EF-CD534BBAB6B8@azul.com> <5973b21b-2098-0231-e4fa-2303a744e84b@redhat.com> Message-ID: There's another dimension to this discussion which hasn't been touched yet. At the OpenJDK Committer's Workshop one OpenJDK vendor committed to provide so called Midterm-Supported Releases (MTS) for OpenJDK 13 and 15 in the OpenJDK project. This means that these releases will be supported such that their support time frame will overlap with that of the next OpenJDK 17 LTS release by one year. The goal is to smoothen the transition from one LTS to the next (e.g. 11 to 17) by offering the possibility of using intermediate releases (e.g. 13, 15) with long enough, overlapping support time frames. While I don't want to comment on or discuss the general usefulness of MTS release in this thread, it is apparent that downports of features like Shenandoah from 14 to 11 will directly affect the maintainers of 13. They either have to replay all the 11 downports in 13 as well, or they risk incompatibilities between 11 and 13 which invalidates the whole reason of an MTS release. This reasoning of course also applies to any other downported fix/enhancement. We should try to make sure that if we downport fix/feature X in release n, we should also downport X to any other, supported release m with m>n. As far as I know we don't have such a rule now and of course following it becomes increasinhly harder with an increasing number of releases supported in parallel. With best regards, Volker Andrew Haley schrieb am Fr., 14. Feb. 2020, 15:57: > On 2/13/20 10:00 PM, Andrew John Hughes wrote: > > > In short, while I appreciate the concerns, I think upstream > > integration is the best solution available, short of convincing the > > people who want these features not to use 11u at all and switch to > > the latest OpenJDK. > > (TL/DR: I haven't yet decided.) > > When I applied to lead this project I wrote > > With regard to future plans, my Rule 0 is "first, do no harm": > OpenJDK 11 is an increasingly important part of many organization's > infrastructure, and we must not break it. I don't imagine that there > will be many major feature backports, but I won't forbid them > altogether. I don't intend to be a dictator: we should reach > consensus on such decisions. > > Therefore, the default action when deciding on backporting a feature > should be to say "no" because of Rule 0, but if there is a compelling > reason to do the backport and we can do so without significant risk, > we should. > > This is a very difficult call to make. While the argument about making > JDK 11u as useful as to the majority as we reasonably can and to make > it as well tested as possible is compelling, 11u is the upstream for > everyone, not just the majority. IMO, if a significant downstream > consumer feels that they cannot use a release because of the risk, the > project will have failed. Therefore, we must seek a broad consensus. > > So what is a broad consensus? ISO defines it as > > General agreement, characterized by the absence of sustained > opposition to substantial issues by any important part of the > concerned interests and by a process that involves seeking to take > into account the views of all parties concerned and to reconcile any > conflicting arguments. Consensus need not imply unanimity. > > This is the definition I will use. > > It is in my view significant that we can guard the import of > Shenandoah in such a way that we can statically analyse it and prove > (beyond reasonable doubt) that, if not configured, it will have no > effect. We can also show, albeit not quite as convincingly, that if it > is not enabled with a runtime flag it will have no significant > effect. For that reason I believe that the import of Shenandoah is > less risky than many of the backport fixes that we do. > > With regard to the TLS 1.3 and JFR backports to 8u, unless there is a > substantial risk we must do these because some proprietary Javas have > them and our mission is to make sure that our end users have the > choice of using free software. We don't want our users to be forced > into using proprietary software because our releases are missing some > important features. For that reason, although these backports are more > risky than Shenandoah would be, there is a broad consensus in favour > of them. > > I am not convinced by the "HotSpot Express" model: as far as I can see > it does little more than replicating the effort that we have to make > today, and increasing the testing effort. > > With regard to Gil Tene, I have to take it into account that he is, > with one or two exceptions, the most experienced HotSpot and Java > developer in this group. I do not believe that he is raising this > objection in order to reduce the free competition for Azul's Zing > product, but that he is solely motivated by the best interests of the > project. Therefore, unless we reach a complete impasse that makes it > impossible to proceed, I want to discuss this matter further in the > hope that we can reach a consensus. > > Gil says that "or every OpenJDK user that wants to see 11u or 8u have > new features (and is not willing to go to 13u or 14u for those), there > are at least 10 that simply want 11u and 8u to remain rock-solid, and > only take on changes that must be taken to improve stability and > security." He may be right about that, but it is also important to > minimize the workload and maximize the effective testing done by > downstream developers. > > Finally, I believe that the underlying worry behind all of this is to > some extent that Shenandoah represents the thin end of the wedge, and > that if it is allowed in there will be a free-for-all. I don't think > that will happen. The need for broad consensus makes such a situation > unlikely, and I don't intend to allow it either. > > The question in the end, then, is just how compelling Shenandoah is, > and how significant the risk is. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > > From claes.redestad at oracle.com Mon Feb 17 15:45:29 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 17 Feb 2020 16:45:29 +0100 Subject: Backporting features [was Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u] In-Reply-To: References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <85327ce1-2336-8950-871e-ac0af1856701@redhat.com> <212BBD26-93B9-46FD-A36E-1E4ED4319D18@azul.com> <8A7C69A5-ED60-4E59-89EF-CD534BBAB6B8@azul.com> <5973b21b-2098-0231-e4fa-2303a744e84b@redhat.com> <239b0c43-c68c-f493-f11f-706003a5fbea@oracle.com> Message-ID: <98dd2ad1-79c9-225c-d0b7-ef70ee5afe51@oracle.com> On 2020-02-17 16:15, Mario Torre wrote: > On Mon, Feb 17, 2020 at 3:39 PM Claes Redestad > wrote: >> >> On 2020-02-14 15:56, Andrew Haley wrote: >>> With regard to the TLS 1.3 and JFR backports to 8u, unless there is a >>> substantial risk we must do these because some proprietary Javas have >>> them and our mission is to make sure that our end users have the >>> choice of using free software. We don't want our users to be forced >>> into using proprietary software because our releases are missing some >>> important features. For that reason, although these backports are more >>> risky than Shenandoah would be, there is a broad consensus in favour >>> of them. >> >> Except that the OpenJDK 11 implementation of JFR being backported to 8u >> is in fact not perfectly compatible with JFR as it exists in Oracle JDK >> 8. Apart from JFR in 11 being a major rewrite of the proprietary version >> in 8, the set of events is substantially different and the >> implementation in 11 relied on strong encapsulation to be correct and >> secure. >> >> The JFR in OpenJDK 11 is of course backwards compatible with Oracle's >> JFR 8, but tools built to deal with Oracle's JFR 8 are likely to not be >> compatible with the JFR being backported to OpenJDK 8u. > > JMC has been made aware of OpenJDK8u+JFR, and although there are still > some issues we're fixing now, it works pretty well. > > I don't know other tools that would not work, but it doesn't really > matter. If a tool doesn't recognise JFR in OpenJDK8u it's not > different than now where there is no JFR. Anecdotally I've written tools to extract data from JFR recordings using the JMC APIs. Sure, such tools *should* work transparently by upgrading to the latest JMC, but there might be any number of such surprises where tools need to be altered/updated that is hard to foresee. > >> So rather merely providing a plug-and-play free software alternative to >> a proprietary solution - which I think is in our common interest going >> forward - this backport is creating something new entirely that *will* >> contribute to fragmenting the JDK landscape. And this with a feature >> that is free software in OpenJDK from 11 and onwards. > > How can a common backport that is fully based on the code currently in > 11 create fragmentation where in fact there exist an alternative > proprietary JDK with a different JFR plus a variety of downstream > distribution that are shipping with some form of support for JFR? We > aim to cure fragmentation, not make it worse, we don't like > fragmentation. The fragmentation I primarily had in mind is that rather than one JFR variant there will now be (at least) two different implementations of JFR in various versions of 8u which have any number of subtle differences in behavior (different set of events, different default settings, etc.). There might also be OpenJDK distros that opt-out of building with JFR due concerns about stability, performance, etc... There is also a more insidious difference in that the backport means the code for OpenJDK 8u takes a big step away from the state of the fork of OpenJDK 8u Oracle maintains for Oracle JDK 8u. This is of course something the OpenJDK updates project is free to ignore, but it significantly increases risk that critical bug fixes to Oracle's proprietary fork will not be applicable to OpenJDK 8u and vice versa, which will lead to more work for everyone, and increase risk that serious bugs slip through. On JDK11+ there is no subtle difference in behavior: if you want something that is interchangeable with proprietary/commercial offerings, it already exists! > >> My personal opinion is that JFR should NOT be backported to 8u. > > I don't disagree with this, in fact, although I've been working on the > backport I've made my opinion known that I prefer if this isn't > backported, even before the backport started I suggested we shouldn't > do it, but not for the reasons you highlighted. I think the only > reason why JFR may not be desirable is the high complexity of this > patch and the areas it touches, with risks of destabilisation of the > OpenJDK8u. On the other hand, testing done by the aforementioned > downstream distribution seems to suggest this is relatively safe. > Having reviewed most of the patches we are backporting I know there's > subtleties that need to be carefully assessed before we can call it > done, but it's not necessarily something that we don't want, and > speaking with a lot of the players involved has convinced me that it > warrants at least a proper try. Perhaps a bitter pill to swallow, but I think the players involved need to take the steps necessary to upgrade to 11+ and stop demanding backports that risk destabilizing 8u /Claes From volker.simonis at gmail.com Mon Feb 17 15:53:11 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 17 Feb 2020 16:53:11 +0100 Subject: Backporting features [was Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u] In-Reply-To: <98dd2ad1-79c9-225c-d0b7-ef70ee5afe51@oracle.com> References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <85327ce1-2336-8950-871e-ac0af1856701@redhat.com> <212BBD26-93B9-46FD-A36E-1E4ED4319D18@azul.com> <8A7C69A5-ED60-4E59-89EF-CD534BBAB6B8@azul.com> <5973b21b-2098-0231-e4fa-2303a744e84b@redhat.com> <239b0c43-c68c-f493-f11f-706003a5fbea@oracle.com> <98dd2ad1-79c9-225c-d0b7-ef70ee5afe51@oracle.com> Message-ID: Claes Redestad schrieb am Mo., 17. Feb. 2020, 16:42: > > > On 2020-02-17 16:15, Mario Torre wrote: > > On Mon, Feb 17, 2020 at 3:39 PM Claes Redestad > > wrote: > >> > >> On 2020-02-14 15:56, Andrew Haley wrote: > >>> With regard to the TLS 1.3 and JFR backports to 8u, unless there is a > >>> substantial risk we must do these because some proprietary Javas have > >>> them and our mission is to make sure that our end users have the > >>> choice of using free software. We don't want our users to be forced > >>> into using proprietary software because our releases are missing some > >>> important features. For that reason, although these backports are more > >>> risky than Shenandoah would be, there is a broad consensus in favour > >>> of them. > >> > >> Except that the OpenJDK 11 implementation of JFR being backported to 8u > >> is in fact not perfectly compatible with JFR as it exists in Oracle JDK > >> 8. Apart from JFR in 11 being a major rewrite of the proprietary version > >> in 8, the set of events is substantially different and the > >> implementation in 11 relied on strong encapsulation to be correct and > >> secure. > >> > >> The JFR in OpenJDK 11 is of course backwards compatible with Oracle's > >> JFR 8, but tools built to deal with Oracle's JFR 8 are likely to not be > >> compatible with the JFR being backported to OpenJDK 8u. > > > > JMC has been made aware of OpenJDK8u+JFR, and although there are still > > some issues we're fixing now, it works pretty well. > > > > I don't know other tools that would not work, but it doesn't really > > matter. If a tool doesn't recognise JFR in OpenJDK8u it's not > > different than now where there is no JFR. > > Anecdotally I've written tools to extract data from JFR recordings > using the JMC APIs. > > Sure, such tools *should* work transparently by upgrading to the latest > JMC, but there might be any number of such surprises where tools need to > be altered/updated that is hard to foresee. > > > > >> So rather merely providing a plug-and-play free software alternative to > >> a proprietary solution - which I think is in our common interest going > >> forward - this backport is creating something new entirely that *will* > >> contribute to fragmenting the JDK landscape. And this with a feature > >> that is free software in OpenJDK from 11 and onwards. > > > > How can a common backport that is fully based on the code currently in > > 11 create fragmentation where in fact there exist an alternative > > proprietary JDK with a different JFR plus a variety of downstream > > distribution that are shipping with some form of support for JFR? We > > aim to cure fragmentation, not make it worse, we don't like > > fragmentation. > > The fragmentation I primarily had in mind is that rather than one JFR > variant there will now be (at least) two different implementations of > JFR in various versions of 8u which have any number of subtle > differences in behavior (different set of events, different default > settings, etc.). There might also be OpenJDK distros that opt-out of > building with JFR due concerns about stability, performance, etc... > > There is also a more insidious difference in that the backport means the > code for OpenJDK 8u takes a big step away from the state of the fork of > OpenJDK 8u Oracle maintains for Oracle JDK 8u. This is of course > something the OpenJDK updates project is free to ignore, but it > significantly increases risk that critical bug fixes to Oracle's > proprietary fork will not be applicable to OpenJDK 8u and vice versa, > which will lead to more work for everyone, and increase risk that > serious bugs slip through. > > On JDK11+ there is no subtle difference in behavior: if you want > something that is interchangeable with proprietary/commercial offerings, > it already exists! > > > > >> My personal opinion is that JFR should NOT be backported to 8u. > > > > I don't disagree with this, in fact, although I've been working on the > > backport I've made my opinion known that I prefer if this isn't > > backported, even before the backport started I suggested we shouldn't > > do it, but not for the reasons you highlighted. I think the only > > reason why JFR may not be desirable is the high complexity of this > > patch and the areas it touches, with risks of destabilisation of the > > OpenJDK8u. On the other hand, testing done by the aforementioned > > downstream distribution seems to suggest this is relatively safe. > > Having reviewed most of the patches we are backporting I know there's > > subtleties that need to be carefully assessed before we can call it > > done, but it's not necessarily something that we don't want, and > > speaking with a lot of the players involved has convinced me that it > > warrants at least a proper try. > > Perhaps a bitter pill to swallow, but I think the players involved need > to take the steps necessary to upgrade to 11+ and stop demanding > backports that risk destabilizing 8u > This is a little bit like asking Oracle to take back the extension to JDK8U support it has just announced and move its customers to 11+ ;-) > /Claes > From claes.redestad at oracle.com Mon Feb 17 16:11:37 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 17 Feb 2020 17:11:37 +0100 Subject: Backporting features [was Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u] In-Reply-To: References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <85327ce1-2336-8950-871e-ac0af1856701@redhat.com> <212BBD26-93B9-46FD-A36E-1E4ED4319D18@azul.com> <8A7C69A5-ED60-4E59-89EF-CD534BBAB6B8@azul.com> <5973b21b-2098-0231-e4fa-2303a744e84b@redhat.com> <239b0c43-c68c-f493-f11f-706003a5fbea@oracle.com> <98dd2ad1-79c9-225c-d0b7-ef70ee5afe51@oracle.com> Message-ID: <82ac3998-a486-a39a-e682-bc887af0c500@oracle.com> On 2020-02-17 16:53, Volker Simonis wrote: > > Perhaps a bitter pill to swallow, but I think the players involved need > to take the steps necessary to upgrade to 11+ and stop demanding > backports that risk destabilizing 8u > > > This is a little bit like asking Oracle to take back the extension to > JDK8U support it has just announced and move its customers to 11+ ;-) While I surely have both conscious and unconscious biases that I can't fully escape, I'm here as an OpenJDK maintainer arguing in favor of stability of past releases. I'd like to think I'd be as opposed to large, risky feature backports regardless of where I was employed. /Claes From neugens at redhat.com Mon Feb 17 16:14:27 2020 From: neugens at redhat.com (Mario Torre) Date: Mon, 17 Feb 2020 17:14:27 +0100 Subject: Backporting features [was Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u] In-Reply-To: <98dd2ad1-79c9-225c-d0b7-ef70ee5afe51@oracle.com> References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <85327ce1-2336-8950-871e-ac0af1856701@redhat.com> <212BBD26-93B9-46FD-A36E-1E4ED4319D18@azul.com> <8A7C69A5-ED60-4E59-89EF-CD534BBAB6B8@azul.com> <5973b21b-2098-0231-e4fa-2303a744e84b@redhat.com> <239b0c43-c68c-f493-f11f-706003a5fbea@oracle.com> <98dd2ad1-79c9-225c-d0b7-ef70ee5afe51@oracle.com> Message-ID: On Mon, Feb 17, 2020 at 4:42 PM Claes Redestad wrote: > Sure, such tools *should* work transparently by upgrading to the latest > JMC, but there might be any number of such surprises where tools need to > be altered/updated that is hard to foresee. Yes, we want to ensure that things are properly tested and keep working for everybody. Of course, this is difficult for an open source project and its community, given the nature of the licensing of the proprietary builds for 8u, so I assume that Oracle keeps working on JMC upstream and help us ensure that their downstream distribution keeps working properly. If there's a strong divergency, we will need to find solutions together, hopefully one that doesn't end up holding an open source project on a proprietary feature. > The fragmentation I primarily had in mind is that rather than one JFR > variant there will now be (at least) two different implementations of > JFR in various versions of 8u which have any number of subtle > differences in behavior (different set of events, different default > settings, etc.). There might also be OpenJDK distros that opt-out of > building with JFR due concerns about stability, performance, etc... > > There is also a more insidious difference in that the backport means the > code for OpenJDK 8u takes a big step away from the state of the fork of > OpenJDK 8u Oracle maintains for Oracle JDK 8u. Well, yeah... I mean... well... I won't discuss on the merit on why using JFR as an "added value" for the past years in the closed version did lead to this exact situation, and I won't do that because I'm extremely grateful to Oracle for JFR and for the fact that they did the right thing with the JFR release and I stated this in public multiple times. But this is an unfortunate consequence of not releasing the tool in time for one of the most popular JDK versions out there. Eventually if we didn't have JFR and JMC we would have had our own version of it, and somebody would have proposed to merge them in the JDK. Now, given the licensing nature of Oracle JDK I don't think it's a problem if OpenJDK has JFR as it comes from 11. This is because: 1. Only Oracle customers would know the difference, but if they are Oracle customers it doesn't matter, they are already using Oracle 2. Oracle JDK will eventually have discrepancy between 11 and 8 anyway, in fact, an 8 with the same infrastructure and events as 11 may help more when migrating from previous versions to later, even in the closed world universe. This is actually a good thing for Oracle. 3. The Events definition aren't really that different, if you look at the code in 8u that changed when the merge patch arrived (and also at the same 11 code where this is even more clear) you see that most of it is based on the now obsolete logging framework and the event changes are trivial. Most of the events are generated from XML descriptions anyway. I don't really think this is a huge matter, and I always assumed that the logging stuff was introduced in 8 to help back and forth patching between the proprietary code and the open one. I consider the issue of having JFR more important than the issue of what events are around, especially since the JFR file is self contained and self specified, if an event isn't there, it just isn't there. > > Perhaps a bitter pill to swallow, but I think the players involved need > to take the steps necessary to upgrade to 11+ and stop demanding > backports that risk destabilizing 8u > I agree, but it's not my call :) Btw, I'm really not advocating for the backport, but I don't think the Open vs Closed is an argument for not doing it. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From volker.simonis at gmail.com Mon Feb 17 16:20:20 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 17 Feb 2020 17:20:20 +0100 Subject: Backporting features [was Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u] In-Reply-To: <82ac3998-a486-a39a-e682-bc887af0c500@oracle.com> References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <85327ce1-2336-8950-871e-ac0af1856701@redhat.com> <212BBD26-93B9-46FD-A36E-1E4ED4319D18@azul.com> <8A7C69A5-ED60-4E59-89EF-CD534BBAB6B8@azul.com> <5973b21b-2098-0231-e4fa-2303a744e84b@redhat.com> <239b0c43-c68c-f493-f11f-706003a5fbea@oracle.com> <98dd2ad1-79c9-225c-d0b7-ef70ee5afe51@oracle.com> <82ac3998-a486-a39a-e682-bc887af0c500@oracle.com> Message-ID: On Mon, Feb 17, 2020 at 5:08 PM Claes Redestad wrote: > > On 2020-02-17 16:53, Volker Simonis wrote: > > > > Perhaps a bitter pill to swallow, but I think the players involved need > > to take the steps necessary to upgrade to 11+ and stop demanding > > backports that risk destabilizing 8u > > > > > > This is a little bit like asking Oracle to take back the extension to > > JDK8U support it has just announced and move its customers to 11+ ;-) > > While I surely have both conscious and unconscious biases that I can't > fully escape, I'm here as an OpenJDK maintainer arguing in favor of > stability of past releases. I'd like to think I'd be as opposed to > large, risky feature backports regardless of where I was employed. > Sorry, no offense at all. This was just a joke :) I don't wanted to challenge your authority as OpenJDK maintainer. It's just funny how all reasonable developers (including me) are asking for migration to 11+ but in the end client requests and business decisions for 8u always win in the end :) > /Claes From adinn at redhat.com Mon Feb 17 16:52:20 2020 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 17 Feb 2020 16:52:20 +0000 Subject: Backporting features [was Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u] In-Reply-To: <98dd2ad1-79c9-225c-d0b7-ef70ee5afe51@oracle.com> References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <85327ce1-2336-8950-871e-ac0af1856701@redhat.com> <212BBD26-93B9-46FD-A36E-1E4ED4319D18@azul.com> <8A7C69A5-ED60-4E59-89EF-CD534BBAB6B8@azul.com> <5973b21b-2098-0231-e4fa-2303a744e84b@redhat.com> <239b0c43-c68c-f493-f11f-706003a5fbea@oracle.com> <98dd2ad1-79c9-225c-d0b7-ef70ee5afe51@oracle.com> Message-ID: On 17/02/2020 15:45, Claes Redestad wrote: > The fragmentation I primarily had in mind is that rather than one JFR > variant there will now be (at least) two different implementations of > JFR in various versions of 8u which have any number of subtle > differences in behavior (different set of events, different default > settings, etc.). There might also be OpenJDK distros that opt-out of > building with JFR due concerns about stability, performance, etc... I'd suggest that the first and second of those two cases are different in degree if not kind. Not doing something is substantially less difficult to accommodate than doing what purports to be the same thing in an incompatible way. > There is also a more insidious difference in that the backport means the > code for OpenJDK 8u takes a big step away from the state of the fork of > OpenJDK 8u Oracle maintains for Oracle JDK 8u. This is of course > something the OpenJDK updates project is free to ignore, but it > significantly increases risk that critical bug fixes to Oracle's > proprietary fork will not be applicable to OpenJDK 8u and vice versa, > which will lead to more work for everyone, and increase risk that > serious bugs slip through. Hmm, I'm not very much swayed by that argument. At the very least I don't really respect its premise. How can I bets put this? The OpenJDK project didn't exactly create the space within which such divergence has become possible. In consequence, I don't think the weight of responsibility for any further divergence should be placed entirely, or even to a large degree, on the shoulders of the OpenJDK project. It was Oracle that made a choice to pursue a different path to all the other parties involved. As regards the potential consequences of living in such a divided space, of course we don't want to introduce incompatibility willy-nilly. However, it is important to bear in mind that the motive for doing so wrt this and other features (e.g. AArch64 or Shenandoah) is to have one common version in upstream jdk8u rather than having different versions in one or more downstream repos (well, one version modulo Oracle's departure into its own different universe). Such divergence is a present fact given that Alibaba already have a JFR jdk8u, Linux distros have an AArch64 jdk8u, Red Hat has a Shenandoah jdk8u. So, what we are doing here is fixing an existing fragmentation within the scope of the OpenJDK project. When it comes to assessing the merits of the proposed jdk8u JFR, I balance the benefits of that /intra-project/ remedy quite highly relative to any concern I might have about the potential for /extra-project/ deviations from Oracle's proprietary version. Indeed, it's the same story as regards other intra- vs extra-project differences whether they relate to the AArch64 port, the inclusion of Shenandoah or evcen differences that emerge in the behaviour of the OpenJDK runtime itself -- noting of course that the TCK signifcantly limits the scope for the latter category of divergences to significantly impact users. I am also, if not exactly underwhelmed, then certainly less than whelmed by the security story. The backport project has a lot of experience applying upstream patches that don't directly apply or even, where needed, developing its own patches. The critical element in managing such issues has not been down to being handed corrected code by Oracle but being party to the details of the CVEs that need fixing. Given that we now do have access to such information I don't see security concerns as posing such a great threat. Also, I have to note that if the room for novel security challenges is such a concern then I do wonder how Oracle can square that concern with a blithe view of the divergence their decision to pursue their own jdk8u implies? likewise with their decision to release, over many years, a version of jdk8u that included JFR when other releases did not. > Perhaps a bitter pill to swallow, but I think the players involved need > to take the steps necessary to upgrade to 11+ and stop demanding > backports that risk destabilizing 8u I am more sympathetic to that exhortation wrt JFR. Less so wrt aarch64 or Shenandoah. However, many others in the project and, most importantly, many of our users -- especially those who are going to be maintaining deployments running on jdk8u for a long time -- feel otherwise. By not providing those users with a standard jdk8u complete with JFR we are leaving the open project short of a capability that many users really need and so failing in our duty to make open source Java a real alternative to proprietary Java. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From aph at redhat.com Mon Feb 17 16:53:29 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 17 Feb 2020 16:53:29 +0000 Subject: Backporting features [was Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u] In-Reply-To: References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <85327ce1-2336-8950-871e-ac0af1856701@redhat.com> <212BBD26-93B9-46FD-A36E-1E4ED4319D18@azul.com> <8A7C69A5-ED60-4E59-89EF-CD534BBAB6B8@azul.com> <5973b21b-2098-0231-e4fa-2303a744e84b@redhat.com> Message-ID: <10d50ddc-15d0-92a3-b58c-028811394dc8@redhat.com> On 2/17/20 3:38 PM, Volker Simonis wrote: > This reasoning of course also applies to any other downported > fix/enhancement. We should try to make sure that if we downport > fix/feature X in release n, we should also downport X to any other, > supported release m with m>n. For some value of "we". -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon Feb 17 17:11:02 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 17 Feb 2020 17:11:02 +0000 Subject: Backporting features [was Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u] In-Reply-To: <239b0c43-c68c-f493-f11f-706003a5fbea@oracle.com> References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <85327ce1-2336-8950-871e-ac0af1856701@redhat.com> <212BBD26-93B9-46FD-A36E-1E4ED4319D18@azul.com> <8A7C69A5-ED60-4E59-89EF-CD534BBAB6B8@azul.com> <5973b21b-2098-0231-e4fa-2303a744e84b@redhat.com> <239b0c43-c68c-f493-f11f-706003a5fbea@oracle.com> Message-ID: <53ecea1c-0aef-b8f2-4fbd-25258df80d74@redhat.com> On 2/17/20 2:42 PM, Claes Redestad wrote: > On 2020-02-14 15:56, Andrew Haley wrote: >> With regard to the TLS 1.3 and JFR backports to 8u, unless there is a >> substantial risk we must do these because some proprietary Javas have >> them and our mission is to make sure that our end users have the >> choice of using free software. We don't want our users to be forced >> into using proprietary software because our releases are missing some >> important features. For that reason, although these backports are more >> risky than Shenandoah would be, there is a broad consensus in favour >> of them. > > Except that the OpenJDK 11 implementation of JFR being backported to > 8u is in fact not perfectly compatible with JFR as it exists in > Oracle JDK 8. Apart from JFR in 11 being a major rewrite of the > proprietary version in 8, the set of events is substantially > different and the implementation in 11 relied on strong > encapsulation to be correct and secure. I hear what you're saying. Of course, any more information that you can provide will be gratefully welcomed. > The JFR in OpenJDK 11 is of course backwards compatible with Oracle's > JFR 8, but tools built to deal with Oracle's JFR 8 are likely to not be > compatible with the JFR being backported to OpenJDK 8u. We'll test with whatever tools we can, of course, and we'll try to fix any incompatibilities. But as Mario said, this is really about JMC, and everything else is a bonus. > So rather merely providing a plug-and-play free software alternative to > a proprietary solution - which I think is in our common interest going > forward - this backport is creating something new entirely that *will* > contribute to fragmenting the JDK landscape. And this with a feature > that is free software in OpenJDK from 11 and onwards. I very strongly disagree. The greatest fragmentation is surely a *completely missing* JFR implementation in 8u. > My personal opinion is that JFR should NOT be backported to 8u. OK, noted. I thank you for speaking up here, and I'll seriously weigh your opinion when deciding what to do next. We must be extremely careful not to break anything, and if in the final analysis committing the backport looks risky, we won't do it. The decision is not final and will not be final until the commit is approved. But as Andrew Dinn noted, we have a duty to extend freedom, and we do that best by making OpenJDK8u as compelling a proposition as it can be. While, yeah, not breaking anything. :-) -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From claes.redestad at oracle.com Mon Feb 17 17:39:19 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 17 Feb 2020 18:39:19 +0100 Subject: Backporting features [was Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u] In-Reply-To: References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <85327ce1-2336-8950-871e-ac0af1856701@redhat.com> <212BBD26-93B9-46FD-A36E-1E4ED4319D18@azul.com> <8A7C69A5-ED60-4E59-89EF-CD534BBAB6B8@azul.com> <5973b21b-2098-0231-e4fa-2303a744e84b@redhat.com> <239b0c43-c68c-f493-f11f-706003a5fbea@oracle.com> <98dd2ad1-79c9-225c-d0b7-ef70ee5afe51@oracle.com> Message-ID: <2aecc25f-195b-c567-0bb6-fe6ee7b75f45@oracle.com> On 2020-02-17 17:52, Andrew Dinn wrote: > Also, I have to note that if the room for novel security challenges is > such a concern then I do wonder how Oracle can square that concern with > a blithe view of the divergence their decision to pursue their own jdk8u > implies? likewise with their decision to release, over many years, a > version of jdk8u that included JFR when other releases did not. I'm not Oracle, and I'm not here to discuss why Oracle invested in and sold proprietary, commercial features on top of the OpenJDK for many years, nor why we/they finally deciced to converge and contribute all those features to the OpenJDK. I have little sway in influencing any such decisions. I will say though that I am personally very happy with where we are in the OpenJDK mainline *now*, and as much as I wish we could converge and retrofit all these features from Oracle JDK to OpenJDK 8u, that's an absolutely massive effort that I think would induce a lot of risks, while detracting from the main mission of moving the OpenJDK forward. > >> Perhaps a bitter pill to swallow, but I think the players involved need >> to take the steps necessary to upgrade to 11+ and stop demanding >> backports that risk destabilizing 8u > I am more sympathetic to that exhortation wrt JFR. Less so wrt aarch64 > or Shenandoah. However, many others in the project and, most > importantly, many of our users -- especially those who are going to be > maintaining deployments running on jdk8u for a long time -- feel > otherwise. By not providing those users with a standard jdk8u complete > with JFR we are leaving the open project short of a capability that many > users really need and so failing in our duty to make open source Java a > real alternative to proprietary Java. Why is this not framed as a need to get help upgrading? Why are we not investing all this time in the future, rather than in delaying the inevitable? Life is too short for backports. /Claes From aph at redhat.com Mon Feb 17 17:46:13 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 17 Feb 2020 17:46:13 +0000 Subject: Backporting features [was Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u] In-Reply-To: <2aecc25f-195b-c567-0bb6-fe6ee7b75f45@oracle.com> References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <85327ce1-2336-8950-871e-ac0af1856701@redhat.com> <212BBD26-93B9-46FD-A36E-1E4ED4319D18@azul.com> <8A7C69A5-ED60-4E59-89EF-CD534BBAB6B8@azul.com> <5973b21b-2098-0231-e4fa-2303a744e84b@redhat.com> <239b0c43-c68c-f493-f11f-706003a5fbea@oracle.com> <98dd2ad1-79c9-225c-d0b7-ef70ee5afe51@oracle.com> <2aecc25f-195b-c567-0bb6-fe6ee7b75f45@oracle.com> Message-ID: On 2/17/20 5:39 PM, Claes Redestad wrote: > Why is this not framed as a need to get help upgrading? Why are we not > investing all this time in the future, rather than in delaying the > inevitable? > > Life is too short for backports. Y'know, I have a lot of sympathy for that point of view. I never entered this business with the ambition of supporting vintage software, yet here we are. However, when the big change that was JDK 9 came along I said fairly confidently that we were going to have to support JDK 8 for the next twenty years. While that was partly a jest, it had a certain grain of truth. One consequence of that is backports. One other thing: we must remember that people have a choice. They are not prisoners to Java. If we withhold backports in order to persuade them to jump to later JDK releases we're forcing them to do work, and some of them might just port to some other platform altogether. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Mon Feb 17 17:51:15 2020 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 17 Feb 2020 17:51:15 +0000 Subject: Backporting features [was Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u] In-Reply-To: <2aecc25f-195b-c567-0bb6-fe6ee7b75f45@oracle.com> References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <85327ce1-2336-8950-871e-ac0af1856701@redhat.com> <212BBD26-93B9-46FD-A36E-1E4ED4319D18@azul.com> <8A7C69A5-ED60-4E59-89EF-CD534BBAB6B8@azul.com> <5973b21b-2098-0231-e4fa-2303a744e84b@redhat.com> <239b0c43-c68c-f493-f11f-706003a5fbea@oracle.com> <98dd2ad1-79c9-225c-d0b7-ef70ee5afe51@oracle.com> <2aecc25f-195b-c567-0bb6-fe6ee7b75f45@oracle.com> Message-ID: On 17/02/2020 17:39, Claes Redestad wrote: > > On 2020-02-17 17:52, Andrew Dinn wrote: >> Also, I have to note that if the room for novel security challenges is >> such a concern then I do wonder how Oracle can square that concern with >> a blithe view of the divergence their decision to pursue their own jdk8u >> implies? likewise with their decision to release, over many years, a >> version of jdk8u that included JFR when other releases did not. > > I'm not Oracle, and I'm not here to discuss why Oracle invested in and > sold proprietary, commercial features on top of the OpenJDK for many > years, nor why we/they finally deciced to converge and contribute all > those features to the OpenJDK. I have little sway in influencing any > such decisions. Of course, I appreciate that, Claes. The comments above were not addressed at you but at your line of reasoning. The rationale for them is that having raised the question as to how seriously the OpenJDK project should consider divergence from Oracle, in particular wrt the room for issues like security holes to appear, Oracle's past divergent behaviour needs to be factored into any answer. That's required to ensure that actions in this project and their potential outcomes are considered on their merits /relative/ to those actions taken by Oracle and results observed as a consequence. If the latter actions have not been significantly harmful to the project then the former cannot easily be held up as such. It's a matter of establishing perspective and balance. Of course, I wasn't intending to suggest that you were in any way resposible for the decisions which led to those actions. > I will say though that I am personally very happy with where we are in > the OpenJDK mainline *now*, and as much as I wish we could converge and > retrofit all these features from Oracle JDK to OpenJDK 8u, that's an > absolutely massive effort that I think would induce a lot of risks, > while detracting from the main mission of moving the OpenJDK forward. Yes, I 100% agree that the Jigsaw hump has been completely flattened and much improvement has been made in more recent releases. So, many users should be considering upgrading and absolutely noe of them should be considering jdk8u for any new projects. However, there are and always were going to be legacy jdk8u deployments for years to come. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From gnu.andrew at redhat.com Mon Feb 17 18:31:41 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 17 Feb 2020 18:31:41 +0000 Subject: Backporting features [was Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u] In-Reply-To: <98dd2ad1-79c9-225c-d0b7-ef70ee5afe51@oracle.com> References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <85327ce1-2336-8950-871e-ac0af1856701@redhat.com> <212BBD26-93B9-46FD-A36E-1E4ED4319D18@azul.com> <8A7C69A5-ED60-4E59-89EF-CD534BBAB6B8@azul.com> <5973b21b-2098-0231-e4fa-2303a744e84b@redhat.com> <239b0c43-c68c-f493-f11f-706003a5fbea@oracle.com> <98dd2ad1-79c9-225c-d0b7-ef70ee5afe51@oracle.com> Message-ID: <4ab7f260-b5b5-3136-4871-7d83e4e2bdd9@redhat.com> On 17/02/2020 15:45, Claes Redestad wrote: snip... > There is also a more insidious difference in that the backport means the > code for OpenJDK 8u takes a big step away from the state of the fork of > OpenJDK 8u Oracle maintains for Oracle JDK 8u. This is of course > something the OpenJDK updates project is free to ignore, but it > significantly increases risk that critical bug fixes to Oracle's > proprietary fork will not be applicable to OpenJDK 8u and vice versa, > which will lead to more work for everyone, and increase risk that > serious bugs slip through. > This seems to give the impression that this would be something new. It isn't. Divergence was inevitable as soon as Oracle chose to create a fork rather than working with the community. It also seems to suggest that these "critical bug fixes to Oracle's proprietary fork" are somehow being made available for integration into OpenJDK 8u. They are not. I don't see how something that is unavailable can be applicable to OpenJDK 8u in the first place. As Andrew Dinn has already said well, and in greater detail, the onus for divergence can not rest solely on the shoulders of the OpenJDK project. We do our best to maintain parity with what Oracle is backporting, using the limited information available, but there is only one of us who has full visibility of both 8u trees, and it is not the OpenJDK 8u project. -- 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 claes.redestad at oracle.com Mon Feb 17 18:41:05 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 17 Feb 2020 19:41:05 +0100 Subject: Backporting features [was Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u] In-Reply-To: <4ab7f260-b5b5-3136-4871-7d83e4e2bdd9@redhat.com> References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <85327ce1-2336-8950-871e-ac0af1856701@redhat.com> <212BBD26-93B9-46FD-A36E-1E4ED4319D18@azul.com> <8A7C69A5-ED60-4E59-89EF-CD534BBAB6B8@azul.com> <5973b21b-2098-0231-e4fa-2303a744e84b@redhat.com> <239b0c43-c68c-f493-f11f-706003a5fbea@oracle.com> <98dd2ad1-79c9-225c-d0b7-ef70ee5afe51@oracle.com> <4ab7f260-b5b5-3136-4871-7d83e4e2bdd9@redhat.com> Message-ID: On 2020-02-17 19:31, Andrew John Hughes wrote: > As Andrew Dinn has already said well, and in greater detail, the onus > for divergence can not rest solely on the shoulders of the OpenJDK > project. I did not imply otherwise, just pointing out that this is a reality the OpenJDK must take into consideration regardless of who's to blame. All I'm saying is that exasperating the divergence might not be in the best interest of either party. /Claes From gnu.andrew at redhat.com Mon Feb 17 18:39:35 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 17 Feb 2020 18:39:35 +0000 Subject: Backporting features [was Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u] In-Reply-To: <10d50ddc-15d0-92a3-b58c-028811394dc8@redhat.com> References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <85327ce1-2336-8950-871e-ac0af1856701@redhat.com> <212BBD26-93B9-46FD-A36E-1E4ED4319D18@azul.com> <8A7C69A5-ED60-4E59-89EF-CD534BBAB6B8@azul.com> <5973b21b-2098-0231-e4fa-2303a744e84b@redhat.com> <10d50ddc-15d0-92a3-b58c-028811394dc8@redhat.com> Message-ID: On 17/02/2020 16:53, Andrew Haley wrote: > On 2/17/20 3:38 PM, Volker Simonis wrote: >> This reasoning of course also applies to any other downported >> fix/enhancement. We should try to make sure that if we downport >> fix/feature X in release n, we should also downport X to any other, >> supported release m with m>n. > > For some value of "we". > Indeed. This did used to be in the case in simpler times, but, now we effectively have nine OpenJDK versions that could warrant a backport of any particular fix (from OpenJDK 14 right down to 6, were they all to be actively maintained), that responsibility has to, in part, lie with those choosing to maintain a particular OpenJDK version. It seems a little unfair to expect, for example, someone backporting to 11u to also cover 12, 13 and 14, if those backporting to 14 don't return the favour in backporting to 11. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Mon Feb 17 18:42:13 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 17 Feb 2020 18:42:13 +0000 Subject: Backporting features [was Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u] In-Reply-To: References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <85327ce1-2336-8950-871e-ac0af1856701@redhat.com> <212BBD26-93B9-46FD-A36E-1E4ED4319D18@azul.com> <8A7C69A5-ED60-4E59-89EF-CD534BBAB6B8@azul.com> <5973b21b-2098-0231-e4fa-2303a744e84b@redhat.com> <239b0c43-c68c-f493-f11f-706003a5fbea@oracle.com> <98dd2ad1-79c9-225c-d0b7-ef70ee5afe51@oracle.com> <4ab7f260-b5b5-3136-4871-7d83e4e2bdd9@redhat.com> Message-ID: <9132b6fb-f023-f5d4-a65a-8098ecd689aa@redhat.com> On 17/02/2020 18:41, Claes Redestad wrote: > > > On 2020-02-17 19:31, Andrew John Hughes wrote: >> As Andrew Dinn has already said well, and in greater detail, the onus >> for divergence can not rest solely on the shoulders of the OpenJDK >> project. > > I did not imply otherwise, just pointing out that this is a reality the > OpenJDK must take into consideration regardless of who's to blame. All > I'm saying is that exasperating the divergence might not be in the best > interest of either party. > > /Claes > True, and this is something we have taken into consideration and continue to do so. My key point is that such considerations are inevitably limited when one is comparing against a black box. -- 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 claes.redestad at oracle.com Mon Feb 17 19:13:49 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 17 Feb 2020 20:13:49 +0100 Subject: Backporting features [was Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u] In-Reply-To: References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <85327ce1-2336-8950-871e-ac0af1856701@redhat.com> <212BBD26-93B9-46FD-A36E-1E4ED4319D18@azul.com> <8A7C69A5-ED60-4E59-89EF-CD534BBAB6B8@azul.com> <5973b21b-2098-0231-e4fa-2303a744e84b@redhat.com> <239b0c43-c68c-f493-f11f-706003a5fbea@oracle.com> <98dd2ad1-79c9-225c-d0b7-ef70ee5afe51@oracle.com> <2aecc25f-195b-c567-0bb6-fe6ee7b75f45@oracle.com> Message-ID: <75d5337c-7bd9-aa11-0984-c68229f43420@oracle.com> On 2020-02-17 18:46, Andrew Haley wrote: > One other thing: we must remember that people have a choice. They are > not prisoners to Java. If we withhold backports in order to persuade > them to jump to later JDK releases we're forcing them to do work, and > some of them might just port to some other platform altogether. Without diminishing the importance of keeping 8u and 11u alive, up-to-date and relevant, this seems to me a bit like catering to people who are just looking for excuses to move on to something else. My gut feeling tell me they are likely going to be moving on in the end, regardless. I think our best bet at both retaining existing users and growing the ecosystem is by putting our collective resources on delivering new features of high quality into the mainline. Backports are a necessary evil, though, and JFR is an obvious "gap". I'm just not convinced it's obviously the right thing to do, especially considering what we could have done instead with that time and effort. /Claes From aph at redhat.com Mon Feb 17 19:35:54 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 17 Feb 2020 19:35:54 +0000 Subject: Backporting features [was Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u] In-Reply-To: <75d5337c-7bd9-aa11-0984-c68229f43420@oracle.com> References: <3595e963-fa5b-bfce-c463-841b84d4103f@redhat.com> <85327ce1-2336-8950-871e-ac0af1856701@redhat.com> <212BBD26-93B9-46FD-A36E-1E4ED4319D18@azul.com> <8A7C69A5-ED60-4E59-89EF-CD534BBAB6B8@azul.com> <5973b21b-2098-0231-e4fa-2303a744e84b@redhat.com> <239b0c43-c68c-f493-f11f-706003a5fbea@oracle.com> <98dd2ad1-79c9-225c-d0b7-ef70ee5afe51@oracle.com> <2aecc25f-195b-c567-0bb6-fe6ee7b75f45@oracle.com> <75d5337c-7bd9-aa11-0984-c68229f43420@oracle.com> Message-ID: <42eb1922-f480-f601-9d9f-b35e5fcb1a38@redhat.com> On 2/17/20 7:13 PM, Claes Redestad wrote: > I think our best bet at both retaining existing users and growing > the ecosystem is by putting our collective resources on delivering > new features of high quality into the mainline. Backports are a > necessary evil, though, and JFR is an obvious "gap". I'm just not > convinced it's obviously the right thing to do, especially > considering what we could have done instead with that time and > effort. I'm not either. I wrestle with thoughts like this every day. Some random thoughts: a significant difference between OpenJDK and closed projects is that we get to have these kinds of conversations out in the open. Not only that, but our deliberations are preserved forever for everyone to see. All we can say in the end is that while the decisions we make may not be the ideal ones from everyone's point of view, or indeed match those of any single individual, I can guarantee we've thought about them very hard. This conversation is part of that process. Also, having several significant backports coming at the same time is unusual and entirely accidental. I believe that the volume of backports will slacken considerably from this point onwards. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rob.mckenna at oracle.com Tue Feb 18 17:09:52 2020 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 18 Feb 2020 17:09:52 +0000 Subject: [13u-communication] End of maintenance & invitation for new maintainers Message-ID: <20200218170952.GA16228@yoga> I'm sending this mail to notify the community that the current maintainers intend to step down as maintainers for the JDK 13 Updates forest [1] at the end of March, or sooner, if new maintainers were to step up. [2] This being the case we would like to invite prospective new maintainers to step forward at this point to ensure a smooth transition should they wish to maintain this forest beyond the end of March. -Rob [1] https://hg.openjdk.java.net/jdk-updates/jdk13u [2] https://openjdk.java.net/projects/jdk-updates/maintainers.html From rob.mckenna at oracle.com Tue Feb 18 17:15:08 2020 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 18 Feb 2020 17:15:08 +0000 Subject: [14u Communication] 14.0.1 higher bar Message-ID: <20200218171508.GB16228@yoga> Hi folks, Its getting late in the 14.0.1 cycle so I'm sending a quick message to let you know that from next week we will likely only accept showstoppers or critical regressions for 14.0.1. -Rob From gnu.andrew at redhat.com Wed Feb 19 05:14:03 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 19 Feb 2020 05:14:03 +0000 Subject: [11u] RFR: 8210459, 8218807, 8223678: Support for creating Visual Studio Code projects In-Reply-To: References: Message-ID: <6ef2dfe8-b96e-ddc2-dbba-45a80aa4a8e0@redhat.com> On 30/12/2019 20:18, Volker Simonis wrote: > Hi, > I'd like to downport the support for Visual Studio Code project > creation to 11u. I think we will have to support 11u for quite some > years and it makes sense to have as good as possible tool support in > 11u as well. I just came across this proposal in the process of backporting JDK-8232748: "Build static versions of certain JDK libraries". The only hunk of that changeset which isn't a simple context difference is that which applies to JdkNativeCompilation.gmk and the FindLib & FindStaticLib rules it introduces. I was going to just drop this hunk, as I didn't see any reason to backport JDK-8210459, but then I saw your existing RFR referenced on the bug. If JDK-8210459 is to be backported, I thus need this in place before posting JDK-8232748 for review. > > This mail is especially intended to get a review from the build team > that the few changes to the patches are OK: > > https://bugs.openjdk.java.net/browse/JDK-8210459 > http://cr.openjdk.java.net/~simonis/webrevs/2019/8210459/ > > https://bugs.openjdk.java.net/browse/JDK-8218807 > http://cr.openjdk.java.net/~simonis/webrevs/2019/8218807/ > > https://bugs.openjdk.java.net/browse/JDK-8223678 > http://cr.openjdk.java.net/~simonis/webrevs/2019/8223678/ > > The downport consists of three changes which are additive (i.e. later > changes depend on earlier ones). That's why I decided to post just one > RFR, because looking at a single change makes no sense without the > corresponding context. The changes mostly apply cleanly except for > very few places where we need manual adjustments because of changed > context. I'm just going to stick to reviewing JDK-8210459 here. I feel an RFR should stick to just the one single change, which a reviewer can then apply and test on the current state of the repository. Having three changes in one RFR is quite overwhelming and the later changes are being applied against a repository state which doesn't yet exist. I suspect that may be one of the reasons this review has not been undertaken thus far. > > These changes only touch make files and actually only add new features > to the make system, so the normal build results shouldn't be affected. > I've tested that the build still works on Linux and Windows and "make > test-make" succeeds. > > Following some details on the three changes: > > 8210459: Add support for generating compile_commands.json > > The initial change which creates the compile_commands.json file (i.e. > "make compile_commands"). This file can be used for many tools (e.g. > CLion IDE, clangd, etc..) > Applies cleanly except for the following hunk, which has a different context: > > ORIGINAL > ======== > CFLAGS_solaris := -KPIC, \ > CFLAGS_macosx := -fPIC, \ > DISABLED_WARNINGS_clang := format-nonliteral, \ > - LDFLAGS := $(UNPACKEXE_ZIPOBJS) \ > - $(LDFLAGS_JDKEXE) $(LDFLAGS_CXX_JDK) \ > + LDFLAGS := $(LDFLAGS_JDKEXE) $(LDFLAGS_CXX_JDK) \ > > JDK11u > ====== > CFLAGS_linux := -fPIC, \ > CFLAGS_solaris := -KPIC, \ > CFLAGS_macosx := -fPIC, \ > - LDFLAGS := $(UNPACKEXE_ZIPOBJS) \ > - $(LDFLAGS_JDKEXE) $(LDFLAGS_CXX_JDK) \ > + LDFLAGS := $(LDFLAGS_JDKEXE) $(LDFLAGS_CXX_JDK) \ > This looks fine. I compared your patch and the original changeset and this is indeed the only difference, and only occurs because of the additional disabled warning for Clang. > > Finally, I've added an additional fix to this last change, whch fixes > the make tests (i.e. "make test-make"). These tests are currently > broken in jdk11u. They have been broken by JDK-8212028 (which has > already been downported to jdk11u) and fixed in jdk 12 as part of > "8210958: Rename "make run-test" to "make test"" (which hasn't been > downported yet and probably won't be donwported at all). Because the > fix is trivial (that's why it was done as part of 8210958 without an > extra bug ID) and because I wanted to run "make test-make" in jdk11u > as well to verify my changes, I've decided to downport this fix as > part of 8223678: > > diff -r 8599975f5b33 test/make/TestMakeBase.gmk > --- a/test/make/TestMakeBase.gmk Tue Feb 12 08:40:43 2019 +0100 > +++ b/test/make/TestMakeBase.gmk Mon Dec 23 22:10:46 2019 +0100 > KWBASE := APA=banan;GURKA=tomat;COUNT=1%202%203%204%205;SUM=1+2+3+4+5;MANY_WORDS=I > have the best words. > > $(eval $(call ParseKeywordVariable, KWBASE, \ > - KEYWORDS := APA GURKA SUM, \ > + SINGLE_KEYWORDS := APA GURKA SUM, \ > STRING_KEYWORDS := COUNT MANY_WORDS, \ > )) > > @@ -364,7 +376,7 @@ > KWBASE_WEIRD := ;;APA=banan;;;GURKA=apelsin;APA=skansen;; > > $(eval $(call ParseKeywordVariable, KWBASE_WEIRD, \ > - KEYWORDS := APA GURKA SUM, \ > + SINGLE_KEYWORDS := APA GURKA SUM, \ > STRING_KEYWORDS := COUNT, \ > )) > I agree it doesn't make sense to backport JDK-8210958, as that's a major change to the test infrastructure. However, I think this warrants its own 11u bug rather than being smuggled in under JDK-8223678. Otherwise, you're just mirroring the same problem that was created by mixing this in with JDK-8210958. An independent bug can describe the breakage and link to the original issue that caused it. 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 From shade at redhat.com Wed Feb 19 08:50:35 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 19 Feb 2020 09:50:35 +0100 Subject: [14u Communication] 14.0.1 higher bar In-Reply-To: <20200218171508.GB16228@yoga> References: <20200218171508.GB16228@yoga> Message-ID: <67b11b29-8bf9-2edd-57cf-9f2db9d8bec2@redhat.com> Hi Rob, On 2/18/20 6:15 PM, Rob McKenna wrote: > Its getting late in the 14.0.1 cycle so I'm sending a quick message to > let you know that from next week we will likely only accept showstoppers > or critical regressions for 14.0.1. Could you explain who and when decides what goes into 14.0.1? Current pushes to jdk-updates/jdk14u are recorded as fixed in 14.0.2. Are you merging current 14.0.2 to 14.0.1 manually? -- Thanks, -Aleksey From yan at azul.com Wed Feb 19 10:56:58 2020 From: yan at azul.com (Yuri Nesterenko) Date: Wed, 19 Feb 2020 13:56:58 +0300 Subject: [13u-communication] End of maintenance & invitation for new maintainers In-Reply-To: <20200218170952.GA16228@yoga> References: <20200218170952.GA16228@yoga> Message-ID: <6fc8d760-75d3-10a6-49f9-64b14ca89365@azul.com> Thank You. I would like to nominate myself to the role of lead maintainer of the OpenJDK 13u Updates forest. I have been working on Java and OpenJDK development for quite some time. I have actively participated in development of AWT and as a Reviewer in JDK, JDK Updates and several other OpenJDK projects. In my role as lead maintainer for 13u, I anticipate the backing of several other OpenJDK Updates committers currently employed at Azul, who have been actively contributing to 11u, 8u, and 7u updates, as well as any others who wish to join in the effort. As some of you already know, Azul plans to continue building quarterly community updates for OpenJDK 13 under what we have been referring to as "MTS" (Mid Term Support) releases. Rather than providing a long term support horizon, MTS releases are intended to provide an update overlap window of 18 months with the next LTS release (presumably JDK 17). The key purpose of MTS updates is to increase the likelihood of production adoption of releases between LTSs, allow users to more quickly adopt new capabilities introduced with Feature releases, and increase the production-based feedback and bug flow that can hopefully make the next LTS even better. By committing to provide updates until 18 months after the next LTS comes out, we expect to increase the production adoption of MTS releases, as end users can expect community updates to continue to arrive until well after the next LTS is mature, stable, and can be transitioned to for production use at low risk. We anticipate our first planned 13u MTS update to be April 2020. Likely using the update version 13.0.3. As such, we have chosen to commit the appropriate resources to do this work, and intend to maintain continuity for OpenJDK's JDK 13u, much like it has for JDK 11u. We would be happy see others join in the 13u effort as well. We have immediate plans to backport some 220+ changes already ported to JDK 11u and maintain security level on par with other update releases. Having a rather tight schedule, it may be not prudent to add all the bug backports to the April, 14? update but we hope to see all of them in by July. Yuri Nesterenko (http://openjdk.java.net/census#yan) --yan On 18.02.2020 20:09, Rob McKenna wrote: > I'm sending this mail to notify the community that the current maintainers > intend to step down as maintainers for the JDK 13 Updates forest [1] at the > end of March, or sooner, if new maintainers were to step up. [2] > > This being the case we would like to invite prospective new maintainers to > step forward at this point to ensure a smooth transition should they wish to > maintain this forest beyond the end of March. > > -Rob > > [1] https://hg.openjdk.java.net/jdk-updates/jdk13u > [2] https://openjdk.java.net/projects/jdk-updates/maintainers.html From martin.doerr at sap.com Wed Feb 19 15:18:07 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 19 Feb 2020 15:18:07 +0000 Subject: [11u] RFR (XS): 8239466: Loss of precision in counter decay calculation in 11u backport of JDK-8237375 In-Reply-To: References: Message-ID: Hi Christoph, looks good. Thanks for fixing. Best regards, Martin From: Langer, Christoph Sent: Mittwoch, 19. Februar 2020 16:14 To: jdk-updates-dev at openjdk.java.net; Doerr, Martin ; Volker Simonis Subject: [11u] RFR (XS): 8239466: Loss of precision in counter decay calculation in 11u backport of JDK-8237375 Hi, I have backported JDK-8237375 [0] [1] to jdk11u (11.0.7) with the change [2]. Unfortunately, the backport contains a flaw that leads to a loss of precision when checking whether a counter decay is needed in method is_decay_needed() which in turn might yield the same test failures that we wanted to fix. Please review the correction: http://cr.openjdk.java.net/~clanger/webrevs/8239466.11u/src/hotspot/share/runtime/compilationPolicy.cpp.frames.html Thanks Christoph [0] https://bugs.openjdk.java.net/browse/JDK-8237375 [1] https://hg.openjdk.java.net/jdk/jdk/rev/2a0e2304e68b [2] https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/695c552952bc From christoph.langer at sap.com Wed Feb 19 15:14:11 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 19 Feb 2020 15:14:11 +0000 Subject: [11u] RFR (XS): 8239466: Loss of precision in counter decay calculation in 11u backport of JDK-8237375 Message-ID: Hi, I have backported JDK-8237375 [0] [1] to jdk11u (11.0.7) with the change [2]. Unfortunately, the backport contains a flaw that leads to a loss of precision when checking whether a counter decay is needed in method is_decay_needed() which in turn might yield the same test failures that we wanted to fix. Please review the correction: http://cr.openjdk.java.net/~clanger/webrevs/8239466.11u/src/hotspot/share/runtime/compilationPolicy.cpp.frames.html Thanks Christoph [0] https://bugs.openjdk.java.net/browse/JDK-8237375 [1] https://hg.openjdk.java.net/jdk/jdk/rev/2a0e2304e68b [2] https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/695c552952bc From gnu.andrew at redhat.com Wed Feb 19 17:44:42 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 19 Feb 2020 17:44:42 +0000 Subject: RFR (backport CSR): 8239395: Accounting currency format support In-Reply-To: <955005dd-7c3a-c407-1be0-7189e1057cff@oracle.com> References: <955005dd-7c3a-c407-1be0-7189e1057cff@oracle.com> Message-ID: <018309cc-f820-c3ad-2c47-e8256e0c3302@redhat.com> On 19/02/2020 05:45, Joe Darcy wrote: > Hi Paul, > > This looks like a spec change to a Java SE API so would be out of bounds > for 11u without a maintenance update of Java SE 11. > > Naoto, do you agree with that analysis? > > Thanks, > > -Joe > > On 2/18/2020 5:44 PM, Hohensee, Paul wrote: >> Please review the CSR https://bugs.openjdk.java.net/browse/JDK-8239395 >> for a backport of JDK-8215181 to jdk11u. It?s identical to the >> original CSR. >> >> Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8215181 >> Original CSR: https://bugs.openjdk.java.net/browse/JDK-8218770 >> Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8239394 >> Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8239395 >> >> Thanks, >> Paul >> > > This seems like it should be sent to jdk-updates-dev, not jdk8u-dev. I tend to agree with Joe Darcy that this would introduce new requirements on those implementing NumberFormat.getCurrencyFormat and is thus a spec change which alters the API requirements of Java 11. I presume current OpenJDK 11 would fail the tests in test/jdk/java/util/Locale/bcp47u/CurrencyFormatTests.java? -- 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 From hohensee at amazon.com Wed Feb 19 18:13:31 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 19 Feb 2020 18:13:31 +0000 Subject: RFR (backport CSR): 8239395: Accounting currency format support In-Reply-To: <5cee4ac1-dfcf-6580-71af-6b84ae84a69a@oracle.com> References: <955005dd-7c3a-c407-1be0-7189e1057cff@oracle.com> <8C09617D-2DA2-47F4-B8B7-A453D8991E53@amazon.com> <5cee4ac1-dfcf-6580-71af-6b84ae84a69a@oracle.com> Message-ID: In that case, I'll withdraw it, unless a maintenance review comes along. Thanks, Paul ?On 2/19/20, 9:01 AM, "Joe Darcy" wrote: As a practical matter, no. Since a Java SE specification is modified by this changeset, a maintenance review (MR) would be needed for Java SE 11 for this change to go into 11u. HTH, -Joe On 2/19/2020 8:09 AM, Hohensee, Paul wrote: > So, not backportable? > > Paul > > On 2/19/20, 5:23 AM, "naoto.sato at oracle.com" wrote: > > Hi Joe, Paul, > > Yes, I was thinking the same. It is a spec change in 14. > > Naoto > > On 2/18/20 9:45 PM, Joe Darcy wrote: > > Hi Paul, > > > > This looks like a spec change to a Java SE API so would be out of bounds > > for 11u without a maintenance update of Java SE 11. > > > > Naoto, do you agree with that analysis? > > > > Thanks, > > > > -Joe > > > > On 2/18/2020 5:44 PM, Hohensee, Paul wrote: > >> Please review the CSR https://bugs.openjdk.java.net/browse/JDK-8239395 > >> for a backport of JDK-8215181 to jdk11u. It?s identical to the > >> original CSR. > >> > >> Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8215181 > >> Original CSR: https://bugs.openjdk.java.net/browse/JDK-8218770 > >> Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8239394 > >> Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8239395 > >> > >> Thanks, > >> Paul > >> > > From volker.simonis at gmail.com Wed Feb 19 19:42:42 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 19 Feb 2020 20:42:42 +0100 Subject: [11u] RFR (XS): 8239466: Loss of precision in counter decay calculation in 11u backport of JDK-8237375 In-Reply-To: References: Message-ID: On Wed, Feb 19, 2020 at 4:26 PM Langer, Christoph wrote: > > Hi, > > > > I have backported JDK-8237375 [0] [1] to jdk11u (11.0.7) with the change [2]. > > > > Unfortunately, the backport contains a flaw that leads to a loss of precision when checking whether a counter decay is needed in method is_decay_needed() which in turn might yield the same test failures that we wanted to fix. Please review the correction: > What a pity :( Sorry that I missed that in the first review. > > http://cr.openjdk.java.net/~clanger/webrevs/8239466.11u/src/hotspot/share/runtime/compilationPolicy.cpp.frames.html > Looks good now! Thanks for fixing, Volker > > Thanks > > Christoph > > > > [0] https://bugs.openjdk.java.net/browse/JDK-8237375 > > [1] https://hg.openjdk.java.net/jdk/jdk/rev/2a0e2304e68b > > [2] https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/695c552952bc > > From hohensee at amazon.com Wed Feb 19 19:59:28 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 19 Feb 2020 19:59:28 +0000 Subject: Hotspot Express (HSX) Message-ID: <1A373C6F-D6F7-4BB1-A5BF-2E77D087CC5B@amazon.com> HSX was mentioned in the ?Backporting features? thread a few times. As one of those who initiated HSX back in 6u4 (it was actually Dave Cox?s idea), I thought I?d chime in. HSX was adopted not only because it made the latest performance and features available in update releases, but also because of the (large) negative impact on JDK 6 of resource diversion to JDK 5 backports. The 6-month release train amounts to JSX (JDK Express), so it?s not like the concept is new or untested. And, all the other ?unexpected? positive results of instituting JSX were presaged by HSX. It?s hard to argue for JSX and against HSX at the same time. :) HSX was just Hotspot back in the day, but looks to include the CI and Graal now (I?ll just call the whole thing ?Hotspot?), so it?s a bigger project than before. I?ve been playing around with supporting HSX in the latest LTS release. Right now, that?s dropping Hotspot from JSX into the latest JDK 11 update release (14 into 11.0.6). When JDK 17 ships, that would become the HSX target, replacing JDK 11. I?m looking at replacing JDK 11?s make/hotspot, src/hotspot, test/hotspot, and src/jdk.internal.* with the corresponding JSX release directories. I?m including backports to JDK 11 common code (mostly makefiles and the odd library) to make it possible to build both vanilla JDK 11 and HSX in the same repo. If HSX were policy, supporting two kinds of builds wouldn?t be necessary. :) A big attraction of HSX is that higher performance and features can be made available in the latest LTS release. JSX was supposed to make a separate HSX unnecessary, but there hasn?t been much JSX adoption. Azul?s MTS proposal might help, but it involves even more backporting effort to support two more release trains. The big problem is that users are skeptical based on their experience with the large amount of change in LTS releases. They haven?t really thought about how the much smaller amount of change in JSX releases means that they?re much less risky to adopt than LTS releases. When HSX was rolled out in 6u4, there was the same skepticism, but it quickly went away. Think of HSX as a kind of half-way house. If HSX were available and users accepted it again, imo they?d be much more inclined to try JSX. If JSX were widely accepted, in the long run both HSX and LTS releases could be dispensed with. There?s a tradeoff between the engineering resources necessary to do backports and those necessary to keep Hotspot viable in the previous LTS release. The cost of doing backports is rather high, with engineers from Oracle, Red Hat, SAP, Amazon, Azul, and others participating. From Aleksey?s pushes- scripts, there were 519 Hotspot (just to src/hotspot) pushes to 11.0.3 through 11.0.6, and 120 for 11.0.7 so far. These are not small numbers and are about half the totals, which are 1038 for 11.0.3 through 11.0.6, and 275 for 11.0.7. And, Oracle and the rest of the community do the same work twice. For HSX, that would not be the case. For HSX, Hotspot must be able to find out in which JDK it?s executing and adjust accordingly. There?s a school of thought that doing so constrains what you can do with Hotspot and the JDK, but I didn?t see that when HSX was policy. Unfortunately (from my pov), most of the small amount of code needed has been removed from Hotspot, some fairly recently. The interface between Hotspot and the JDK libraries would have to be (re)defined and come under CSR control, and Hotspot build/test would have to be (re)made truly independent of the rest of the JDK. Imo, doing these would be a good idea whether or not HSX exists. My experience so far has been that the Hotspot/JDK library interface changes quite slowly and is thus easy to track, but that build/test changes rapidly and is heavily interdependent between Hotspot and the rest of the JDK. Another issue is QA. While it?s true that full test cycles must be done on the latest LTS whether or not HSX is used, imo the inherent quality of the latest Hotspot is greater than that of a patched Hotspot. That?s because backport patches may not work well outside the context in which they were made and thus lead to instability. The more patches, the worse the problem becomes. When HSX was policy, there were essentially no extra QA issues with running Hotspot in earlier releases. Thanks, Paul From claes.redestad at oracle.com Wed Feb 19 20:26:29 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 19 Feb 2020 21:26:29 +0100 Subject: Hotspot Express (HSX) In-Reply-To: <1A373C6F-D6F7-4BB1-A5BF-2E77D087CC5B@amazon.com> References: <1A373C6F-D6F7-4BB1-A5BF-2E77D087CC5B@amazon.com> Message-ID: <271678a3-3392-bd91-4a54-215cb20cc4ba@oracle.com> On 2020-02-19 20:59, Hohensee, Paul wrote: > It?s hard to argue for JSX and against HSX at the same time.:) Quite the opposite: The existence of JSX, as you put it, makes HSX very questionable since a new JDK will be available with short notice for those users who need it. HSX made more sense in a world where the next big JDK was up to three years away. In my opinion, the rapid cadence makes backports of anything except the most critical patches to enhance stability questionable - but I've heard that's not an uncontroversial opinion. :-) It's also easy to argue against HSX for many other reasons: it complicates the code base, the QA effort is not at all lessened since you still had to test every supported combination of JDK x HS (the more complex code meant there were more places for code to hide, though), and it ultimately goes against the goal of optimizing performance. Why? Well, it means anything where the VM and JDK interacts need to use dynamic linkage and extra check. Does this field exist in this java class? Is this the layout of java.lang.String this time around? While not hugely impactful, a great number of improvements to startup, footprint and some throughput performance in the last few releases has come from *removing* the remnants of HSX, as it existed in the past, and I think the OpenJDK is better for it. Please don't bring HSX back! Thanks! /Claes From manc at google.com Wed Feb 19 21:01:56 2020 From: manc at google.com (Man Cao) Date: Wed, 19 Feb 2020 13:01:56 -0800 Subject: Should I use Bug ID JDK-8239012 or JDK-8234608 for this 14u backport? Message-ID: Hi, I'm trying to submit a backport to 14u: https://bugs.openjdk.java.net/browse/JDK-8239012. The problem is that I initially created JDK-8234608 , and "Fix Version" was set to 14. When I pushed it to jdk/jdk, the major version has become 15, so "HG Updates" automatically created JDK-8239012 . I have closed JDK-8234608 as a duplicate, but the commit record in JDK-8239012 still shows JDK-8234608. So the question is, when I push it to 14u, should I keep using JDK-8234608 as the bug ID in the commit message, or can I change it to JDK-8239012? -Man From jesper.wilhelmsson at oracle.com Wed Feb 19 21:15:22 2020 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 19 Feb 2020 22:15:22 +0100 Subject: Should I use Bug ID JDK-8239012 or JDK-8234608 for this 14u backport? In-Reply-To: References: Message-ID: Since JDK-8234608 is the bug mentioned in the commit comment, let's use that one as the main bug. Let me clean that up for you. Please don't push the backport until I get back to you. /Jesper > On 19 Feb 2020, at 22:01, Man Cao wrote: > > Hi, > > I'm trying to submit a backport to 14u: > https://bugs.openjdk.java.net/browse/JDK-8239012. > The problem is that I initially created JDK-8234608 > , and "Fix Version" was > set to 14. When I pushed it to jdk/jdk, the major version has become 15, so > "HG Updates" automatically created JDK-8239012 > . > I have closed JDK-8234608 as > a duplicate, but the commit record > in JDK-8239012 > still shows JDK-8234608. > > So the question is, when I push it to 14u, should I keep using JDK-8234608 > as the bug ID in the commit message, or can I change it to JDK-8239012? > > -Man From jesper.wilhelmsson at oracle.com Wed Feb 19 21:25:51 2020 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 19 Feb 2020 22:25:51 +0100 Subject: Should I use Bug ID JDK-8239012 or JDK-8234608 for this 14u backport? In-Reply-To: References: Message-ID: <49BF8B90-E358-445D-9EF6-2C0B2D2BA42E@oracle.com> You should be good to go now. Now you can use JDK-8234608 as the bugid for the backport as well. /Jesper > On 19 Feb 2020, at 22:15, Jesper Wilhelmsson wrote: > > Since JDK-8234608 is the bug mentioned in the commit comment, let's use that one as the main bug. Let me clean that up for you. > Please don't push the backport until I get back to you. > /Jesper > > >> On 19 Feb 2020, at 22:01, Man Cao wrote: >> >> Hi, >> >> I'm trying to submit a backport to 14u: >> https://bugs.openjdk.java.net/browse/JDK-8239012. >> The problem is that I initially created JDK-8234608 >> , and "Fix Version" was >> set to 14. When I pushed it to jdk/jdk, the major version has become 15, so >> "HG Updates" automatically created JDK-8239012 >> . >> I have closed JDK-8234608 as >> a duplicate, but the commit record >> in JDK-8239012 >> still shows JDK-8234608. >> >> So the question is, when I push it to 14u, should I keep using JDK-8234608 >> as the bug ID in the commit message, or can I change it to JDK-8239012? >> >> -Man > From manc at google.com Wed Feb 19 21:32:19 2020 From: manc at google.com (Man Cao) Date: Wed, 19 Feb 2020 13:32:19 -0800 Subject: Should I use Bug ID JDK-8239012 or JDK-8234608 for this 14u backport? In-Reply-To: <49BF8B90-E358-445D-9EF6-2C0B2D2BA42E@oracle.com> References: <49BF8B90-E358-445D-9EF6-2C0B2D2BA42E@oracle.com> Message-ID: Thanks for the help! Now I know how to properly handle cases like this. -Man On Wed, Feb 19, 2020 at 1:26 PM Jesper Wilhelmsson < jesper.wilhelmsson at oracle.com> wrote: > You should be good to go now. Now you can use JDK-8234608 as the bugid for > the backport as well. > /Jesper > > > On 19 Feb 2020, at 22:15, Jesper Wilhelmsson < > jesper.wilhelmsson at oracle.com> wrote: > > > > Since JDK-8234608 is the bug mentioned in the commit comment, let's use > that one as the main bug. Let me clean that up for you. > > Please don't push the backport until I get back to you. > > /Jesper > > > > > >> On 19 Feb 2020, at 22:01, Man Cao wrote: > >> > >> Hi, > >> > >> I'm trying to submit a backport to 14u: > >> https://bugs.openjdk.java.net/browse/JDK-8239012. > >> The problem is that I initially created JDK-8234608 > >> , and "Fix Version" > was > >> set to 14. When I pushed it to jdk/jdk, the major version has become > 15, so > >> "HG Updates" automatically created JDK-8239012 > >> . > >> I have closed JDK-8234608 < > https://bugs.openjdk.java.net/browse/JDK-8234608> as > >> a duplicate, but the commit record > >> in JDK-8239012 > >> still shows > JDK-8234608. > >> > >> So the question is, when I push it to 14u, should I keep using > JDK-8234608 > >> as the bug ID in the commit message, or can I change it to JDK-8239012? > >> > >> -Man > > > > From hohensee at amazon.com Wed Feb 19 21:50:43 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 19 Feb 2020 21:50:43 +0000 Subject: Hotspot Express (HSX) In-Reply-To: <271678a3-3392-bd91-4a54-215cb20cc4ba@oracle.com> References: <1A373C6F-D6F7-4BB1-A5BF-2E77D087CC5B@amazon.com> <271678a3-3392-bd91-4a54-215cb20cc4ba@oracle.com> Message-ID: <41CE1D47-5F5D-424D-AABE-07AD640F0E56@amazon.com> Given your stance on backports and JSX adoption, I can see your point and even agree with it. The problem is that the vast majority of users don?t want to use JSX. That's definitely the case inside Amazon. HSX does complicate the code base a bit, but is that worse than doing 600+ backports and counting? Also, I'm curious about how removing HSX remnants has improved performance. Can anyone point me at specifics? Thanks, Paul ?On 2/19/20, 12:23 PM, "Claes Redestad" wrote: On 2020-02-19 20:59, Hohensee, Paul wrote: > It?s hard to argue for JSX and against HSX at the same time.:) Quite the opposite: The existence of JSX, as you put it, makes HSX very questionable since a new JDK will be available with short notice for those users who need it. HSX made more sense in a world where the next big JDK was up to three years away. In my opinion, the rapid cadence makes backports of anything except the most critical patches to enhance stability questionable - but I've heard that's not an uncontroversial opinion. :-) It's also easy to argue against HSX for many other reasons: it complicates the code base, the QA effort is not at all lessened since you still had to test every supported combination of JDK x HS (the more complex code meant there were more places for code to hide, though), and it ultimately goes against the goal of optimizing performance. Why? Well, it means anything where the VM and JDK interacts need to use dynamic linkage and extra check. Does this field exist in this java class? Is this the layout of java.lang.String this time around? While not hugely impactful, a great number of improvements to startup, footprint and some throughput performance in the last few releases has come from *removing* the remnants of HSX, as it existed in the past, and I think the OpenJDK is better for it. Please don't bring HSX back! Thanks! /Claes From david.holmes at oracle.com Wed Feb 19 22:53:32 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 Feb 2020 08:53:32 +1000 Subject: Hotspot Express (HSX) In-Reply-To: <41CE1D47-5F5D-424D-AABE-07AD640F0E56@amazon.com> References: <1A373C6F-D6F7-4BB1-A5BF-2E77D087CC5B@amazon.com> <271678a3-3392-bd91-4a54-215cb20cc4ba@oracle.com> <41CE1D47-5F5D-424D-AABE-07AD640F0E56@amazon.com> Message-ID: On 20/02/2020 7:50 am, Hohensee, Paul wrote: > Given your stance on backports and JSX adoption, I can see your point and even agree with it. The problem is that the vast majority of users don?t want to use JSX. That's definitely the case inside Amazon. There was concern when the new release model was announced that people would view the LTS releases as the "real" releases with the interim releases just being re-badged "update releases". Backporting everything to the last LTS release, or equivalently moving to a HSX model, just panders to that view and undermines the new release model in my personal opinion. If you are prepared to use 11u with (nearly) everything from 13 (for example) backported into it, then why not just use 13? > HSX does complicate the code base a bit, but is that worse than doing 600+ backports and counting? Yes it is worse. HSX impacts everyone working on the bleeding edge of JDK/JVM development. Backports are a cost to those who choose to make the backports only - that cost is high only because, again in my personal opinion, far too much is being backported. With HSX, particularly within JSX, every change to the VM has to be made with consideration of whether this change will impact any previous release in an adverse way, and whether the change will need to be made conditional based on the version of the JDK used. The amount of baggage the VM has to carry and maintain just grows and grows, making the whole code base harder to understand and maintain. You'd need to run performance tests across all previous release before accepting any change - which is simply impractical. > Also, I'm curious about how removing HSX remnants has improved performance. Can anyone point me at specifics? By removing dynamic checks, simplifying and streamlining code. Just my personal opinions having also worked on the previous HSX and its subsequent eradication (still ongoing). Cheers, David ----- > Thanks, > Paul > > ?On 2/19/20, 12:23 PM, "Claes Redestad" wrote: > > On 2020-02-19 20:59, Hohensee, Paul wrote: > > It?s hard to argue for JSX and against HSX at the same time.:) > > Quite the opposite: The existence of JSX, as you put it, makes HSX very > questionable since a new JDK will be available with short notice for > those users who need it. HSX made more sense in a world where the next > big JDK was up to three years away. > > In my opinion, the rapid cadence makes backports of anything except the > most critical patches to enhance stability questionable - but I've heard > that's not an uncontroversial opinion. :-) > > It's also easy to argue against HSX for many other reasons: it > complicates the code base, the QA effort is not at all lessened since > you still had to test every supported combination of JDK x HS (the more > complex code meant there were more places for code to hide, though), and > it ultimately goes against the goal of optimizing performance. > > Why? Well, it means anything where the VM and JDK interacts need to use > dynamic linkage and extra check. Does this field exist in this java > class? Is this the layout of java.lang.String this time around? While > not hugely impactful, a great number of improvements to startup, > footprint and some throughput performance in the last few releases has > come from *removing* the remnants of HSX, as it existed in the past, > and I think the OpenJDK is better for it. > > Please don't bring HSX back! > > Thanks! > > /Claes > > > > > From claes.redestad at oracle.com Wed Feb 19 23:10:14 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 20 Feb 2020 00:10:14 +0100 Subject: Hotspot Express (HSX) In-Reply-To: <41CE1D47-5F5D-424D-AABE-07AD640F0E56@amazon.com> References: <1A373C6F-D6F7-4BB1-A5BF-2E77D087CC5B@amazon.com> <271678a3-3392-bd91-4a54-215cb20cc4ba@oracle.com> <41CE1D47-5F5D-424D-AABE-07AD640F0E56@amazon.com> Message-ID: On 2020-02-19 22:50, Hohensee, Paul wrote: > Given your stance on backports and JSX adoption, I can see your point and even agree with it. The problem is that the vast majority of users don?t want to use JSX. That's definitely the case inside Amazon. And why is that, Paul? > > HSX does complicate the code base a bit, but is that worse than doing 600+ backports and counting? Yes. :-) Or rather: Even if a vast majority of users only skip from LTS to LTS, I believe only a small fraction of those backports have been *strictly necessary*. There are definitely resources that can be diverted from backporting (which helps users stuck on some old release) to maintaining and improving the tip (which brings *everyone* value sooner or later, be it next quarter or in three years). Granted, I've backported a few things that weren't strictly necessary, too, such as various startup optimizations, but always with the motivation that without a fix there would have been regressions caused by other, more critical changes. I'm not religiously against backports. :-) But even if you don't agree the virtues of focusing engineering resources on maintaining and working on the tip, we should stay well clear of things that make maintaining the tip harder than it already is. Because it is already really hard. And HSX is one of the worse things you can do to make that maintenance harder. > Also, I'm curious about how removing HSX remnants has improved performance. Can anyone point me at specifics? No. It's an accumulation of small improvements over time, including a reduction in static footprint, many small startup improvements and some overall performance improvements. But what's really at stake here are all the future features, cleanups and larger improvements that will be just that little bit *harder* to do *right* if hsx was still a thing. I won't go so far as to say it'd make any of the cool stuff happening at or near the tip now impossible. But it would without a doubt slow down progress to the detriment of everyone. Perhaps even enough to make some throw their hands in the air and pick up ranching. Just sayin'. /Claes From hohensee at amazon.com Wed Feb 19 23:58:24 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 19 Feb 2020 23:58:24 +0000 Subject: Hotspot Express (HSX) In-Reply-To: References: <1A373C6F-D6F7-4BB1-A5BF-2E77D087CC5B@amazon.com> <271678a3-3392-bd91-4a54-215cb20cc4ba@oracle.com> <41CE1D47-5F5D-424D-AABE-07AD640F0E56@amazon.com> Message-ID: <4D5DA55E-ACCD-4DE9-8E09-37BBE40205B4@amazon.com> Re JSX lack of adoption, the argument is that it's always taken at least a year to stabilize a new release, and with 6 months between releases none of the non-LTS releases will ever be stable. Doesn't matter whether that's true or not, it's what people believe based on previous experience with 8 and 11. The relatively large degree of incompatibility between 8 and 11 is another hurdle. People remember that and don't want to worry about language and library backward compatibility every 6 months, no matter how small those incompatibilities are. Doing a lot of backports is a response to that customer demand. Hotspot is "under the covers", so to speak, so HSX was easier to sell than is JSX. Paul ?On 2/19/20, 3:07 PM, "Claes Redestad" wrote: On 2020-02-19 22:50, Hohensee, Paul wrote: > Given your stance on backports and JSX adoption, I can see your point and even agree with it. The problem is that the vast majority of users don?t want to use JSX. That's definitely the case inside Amazon. And why is that, Paul? > > HSX does complicate the code base a bit, but is that worse than doing 600+ backports and counting? Yes. :-) Or rather: Even if a vast majority of users only skip from LTS to LTS, I believe only a small fraction of those backports have been *strictly necessary*. There are definitely resources that can be diverted from backporting (which helps users stuck on some old release) to maintaining and improving the tip (which brings *everyone* value sooner or later, be it next quarter or in three years). Granted, I've backported a few things that weren't strictly necessary, too, such as various startup optimizations, but always with the motivation that without a fix there would have been regressions caused by other, more critical changes. I'm not religiously against backports. :-) But even if you don't agree the virtues of focusing engineering resources on maintaining and working on the tip, we should stay well clear of things that make maintaining the tip harder than it already is. Because it is already really hard. And HSX is one of the worse things you can do to make that maintenance harder. > Also, I'm curious about how removing HSX remnants has improved performance. Can anyone point me at specifics? No. It's an accumulation of small improvements over time, including a reduction in static footprint, many small startup improvements and some overall performance improvements. But what's really at stake here are all the future features, cleanups and larger improvements that will be just that little bit *harder* to do *right* if hsx was still a thing. I won't go so far as to say it'd make any of the cool stuff happening at or near the tip now impossible. But it would without a doubt slow down progress to the detriment of everyone. Perhaps even enough to make some throw their hands in the air and pick up ranching. Just sayin'. /Claes From christoph.langer at sap.com Thu Feb 20 10:16:05 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 20 Feb 2020 10:16:05 +0000 Subject: [11u] RFR (XS): 8239466: Loss of precision in counter decay calculation in 11u backport of JDK-8237375 In-Reply-To: References: Message-ID: Thanks for the reviews, Volker and Martin ?? > -----Original Message----- > From: Volker Simonis > Sent: Mittwoch, 19. Februar 2020 20:43 > To: Langer, Christoph > Cc: jdk-updates-dev at openjdk.java.net; Doerr, Martin > > Subject: Re: [11u] RFR (XS): 8239466: Loss of precision in counter decay > calculation in 11u backport of JDK-8237375 > > On Wed, Feb 19, 2020 at 4:26 PM Langer, Christoph > wrote: > > > > Hi, > > > > > > > > I have backported JDK-8237375 [0] [1] to jdk11u (11.0.7) with the change > [2]. > > > > > > > > Unfortunately, the backport contains a flaw that leads to a loss of precision > when checking whether a counter decay is needed in method > is_decay_needed() which in turn might yield the same test failures that we > wanted to fix. Please review the correction: > > > > What a pity :( > Sorry that I missed that in the first review. > > > > > > http://cr.openjdk.java.net/~clanger/webrevs/8239466.11u/src/hotspot/shar > e/runtime/compilationPolicy.cpp.frames.html > > > > Looks good now! > > Thanks for fixing, > Volker > > > > > > Thanks > > > > Christoph > > > > > > > > [0] https://bugs.openjdk.java.net/browse/JDK-8237375 > > > > [1] https://hg.openjdk.java.net/jdk/jdk/rev/2a0e2304e68b > > > > [2] https://hg.openjdk.java.net/jdk-updates/jdk11u- > dev/rev/695c552952bc > > > > From rene.schuenemann at gmail.com Thu Feb 20 11:49:19 2020 From: rene.schuenemann at gmail.com (=?UTF-8?B?UmVuw6kgU2Now7xuZW1hbm4=?=) Date: Thu, 20 Feb 2020 12:49:19 +0100 Subject: [11u] RFR: 8238534: Deep sign macOS bundles before bundle archive is being created Message-ID: Hi, I would like to downport 8238534 to jdk11u. This change does the code signing of the complete JDK/JRE bundle an therefore provides all the necessary code signing prerequisites which are needed for the Apple notarization. I had to do a minor adjustment for jdk11 since the "isTargetOs" macro is not working in jdk11 Line 227: - ifeq ($(call isTargetOs, macosx)+$(DEBUG_LEVEL), true+release) + ifeq ($(OPENJDK_TARGET_OS)-$(DEBUG_LEVEL), macosx-release) https://bugs.openjdk.java.net/browse/JDK-8238534 https://hg.openjdk.java.net/jdk/jdk/rev/6f40f03179f9 http://cr.openjdk.java.net/~rschuenemann/wr/2020/8238534-macos_sign_bundles-jdk11u/01 Rene From dalibor.topic at oracle.com Thu Feb 20 11:53:39 2020 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 20 Feb 2020 12:53:39 +0100 Subject: [13u-communication] End of maintenance & invitation for new maintainers In-Reply-To: <6fc8d760-75d3-10a6-49f9-64b14ca89365@azul.com> References: <20200218170952.GA16228@yoga> <6fc8d760-75d3-10a6-49f9-64b14ca89365@azul.com> Message-ID: <3ff0a21f-cbc1-718d-4f55-7625d422fc51@oracle.com> Hi Yuri, thank you for your nomination. As a process reminder https://openjdk.java.net/projects/jdk-updates/maintainers.html says "After a one-week nomination period, the Project Lead will select a candidate from amongst the nominees and then ratify this selection via a one-week Lazy Consensus vote of this Project's Committers and Reviewers." The nomination period ends a week after Rob's message, i.e. on 25.2. cheers, dalibor topic On 19.02.2020 11:56, Yuri Nesterenko wrote: > Thank You. > > I would like to nominate myself to the role of lead maintainer of the > OpenJDK 13u Updates forest. I have been working on Java and OpenJDK > development for quite some time. I have actively participated in > development of AWT and as a Reviewer in JDK, JDK Updates and several > other OpenJDK projects. In my role as lead maintainer for 13u, I > anticipate the backing of several other OpenJDK Updates committers > currently employed at Azul, who have been actively contributing to 11u, > 8u, and 7u updates, as well as any others who wish to join in the effort. > > As some of you already know, Azul plans to continue building quarterly > community updates for OpenJDK 13 under what we have been referring to as > "MTS" (Mid Term Support) releases. Rather than providing a long term > support horizon, MTS releases are intended to provide an update overlap > window of 18 months with the next LTS release (presumably JDK 17). The > key purpose of MTS updates is to increase the likelihood of production > adoption of releases between LTSs, allow users to more quickly adopt new > capabilities introduced with Feature releases, and increase the > production-based feedback and bug flow that can hopefully make the next > LTS even better. By committing to provide updates until 18 months after > the next LTS comes out, we expect to increase the production adoption of > MTS releases, as end users can expect community updates to continue to > arrive until well after the next LTS is mature, stable, and can be > transitioned to for production use at low risk. > > We anticipate our first planned 13u MTS update to be April 2020. Likely > using the update version 13.0.3. As such, we have chosen to commit the > appropriate resources to do this work, and intend to maintain continuity > for OpenJDK's JDK 13u, much like it has for JDK 11u. We would be happy > see others join in the 13u effort as well. > > We have immediate plans to backport some 220+ changes already ported to > JDK 11u and maintain security level on par with other update releases. > Having a rather tight schedule, it may be not prudent to add all the bug > backports to the April, 14? update but we hope to see all of them in by > July. > > Yuri Nesterenko (http://openjdk.java.net/census#yan) > > --yan > > On 18.02.2020 20:09, Rob McKenna wrote: >> I'm sending this mail to notify the community that the current maintainers >> intend to step down as maintainers for the JDK 13 Updates forest [1] at the >> end of March, or sooner, if new maintainers were to step up. [2] >> >> This being the case we would like to invite prospective new maintainers to >> step forward at this point to ensure a smooth transition should they wish to >> maintain this forest beyond the end of March. >> >> -Rob >> >> [1] https://hg.openjdk.java.net/jdk-updates/jdk13u >> [2] https://openjdk.java.net/projects/jdk-updates/maintainers.html -- 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 From rob.mckenna at oracle.com Thu Feb 20 14:34:54 2020 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 20 Feb 2020 14:34:54 +0000 Subject: [14u Communication] 14.0.1 higher bar In-Reply-To: <67b11b29-8bf9-2edd-57cf-9f2db9d8bec2@redhat.com> References: <20200218171508.GB16228@yoga> <67b11b29-8bf9-2edd-57cf-9f2db9d8bec2@redhat.com> Message-ID: <20200220143454.GE16228@yoga> Hi Aleksey, So, generally you should always use the RDP2 date to err on the side of caution. However, given the short period of time between the update repo creation and the RDP2 date for 14.0.1 we try to get as many of the (less risky) changes into 14.0.1 even after RDP2. I manually merge these changes into the 14.0.1 stabilization forest as you have surmised. -Rob On 19/02/20 09:50, Aleksey Shipilev wrote: > Hi Rob, > > On 2/18/20 6:15 PM, Rob McKenna wrote: > > Its getting late in the 14.0.1 cycle so I'm sending a quick message to > > let you know that from next week we will likely only accept showstoppers > > or critical regressions for 14.0.1. > > Could you explain who and when decides what goes into 14.0.1? Current pushes to jdk-updates/jdk14u > are recorded as fixed in 14.0.2. Are you merging current 14.0.2 to 14.0.1 manually? > > -- > Thanks, > -Aleksey > From shade at redhat.com Thu Feb 20 14:45:09 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 20 Feb 2020 15:45:09 +0100 Subject: [14u Communication] 14.0.1 higher bar In-Reply-To: <20200220143454.GE16228@yoga> References: <20200218171508.GB16228@yoga> <67b11b29-8bf9-2edd-57cf-9f2db9d8bec2@redhat.com> <20200220143454.GE16228@yoga> Message-ID: <573d9a0e-4903-91fe-1375-beb8ea88ff18@redhat.com> On 2/20/20 3:34 PM, Rob McKenna wrote: > So, generally you should always use the RDP2 date to err on the side of > caution. However, given the short period of time between the update repo > creation and the RDP2 date for 14.0.1 we try to get as many of the (less > risky) changes into 14.0.1 even after RDP2. Yes, that is very good. > I manually merge these changes into the 14.0.1 stabilization forest as > you have surmised. Thanks. -- -Aleksey From christoph.langer at sap.com Fri Feb 21 10:30:26 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 21 Feb 2020 10:30:26 +0000 Subject: [11u] RFR: 8238534: Deep sign macOS bundles before bundle archive is being created In-Reply-To: References: Message-ID: Hi Ren?, thanks for doing the 11u backport of this. The patch looks good. I'll sponsor this for you. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Ren? Sch?nemann > Sent: Donnerstag, 20. Februar 2020 12:49 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8238534: Deep sign macOS bundles before bundle archive > is being created > > Hi, > > I would like to downport 8238534 to jdk11u. This change does the code > signing of the complete JDK/JRE bundle an therefore provides all the > necessary code signing prerequisites which are needed for the Apple > notarization. > > I had to do a minor adjustment for jdk11 since the "isTargetOs" macro > is not working in jdk11 > > Line 227: > > - ifeq ($(call isTargetOs, macosx)+$(DEBUG_LEVEL), true+release) > + ifeq ($(OPENJDK_TARGET_OS)-$(DEBUG_LEVEL), macosx-release) > > https://bugs.openjdk.java.net/browse/JDK-8238534 > https://hg.openjdk.java.net/jdk/jdk/rev/6f40f03179f9 > http://cr.openjdk.java.net/~rschuenemann/wr/2020/8238534- > macos_sign_bundles-jdk11u/01 > > Rene From matthias.baesken at sap.com Fri Feb 21 12:45:19 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 21 Feb 2020 12:45:19 +0000 Subject: jdk11 LIBZIP build and 8201349: build broken when configured with --with-zlib=bundled on gcc 7.3 Message-ID: Hello, we were running into build errors recently when using gcc-7 and with-zlib=bundled in jdk11u-dev . This combination worked nicely in jdk/jdk . Reason is that in jdk11 we do not have : 8201349: build broken when configured with --with-zlib=bundled on gcc 7.3 https://hg.openjdk.java.net/jdk/jdk/rev/c35eac313084 which unfortunately has a predecessor 8211029: Have a common set of enabled warnings for all native libraries https://hg.openjdk.java.net/jdk/jdk/rev/ec62d6cab037 I'd like to have the gcc - warning disablements for LIBJLI / LIBZIP , but taking over the large patch 8211029 to 11 looks a bit too much . Should I just post a separate patch for jdk11u-dev with the gcc warning disablements for LIBJLI / LIBZIP : DISABLED_WARNINGS_gcc := unused-function implicit-fallthrough, \ ? This fixes our build issues and sounds reasonable and small . Thanks, Matthias From christoph.langer at sap.com Fri Feb 21 12:51:22 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 21 Feb 2020 12:51:22 +0000 Subject: jdk11 LIBZIP build and 8201349: build broken when configured with --with-zlib=bundled on gcc 7.3 In-Reply-To: References: Message-ID: Hi Matthias, yes, I suggest to backport only JDK-8201349 with setting both statements to DISABLED_WARNINGS_gcc := unused-function implicit-fallthrough as was the result of the original fix for JDK-8201349. Cheers Christoph From: Baesken, Matthias Sent: Freitag, 21. Februar 2020 13:45 To: jdk-updates-dev at openjdk.java.net; 'build-dev at openjdk.java.net' Cc: 'magnus.ihse.bursie at oracle.com' ; Langer, Christoph Subject: jdk11 LIBZIP build and 8201349: build broken when configured with --with-zlib=bundled on gcc 7.3 Hello, we were running into build errors recently when using gcc-7 and with-zlib=bundled in jdk11u-dev . This combination worked nicely in jdk/jdk . Reason is that in jdk11 we do not have : 8201349: build broken when configured with --with-zlib=bundled on gcc 7.3 https://hg.openjdk.java.net/jdk/jdk/rev/c35eac313084 which unfortunately has a predecessor 8211029: Have a common set of enabled warnings for all native libraries https://hg.openjdk.java.net/jdk/jdk/rev/ec62d6cab037 I'd like to have the gcc - warning disablements for LIBJLI / LIBZIP , but taking over the large patch 8211029 to 11 looks a bit too much . Should I just post a separate patch for jdk11u-dev with the gcc warning disablements for LIBJLI / LIBZIP : DISABLED_WARNINGS_gcc := unused-function implicit-fallthrough, \ ? This fixes our build issues and sounds reasonable and small . Thanks, Matthias From matthias.baesken at sap.com Fri Feb 21 13:50:09 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 21 Feb 2020 13:50:09 +0000 Subject: RFR [jdk11]: 8201349: build broken when configured with --with-zlib=bundled on gcc 7.3 Message-ID: Hello, please review this small downport of 8201349 . Reason is that we run into warnings as errors, when building jdk11 on Linux with gcc-7.X and with-zlib=bundled . This adds the compiler options -Wno-unused-function -Wno-implicit-fallthrough To some compilations e.g. zlib-files ; these 2 flags are at least supported with gcc-4.7 , gcc-4.8 ,gcc-7 and gcc-8 . Bug : https://bugs.openjdk.java.net/browse/JDK-8201349 jdk/jdk webrev : https://hg.openjdk.java.net/jdk/jdk/rev/c35eac313084 adjusted Jdk11 webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8201349.0_jdk11/ Thanks, Matthias From goetz.lindenmaier at sap.com Fri Feb 21 15:16:19 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 21 Feb 2020 15:16:19 +0000 Subject: [11u reminder]: jdk 11.0.5 rampdown starts Tuesday, February 25, 18:00 CET. Message-ID: Hi, I would like to remind everybody who is working on jdk 11 updates that Rampdown of 11.0.7 starts next Tuesday, February 25, at 18:00 CET. At that point in time the last merge from jdk11u-dev to jdk11u will take place. Please push all changes you want to get to 11.0.7 before that date. After that, changes for 11.0.7 must be requested with jdk11u-critical-request tags, and they need to be pushed directly to jdk11u. Best regards, Goetz From goetz.lindenmaier at sap.com Fri Feb 21 15:35:34 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 21 Feb 2020 15:35:34 +0000 Subject: [11u] RFR(XS) 8239792: Bump update version for OpenJDK: jdk-11.0.8 Message-ID: Hi, to start development of jdk-11.0.8, we need to bump the version: http://cr.openjdk.java.net/~goetz/wr20/8239792-version_11.0.8-jdk11/01/ Please review. Naturally, I will only push this after dev close of 11.0.7, and after JBS was updated to tag for 11.0.8. For the date, see also https://www.oracle.com/security-alerts/ Thanks, Goetz. From volker.simonis at gmail.com Fri Feb 21 15:45:50 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 21 Feb 2020 16:45:50 +0100 Subject: Hotspot Express (HSX) In-Reply-To: <4D5DA55E-ACCD-4DE9-8E09-37BBE40205B4@amazon.com> References: <1A373C6F-D6F7-4BB1-A5BF-2E77D087CC5B@amazon.com> <271678a3-3392-bd91-4a54-215cb20cc4ba@oracle.com> <41CE1D47-5F5D-424D-AABE-07AD640F0E56@amazon.com> <4D5DA55E-ACCD-4DE9-8E09-37BBE40205B4@amazon.com> Message-ID: Hi, I want to start with some personal experience. Before joining Amazon I've worked at SAP for many years and there, with SAP JVM as you many know, we've taken HSX to the extreme. We've used the same HotSpot (from JDK 8) for up to 5 different Java releases (4,5,6,7,8) in parallel and still now SAP JVM 8 is running with an HS version from JDK 10+. Our general experience was positive and the whole SAP Java eco system running on these versions is a strong proof that this is a viable approach. One of the reasons we did HSX was that we had to support a lot of custom features and ports which are not (or were not at that time) part of OpenJDK. That's obviously a lot easier to do with a single HS version. I also think it wouldn't have been easy to support that many different Java releases in parallel with a restricted amount of resources, without HotSpot Express. We obviously had to add some switches and gates to the latest HS in order to make it work with previous releases, but in our experience that was much less work than down-porting, even if it was just down-porting of relevant bug fixes. We obviously monitored performance carefully. For all but the latest release, the impact of HSX is just positive and the older the JDK version that uses HSX, the bigger the performance gain. But even for the latest JDK release we never observed any measurable performance regression compared to the corresponding OpenJDK/Oracle JDK because of HSX. Coming back to the here and now. I don't see why HotSpot shouldn't be more modular and more independent of the JDK/class library. There's simply no reason why major parts of the JVM like JIT or GC should be tied to a specific Java /JDK version (and with JVMCI and the GC interface we're moving in the right direction here). Some of the reasons for HSX we had at SAP like new features (e.g. Shenandoah) or ports (e.g. aarch64) maintained outside of the main update repositories for LTS releases, are still relevant in OpenJDK today. By the way, the discussion about a clean VM interface is as old as OpenJDK itself and we even (still) have a special OpenJDK project (sponsored by the HS Group) dedicated to this topic: "Common VM Interface" (http://openjdk.java.net/projects/cvmi). Anyone remembers it :)) In the early OpenJDK days, a bunch of different VM implementations (e.g. JamVM, JikesRVM, IKVM.NET) integrated with the OpenJDK class library but even today we still have one major, alternative JVM implementation (called OpenJ9 :) which can work with the OpenJDK JDK - and I think this is good for the project. I know that in the early days, Sun "kind of" supported these alternative JVM implementations while nowadays Oralce is trying to prevent them with legal means (i.e. withdrawing the OCTLA license), but let's not go into that direction here and keep this discussion on a technical level :) I don't agree with what's been said in this thread before, namely that a strong coupling of VM and JDK "is good" for OpenJDK, helps accelerating the development and improves the performance. In contrary, I think it will lead to bad "ad-hoc" decisions and wrong dependencies which might be helpful for the moment but which introduce considerable maintenance costs in the long term. I can understand that Oracle who is running the "tip" project, is not interested to invest in HSX. On the other hand, this mail thread has been initiated on "jdk-udates-dev" and not on "hotspot-dev". So maybe some parties on this list who are already involved in maintaining LTS/MTS releases, can agree on something like an "Hot Spot Express" project which can evaluate the benefits and drawbacks of such an approach in more detail (and in parallel and without impacting the current "tip" development). If the experiments are successful, I can imagine that some outcome which is not so controversial like for example better (GC,JIT,etc..) interfaces, better modularization, a better VM/JDK Interface can be upstreamed (simplifying the future maintenance of HSX) while other parts may stay in the HSX project forever. Such a project could then be used by every downstream distribution as a drop-in replacement for the default LTS HotSpot but also by projects which develop new features in "tip" to easily and more quickly get access to a much wider user base. Best regards, Volker On Thu, Feb 20, 2020 at 12:58 AM Hohensee, Paul wrote: > > Re JSX lack of adoption, the argument is that it's always taken at least a year to stabilize a new release, and with 6 months between releases none of the non-LTS releases will ever be stable. Doesn't matter whether that's true or not, it's what people believe based on previous experience with 8 and 11. The relatively large degree of incompatibility between 8 and 11 is another hurdle. People remember that and don't want to worry about language and library backward compatibility every 6 months, no matter how small those incompatibilities are. Doing a lot of backports is a response to that customer demand. Hotspot is "under the covers", so to speak, so HSX was easier to sell than is JSX. > > Paul > > ?On 2/19/20, 3:07 PM, "Claes Redestad" wrote: > > On 2020-02-19 22:50, Hohensee, Paul wrote: > > Given your stance on backports and JSX adoption, I can see your point and even agree with it. The problem is that the vast majority of users don?t want to use JSX. That's definitely the case inside Amazon. > > And why is that, Paul? > > > > > HSX does complicate the code base a bit, but is that worse than doing 600+ backports and counting? > > Yes. :-) > > Or rather: Even if a vast majority of users only skip from LTS to LTS, I > believe only a small fraction of those backports have been *strictly > necessary*. > > There are definitely resources that can be diverted from backporting > (which helps users stuck on some old release) to maintaining and > improving the tip (which brings *everyone* value sooner or later, be it > next quarter or in three years). > > Granted, I've backported a few things that weren't strictly necessary, > too, such as various startup optimizations, but always with the > motivation that without a fix there would have been regressions caused > by other, more critical changes. I'm not religiously against backports. > :-) > > But even if you don't agree the virtues of focusing engineering > resources on maintaining and working on the tip, we should stay well > clear of things that make maintaining the tip harder than it already is. > > Because it is already really hard. > > And HSX is one of the worse things you can do to make that maintenance > harder. > > > Also, I'm curious about how removing HSX remnants has improved performance. Can anyone point me at specifics? > > No. It's an accumulation of small improvements over time, including a > reduction in static footprint, many small startup improvements and > some overall performance improvements. > > But what's really at stake here are all the future features, cleanups > and larger improvements that will be just that little bit *harder* to do > *right* if hsx was still a thing. > > I won't go so far as to say it'd make any of the cool stuff happening at > or near the tip now impossible. But it would without a doubt slow down > progress to the detriment of everyone. Perhaps even enough to make some > throw their hands in the air and pick up ranching. Just sayin'. > > /Claes > > From volker.simonis at gmail.com Fri Feb 21 15:58:39 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 21 Feb 2020 16:58:39 +0100 Subject: RFR [jdk11]: 8201349: build broken when configured with --with-zlib=bundled on gcc 7.3 In-Reply-To: References: Message-ID: Looks good! Thanks, Volker On Fri, Feb 21, 2020 at 2:50 PM Baesken, Matthias wrote: > > Hello, please review this small downport of 8201349 . > Reason is that we run into warnings as errors, when building jdk11 on Linux with gcc-7.X and with-zlib=bundled . > This adds the compiler options > > -Wno-unused-function -Wno-implicit-fallthrough > > To some compilations e.g. zlib-files ; these 2 flags are at least supported with gcc-4.7 , gcc-4.8 ,gcc-7 and gcc-8 . > > > > Bug : > > https://bugs.openjdk.java.net/browse/JDK-8201349 > > jdk/jdk webrev : > > https://hg.openjdk.java.net/jdk/jdk/rev/c35eac313084 > > > adjusted Jdk11 webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8201349.0_jdk11/ > > > Thanks, Matthias From claes.redestad at oracle.com Fri Feb 21 16:59:36 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 21 Feb 2020 17:59:36 +0100 Subject: Hotspot Express (HSX) In-Reply-To: References: <1A373C6F-D6F7-4BB1-A5BF-2E77D087CC5B@amazon.com> <271678a3-3392-bd91-4a54-215cb20cc4ba@oracle.com> <41CE1D47-5F5D-424D-AABE-07AD640F0E56@amazon.com> <4D5DA55E-ACCD-4DE9-8E09-37BBE40205B4@amazon.com> Message-ID: <9f974c51-f246-1d6b-6377-c6e75cf9f72d@oracle.com> On 2020-02-21 16:45, Volker Simonis wrote: > I don't agree with what's been said in this thread before, namely that > a strong coupling of VM and JDK "is good" for OpenJDK, helps > accelerating the development and improves the performance. Let's agree to disagree. The speed-up in OpenJDK mainline development I've witnessed over my 7 years working here has been remarkable. Of course removing hsx is only partially to thank for this, but it's an important piece in a greater scheme to remove impediments that would have been at odds with many of the tougher decisions made over the past few years. For example consolidated repositories have decidedly helped streamline work, especially when needing to sync changes from jdk to hotspot and vice versa. Of course you can have hsx in a consolidated world, but it does work against you. A more allowing stance on feature removals have also helped us shed a lot of weight. Removing anything is bound to be a lot messier in a world with hsx. Not to mention java modules, the implementation for which I think would have ended up much messier if the hsx model was retained. > In contrary, I think it will lead to bad "ad-hoc" decisions and wrong > dependencies which might be helpful for the moment but which introduce > considerable maintenance costs in the long term. From my experience this seems unlikely, but yes, there will be fewer checks against it. As a counterpoint I believe most decisions are very mindful about maintenance costs, to the point where reducing future maintenance cost is usually the sole motivator - sometimes at expense of customer convenience. See the removal of CMS, for example. On that note, how _would_ this hsx project deal with features and flags that are deprecated and removed from the mainline? Will you need to resurrect removed features such as CMS, but hide the code behind build flags..? And looking further, how would hsx deal with a project like the C++ compiler upgrade[1], which will change system requirements and thus be unsuitable for a backport? /Claes [1] https://openjdk.java.net/jeps/347 From shade at redhat.com Fri Feb 21 17:53:59 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 21 Feb 2020 18:53:59 +0100 Subject: [11u] RFR 8229994: assert(false) failed: Bad graph detected in get_early_ctrl_for_expensive Message-ID: Original bug: https://bugs.openjdk.java.net/browse/JDK-8229994 https://hg.openjdk.java.net/jdk/jdk/rev/4938269b8b17 The patch is simple, but it does not apply to 11u because of the whitespace difference. I had to reapply the patch by hand. 11u webrev: https://cr.openjdk.java.net/~shade/8229994/webrev.11u.01/ Testing: new test (fails before, passes after); tier{1,2,3} -- Thanks, -Aleksey From shade at redhat.com Fri Feb 21 17:55:00 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 21 Feb 2020 18:55:00 +0100 Subject: [11u] RFR(XS) 8239792: Bump update version for OpenJDK: jdk-11.0.8 In-Reply-To: References: Message-ID: <36cbb30e-f55a-ff98-14b5-3c9777f79a51@redhat.com> On 2/21/20 4:35 PM, Lindenmaier, Goetz wrote: > to start development of jdk-11.0.8, we need to bump > the version: > http://cr.openjdk.java.net/~goetz/wr20/8239792-version_11.0.8-jdk11/01/ Looks fine. -- Thanks, -Aleksey From aph at redhat.com Fri Feb 21 17:57:22 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 21 Feb 2020 17:57:22 +0000 Subject: Hotspot Express (HSX) In-Reply-To: References: <1A373C6F-D6F7-4BB1-A5BF-2E77D087CC5B@amazon.com> <271678a3-3392-bd91-4a54-215cb20cc4ba@oracle.com> <41CE1D47-5F5D-424D-AABE-07AD640F0E56@amazon.com> Message-ID: <9d63df37-8151-2a06-22de-0e5c0f63786c@redhat.com> On 2/19/20 10:53 PM, David Holmes wrote: > If you are prepared to use 11u with (nearly) everything from 13 (for > example) backported into it, then why not just use 13? Because any company with a support policy of many years would have to support a dozen different Java releases *at the same time*. We couldn't do that, and your lot probably couldn't either. People want support. It's our business. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ron.pressler at oracle.com Fri Feb 21 21:28:36 2020 From: ron.pressler at oracle.com (Ron Pressler) Date: Fri, 21 Feb 2020 21:28:36 +0000 Subject: Hotspot Express (HSX) Message-ID: Major releases took a year to stabilize. The last major release was 9. It was released over two years ago. It's stabilized. Feature releases (or "limited updates," as they were called back then) never took a year to stabilize. And I think it matters a great deal whether some argument is true or not. We're not bystanders. If it's is right, then it shouldn't be and we should? focus on fixing that. If it's not, then it is our responsibility to help? people overcome the temporary confusion caused by the change to how we name? versions and the elimination of major releases, rather than entrench that? confusion. - Ron On 2/19/20, 23:58 PM, "Hohensee, Paul" wrote: ?> Re JSX lack of adoption, the argument is that it's always taken at least ?a year to stabilize a new release, and with 6 months between releases ?none of the non-LTS releases will ever be stable. Doesn't matter whether ?that's true or not, it's what people believe based on previous ?experience with 8 and 11. The relatively large degree of incompatibility ?between 8 and 11 is another hurdle. People remember that and don't want ?to worry about language and library backward compatibility every 6 ?months, no matter how small those incompatibilities are. Doing a lot of ?backports is a response to that customer demand. Hotspot is "under the ?covers", so to speak, so HSX was easier to sell than is JSX. ?> Paul From volker.simonis at gmail.com Fri Feb 21 22:38:49 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 21 Feb 2020 23:38:49 +0100 Subject: Hotspot Express (HSX) In-Reply-To: References: Message-ID: Ron Pressler schrieb am Fr., 21. Feb. 2020, 22:30: > > Major releases took a year to stabilize. The last major release was 9. It > was > released over two years ago. It's stabilized. Feature releases (or "limited > updates," as they were called back then) never took a year to stabilize. > No it's not, because nobody seriously used it, because it was clear from the beginning that it would only be supported for 6 month. That's exactly the point why nobody seriously considers non-LTS releases for production. And the reason why intermediat, overlapping MTS (Medium Term Support) releases have been proposed to solve the problem. 11 is LTS, it's more than a year old and it's the first release since 8 which really gains some serious adoption. But the gap from 8 to 11 is obviously quite big. Considering all the features currently under development, the gap between 11 and 17, the next LTS, might be even bigger. > And I think it matters a great deal whether some argument is true or not. > We're not bystanders. If it's is right, then it shouldn't be and we should > focus on fixing that. If it's not, then it is our responsibility to help > people overcome the temporary confusion caused by the change to how we > name > versions and the elimination of major releases, rather than entrench that > confusion. > > - Ron > > > On 2/19/20, 23:58 PM, "Hohensee, Paul" wrote: > > > Re JSX lack of adoption, the argument is that it's always taken at least > a year to stabilize a new release, and with 6 months between releases > none of the non-LTS releases will ever be stable. Doesn't matter whether > that's true or not, it's what people believe based on previous > experience with 8 and 11. The relatively large degree of incompatibility > between 8 and 11 is another hurdle. People remember that and don't want > to worry about language and library backward compatibility every 6 > months, no matter how small those incompatibilities are. Doing a lot of > backports is a response to that customer demand. Hotspot is "under the > covers", so to speak, so HSX was easier to sell than is JSX. > > > Paul > > > > From ron.pressler at oracle.com Fri Feb 21 22:55:10 2020 From: ron.pressler at oracle.com (Ron Pressler) Date: Fri, 21 Feb 2020 22:55:10 +0000 Subject: Hotspot Express (HSX) In-Reply-To: References: Message-ID: A great many people have used 9 and its feature updates ? 9u20, 9u40, 9u60,? 9u80 or, as we now call them after the version naming change, 10, 11, 12,? and 13. My point is just that any kind of argument based on a major-release model? is at odds with the new reality of how OpenJDK is actually developed (e.g. we now merge features when they are much more mature than they used to be back when we had major releases; the number of people working on, say, 11u,? is 20-50x less than the number of those who'd be working on 9 had we kept? the old version name). Instead of keeping up a confusing mirage for the? sake of those who have not yet internalized the new model, we should help? people understand it. - Ron On 21 February 2020 at 22:38:59, Volker Simonis wrote: > > > Ron Pressler schrieb am Fr., 21. Feb. 2020, 22:30: > > > > Major releases took a year to stabilize. The last major release was 9. It was > > released over two years ago. It's stabilized. Feature releases (or "limited > > updates," as they were called back then) never took a year to stabilize. > > No it's not, because nobody seriously used it, because it was clear from the beginning that it would only be supported for 6 month. > > That's exactly the point why nobody seriously considers non-LTS releases for production. And the reason why intermediat, overlapping MTS (Medium Term Support) releases have been proposed to solve the problem. > > 11 is LTS, it's more than a year old and it's the first release since 8 which really gains some serious adoption. But the gap from 8 to 11 is obviously quite big. Considering all the features currently under development, the gap between 11 and 17, the next LTS, might be even bigger. > > > > > And I think it matters a great deal whether some argument is true or not. > > We're not bystanders. If it's is right, then it shouldn't be and we should > > focus on fixing that. If it's not, then it is our responsibility to help > > people overcome the temporary confusion caused by the change to how we name > > versions and the elimination of major releases, rather than entrench that > > confusion. > > > > - Ron > > > > > > On 2/19/20, 23:58 PM, "Hohensee, Paul" wrote: > > > > > Re JSX lack of adoption, the argument is that it's always taken at least > > a year to stabilize a new release, and with 6 months between releases > > none of the non-LTS releases will ever be stable. Doesn't matter whether > > that's true or not, it's what people believe based on previous > > experience with 8 and 11. The relatively large degree of incompatibility > > between 8 and 11 is another hurdle. People remember that and don't want > > to worry about language and library backward compatibility every 6 > > months, no matter how small those incompatibilities are. Doing a lot of > > backports is a response to that customer demand. Hotspot is "under the > > covers", so to speak, so HSX was easier to sell than is JSX. > > > > > Paul > > > > > > From christoph.langer at sap.com Fri Feb 21 23:08:14 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 21 Feb 2020 23:08:14 +0000 Subject: [11u] RFR: 8210459, 8218807, 8223678: Support for creating Visual Studio Code projects In-Reply-To: <6ef2dfe8-b96e-ddc2-dbba-45a80aa4a8e0@redhat.com> References: <6ef2dfe8-b96e-ddc2-dbba-45a80aa4a8e0@redhat.com> Message-ID: Hi, Thanks, Volker for backporting this to JDK11 and thanks Andrew for reviewing it. > On 30/12/2019 20:18, Volker Simonis wrote: > > Hi, > > I'd like to downport the support for Visual Studio Code project > > creation to 11u. I think we will have to support 11u for quite some > > years and it makes sense to have as good as possible tool support in > > 11u as well. > > I just came across this proposal in the process of backporting > JDK-8232748: "Build static versions of certain JDK libraries". The only > hunk of that changeset which isn't a simple context difference is that > which applies to JdkNativeCompilation.gmk and the FindLib & > FindStaticLib rules it introduces. > > I was going to just drop this hunk, as I didn't see any reason to > backport JDK-8210459, but then I saw your existing RFR referenced on the > bug. If JDK-8210459 is to be backported, I thus need this in place > before posting JDK-8232748 for review. Thanks for waiting, Andrew. I'll approve JDK-8210459 now in order to get it pushed to unblock your work on JDK-8210459. > > Finally, I've added an additional fix to this last change, whch fixes > > the make tests (i.e. "make test-make"). These tests are currently > > broken in jdk11u. They have been broken by JDK-8212028 (which has > > already been downported to jdk11u) and fixed in jdk 12 as part of > > "8210958: Rename "make run-test" to "make test"" (which hasn't been > > downported yet and probably won't be donwported at all). Because the > > fix is trivial (that's why it was done as part of 8210958 without an > > extra bug ID) and because I wanted to run "make test-make" in jdk11u > > as well to verify my changes, I've decided to downport this fix as > > part of 8223678: > > > > diff -r 8599975f5b33 test/make/TestMakeBase.gmk > > --- a/test/make/TestMakeBase.gmk Tue Feb 12 08:40:43 2019 +0100 > > +++ b/test/make/TestMakeBase.gmk Mon Dec 23 22:10:46 2019 +0100 > > KWBASE := > APA=banan;GURKA=tomat;COUNT=1%202%203%204%205;SUM=1+2+3+4+5 > ;MANY_WORDS=I > > have the best words. > > > > $(eval $(call ParseKeywordVariable, KWBASE, \ > > - KEYWORDS := APA GURKA SUM, \ > > + SINGLE_KEYWORDS := APA GURKA SUM, \ > > STRING_KEYWORDS := COUNT MANY_WORDS, \ > > )) > > > > @@ -364,7 +376,7 @@ > > KWBASE_WEIRD := ;;APA=banan;;;GURKA=apelsin;APA=skansen;; > > > > $(eval $(call ParseKeywordVariable, KWBASE_WEIRD, \ > > - KEYWORDS := APA GURKA SUM, \ > > + SINGLE_KEYWORDS := APA GURKA SUM, \ > > STRING_KEYWORDS := COUNT, \ > > )) > > > > I agree it doesn't make sense to backport JDK-8210958, as that's a major > change to the test infrastructure. However, I think this warrants its > own 11u bug rather than being smuggled in under JDK-8223678. Otherwise, > you're just mirroring the same problem that was created by mixing this > in with JDK-8210958. An independent bug can describe the breakage and > link to the original issue that caused it. Hm, I think Volker's way of adding this trivial correction to the backport of 8223678 is okay. But, of course a separate bug could also be a good way to document this fix. Maybe we need a tiebreaker here? ?? So I'll approve the series of backports now, except for JDK-8223678. Cheers Christoph From ioi.lam at oracle.com Sat Feb 22 00:21:30 2020 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 21 Feb 2020 16:21:30 -0800 Subject: Hotspot Express (HSX) In-Reply-To: References: <1A373C6F-D6F7-4BB1-A5BF-2E77D087CC5B@amazon.com> <271678a3-3392-bd91-4a54-215cb20cc4ba@oracle.com> <41CE1D47-5F5D-424D-AABE-07AD640F0E56@amazon.com> <4D5DA55E-ACCD-4DE9-8E09-37BBE40205B4@amazon.com> Message-ID: There used to be a clean separation between the "JDK" (Java libraries consisting of mostly of Java bytecodes and some JNI code) vs the "VM", which executes the bytecodes. However, this is no longer the case. Many new language features, such as Lambda, are implemented with both Java code under corelibs (look under here: http://hg.openjdk.java.net/jdk/jdk/file/tip/src/java.base/share/classes/java/lang/invoke/) and C++ code under HotSpot. We have found that implementing new language features in Java to be much less painful than in C++, so this type of Java code will likely become more prevalent in the future. So if we want to separate the class library vs the language implementation, just replacing libjvm.so won't be enough. We need to be able to replace part of the class libraries as well. Doing so will probably reduce the inter-dependency between the "Java library" part of the JDK vs the "JLS implementation" part of the JDK. We can still have tight coupling within the latter part so we don't need to sacrifice performance. So instead of replacing just libjvm.so, maybe replacing the entire java.base module would be a better approach? Maybe someone can do a jlink hack by mixing the java.base module file with the modules of an earlier JDK release, and see if it works? Thanks - Ioi On 2/21/20 7:45 AM, Volker Simonis wrote: > Hi, > > I want to start with some personal experience. Before joining Amazon > I've worked at SAP for many years and there, with SAP JVM as you many > know, we've taken HSX to the extreme. We've used the same HotSpot > (from JDK 8) for up to 5 different Java releases (4,5,6,7,8) in > parallel and still now SAP JVM 8 is running with an HS version from > JDK 10+. Our general experience was positive and the whole SAP Java > eco system running on these versions is a strong proof that this is a > viable approach. > > One of the reasons we did HSX was that we had to support a lot of > custom features and ports which are not (or were not at that time) > part of OpenJDK. That's obviously a lot easier to do with a single HS > version. I also think it wouldn't have been easy to support that many > different Java releases in parallel with a restricted amount of > resources, without HotSpot Express. We obviously had to add some > switches and gates to the latest HS in order to make it work with > previous releases, but in our experience that was much less work than > down-porting, even if it was just down-porting of relevant bug fixes. > We obviously monitored performance carefully. For all but the latest > release, the impact of HSX is just positive and the older the JDK > version that uses HSX, the bigger the performance gain. But even for > the latest JDK release we never observed any measurable performance > regression compared to the corresponding OpenJDK/Oracle JDK because of > HSX. > > Coming back to the here and now. I don't see why HotSpot shouldn't be > more modular and more independent of the JDK/class library. There's > simply no reason why major parts of the JVM like JIT or GC should be > tied to a specific Java /JDK version (and with JVMCI and the GC > interface we're moving in the right direction here). Some of the > reasons for HSX we had at SAP like new features (e.g. Shenandoah) or > ports (e.g. aarch64) maintained outside of the main update > repositories for LTS releases, are still relevant in OpenJDK today. By > the way, the discussion about a clean VM interface is as old as > OpenJDK itself and we even (still) have a special OpenJDK project > (sponsored by the HS Group) dedicated to this topic: "Common VM > Interface" (http://openjdk.java.net/projects/cvmi). Anyone remembers > it :)) > > In the early OpenJDK days, a bunch of different VM implementations > (e.g. JamVM, JikesRVM, IKVM.NET) integrated with the OpenJDK class > library but even today we still have one major, alternative JVM > implementation (called OpenJ9 :) which can work with the OpenJDK JDK - > and I think this is good for the project. I know that in the early > days, Sun "kind of" supported these alternative JVM implementations > while nowadays Oralce is trying to prevent them with legal means > (i.e. withdrawing the OCTLA license), but let's not go into that > direction here and keep this discussion on a technical level :) > > I don't agree with what's been said in this thread before, namely that > a strong coupling of VM and JDK "is good" for OpenJDK, helps > accelerating the development and improves the performance. In > contrary, I think it will lead to bad "ad-hoc" decisions and wrong > dependencies which might be helpful for the moment but which introduce > considerable maintenance costs in the long term. > > I can understand that Oracle who is running the "tip" project, is not > interested to invest in HSX. On the other hand, this mail thread has > been initiated on "jdk-udates-dev" and not on "hotspot-dev". So maybe > some parties on this list who are already involved in maintaining > LTS/MTS releases, can agree on something like an "Hot Spot Express" > project which can evaluate the benefits and drawbacks of such an > approach in more detail (and in parallel and without impacting the > current "tip" development). If the experiments are successful, I can > imagine that some outcome which is not so controversial like for > example better (GC,JIT,etc..) interfaces, better modularization, a > better VM/JDK Interface can be upstreamed (simplifying the future > maintenance of HSX) while other parts may stay in the HSX project > forever. Such a project could then be used by every downstream > distribution as a drop-in replacement for the default LTS HotSpot but > also by projects which develop new features in "tip" to easily and > more quickly get access to a much wider user base. > > Best regards, > Volker > > On Thu, Feb 20, 2020 at 12:58 AM Hohensee, Paul wrote: >> Re JSX lack of adoption, the argument is that it's always taken at least a year to stabilize a new release, and with 6 months between releases none of the non-LTS releases will ever be stable. Doesn't matter whether that's true or not, it's what people believe based on previous experience with 8 and 11. The relatively large degree of incompatibility between 8 and 11 is another hurdle. People remember that and don't want to worry about language and library backward compatibility every 6 months, no matter how small those incompatibilities are. Doing a lot of backports is a response to that customer demand. Hotspot is "under the covers", so to speak, so HSX was easier to sell than is JSX. >> >> Paul >> >> ?On 2/19/20, 3:07 PM, "Claes Redestad" wrote: >> >> On 2020-02-19 22:50, Hohensee, Paul wrote: >> > Given your stance on backports and JSX adoption, I can see your point and even agree with it. The problem is that the vast majority of users don?t want to use JSX. That's definitely the case inside Amazon. >> >> And why is that, Paul? >> >> > >> > HSX does complicate the code base a bit, but is that worse than doing 600+ backports and counting? >> >> Yes. :-) >> >> Or rather: Even if a vast majority of users only skip from LTS to LTS, I >> believe only a small fraction of those backports have been *strictly >> necessary*. >> >> There are definitely resources that can be diverted from backporting >> (which helps users stuck on some old release) to maintaining and >> improving the tip (which brings *everyone* value sooner or later, be it >> next quarter or in three years). >> >> Granted, I've backported a few things that weren't strictly necessary, >> too, such as various startup optimizations, but always with the >> motivation that without a fix there would have been regressions caused >> by other, more critical changes. I'm not religiously against backports. >> :-) >> >> But even if you don't agree the virtues of focusing engineering >> resources on maintaining and working on the tip, we should stay well >> clear of things that make maintaining the tip harder than it already is. >> >> Because it is already really hard. >> >> And HSX is one of the worse things you can do to make that maintenance >> harder. >> >> > Also, I'm curious about how removing HSX remnants has improved performance. Can anyone point me at specifics? >> >> No. It's an accumulation of small improvements over time, including a >> reduction in static footprint, many small startup improvements and >> some overall performance improvements. >> >> But what's really at stake here are all the future features, cleanups >> and larger improvements that will be just that little bit *harder* to do >> *right* if hsx was still a thing. >> >> I won't go so far as to say it'd make any of the cool stuff happening at >> or near the tip now impossible. But it would without a doubt slow down >> progress to the detriment of everyone. Perhaps even enough to make some >> throw their hands in the air and pick up ranching. Just sayin'. >> >> /Claes >> >> From chris.hegarty at oracle.com Sat Feb 22 13:41:13 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 22 Feb 2020 13:41:13 +0000 Subject: Hotspot Express (HSX) In-Reply-To: References: <1A373C6F-D6F7-4BB1-A5BF-2E77D087CC5B@amazon.com> <271678a3-3392-bd91-4a54-215cb20cc4ba@oracle.com> <41CE1D47-5F5D-424D-AABE-07AD640F0E56@amazon.com> <4D5DA55E-ACCD-4DE9-8E09-37BBE40205B4@amazon.com> Message-ID: <0ED4F7F7-B075-4A7D-9EBD-0C6291F2A429@oracle.com> > On 22 Feb 2020, at 00:21, Ioi Lam wrote: > > ... > > So instead of replacing just libjvm.so, maybe replacing the entire java.base module would be a better approach? Stating the obvious, but I will anyway for the record. The java.base module exports many public APIs that make up the Java SE Platform. It would not be a good idea to just replace the entire java.base module, as, at a very minimum, the java.base module would likely contain many new, removed, or updated, APIs. -Chris. From christian.hagedorn at oracle.com Mon Feb 24 08:24:00 2020 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Mon, 24 Feb 2020 09:24:00 +0100 Subject: [11u] RFR 8229994: assert(false) failed: Bad graph detected in get_early_ctrl_for_expensive In-Reply-To: References: Message-ID: Hi Aleksey Looks good to me but I do not have reviewer status. Best regards, Christian On 21.02.20 18:53, Aleksey Shipilev wrote: > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8229994 > https://hg.openjdk.java.net/jdk/jdk/rev/4938269b8b17 > > The patch is simple, but it does not apply to 11u because of the whitespace difference. I had to > reapply the patch by hand. 11u webrev: > https://cr.openjdk.java.net/~shade/8229994/webrev.11u.01/ > > Testing: new test (fails before, passes after); tier{1,2,3} > From shade at redhat.com Mon Feb 24 08:25:43 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 24 Feb 2020 09:25:43 +0100 Subject: [11u] RFR 8229994: assert(false) failed: Bad graph detected in get_early_ctrl_for_expensive In-Reply-To: References: Message-ID: <98a57c6b-a9ee-2b83-b32b-bc67c73ab3fd@redhat.com> On 2/24/20 9:24 AM, Christian Hagedorn wrote: > Looks good to me but I do not have reviewer status. Thanks. The review is still useful. I'll wait for formal reviewers to chime in as well. > Best regards, > Christian > > On 21.02.20 18:53, Aleksey Shipilev wrote: >> Original bug: >> https://bugs.openjdk.java.net/browse/JDK-8229994 >> https://hg.openjdk.java.net/jdk/jdk/rev/4938269b8b17 >> >> The patch is simple, but it does not apply to 11u because of the whitespace difference. I had to >> reapply the patch by hand. 11u webrev: >> https://cr.openjdk.java.net/~shade/8229994/webrev.11u.01/ -- -Aleksey From goetz.lindenmaier at sap.com Mon Feb 24 09:07:38 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 24 Feb 2020 09:07:38 +0000 Subject: [11u] RFR(XS) 8239792: Bump update version for OpenJDK: jdk-11.0.8 In-Reply-To: <36cbb30e-f55a-ff98-14b5-3c9777f79a51@redhat.com> References: <36cbb30e-f55a-ff98-14b5-3c9777f79a51@redhat.com> Message-ID: Hi Aleksey, thanks for the review! Best regards, Goetz > -----Original Message----- > From: Aleksey Shipilev > Sent: Freitag, 21. Februar 2020 18:55 > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: Re: [11u] RFR(XS) 8239792: Bump update version for OpenJDK: jdk- > 11.0.8 > > On 2/21/20 4:35 PM, Lindenmaier, Goetz wrote: > > to start development of jdk-11.0.8, we need to bump > > the version: > > http://cr.openjdk.java.net/~goetz/wr20/8239792-version_11.0.8-jdk11/01/ > > Looks fine. > > -- > Thanks, > -Aleksey From sgehwolf at redhat.com Mon Feb 24 09:46:14 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 24 Feb 2020 10:46:14 +0100 Subject: [11u reminder]: jdk 11.0.7 rampdown starts Tuesday, February 25, 18:00 CET. In-Reply-To: References: Message-ID: <9998c609919a138a0155189626fc586afa58eddd.camel@redhat.com> Fixing subject. It's 11.0.7 (not 11.0.5). On Fri, 2020-02-21 at 15:16 +0000, Lindenmaier, Goetz wrote: > Hi, > > I would like to remind everybody who is working on jdk 11 updates > that Rampdown of 11.0.7 starts next Tuesday, February 25, at 18:00 CET. > > At that point in time the last merge from jdk11u-dev to jdk11u > will take place. Please push all changes you want to get to 11.0.7 > before that date. > > After that, changes for 11.0.7 must be requested with > jdk11u-critical-request tags, and they need to be pushed > directly to jdk11u. > > Best regards, > Goetz > From goetz.lindenmaier at sap.com Mon Feb 24 10:50:06 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 24 Feb 2020 10:50:06 +0000 Subject: [11u reminder]: jdk 11.0.7 rampdown starts Tuesday, February 25, 18:00 CET. In-Reply-To: <9998c609919a138a0155189626fc586afa58eddd.camel@redhat.com> References: <9998c609919a138a0155189626fc586afa58eddd.camel@redhat.com> Message-ID: Yes, thanks, Best regards, Goetz. > -----Original Message----- > From: Severin Gehwolf > Sent: Montag, 24. Februar 2020 10:46 > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: Re: [11u reminder]: jdk 11.0.7 rampdown starts Tuesday, February 25, > 18:00 CET. > > Fixing subject. It's 11.0.7 (not 11.0.5). > > On Fri, 2020-02-21 at 15:16 +0000, Lindenmaier, Goetz wrote: > > Hi, > > > > I would like to remind everybody who is working on jdk 11 updates > > that Rampdown of 11.0.7 starts next Tuesday, February 25, at 18:00 CET. > > > > At that point in time the last merge from jdk11u-dev to jdk11u > > will take place. Please push all changes you want to get to 11.0.7 > > before that date. > > > > After that, changes for 11.0.7 must be requested with > > jdk11u-critical-request tags, and they need to be pushed > > directly to jdk11u. > > > > Best regards, > > Goetz > > From hohensee at amazon.com Mon Feb 24 18:22:31 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 24 Feb 2020 18:22:31 +0000 Subject: [11u] RFR 8229994: assert(false) failed: Bad graph detected in get_early_ctrl_for_expensive In-Reply-To: <98a57c6b-a9ee-2b83-b32b-bc67c73ab3fd@redhat.com> References: <98a57c6b-a9ee-2b83-b32b-bc67c73ab3fd@redhat.com> Message-ID: Lgtm. Paul ?On 2/24/20, 12:27 AM, "jdk-updates-dev on behalf of Aleksey Shipilev" wrote: On 2/24/20 9:24 AM, Christian Hagedorn wrote: > Looks good to me but I do not have reviewer status. Thanks. The review is still useful. I'll wait for formal reviewers to chime in as well. > Best regards, > Christian > > On 21.02.20 18:53, Aleksey Shipilev wrote: >> Original bug: >> https://bugs.openjdk.java.net/browse/JDK-8229994 >> https://hg.openjdk.java.net/jdk/jdk/rev/4938269b8b17 >> >> The patch is simple, but it does not apply to 11u because of the whitespace difference. I had to >> reapply the patch by hand. 11u webrev: >> https://cr.openjdk.java.net/~shade/8229994/webrev.11u.01/ -- -Aleksey From shade at redhat.com Mon Feb 24 18:26:27 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 24 Feb 2020 19:26:27 +0100 Subject: [11u] RFR 8229994: assert(false) failed: Bad graph detected in get_early_ctrl_for_expensive In-Reply-To: References: <98a57c6b-a9ee-2b83-b32b-bc67c73ab3fd@redhat.com> Message-ID: Thanks! Added the tags. -- -Aleksey On 2/24/20 7:22 PM, Hohensee, Paul wrote: > Lgtm. > > Paul > > ?On 2/24/20, 12:27 AM, "jdk-updates-dev on behalf of Aleksey Shipilev" wrote: > > On 2/24/20 9:24 AM, Christian Hagedorn wrote: > > Looks good to me but I do not have reviewer status. > > Thanks. The review is still useful. > > I'll wait for formal reviewers to chime in as well. > > > Best regards, > > Christian > > > > On 21.02.20 18:53, Aleksey Shipilev wrote: > >> Original bug: > >> https://bugs.openjdk.java.net/browse/JDK-8229994 > >> https://hg.openjdk.java.net/jdk/jdk/rev/4938269b8b17 > >> > >> The patch is simple, but it does not apply to 11u because of the whitespace difference. I had to > >> reapply the patch by hand. 11u webrev: > >> https://cr.openjdk.java.net/~shade/8229994/webrev.11u.01/ From dalibor.topic at oracle.com Tue Feb 25 13:58:24 2020 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Tue, 25 Feb 2020 14:58:24 +0100 Subject: Hotspot Express (HSX) In-Reply-To: References: <1A373C6F-D6F7-4BB1-A5BF-2E77D087CC5B@amazon.com> <271678a3-3392-bd91-4a54-215cb20cc4ba@oracle.com> <41CE1D47-5F5D-424D-AABE-07AD640F0E56@amazon.com> <4D5DA55E-ACCD-4DE9-8E09-37BBE40205B4@amazon.com> Message-ID: On 21.02.2020 16:45, Volker Simonis wrote: > I can understand that Oracle who is running the "tip" project, is not > interested to invest in HSX. On the other hand, this mail thread has > been initiated on "jdk-udates-dev" and not on "hotspot-dev". As a maintainer of OpenJDK 14 updates, I wouldn't really see the value of adding unnecessary complexity which could impact the backporting work on the planned few releases negatively. Like previous OpenJDK update releases since JDK 9, OpenJDK 14 Updates are not planned to be maintained for an extraordinarily long time by its current team of maintainers. 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 From shade at redhat.com Tue Feb 25 19:01:00 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 25 Feb 2020 20:01:00 +0100 Subject: [11u reminder]: jdk 11.0.5 rampdown starts Tuesday, February 25, 18:00 CET. In-Reply-To: References: Message-ID: <9b1bb59b-c691-4a59-2778-d3db153e8284@redhat.com> On 2/21/20 4:16 PM, Lindenmaier, Goetz wrote: > I would like to remind everybody who is working on jdk 11 updates > that Rampdown of 11.0.7 starts next Tuesday, February 25, at 18:00 CET. It is past that now. Can I push stuff destined for 11.0.8 now? Or should I wait for tomorrow? -- Thanks, -Aleksey From goetz.lindenmaier at sap.com Tue Feb 25 20:01:41 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 25 Feb 2020 20:01:41 +0000 Subject: [11u reminder]: jdk 11.0.5 rampdown starts Tuesday, February 25, 18:00 CET. In-Reply-To: <9b1bb59b-c691-4a59-2778-d3db153e8284@redhat.com> References: , <9b1bb59b-c691-4a59-2778-d3db153e8284@redhat.com> Message-ID: <6144CD6D-A044-430C-A297-156F02B7D116@sap.com> Hi Aleksey, JBS will mark it as fixed for 11.0.8. But it would be nice if the 11.0.8+0 tag would be the first change. Feel free to tag accordingly before you push, or give me until tomorrow morning. Best regards, G?tz > Am 25.02.2020 um 20:01 schrieb Aleksey Shipilev : > > ?On 2/21/20 4:16 PM, Lindenmaier, Goetz wrote: >> I would like to remind everybody who is working on jdk 11 updates >> that Rampdown of 11.0.7 starts next Tuesday, February 25, at 18:00 CET. > > It is past that now. Can I push stuff destined for 11.0.8 now? Or should I wait for tomorrow? > > -- > Thanks, > -Aleksey > From shade at redhat.com Tue Feb 25 20:02:56 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 25 Feb 2020 21:02:56 +0100 Subject: [11u reminder]: jdk 11.0.5 rampdown starts Tuesday, February 25, 18:00 CET. In-Reply-To: <6144CD6D-A044-430C-A297-156F02B7D116@sap.com> References: <9b1bb59b-c691-4a59-2778-d3db153e8284@redhat.com> <6144CD6D-A044-430C-A297-156F02B7D116@sap.com> Message-ID: <5d8ebca4-07e2-4f98-7e6a-414ad2a18227@redhat.com> Hi Goetz, On 2/25/20 9:01 PM, Lindenmaier, Goetz wrote: > JBS will mark it as fixed for 11.0.8. > But it would be nice if the 11.0.8+0 tag would be the first change. > Feel free to tag accordingly before you push, or give me until tomorrow morning. Makes sense. I am in no rush, will wait until tomorrow. -- Thanks, -Aleksey From volker.simonis at gmail.com Wed Feb 26 00:16:24 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 26 Feb 2020 01:16:24 +0100 Subject: Hotspot Express (HSX) In-Reply-To: References: <1A373C6F-D6F7-4BB1-A5BF-2E77D087CC5B@amazon.com> <271678a3-3392-bd91-4a54-215cb20cc4ba@oracle.com> <41CE1D47-5F5D-424D-AABE-07AD640F0E56@amazon.com> <4D5DA55E-ACCD-4DE9-8E09-37BBE40205B4@amazon.com> Message-ID: Dalibor Topic schrieb am Di., 25. Feb. 2020, 14:58: > > > On 21.02.2020 16:45, Volker Simonis wrote: > > > I can understand that Oracle who is running the "tip" project, is not > > interested to invest in HSX. On the other hand, this mail thread has > > been initiated on "jdk-udates-dev" and not on "hotspot-dev". > > As a maintainer of OpenJDK 14 updates, I wouldn't really see the value > of adding unnecessary complexity which could impact the backporting work > on the planned few releases negatively. > > Like previous OpenJDK update releases since JDK 9, OpenJDK 14 Updates > are not planned to be maintained for an extraordinarily long time by its > current team of maintainers. > The proposed HSX approach isn't gonna change this at all. It will always use the latest released HS version in the current LTS JDK. And it does this exactly because it wants to save the constantly growing effort of downporting fixes from the latest feature releases to the last supported LTS version. Withe HSX, downports to the latest supported feature release (i.e. 14) are unnecessary, because HSX would be updated to the latest feature release any 6 month anyway. > 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 > > From goetz.lindenmaier at sap.com Wed Feb 26 08:52:25 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 26 Feb 2020 08:52:25 +0000 Subject: [11u reminder]: jdk 11.0.7 rampdown starts Tuesday, February 25, 18:00 CET. Message-ID: Hi Aleksey, I pushed the tags, go ahead and push changes to 11.0.8! Thanks for waiting, Goetz > -----Original Message----- > From: Aleksey Shipilev > Sent: Tuesday, February 25, 2020 9:03 PM > To: Lindenmaier, Goetz > Cc: jdk-updates-dev at openjdk.java.net > Subject: Re: [11u reminder]: jdk 11.0.5 rampdown starts Tuesday, February > 25, 18:00 CET. > > Hi Goetz, > > On 2/25/20 9:01 PM, Lindenmaier, Goetz wrote: > > JBS will mark it as fixed for 11.0.8. > > But it would be nice if the 11.0.8+0 tag would be the first change. > > Feel free to tag accordingly before you push, or give me until tomorrow > morning. > > Makes sense. I am in no rush, will wait until tomorrow. > > -- > Thanks, > -Aleksey From dalibor.topic at oracle.com Wed Feb 26 09:50:07 2020 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 26 Feb 2020 10:50:07 +0100 Subject: Hotspot Express (HSX) In-Reply-To: References: <1A373C6F-D6F7-4BB1-A5BF-2E77D087CC5B@amazon.com> <271678a3-3392-bd91-4a54-215cb20cc4ba@oracle.com> <41CE1D47-5F5D-424D-AABE-07AD640F0E56@amazon.com> <4D5DA55E-ACCD-4DE9-8E09-37BBE40205B4@amazon.com> Message-ID: On 26.02.2020 01:16, Volker Simonis wrote: > The proposed HSX approach isn't gonna change this at all. It will always > use the latest released HS version in the current LTS JDK. Thanks for clarifying that your proposal would affect OpenJDK 11 Updates only, Volker. 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 From volker.simonis at gmail.com Wed Feb 26 10:59:37 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 26 Feb 2020 11:59:37 +0100 Subject: [11u] RFR: 8223678: Add Visual Studio Code workspace generation support (for native code) Message-ID: Hi, I'd like to downport the support for Visual Studio Code project creation to 11u. I think we will have to support 11u for quite some years and it makes sense to have as good as possible tool support in 11u as well: https://bugs.openjdk.java.net/browse/JDK-8223678 http://cr.openjdk.java.net/~simonis/webrevs/2020/8223678/ This change is the third in a series of three changes (8210459, 8218807, 8223678) which are required to get VS Code support in 11u. The first two changes (8210459, 8218807) have already been approved and pushed. This change only touch make files and actually only add new features to the make system, so the normal build results shouldn't be affected. I've tested that the build still works on Linux and Windows and "make test-make" succeeds. This change actually creates the VS Code project files (i.e. "make vscode-project-ccls"). See http://hg.openjdk.java.net/jdk/jdk/raw-file/tip/doc/ide.html for more details. It applies cleanly except the following two hunks. The first one had to be moved back from "make/common/Utils.gmk" to "make/common/MakeBase.gmk" where it still applies cleanly, because the "RelativePath" macro is still in "MakeBase.gmk" in jdk11u. ORIGINAL ======== diff -r a82a367b2d8c -r 2ae056696b15 make/common/Utils.gmk --- a/make/common/Utils.gmk Mon Jun 03 17:14:23 2019 -0700 +++ b/make/common/Utils.gmk Mon Jun 03 10:28:03 2019 +0200 @@ -122,7 +122,8 @@ # $2 - Directory to compute the relative path from RelativePath = \ $(eval $1_prefix := $(call FindCommonPathPrefix, $1, $2)) \ - $(eval $1_dotdots := $(call DirToDotDot, $(patsubst $($(strip $1)_prefix)/%, %, $2))) \ + $(eval $1_dotdots := $(call DirToDotDot, $(patsubst $($(strip $1)_prefix)%, %, $2))) \ + $(eval $1_dotdots := $(if $($(strip $1)_dotdots),$($(strip $1)_dotdots),.)) \ $(eval $1_suffix := $(patsubst $($(strip $1)_prefix)/%, %, $1)) \ $($(strip $1)_dotdots)/$($(strip $1)_suffix) JDK11u ====== diff -r 8599975f5b33 make/common/MakeBase.gmk --- a/make/common/MakeBase.gmk Tue Feb 12 08:40:43 2019 +0100 +++ b/make/common/MakeBase.gmk Mon Dec 23 22:10:46 2019 +0100 @@ -611,7 +611,8 @@ # $2 - Directory to compute the relative path from RelativePath = \ $(eval $1_prefix := $(call FindCommonPathPrefix, $1, $2)) \ - $(eval $1_dotdots := $(call DirToDotDot, $(patsubst $($(strip $1)_prefix)/%, %, $2))) \ + $(eval $1_dotdots := $(call DirToDotDot, $(patsubst $($(strip $1)_prefix)%, %, $2))) \ + $(eval $1_dotdots := $(if $($(strip $1)_dotdots),$($(strip $1)_dotdots),.)) \ $(eval $1_suffix := $(patsubst $($(strip $1)_prefix)/%, %, $1)) \ $($(strip $1)_dotdots)/$($(strip $1)_suffix) For the second changed hunk, the simple call of the "AssertEquals" macro had to be renamed to "assert-equals" and wrapped with "eval" because the corresponding macros haven't been updated in jdk11u yet. Notice that these are only test changes (for testing the make system itself) and don't effect the build at all. ORIGINAL ======== diff -r a82a367b2d8c -r 2ae056696b15 test/make/TestMakeBase.gmk --- a/test/make/TestMakeBase.gmk Mon Jun 03 17:14:23 2019 -0700 +++ b/test/make/TestMakeBase.gmk Mon Jun 03 10:28:03 2019 +0200 @@ -361,6 +361,18 @@ RelativePath, \ ) +$(call AssertEquals, \ + $(call RelativePath, /foo/bar/baz/banan/kung, /foo/bar/baz), \ + ./banan/kung, \ + RelativePath, \ +) + +$(call AssertEquals, \ + $(call RelativePath, /foo/bar/baz/banan/kung, /foo/bar/baz/), \ + ./banan/kung, \ + RelativePath, \ +) JDK11u ====== diff -r 8599975f5b33 test/make/TestMakeBase.gmk --- a/test/make/TestMakeBase.gmk Tue Feb 12 08:40:43 2019 +0100 +++ b/test/make/TestMakeBase.gmk Mon Dec 23 22:10:46 2019 +0100 @@ -325,13 +325,25 @@ RelativePath, \ )) +$(eval $(call assert-equals, \ + $(call RelativePath, /foo/bar/baz/banan/kung, /foo/bar/baz), \ + ./banan/kung, \ + RelativePath, \ +)) + +$(eval $(call assert-equals, \ + $(call RelativePath, /foo/bar/baz/banan/kung, /foo/bar/baz/), \ + ./banan/kung, \ + RelativePath, \ +)) From volker.simonis at gmail.com Wed Feb 26 11:17:25 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 26 Feb 2020 12:17:25 +0100 Subject: [11u] RFR: 8240073: Fix 'test-make' build target in 11u Message-ID: Hi, can I please have a review for the following tiny change which fixes the 'test-make' build target in 11u: http://cr.openjdk.java.net/~simonis/webrevs/2020/8240073/ https://bugs.openjdk.java.net/browse/JDK-8240073 This is a tiny fix for a problem introduced by JDK-8212028 (which has already been downported to 11u) and fixed in jdk 12 as part of JDK-8210958 (which hasn't been downported yet and probably won't be donwported at all). Instead of smuggling this fix into another downport, it has been argued (https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-February/002533.html) that it is cleaner to create an explicit issue for fixing it in 11u. The fix is trivial (that's why it was done as part of JDK-8210958 without an extra bug ID) and only affects running "make test-make". Thank you and best regards, Volker From volker.simonis at gmail.com Wed Feb 26 11:19:10 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 26 Feb 2020 12:19:10 +0100 Subject: [11u] RFR: 8210459, 8218807, 8223678: Support for creating Visual Studio Code projects In-Reply-To: <6ef2dfe8-b96e-ddc2-dbba-45a80aa4a8e0@redhat.com> References: <6ef2dfe8-b96e-ddc2-dbba-45a80aa4a8e0@redhat.com> Message-ID: On Wed, Feb 19, 2020 at 6:14 AM Andrew Hughes wrote: > > > > On 30/12/2019 20:18, Volker Simonis wrote: > > Hi, > > I'd like to downport the support for Visual Studio Code project > > creation to 11u. I think we will have to support 11u for quite some > > years and it makes sense to have as good as possible tool support in > > 11u as well. > > I just came across this proposal in the process of backporting > JDK-8232748: "Build static versions of certain JDK libraries". The only > hunk of that changeset which isn't a simple context difference is that > which applies to JdkNativeCompilation.gmk and the FindLib & > FindStaticLib rules it introduces. > > I was going to just drop this hunk, as I didn't see any reason to > backport JDK-8210459, but then I saw your existing RFR referenced on the > bug. If JDK-8210459 is to be backported, I thus need this in place > before posting JDK-8232748 for review. > > > > > This mail is especially intended to get a review from the build team > > that the few changes to the patches are OK: > > > > https://bugs.openjdk.java.net/browse/JDK-8210459 > > http://cr.openjdk.java.net/~simonis/webrevs/2019/8210459/ > > > > https://bugs.openjdk.java.net/browse/JDK-8218807 > > http://cr.openjdk.java.net/~simonis/webrevs/2019/8218807/ > > > > https://bugs.openjdk.java.net/browse/JDK-8223678 > > http://cr.openjdk.java.net/~simonis/webrevs/2019/8223678/ > > > > The downport consists of three changes which are additive (i.e. later > > changes depend on earlier ones). That's why I decided to post just one > > RFR, because looking at a single change makes no sense without the > > corresponding context. The changes mostly apply cleanly except for > > very few places where we need manual adjustments because of changed > > context. > > I'm just going to stick to reviewing JDK-8210459 here. I feel an RFR > should stick to just the one single change, which a reviewer can then > apply and test on the current state of the repository. Having three > changes in one RFR is quite overwhelming and the later changes are being > applied against a repository state which doesn't yet exist. I suspect > that may be one of the reasons this review has not been undertaken thus far. > I'm always torn between the two approaches here. On one side I completely understand and respect your position. On the other hand, I find it hard to judge and review backport changes which are only required as dependencies for other backports out of their context. And we don't have any good possibilities of somehow grouping such changes together logically. It also increases the latency considerably, because you can't post the second change for review before the first one has been approved and pushed. This is exactly for the reason you mention, that a reviewer will first have to find and apply the first change, before he can look at the second one. Having all the related changes in one RFR at least keeps the context together and allows a review to apply and review them one after another. Anyway, thanks for looking at JDK-8210459 :) > > > > These changes only touch make files and actually only add new features > > to the make system, so the normal build results shouldn't be affected. > > I've tested that the build still works on Linux and Windows and "make > > test-make" succeeds. > > > > Following some details on the three changes: > > > > 8210459: Add support for generating compile_commands.json > > > > The initial change which creates the compile_commands.json file (i.e. > > "make compile_commands"). This file can be used for many tools (e.g. > > CLion IDE, clangd, etc..) > > Applies cleanly except for the following hunk, which has a different context: > > > > ORIGINAL > > ======== > > CFLAGS_solaris := -KPIC, \ > > CFLAGS_macosx := -fPIC, \ > > DISABLED_WARNINGS_clang := format-nonliteral, \ > > - LDFLAGS := $(UNPACKEXE_ZIPOBJS) \ > > - $(LDFLAGS_JDKEXE) $(LDFLAGS_CXX_JDK) \ > > + LDFLAGS := $(LDFLAGS_JDKEXE) $(LDFLAGS_CXX_JDK) \ > > > > JDK11u > > ====== > > CFLAGS_linux := -fPIC, \ > > CFLAGS_solaris := -KPIC, \ > > CFLAGS_macosx := -fPIC, \ > > - LDFLAGS := $(UNPACKEXE_ZIPOBJS) \ > > - $(LDFLAGS_JDKEXE) $(LDFLAGS_CXX_JDK) \ > > + LDFLAGS := $(LDFLAGS_JDKEXE) $(LDFLAGS_CXX_JDK) \ > > > > This looks fine. I compared your patch and the original changeset and > this is indeed the only difference, and only occurs because of the > additional disabled warning for Clang. > Thanks. I've pushed JDK-8210459 now, after Christoph has approve it. > > > > Finally, I've added an additional fix to this last change, whch fixes > > the make tests (i.e. "make test-make"). These tests are currently > > broken in jdk11u. They have been broken by JDK-8212028 (which has > > already been downported to jdk11u) and fixed in jdk 12 as part of > > "8210958: Rename "make run-test" to "make test"" (which hasn't been > > downported yet and probably won't be donwported at all). Because the > > fix is trivial (that's why it was done as part of 8210958 without an > > extra bug ID) and because I wanted to run "make test-make" in jdk11u > > as well to verify my changes, I've decided to downport this fix as > > part of 8223678: > > > > diff -r 8599975f5b33 test/make/TestMakeBase.gmk > > --- a/test/make/TestMakeBase.gmk Tue Feb 12 08:40:43 2019 +0100 > > +++ b/test/make/TestMakeBase.gmk Mon Dec 23 22:10:46 2019 +0100 > > KWBASE := APA=banan;GURKA=tomat;COUNT=1%202%203%204%205;SUM=1+2+3+4+5;MANY_WORDS=I > > have the best words. > > > > $(eval $(call ParseKeywordVariable, KWBASE, \ > > - KEYWORDS := APA GURKA SUM, \ > > + SINGLE_KEYWORDS := APA GURKA SUM, \ > > STRING_KEYWORDS := COUNT MANY_WORDS, \ > > )) > > > > @@ -364,7 +376,7 @@ > > KWBASE_WEIRD := ;;APA=banan;;;GURKA=apelsin;APA=skansen;; > > > > $(eval $(call ParseKeywordVariable, KWBASE_WEIRD, \ > > - KEYWORDS := APA GURKA SUM, \ > > + SINGLE_KEYWORDS := APA GURKA SUM, \ > > STRING_KEYWORDS := COUNT, \ > > )) > > > > I agree it doesn't make sense to backport JDK-8210958, as that's a major > change to the test infrastructure. However, I think this warrants its > own 11u bug rather than being smuggled in under JDK-8223678. Otherwise, > you're just mirroring the same problem that was created by mixing this > in with JDK-8210958. An independent bug can describe the breakage and > link to the original issue that caused it. > OK, fine for me. I've created "JDK-8240073: Fix 'test-make' build target in 11u" for this issue now and sent out a RFR here: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-February/002589.html I've also sent out a new RFR for "JDK-8223678: Add Visual Studio Code workspace generation support (for native code)" without the extra fix which has been now moved to JDK-8240073: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-February/002588.html Please take a look if possible :) Thank you and best regards, Volker > 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 > From volker.simonis at gmail.com Wed Feb 26 11:22:26 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 26 Feb 2020 12:22:26 +0100 Subject: [11u] RFR: 8210459, 8218807, 8223678: Support for creating Visual Studio Code projects In-Reply-To: References: <6ef2dfe8-b96e-ddc2-dbba-45a80aa4a8e0@redhat.com> Message-ID: On Sat, Feb 22, 2020 at 12:08 AM Langer, Christoph wrote: > Hi, > > Thanks, Volker for backporting this to JDK11 and thanks Andrew for > reviewing it. > > > On 30/12/2019 20:18, Volker Simonis wrote: > > > Hi, > > > I'd like to downport the support for Visual Studio Code project > > > creation to 11u. I think we will have to support 11u for quite some > > > years and it makes sense to have as good as possible tool support in > > > 11u as well. > > > > I just came across this proposal in the process of backporting > > JDK-8232748: "Build static versions of certain JDK libraries". The only > > hunk of that changeset which isn't a simple context difference is that > > which applies to JdkNativeCompilation.gmk and the FindLib & > > FindStaticLib rules it introduces. > > > > I was going to just drop this hunk, as I didn't see any reason to > > backport JDK-8210459, but then I saw your existing RFR referenced on the > > bug. If JDK-8210459 is to be backported, I thus need this in place > > before posting JDK-8232748 for review. > > Thanks for waiting, Andrew. I'll approve JDK-8210459 now in order to get > it pushed to unblock your work on JDK-8210459. > Thanks, pushed. > > > > Finally, I've added an additional fix to this last change, whch fixes > > > the make tests (i.e. "make test-make"). These tests are currently > > > broken in jdk11u. They have been broken by JDK-8212028 (which has > > > already been downported to jdk11u) and fixed in jdk 12 as part of > > > "8210958: Rename "make run-test" to "make test"" (which hasn't been > > > downported yet and probably won't be donwported at all). Because the > > > fix is trivial (that's why it was done as part of 8210958 without an > > > extra bug ID) and because I wanted to run "make test-make" in jdk11u > > > as well to verify my changes, I've decided to downport this fix as > > > part of 8223678: > > > > > > diff -r 8599975f5b33 test/make/TestMakeBase.gmk > > > --- a/test/make/TestMakeBase.gmk Tue Feb 12 08:40:43 2019 +0100 > > > +++ b/test/make/TestMakeBase.gmk Mon Dec 23 22:10:46 2019 +0100 > > > KWBASE := > > APA=banan;GURKA=tomat;COUNT=1%202%203%204%205;SUM=1+2+3+4+5 > > ;MANY_WORDS=I > > > have the best words. > > > > > > $(eval $(call ParseKeywordVariable, KWBASE, \ > > > - KEYWORDS := APA GURKA SUM, \ > > > + SINGLE_KEYWORDS := APA GURKA SUM, \ > > > STRING_KEYWORDS := COUNT MANY_WORDS, \ > > > )) > > > > > > @@ -364,7 +376,7 @@ > > > KWBASE_WEIRD := ;;APA=banan;;;GURKA=apelsin;APA=skansen;; > > > > > > $(eval $(call ParseKeywordVariable, KWBASE_WEIRD, \ > > > - KEYWORDS := APA GURKA SUM, \ > > > + SINGLE_KEYWORDS := APA GURKA SUM, \ > > > STRING_KEYWORDS := COUNT, \ > > > )) > > > > > > > I agree it doesn't make sense to backport JDK-8210958, as that's a major > > change to the test infrastructure. However, I think this warrants its > > own 11u bug rather than being smuggled in under JDK-8223678. Otherwise, > > you're just mirroring the same problem that was created by mixing this > > in with JDK-8210958. An independent bug can describe the breakage and > > link to the original issue that caused it. > > Hm, I think Volker's way of adding this trivial correction to the backport > of 8223678 is okay. But, of course a separate bug could also be a good way > to document this fix. Maybe we need a tiebreaker here? ?? > No problem. I've created "JDK-8240073: Fix 'test-make' build target in 11u" for this issue now and sent out a RFR here: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-February/002589.html Please take a look if possible :) > So I'll approve the series of backports now, except for JDK-8223678. > > Thanks, I've pushed 8210459 and 8218807 now and sent out a new RFR for "JDK-8223678: Add Visual Studio Code workspace generation support (for native code)" without the extra fix which has been moved to JDK-8240073: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-February/002588.html Please take a look if possible :) Thank you and best regards, Volker > Cheers > Christoph > > From shade at redhat.com Wed Feb 26 12:02:38 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 26 Feb 2020 13:02:38 +0100 Subject: [11u reminder]: jdk 11.0.7 rampdown starts Tuesday, February 25, 18:00 CET. In-Reply-To: References: Message-ID: On 2/26/20 9:52 AM, Lindenmaier, Goetz wrote: > I pushed the tags, go ahead and push changes to 11.0.8! Cool. Pushed, everything seems to be in order. -- Thanks, -Aleksey From gnu.andrew at redhat.com Wed Feb 26 14:49:27 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 26 Feb 2020 14:49:27 +0000 Subject: [11u] RFR: 8223678: Add Visual Studio Code workspace generation support (for native code) In-Reply-To: References: Message-ID: <971e7935-c61c-1dee-dc1e-0bc567695222@redhat.com> On 26/02/2020 10:59, Volker Simonis wrote: > Hi, > I'd like to downport the support for Visual Studio Code project > creation to 11u. I think we will have to support 11u for quite some > years and it makes sense to have as good as possible tool support in > 11u as well: > > https://bugs.openjdk.java.net/browse/JDK-8223678 > http://cr.openjdk.java.net/~simonis/webrevs/2020/8223678/ > > This change is the third in a series of three changes (8210459, > 8218807, 8223678) which are required to get VS Code support in 11u. > The first two changes (8210459, 8218807) have already been approved > and pushed. > > This change only touch make files and actually only add new features > to the make system, so the normal build results shouldn't be affected. > I've tested that the build still works on Linux and Windows and "make > test-make" succeeds. > > This change actually creates the VS Code project files (i.e. "make > vscode-project-ccls"). See > http://hg.openjdk.java.net/jdk/jdk/raw-file/tip/doc/ide.html for more > details. > > It applies cleanly except the following two hunks. The first one had to > be moved back from "make/common/Utils.gmk" to > "make/common/MakeBase.gmk" where it still applies cleanly, because the > "RelativePath" macro is still in "MakeBase.gmk" in jdk11u. > > ORIGINAL > ======== > diff -r a82a367b2d8c -r 2ae056696b15 make/common/Utils.gmk > --- a/make/common/Utils.gmk Mon Jun 03 17:14:23 2019 -0700 > +++ b/make/common/Utils.gmk Mon Jun 03 10:28:03 2019 +0200 > @@ -122,7 +122,8 @@ > # $2 - Directory to compute the relative path from > RelativePath = \ > $(eval $1_prefix := $(call FindCommonPathPrefix, $1, $2)) \ > - $(eval $1_dotdots := $(call DirToDotDot, $(patsubst $($(strip > $1)_prefix)/%, %, $2))) \ > + $(eval $1_dotdots := $(call DirToDotDot, $(patsubst $($(strip > $1)_prefix)%, %, $2))) \ > + $(eval $1_dotdots := $(if $($(strip $1)_dotdots),$($(strip > $1)_dotdots),.)) \ > $(eval $1_suffix := $(patsubst $($(strip $1)_prefix)/%, %, $1)) \ > $($(strip $1)_dotdots)/$($(strip $1)_suffix) > > JDK11u > ====== > diff -r 8599975f5b33 make/common/MakeBase.gmk > --- a/make/common/MakeBase.gmk Tue Feb 12 08:40:43 2019 +0100 > +++ b/make/common/MakeBase.gmk Mon Dec 23 22:10:46 2019 +0100 > @@ -611,7 +611,8 @@ > # $2 - Directory to compute the relative path from > RelativePath = \ > $(eval $1_prefix := $(call FindCommonPathPrefix, $1, $2)) \ > - $(eval $1_dotdots := $(call DirToDotDot, $(patsubst $($(strip > $1)_prefix)/%, %, $2))) \ > + $(eval $1_dotdots := $(call DirToDotDot, $(patsubst $($(strip > $1)_prefix)%, %, $2))) \ > + $(eval $1_dotdots := $(if $($(strip $1)_dotdots),$($(strip > $1)_dotdots),.)) \ > $(eval $1_suffix := $(patsubst $($(strip $1)_prefix)/%, %, $1)) \ > $($(strip $1)_dotdots)/$($(strip $1)_suffix) > > For the second changed hunk, the simple call of the "AssertEquals" > macro had to be renamed to "assert-equals" and wrapped with "eval" > because the corresponding macros haven't been updated in jdk11u yet. > Notice that these are only test changes (for testing the make system > itself) and don't effect the build at all. > > ORIGINAL > ======== > diff -r a82a367b2d8c -r 2ae056696b15 test/make/TestMakeBase.gmk > --- a/test/make/TestMakeBase.gmk Mon Jun 03 17:14:23 2019 -0700 > +++ b/test/make/TestMakeBase.gmk Mon Jun 03 10:28:03 2019 +0200 > @@ -361,6 +361,18 @@ > RelativePath, \ > ) > > +$(call AssertEquals, \ > + $(call RelativePath, /foo/bar/baz/banan/kung, /foo/bar/baz), \ > + ./banan/kung, \ > + RelativePath, \ > +) > + > +$(call AssertEquals, \ > + $(call RelativePath, /foo/bar/baz/banan/kung, /foo/bar/baz/), \ > + ./banan/kung, \ > + RelativePath, \ > +) > > JDK11u > ====== > diff -r 8599975f5b33 test/make/TestMakeBase.gmk > --- a/test/make/TestMakeBase.gmk Tue Feb 12 08:40:43 2019 +0100 > +++ b/test/make/TestMakeBase.gmk Mon Dec 23 22:10:46 2019 +0100 > @@ -325,13 +325,25 @@ > RelativePath, \ > )) > > +$(eval $(call assert-equals, \ > + $(call RelativePath, /foo/bar/baz/banan/kung, /foo/bar/baz), \ > + ./banan/kung, \ > + RelativePath, \ > +)) > + > +$(eval $(call assert-equals, \ > + $(call RelativePath, /foo/bar/baz/banan/kung, /foo/bar/baz/), \ > + ./banan/kung, \ > + RelativePath, \ > +)) > Thanks for the comprehensive description of the changes. It looks fine to me, though I've only eyeballed the changes & backporting, as I'm not a potential consumer of the new rules. From that perspective, it doesn't look like it will disrupt any existing builds. Out of interest, is the AssertEquals macro something worth backporting at some point? Generally, I find its worthwhile if people are going to be doing the same replacement in multiple backports. 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 From hohensee at amazon.com Wed Feb 26 16:12:41 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 26 Feb 2020 16:12:41 +0000 Subject: Hotspot Express (HSX) In-Reply-To: References: <1A373C6F-D6F7-4BB1-A5BF-2E77D087CC5B@amazon.com> <271678a3-3392-bd91-4a54-215cb20cc4ba@oracle.com> <41CE1D47-5F5D-424D-AABE-07AD640F0E56@amazon.com> <4D5DA55E-ACCD-4DE9-8E09-37BBE40205B4@amazon.com> Message-ID: <8A54AFA2-974F-42EA-A207-62FEA765D1AC@amazon.com> And, when jdk17 ships, it would affect only jdk17u. Paul ?On 2/26/20, 1:50 AM, "jdk-updates-dev on behalf of Dalibor Topic" wrote: On 26.02.2020 01:16, Volker Simonis wrote: > The proposed HSX approach isn't gonna change this at all. It will always > use the latest released HS version in the current LTS JDK. Thanks for clarifying that your proposal would affect OpenJDK 11 Updates only, Volker. 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 From hohensee at amazon.com Wed Feb 26 16:20:58 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 26 Feb 2020 16:20:58 +0000 Subject: [11u] RFR: 8240073: Fix 'test-make' build target in 11u In-Reply-To: References: Message-ID: <4BEE0678-3E37-41DD-A406-F5AE0A57536F@amazon.com> Looks to me like the replaced store to KEYWORDS is dead (i.e., no uses of KEYWORDS that I could find in make and test/make). Lgtm. Thanks, Paul ?On 2/26/20, 3:19 AM, "build-dev on behalf of Volker Simonis" wrote: Hi, can I please have a review for the following tiny change which fixes the 'test-make' build target in 11u: http://cr.openjdk.java.net/~simonis/webrevs/2020/8240073/ https://bugs.openjdk.java.net/browse/JDK-8240073 This is a tiny fix for a problem introduced by JDK-8212028 (which has already been downported to 11u) and fixed in jdk 12 as part of JDK-8210958 (which hasn't been downported yet and probably won't be donwported at all). Instead of smuggling this fix into another downport, it has been argued (https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-February/002533.html) that it is cleaner to create an explicit issue for fixing it in 11u. The fix is trivial (that's why it was done as part of JDK-8210958 without an extra bug ID) and only affects running "make test-make". Thank you and best regards, Volker From zgu at redhat.com Wed Feb 26 16:28:19 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 26 Feb 2020 11:28:19 -0500 Subject: [11u] 8234270: [REDO] JDK-8204128 NMT might report incorrect numbers for Compiler area Message-ID: <57588961-d641-b8a8-bad1-8f3ba45b12e1@redhat.com> Hi, I would like to downport this patch to 11u, as this bug is visible to users [1]. Original bug: https://bugs.openjdk.java.net/browse/JDK-8234270 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/ac6f7738a0ee Original patch does not apply cleanly, but the conflict is minor, just a line shift in mallocTracker.hpp 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8234270/11u/webrev.00/ Test: hotspot_nmt on Linux x86_64 Thanks, -Zhengyu [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-November/039964.html From shade at redhat.com Wed Feb 26 16:57:17 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 26 Feb 2020 17:57:17 +0100 Subject: [11u] 8234270: [REDO] JDK-8204128 NMT might report incorrect numbers for Compiler area In-Reply-To: <57588961-d641-b8a8-bad1-8f3ba45b12e1@redhat.com> References: <57588961-d641-b8a8-bad1-8f3ba45b12e1@redhat.com> Message-ID: <3be8810e-a3be-ce7b-92dc-3de6f6228cee@redhat.com> On 2/26/20 5:28 PM, Zhengyu Gu wrote: > Original bug: https://bugs.openjdk.java.net/browse/JDK-8234270 > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/ac6f7738a0ee > > Original patch does not apply cleanly, but the conflict is minor, just a > line shift in mallocTracker.hpp > > 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8234270/11u/webrev.00/ Backport looks good. -- Thanks, -Aleksey From rob.mckenna at oracle.com Wed Feb 26 18:12:02 2020 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 26 Feb 2020 18:12:02 +0000 Subject: [13u-communication] CFV: 13u lead maintainer nomination for Yuri Nesterenko Message-ID: <20200226181202.GE24113@yoga> As the Project Lead, I would like to ask for your vote for the nomination [0] of Yuri Nesterenko as future lead maintainer. Votes are due by the 3rd of March. Only current JDK Updates Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying "Vote: yes" to this mail. For Lazy Consensus voting instructions, see [2]. -Rob [0] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-February/002535.html [1] http://openjdk.java.net/census [2] http://openjdk.java.net/bylaws#lazy-consensus From martinrb at google.com Wed Feb 26 18:12:45 2020 From: martinrb at google.com (Martin Buchholz) Date: Wed, 26 Feb 2020 10:12:45 -0800 Subject: [13u-communication] CFV: 13u lead maintainer nomination for Yuri Nesterenko In-Reply-To: <20200226181202.GE24113@yoga> References: <20200226181202.GE24113@yoga> Message-ID: Vote: yes On Wed, Feb 26, 2020 at 10:11 AM Rob McKenna wrote: > As the Project Lead, I would like to ask for your vote for the > nomination [0] of Yuri Nesterenko as future lead maintainer. > > Votes are due by the 3rd of March. > > Only current JDK Updates Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > "Vote: yes" to this mail. > > For Lazy Consensus voting instructions, see [2]. > > -Rob > > [0] > http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-February/002535.html > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > From shade at redhat.com Wed Feb 26 18:19:14 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 26 Feb 2020 19:19:14 +0100 Subject: [13u-communication] CFV: 13u lead maintainer nomination for Yuri Nesterenko In-Reply-To: <20200226181202.GE24113@yoga> References: <20200226181202.GE24113@yoga> Message-ID: Vote: yes On 2/26/20 7:12 PM, Rob McKenna wrote: > As the Project Lead, I would like to ask for your vote for the > nomination [0] of Yuri Nesterenko as future lead maintainer. -- Thanks, -Aleksey From sgehwolf at redhat.com Wed Feb 26 18:23:50 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 26 Feb 2020 19:23:50 +0100 Subject: [13u-communication] CFV: 13u lead maintainer nomination for Yuri Nesterenko In-Reply-To: <20200226181202.GE24113@yoga> References: <20200226181202.GE24113@yoga> Message-ID: <974de93a585bb4c8d0d5fb76bfbaac747583003d.camel@redhat.com> Vote: yes. On Wed, 2020-02-26 at 18:12 +0000, Rob McKenna wrote: > As the Project Lead, I would like to ask for your vote for the > nomination [0] of Yuri Nesterenko as future lead maintainer. > > Votes are due by the 3rd of March. > > Only current JDK Updates Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > "Vote: yes" to this mail. > > For Lazy Consensus voting instructions, see [2]. > > -Rob > > [0] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-February/002535.html > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > From ivan.gerasimov at oracle.com Wed Feb 26 18:43:08 2020 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 26 Feb 2020 10:43:08 -0800 Subject: [13u-communication] CFV: 13u lead maintainer nomination for Yuri Nesterenko In-Reply-To: <20200226181202.GE24113@yoga> References: <20200226181202.GE24113@yoga> Message-ID: <39363dab-4c07-accc-fb1a-ea4f1526ab94@oracle.com> Vote: Yes On 2/26/20 10:12 AM, Rob McKenna wrote: > As the Project Lead, I would like to ask for your vote for the > nomination [0] of Yuri Nesterenko as future lead maintainer. > -- With kind regards, Ivan Gerasimov From zgu at redhat.com Wed Feb 26 19:33:24 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 26 Feb 2020 14:33:24 -0500 Subject: [11u] 8234270: [REDO] JDK-8204128 NMT might report incorrect numbers for Compiler area In-Reply-To: <3be8810e-a3be-ce7b-92dc-3de6f6228cee@redhat.com> References: <57588961-d641-b8a8-bad1-8f3ba45b12e1@redhat.com> <3be8810e-a3be-ce7b-92dc-3de6f6228cee@redhat.com> Message-ID: <8c34ea9f-5346-ba2a-e251-122859a60a3b@redhat.com> Thanks, Aleksey. -Zhengyu On 2/26/20 11:57 AM, Aleksey Shipilev wrote: > On 2/26/20 5:28 PM, Zhengyu Gu wrote: >> Original bug: https://bugs.openjdk.java.net/browse/JDK-8234270 >> Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/ac6f7738a0ee >> >> Original patch does not apply cleanly, but the conflict is minor, just a >> line shift in mallocTracker.hpp >> >> 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8234270/11u/webrev.00/ > > Backport looks good. > From neugens.limasoftware at gmail.com Wed Feb 26 19:34:31 2020 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Wed, 26 Feb 2020 20:34:31 +0100 Subject: [13u-communication] CFV: 13u lead maintainer nomination for Yuri Nesterenko In-Reply-To: <20200226181202.GE24113@yoga> References: <20200226181202.GE24113@yoga> Message-ID: Vote: Yes, Cheers, Mario Il giorno mer 26 feb 2020 alle ore 19:11 Rob McKenna ha scritto: > > As the Project Lead, I would like to ask for your vote for the > nomination [0] of Yuri Nesterenko as future lead maintainer. > > Votes are due by the 3rd of March. > > Only current JDK Updates Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > "Vote: yes" to this mail. > > For Lazy Consensus voting instructions, see [2]. > > -Rob > > [0] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-February/002535.html > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From jesper.wilhelmsson at oracle.com Wed Feb 26 21:16:29 2020 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 26 Feb 2020 22:16:29 +0100 Subject: Hotspot Express (HSX) In-Reply-To: <8A54AFA2-974F-42EA-A207-62FEA765D1AC@amazon.com> References: <1A373C6F-D6F7-4BB1-A5BF-2E77D087CC5B@amazon.com> <271678a3-3392-bd91-4a54-215cb20cc4ba@oracle.com> <41CE1D47-5F5D-424D-AABE-07AD640F0E56@amazon.com> <4D5DA55E-ACCD-4DE9-8E09-37BBE40205B4@amazon.com> <8A54AFA2-974F-42EA-A207-62FEA765D1AC@amazon.com> Message-ID: <98184652-CC83-4C6C-A7C3-C99030D869DD@oracle.com> My personal experience from the hsx model was that it caused problems for several features we were implementing at the time. Features that actually needed to keep the JVM and the libraries in sync. That could be because we were porting a lot of the old JRockit stuff to Hotspot at that time, so there were several features that were more intrusive than the average JVM change - and there was simply a lot going on all over the place. (JFR was one of these features for instance.) Since I'm not heavily involved in the updates project I don't really have an opinion on how you run it, but I do have an observation. I find it interesting that so many experienced developers are willing to fend off all the changes that are done in the JVM as things that happen under the surface and won't be noticed by the users. Performance improvements is one thing - that you obviously want the users to notice, but all the other intricate details seems to be ignored in this discussion. Let's say there were no maintenance cost at all involved in hsx - the latest JVM could simply be plugged in to any old JDK - would you do it? Changes in the JVM often have several observable effects. Faster execution can be one of them. But reordering of instructions, changes in cache behavior, NUMA behavior, locking schemes and thread synchronization, or even simple bugfixes can from time to time cause unexpected results in the execution of the Java application and even break code that deliberately or undeliberately depends on a certain unspecified behavior. Not to mention even more intrusive, deliberate changes in default values, default algorithms or even the existence of algorithms. Would an hsx model happily pick up a new JVM where the default GC was changed to G1, or where CMS was removed and plug it into a JDK 8 running in production out there? The JVM isn't an isolated library that lives its own life without contact with the rest of the JDK. Changes in the JVM often go hand in hand with changes in the language. Which GC behaves the best depends on how the language is used and what kind of objects that fills the heap. This in turn depends heavily on what language features that are used. The same goes for the JIT compilers, different optimizations have different effect on the executed code depending on what language constructs are used in the Java application. The optimizations done in a JVM designed for JDK 15 is not necessarily the best choices for a JVM intended for JDK 11. Just an observation. /Jesper > On 26 Feb 2020, at 17:12, Hohensee, Paul wrote: > > And, when jdk17 ships, it would affect only jdk17u. > > Paul > > ?On 2/26/20, 1:50 AM, "jdk-updates-dev on behalf of Dalibor Topic" wrote: > > > > On 26.02.2020 01:16, Volker Simonis wrote: >> The proposed HSX approach isn't gonna change this at all. It will always >> use the latest released HS version in the current LTS JDK. > > Thanks for clarifying that your proposal would affect OpenJDK 11 Updates > only, Volker. > > 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 > > > From david.holmes at oracle.com Wed Feb 26 23:18:01 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 27 Feb 2020 09:18:01 +1000 Subject: Hotspot Express (HSX) In-Reply-To: <8A54AFA2-974F-42EA-A207-62FEA765D1AC@amazon.com> References: <1A373C6F-D6F7-4BB1-A5BF-2E77D087CC5B@amazon.com> <271678a3-3392-bd91-4a54-215cb20cc4ba@oracle.com> <41CE1D47-5F5D-424D-AABE-07AD640F0E56@amazon.com> <4D5DA55E-ACCD-4DE9-8E09-37BBE40205B4@amazon.com> <8A54AFA2-974F-42EA-A207-62FEA765D1AC@amazon.com> Message-ID: <93de23f1-08dc-64c4-25b5-0ca7c5b856c1@oracle.com> On 27/02/2020 2:12 am, Hohensee, Paul wrote: > And, when jdk17 ships, it would affect only jdk17u. If that is the case then I do not understand what is being discussed. To support HSX doesn't it mean that all current JVM feature work would have to be gated off specific JDK version checks, and that no cleanups involving code related to older JDKs could be done? Otherwise someone will have to backport all those changes to the HSX code, which seems a far more onerous task than the current selective backports. ??? David > Paul > > ?On 2/26/20, 1:50 AM, "jdk-updates-dev on behalf of Dalibor Topic" wrote: > > > > On 26.02.2020 01:16, Volker Simonis wrote: > > The proposed HSX approach isn't gonna change this at all. It will always > > use the latest released HS version in the current LTS JDK. > > Thanks for clarifying that your proposal would affect OpenJDK 11 Updates > only, Volker. > > 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 > > > From gnu.andrew at redhat.com Thu Feb 27 04:52:29 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 27 Feb 2020 04:52:29 +0000 Subject: [RFR] [11u] JDK-8232748: "Build static versions of certain JDK libraries" Message-ID: <9c9053d7-3f3e-17f1-ec1f-dadba6102214@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8232748 Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/8232748/webrev.01/ This patch adds targets to the build so that static versions of the JDK native libraries can be built, using static-libs-image. Such static versions of the libraries are required for consumption by Graal. With JDK-8210459 now in 11u, this is a largely clean backport, aside from some context changes, due to additional targets (JCov, JMH) being present in trunk: * In make/Bundles.gmk, 11u does not have jcov-bundles * In make/Main.gmk, 11u does not have jcov-image or jcov-bundles * In make/autoconf/spec.gmk.in, 11u does not have JMH_CORE_JAR, etc or JCOV_BUNDLE_NAME. * In make/conf/jib-profiles.js, the dependencies list in 11u doesn't include jmh and jcov. Building the new target, static-libs-image, succeeded. This should have no effect on other targets. 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 From goetz.lindenmaier at sap.com Thu Feb 27 08:35:26 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 27 Feb 2020 08:35:26 +0000 Subject: [13u-communication] CFV: 13u lead maintainer nomination for Yuri Nesterenko In-Reply-To: <20200226181202.GE24113@yoga> References: <20200226181202.GE24113@yoga> Message-ID: vote: yes Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Rob McKenna > Sent: Mittwoch, 26. Februar 2020 19:12 > To: jdk-updates-dev at openjdk.java.net > Subject: [13u-communication] CFV: 13u lead maintainer nomination for Yuri > Nesterenko > > As the Project Lead, I would like to ask for your vote for the > nomination [0] of Yuri Nesterenko as future lead maintainer. > > Votes are due by the 3rd of March. > > Only current JDK Updates Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > "Vote: yes" to this mail. > > For Lazy Consensus voting instructions, see [2]. > > -Rob > > [0] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020- > February/002535.html > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus From dcherepanov at azul.com Thu Feb 27 09:32:10 2020 From: dcherepanov at azul.com (Dmitry Cherepanov) Date: Thu, 27 Feb 2020 12:32:10 +0300 Subject: [13u-communication] CFV: 13u lead maintainer nomination for Yuri Nesterenko In-Reply-To: <20200226181202.GE24113@yoga> References: <20200226181202.GE24113@yoga> Message-ID: Vote: yes On 2/26/20 9:12 PM, Rob McKenna wrote: > As the Project Lead, I would like to ask for your vote for the > nomination [0] of Yuri Nesterenko as future lead maintainer. > > Votes are due by the 3rd of March. > > Only current JDK Updates Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > "Vote: yes" to this mail. > > For Lazy Consensus voting instructions, see [2]. > > -Rob > > [0] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-February/002535.html > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus From abrygin at azul.com Thu Feb 27 09:33:35 2020 From: abrygin at azul.com (Andrew Brygin) Date: Thu, 27 Feb 2020 12:33:35 +0300 Subject: [13u-communication] CFV: 13u lead maintainer nomination for Yuri Nesterenko In-Reply-To: <20200226181202.GE24113@yoga> References: <20200226181202.GE24113@yoga> Message-ID: <7e70735d-624e-4bc4-0524-6c852cc93c5f@azul.com> Vote: yes Thanks, Andrew On 26/02/2020 21:12, Rob McKenna wrote: > As the Project Lead, I would like to ask for your vote for the > nomination [0] of Yuri Nesterenko as future lead maintainer. > > Votes are due by the 3rd of March. > > Only current JDK Updates Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > "Vote: yes" to this mail. > > For Lazy Consensus voting instructions, see [2]. > > -Rob > > [0] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-February/002535.html > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus From vkempik at azul.com Thu Feb 27 09:35:56 2020 From: vkempik at azul.com (Vladimir Kempik) Date: Thu, 27 Feb 2020 09:35:56 +0000 Subject: [13u-communication] CFV: 13u lead maintainer nomination for Yuri Nesterenko In-Reply-To: <20200226181202.GE24113@yoga> References: <20200226181202.GE24113@yoga> Message-ID: Vote: yes > 26 ????. 2020 ?., ? 21:12, Rob McKenna ???????(?): > > As the Project Lead, I would like to ask for your vote for the > nomination [0] of Yuri Nesterenko as future lead maintainer. > > Votes are due by the 3rd of March. > > Only current JDK Updates Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > "Vote: yes" to this mail. > > For Lazy Consensus voting instructions, see [2]. > > -Rob > > [0] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-February/002535.html > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus From adinn at redhat.com Thu Feb 27 10:57:48 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 27 Feb 2020 10:57:48 +0000 Subject: Hotspot Express (HSX) In-Reply-To: <98184652-CC83-4C6C-A7C3-C99030D869DD@oracle.com> References: <1A373C6F-D6F7-4BB1-A5BF-2E77D087CC5B@amazon.com> <271678a3-3392-bd91-4a54-215cb20cc4ba@oracle.com> <41CE1D47-5F5D-424D-AABE-07AD640F0E56@amazon.com> <4D5DA55E-ACCD-4DE9-8E09-37BBE40205B4@amazon.com> <8A54AFA2-974F-42EA-A207-62FEA765D1AC@amazon.com> <98184652-CC83-4C6C-A7C3-C99030D869DD@oracle.com> Message-ID: <8efc82f9-85d9-dc6d-9de5-62aba3c2d843@redhat.com> On 26/02/2020 21:16, Jesper Wilhelmsson wrote: > . . . > Since I'm not heavily involved in the updates project I don't really > have an opinion on how you run it, but I do have an observation. > . . . > > Just an observation. /Jesper Indeed, /what he said/. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From kshefov at azul.com Thu Feb 27 11:08:22 2020 From: kshefov at azul.com (Konstantin Shefov) Date: Thu, 27 Feb 2020 11:08:22 +0000 Subject: [13u-communication] CFV: 13u lead maintainer nomination for Yuri Nesterenko Message-ID: Vote: Yes -- Konstantin ________________________________ From: jdk-updates-dev on behalf of Rob McKenna Sent: Wednesday, February 26, 2020, 9:11 PM To: jdk-updates-dev at openjdk.java.net Subject: [13u-communication] CFV: 13u lead maintainer nomination for Yuri Nesterenko As the Project Lead, I would like to ask for your vote for the nomination [0] of Yuri Nesterenko as future lead maintainer. Votes are due by the 3rd of March. Only current JDK Updates Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying "Vote: yes" to this mail. For Lazy Consensus voting instructions, see [2]. -Rob [0] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-February/002535.html [1] http://openjdk.java.net/census [2] http://openjdk.java.net/bylaws#lazy-consensus From Sergey.Bylokhov at oracle.com Thu Feb 27 11:16:25 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 27 Feb 2020 03:16:25 -0800 Subject: [13u-communication] CFV: 13u lead maintainer nomination for Yuri Nesterenko In-Reply-To: <20200226181202.GE24113@yoga> References: <20200226181202.GE24113@yoga> Message-ID: <1bc35c2e-4d2f-65da-12a0-9f25e7d9433a@oracle.com> Vote: yes On 2/26/20 10:12 am, Rob McKenna wrote: > As the Project Lead, I would like to ask for your vote for the > nomination [0] of Yuri Nesterenko as future lead maintainer. > > Votes are due by the 3rd of March. > > Only current JDK Updates Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > "Vote: yes" to this mail. > > For Lazy Consensus voting instructions, see [2]. > > -Rob > > [0] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-February/002535.html > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > -- Best regards, Sergey. From hohensee at amazon.com Thu Feb 27 13:08:28 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 27 Feb 2020 13:08:28 +0000 Subject: [13u-communication] CFV: 13u lead maintainer nomination for Yuri Nesterenko In-Reply-To: <20200226181202.GE24113@yoga> References: <20200226181202.GE24113@yoga> Message-ID: <0B400E8E-AF03-4E5F-B05B-D200D0FABC52@amazon.com> Vote: yes ?On 2/26/20, 10:13 AM, "jdk-updates-dev on behalf of Rob McKenna" wrote: As the Project Lead, I would like to ask for your vote for the nomination [0] of Yuri Nesterenko as future lead maintainer. Votes are due by the 3rd of March. Only current JDK Updates Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying "Vote: yes" to this mail. For Lazy Consensus voting instructions, see [2]. -Rob [0] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-February/002535.html [1] http://openjdk.java.net/census [2] http://openjdk.java.net/bylaws#lazy-consensus From sgehwolf at redhat.com Thu Feb 27 14:14:26 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 27 Feb 2020 15:14:26 +0100 Subject: [11u] RFR: 8223260: NamingManager should cache InitialContextFactory Message-ID: <1bbc7440ed7961da2e33716c5ffa7335086bea24.camel@redhat.com> Hi, Could I please get a review for this JDK 11 backport? I'd like to backport this for Oracle JDK 11.0.7 parity. The JDK 15 patch applies cleany, but it doesn't build and the test needed a slight modification: * JDK 11u doesn't have java.io.Serial (14+ only). I've removed it from the patch in class FactoryInitializationError. * JDK 15 has JarUtils consolidated, and thus, the test needed an additional /lib/testlibrary @libray while at the same time dropping the jdk.test.lib.util.JarUtils import. Otherwise the patch is the same as in JDK 15. Bug: https://bugs.openjdk.java.net/browse/JDK-8223260 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8223260/01/webrev/ original change: https://hg.openjdk.java.net/jdk/jdk/rev/92b01977fde2 Testing: tier 1 tests and javax/naming tests. Including the new regression test, which fails before and passes after patch. Thoughts? Thanks, Severin From sgehwolf at redhat.com Thu Feb 27 14:43:34 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 27 Feb 2020 15:43:34 +0100 Subject: [RFR] [11u] JDK-8232748: "Build static versions of certain JDK libraries" In-Reply-To: <9c9053d7-3f3e-17f1-ec1f-dadba6102214@redhat.com> References: <9c9053d7-3f3e-17f1-ec1f-dadba6102214@redhat.com> Message-ID: <90baf4b54dec114854cb5286bcefda56e4d945e0.camel@redhat.com> Hi Andrew, On Thu, 2020-02-27 at 04:52 +0000, Andrew Hughes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8232748 > Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/8232748/webrev.01/ > > This patch adds targets to the build so that static versions of the JDK > native libraries can be built, using static-libs-image. Such static > versions of the libraries are required for consumption by Graal. > > With JDK-8210459 now in 11u, this is a largely clean backport, aside > from some context changes, due to additional targets (JCov, JMH) being > present in trunk: > > * In make/Bundles.gmk, 11u does not have jcov-bundles > * In make/Main.gmk, 11u does not have jcov-image or jcov-bundles > * In make/autoconf/spec.gmk.in, 11u does not have JMH_CORE_JAR, etc or > JCOV_BUNDLE_NAME. > * In make/conf/jib-profiles.js, the dependencies list in 11u doesn't > include jmh and jcov. > > Building the new target, static-libs-image, succeeded. This should have > no effect on other targets. Unfortunately this patch doesn't work. While a build of static-libs- image succeeds, it doesn't create the image in build//images. Expected is this: $ find build/linux-x86_64-normal-server-release/images/static-libs/ build/linux-x86_64-normal-server-release/images/static-libs/ build/linux-x86_64-normal-server-release/images/static-libs/lib build/linux-x86_64-normal-server-release/images/static-libs/lib/libj2pkcs11.a build/linux-x86_64-normal-server-release/images/static-libs/lib/libj2pcsc.a build/linux-x86_64-normal-server-release/images/static-libs/lib/libnio.a build/linux-x86_64-normal-server-release/images/static-libs/lib/libprefs.a build/linux-x86_64-normal-server-release/images/static-libs/lib/libjava.a build/linux-x86_64-normal-server-release/images/static-libs/lib/libjli.a build/linux-x86_64-normal-server-release/images/static-libs/lib/libnet.a build/linux-x86_64-normal-server-release/images/static-libs/lib/libjimage.a build/linux-x86_64-normal-server-release/images/static-libs/lib/libjaas.a build/linux-x86_64-normal-server-release/images/static-libs/lib/libfdlibm.a build/linux-x86_64-normal-server-release/images/static-libs/lib/libj2gss.a build/linux-x86_64-normal-server-release/images/static-libs/lib/libsunec.a build/linux-x86_64-normal-server-release/images/static-libs/lib/libjsig.a build/linux-x86_64-normal-server-release/images/static-libs/lib/libextnet.a build/linux-x86_64-normal-server-release/images/static-libs/lib/libverify.a build/linux-x86_64-normal-server-release/images/static-libs/lib/libzip.a The reason for this is that FindFiles isn't available in JDK 11u. I had to do these modifications to your patch to make it work: diff --git a/make/Bundles.gmk b/make/Bundles.gmk --- a/make/Bundles.gmk +++ b/make/Bundles.gmk @@ -367,7 +367,7 @@ ################################################################################ ifneq ($(filter static-libs-bundles, $(MAKECMDGOALS)), ) - STATIC_LIBS_BUNDLE_FILES := $(call FindFiles, $(STATIC_LIBS_IMAGE_DIR)) + STATIC_LIBS_BUNDLE_FILES := $(shell $(FIND) $(STATIC_LIBS_IMAGE_DIR)) ifeq ($(OPENJDK_TARGET_OS)-$(DEBUG_LEVEL), macosx-release) STATIC_LIBS_BUNDLE_SUBDIR := $(JDK_MACOSX_CONTENTS_SUBDIR)/Home diff --git a/make/StaticLibsImage.gmk b/make/StaticLibsImage.gmk --- a/make/StaticLibsImage.gmk +++ b/make/StaticLibsImage.gmk @@ -42,7 +42,7 @@ SRC := $(SUPPORT_OUTPUTDIR)/native/$m, \ DEST := $(STATIC_LIBS_IMAGE_DIR)/lib, \ FILES := $(filter %$(STATIC_LIBRARY_SUFFIX), \ - $(call FindFiles, $(SUPPORT_OUTPUTDIR)/native/$m/*/static)), \ + $(shell $(FIND) $(SUPPORT_OUTPUTDIR)/native/$m/*/static)), \ )) \ $(eval TARGETS += $$(COPY_STATIC_LIBS_$m)) \ ) This uses FIND directly, but there ought to be a (convoluted?) way to use CacheFind instead of FindFiles in 11u. Maybe build-dev folks could help there? Thanks, Severin From goetz.lindenmaier at sap.com Thu Feb 27 14:58:30 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 27 Feb 2020 14:58:30 +0000 Subject: [11u] RFR: 8223260: NamingManager should cache InitialContextFactory In-Reply-To: <1bbc7440ed7961da2e33716c5ffa7335086bea24.camel@redhat.com> References: <1bbc7440ed7961da2e33716c5ffa7335086bea24.camel@redhat.com> Message-ID: Hi Severin, the change looks good, adaptions are only minimal. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Severin Gehwolf > Sent: Donnerstag, 27. Februar 2020 15:14 > To: jdk-updates-dev > Subject: [11u] RFR: 8223260: NamingManager should cache > InitialContextFactory > > Hi, > > Could I please get a review for this JDK 11 backport? I'd like to > backport this for Oracle JDK 11.0.7 parity. The JDK 15 patch applies > cleany, but it doesn't build and the test needed a slight modification: > > * JDK 11u doesn't have java.io.Serial (14+ only). I've removed it from > the patch in class FactoryInitializationError. > * JDK 15 has JarUtils consolidated, and thus, the test needed an > additional /lib/testlibrary @libray while at the same time dropping > the jdk.test.lib.util.JarUtils import. > > Otherwise the patch is the same as in JDK 15. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223260 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > 8223260/01/webrev/ > original change: https://hg.openjdk.java.net/jdk/jdk/rev/92b01977fde2 > > Testing: tier 1 tests and javax/naming tests. Including the new > regression test, which fails before and passes after patch. > > Thoughts? > > Thanks, > Severin From adinn at redhat.com Thu Feb 27 15:27:26 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 27 Feb 2020 15:27:26 +0000 Subject: Hotspot Express (HSX) In-Reply-To: <8efc82f9-85d9-dc6d-9de5-62aba3c2d843@redhat.com> References: <1A373C6F-D6F7-4BB1-A5BF-2E77D087CC5B@amazon.com> <271678a3-3392-bd91-4a54-215cb20cc4ba@oracle.com> <41CE1D47-5F5D-424D-AABE-07AD640F0E56@amazon.com> <4D5DA55E-ACCD-4DE9-8E09-37BBE40205B4@amazon.com> <8A54AFA2-974F-42EA-A207-62FEA765D1AC@amazon.com> <98184652-CC83-4C6C-A7C3-C99030D869DD@oracle.com> <8efc82f9-85d9-dc6d-9de5-62aba3c2d843@redhat.com> Message-ID: <96dca808-40a0-d970-53b6-5134585f7018@redhat.com> On 27/02/2020 10:57, Andrew Dinn wrote: > On 26/02/2020 21:16, Jesper Wilhelmsson wrote: >> . . . >> Since I'm not heavily involved in the updates project I don't really >> have an opinion on how you run it, but I do have an observation. >> . . . >> >> Just an observation. /Jesper > > Indeed, /what he said/. After a private communication in which my correspondent clearly was not sure what I meant by the above comment I'll just confirm that I share Jesper's concerns and could not have articulated them more clearly. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From sgehwolf at redhat.com Thu Feb 27 16:12:44 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 27 Feb 2020 17:12:44 +0100 Subject: [11u] RFR: 8223260: NamingManager should cache InitialContextFactory In-Reply-To: References: <1bbc7440ed7961da2e33716c5ffa7335086bea24.camel@redhat.com> Message-ID: <28124f21c9286a224167a70249050af294703771.camel@redhat.com> Hi Goetz, On Thu, 2020-02-27 at 14:58 +0000, Lindenmaier, Goetz wrote: > Hi Severin, > > the change looks good, adaptions are only minimal. Thanks for the review! Cheers, Severin > Best regards, > Goetz. > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Severin Gehwolf > > Sent: Donnerstag, 27. Februar 2020 15:14 > > To: jdk-updates-dev > > Subject: [11u] RFR: 8223260: NamingManager should cache > > InitialContextFactory > > > > Hi, > > > > Could I please get a review for this JDK 11 backport? I'd like to > > backport this for Oracle JDK 11.0.7 parity. The JDK 15 patch applies > > cleany, but it doesn't build and the test needed a slight modification: > > > > * JDK 11u doesn't have java.io.Serial (14+ only). I've removed it from > > the patch in class FactoryInitializationError. > > * JDK 15 has JarUtils consolidated, and thus, the test needed an > > additional /lib/testlibrary @libray while at the same time dropping > > the jdk.test.lib.util.JarUtils import. > > > > Otherwise the patch is the same as in JDK 15. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223260 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > 8223260/01/webrev/ > > original change: https://hg.openjdk.java.net/jdk/jdk/rev/92b01977fde2 > > > > Testing: tier 1 tests and javax/naming tests. Including the new > > regression test, which fails before and passes after patch. > > > > Thoughts? > > > > Thanks, > > Severin From ravi.k.reddy at oracle.com Fri Feb 28 07:00:22 2020 From: ravi.k.reddy at oracle.com (Ravi Reddy) Date: Thu, 27 Feb 2020 23:00:22 -0800 (PST) Subject: RFA [14u] 8238452: Keytool generates wrong expiration date if validity is set to 2050/01/01 In-Reply-To: <80d9a106-d90b-46cc-a326-e44cf8f757c4@default> References: <80d9a106-d90b-46cc-a326-e44cf8f757c4@default> Message-ID: Hi, Could you please approve to push this straight backport of the following JDK 15 fix. bug report: https://bugs.openjdk.java.net/browse/JDK-8238452 code review: https://mail.openjdk.java.net/pipermail/security-dev/2020-February/021331.html Webrev: http://cr.openjdk.java.net/~pkoppula/ravire/8238452/webrev.00/ Thanks, Ravi From matthias.baesken at sap.com Fri Feb 28 08:53:09 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 28 Feb 2020 08:53:09 +0000 Subject: [jdk11u] RFR: 8229888: (zipfs) Updating an existing zip file does not preserve original permissions Message-ID: Hello, please review the downport of 8229888: (zipfs) Updating an existing zip file does not preserve original permissions to jdk11u. The change is in 11.0.7-oracle so it would be good to have it in OpenJDK 11 as well. The change touches src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java and test related files. I had to add imports to ZipFileSystem.java, and had to adjust the test file test/jdk/jdk/nio/zipfs/ZipFSPermissionsTest.java because jdk11 misses java.nio.file.FileSystems.newFileSystem(Path path, Map env) . bug : https://bugs.openjdk.java.net/browse/JDK-8229888 original jdk/jdk change : https://hg.openjdk.java.net/jdk/jdk/rev/798c0903fcd0 adjusted jdk11u change : http://cr.openjdk.java.net/~mbaesken/webrevs/8229888_0_jdk11/ Thanks, Matthias From volker.simonis at gmail.com Fri Feb 28 09:07:02 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 28 Feb 2020 10:07:02 +0100 Subject: [RFR] [11u] JDK-8232748: "Build static versions of certain JDK libraries" In-Reply-To: <90baf4b54dec114854cb5286bcefda56e4d945e0.camel@redhat.com> References: <9c9053d7-3f3e-17f1-ec1f-dadba6102214@redhat.com> <90baf4b54dec114854cb5286bcefda56e4d945e0.camel@redhat.com> Message-ID: On Thu, Feb 27, 2020 at 3:44 PM Severin Gehwolf wrote: > > Hi Andrew, > > On Thu, 2020-02-27 at 04:52 +0000, Andrew Hughes wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8232748 > > Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/8232748/webrev.01/ > > > > This patch adds targets to the build so that static versions of the JDK > > native libraries can be built, using static-libs-image. Such static > > versions of the libraries are required for consumption by Graal. > > > > With JDK-8210459 now in 11u, this is a largely clean backport, aside > > from some context changes, due to additional targets (JCov, JMH) being > > present in trunk: > > > > * In make/Bundles.gmk, 11u does not have jcov-bundles > > * In make/Main.gmk, 11u does not have jcov-image or jcov-bundles > > * In make/autoconf/spec.gmk.in, 11u does not have JMH_CORE_JAR, etc or > > JCOV_BUNDLE_NAME. > > * In make/conf/jib-profiles.js, the dependencies list in 11u doesn't > > include jmh and jcov. > > > > Building the new target, static-libs-image, succeeded. This should have > > no effect on other targets. > > Unfortunately this patch doesn't work. While a build of static-libs- > image succeeds, it doesn't create the image in build/ name>/images. Expected is this: > > $ find build/linux-x86_64-normal-server-release/images/static-libs/ > build/linux-x86_64-normal-server-release/images/static-libs/ > build/linux-x86_64-normal-server-release/images/static-libs/lib > build/linux-x86_64-normal-server-release/images/static-libs/lib/libj2pkcs11.a > build/linux-x86_64-normal-server-release/images/static-libs/lib/libj2pcsc.a > build/linux-x86_64-normal-server-release/images/static-libs/lib/libnio.a > build/linux-x86_64-normal-server-release/images/static-libs/lib/libprefs.a > build/linux-x86_64-normal-server-release/images/static-libs/lib/libjava.a > build/linux-x86_64-normal-server-release/images/static-libs/lib/libjli.a > build/linux-x86_64-normal-server-release/images/static-libs/lib/libnet.a > build/linux-x86_64-normal-server-release/images/static-libs/lib/libjimage.a > build/linux-x86_64-normal-server-release/images/static-libs/lib/libjaas.a > build/linux-x86_64-normal-server-release/images/static-libs/lib/libfdlibm.a > build/linux-x86_64-normal-server-release/images/static-libs/lib/libj2gss.a > build/linux-x86_64-normal-server-release/images/static-libs/lib/libsunec.a > build/linux-x86_64-normal-server-release/images/static-libs/lib/libjsig.a > build/linux-x86_64-normal-server-release/images/static-libs/lib/libextnet.a > build/linux-x86_64-normal-server-release/images/static-libs/lib/libverify.a > build/linux-x86_64-normal-server-release/images/static-libs/lib/libzip.a > > The reason for this is that FindFiles isn't available in JDK 11u. I had > to do these modifications to your patch to make it work: > > diff --git a/make/Bundles.gmk b/make/Bundles.gmk > --- a/make/Bundles.gmk > +++ b/make/Bundles.gmk > @@ -367,7 +367,7 @@ > ################################################################################ > > ifneq ($(filter static-libs-bundles, $(MAKECMDGOALS)), ) > - STATIC_LIBS_BUNDLE_FILES := $(call FindFiles, $(STATIC_LIBS_IMAGE_DIR)) > + STATIC_LIBS_BUNDLE_FILES := $(shell $(FIND) $(STATIC_LIBS_IMAGE_DIR)) > > ifeq ($(OPENJDK_TARGET_OS)-$(DEBUG_LEVEL), macosx-release) > STATIC_LIBS_BUNDLE_SUBDIR := $(JDK_MACOSX_CONTENTS_SUBDIR)/Home > diff --git a/make/StaticLibsImage.gmk b/make/StaticLibsImage.gmk > --- a/make/StaticLibsImage.gmk > +++ b/make/StaticLibsImage.gmk > @@ -42,7 +42,7 @@ > SRC := $(SUPPORT_OUTPUTDIR)/native/$m, \ > DEST := $(STATIC_LIBS_IMAGE_DIR)/lib, \ > FILES := $(filter %$(STATIC_LIBRARY_SUFFIX), \ > - $(call FindFiles, $(SUPPORT_OUTPUTDIR)/native/$m/*/static)), \ > + $(shell $(FIND) $(SUPPORT_OUTPUTDIR)/native/$m/*/static)), \ > )) \ > $(eval TARGETS += $$(COPY_STATIC_LIBS_$m)) \ > ) > > This uses FIND directly, but there ought to be a (convoluted?) way to > use CacheFind instead of FindFiles in 11u. Maybe build-dev folks could > help there? > Hi Severin, Andrew, there's no magic behind calling "CacheFind", you can just replace FindFiles by CacheFind. I've just did it and a test build with "make static-libs-image" resulted in the following output which seems to be correct: $ find images/static-libs/ images/static-libs/ images/static-libs/lib images/static-libs/lib/libjaas.a images/static-libs/lib/libnet.a images/static-libs/lib/libzip.a images/static-libs/lib/libfdlibm.a images/static-libs/lib/libprefs.a images/static-libs/lib/libnio.a images/static-libs/lib/libextnet.a images/static-libs/lib/libj2pcsc.a images/static-libs/lib/libjimage.a images/static-libs/lib/libsunec.a images/static-libs/lib/libjava.a images/static-libs/lib/libjsig.a images/static-libs/lib/libj2gss.a images/static-libs/lib/libverify.a images/static-libs/lib/libjli.a images/static-libs/lib/libj2pkcs11.a I've uploaded the updated webrev for your convenience to: http://cr.openjdk.java.net/~simonis/webrevs/2020/8232748.02/ While I think replacing "FindFiles" by "CacheFind" in this downport is OK, we might also consider to downport "8189861: Refactor CacheFind" which introduced "FindFiles". I think this might be useful because it was introduced in jdk13, so there might be other downports in the future which might depend on it and benefit from it being in jdk11u. We recently had another downport (8223678: Add Visual Studio Code workspace generation support (for native code)) which required "AssertEquals", something that's introduced by "8189861" as well. Andrew asked if it would make sense to downport the "AssertEquals" macro and I wnated to answer that it will probably make sense if we see another downport requiring it. Now, even before I answered we have this situation :) (this downport doesn't exactly require "AssertEquals" but "FindFiles" which was introduced with the same change). On the other hand "8189861: Refactor CacheFind" which introduced "FindFiles" isn't trivial to downport. I've just did a quick check and it require manual resolving in several files (even if I ignore the copyright-headers for now). I think I could volunteer to do it, but it would definitely require some work. Maybe now, where we'te at the beginning of 11.0.8 it's a good point in time to do such a change? I'll leave the final decision up to Andrew? Best regards, Volker > Thanks, > Severin > From volker.simonis at gmail.com Fri Feb 28 09:14:12 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 28 Feb 2020 10:14:12 +0100 Subject: [11u] RFR: 8223678: Add Visual Studio Code workspace generation support (for native code) In-Reply-To: <971e7935-c61c-1dee-dc1e-0bc567695222@redhat.com> References: <971e7935-c61c-1dee-dc1e-0bc567695222@redhat.com> Message-ID: On Wed, Feb 26, 2020 at 3:49 PM Andrew Hughes wrote: > > On 26/02/2020 10:59, Volker Simonis wrote: > > Hi, > > I'd like to downport the support for Visual Studio Code project > > creation to 11u. I think we will have to support 11u for quite some > > years and it makes sense to have as good as possible tool support in > > 11u as well: > > > > https://bugs.openjdk.java.net/browse/JDK-8223678 > > http://cr.openjdk.java.net/~simonis/webrevs/2020/8223678/ > > > > This change is the third in a series of three changes (8210459, > > 8218807, 8223678) which are required to get VS Code support in 11u. > > The first two changes (8210459, 8218807) have already been approved > > and pushed. > > > > This change only touch make files and actually only add new features > > to the make system, so the normal build results shouldn't be affected. > > I've tested that the build still works on Linux and Windows and "make > > test-make" succeeds. > > > > This change actually creates the VS Code project files (i.e. "make > > vscode-project-ccls"). See > > http://hg.openjdk.java.net/jdk/jdk/raw-file/tip/doc/ide.html for more > > details. > > > > It applies cleanly except the following two hunks. The first one had to > > be moved back from "make/common/Utils.gmk" to > > "make/common/MakeBase.gmk" where it still applies cleanly, because the > > "RelativePath" macro is still in "MakeBase.gmk" in jdk11u. > > > > ORIGINAL > > ======== > > diff -r a82a367b2d8c -r 2ae056696b15 make/common/Utils.gmk > > --- a/make/common/Utils.gmk Mon Jun 03 17:14:23 2019 -0700 > > +++ b/make/common/Utils.gmk Mon Jun 03 10:28:03 2019 +0200 > > @@ -122,7 +122,8 @@ > > # $2 - Directory to compute the relative path from > > RelativePath = \ > > $(eval $1_prefix := $(call FindCommonPathPrefix, $1, $2)) \ > > - $(eval $1_dotdots := $(call DirToDotDot, $(patsubst $($(strip > > $1)_prefix)/%, %, $2))) \ > > + $(eval $1_dotdots := $(call DirToDotDot, $(patsubst $($(strip > > $1)_prefix)%, %, $2))) \ > > + $(eval $1_dotdots := $(if $($(strip $1)_dotdots),$($(strip > > $1)_dotdots),.)) \ > > $(eval $1_suffix := $(patsubst $($(strip $1)_prefix)/%, %, $1)) \ > > $($(strip $1)_dotdots)/$($(strip $1)_suffix) > > > > JDK11u > > ====== > > diff -r 8599975f5b33 make/common/MakeBase.gmk > > --- a/make/common/MakeBase.gmk Tue Feb 12 08:40:43 2019 +0100 > > +++ b/make/common/MakeBase.gmk Mon Dec 23 22:10:46 2019 +0100 > > @@ -611,7 +611,8 @@ > > # $2 - Directory to compute the relative path from > > RelativePath = \ > > $(eval $1_prefix := $(call FindCommonPathPrefix, $1, $2)) \ > > - $(eval $1_dotdots := $(call DirToDotDot, $(patsubst $($(strip > > $1)_prefix)/%, %, $2))) \ > > + $(eval $1_dotdots := $(call DirToDotDot, $(patsubst $($(strip > > $1)_prefix)%, %, $2))) \ > > + $(eval $1_dotdots := $(if $($(strip $1)_dotdots),$($(strip > > $1)_dotdots),.)) \ > > $(eval $1_suffix := $(patsubst $($(strip $1)_prefix)/%, %, $1)) \ > > $($(strip $1)_dotdots)/$($(strip $1)_suffix) > > > > For the second changed hunk, the simple call of the "AssertEquals" > > macro had to be renamed to "assert-equals" and wrapped with "eval" > > because the corresponding macros haven't been updated in jdk11u yet. > > Notice that these are only test changes (for testing the make system > > itself) and don't effect the build at all. > > > > ORIGINAL > > ======== > > diff -r a82a367b2d8c -r 2ae056696b15 test/make/TestMakeBase.gmk > > --- a/test/make/TestMakeBase.gmk Mon Jun 03 17:14:23 2019 -0700 > > +++ b/test/make/TestMakeBase.gmk Mon Jun 03 10:28:03 2019 +0200 > > @@ -361,6 +361,18 @@ > > RelativePath, \ > > ) > > > > +$(call AssertEquals, \ > > + $(call RelativePath, /foo/bar/baz/banan/kung, /foo/bar/baz), \ > > + ./banan/kung, \ > > + RelativePath, \ > > +) > > + > > +$(call AssertEquals, \ > > + $(call RelativePath, /foo/bar/baz/banan/kung, /foo/bar/baz/), \ > > + ./banan/kung, \ > > + RelativePath, \ > > +) > > > > JDK11u > > ====== > > diff -r 8599975f5b33 test/make/TestMakeBase.gmk > > --- a/test/make/TestMakeBase.gmk Tue Feb 12 08:40:43 2019 +0100 > > +++ b/test/make/TestMakeBase.gmk Mon Dec 23 22:10:46 2019 +0100 > > @@ -325,13 +325,25 @@ > > RelativePath, \ > > )) > > > > +$(eval $(call assert-equals, \ > > + $(call RelativePath, /foo/bar/baz/banan/kung, /foo/bar/baz), \ > > + ./banan/kung, \ > > + RelativePath, \ > > +)) > > + > > +$(eval $(call assert-equals, \ > > + $(call RelativePath, /foo/bar/baz/banan/kung, /foo/bar/baz/), \ > > + ./banan/kung, \ > > + RelativePath, \ > > +)) > > > > Thanks for the comprehensive description of the changes. It looks fine > to me, though I've only eyeballed the changes & backporting, as I'm not > a potential consumer of the new rules. From that perspective, it doesn't > look like it will disrupt any existing builds. > Hi Andrew, thanks for looking at this downport. I've obviously verified that the generated VS-Code project files work :) > Out of interest, is the AssertEquals macro something worth backporting > at some point? Generally, I find its worthwhile if people are going to > be doing the same replacement in multiple backports. > I actually wanted to answer something like "..lets wait until we get another backport requiring this.." but already before answering we already ran into such a case (see my answer to the other thread "8232748: "Build static versions of certain JDK libraries"). The only problem is that "8189861: Refactor CacheFind" which introduced AssertEquals is not a trivial downport. Please let me know what you think? Best regards, Volker > 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 > From volker.simonis at gmail.com Fri Feb 28 09:24:45 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 28 Feb 2020 10:24:45 +0100 Subject: [11u] RFR: 8240073: Fix 'test-make' build target in 11u In-Reply-To: <4BEE0678-3E37-41DD-A406-F5AE0A57536F@amazon.com> References: <4BEE0678-3E37-41DD-A406-F5AE0A57536F@amazon.com> Message-ID: On Wed, Feb 26, 2020 at 5:21 PM Hohensee, Paul wrote: > > Looks to me like the replaced store to KEYWORDS is dead (i.e., no uses of KEYWORDS that I could find in make and test/make). Lgtm. Yes, that's exactly why we need this patch :) "ParseKeywordVariableBody" in "make/common/MakeBase.gmk" initially used "KEYWORDS" but when it was updated by "8212028: Use run-test makefile framework for testing in Oracle's Mach5" to use "SINGLE_KEYWORDS" instead, these two places were forgotten. Thanks for reviewing, Volker > > Thanks, > Paul > > ?On 2/26/20, 3:19 AM, "build-dev on behalf of Volker Simonis" wrote: > > Hi, > > can I please have a review for the following tiny change which fixes > the 'test-make' build target in 11u: > > http://cr.openjdk.java.net/~simonis/webrevs/2020/8240073/ > https://bugs.openjdk.java.net/browse/JDK-8240073 > > This is a tiny fix for a problem introduced by JDK-8212028 (which has > already been downported to 11u) and fixed in jdk 12 as part of > JDK-8210958 (which hasn't been downported yet and probably won't be > donwported at all). > > Instead of smuggling this fix into another downport, it has been > argued (https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-February/002533.html) > that it is cleaner to create an explicit issue for fixing it in 11u. > > The fix is trivial (that's why it was done as part of JDK-8210958 > without an extra bug ID) and only affects running "make test-make". > > Thank you and best regards, > Volker > > From aph at redhat.com Fri Feb 28 09:43:41 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 28 Feb 2020 09:43:41 +0000 Subject: Hotspot Express (HSX) In-Reply-To: <96dca808-40a0-d970-53b6-5134585f7018@redhat.com> References: <1A373C6F-D6F7-4BB1-A5BF-2E77D087CC5B@amazon.com> <271678a3-3392-bd91-4a54-215cb20cc4ba@oracle.com> <41CE1D47-5F5D-424D-AABE-07AD640F0E56@amazon.com> <4D5DA55E-ACCD-4DE9-8E09-37BBE40205B4@amazon.com> <8A54AFA2-974F-42EA-A207-62FEA765D1AC@amazon.com> <98184652-CC83-4C6C-A7C3-C99030D869DD@oracle.com> <8efc82f9-85d9-dc6d-9de5-62aba3c2d843@redhat.com> <96dca808-40a0-d970-53b6-5134585f7018@redhat.com> Message-ID: <2fede250-2bf5-4e4c-9f89-6d4b029ad4a1@redhat.com> On 2/27/20 3:27 PM, Andrew Dinn wrote: > After a private communication in which my correspondent clearly was not > sure what I meant by the above comment I'll just confirm that I share > Jesper's concerns and could not have articulated them more clearly. LOL! So there really can be a good reason for just saying "+1" ! :-) -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From volker.simonis at gmail.com Fri Feb 28 11:29:43 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 28 Feb 2020 12:29:43 +0100 Subject: Hotspot Express (HSX) In-Reply-To: <98184652-CC83-4C6C-A7C3-C99030D869DD@oracle.com> References: <1A373C6F-D6F7-4BB1-A5BF-2E77D087CC5B@amazon.com> <271678a3-3392-bd91-4a54-215cb20cc4ba@oracle.com> <41CE1D47-5F5D-424D-AABE-07AD640F0E56@amazon.com> <4D5DA55E-ACCD-4DE9-8E09-37BBE40205B4@amazon.com> <8A54AFA2-974F-42EA-A207-62FEA765D1AC@amazon.com> <98184652-CC83-4C6C-A7C3-C99030D869DD@oracle.com> Message-ID: Hi Jesper, thanks for your thoughts. They are definitely helpful for the discussion. Please find my answers/comments inline: On Wed, Feb 26, 2020 at 10:16 PM Jesper Wilhelmsson wrote: > > My personal experience from the hsx model was that it caused problems for several features we were implementing at the time. Features that actually needed to keep the JVM and the libraries in sync. That could be because we were porting a lot of the old JRockit stuff to Hotspot at that time, so there were several features that were more intrusive than the average JVM change - and there was simply a lot going on all over the place. (JFR was one of these features for instance.) > > Since I'm not heavily involved in the updates project I don't really have an opinion on how you run it, but I do have an observation. > > I find it interesting that so many experienced developers are willing to fend off all the changes that are done in the JVM as things that happen under the surface and won't be noticed by the users. Performance improvements is one thing - that you obviously want the users to notice, but all the other intricate details seems to be ignored in this discussion. Let's say there were no maintenance cost at all involved in hsx - the latest JVM could simply be plugged in to any old JDK - would you do it? > My answer to this is yes, because we've actually done it for many years (as mentioned before, with SAP JVM), and our users where quite happy about it :) Users usually want both at the same time, all the new shiny features but with full backward compatibility so they don't have to change any of their running applications. We all know that's impossible. But what are the current alternatives? You can take a new Java release every six month with just one month of overlapping support. Everybody who is seriously using Java in production knows that this is impossible. Some people claim that there are no more major Java releases since Java 9 and every new feature release (i.e. 10, 11, 12, etc.) is nothing more than a normal update release like 8u20, 8u40, etc in the old Java 8 days. In my opinion, such a claim is simply ridiculous, because most of the 10, 11, 12,.. releases are source and binary incompatible with the previous release (e.g. because the removal of the Corba, EE modules, Nashorn, new keywords, new class file versions, the removal/renaming/hiding of internal classes, etc). It doesn't matter if these incompatibilities are touching areas covered be the Java SE specification of not - what matters is that no application running on Java is guaranteed to compile/run on Java without any modification. Such problem clearly never happened in update releases like 8u20, 8u40, etc in the past. > Changes in the JVM often have several observable effects. Faster execution can be one of them. But reordering of instructions, changes in cache behavior, NUMA behavior, locking schemes and thread synchronization, or even simple bugfixes can from time to time cause unexpected results in the execution of the Java application and even break code that deliberately or undeliberately depends on a certain unspecified behavior. Not to mention even more intrusive, deliberate changes in default values, default algorithms or even the existence of algorithms. Would an hsx model happily pick up a new JVM where the default GC was changed to G1, or where CMS was removed and plug it into a JDK 8 running in production out there? > What you write is of course true. But these are not source or binary incompatible changes (and if such should exists, it would be the job of the HSX project to work them around). Also, if a new JVM changes some defaults, it would again be up to the HSX project to decide if it will use the same, changed defaults or remain with the old ones. As an example, HSX would probably not change the default GC but still give the users of HSX the possibility to use a new GC which they wouldn't have otherwise (a HSX project could even maintain a GC removed from the latest JVM for some additional amount of time). On the other hand, changing the MaxInlineDepth would be probably a changed default which could be safely adapted by HSX after careful testing. For example in SAP JVM, we never changed the default GC in older releases, but we gave users of Java 5/6 the possibility to use G1, which they wouldn't have had otherwise because downporting G1 would have been impractical if not impossible. > The JVM isn't an isolated library that lives its own life without contact with the rest of the JDK. Changes in the JVM often go hand in hand with changes in the language. Which GC behaves the best depends on how the language is used and what kind of objects that fills the heap. This in turn depends heavily on what language features that are used. The same goes for the JIT compilers, different optimizations have different effect on the executed code depending on what language constructs are used in the Java application. The optimizations done in a JVM designed for JDK 15 is not necessarily the best choices for a JVM intended for JDK 11. > That's all true. But in the end one has to decide what's cheaper, more efficient and more attractive for the users: regularly downporting hundred of bugfixes and maintaining big features like Shenandoah or GraalVM in several major JDK versions in parallel or maintaining a HSX version of the current JVM which gives you all the fixes and new features for free. I just want to re-iterate one more time: - this proposal is not about changing jdk tip or jdk tip development - it's also not about changing how the updates project is run The proposal is about evaluating the advantages and drawbacks of HSX in a new project. It would be nice to have such a project under the OpenJDK umbrella, but if nobody is interested at all, it can just as well be developed independently. Best regards, Volker > Just an observation. > /Jesper > > > On 26 Feb 2020, at 17:12, Hohensee, Paul wrote: > > > > And, when jdk17 ships, it would affect only jdk17u. > > > > Paul > > > > ?On 2/26/20, 1:50 AM, "jdk-updates-dev on behalf of Dalibor Topic" wrote: > > > > > > > > On 26.02.2020 01:16, Volker Simonis wrote: > >> The proposed HSX approach isn't gonna change this at all. It will always > >> use the latest released HS version in the current LTS JDK. > > > > Thanks for clarifying that your proposal would affect OpenJDK 11 Updates > > only, Volker. > > > > 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 > > > > > > > From ron.pressler at oracle.com Fri Feb 28 13:57:02 2020 From: ron.pressler at oracle.com (Ron Pressler) Date: Fri, 28 Feb 2020 13:57:02 +0000 Subject: Hotspot Express (HSX) In-Reply-To: References: <1A373C6F-D6F7-4BB1-A5BF-2E77D087CC5B@amazon.com> <271678a3-3392-bd91-4a54-215cb20cc4ba@oracle.com> <41CE1D47-5F5D-424D-AABE-07AD640F0E56@amazon.com> <4D5DA55E-ACCD-4DE9-8E09-37BBE40205B4@amazon.com> <8A54AFA2-974F-42EA-A207-62FEA765D1AC@amazon.com> <98184652-CC83-4C6C-A7C3-C99030D869DD@oracle.com> Message-ID: ? On 28 February 2020 at 11:30:19, Volker Simonis (volker.simonis at gmail.com(mailto:volker.simonis at gmail.com)) wrote: > Some people claim that there are no more major Java releases since > Java 9? "Major releases? don?t have a precise definition, but that major releases *as they were in Java up to 9? clearly and factually no longer exist, as as any examination of the release notes would confirm. > and every new feature release (i.e. 10, 11, 12, etc.) is > nothing more than a normal update release like 8u20, 8u40, etc in the > old Java 8 days.? Not *nothing* more, but *little* more, as confirmed in practice by those who do these migrations regularly. > In my opinion, such a claim is simply ridiculous, > because most of the 10, 11, 12,.. releases are source and binary > incompatible with the previous release (e.g. because the removal of > the Corba, EE modules, Nashorn, new keywords, new class file versions, > the removal/renaming/hiding of internal classes, etc).? I don?t understand this argument. When Nashorn is removed in 15 how will HSX help keep it alive in 11u? When finalizers are removed, how will HSX keep them alive? > Such problem clearly never happened in update > releases like 8u20, 8u40, etc in the past. This is not true, as an examination of the bug database would? confirm.?Sure, the new feature releases require more work than the? old feature releases. The question is *how much* more? The answer is: not that much, and while it will always be somewhat more (in exchange for no more major upgrades), the amount of additional work required is constantly decreasing as more libraries and tools (Spring, Gradle) are supporting the current model. > The proposal is about evaluating the advantages and drawbacks of HSX > in a new project. Paul said something about stability of the old major release, but of course you believe the current JDK to be stable (at the very least modulo changes to javac/libs, though I don?t know why they'd be less stable than VM changes) or you wouldn?t propose HSX, which depends on that assumption. You?re suggesting to take code you trust to be stable but that your customers might not, have a small team subtly change it, and then package the result under a label that would sound more stable to some customers who might not be as educated as we are on the changes to the OpenJDK?s development process and version naming scheme. True, there are migration challenges, but we know they're rather small, post 9, from people who have gone through them, and we're working with members of the ecosystem to make them smaller still. Also true, some fear that OpenJDK will remove a feature they rely on. But entrenching a mistrust for OpenJDK?s general commitment to backward compatibility because it's somewhat changed ? to be more sustainable ? is a mirage. For example, now that CMS is no longer maintained in tip, it is likely to de facto become unmaintained in Updates; same for Nashorn when it is removed. Yet customers might not realize that; if we don?t explain it to them, why should they? Projecting an image of "everything is as it was" might help calm them in the short term, because change is scary, but is harmful in the longer term because the change is real, and HSX can't undo it.? The upside is that the new model is better than the old one; there's no need to? reach for an approach conceived when things weren?t working as well. What I propose instead is to educate customers on the changes to OpenJDK?s development and release process, and explain to those who wish to enjoy the enhancements in the JDK that it is stable ? or, at least, stable enough for those benefits important to them to outweigh the risk ? that they should just use it. It's ?significantly cheaper and less risky than adopting a competing platform. And if the risk is real, and to some extent I suppose it is, those who, over anything else, wish to avoid it will be better served by a conservative approach that reduces it than by one that hides it. - Ron > > > > > On 26 Feb 2020, at 17:12, Hohensee, Paul wrote: > > > > > > And, when jdk17 ships, it would affect only jdk17u. > > > > > > Paul > > > > > > ?On 2/26/20, 1:50 AM, "jdk-updates-dev on behalf of Dalibor Topic" wrote: > > > > > > > > > > > > On 26.02.2020 01:16, Volker Simonis wrote: > > >> The proposed HSX approach isn't gonna change this at all. It will always > > >> use the latest released HS version in the current LTS JDK. > > > > > > Thanks for clarifying that your proposal would affect OpenJDK 11 Updates > > > only, Volker. > > > > > > 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 > > > > > > > > > > > From neugens at redhat.com Fri Feb 28 14:15:58 2020 From: neugens at redhat.com (Mario Torre) Date: Fri, 28 Feb 2020 15:15:58 +0100 Subject: Hotspot Express (HSX) In-Reply-To: References: <1A373C6F-D6F7-4BB1-A5BF-2E77D087CC5B@amazon.com> <271678a3-3392-bd91-4a54-215cb20cc4ba@oracle.com> <41CE1D47-5F5D-424D-AABE-07AD640F0E56@amazon.com> <4D5DA55E-ACCD-4DE9-8E09-37BBE40205B4@amazon.com> <8A54AFA2-974F-42EA-A207-62FEA765D1AC@amazon.com> <98184652-CC83-4C6C-A7C3-C99030D869DD@oracle.com> Message-ID: On Fri, Feb 28, 2020 at 2:57 PM Ron Pressler wrote: > > > In my opinion, such a claim is simply ridiculous, > > because most of the 10, 11, 12,.. releases are source and binary > > incompatible with the previous release (e.g. because the removal of > > the Corba, EE modules, Nashorn, new keywords, new class file versions, > > the removal/renaming/hiding of internal classes, etc). > > I don?t understand this argument. When Nashorn is removed in 15 how > will HSX help keep it alive in 11u? When finalizers are removed, > how will HSX keep them alive? This is not what Volker is claiming, if I understood him correctly, he means that current updates across jdks already have incompatible behaviour introduced via source or binary changes. So there's a stronger evidence that supporting the LTS for longer is necessary, and that it would benefit from having a shared Hotspot rather than backporting single patches. I see his point, I don't know if I agree with him more or I'm more inclined to second what Jesper said though, both have valid arguments to me. > > Such problem clearly never happened in update > > releases like 8u20, 8u40, etc in the past. > > Sure, the new feature releases require more work than the > old feature releases. The question is *how much* more? The answer > is: not that much Of course, analysing the bug database is a good indication of the indirect work of feature backport, but I think this sort of answers can't be given by us directly, but are a result of customer relationship more than anything else. It's entirely possible that some customers wanted the HSX features from SAP as Volker suggested and some other prefer the stability of fine tuned single backport. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From hohensee at amazon.com Fri Feb 28 15:28:40 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 28 Feb 2020 15:28:40 +0000 Subject: Hotspot Express (HSX) In-Reply-To: <9f974c51-f246-1d6b-6377-c6e75cf9f72d@oracle.com> References: <1A373C6F-D6F7-4BB1-A5BF-2E77D087CC5B@amazon.com> <271678a3-3392-bd91-4a54-215cb20cc4ba@oracle.com> <41CE1D47-5F5D-424D-AABE-07AD640F0E56@amazon.com> <4D5DA55E-ACCD-4DE9-8E09-37BBE40205B4@amazon.com> <9f974c51-f246-1d6b-6377-c6e75cf9f72d@oracle.com> Message-ID: <4C19E352-1BC1-4A13-86C1-C4BB65F929F7@amazon.com> Re flags/features and compiler upgrades, my current HSX investigation covers delivering it only wrt to the latest LTS release, so I'm only thinking about 3 years, not forever, though process would the similar in the forever case. When HSX was policy, flag and feature changes were handled much the same way they are now in JSX. I.e., deprecated and eventually removed, though physical removal was usually deferred to an LTS release. New features started out experimental, were default disabled until production ready, and when enabled, old flags became either nops or were translated to the nearest new equivalent. Once the new feature was in production and had possibly been made the default, we kept the now-deprecated old feature around for a transition period whose length varied with the feature. For CMS, I'd have proposed removing it in an LTS release: if people wanted it, they could use the previous LTS release, which would now be off HSX. Timing of C++ compiler upgrades depends on whether it's just a toolchain upgrade or involves using new language features. Tool chain upgrades for tip aren't that big a deal (we're doing this already) and can be checked for in the most recent LTS release's makefiles: mostly they involve more-pedantic error checking, for which source changes are accepted by earlier versions. If the intent is to use more recent C++ language features, I'd propose allowing those only starting with an LTS release and provide lots of notice. Three year intervals seem to me short enough for this kind of change, though I realize some may disagree. If HSX were extended to earlier LTS releases, a potential solution would be to upgrade their tool chains, backport non-HSX source code changes as needed (i.e., to satisfy more-pedantic compilers), and restrict builds using old toolchains to security patches only (i.e., take them out of HSX). Thanks, Paul ?On 2/21/20, 8:56 AM, "Claes Redestad" wrote: On 2020-02-21 16:45, Volker Simonis wrote: > I don't agree with what's been said in this thread before, namely that > a strong coupling of VM and JDK "is good" for OpenJDK, helps > accelerating the development and improves the performance. Let's agree to disagree. The speed-up in OpenJDK mainline development I've witnessed over my 7 years working here has been remarkable. Of course removing hsx is only partially to thank for this, but it's an important piece in a greater scheme to remove impediments that would have been at odds with many of the tougher decisions made over the past few years. For example consolidated repositories have decidedly helped streamline work, especially when needing to sync changes from jdk to hotspot and vice versa. Of course you can have hsx in a consolidated world, but it does work against you. A more allowing stance on feature removals have also helped us shed a lot of weight. Removing anything is bound to be a lot messier in a world with hsx. Not to mention java modules, the implementation for which I think would have ended up much messier if the hsx model was retained. > In contrary, I think it will lead to bad "ad-hoc" decisions and wrong > dependencies which might be helpful for the moment but which introduce > considerable maintenance costs in the long term. From my experience this seems unlikely, but yes, there will be fewer checks against it. As a counterpoint I believe most decisions are very mindful about maintenance costs, to the point where reducing future maintenance cost is usually the sole motivator - sometimes at expense of customer convenience. See the removal of CMS, for example. On that note, how _would_ this hsx project deal with features and flags that are deprecated and removed from the mainline? Will you need to resurrect removed features such as CMS, but hide the code behind build flags..? And looking further, how would hsx deal with a project like the C++ compiler upgrade[1], which will change system requirements and thus be unsuitable for a backport? /Claes [1] https://openjdk.java.net/jeps/347 From dalibor.topic at oracle.com Fri Feb 28 16:44:49 2020 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 28 Feb 2020 17:44:49 +0100 Subject: Hotspot Express (HSX) In-Reply-To: References: <1A373C6F-D6F7-4BB1-A5BF-2E77D087CC5B@amazon.com> <271678a3-3392-bd91-4a54-215cb20cc4ba@oracle.com> <41CE1D47-5F5D-424D-AABE-07AD640F0E56@amazon.com> <4D5DA55E-ACCD-4DE9-8E09-37BBE40205B4@amazon.com> <8A54AFA2-974F-42EA-A207-62FEA765D1AC@amazon.com> <98184652-CC83-4C6C-A7C3-C99030D869DD@oracle.com> Message-ID: On 28.02.2020 12:29, Volker Simonis wrote: > I just want to re-iterate one more time: > - this proposal is not about changing jdk tip or jdk tip development > - it's also not about changing how the updates project is run > > The proposal is about evaluating the advantages and drawbacks of HSX > in a new project. It would be nice to have such a project under the > OpenJDK umbrella, but if nobody is interested at all, it can just as > well be developed independently. Hi Volker, I have to admit that I'm still a bit confused about the scope of the proposal, as it sounded to me a few days ago as if this was a proposal to modify the jdk11u/jdk11u repository in some way or another, or maybe even to establish another jdk11u/jdk11u-hsx (?) repository within the JDK Updates Project. Now it sounds like you're thinking about creating a new OpenJDK Project instead. So maybe it would be helpful to start a new thread which more plainly states what the suggested scope is instead of continuing to get deeper into the back and forth of this thread, as I suspect the number of people who can follow all this and still understand it is getting smaller with each further e-mail. ;) 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 From volker.simonis at gmail.com Fri Feb 28 18:03:42 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 28 Feb 2020 19:03:42 +0100 Subject: Hotspot Express (HSX) In-Reply-To: References: <1A373C6F-D6F7-4BB1-A5BF-2E77D087CC5B@amazon.com> <271678a3-3392-bd91-4a54-215cb20cc4ba@oracle.com> <41CE1D47-5F5D-424D-AABE-07AD640F0E56@amazon.com> <4D5DA55E-ACCD-4DE9-8E09-37BBE40205B4@amazon.com> <8A54AFA2-974F-42EA-A207-62FEA765D1AC@amazon.com> <98184652-CC83-4C6C-A7C3-C99030D869DD@oracle.com> Message-ID: On Fri, Feb 28, 2020 at 5:45 PM Dalibor Topic wrote: > > > > On 28.02.2020 12:29, Volker Simonis wrote: > > > I just want to re-iterate one more time: > > - this proposal is not about changing jdk tip or jdk tip development > > - it's also not about changing how the updates project is run > > > > The proposal is about evaluating the advantages and drawbacks of HSX > > in a new project. It would be nice to have such a project under the > > OpenJDK umbrella, but if nobody is interested at all, it can just as > > well be developed independently. > > Hi Volker, > > I have to admit that I'm still a bit confused about the scope of the > proposal, as it sounded to me a few days ago as if this was a proposal > to modify the jdk11u/jdk11u repository in some way or another, or maybe > even to establish another jdk11u/jdk11u-hsx (?) repository within the > JDK Updates Project. > > Now it sounds like you're thinking about creating a new OpenJDK Project > instead. > > So maybe it would be helpful to start a new thread which more plainly > states what the suggested scope is instead of continuing to get deeper > into the back and forth of this thread, as I suspect the number of > people who can follow all this and still understand it is getting > smaller with each further e-mail. ;) > Hi Dalibor, this thread is the discussion about a concept. The concept is called HotSpot Express (HSX). More senior colleagues will remember it from the old jdk 6,7,8 days. I think Paul described it pretty well in his initial mail, but in short, "in the HotSpot Express release model, new versions of HotSpot are drawn from its leading development line ... and prepared for delivery as product-quality JVMs" in older JDK releases. This is by the way cited directly from Erik Trimble's Project proposal from 2009 [1]. For those of you who like software archeology, I strongly recommend another of Erik's mails [2] where he describes in great detail how this process worked for jdk 7 and 8. And by the way, everybody who ever used Oracle JDK 6 & 7 has already used HSX. What you are asking now, is how this concept can be implemented? Of course there are plenty of possibilities for doing that and the details are obviously not decided yet. That's what this thread has been created for in the first place. HSX can be a sub-project of the Updates project in which case it would get its own repository as you suggested (maybe jdk11u/jdk11u-hsx ?). If it is successful and the jdk11u maintainers like it, it may even be merged into jdk1u/jdk11u eventually. On the other hand, if there's absolutely no interest in the HSX project from the people involved in the Updates Project, HSX might be developed in its own OpenJDK Project, which still would have to be proposed and created. As a last resort, if nobody in the OpenJDK community at all is interested in HSX, there's still the possibility to develop it in a downstream project. You see, all pretty simple. No need to worry :) We got exactly what we wanted - a discussion about HotSpot Exress in a thread called "Hotspot Express (HSX)". Regards, Volker PS: Ceci n'est pas HotSpot Exress [3] :) [1] http://mail.openjdk.java.net/pipermail/jdk7u-dev/2011-August/000160.html [2] http://mail.openjdk.java.net/pipermail/jdk7u-dev/2011-August/000160.html [3] https://en.wikipedia.org/wiki/The_Treachery_of_Images > 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 > From mikael.vidstedt at oracle.com Fri Feb 28 18:24:00 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 28 Feb 2020 10:24:00 -0800 Subject: Hotspot Express (HSX) In-Reply-To: <4C19E352-1BC1-4A13-86C1-C4BB65F929F7@amazon.com> References: <1A373C6F-D6F7-4BB1-A5BF-2E77D087CC5B@amazon.com> <271678a3-3392-bd91-4a54-215cb20cc4ba@oracle.com> <41CE1D47-5F5D-424D-AABE-07AD640F0E56@amazon.com> <4D5DA55E-ACCD-4DE9-8E09-37BBE40205B4@amazon.com> <9f974c51-f246-1d6b-6377-c6e75cf9f72d@oracle.com> <4C19E352-1BC1-4A13-86C1-C4BB65F929F7@amazon.com> Message-ID: > On Feb 28, 2020, at 7:28 AM, Hohensee, Paul wrote: > > Re flags/features and compiler upgrades, my current HSX investigation covers delivering it only wrt to the latest LTS release, so I'm only thinking about 3 years, not forever, though process would the similar in the forever case. > > When HSX was policy, flag and feature changes were handled much the same way they are now in JSX. I.e., deprecated and eventually removed, though physical removal was usually deferred to an LTS release. New features started out experimental, were default disabled until production ready, and when enabled, old flags became either nops or were translated to the nearest new equivalent. Once the new feature was in production and had possibly been made the default, we kept the now-deprecated old feature around for a transition period whose length varied with the feature. For CMS, I'd have proposed removing it in an LTS release: if people wanted it, they could use the previous LTS release, which would now be off HSX. > > Timing of C++ compiler upgrades depends on whether it's just a toolchain upgrade or involves using new language features. Tool chain upgrades for tip aren't that big a deal (we're doing this already) and can be checked for in the most recent LTS release's makefiles: mostly they involve more-pedantic error checking, for which source changes are accepted by earlier versions. If the intent is to use more recent C++ language features, I'd propose allowing those only starting with an LTS release and provide lots of notice. Three year intervals seem to me short enough for this kind of change, though I realize some may disagree. If HSX were extended to earlier LTS releases, a potential solution would be to upgrade their tool chains, backport non-HSX source code changes as needed (i.e., to satisfy more-pedantic compilers), and restrict builds using old toolchains to security patches only (i.e., take them out of HSX). If I understand you correctly, you?re suggesting holding up many of the significant changes until the next LTS. That sounds like to opposite of what we want. Doing so would introduce significantly more risk in the LTS releases, which are the exact ones we'd ideally *minimize* risk in since we?ll be maintaining them much longer. Theoretically we should really make the significant changes in the very first release after an LTS to get the maximum amount of feedback in time for the next LTS. Also, one of the beauties of the new model is that we don?t really have to care about when releases happen or what kind of release they are, and in particular we don?t have to hold things up. When things are ready they get integrated. No need to sit on changes, keep side branches up to date, or do any flag dancing. Not having to care about which release a feature ?must? go into is a true win - developer/planning/stress. Getting those features integrated early means we can move on and work on the next thing, building on top of it. Unless I?m missing something I think your proposal would add risk to all releases, and slow down innovation in mainline, and I think that?s the wrong tradeoff. Cheers, Mikael From ioi.lam at oracle.com Fri Feb 28 18:29:01 2020 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 28 Feb 2020 10:29:01 -0800 Subject: Hotspot Express (HSX) In-Reply-To: References: <1A373C6F-D6F7-4BB1-A5BF-2E77D087CC5B@amazon.com> <271678a3-3392-bd91-4a54-215cb20cc4ba@oracle.com> <41CE1D47-5F5D-424D-AABE-07AD640F0E56@amazon.com> <4D5DA55E-ACCD-4DE9-8E09-37BBE40205B4@amazon.com> <8A54AFA2-974F-42EA-A207-62FEA765D1AC@amazon.com> <98184652-CC83-4C6C-A7C3-C99030D869DD@oracle.com> Message-ID: <31e0b21b-dcc6-f39c-4d6a-b48bef1a17e5@oracle.com> On 2/28/20 10:03 AM, Volker Simonis wrote: > On Fri, Feb 28, 2020 at 5:45 PM Dalibor Topic wrote: >> >> >> On 28.02.2020 12:29, Volker Simonis wrote: >> >>> I just want to re-iterate one more time: >>> - this proposal is not about changing jdk tip or jdk tip development >>> - it's also not about changing how the updates project is run >>> >>> The proposal is about evaluating the advantages and drawbacks of HSX >>> in a new project. It would be nice to have such a project under the >>> OpenJDK umbrella, but if nobody is interested at all, it can just as >>> well be developed independently. >> Hi Volker, >> >> I have to admit that I'm still a bit confused about the scope of the >> proposal, as it sounded to me a few days ago as if this was a proposal >> to modify the jdk11u/jdk11u repository in some way or another, or maybe >> even to establish another jdk11u/jdk11u-hsx (?) repository within the >> JDK Updates Project. >> >> Now it sounds like you're thinking about creating a new OpenJDK Project >> instead. >> >> So maybe it would be helpful to start a new thread which more plainly >> states what the suggested scope is instead of continuing to get deeper >> into the back and forth of this thread, as I suspect the number of >> people who can follow all this and still understand it is getting >> smaller with each further e-mail. ;) >> > Hi Dalibor, > > this thread is the discussion about a concept. The concept is called > HotSpot Express (HSX). More senior colleagues will remember it from > the old jdk 6,7,8 days. I think Paul described it pretty well in his > initial mail, but in short, "in the HotSpot Express release model, new > versions of HotSpot are drawn from its leading development line ... > and prepared for delivery as product-quality JVMs" in older JDK > releases. This is by the way cited directly from Erik Trimble's > Project proposal from 2009 [1]. For those of you who like software > archeology, I strongly recommend another of Erik's mails [2] where he > describes in great detail how this process worked for jdk 7 and 8. And > by the way, everybody who ever used Oracle JDK 6 & 7 has already used > HSX. > > What you are asking now, is how this concept can be implemented? Of > course there are plenty of possibilities for doing that and the > details are obviously not decided yet. That's what this thread has > been created for in the first place. > > HSX can be a sub-project of the Updates project in which case it would > get its own repository as you suggested (maybe jdk11u/jdk11u-hsx ?). > If it is successful and the jdk11u maintainers like it, it may even be > merged into jdk1u/jdk11u eventually. On the other hand, if there's > absolutely no interest in the HSX project from the people involved in > the Updates Project, HSX might be developed in its own OpenJDK > Project, which still would have to be proposed and created. As a last > resort, if nobody in the OpenJDK community at all is interested in > HSX, there's still the possibility to develop it in a downstream > project. Without expressing my opinion whether HSX is a good idea (I do have an opinion :-), I would encourage the HSX proponents to consider what the implementation would look like. The old implementation of HSX just drops in a new HotSpot VM (libjvm.so) into an older JDK, and that puts a lot of burden on HotSpot development. It was also done in an era where the "JDK" was just the library and "HotSpot" was the language execution engine. However, today large parts of the execution engine (e.g., Lambda) is implemented inside JDK core libs and are inseparable from the corresponding version of libjvm.so. So if the proposal is "let's go back to the old way", that's simply impossible. I think for the HSX idea to get traction, we need a more concrete proposal of - what part of a new JDK release will be extracted and installed into an older release - what's the extraction/installation model? ? - Just copy binary files? ? - Manipulation of binary files by tools (jlink??) ? - source level rebuild? If we just keep arguing on the merits of the "idea", it will probably not go anywhere. Thanks - Ioi > You see, all pretty simple. No need to worry :) > We got exactly what we wanted - a discussion about HotSpot Exress in a > thread called "Hotspot Express (HSX)". > > Regards, > Volker > > PS: Ceci n'est pas HotSpot Exress [3] :) > > [1] http://mail.openjdk.java.net/pipermail/jdk7u-dev/2011-August/000160.html > [2] http://mail.openjdk.java.net/pipermail/jdk7u-dev/2011-August/000160.html > [3] https://en.wikipedia.org/wiki/The_Treachery_of_Images > >> 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 >> From thomas.stuefe at gmail.com Fri Feb 28 18:38:34 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 28 Feb 2020 19:38:34 +0100 Subject: Hotspot Express (HSX) In-Reply-To: References: <1A373C6F-D6F7-4BB1-A5BF-2E77D087CC5B@amazon.com> <271678a3-3392-bd91-4a54-215cb20cc4ba@oracle.com> <41CE1D47-5F5D-424D-AABE-07AD640F0E56@amazon.com> <4D5DA55E-ACCD-4DE9-8E09-37BBE40205B4@amazon.com> <8A54AFA2-974F-42EA-A207-62FEA765D1AC@amazon.com> <98184652-CC83-4C6C-A7C3-C99030D869DD@oracle.com> Message-ID: Hi Volker, On Fri, Feb 28, 2020 at 12:30 PM Volker Simonis wrote: > Hi Jesper, > > thanks for your thoughts. They are definitely helpful for the > discussion. Please find my answers/comments inline: > > On Wed, Feb 26, 2020 at 10:16 PM Jesper Wilhelmsson > wrote: > > > > My personal experience from the hsx model was that it caused problems > for several features we were implementing at the time. Features that > actually needed to keep the JVM and the libraries in sync. That could be > because we were porting a lot of the old JRockit stuff to Hotspot at that > time, so there were several features that were more intrusive than the > average JVM change - and there was simply a lot going on all over the > place. (JFR was one of these features for instance.) > > > > Since I'm not heavily involved in the updates project I don't really > have an opinion on how you run it, but I do have an observation. > > > > I find it interesting that so many experienced developers are willing to > fend off all the changes that are done in the JVM as things that happen > under the surface and won't be noticed by the users. Performance > improvements is one thing - that you obviously want the users to notice, > but all the other intricate details seems to be ignored in this discussion. > Let's say there were no maintenance cost at all involved in hsx - the > latest JVM could simply be plugged in to any old JDK - would you do it? > > > > My answer to this is yes, because we've actually done it for many > years (as mentioned before, with SAP JVM), and our users where quite > happy about it :) > Opinions differ :-) I personally think your retrospective is both a bit rosy and not really applicable to the current situation in the OpenJDK. Note that I only talk for personal self here, not for my team. I remember when we first implemented the hsx model - I was one of the original developers - and the reason we did this was because we had a huge load of valuable in-house developments which we had no choice but to provide on every release and - in that time, before the OpenJDK was a thing - without a way to contribute upstream. We then felt we really had no other choice. In that time, JDK upstream dev velocity was low, way lower than our own development speed, and so the hsx model seemed like the lesser evil. But we never really measured the costs hsx incurred. All we have is feelings, and feelings differ a lot depending on how one was involved. My personal feeling was that the costs were considerable, and often not directly obvious and easily overlooked. > Users usually want both at the same time, This is a conjecture, unless we have numbers to prove this. How many of our customers really want new features, and how many just want to be left alone, have a stable JDK which gets important bug fixes and security fixes, but would feel uncomfortable if they knew that a large part of their "old" JDK is actually from the latest release - which by the nature of things has seen less field hours than the old VM? This is not an argument against hsx, but I argue that there exists those two groups of customers, and we do not know how large they are. > all the new shiny features > but with full backward compatibility so they don't have to change any > of their running applications. We all know that's impossible. But what > are the current alternatives? You can take a new Java release every > six month with just one month of overlapping support. Everybody who is > seriously using Java in production knows that this is impossible. > > Some people claim that there are no more major Java releases since > Java 9 and every new feature release (i.e. 10, 11, 12, etc.) is > nothing more than a normal update release like 8u20, 8u40, etc in the > old Java 8 days. In my opinion, such a claim is simply ridiculous, > because most of the 10, 11, 12,.. releases are source and binary > incompatible with the previous release (e.g. because the removal of > the Corba, EE modules, Nashorn, new keywords, new class file versions, > the removal/renaming/hiding of internal classes, etc). It doesn't > matter if these incompatibilities are touching areas covered be the > Java SE specification of not - what matters is that no application > running on Java is guaranteed to compile/run on Java without > any modification. Such problem clearly never happened in update > releases like 8u20, 8u40, etc in the past. > > > Changes in the JVM often have several observable effects. Faster > execution can be one of them. But reordering of instructions, changes in > cache behavior, NUMA behavior, locking schemes and thread synchronization, > or even simple bugfixes can from time to time cause unexpected results in > the execution of the Java application and even break code that deliberately > or undeliberately depends on a certain unspecified behavior. Not to mention > even more intrusive, deliberate changes in default values, default > algorithms or even the existence of algorithms. Would an hsx model happily > pick up a new JVM where the default GC was changed to G1, or where CMS was > removed and plug it into a JDK 8 running in production out there? > > > > What you write is of course true. But these are not source or binary > incompatible changes (and if such should exists, it would be the job > of the HSX project to work them around). Also, if a new JVM changes > some defaults, it would again be up to the HSX project to decide if it > will use the same, changed defaults or remain with the old ones. As an > example, HSX would probably not change the default GC but still give > the users of HSX the possibility to use a new GC which they wouldn't > have otherwise (a HSX project could even maintain a GC removed from > the latest JVM for some additional amount of time). On the other hand, > changing the MaxInlineDepth would be probably a changed default which > could be safely adapted by HSX after careful testing. For example in > SAP JVM, we never changed the default GC in older releases, but we > gave users of Java 5/6 the possibility to use G1, which they wouldn't > have had otherwise because downporting G1 would have been impractical > if not impossible. > > > The JVM isn't an isolated library that lives its own life without > contact with the rest of the JDK. Changes in the JVM often go hand in hand > with changes in the language. Which GC behaves the best depends on how the > language is used and what kind of objects that fills the heap. This in turn > depends heavily on what language features that are used. The same goes for > the JIT compilers, different optimizations have different effect on the > executed code depending on what language constructs are used in the Java > application. The optimizations done in a JVM designed for JDK 15 is not > necessarily the best choices for a JVM intended for JDK 11. > > > > That's all true. But in the end one has to decide what's cheaper, more > efficient and more attractive for the users: regularly downporting > hundred of bugfixes and maintaining big features like Shenandoah or > GraalVM in several major JDK versions in parallel or maintaining a HSX > version of the current JVM which gives you all the fixes and new > features for free. > > I just want to re-iterate one more time: > - this proposal is not about changing jdk tip or jdk tip development > - it's also not about changing how the updates project is run > > The proposal is about evaluating the advantages and drawbacks of HSX > in a new project. I don't understand. Would a hsx model not have deep implications about development at jdk tip? Whether or not we think about this in an own project is irrelevant, unless I misunderstand things. > It would be nice to have such a project under the > OpenJDK umbrella, but if nobody is interested at all, it can just as > well be developed independently. > How? The hsx model imposes limits on the developers of jdk tip. How could it live without their buy-in? > Best regards, > Volker > > Cheers, Thomas > > Just an observation. > > /Jesper > > > > > On 26 Feb 2020, at 17:12, Hohensee, Paul wrote: > > > > > > And, when jdk17 ships, it would affect only jdk17u. > > > > > > Paul > > > > > > ?On 2/26/20, 1:50 AM, "jdk-updates-dev on behalf of Dalibor Topic" < > jdk-updates-dev-bounces at openjdk.java.net on behalf of > dalibor.topic at oracle.com> wrote: > > > > > > > > > > > > On 26.02.2020 01:16, Volker Simonis wrote: > > >> The proposed HSX approach isn't gonna change this at all. It will > always > > >> use the latest released HS version in the current LTS JDK. > > > > > > Thanks for clarifying that your proposal would affect OpenJDK 11 > Updates > > > only, Volker. > > > > > > 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 > > > > > > > > > > > > From jbollinger at wrallp.com Wed Feb 5 18:36:53 2020 From: jbollinger at wrallp.com (Bollinger, Jason) Date: Wed, 05 Feb 2020 18:36:53 -0000 Subject: If you can answer great, if not I understand Message-ID: Can you tell me what the difference is between OpenJDK JRE Version 1.8 and version 11. I am sorry I am not a programmer. Do these versions get security updates often? Thanks, Jason The information supplied in this message may be privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient of this message, the sender does not intend delivery to you to waive any privilege or right pertaining to this message. You have no right to retain, disseminate, copy or disclose the material contained herein. If you have received this message in error, please immediately notify the sender by return e-mail, and delete the errant message. Thank you. WRA_Disclaimer_v20070222a