From gnu.andrew at redhat.com  Mon Mar  1 13:45:41 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 1 Mar 2021 13:45:41 +0000
Subject: FW: RFR: [8u] 6878250: (so) IllegalBlockingModeException thrown
 when reading from a closed SocketChannel's InputStream
In-Reply-To: <8FC616E5EC1A774287430B1CC2696FE304788C1E@dggeml513-mbx.china.huawei.com>
References: <8FC616E5EC1A774287430B1CC2696FE304788C1E@dggeml513-mbx.china.huawei.com>
Message-ID: <20210301134541.GA1216154@rincewind>

On 07:48 Thu 25 Feb     , hedongbo wrote:
> Ping?
> 
> From: hedongbo
> Sent: Friday, February 5, 2021 10:27 AM
> To: 'jdk8u-dev' <jdk8u-dev at openjdk.java.net>
> Subject: RFR: [8u] 6878250: (so) IllegalBlockingModeException thrown when reading from a closed SocketChannel's InputStream
> 
> 
> Hi,
> 
> 
> 
> Please help review this changes.
> 
> 
> 
> webrev: http://cr.openjdk.java.net/~dongbohe/6878250/webrev.01/
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-6878250
> 
> 
> 
> related bug: https://bugs.openjdk.java.net/browse/JDK-8260875
> 
> related thread: https://mail.openjdk.java.net/pipermail/nio-dev/2021-February/008123.html
> 
> 
> 
> 
> 
> 
> 
> Thanks,
> 
> dongbohe
> 

This looks ok to me. Please flag for approval.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 anleonar at redhat.com  Mon Mar  1 14:33:14 2021
From: anleonar at redhat.com (Andrew Leonard)
Date: Mon, 1 Mar 2021 14:33:14 +0000
Subject: jdk8u-dev MacOS 10.15+ build environment?
Message-ID: <CAFFhbGPPjte_0V5kGxW2bbyodwP6HyR+8acTvv9whR91-sgGdw@mail.gmail.com>

Hi,
I have a Mac OS contribution i've developed and tested at AdoptOpenJDK, I
would like to contribute it upstream to jdk8u-dev, unfortunately the
jdk8u-dev supported build platform is MacOS 10.7. Is there a method people
use to build & test their contributions if you don't have a MacOS 10.7
environment? The AdoptOpenJDK jdk8u base has patches to allow building
jdk8u with Xcode 11.5 on 10.15+..
How do others approach Mac contributions?
Thanks
Andrew

From dcherepanov at azul.com  Mon Mar  1 14:59:33 2021
From: dcherepanov at azul.com (Dmitry Cherepanov)
Date: Mon, 1 Mar 2021 17:59:33 +0300
Subject: [8u] RFR: 8259048: (tz) Upgrade time-zone data to tzdata2020f
In-Reply-To: <20210224060238.GA1121302@rincewind>
References: <20210224060238.GA1121302@rincewind>
Message-ID: <fe5b3711-3728-27d1-d14b-20c5222fc741@azul.com>

Looks good to me.

Thanks,

Dmitry

On 24.02.2021 09:02, Andrew Hughes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8259048
> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8259048/webrev.01/
>
> Usual update for the in-tree tzdata update.
>
> Although I did the update manually from the rearguard version of the
> tzdata2020f data, there is no difference between the patch for the
> files in make in 11u and those in this 8u patch. The only difference
> between the patches as a whole is 8u has the changes duplicated in
> the test subdirectory.
>
> Tests for sun.util.calendar and java.time.test all passed on the
> patched build.
>
> Thanks,



From shade at redhat.com  Mon Mar  1 18:06:27 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 1 Mar 2021 19:06:27 +0100
Subject: [8u] RFR (XS) 8257999: Parallel GC crash in
 gc/parallel/TestDynShrinkHeap.java: new region is not in covered_region
Message-ID: <b3a70a24-686e-c64b-246e-84a746e5ec73@redhat.com>

This is first of three patches that dance around the same issue.

Original change:
   https://bugs.openjdk.java.net/browse/JDK-8257999
   https://github.com/openjdk/jdk16/commit/61390d8e

Patch does not apply cleanly to 8u, because #include list is a bit different in 8u.

8u variant:

diff -r a435c913c8ce src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp
--- a/src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp      Thu Jun 25 08:15:07 2015 +0200
+++ b/src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp      Mon Mar 01 19:00:24 2021 +0100
@@ -30,10 +30,11 @@
  #include "gc_implementation/shared/spaceDecorator.hpp"
  #include "memory/cardTableModRefBS.hpp"
  #include "memory/gcLocker.inline.hpp"
  #include "oops/oop.inline.hpp"
  #include "runtime/java.hpp"
+#include "runtime/orderAccess.hpp"

  PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC

  inline const char* PSOldGen::select_name() {
    return UseParallelOldGC ? "ParOldGen" : "PSOldGen";
@@ -399,11 +400,13 @@
    size_t new_word_size = new_memregion.word_size();

    start_array()->set_covered_region(new_memregion);
    Universe::heap()->barrier_set()->resize_covered_region(new_memregion);

-  // ALWAYS do this last!!
+  // Ensure the space bounds are updated and made visible to other
+  // threads after the other data structures have been resized.
+  OrderAccess::storestore();
    object_space()->initialize(new_memregion,
                               SpaceDecorator::DontClear,
                               SpaceDecorator::DontMangle);

    assert(new_word_size == heap_word_size(object_space()->capacity_in_bytes()),

Testing: tier1

-- 
Thanks,
-Aleksey


From shade at redhat.com  Mon Mar  1 18:09:26 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 1 Mar 2021 19:09:26 +0100
Subject: [8u] RFR (XS) 8259271: gc/parallel/TestDynShrinkHeap.java still fails
 "assert(covered_region.contains(new_memregion)) failed: new region is
 not in covered_region"
Message-ID: <859fad81-4731-ee9a-ee2f-6043bebd3ac8@redhat.com>

This is second of three patches that dance around the same issue.

Original change:
   https://bugs.openjdk.java.net/browse/JDK-8259271
   https://github.com/openjdk/jdk16/commit/685c03dc

This applies on top of JDK-8257999.

Unfortunately, 8u code does not have OrderAccess cleanups, so we have to use the older forms of 
load_acquire. 8u variant is:

diff -r a9fd914bc78f src/share/vm/gc_implementation/shared/mutableSpace.cpp
--- a/src/share/vm/gc_implementation/shared/mutableSpace.cpp    Thu Dec 17 14:18:00 2020 +0000
+++ b/src/share/vm/gc_implementation/shared/mutableSpace.cpp    Mon Mar 01 19:07:25 2021 +0100
@@ -26,10 +26,11 @@
  #include "utilities/macros.hpp"
  #if INCLUDE_ALL_GCS
  #include "gc_implementation/shared/mutableSpace.hpp"
  #include "gc_implementation/shared/spaceDecorator.hpp"
  #include "oops/oop.inline.hpp"
+#include "runtime/orderAccess.hpp"
  #include "runtime/safepoint.hpp"
  #include "runtime/thread.hpp"
  #endif // INCLUDE_ALL_GCS

  PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC
@@ -190,11 +191,15 @@
  }

  // This version is lock-free.
  HeapWord* MutableSpace::cas_allocate(size_t size) {
    do {
-    HeapWord* obj = top();
+    // Read top before end, else the range check may pass when it shouldn't.
+    // If end is read first, other threads may advance end and top such that
+    // current top > old end and current top + size > current end.  Then
+    // pointer_delta underflows, allowing installation of top > current end.
+    HeapWord* obj = (HeapWord*)OrderAccess::load_ptr_acquire(top_addr());
      if (pointer_delta(end(), obj) >= size) {
        HeapWord* new_top = obj + size;
        HeapWord* result = (HeapWord*)Atomic::cmpxchg_ptr(new_top, top_addr(), obj);
        // result can be one of two:
        //  the old top value: the exchange succeeded

Testing: tier1

-- 
Thanks,
-Aleksey


From shade at redhat.com  Mon Mar  1 18:14:46 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 1 Mar 2021 19:14:46 +0100
Subject: [8u] RFR (S) 8260704: ParallelGC: oldgen expansion needs
 release-store for _end
Message-ID: <e58eb635-47f6-e98c-781f-3c0a37b992c4@redhat.com>

This is third of three patches that dance around the same issue.

Original change:
   https://bugs.openjdk.java.net/browse/JDK-8260704
   https://github.com/openjdk/jdk16/commit/afd5eefd

Applies on top of JDK-8257999 (effectively reverting everything but the extended comment) and 
JDK-8259271 (which brings orderAccess.hpp include to mutableSpace.cpp).

Unfortunately, 8u code does not have OrderAccess cleanups, so we have to use the older forms of
release_store. 8u variant is:

iff -r 9b1a140fca5a src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp
--- a/src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp      Fri Jan 22 11:20:52 2021 +0000
+++ b/src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp      Mon Mar 01 19:10:34 2021 +0100
@@ -1,4 +1,4 @@
  /*
- * Copyright (c) 2001, 2014, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2001, 2021, Oracle and/or its affiliates. All rights reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
@@ -33,5 +33,4 @@
  #include "oops/oop.inline.hpp"
  #include "runtime/java.hpp"
-#include "runtime/orderAccess.hpp"

  PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC
@@ -403,7 +402,7 @@
    Universe::heap()->barrier_set()->resize_covered_region(new_memregion);

-  // Ensure the space bounds are updated and made visible to other
-  // threads after the other data structures have been resized.
-  OrderAccess::storestore();
+  // The update of the space's end is done by this call.  As that
+  // makes the new space available for concurrent allocation, this
+  // must be the last step when expanding.
    object_space()->initialize(new_memregion,
                               SpaceDecorator::DontClear,
diff -r 9b1a140fca5a src/share/vm/gc_implementation/shared/mutableSpace.cpp
--- a/src/share/vm/gc_implementation/shared/mutableSpace.cpp    Fri Jan 22 11:20:52 2021 +0000
+++ b/src/share/vm/gc_implementation/shared/mutableSpace.cpp    Mon Mar 01 19:10:34 2021 +0100
@@ -1,4 +1,4 @@
  /*
- * Copyright (c) 2001, 2014, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2001, 2021, Oracle and/or its affiliates. All rights reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
@@ -126,5 +126,9 @@

    set_bottom(mr.start());
-  set_end(mr.end());
+  // When expanding concurrently with callers of cas_allocate, setting end
+  // makes the new space available for allocation by other threads.  So this
+  // assignment must follow all other configuration and initialization that
+  // might be done for expansion.
+  OrderAccess::release_store_ptr(end_addr(), mr.end());

    if (clear_space) {

Testing: tier1

-- 
Thanks,
-Aleksey


From shade at redhat.com  Mon Mar  1 18:19:14 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 1 Mar 2021 19:19:14 +0100
Subject: [8u] RFR (XS) 8130308: Too low memory usage in
 TestPromotionFromSurvivorToTenuredAfterMinorGC.java
Message-ID: <3e2a4fc9-6566-07e8-cc74-bd9456ef8bdd@redhat.com>

Original change:
   https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/1facc49c0499
   https://bugs.openjdk.java.net/browse/JDK-8130308

In some of our 8u testing, we see the similar test failure. Making the test more reliable helps. 
The patch does not apply cleanly, because there is no @ignore line in 8u (which is why the test runs 
at all).

8u variant is the actual fix hunk:

diff -r af8aba9ce33a test/gc/survivorAlignment/TestPromotionFromSurvivorToTenuredAfterMinorGC.java
--- a/test/gc/survivorAlignment/TestPromotionFromSurvivorToTenuredAfterMinorGC.java     Tue Feb 02 
19:20:19 2021 +0000
+++ b/test/gc/survivorAlignment/TestPromotionFromSurvivorToTenuredAfterMinorGC.java     Mon Mar 01 
19:19:00 2021 +0100
@@ -94,13 +94,20 @@
          expectedMemoryUsage += SurvivorAlignmentTestMain.getAlignmentHelper(
                  SurvivorAlignmentTestMain.HeapSpace.TENURED)
                  .getActualMemoryUsage();

          test.allocate();
-        for (int i = 0; i <= SurvivorAlignmentTestMain.MAX_TENURING_THRESHOLD;
-             i++) {
+        for (int i = 0; i <= SurvivorAlignmentTestMain.MAX_TENURING_THRESHOLD; i++) {
              SurvivorAlignmentTestMain.WHITE_BOX.youngGC();
          }

+        // Sometimes we see that data unrelated to the test has been allocated during
+        // the loop. This data is included in the expectedMemoryUsage since we look
+        // through all threads to see what they allocated. If this data is still in
+        // the survivor area however, it should not be included in expectedMemoryUsage
+        // since the verification below only look at what's in tenured space.
+        expectedMemoryUsage -= SurvivorAlignmentTestMain.getAlignmentHelper(
+                                   SurvivorAlignmentTestMain.HeapSpace.SURVIVOR)
+                                   .getActualMemoryUsage();
          test.verifyMemoryUsage(expectedMemoryUsage);
      }
  }

Testing: affected test

-- 
Thanks,
-Aleksey


From hohensee at amazon.com  Mon Mar  1 18:28:03 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 1 Mar 2021 18:28:03 +0000
Subject: [8u] RFR (XS) 8257999: Parallel GC crash in
 gc/parallel/TestDynShrinkHeap.java: new region is not in covered_region
Message-ID: <D6DD9912-610B-4366-8DF7-D7C3425F1012@amazon.com>

Lgtm. I've created an openjdk8u backport issue https://bugs.openjdk.java.net/browse/JDK-8262792 (new'ish process), which you can tag.

Thanks,
Paul

?-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Aleksey Shipilev <shade at redhat.com>
Date: Monday, March 1, 2021 at 10:07 AM
To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: [8u] RFR (XS) 8257999: Parallel GC crash in gc/parallel/TestDynShrinkHeap.java: new region is not in covered_region

This is first of three patches that dance around the same issue.

Original change:
   https://bugs.openjdk.java.net/browse/JDK-8257999
   https://github.com/openjdk/jdk16/commit/61390d8e

Patch does not apply cleanly to 8u, because #include list is a bit different in 8u.

8u variant:

diff -r a435c913c8ce src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp
--- a/src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp      Thu Jun 25 08:15:07 2015 +0200
+++ b/src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp      Mon Mar 01 19:00:24 2021 +0100
@@ -30,10 +30,11 @@
  #include "gc_implementation/shared/spaceDecorator.hpp"
  #include "memory/cardTableModRefBS.hpp"
  #include "memory/gcLocker.inline.hpp"
  #include "oops/oop.inline.hpp"
  #include "runtime/java.hpp"
+#include "runtime/orderAccess.hpp"

  PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC

  inline const char* PSOldGen::select_name() {
    return UseParallelOldGC ? "ParOldGen" : "PSOldGen";
@@ -399,11 +400,13 @@
    size_t new_word_size = new_memregion.word_size();

    start_array()->set_covered_region(new_memregion);
    Universe::heap()->barrier_set()->resize_covered_region(new_memregion);

-  // ALWAYS do this last!!
+  // Ensure the space bounds are updated and made visible to other
+  // threads after the other data structures have been resized.
+  OrderAccess::storestore();
    object_space()->initialize(new_memregion,
                               SpaceDecorator::DontClear,
                               SpaceDecorator::DontMangle);

    assert(new_word_size == heap_word_size(object_space()->capacity_in_bytes()),

Testing: tier1

--
Thanks,
-Aleksey



From shade at redhat.com  Mon Mar  1 18:32:26 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 1 Mar 2021 19:32:26 +0100
Subject: [8u] RFR (S) 8042891: Format issues embedded in macros for two g1
 source files
Message-ID: <390aa3c5-509b-1dfd-8d0b-7cbf6aa4ea59@redhat.com>

Original issue:
   https://bugs.openjdk.java.net/browse/JDK-8042891
   https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2e360934b0cf

In our testing, we have seen G1 crashes when it tries to log something, the stack traces leading 
into vnsprintf. I suspect the cause is formatting problems, which are supposed to be resolved by 
this backport.

There are lots of conflicts when applying the patch, all resolved by hand. Additionally, I built 
with x86_32 and x86_64 with GCC 9, and fixed up a few more formatting warnings. The changes are 
mostly putting p2i() where PTR_FORMAT is expected, matching %u or UINTX_FORMAT where needed, etc.

8u variant:
   https://cr.openjdk.java.net/~shade/8042891/webrev.8u.01/

Testing: tier1

-- 
Thanks,
-Aleksey


From hohensee at amazon.com  Mon Mar  1 18:30:31 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 1 Mar 2021 18:30:31 +0000
Subject: [8u] RFR (XS) 8259271: gc/parallel/TestDynShrinkHeap.java still
 fails "assert(covered_region.contains(new_memregion)) failed: new region is
 not in covered_region"
Message-ID: <9E6CD0EA-19F4-44BE-A759-0F73B9C2857D@amazon.com>

Lgtm. I've created an openjdk8u backport issue https://bugs.openjdk.java.net/browse/JDK-8262790 (new'ish process), which you can tag.

Thanks,
Paul

?-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Aleksey Shipilev <shade at redhat.com>
Date: Monday, March 1, 2021 at 10:10 AM
To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: [8u] RFR (XS) 8259271: gc/parallel/TestDynShrinkHeap.java still fails "assert(covered_region.contains(new_memregion)) failed: new region is not in covered_region"

This is second of three patches that dance around the same issue.

Original change:
   https://bugs.openjdk.java.net/browse/JDK-8259271
   https://github.com/openjdk/jdk16/commit/685c03dc

This applies on top of JDK-8257999.

Unfortunately, 8u code does not have OrderAccess cleanups, so we have to use the older forms of
load_acquire. 8u variant is:

diff -r a9fd914bc78f src/share/vm/gc_implementation/shared/mutableSpace.cpp
--- a/src/share/vm/gc_implementation/shared/mutableSpace.cpp    Thu Dec 17 14:18:00 2020 +0000
+++ b/src/share/vm/gc_implementation/shared/mutableSpace.cpp    Mon Mar 01 19:07:25 2021 +0100
@@ -26,10 +26,11 @@
  #include "utilities/macros.hpp"
  #if INCLUDE_ALL_GCS
  #include "gc_implementation/shared/mutableSpace.hpp"
  #include "gc_implementation/shared/spaceDecorator.hpp"
  #include "oops/oop.inline.hpp"
+#include "runtime/orderAccess.hpp"
  #include "runtime/safepoint.hpp"
  #include "runtime/thread.hpp"
  #endif // INCLUDE_ALL_GCS

  PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC
@@ -190,11 +191,15 @@
  }

  // This version is lock-free.
  HeapWord* MutableSpace::cas_allocate(size_t size) {
    do {
-    HeapWord* obj = top();
+    // Read top before end, else the range check may pass when it shouldn't.
+    // If end is read first, other threads may advance end and top such that
+    // current top > old end and current top + size > current end.  Then
+    // pointer_delta underflows, allowing installation of top > current end.
+    HeapWord* obj = (HeapWord*)OrderAccess::load_ptr_acquire(top_addr());
      if (pointer_delta(end(), obj) >= size) {
        HeapWord* new_top = obj + size;
        HeapWord* result = (HeapWord*)Atomic::cmpxchg_ptr(new_top, top_addr(), obj);
        // result can be one of two:
        //  the old top value: the exchange succeeded

Testing: tier1

--
Thanks,
-Aleksey



From hohensee at amazon.com  Mon Mar  1 18:38:04 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 1 Mar 2021 18:38:04 +0000
Subject: [8u] RFR (S) 8260704: ParallelGC: oldgen expansion needs
 release-store for _end
Message-ID: <12EC4C2A-6FD1-4C8C-BF35-6D2ECBC84E08@amazon.com>

Lgtm. I've created an openjdk8u backport issue https://bugs.openjdk.java.net/browse/JDK-8262794 (new'ish process), which you can tag.

Thanks,
Paul

?-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Aleksey Shipilev <shade at redhat.com>
Date: Monday, March 1, 2021 at 10:15 AM
To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: [8u] RFR (S) 8260704: ParallelGC: oldgen expansion needs release-store for _end

This is third of three patches that dance around the same issue.

Original change:
   https://bugs.openjdk.java.net/browse/JDK-8260704
   https://github.com/openjdk/jdk16/commit/afd5eefd

Applies on top of JDK-8257999 (effectively reverting everything but the extended comment) and
JDK-8259271 (which brings orderAccess.hpp include to mutableSpace.cpp).

Unfortunately, 8u code does not have OrderAccess cleanups, so we have to use the older forms of
release_store. 8u variant is:

iff -r 9b1a140fca5a src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp
--- a/src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp      Fri Jan 22 11:20:52 2021 +0000
+++ b/src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp      Mon Mar 01 19:10:34 2021 +0100
@@ -1,4 +1,4 @@
  /*
- * Copyright (c) 2001, 2014, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2001, 2021, Oracle and/or its affiliates. All rights reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
@@ -33,5 +33,4 @@
  #include "oops/oop.inline.hpp"
  #include "runtime/java.hpp"
-#include "runtime/orderAccess.hpp"

  PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC
@@ -403,7 +402,7 @@
    Universe::heap()->barrier_set()->resize_covered_region(new_memregion);

-  // Ensure the space bounds are updated and made visible to other
-  // threads after the other data structures have been resized.
-  OrderAccess::storestore();
+  // The update of the space's end is done by this call.  As that
+  // makes the new space available for concurrent allocation, this
+  // must be the last step when expanding.
    object_space()->initialize(new_memregion,
                               SpaceDecorator::DontClear,
diff -r 9b1a140fca5a src/share/vm/gc_implementation/shared/mutableSpace.cpp
--- a/src/share/vm/gc_implementation/shared/mutableSpace.cpp    Fri Jan 22 11:20:52 2021 +0000
+++ b/src/share/vm/gc_implementation/shared/mutableSpace.cpp    Mon Mar 01 19:10:34 2021 +0100
@@ -1,4 +1,4 @@
  /*
- * Copyright (c) 2001, 2014, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2001, 2021, Oracle and/or its affiliates. All rights reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
@@ -126,5 +126,9 @@

    set_bottom(mr.start());
-  set_end(mr.end());
+  // When expanding concurrently with callers of cas_allocate, setting end
+  // makes the new space available for allocation by other threads.  So this
+  // assignment must follow all other configuration and initialization that
+  // might be done for expansion.
+  OrderAccess::release_store_ptr(end_addr(), mr.end());

    if (clear_space) {

Testing: tier1

--
Thanks,
-Aleksey



From hohensee at amazon.com  Mon Mar  1 18:44:44 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 1 Mar 2021 18:44:44 +0000
Subject: [8u] RFR (XS) 8130308: Too low memory usage in
 TestPromotionFromSurvivorToTenuredAfterMinorGC.java
Message-ID: <35CD0D58-6A08-473F-B955-B8EC39B3903C@amazon.com>

Lgtm. I've created an openjdk8u backport issue https://bugs.openjdk.java.net/browse/JDK-8262795 (new'ish process), which you can tag.

Thanks,
Paul

?-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Aleksey Shipilev <shade at redhat.com>
Date: Monday, March 1, 2021 at 10:21 AM
To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: [8u] RFR (XS) 8130308: Too low memory usage in TestPromotionFromSurvivorToTenuredAfterMinorGC.java

Original change:
   https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/1facc49c0499
   https://bugs.openjdk.java.net/browse/JDK-8130308

In some of our 8u testing, we see the similar test failure. Making the test more reliable helps.
The patch does not apply cleanly, because there is no @ignore line in 8u (which is why the test runs
at all).

8u variant is the actual fix hunk:

diff -r af8aba9ce33a test/gc/survivorAlignment/TestPromotionFromSurvivorToTenuredAfterMinorGC.java
--- a/test/gc/survivorAlignment/TestPromotionFromSurvivorToTenuredAfterMinorGC.java     Tue Feb 02
19:20:19 2021 +0000
+++ b/test/gc/survivorAlignment/TestPromotionFromSurvivorToTenuredAfterMinorGC.java     Mon Mar 01
19:19:00 2021 +0100
@@ -94,13 +94,20 @@
          expectedMemoryUsage += SurvivorAlignmentTestMain.getAlignmentHelper(
                  SurvivorAlignmentTestMain.HeapSpace.TENURED)
                  .getActualMemoryUsage();

          test.allocate();
-        for (int i = 0; i <= SurvivorAlignmentTestMain.MAX_TENURING_THRESHOLD;
-             i++) {
+        for (int i = 0; i <= SurvivorAlignmentTestMain.MAX_TENURING_THRESHOLD; i++) {
              SurvivorAlignmentTestMain.WHITE_BOX.youngGC();
          }

+        // Sometimes we see that data unrelated to the test has been allocated during
+        // the loop. This data is included in the expectedMemoryUsage since we look
+        // through all threads to see what they allocated. If this data is still in
+        // the survivor area however, it should not be included in expectedMemoryUsage
+        // since the verification below only look at what's in tenured space.
+        expectedMemoryUsage -= SurvivorAlignmentTestMain.getAlignmentHelper(
+                                   SurvivorAlignmentTestMain.HeapSpace.SURVIVOR)
+                                   .getActualMemoryUsage();
          test.verifyMemoryUsage(expectedMemoryUsage);
      }
  }

Testing: affected test

--
Thanks,
-Aleksey



From gnu.andrew at redhat.com  Mon Mar  1 20:11:32 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 1 Mar 2021 20:11:32 +0000
Subject: [8u] RFR: 8259048: (tz) Upgrade time-zone data to tzdata2020f
In-Reply-To: <fe5b3711-3728-27d1-d14b-20c5222fc741@azul.com>
References: <20210224060238.GA1121302@rincewind>
 <fe5b3711-3728-27d1-d14b-20c5222fc741@azul.com>
Message-ID: <20210301201132.GA1276234@rincewind>

On 17:59 Mon 01 Mar     , Dmitry Cherepanov wrote:
> Looks good to me.
> 
> Thanks,
> 
> Dmitry
> 
> On 24.02.2021 09:02, Andrew Hughes wrote:
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8259048
> > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8259048/webrev.01/
> > 
> > Usual update for the in-tree tzdata update.
> > 
> > Although I did the update manually from the rearguard version of the
> > tzdata2020f data, there is no difference between the patch for the
> > files in make in 11u and those in this 8u patch. The only difference
> > between the patches as a whole is 8u has the changes duplicated in
> > the test subdirectory.
> > 
> > Tests for sun.util.calendar and java.time.test all passed on the
> > patched build.
> > 
> > Thanks,
> 
> 

Thanks Dmitry. Flagged for approval.
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 gnu.andrew at redhat.com  Mon Mar  1 20:21:46 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 1 Mar 2021 20:21:46 +0000
Subject: [IMPORTANT] 8u & 8u-dev now CLOSED FOR PUSHES for rampdown of 8u292
Message-ID: <20210301202146.GB1276234@rincewind>

Hi all,

We are now ramping down for the release of OpenJDK 8u292 in April.

I have tagged 8u-dev locally and will promote b05 once build testing
is complete.

jdk8u/jdk8u will be closed until this promotion is completed. After
that, requests for regression fixes for 8u292 can be made using the
jdk8u-critical-request label.

jdk8u/jdk8u-dev will be closed until hgupdater is switched over to
use openjdk8u302.

Please await further e-mail before pushing changes.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 hedongbo at huawei.com  Tue Mar  2 02:01:34 2021
From: hedongbo at huawei.com (hedongbo)
Date: Tue, 2 Mar 2021 02:01:34 +0000
Subject: FW:  RFR: [8u] 6878250: (so) IllegalBlockingModeException
 thrown when reading from a closed SocketChannel's InputStream
In-Reply-To: <20210301134541.GA1216154@rincewind>
References: <8FC616E5EC1A774287430B1CC2696FE304788C1E@dggeml513-mbx.china.huawei.com>
 <20210301134541.GA1216154@rincewind>
Message-ID: <8FC616E5EC1A774287430B1CC2696FE3047A513C@dggeml533-mbs.china.huawei.com>

Thanks, Andrew. Tagged.


Thanks,
Dongbohe

-----Original Message-----
From: Andrew Hughes [mailto:gnu.andrew at redhat.com] 
Sent: Monday, March 1, 2021 9:46 PM
To: hedongbo <hedongbo at huawei.com>
Cc: jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject: Re: FW: RFR: [8u] 6878250: (so) IllegalBlockingModeException thrown when reading from a closed SocketChannel's InputStream

On 07:48 Thu 25 Feb     , hedongbo wrote:
> Ping?
> 
> From: hedongbo
> Sent: Friday, February 5, 2021 10:27 AM
> To: 'jdk8u-dev' <jdk8u-dev at openjdk.java.net>
> Subject: RFR: [8u] 6878250: (so) IllegalBlockingModeException thrown 
> when reading from a closed SocketChannel's InputStream
> 
> 
> Hi,
> 
> 
> 
> Please help review this changes.
> 
> 
> 
> webrev: http://cr.openjdk.java.net/~dongbohe/6878250/webrev.01/
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-6878250
> 
> 
> 
> related bug: https://bugs.openjdk.java.net/browse/JDK-8260875
> 
> related thread: 
> https://mail.openjdk.java.net/pipermail/nio-dev/2021-February/008123.h
> tml
> 
> 
> 
> 
> 
> 
> 
> Thanks,
> 
> dongbohe
> 

This looks ok to me. Please flag for approval.

Thanks,
--
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 gnu.andrew at redhat.com  Tue Mar  2 13:18:15 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 2 Mar 2021 13:18:15 +0000
Subject: [IMPORTANT] 8u & 8u-dev now OPEN
Message-ID: <20210302131815.GA1341087@rincewind>

8u is now open for 8u292 regression fixes with the label jdk8u-critical-yes.

8u-dev is now open for 8u302 fixes with the label jdk8u-fix-yes.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 gnu.andrew at redhat.com  Tue Mar  2 13:23:34 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 2 Mar 2021 13:23:34 +0000
Subject: [8u] RFR (XS) 8257999: Parallel GC crash in
 gc/parallel/TestDynShrinkHeap.java: new region is not in covered_region
In-Reply-To: <b3a70a24-686e-c64b-246e-84a746e5ec73@redhat.com>
References: <b3a70a24-686e-c64b-246e-84a746e5ec73@redhat.com>
Message-ID: <20210302132334.GA1341251@rincewind>

On 19:06 Mon 01 Mar     , Aleksey Shipilev wrote:
> This is first of three patches that dance around the same issue.
> 
> Original change:
>   https://bugs.openjdk.java.net/browse/JDK-8257999
>   https://github.com/openjdk/jdk16/commit/61390d8e
> 
> Patch does not apply cleanly to 8u, because #include list is a bit different in 8u.
> 
> 8u variant:
> 
> diff -r a435c913c8ce src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp
> --- a/src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp      Thu Jun 25 08:15:07 2015 +0200
> +++ b/src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp      Mon Mar 01 19:00:24 2021 +0100
> @@ -30,10 +30,11 @@
>  #include "gc_implementation/shared/spaceDecorator.hpp"
>  #include "memory/cardTableModRefBS.hpp"
>  #include "memory/gcLocker.inline.hpp"
>  #include "oops/oop.inline.hpp"
>  #include "runtime/java.hpp"
> +#include "runtime/orderAccess.hpp"
> 
>  PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC
> 
>  inline const char* PSOldGen::select_name() {
>    return UseParallelOldGC ? "ParOldGen" : "PSOldGen";
> @@ -399,11 +400,13 @@
>    size_t new_word_size = new_memregion.word_size();
> 
>    start_array()->set_covered_region(new_memregion);
>    Universe::heap()->barrier_set()->resize_covered_region(new_memregion);
> 
> -  // ALWAYS do this last!!
> +  // Ensure the space bounds are updated and made visible to other
> +  // threads after the other data structures have been resized.
> +  OrderAccess::storestore();
>    object_space()->initialize(new_memregion,
>                               SpaceDecorator::DontClear,
>                               SpaceDecorator::DontMangle);
> 
>    assert(new_word_size == heap_word_size(object_space()->capacity_in_bytes()),
> 
> Testing: tier1
> 
> -- 
> Thanks,
> -Aleksey
> 

Please post patches as a link to a generated webrev.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 gnu.andrew at redhat.com  Tue Mar  2 13:31:22 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 2 Mar 2021 13:31:22 +0000
Subject: [8u] RFR (XS) 8257999: Parallel GC crash in
 gc/parallel/TestDynShrinkHeap.java: new region is not in covered_region
In-Reply-To: <D6DD9912-610B-4366-8DF7-D7C3425F1012@amazon.com>
References: <D6DD9912-610B-4366-8DF7-D7C3425F1012@amazon.com>
Message-ID: <20210302133122.GB1341251@rincewind>

On 18:28 Mon 01 Mar     , Hohensee, Paul wrote:
> Lgtm. I've created an openjdk8u backport issue https://bugs.openjdk.java.net/browse/JDK-8262792 (new'ish process), which you can tag.
> 
> Thanks,
> Paul
> 

When creating these bugs, please try and use the current fix
version ('openjdk8u302' at present). 'openjdk8u' is always
incorrect and will never resolve the bug when pushed.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 anleonar at redhat.com  Tue Mar  2 14:00:57 2021
From: anleonar at redhat.com (Andrew Leonard)
Date: Tue, 2 Mar 2021 14:00:57 +0000
Subject: [8u] RFR: 8262730: Enable jdk8u MacOS external debug symbols
Message-ID: <CAFFhbGO861wg9oY70xs_u5CWSm2qQE=_WXo5TFY6XmxUCDYJaQ@mail.gmail.com>

Hi,
Please can get reviews for a patch to enable jdk8u MacOS external debug
symbols, which we have already applied at AdoptOpenJDK, and would like to
contribute back upstream.
wbrev: https://cr.openjdk.java.net/~aleonard/8262730/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8262730

Thank you,
Andrew

From anleonar at redhat.com  Tue Mar  2 18:50:47 2021
From: anleonar at redhat.com (Andrew Leonard)
Date: Tue, 2 Mar 2021 18:50:47 +0000
Subject: [8u] RFR: 8262864: No debug symbols in image for Windows
 --with-native-debug-symbols=external
Message-ID: <CAFFhbGM84D=mi2H1emTWiam-Yo29LjqjiHQASov4+AN3bd-tXg@mail.gmail.com>

Hi,
Please can I get reviews for this patch to fix the creation of jdk8u
Windows debug files (.map, .pdb) when using
--with-native-debug-symbols=external. A recent fix resolved this for
non-Windows (https://bugs.openjdk.java.net/browse/JDK-8252395), this fixes
Windows and also a minor issue with the other platforms that JDK-8252395
didn't quite fix.
webrev: https://cr.openjdk.java.net/~aleonard/8262864/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8262864
Thanks
Andrew

From hohensee at amazon.com  Tue Mar  2 19:03:47 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 2 Mar 2021 19:03:47 +0000
Subject: [8u] RFR (XS) 8257999: Parallel GC crash in
 gc/parallel/TestDynShrinkHeap.java: new region is not in covered_region
Message-ID: <4FF8F3D6-9F6A-4E71-AF57-07DEAC5F3281@amazon.com>

Sure. I'd thought that the fix version was to be set by the approver when tagging the issue jdk8u-fix-yes.

?-----Original Message-----
From: Andrew Hughes <gnu.andrew at redhat.com>
Date: Tuesday, March 2, 2021 at 5:32 AM
To: "Hohensee, Paul" <hohensee at amazon.com>
Cc: Aleksey Shipilev <shade at redhat.com>, "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: RE: [8u] RFR (XS) 8257999: Parallel GC crash in gc/parallel/TestDynShrinkHeap.java: new region is not in covered_region

On 18:28 Mon 01 Mar     , Hohensee, Paul wrote:
> Lgtm. I've created an openjdk8u backport issue https://bugs.openjdk.java.net/browse/JDK-8262792 (new'ish process), which you can tag.
> 
> Thanks,
> Paul
> 

When creating these bugs, please try and use the current fix
version ('openjdk8u302' at present). 'openjdk8u' is always
incorrect and will never resolve the bug when pushed.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 gnu.andrew at redhat.com  Tue Mar  2 20:17:40 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 2 Mar 2021 20:17:40 +0000
Subject: OpenJDK 8u292-b04 & 8u292-b05 EA Released
Message-ID: <20210302195611.GA1349824@rincewind>

I've made available early access source bundles for 8u292, based on
the tags jdk8u292-b04 and jdk8u292-b05:

https://openjdk-sources.osci.io/openjdk8/openjdk8u292-b04-ea.tar.xz
https://openjdk-sources.osci.io/openjdk8/openjdk8u292-b05-ea.tar.xz

The tarball is accompanied by a digital signature available at:

https://openjdk-sources.osci.io/openjdk8/openjdk8u292-b04-ea.tar.xz.sig
https://openjdk-sources.osci.io/openjdk8/openjdk8u292-b05-ea.tar.xz.sig

This is signed by our new Red Hat OpenJDK key (openjdk at redhat.com):

PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net)
Fingerprint: CA5F 11C6 CE22 644D 42C6  AC44 92EF 8D39 DC13 168F

SHA256 checksums:

276b565a85aafaa0e88c30fc6180b7afbf7880d2d0145ec1bceea3cc1a756bf9  openjdk8u292-b04-ea.tar.xz
022f4d3c08acad7ce87ea86668aa0798b4f7f7c4d5fcbdb1e4defacd2eaf7b4b  openjdk8u292-b04-ea.tar.xz.sig

d0298b9d7fb796f0750ff418fc2060a843e52864365bc600e7c38c30f8601048  openjdk8u292-b05-ea.tar.xz
47a5ebb18e77c2e64483d09cf399c52a1052c5c2def534335b860f6739d7dc0c  openjdk8u292-b05-ea.tar.xz.sig

They are listed at
https://openjdk-sources.osci.io/openjdk8/openjdk8u292-b04-ea.sha256
https://openjdk-sources.osci.io/openjdk8/openjdk8u292-b05-ea.sha256

Changes in 8u292-b04:
  - JDK-8061777: (zipfs) IllegalArgumentException in ZipCoder.toString when using Shitft_JIS
  - JDK-8158525: Update a few java/net tests to use the loopback address instead of the host address
  - JDK-8171410: aarch64: long multiplyExact shifts by 31 instead of 63
  - JDK-8225435: Upgrade IANA Language Subtag Registry to the latest for JDK14
  - JDK-8235263: Revert TLS 1.3 change that wrapped IOExceptions
  - JDK-8235311: Tag mismatch may alert bad_record_mac
  - JDK-8236500: Windows ucrt.dll should be looked up in versioned WINSDK subdirectory
  - JDK-8260349: Cannot programmatically retrieve Metaspace max set via JAVA_TOOL_OPTIONS
  - JDK-8261766: [8u] hotspot needs to recognise cl.exe 19.16 to build with VS2017
  - JDK-8262075: sun/security/krb5/auto/UseCacheAndStoreKey.java timed out intermittently

Changes in 8u292-b05:
  - JDK-6345095: regression test EmptyClipRenderingTest fails
  - JDK-6896810: TEST_BUG: java/lang/ref/SoftReference/Pin.java fails with OOME during System.out.println
  - JDK-7107012: sun.jvm.hostspot.code.CompressedReadStream readDouble() conversion to long mishandled
  - JDK-7112454: TEST_BUG: java/awt/Choice/PopdownGeneratesMouseEvents/PopdownGeneratesMouseEvents.html failed
  - JDK-7131835: [TEST_BUG] Test does not consider that the rounded edges of the window in Mac OS 10.7
  - JDK-7185221: [macosx] Regtest should not throw exception if a suitable display mode found
  - JDK-8041464: [TEST_BUG] CustomClassLoaderTransferTest does not support OS X
  - JDK-8078024: javac, several incorporation steps are silently failing when an error should be reported
  - JDK-8129626: G1: set_in_progress() and clear_started() needs a barrier on non-TSO platforms
  - JDK-8211301: [macos] support full window content options
  - JDK-8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1
  - JDK-8248336: AArch64: C2: offset overflow in BoxLockNode::emit
  - JDK-8257746: Regression introduced with JDK-8250984 - memory might be null in some machines
  - JDK-8261231: Windows IME was disabled after DnD operation
  - JDK-8262073: assert(allocates2(pc)) failed: not in CodeBuffer memory

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 yano-masanori at fujitsu.com  Wed Mar  3 07:23:32 2021
From: yano-masanori at fujitsu.com (yano-masanori at fujitsu.com)
Date: Wed, 3 Mar 2021 07:23:32 +0000
Subject: [PING] RE: [PING] RE: 8180478: tools/launcher/MultipleJRE.sh fails on
 Windows because of extra-''
Message-ID: <TYCPR01MB5823C6FE10C571459BFD62E8E7989@TYCPR01MB5823.jpnprd01.prod.outlook.com>

Hello,

Please reply if anyone can be a sponsor.

Regards,
Masanori Yano

> -----Original Message-----
> From: Yano, Masanori 
> Sent: Tuesday, January 12, 2021 4:30 PM
> To: 'jdk8u-dev at openjdk.java.net' <jdk8u-dev at openjdk.java.net>
> Subject: RE: [PING] RE: 8180478: tools/launcher/MultipleJRE.sh fails on Windows
> because of extra-''
> 
> Hello,
> 
> Please reply if anyone can be a sponsor.
> 
> Regards,
> Masanori Yano
> 
> > -----Original Message-----
> > From: Yano, Masanori
> > Sent: Wednesday, December 23, 2020 4:58 PM
> > To: 'jdk8u-dev at openjdk.java.net' <jdk8u-dev at openjdk.java.net>
> > Subject: [PING] RE: 8180478: tools/launcher/MultipleJRE.sh fails on
> > Windows because of extra-''
> >
> > Hello,
> >
> > Please reply if anyone can be a sponsor.
> >
> > Regards,
> > Masanori Yano
> >
> > > -----Original Message-----
> > > From: Yano, Masanori/?? ??
> > > Sent: Wednesday, November 11, 2020 4:06 PM
> > > To: 'jdk8u-dev at openjdk.java.net' <jdk8u-dev at openjdk.java.net>
> > > Subject: 8180478: tools/launcher/MultipleJRE.sh fails on Windows
> > > because of extra-''
> > >
> > > Hello.
> > >
> > > I would like to contribute for JDK-8180478.
> > >
> > > The test of tools/launcher/MultipleJRE.sh fails on the JDK8 for the
> > > Windows because the 'RELEASE' variable contains the carriage return.
> > >
> > > The 'RELEASE' variable is created from the third word in the first
> > > line of the "java -version" command.
> > > But this is a last word of the line, so the 'RELEASE' variable
> > > contains the carriage return.
> > > The 'RELEASE' variable is compared to the actual java version, but
> > > does not match because of the carriage return difference.
> > >
> > > Since JDK 11, this is no longer a problem because the date has been
> > > added as a fourth word.
> > > Therefore, the test for JDK8 should be fixed to remove the carriage returns.
> > >
> > > Please sponsor the following change.
> > >
> > > diff -r 4c5dceabd4c6 test/tools/launcher/MultipleJRE.sh
> > > --- a/test/tools/launcher/MultipleJRE.sh        Mon Apr 21 14:35:14 2014
> > +0400
> > > +++ b/test/tools/launcher/MultipleJRE.sh        Tue Nov 10 20:08:05 2020
> > > +0900
> > > @@ -308,7 +308,7 @@
> > >  # Main test sequence starts here
> > >  #
> > >  RELEASE=`$JAVA -version 2>&1 | head -n 1 | cut -d ' ' -f 3 | \
> > > -  sed -e "s/\"//g"`
> > > +  sed -e "s/\"//g" | sed -e "s/\r//g"`
> > >  BASE_RELEASE=`echo $RELEASE | sed -e "s/-.*//g"`
> > >
> > >  #
> > >
> > > Regards,
> > > Masanori Yano

From sgehwolf at redhat.com  Wed Mar  3 09:07:50 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 03 Mar 2021 10:07:50 +0100
Subject: [PING] RE: [PING] RE: 8180478: tools/launcher/MultipleJRE.sh
 fails on Windows because of extra-''
In-Reply-To: <TYCPR01MB5823C6FE10C571459BFD62E8E7989@TYCPR01MB5823.jpnprd01.prod.outlook.com>
References: <TYCPR01MB5823C6FE10C571459BFD62E8E7989@TYCPR01MB5823.jpnprd01.prod.outlook.com>
Message-ID: <0fb0ac5e331771303020d69131b6745f56ac02b5.camel@redhat.com>

Hi,

On Wed, 2021-03-03 at 07:23 +0000, yano-masanori at fujitsu.com wrote:
> Hello,
> 
> Please reply if anyone can be a sponsor.

I'll sponsor this for you. Patch looks fine.

Thanks,
Severin

> Regards,
> Masanori Yano
> 
> > -----Original Message-----
> > From: Yano, Masanori 
> > Sent: Tuesday, January 12, 2021 4:30 PM
> > To: 'jdk8u-dev at openjdk.java.net' <jdk8u-dev at openjdk.java.net>
> > Subject: RE: [PING] RE: 8180478: tools/launcher/MultipleJRE.sh
> > fails on Windows
> > because of extra-''
> > 
> > Hello,
> > 
> > Please reply if anyone can be a sponsor.
> > 
> > Regards,
> > Masanori Yano
> > 
> > > -----Original Message-----
> > > From: Yano, Masanori
> > > Sent: Wednesday, December 23, 2020 4:58 PM
> > > To: 'jdk8u-dev at openjdk.java.net' <jdk8u-dev at openjdk.java.net>
> > > Subject: [PING] RE: 8180478: tools/launcher/MultipleJRE.sh fails
> > > on
> > > Windows because of extra-''
> > > 
> > > Hello,
> > > 
> > > Please reply if anyone can be a sponsor.
> > > 
> > > Regards,
> > > Masanori Yano
> > > 
> > > > -----Original Message-----
> > > > From: Yano, Masanori/?? ??
> > > > Sent: Wednesday, November 11, 2020 4:06 PM
> > > > To: 'jdk8u-dev at openjdk.java.net' <jdk8u-dev at openjdk.java.net>
> > > > Subject: 8180478: tools/launcher/MultipleJRE.sh fails on
> > > > Windows
> > > > because of extra-''
> > > > 
> > > > Hello.
> > > > 
> > > > I would like to contribute for JDK-8180478.
> > > > 
> > > > The test of tools/launcher/MultipleJRE.sh fails on the JDK8 for
> > > > the
> > > > Windows because the 'RELEASE' variable contains the carriage
> > > > return.
> > > > 
> > > > The 'RELEASE' variable is created from the third word in the
> > > > first
> > > > line of the "java -version" command.
> > > > But this is a last word of the line, so the 'RELEASE' variable
> > > > contains the carriage return.
> > > > The 'RELEASE' variable is compared to the actual java version,
> > > > but
> > > > does not match because of the carriage return difference.
> > > > 
> > > > Since JDK 11, this is no longer a problem because the date has
> > > > been
> > > > added as a fourth word.
> > > > Therefore, the test for JDK8 should be fixed to remove the
> > > > carriage returns.
> > > > 
> > > > Please sponsor the following change.
> > > > 
> > > > diff -r 4c5dceabd4c6 test/tools/launcher/MultipleJRE.sh
> > > > --- a/test/tools/launcher/MultipleJRE.sh??????? Mon Apr 21
> > > > 14:35:14 2014
> > > +0400
> > > > +++ b/test/tools/launcher/MultipleJRE.sh??????? Tue Nov 10
> > > > 20:08:05 2020
> > > > +0900
> > > > @@ -308,7 +308,7 @@
> > > > ?# Main test sequence starts here
> > > > ?#
> > > > ?RELEASE=`$JAVA -version 2>&1 | head -n 1 | cut -d ' ' -f 3 | \
> > > > -? sed -e "s/\"//g"`
> > > > +? sed -e "s/\"//g" | sed -e "s/\r//g"`
> > > > ?BASE_RELEASE=`echo $RELEASE | sed -e "s/-.*//g"`
> > > > 
> > > > ?#
> > > > 
> > > > Regards,
> > > > Masanori Yano
> 



From sgehwolf at redhat.com  Wed Mar  3 10:39:18 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 03 Mar 2021 11:39:18 +0100
Subject: [8u] RFR: 8255086: Update the root locale display names
Message-ID: <4c025f2593a87123f5eea2b7e9b5940bb23f1275.camel@redhat.com>

Hi,

Please review this 8u backport of 8255086. The JDK 11u patch doesn't
apply cleanly after path unshuffeling due to:

- bug line differences in tests
- copyright date differences
- different context in test/java/util/Locale/LocaleTest.java
  where relevant lines are in different places

In terms of functionality, the patch should be equivalent.

Bug: https://bugs.openjdk.java.net/browse/JDK-8255086
webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8255086/jdk8/01/webrev/

Testing: Changed regression tests and tier1

Thoughts?

Thanks,
Severin


From hohensee at amazon.com  Wed Mar  3 22:22:25 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 3 Mar 2021 22:22:25 +0000
Subject: [8u] RFR (S) 8042891: Format issues embedded in macros for two g1
 source files
Message-ID: <019FCC33-C991-4FF5-9988-865F3948537C@amazon.com>

Lgtm.

Thanks,
Paul

?-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Aleksey Shipilev <shade at redhat.com>
Date: Monday, March 1, 2021 at 10:33 AM
To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: [8u] RFR (S) 8042891: Format issues embedded in macros for two g1 source files

Original issue:
   https://bugs.openjdk.java.net/browse/JDK-8042891
   https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2e360934b0cf

In our testing, we have seen G1 crashes when it tries to log something, the stack traces leading
into vnsprintf. I suspect the cause is formatting problems, which are supposed to be resolved by
this backport.

There are lots of conflicts when applying the patch, all resolved by hand. Additionally, I built
with x86_32 and x86_64 with GCC 9, and fixed up a few more formatting warnings. The changes are
mostly putting p2i() where PTR_FORMAT is expected, matching %u or UINTX_FORMAT where needed, etc.

8u variant:
   https://cr.openjdk.java.net/~shade/8042891/webrev.8u.01/

Testing: tier1

--
Thanks,
-Aleksey



From hohensee at amazon.com  Wed Mar  3 22:38:16 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 3 Mar 2021 22:38:16 +0000
Subject: [8u] RFR: 8255086: Update the root locale display names
Message-ID: <63DB162A-5542-4B9A-A318-0D8FBB3063F7@amazon.com>

Lgtm.

Thanks,
Paul 

?-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Severin Gehwolf <sgehwolf at redhat.com>
Date: Wednesday, March 3, 2021 at 2:40 AM
To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject: [8u] RFR: 8255086: Update the root locale display names

Hi,

Please review this 8u backport of 8255086. The JDK 11u patch doesn't
apply cleanly after path unshuffeling due to:

- bug line differences in tests
- copyright date differences
- different context in test/java/util/Locale/LocaleTest.java
  where relevant lines are in different places

In terms of functionality, the patch should be equivalent.

Bug: https://bugs.openjdk.java.net/browse/JDK-8255086
webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8255086/jdk8/01/webrev/

Testing: Changed regression tests and tier1

Thoughts?

Thanks,
Severin



From hohensee at amazon.com  Wed Mar  3 23:15:19 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 3 Mar 2021 23:15:19 +0000
Subject: [8u] RFR: 8262730: Enable jdk8u MacOS external debug symbols
Message-ID: <3BD8A7A4-A5F9-4CA2-BE87-6A3956194E9F@amazon.com>

Lgtm. Afaict, the implementation of this in 9u and later is quite different, so an 8u-specific issue is warranted.

Thanks,
Paul

?-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Andrew Leonard <anleonar at redhat.com>
Date: Tuesday, March 2, 2021 at 6:02 AM
To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: [8u] RFR: 8262730: Enable jdk8u MacOS external debug symbols

Hi,
Please can get reviews for a patch to enable jdk8u MacOS external debug
symbols, which we have already applied at AdoptOpenJDK, and would like to
contribute back upstream
wbrev: https://cr.openjdk.java.net/~aleonard/8262730/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8262730

Thank you,
Andrew


From anleonar at redhat.com  Thu Mar  4 09:06:49 2021
From: anleonar at redhat.com (Andrew Leonard)
Date: Thu, 4 Mar 2021 09:06:49 +0000
Subject: [8u] RFR: 8262730: Enable jdk8u MacOS external debug symbols
In-Reply-To: <3BD8A7A4-A5F9-4CA2-BE87-6A3956194E9F@amazon.com>
References: <3BD8A7A4-A5F9-4CA2-BE87-6A3956194E9F@amazon.com>
Message-ID: <CAFFhbGO49DqvtyBbpL8m+bjBPN1Okq8D6Xn=n3SzvKzWxGaRBw@mail.gmail.com>

Thank you Paul

On Wed, Mar 3, 2021 at 11:16 PM Hohensee, Paul <hohensee at amazon.com> wrote:

> Lgtm. Afaict, the implementation of this in 9u and later is quite
> different, so an 8u-specific issue is warranted.
>
> Thanks,
> Paul
>
> ?-----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Andrew
> Leonard <anleonar at redhat.com>
> Date: Tuesday, March 2, 2021 at 6:02 AM
> To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
> Subject: [8u] RFR: 8262730: Enable jdk8u MacOS external debug symbols
>
> Hi,
> Please can get reviews for a patch to enable jdk8u MacOS external debug
> symbols, which we have already applied at AdoptOpenJDK, and would like to
> contribute back upstream
> wbrev: https://cr.openjdk.java.net/~aleonard/8262730/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8262730
>
> Thank you,
> Andrew
>
>

From sgehwolf at redhat.com  Thu Mar  4 09:08:56 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 04 Mar 2021 10:08:56 +0100
Subject: [8u] RFR: 8255086: Update the root locale display names
In-Reply-To: <63DB162A-5542-4B9A-A318-0D8FBB3063F7@amazon.com>
References: <63DB162A-5542-4B9A-A318-0D8FBB3063F7@amazon.com>
Message-ID: <12f3643bc1b336466fbf2a2656fd9533a7aaf340.camel@redhat.com>

On Wed, 2021-03-03 at 22:38 +0000, Hohensee, Paul wrote:
> Lgtm.

Thanks for the review, Paul!

Cheers,
Severin


From hedongbo at huawei.com  Thu Mar  4 10:43:47 2021
From: hedongbo at huawei.com (hedongbo)
Date: Thu, 4 Mar 2021 10:43:47 +0000
Subject: RFR: [8u] 8263008: AARCH64: Add debug info for libsaproc.so
Message-ID: <8FC616E5EC1A774287430B1CC2696FE3047BB915@dggeml513-mbs.china.huawei.com>

Hi,

Please review this 8u trivial changes.

Bug: https://bugs.openjdk.java.net/browse/JDK-8263008
webrev: http://cr.openjdk.java.net/~dongbohe/8263008/webrev.00/

Testing:  Worked correctly after patch.

Thanks,
dongbohe


From sgehwolf at redhat.com  Thu Mar  4 10:49:19 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 04 Mar 2021 11:49:19 +0100
Subject: RFR: [8u] 8263008: AARCH64: Add debug info for libsaproc.so
In-Reply-To: <8FC616E5EC1A774287430B1CC2696FE3047BB915@dggeml513-mbs.china.huawei.com>
References: <8FC616E5EC1A774287430B1CC2696FE3047BB915@dggeml513-mbs.china.huawei.com>
Message-ID: <8880cb84ae0b3132a3087d0800621896ce141aa2.camel@redhat.com>

On Thu, 2021-03-04 at 10:43 +0000, hedongbo wrote:
> Hi,
> 
> Please review this 8u trivial changes.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8263008
> webrev: http://cr.openjdk.java.net/~dongbohe/8263008/webrev.00/
> 
> Testing:? Worked correctly after patch.

This looks fine.

Thanks,
Severin


From hedongbo at huawei.com  Thu Mar  4 11:02:41 2021
From: hedongbo at huawei.com (hedongbo)
Date: Thu, 4 Mar 2021 11:02:41 +0000
Subject: RFR: [8u] 8263008: AARCH64: Add debug info for libsaproc.so
In-Reply-To: <8880cb84ae0b3132a3087d0800621896ce141aa2.camel@redhat.com>
References: <8FC616E5EC1A774287430B1CC2696FE3047BB915@dggeml513-mbs.china.huawei.com>
 <8880cb84ae0b3132a3087d0800621896ce141aa2.camel@redhat.com>
Message-ID: <8FC616E5EC1A774287430B1CC2696FE3047BB9DD@dggeml513-mbs.china.huawei.com>

Thanks, Severin. Tagged.

Only modified the copyright year.
webrev: http://cr.openjdk.java.net/~dongbohe/8263008/webrev.01/


Thanks,
dongbohe

-----Original Message-----
From: Severin Gehwolf [mailto:sgehwolf at redhat.com] 
Sent: Thursday, March 4, 2021 6:49 PM
To: hedongbo <hedongbo at huawei.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject: Re: RFR: [8u] 8263008: AARCH64: Add debug info for libsaproc.so

On Thu, 2021-03-04 at 10:43 +0000, hedongbo wrote:
> Hi,
> 
> Please review this 8u trivial changes.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8263008
> webrev: http://cr.openjdk.java.net/~dongbohe/8263008/webrev.00/
> 
> Testing:? Worked correctly after patch.

This looks fine.

Thanks,
Severin


From kalinshi at tencent.com  Fri Mar  5 07:35:19 2021
From: kalinshi at tencent.com (=?gb2312?B?a2FsaW5zaGkoyqm72yk=?=)
Date: Fri, 5 Mar 2021 07:35:19 +0000
Subject: [8u]RFR: 8263061: copy wrong unpack200.diz to bin directory on linux
 after 8252395
Message-ID: <cff06e34930f41fa9a95601d5312fed0@tencent.com>

Hi,

Please help review this fix.
After 8252395, unpack200 executable is wrongly copied to bin directory as unpack200.diz when configure with debuginfo.

Makefile sets same prerequisite for unpack200 executable and debuginfo file. install-file function always copies first prerequisite, which is executable.
Fix is use debuginfo file as first prerequisite and copy it.

webrev: http://cr.openjdk.java.net/~hshi/8263061/webrev1/
bug: https://bugs.openjdk.java.net/browse/JDK-8263061

Regards
Hui

From sgehwolf at redhat.com  Fri Mar  5 10:36:58 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 05 Mar 2021 11:36:58 +0100
Subject: [8u]RFR: 8263061: copy wrong unpack200.diz to bin directory on
 linux after 8252395
In-Reply-To: <cff06e34930f41fa9a95601d5312fed0@tencent.com>
References: <cff06e34930f41fa9a95601d5312fed0@tencent.com>
Message-ID: <b1116fa7312e1242a6542f9b1a69a709f4927a21.camel@redhat.com>

On Fri, 2021-03-05 at 07:35 +0000, kalinshi(??) wrote:
> Hi,
> 
> Please help review this fix.
> After 8252395, unpack200 executable is wrongly copied to bin directory
> as unpack200.diz when configure with debuginfo.
> 
> Makefile sets same prerequisite for unpack200 executable and debuginfo
> file. install-file function always copies first prerequisite, which is
> executable.
> Fix is use debuginfo file as first prerequisite and copy it.
> 
> webrev: http://cr.openjdk.java.net/~hshi/8263061/webrev1/
> bug: https://bugs.openjdk.java.net/browse/JDK-8263061

I've stared at this bug for a bit, but I'm not sure what you are trying
to solve.

$ find build/linux-x86_64-normal-server-release/images/j2sdk-image/ | grep unpack
build/linux-x86_64-normal-server-release/images/j2sdk-image/man/ja_JP.UTF-8/man1/unpack200.1
build/linux-x86_64-normal-server-release/images/j2sdk-image/man/man1/unpack200.1
build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/unpack200.debuginfo
build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/unpack200
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/bin/unpack200.debuginfo
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/bin/unpack200
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libunpack.so
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libunpack.debuginfo
$ build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/unpack200 -J-version -h
Usage:  unpack200 [-opt... | --option=value]... x.pack[.gz] y.jar

Unpacking Options
  -H{h}, --deflate-hint={h}     override transmitted deflate hint: true, false, or keep (default)
  -r, --remove-pack-file        remove input file after unpacking
  -v, --verbose                 increase program verbosity
  -q, --quiet                   set verbosity to lowest level
  -l{F}, --log-file={F}         output to the given log file, or '-' for standard output (default)
  -?, -h, --help                print this message
  -V, --version                 print program version
  -J{X}                         Java VM argument (ignored)
$ build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/unpack200 --version
unpack200 version 1.30, 07/05/05
$ build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/bin/unpack200 --version
unpack200 version 1.30, 07/05/05

Are you trying to fix tools/launcher/VersionCheck.java test or
something else? I've reproduced that test failure with external
debuginfo since the test tries to execute *every* file in
$JAVA_HOME/bin (including *.debuginfo files). If you are trying to fix
that problem, I'd suggest to filter debuginfo files out like was done
as part of JDK-8237192 for JDK 11. We'd also have to include *.diz
files from being excluded from the test. Those files are zipped version
s of the *.debuginfo files. It looks like JDK 11 all the way to JDK 17
would try to run *.diz files as well?

Thanks,
Severin


From kalinshi at tencent.com  Fri Mar  5 11:00:15 2021
From: kalinshi at tencent.com (=?utf-8?B?a2FsaW5zaGko5pa95oWnKQ==?=)
Date: Fri, 5 Mar 2021 11:00:15 +0000
Subject: =?utf-8?B?5Zue5aSNOiBbOHVdUkZSOiA4MjYzMDYxOiBjb3B5IHdyb25nIHVucGFjazIw?=
 =?utf-8?B?MC5kaXogdG8gYmluIGRpcmVjdG9yeSBvbiBsaW51eCBhZnRlciA4MjUyMzk1?=
 =?utf-8?Q?(Internet_mail)?=
In-Reply-To: <b1116fa7312e1242a6542f9b1a69a709f4927a21.camel@redhat.com>
References: <cff06e34930f41fa9a95601d5312fed0@tencent.com>
 <b1116fa7312e1242a6542f9b1a69a709f4927a21.camel@redhat.com>
Message-ID: <5541b2eea80b441ab6d8a417f09184a1@tencent.com>

Thanks Severin!

< Are you trying to fix tools/launcher/VersionCheck.java test or something else? I've reproduced that test failure with external debuginfo since the test tries to execute *every* file in $JAVA_HOME/bin (including *.debuginfo files). If you are trying to fix that problem, I'd suggest to filter debuginfo files out like was done as part of JDK-8237192 for JDK 11. We'd also have to include *.diz files from being excluded from the test. Those files are zipped version s of the *.debuginfo files. It looks like JDK 11 all the way to JDK 17 would try to run *.diz files as well?

tools/launcher/VersionCheck.java tries to execute *every*      EXECUTABLE       file in $JAVA_HOME/bin.
It fails due to unpack200.diz is executable before fix, because install command is "cp build/linux-x86_64-normal-server-release/jdk/objs/unpackexe/unpack200 build/linux-x86_64-normal-server-release/jdk/bin/unpack200.diz".
It copies wrong source file, make unpack200.diz is a side effect.

This fix is making it copy correct debug info file.
"cp build/linux-x86_64-normal-server-release/jdk/objs/unpackexe/unpack200.diz build/linux-x86_64-normal-server-release/jdk/bin/unpack200.diz".

Regards
Hui
-----????-----
???: Severin Gehwolf <sgehwolf at redhat.com> 
????: 2021?3?5? 18:37
???: kalinshi(??) <kalinshi at tencent.com>; jdk8u-dev at openjdk.java.net
??: Re: [8u]RFR: 8263061: copy wrong unpack200.diz to bin directory on linux after 8252395(Internet mail)

On Fri, 2021-03-05 at 07:35 +0000, kalinshi(??) wrote:
> Hi,
> 
> Please help review this fix.
> After 8252395, unpack200 executable is wrongly copied to bin directory 
> as unpack200.diz when configure with debuginfo.
> 
> Makefile sets same prerequisite for unpack200 executable and debuginfo 
> file. install-file function always copies first prerequisite, which is 
> executable.
> Fix is use debuginfo file as first prerequisite and copy it.
> 
> webrev: http://cr.openjdk.java.net/~hshi/8263061/webrev1/
> bug: https://bugs.openjdk.java.net/browse/JDK-8263061

I've stared at this bug for a bit, but I'm not sure what you are trying to solve.

$ find build/linux-x86_64-normal-server-release/images/j2sdk-image/ | grep unpack
build/linux-x86_64-normal-server-release/images/j2sdk-image/man/ja_JP.UTF-8/man1/unpack200.1
build/linux-x86_64-normal-server-release/images/j2sdk-image/man/man1/unpack200.1
build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/unpack200.debuginfo
build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/unpack200
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/bin/unpack200.debuginfo
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/bin/unpack200
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libunpack.so
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libunpack.debuginfo
$ build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/unpack200 -J-version -h
Usage:  unpack200 [-opt... | --option=value]... x.pack[.gz] y.jar

Unpacking Options
  -H{h}, --deflate-hint={h}     override transmitted deflate hint: true, false, or keep (default)
  -r, --remove-pack-file        remove input file after unpacking
  -v, --verbose                 increase program verbosity
  -q, --quiet                   set verbosity to lowest level
  -l{F}, --log-file={F}         output to the given log file, or '-' for standard output (default)
  -?, -h, --help                print this message
  -V, --version                 print program version
  -J{X}                         Java VM argument (ignored)
$ build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/unpack200 --version
unpack200 version 1.30, 07/05/05
$ build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/bin/unpack200 --version
unpack200 version 1.30, 07/05/05

Are you trying to fix tools/launcher/VersionCheck.java test or something else? I've reproduced that test failure with external debuginfo since the test tries to execute *every* file in $JAVA_HOME/bin (including *.debuginfo files). If you are trying to fix that problem, I'd suggest to filter debuginfo files out like was done as part of JDK-8237192 for JDK 11. We'd also have to include *.diz files from being excluded from the test. Those files are zipped version s of the *.debuginfo files. It looks like JDK 11 all the way to JDK 17 would try to run *.diz files as well?

Thanks,
Severin



From sgehwolf at redhat.com  Fri Mar  5 11:23:02 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 05 Mar 2021 12:23:02 +0100
Subject: =?UTF-8?Q?=E5=9B=9E=E5=A4=8D=3A?= [8u]RFR: 8263061: copy wrong
 unpack200.diz to bin directory on linux after 8252395(Internet mail)
In-Reply-To: <5541b2eea80b441ab6d8a417f09184a1@tencent.com>
References: <cff06e34930f41fa9a95601d5312fed0@tencent.com>
 <b1116fa7312e1242a6542f9b1a69a709f4927a21.camel@redhat.com>
 <5541b2eea80b441ab6d8a417f09184a1@tencent.com>
Message-ID: <378036e93c6ec186d4af5b0dfe794c49ef08a149.camel@redhat.com>

On Fri, 2021-03-05 at 11:00 +0000, kalinshi(??) wrote:
> 
> This fix is making it copy correct debug info file.
> "cp build/linux-x86_64-normal-server-release/jdk/objs/unpackexe/unpack200.diz build/linux-x86_64-normal-server-release/jdk/bin/unpack200.diz".

OK, got it. Currently, without this patch, we have this weird thing:

$ build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/unpack200.debuginfo -h
Usage:  unpack200.debuginfo [-opt... | --option=value]... x.pack[.gz] y.jar

Unpacking Options
  -H{h}, --deflate-hint={h}     override transmitted deflate hint: true, false, or keep (default)
  -r, --remove-pack-file        remove input file after unpacking
  -v, --verbose                 increase program verbosity
  -q, --quiet                   set verbosity to lowest level
  -l{F}, --log-file={F}         output to the given log file, or '-' for standard output (default)
  -?, -h, --help                print this message
  -V, --version                 print program version
  -J{X}                         Java VM argument (ignored)

I've changed the bug description slightly so as to make this clearer.
Hope that's OK. I'll review this change later today.

Thanks,
Severin


From adfarley at redhat.com  Fri Mar  5 16:15:26 2021
From: adfarley at redhat.com (Adam Farley)
Date: Fri, 5 Mar 2021 16:15:26 +0000
Subject: RFR: 8263099: TimSortStackSize2.java throws OOM when using
 -XX:-UseCompressedOops
Message-ID: <CANZLDasCM3PRic1Z_xswdcWNTo8c2Ho7vLXQLmd+UwpR2dBO_w@mail.gmail.com>

Hi All,

Simple problem, which is solved on later jdk versions by simply increasing
the heap.

Request reviews and sponsor for this change.

Bug: https://bugs.openjdk.java.net/browse/JDK-8263099

Best Regards

Adam Farley
Software Developer
Red Hat

From sgehwolf at redhat.com  Fri Mar  5 17:54:59 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 05 Mar 2021 18:54:59 +0100
Subject: [8u]RFR: 8263061: copy wrong unpack200.diz to bin directory on
 linux after 8252395
In-Reply-To: <cff06e34930f41fa9a95601d5312fed0@tencent.com>
References: <cff06e34930f41fa9a95601d5312fed0@tencent.com>
Message-ID: <705e44018175a1b2b02a388fb253a0a03edff3de.camel@redhat.com>

On Fri, 2021-03-05 at 07:35 +0000, kalinshi(??) wrote:
> Hi,
> 
> Please help review this fix.
> After 8252395, unpack200 executable is wrongly copied to bin directory
> as unpack200.diz when configure with debuginfo.
> 
> Makefile sets same prerequisite for unpack200 executable and debuginfo
> file. install-file function always copies first prerequisite, which is
> executable.
> Fix is use debuginfo file as first prerequisite and copy it.
> 
> webrev: http://cr.openjdk.java.net/~hshi/8263061/webrev1/
> bug: https://bugs.openjdk.java.net/browse/JDK-8263061

558 # move DEBUGINFO_EXT suffix prerequisite to first prerequisite
559 BUILD_UNPACK_DEBUGINFO := $(filter %$(DEBUGINFO_EXT), $(BUILD_UNPACKEXE))
560 BUILD_UNPACK_DEBUGINFO += $(filter-out %$(DEBUGINFO_EXT), $(BUILD_UNPACKEXE))
561 $(JDK_OUTPUTDIR)/bin$(OUTPUT_SUBDIR)/unpack200$(DEBUGINFO_EXT): $(BUILD_UNPACK_DEBUGINFO)
562         $(call install-file)

Rather than sorting dependencies to be in the right order (make
unpack200.(debuginfo|diz) the first dependency) just to suit the
install-file macro, have you considered using a similar pattern than is
used for the java launcher? I.e. lets just not use install-file for
this one.

This perhaps?

diff --git a/make/CompileLaunchers.gmk b/make/CompileLaunchers.gmk
--- a/make/CompileLaunchers.gmk
+++ b/make/CompileLaunchers.gmk
@@ -556,7 +556,9 @@
        $(call install-file)
 
 $(JDK_OUTPUTDIR)/bin$(OUTPUT_SUBDIR)/unpack200$(DEBUGINFO_EXT): $(BUILD_UNPACKEXE)
-       $(call install-file)
+       $(MKDIR) -p $(@D)
+       $(RM) $@
+       $(CP) -R $(JDK_OUTPUTDIR)/objs/unpackexe$(OUTPUT_SUBDIR)/unpack200$(DEBUGINFO_EXT) $@
 
 BUILD_LAUNCHERS += $(JDK_OUTPUTDIR)/bin$(OUTPUT_SUBDIR)/unpack200$(EXE_SUFFIX)
 ifeq ($(ENABLE_DEBUG_SYMBOLS), true)


Thanks,
Severin


From hohensee at amazon.com  Fri Mar  5 19:15:57 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 5 Mar 2021 19:15:57 +0000
Subject: RFR: 8263099: TimSortStackSize2.java throws OOM when using
 -XX:-UseCompressedOops
Message-ID: <DCC0F21F-80DA-4DCB-A904-D5CB623B9434@amazon.com>

"hg log" says that this test has had quite a few problems since JDK 8. These are the post JDK 8 ones.

$ hg log test/jdk/java/util/Arrays/TimSortStackSize2.java # after repo consolidation

changeset:   53086:a15200acedcd
user:        andrew
date:        Tue Mar 31 08:08:44 2020 +0100
summary:     8220613: java/util/Arrays/TimSortStackSize2.java times out with fastdebug build

changeset:   50849:9b0e2937fac5
user:        iignatyev
date:        Wed Jun 27 13:43:52 2018 -0700
summary:     8199265: java/util/Arrays/TimSortStackSize2.java fails with OOM

changeset:   49820:663f5d90f0e8
user:        darcy
date:        Wed Apr 18 10:03:49 2018 -0700
summary:     8201766: Mark TimSortStackSize2.java as intermittently failing

changeset:   49178:1836bf0c820a
user:        iignatyev
date:        Tue Feb 27 21:29:08 2018 -0800
summary:     8190679: java/util/Arrays/TimSortStackSize2.java fails with "Initial heap size set to a larger value than the maximum heap size"

changeset:   47216:71c04702a3d5
user:        erikj
date:        Tue Sep 12 19:03:39 2017 +0200
summary:     8187443: Forest Consolidation: Move files to unified layout

% hg log jdk/test/java/util/Arrays/TimSortStackSize2.java # before repo consolidation

changeset:   35768:7066da300a08
parent:      35739:db483b34fa71
user:        shurailine
date:        Mon Feb 08 18:14:48 2016 -0800
summary:     8149391: Fix module dependences in java/util tests

changeset:   33832:7dde7a271492
parent:      33659:400008d8de8c
user:        cjplummer
date:        Thu Oct 29 12:02:53 2015 -0700
summary:     8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests

changeset:   29613:da0ff5cf6e75
user:        lpriima
date:        Tue Mar 24 03:46:57 2015 -0400
summary:     8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java heap space: MaxHeap shrinked by MaxRAMFraction

If at all possible, I'd prefer to see these backported, excepting 8201766, 8187443, 8149391, and probably 8140189. The backports should apply pretty cleanly if done in order.

Thanks,
Paul

?-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Adam Farley <adfarley at redhat.com>
Date: Friday, March 5, 2021 at 8:16 AM
To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: RFR: 8263099: TimSortStackSize2.java throws OOM when using -XX:-UseCompressedOops

Hi All,

Simple problem, which is solved on later jdk versions by simply increasing
the heap.

Request reviews and sponsor for this change.

Bug: https://bugs.openjdk.java.net/browse/JDK-8263099

Best Regards

Adam Farley
Software Developer
Red Hat


From kalinshi at tencent.com  Sat Mar  6 10:49:06 2021
From: kalinshi at tencent.com (=?utf-8?B?a2FsaW5zaGko5pa95oWnKQ==?=)
Date: Sat, 6 Mar 2021 10:49:06 +0000
Subject: =?utf-8?B?5Zue5aSNOiBbOHVdUkZSOiA4MjYzMDYxOiBjb3B5IHdyb25nIHVucGFjazIw?=
 =?utf-8?B?MC5kaXogdG8gYmluIGRpcmVjdG9yeSBvbiBsaW51eCBhZnRlciA4MjUyMzk1?=
 =?utf-8?Q?(Internet_mail)?=
In-Reply-To: <705e44018175a1b2b02a388fb253a0a03edff3de.camel@redhat.com>
References: <cff06e34930f41fa9a95601d5312fed0@tencent.com>
 <705e44018175a1b2b02a388fb253a0a03edff3de.camel@redhat.com>
Message-ID: <d670296fdf5c4be1a29ff38ebd27f6dd@tencent.com>

Thanks Severin!

It's more reasonable to keep same copy way in Makefile. Tested with both --with-native-debug-symbols=external --with-native-debug-symbols=zipped
Updated Webrev: http://cr.openjdk.java.net/~hshi/8263061/webrev_v2

Another finding is that debuginfo files (not zipped) are executable and this fails VersionCheck.java test.
Instead of porting JDK-8237192 changes to filter these debuginfo files, is it more reasonable to make them not executable on linux/solaris?
Making following changes in top level mercurial jdk8u repository.

diff -r 8006ef1eeba6 make/common/NativeCompilation.gmk
--- a/make/common/NativeCompilation.gmk Mon Mar 01 20:02:56 2021 +0000
+++ b/make/common/NativeCompilation.gmk Sat Mar 06 18:45:29 2021 +0800
@@ -480,6 +480,7 @@
                        $(OBJCOPY) --only-keep-debug $$< $$@
                        $(CD) $$(@D) && $(ADD_GNU_DEBUGLINK) $(LOG_INFO) $$(@F) $$<
                        $(TOUCH) $$@
+                       $(CHMOD) a-x $$@
             endif
           else ifeq ($(OPENJDK_TARGET_OS), linux)
             ifneq ($$($1_STRIP_POLICY), no_strip)
@@ -489,6 +490,7 @@
                        $(OBJCOPY) --only-keep-debug $$< $$@
                        $(CD) $$(@D) && $(OBJCOPY) --add-gnu-debuglink=$$(@F) $$<
                        $(TOUCH) $$@
+                       $(CHMOD) a-x $$@
             endif
           endif # No MacOS X support

Regards
Hui

-----????-----
???: Severin Gehwolf <sgehwolf at redhat.com> 
????: 2021?3?6? 1:55
???: kalinshi(??) <kalinshi at tencent.com>; jdk8u-dev at openjdk.java.net
??: Re: [8u]RFR: 8263061: copy wrong unpack200.diz to bin directory on linux after 8252395(Internet mail)

On Fri, 2021-03-05 at 07:35 +0000, kalinshi(??) wrote:
> Hi,
> 
> Please help review this fix.
> After 8252395, unpack200 executable is wrongly copied to bin directory 
> as unpack200.diz when configure with debuginfo.
> 
> Makefile sets same prerequisite for unpack200 executable and debuginfo 
> file. install-file function always copies first prerequisite, which is 
> executable.
> Fix is use debuginfo file as first prerequisite and copy it.
> 
> webrev: http://cr.openjdk.java.net/~hshi/8263061/webrev1/
> bug: https://bugs.openjdk.java.net/browse/JDK-8263061

558 # move DEBUGINFO_EXT suffix prerequisite to first prerequisite
559 BUILD_UNPACK_DEBUGINFO := $(filter %$(DEBUGINFO_EXT), $(BUILD_UNPACKEXE))
560 BUILD_UNPACK_DEBUGINFO += $(filter-out %$(DEBUGINFO_EXT), $(BUILD_UNPACKEXE))
561 $(JDK_OUTPUTDIR)/bin$(OUTPUT_SUBDIR)/unpack200$(DEBUGINFO_EXT): $(BUILD_UNPACK_DEBUGINFO)
562         $(call install-file)

Rather than sorting dependencies to be in the right order (make
unpack200.(debuginfo|diz) the first dependency) just to suit the install-file macro, have you considered using a similar pattern than is used for the java launcher? I.e. lets just not use install-file for this one.

This perhaps?

diff --git a/make/CompileLaunchers.gmk b/make/CompileLaunchers.gmk
--- a/make/CompileLaunchers.gmk
+++ b/make/CompileLaunchers.gmk
@@ -556,7 +556,9 @@
        $(call install-file)
 
 $(JDK_OUTPUTDIR)/bin$(OUTPUT_SUBDIR)/unpack200$(DEBUGINFO_EXT): $(BUILD_UNPACKEXE)
-       $(call install-file)
+       $(MKDIR) -p $(@D)
+       $(RM) $@
+       $(CP) -R 
+ $(JDK_OUTPUTDIR)/objs/unpackexe$(OUTPUT_SUBDIR)/unpack200$(DEBUGINFO_E
+ XT) $@
 
 BUILD_LAUNCHERS += $(JDK_OUTPUTDIR)/bin$(OUTPUT_SUBDIR)/unpack200$(EXE_SUFFIX)
 ifeq ($(ENABLE_DEBUG_SYMBOLS), true)


Thanks,
Severin



From sgehwolf at redhat.com  Mon Mar  8 09:25:59 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 08 Mar 2021 10:25:59 +0100
Subject: =?UTF-8?Q?=E5=9B=9E=E5=A4=8D=3A?= [8u]RFR: 8263061: copy wrong
 unpack200.diz to bin directory on linux after 8252395(Internet mail)
In-Reply-To: <d670296fdf5c4be1a29ff38ebd27f6dd@tencent.com>
References: <cff06e34930f41fa9a95601d5312fed0@tencent.com>
 <705e44018175a1b2b02a388fb253a0a03edff3de.camel@redhat.com>
 <d670296fdf5c4be1a29ff38ebd27f6dd@tencent.com>
Message-ID: <7abc5dc1b1741f45d2e85fe97479a15a8dc48b6b.camel@redhat.com>

Hi,

On Sat, 2021-03-06 at 10:49 +0000, kalinshi(??) wrote:
> Thanks Severin!
> 
> It's more reasonable to keep same copy way in Makefile. Tested with
> both --with-native-debug-symbols=external --with-native-debug-
> symbols=zipped
> Updated Webrev: http://cr.openjdk.java.net/~hshi/8263061/webrev_v2

This looks good. Thanks!

> Another finding is that debuginfo files (not zipped) are executable
> and this fails VersionCheck.java test.
> Instead of porting JDK-8237192 changes to filter these debuginfo
> files, is it more reasonable to make them not executable on
> linux/solaris?
> Making following changes in top level mercurial jdk8u repository.
> 
> diff -r 8006ef1eeba6 make/common/NativeCompilation.gmk
> --- a/make/common/NativeCompilation.gmk Mon Mar 01 20:02:56 2021 +0000
> +++ b/make/common/NativeCompilation.gmk Sat Mar 06 18:45:29 2021 +0800
> @@ -480,6 +480,7 @@
> ??????????????????????? $(OBJCOPY) --only-keep-debug $$< $$@
> ??????????????????????? $(CD) $$(@D) && $(ADD_GNU_DEBUGLINK) $(LOG_INFO) $$(@F) $$<
> ??????????????????????? $(TOUCH) $$@
> +?????????????????????? $(CHMOD) a-x $$@
> ???????????? endif
> ?????????? else ifeq ($(OPENJDK_TARGET_OS), linux)
> ???????????? ifneq ($$($1_STRIP_POLICY), no_strip)
> @@ -489,6 +490,7 @@
> ??????????????????????? $(OBJCOPY) --only-keep-debug $$< $$@
> ??????????????????????? $(CD) $$(@D) && $(OBJCOPY) --add-gnu-debuglink=$$(@F) $$<
> ??????????????????????? $(TOUCH) $$@
> +?????????????????????? $(CHMOD) a-x $$@
> ???????????? endif
> ?????????? endif # No MacOS X support

I haven't made up my mind about it. It feels like we should do
something similar to a partial port of JDK-8237192 to JDK 8u so as to
keep trees in sync. Either way, this is for a separate bug/discussion.

Thanks,
Severin


From kalinshi at tencent.com  Mon Mar  8 10:29:46 2021
From: kalinshi at tencent.com (=?utf-8?B?a2FsaW5zaGko5pa95oWnKQ==?=)
Date: Mon, 8 Mar 2021 10:29:46 +0000
Subject: =?utf-8?B?5Zue5aSNOiDlm57lpI06IFs4dV1SRlI6IDgyNjMwNjE6IGNvcHkgd3Jvbmcg?=
 =?utf-8?B?dW5wYWNrMjAwLmRpeiB0byBiaW4gZGlyZWN0b3J5IG9uIGxpbnV4IGFmdGVy?=
 =?utf-8?Q?_8252395(Internet_mail)?=
In-Reply-To: <7abc5dc1b1741f45d2e85fe97479a15a8dc48b6b.camel@redhat.com>
References: <cff06e34930f41fa9a95601d5312fed0@tencent.com>
 <705e44018175a1b2b02a388fb253a0a03edff3de.camel@redhat.com>
 <d670296fdf5c4be1a29ff38ebd27f6dd@tencent.com>
 <7abc5dc1b1741f45d2e85fe97479a15a8dc48b6b.camel@redhat.com>
Message-ID: <2b450da6825441cf9de5a7c143f90e5a@tencent.com>

Thanks!

I'll leave other issue here.

Regards
Hui
-----????-----
???: Severin Gehwolf <sgehwolf at redhat.com> 
????: 2021?3?8? 17:26
???: kalinshi(??) <kalinshi at tencent.com>; jdk8u-dev at openjdk.java.net
??: Re: ??: [8u]RFR: 8263061: copy wrong unpack200.diz to bin directory on linux after 8252395(Internet mail)

Hi,

On Sat, 2021-03-06 at 10:49 +0000, kalinshi(??) wrote:
> Thanks Severin!
> 
> It's more reasonable to keep same copy way in Makefile. Tested with 
> both --with-native-debug-symbols=external --with-native-debug- 
> symbols=zipped Updated Webrev: 
> http://cr.openjdk.java.net/~hshi/8263061/webrev_v2

This looks good. Thanks!

> Another finding is that debuginfo files (not zipped) are executable 
> and this fails VersionCheck.java test.
> Instead of porting JDK-8237192 changes to filter these debuginfo 
> files, is it more reasonable to make them not executable on 
> linux/solaris?
> Making following changes in top level mercurial jdk8u repository.
> 
> diff -r 8006ef1eeba6 make/common/NativeCompilation.gmk
> --- a/make/common/NativeCompilation.gmk Mon Mar 01 20:02:56 2021 +0000
> +++ b/make/common/NativeCompilation.gmk Sat Mar 06 18:45:29 2021 +0800
> @@ -480,6 +480,7 @@
> ??????????????????????? $(OBJCOPY) --only-keep-debug $$< $$@
> ??????????????????????? $(CD) $$(@D) && $(ADD_GNU_DEBUGLINK) 
> $(LOG_INFO) $$(@F) $$<
> ??????????????????????? $(TOUCH) $$@
> +?????????????????????? $(CHMOD) a-x $$@
> ???????????? endif
> ?????????? else ifeq ($(OPENJDK_TARGET_OS), linux)
> ???????????? ifneq ($$($1_STRIP_POLICY), no_strip) @@ -489,6 +490,7 @@
> ??????????????????????? $(OBJCOPY) --only-keep-debug $$< $$@
> ??????????????????????? $(CD) $$(@D) && $(OBJCOPY) 
> --add-gnu-debuglink=$$(@F) $$<
> ??????????????????????? $(TOUCH) $$@
> +?????????????????????? $(CHMOD) a-x $$@
> ???????????? endif
> ?????????? endif # No MacOS X support

I haven't made up my mind about it. It feels like we should do something similar to a partial port of JDK-8237192 to JDK 8u so as to keep trees in sync. Either way, this is for a separate bug/discussion.

Thanks,
Severin



From adfarley at redhat.com  Mon Mar  8 18:00:16 2021
From: adfarley at redhat.com (Adam Farley)
Date: Mon, 8 Mar 2021 18:00:16 +0000
Subject: RFR: 8263099: TimSortStackSize2.java throws OOM when using
 -XX:-UseCompressedOops
In-Reply-To: <DCC0F21F-80DA-4DCB-A904-D5CB623B9434@amazon.com>
References: <DCC0F21F-80DA-4DCB-A904-D5CB623B9434@amazon.com>
Message-ID: <CANZLDas2HLdP_uSUW-dEksPXK3kVSoTodSWMB1dU5RfnUP3z0A@mail.gmail.com>

Hi Paul,

I merged the other four change sets, however 3 of the 4 were not clean
backports.

Mainly:

1) /../../test/lib causes errors (and, sans ".."s, is the wrong dir for
that lib on jdk8 anyway).
2) ProcessTools lacks executeTestJava(String...), though executeTestJvm
seems to do the same thing.
3) TEST.ROOT seems to lack the section required for the vm.debug change.

I don't think any of those is a major loss though, so I added the parts of
the change sets I thought were clean.

https://github.com/AdoptOpenJDK/openjdk-jdk8u/compare/master...adamfarley:oom_upstream_merge_fix

Your thoughts?

Best Regards

Adam Farley
Software Developer
Red Hat


On Fri, Mar 5, 2021 at 7:19 PM Hohensee, Paul <hohensee at amazon.com> wrote:

> "hg log" says that this test has had quite a few problems since JDK 8.
> These are the post JDK 8 ones.
>
> $ hg log test/jdk/java/util/Arrays/TimSortStackSize2.java # after repo
> consolidation
>
> changeset:   53086:a15200acedcd
> user:        andrew
> date:        Tue Mar 31 08:08:44 2020 +0100
> summary:     8220613: java/util/Arrays/TimSortStackSize2.java times out
> with fastdebug build
>
> changeset:   50849:9b0e2937fac5
> user:        iignatyev
> date:        Wed Jun 27 13:43:52 2018 -0700
> summary:     8199265: java/util/Arrays/TimSortStackSize2.java fails with
> OOM
>
> changeset:   49820:663f5d90f0e8
> user:        darcy
> date:        Wed Apr 18 10:03:49 2018 -0700
> summary:     8201766: Mark TimSortStackSize2.java as intermittently failing
>
> changeset:   49178:1836bf0c820a
> user:        iignatyev
> date:        Tue Feb 27 21:29:08 2018 -0800
> summary:     8190679: java/util/Arrays/TimSortStackSize2.java fails with
> "Initial heap size set to a larger value than the maximum heap size"
>
> changeset:   47216:71c04702a3d5
> user:        erikj
> date:        Tue Sep 12 19:03:39 2017 +0200
> summary:     8187443: Forest Consolidation: Move files to unified layout
>
> % hg log jdk/test/java/util/Arrays/TimSortStackSize2.java # before repo
> consolidation
>
> changeset:   35768:7066da300a08
> parent:      35739:db483b34fa71
> user:        shurailine
> date:        Mon Feb 08 18:14:48 2016 -0800
> summary:     8149391: Fix module dependences in java/util tests
>
> changeset:   33832:7dde7a271492
> parent:      33659:400008d8de8c
> user:        cjplummer
> date:        Thu Oct 29 12:02:53 2015 -0700
> summary:     8140189: [TESTBUG] Get rid of "@library /../../test/lib" in
> jtreg tests
>
> changeset:   29613:da0ff5cf6e75
> user:        lpriima
> date:        Tue Mar 24 03:46:57 2015 -0400
> summary:     8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java heap
> space: MaxHeap shrinked by MaxRAMFraction
>
> If at all possible, I'd prefer to see these backported, excepting 8201766,
> 8187443, 8149391, and probably 8140189. The backports should apply pretty
> cleanly if done in order.
>
> Thanks,
> Paul
>
> ?-----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Adam
> Farley <adfarley at redhat.com>
> Date: Friday, March 5, 2021 at 8:16 AM
> To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
> Subject: RFR: 8263099: TimSortStackSize2.java throws OOM when using
> -XX:-UseCompressedOops
>
> Hi All,
>
> Simple problem, which is solved on later jdk versions by simply increasing
> the heap.
>
> Request reviews and sponsor for this change.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8263099
>
> Best Regards
>
> Adam Farley
> Software Developer
> Red Hat
>
>

From ge.guo at huawei.com  Tue Mar  9 08:18:54 2021
From: ge.guo at huawei.com (Guo Ge)
Date: Tue, 9 Mar 2021 16:18:54 +0800
Subject: [8u] RFR: 8191955: AArch64: incorrect prefetch distance causes an
 internal error
Message-ID: <c8e01978-3cb2-1995-c26a-72bb9c05ea12@huawei.com>

Hi,

I would like to request a review for backport of JDK-8191955.

Original bug: https://bugs.openjdk.java.net/browse/JDK-8191955
webrev for 8u: http://cr.openjdk.java.net/~gguo/8191955-8u/webrev.00/

The original fix is not clean due to context change, `java 
-XX:AllocatePrefetchDistance=196 -jar SPECjvm2008.jar -coe -ikv -wt 5s 
-it 10s scimark.sparse.large` will throw a crash without the patch and 
pass with it.

Thanks,
Guo Ge

From ge.guo at huawei.com  Tue Mar  9 09:02:24 2021
From: ge.guo at huawei.com (Guo Ge)
Date: Tue, 9 Mar 2021 17:02:24 +0800
Subject: [8u] RFR: 8031085: DateTimeFormatter won't parse dates with custom
 format "yyyyMMddHHmmssSSS"
Message-ID: <ef2c80ec-ca1f-d1f9-9b44-6326e80cc177@huawei.com>

Hi,

I would like to request a review for backport of JDK-8031085.

Original bug: https://bugs.openjdk.java.net/browse/JDK-8031085
webrev for 8u: http://cr.openjdk.java.net/~gguo/8031085-8u/webrev.00

The fix is imperative in product, the original fix is not clean due to 
context change, performed jtreg jdk/test/java/time on Linux/x86-64.

Thanks,
Guo Ge

From sgehwolf at redhat.com  Tue Mar  9 10:20:04 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 09 Mar 2021 11:20:04 +0100
Subject: [8u] RFR: 8031085: DateTimeFormatter won't parse dates with
 custom format "yyyyMMddHHmmssSSS"
In-Reply-To: <ef2c80ec-ca1f-d1f9-9b44-6326e80cc177@huawei.com>
References: <ef2c80ec-ca1f-d1f9-9b44-6326e80cc177@huawei.com>
Message-ID: <d748d177f338cf4b5d5997aaa10e6608e86646bf.camel@redhat.com>

On Tue, 2021-03-09 at 17:02 +0800, Guo Ge wrote:
> Hi,
> 
> I would like to request a review for backport of JDK-8031085.
> 
> Original bug: https://bugs.openjdk.java.net/browse/JDK-8031085
> webrev for 8u: http://cr.openjdk.java.net/~gguo/8031085-8u/webrev.00
> 
> The fix is imperative in product, the original fix is not clean due to
>  context change, performed jtreg jdk/test/java/time on Linux/x86-64.

This seems a dangerous change and has been in JDK 8u for a long
time.?I'm not sure this one is worth fixing.

It would need a) a CSR (changes public API) b) verification this
doesn't break TCK. Has that been done?

Thanks,
Severin




From hohensee at amazon.com  Tue Mar  9 16:49:07 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 9 Mar 2021 16:49:07 +0000
Subject: [8u] RFR: 8191955: AArch64: incorrect prefetch distance causes an
 internal error
Message-ID: <663B73C9-FB81-41B0-A8D0-6BEDD18E61F2@amazon.com>

Lgtm.

Thanks,
Paul

?-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Guo Ge <ge.guo at huawei.com>
Date: Tuesday, March 9, 2021 at 12:19 AM
To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: [8u] RFR: 8191955: AArch64: incorrect prefetch distance causes an internal error

Hi,

I would like to request a review for backport of JDK-8191955.

Original bug: https://bugs.openjdk.java.net/browse/JDK-8191955
webrev for 8u: http://cr.openjdk.java.net/~gguo/8191955-8u/webrev.00/

The original fix is not clean due to context change, `java
-XX:AllocatePrefetchDistance=196 -jar SPECjvm2008.jar -coe -ikv -wt 5s
-it 10s scimark.sparse.large` will throw a crash without the patch and
pass with it.

Thanks,
Guo Ge


From stooke at redhat.com  Tue Mar  9 17:10:56 2021
From: stooke at redhat.com (Simon Tooke)
Date: Tue, 9 Mar 2021 12:10:56 -0500
Subject: [8u] RFR: 8262864: No debug symbols in image for Windows
 --with-native-debug-symbols=external
In-Reply-To: <CAFFhbGM84D=mi2H1emTWiam-Yo29LjqjiHQASov4+AN3bd-tXg@mail.gmail.com>
References: <CAFFhbGM84D=mi2H1emTWiam-Yo29LjqjiHQASov4+AN3bd-tXg@mail.gmail.com>
Message-ID: <f9279f3b-6921-7cca-e55d-7763aaa0e66e@redhat.com>

(disclaimer, I am not an official reviewer, but I'm offering my opinion 
to those who are)

I tried this patch, and it does as it says; I see map and PDB files 
where I didn't before.

However (and this is not a fault of this PR; it's a preexisting bug) 
since java.exe and java.dll are both in the ./bin directory on Windows, 
only one set of debug information is present - in my testing, the 
map/pdb files corresponding to java.dll, not java.exe.

Another pre-existing issue is that the compressed debug ('.diz') file 
contains the full build path to the debug files, where it's probably 
tidier to have them relative to the image directory.? For example:

Archive: 
C:/tmp/build-8/jdk8u-dev/build/windows-x86_64-server-fastdebug/images/j2re-image/bin/java.diz
 ?Length?? Method??? Size? Cmpr??? Date??? Time?? CRC-32?? Name
--------? ------? ------- ---- ---------- ----- --------? ----
 ?1199104? Defl:N?? 215859? 82% 03/09/2021 11:37 bf9b8804 
cygdrive/c/tmp/build-8/jdk8u-dev/build/windows-x86_64-server-fastdebug/jdk/objs/libjava/java.pdb
 ? 141184? Defl:N??? 26367? 81% 03/09/2021 11:37 a6a7fc16 
cygdrive/c/tmp/build-8/jdk8u-dev/build/windows-x86_64-server-fastdebug/jdk/objs/libjava/java.map
--------????????? -------? ---??????????????????????????? -------
 ?1340288?????????? 242226? 82%??????????????????????????? 2 files

instead of ./bin/java.pdb and ./bin/java.map.

I don't expect either of these issues to hold up this PR, though; this 
PR is fine.? These issue may even occur in later JDKs; I'll have to go 
check.

-Simon Tooke

On 2021-03-02 1:50 p.m., Andrew Leonard wrote:
> Hi,
> Please can I get reviews for this patch to fix the creation of jdk8u
> Windows debug files (.map, .pdb) when using
> --with-native-debug-symbols=external. A recent fix resolved this for
> non-Windows (https://bugs.openjdk.java.net/browse/JDK-8252395), this fixes
> Windows and also a minor issue with the other platforms that JDK-8252395
> didn't quite fix.
> webrev: https://cr.openjdk.java.net/~aleonard/8262864/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8262864
> Thanks
> Andrew
>


From kalinshi at tencent.com  Wed Mar 10 01:46:59 2021
From: kalinshi at tencent.com (=?utf-8?B?a2FsaW5zaGko5pa95oWnKQ==?=)
Date: Wed, 10 Mar 2021 01:46:59 +0000
Subject: =?utf-8?B?5Zue5aSNOiDlm57lpI06IFs4dV1SRlI6IDgyNjMwNjE6IGNvcHkgd3Jvbmcg?=
 =?utf-8?B?dW5wYWNrMjAwLmRpeiB0byBiaW4gZGlyZWN0b3J5IG9uIGxpbnV4IGFmdGVy?=
 =?utf-8?Q?_8252395(Internet_mail)?=
In-Reply-To: <7abc5dc1b1741f45d2e85fe97479a15a8dc48b6b.camel@redhat.com>
References: <cff06e34930f41fa9a95601d5312fed0@tencent.com>
 <705e44018175a1b2b02a388fb253a0a03edff3de.camel@redhat.com>
 <d670296fdf5c4be1a29ff38ebd27f6dd@tencent.com>
 <7abc5dc1b1741f45d2e85fe97479a15a8dc48b6b.camel@redhat.com>
Message-ID: <ae62e14b2fce4287b200a958ddeab10b@tencent.com>

Could some committer help sponsor this commit?

Regards
Hui

-----????-----
???: Severin Gehwolf <sgehwolf at redhat.com> 
????: 2021?3?8? 17:26
???: kalinshi(??) <kalinshi at tencent.com>; jdk8u-dev at openjdk.java.net
??: Re: ??: [8u]RFR: 8263061: copy wrong unpack200.diz to bin directory on linux after 8252395(Internet mail)

Hi,

On Sat, 2021-03-06 at 10:49 +0000, kalinshi(??) wrote:
> Thanks Severin!
> 
> It's more reasonable to keep same copy way in Makefile. Tested with 
> both --with-native-debug-symbols=external --with-native-debug- 
> symbols=zipped Updated Webrev: 
> http://cr.openjdk.java.net/~hshi/8263061/webrev_v2

This looks good. Thanks!

> Another finding is that debuginfo files (not zipped) are executable 
> and this fails VersionCheck.java test.
> Instead of porting JDK-8237192 changes to filter these debuginfo 
> files, is it more reasonable to make them not executable on 
> linux/solaris?
> Making following changes in top level mercurial jdk8u repository.
> 
> diff -r 8006ef1eeba6 make/common/NativeCompilation.gmk
> --- a/make/common/NativeCompilation.gmk Mon Mar 01 20:02:56 2021 +0000
> +++ b/make/common/NativeCompilation.gmk Sat Mar 06 18:45:29 2021 +0800
> @@ -480,6 +480,7 @@
> ??????????????????????? $(OBJCOPY) --only-keep-debug $$< $$@
> ??????????????????????? $(CD) $$(@D) && $(ADD_GNU_DEBUGLINK) 
> $(LOG_INFO) $$(@F) $$<
> ??????????????????????? $(TOUCH) $$@
> +?????????????????????? $(CHMOD) a-x $$@
> ???????????? endif
> ?????????? else ifeq ($(OPENJDK_TARGET_OS), linux)
> ???????????? ifneq ($$($1_STRIP_POLICY), no_strip) @@ -489,6 +490,7 @@
> ??????????????????????? $(OBJCOPY) --only-keep-debug $$< $$@
> ??????????????????????? $(CD) $$(@D) && $(OBJCOPY) 
> --add-gnu-debuglink=$$(@F) $$<
> ??????????????????????? $(TOUCH) $$@
> +?????????????????????? $(CHMOD) a-x $$@
> ???????????? endif
> ?????????? endif # No MacOS X support

I haven't made up my mind about it. It feels like we should do something similar to a partial port of JDK-8237192 to JDK 8u so as to keep trees in sync. Either way, this is for a separate bug/discussion.

Thanks,
Severin



From sgehwolf at redhat.com  Wed Mar 10 10:14:59 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 10 Mar 2021 11:14:59 +0100
Subject: [8u] RFR: 8262864: No debug symbols in image for Windows
 --with-native-debug-symbols=external
In-Reply-To: <CAFFhbGM84D=mi2H1emTWiam-Yo29LjqjiHQASov4+AN3bd-tXg@mail.gmail.com>
References: <CAFFhbGM84D=mi2H1emTWiam-Yo29LjqjiHQASov4+AN3bd-tXg@mail.gmail.com>
Message-ID: <1d1eccc31077996cdb08f1f6e4877df3f8d8c690.camel@redhat.com>

Hi Andrew,

On Tue, 2021-03-02 at 18:50 +0000, Andrew Leonard wrote:
> Hi,
> Please can I get reviews for this patch to fix the creation of jdk8u
> Windows debug files (.map, .pdb) when using
> --with-native-debug-symbols=external. A recent fix resolved this for
> non-Windows (https://bugs.openjdk.java.net/browse/JDK-8252395), this fixes
> Windows and also a minor issue with the other platforms that
> JDK-8252395 didn't quite fix.

Can you be more specific what this "minor issue" is that you fixed
here?

> webrev: https://cr.openjdk.java.net/~aleonard/8262864/webrev.00/

-ifeq ($(OPENJDK_TARGET_OS), windows)
-  # On windows, the libraries are in the bin dir, only filter out debuginfo files
-  # for executables. "java" is both a library and executable.
-  ALL_BIN_EXEC_FILES := $(filter-out java.exe, $(notdir $(filter %.exe, $(ALL_BIN_LIST))))
-  ALL_BIN_DEBUG_FILTER := $(addprefix %, $(patsubst %.exe, %.debuginfo, $(ALL_BIN_EXEC_FILES)) \
-      $(patsubst %.exe, %.diz, $(ALL_BIN_EXEC_FILES))) %.pdb
-  ALL_BIN_LIST := $(filter-out $(ALL_BIN_DEBUG_FILTER), $(ALL_BIN_LIST))
-endif

If I understand Simon correctly then by removing these bits it doesn't
change the fact that debuginfo for only one of the files, java.exe OR
java.dll, end up in the image. In his case it seemed to be debuginfo
for java.dll, but I wonder how predictable is? Isn't that a reason to
keep this part of the patch as it makes it more explicit that we prefer
debuginfo for java.dll over java.exe as we cannot have both.

Thoughts?

Thanks,
Severin


From sgehwolf at redhat.com  Wed Mar 10 10:37:57 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 10 Mar 2021 11:37:57 +0100
Subject: =?UTF-8?Q?=E5=9B=9E=E5=A4=8D=3A?=
 =?UTF-8?Q?_=E5=9B=9E=E5=A4=8D=3A?= [8u]RFR: 8263061: copy wrong
 unpack200.diz to bin directory on linux after 8252395(Internet mail)
In-Reply-To: <ae62e14b2fce4287b200a958ddeab10b@tencent.com>
References: <cff06e34930f41fa9a95601d5312fed0@tencent.com>
 <705e44018175a1b2b02a388fb253a0a03edff3de.camel@redhat.com>
 <d670296fdf5c4be1a29ff38ebd27f6dd@tencent.com>
 <7abc5dc1b1741f45d2e85fe97479a15a8dc48b6b.camel@redhat.com>
 <ae62e14b2fce4287b200a958ddeab10b@tencent.com>
Message-ID: <91af38befae04bfaa0ec8809d583e99ac8e79b2d.camel@redhat.com>

On Wed, 2021-03-10 at 01:46 +0000, kalinshi(??) wrote:
> Could some committer help sponsor this commit?

Sure I can do that for you.

Thanks,
Severin

> Regards
> Hui
> 
> -----????-----
> ???: Severin Gehwolf <sgehwolf at redhat.com> 
> ????: 2021?3?8? 17:26
> ???: kalinshi(??) <kalinshi at tencent.com>; jdk8u-dev at openjdk.java.net
> ??: Re: ??: [8u]RFR: 8263061: copy wrong unpack200.diz to bin
> directory on linux after 8252395(Internet mail)
> 
> Hi,
> 
> On Sat, 2021-03-06 at 10:49 +0000, kalinshi(??) wrote:
> > Thanks Severin!
> > 
> > both --with-native-debug-symbols=external --with-native-debug- 
> > symbols=zipped Updated Webrev: 
> > http://cr.openjdk.java.net/~hshi/8263061/webrev_v2
> 
> This looks good. Thanks!
> 
> > and this fails VersionCheck.java test.
> > Instead of porting JDK-8237192 changes to filter these debuginfo 
> > files, is it more reasonable to make them not executable on 
> > linux/solaris?
> > Making following changes in top level mercurial jdk8u repository.
> > 
> > diff -r 8006ef1eeba6 make/common/NativeCompilation.gmk
> > --- a/make/common/NativeCompilation.gmk Mon Mar 01 20:02:56 2021
> > +0000
> > +++ b/make/common/NativeCompilation.gmk Sat Mar 06 18:45:29 2021
> > +0800
> > @@ -480,6 +480,7 @@
> > ??????????????????????? $(OBJCOPY) --only-keep-debug $$< $$@
> > ??????????????????????? $(CD) $$(@D) && $(ADD_GNU_DEBUGLINK) 
> > $(LOG_INFO) $$(@F) $$<
> > ??????????????????????? $(TOUCH) $$@
> > +?????????????????????? $(CHMOD) a-x $$@
> > ???????????? endif
> > ?????????? else ifeq ($(OPENJDK_TARGET_OS), linux)
> > ???????????? ifneq ($$($1_STRIP_POLICY), no_strip) @@ -489,6 +490,7
> > @@
> > ??????????????????????? $(OBJCOPY) --only-keep-debug $$< $$@
> > ??????????????????????? $(CD) $$(@D) && $(OBJCOPY) 
> > --add-gnu-debuglink=$$(@F) $$<
> > ??????????????????????? $(TOUCH) $$@
> > +?????????????????????? $(CHMOD) a-x $$@
> > ???????????? endif
> > ?????????? endif # No MacOS X support
> 
> I haven't made up my mind about it. It feels like we should do
> something similar to a partial port of JDK-8237192 to JDK 8u so as to
> keep trees in sync. Either way, this is for a separate
> bug/discussion.
> 
> Thanks,
> Severin
> 
> 



From anleonar at redhat.com  Wed Mar 10 10:45:05 2021
From: anleonar at redhat.com (Andrew Leonard)
Date: Wed, 10 Mar 2021 10:45:05 +0000
Subject: [8u] RFR: 8262864: No debug symbols in image for Windows
 --with-native-debug-symbols=external
In-Reply-To: <1d1eccc31077996cdb08f1f6e4877df3f8d8c690.camel@redhat.com>
References: <CAFFhbGM84D=mi2H1emTWiam-Yo29LjqjiHQASov4+AN3bd-tXg@mail.gmail.com>
 <1d1eccc31077996cdb08f1f6e4877df3f8d8c690.camel@redhat.com>
Message-ID: <CAFFhbGMekTVuW=s4m=h8aAsfp6oK7cpe3LXnvOnZ45kb6QG35A@mail.gmail.com>

The minor issue on Linux platforms was that it also did not remove the
non-jre jdk/jre/bin debug files correctly, it removed them "only" from
the JRE_BIN_LIST
and not the JDKJRE_BIN_LIST, so we had debuginfo files in jdk/jre/bin for
executeable files that were not there, eg.javap.debuginfo, but there is no
javap executable in jdk/jre/bin.

The section I removed did not achieve maybe what it was intending, i'm
actually not sure what it was intending! but the section was filtering out
from ALL_BIN_LIST all *.pdb debug files, ie.removing ALL external debug
symbols, hence the problem.. It was also removing *.debuginfo and *.diz
files for all .exe files in bin "except" for java.exe. So the "essence" of
what it was trying to do was always remove every type of debug file
(.diz,.debuginfo,.pdb) except for java.exe. Which didn't make sense, as per
the Linux section that was removed in the previous PR.
The issue Simon is referring to I think is at the source of the .pdb
generation for java.exe/dll (probably in
make/common/NativeCompilation.gmk), since they have the same basename one
is going to overwrite the other...this behavior is separate to this Image
creation copy rules. I've raised a new issue to cover that:
https://bugs.openjdk.java.net/browse/JDK-8263356

What do you think?
Thanks

On Wed, Mar 10, 2021 at 10:15 AM Severin Gehwolf <sgehwolf at redhat.com>
wrote:

> Hi Andrew,
>
> On Tue, 2021-03-02 at 18:50 +0000, Andrew Leonard wrote:
> > Hi,
> > Please can I get reviews for this patch to fix the creation of jdk8u
> > Windows debug files (.map, .pdb) when using
> > --with-native-debug-symbols=external. A recent fix resolved this for
> > non-Windows (https://bugs.openjdk.java.net/browse/JDK-8252395), this
> fixes
> > Windows and also a minor issue with the other platforms that
> > JDK-8252395 didn't quite fix.
>
> Can you be more specific what this "minor issue" is that you fixed
> here?
>
> > webrev: https://cr.openjdk.java.net/~aleonard/8262864/webrev.00/
>
> -ifeq ($(OPENJDK_TARGET_OS), windows)
> -  # On windows, the libraries are in the bin dir, only filter out
> debuginfo files
> -  # for executables. "java" is both a library and executable.
> -  ALL_BIN_EXEC_FILES := $(filter-out java.exe, $(notdir $(filter %.exe,
> $(ALL_BIN_LIST))))
> -  ALL_BIN_DEBUG_FILTER := $(addprefix %, $(patsubst %.exe, %.debuginfo,
> $(ALL_BIN_EXEC_FILES)) \
> -      $(patsubst %.exe, %.diz, $(ALL_BIN_EXEC_FILES))) %.pdb
> -  ALL_BIN_LIST := $(filter-out $(ALL_BIN_DEBUG_FILTER), $(ALL_BIN_LIST))
> -endif
>
> If I understand Simon correctly then by removing these bits it doesn't
> change the fact that debuginfo for only one of the files, java.exe OR
> java.dll, end up in the image. In his case it seemed to be debuginfo
> for java.dll, but I wonder how predictable is? Isn't that a reason to
> keep this part of the patch as it makes it more explicit that we prefer
> debuginfo for java.dll over java.exe as we cannot have both.
>
> Thoughts?
>
> Thanks,
> Severin
>
>

From anleonar at redhat.com  Wed Mar 10 11:25:11 2021
From: anleonar at redhat.com (Andrew Leonard)
Date: Wed, 10 Mar 2021 11:25:11 +0000
Subject: Re.[8u] RFRe: 8262864: No debug symbols in image for Windows
 --with-native-debug-symbols=external
Message-ID: <CAFFhbGOm+bR3fcaZjXCmD6-D60FAs=5kf05H5BaRhAC5JheYKA@mail.gmail.com>

Thanks for the informal review, I hadn't quite appreciated the java.exe/dll
issue, but as you point out that's an issue where these native debug files
are created, i've thus created a new bug for that problem:
https://bugs.openjdk.java.net/browse/JDK-8263356

Cheers
Andrew

From sgehwolf at redhat.com  Wed Mar 10 13:58:54 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 10 Mar 2021 14:58:54 +0100
Subject: [8u] RFR: 8262864: No debug symbols in image for Windows
 --with-native-debug-symbols=external
In-Reply-To: <CAFFhbGMekTVuW=s4m=h8aAsfp6oK7cpe3LXnvOnZ45kb6QG35A@mail.gmail.com>
References: <CAFFhbGM84D=mi2H1emTWiam-Yo29LjqjiHQASov4+AN3bd-tXg@mail.gmail.com>
 <1d1eccc31077996cdb08f1f6e4877df3f8d8c690.camel@redhat.com>
 <CAFFhbGMekTVuW=s4m=h8aAsfp6oK7cpe3LXnvOnZ45kb6QG35A@mail.gmail.com>
Message-ID: <a87ed30a41c2bd81e0e5c565d277346fd9bbeae1.camel@redhat.com>

Hi Andrew,

On Wed, 2021-03-10 at 10:45 +0000, Andrew Leonard wrote:
> The minor issue on Linux platforms was that it also did not remove
> the non-jre jdk/jre/bin debug files correctly, it removed them "only"
> from the JRE_BIN_LIST and not the JDKJRE_BIN_LIST, so we had
> debuginfo files in jdk/jre/bin for executeable files that were not
> there, eg.javap.debuginfo, but there is no javap executable in
> jdk/jre/bin.

Thanks for the explanation. Makes sense.

> The section I removed did not achieve maybe what it was intending,
> i'm actually not sure what it was intending! but the section was
> filtering out from ALL_BIN_LIST all *.pdb debug files, ie.removing
> ALL external debug symbols, hence the problem.. It was also removing
> *.debuginfo and *.diz files for all .exe files in bin "except" for
> java.exe. So the "essence" of what it was trying to do was always
> remove every type of debug file (.diz,.debuginfo,.pdb) except for
> java.exe. Which didn't make sense, as per the Linux section that was
> removed in the previous PR.
> The issue Simon is referring to I think is at the source of the .pdb
> generation for java.exe/dll (probably in
> make/common/NativeCompilation.gmk), since they have the same basename
> one is going to overwrite the other...this behavior is separate to
> this Image creation copy rules. I've raised a new issue to cover
> that: https://bugs.openjdk.java.net/browse/JDK-8263356

Thanks, this clarifies things. Yes, what you say makes sense. Consider
your patch reviewed. Feel free to flag for approval.

Thanks,
Severin


> What do you think?
> Thanks
> 
> On Wed, Mar 10, 2021 at 10:15 AM Severin Gehwolf
> <sgehwolf at redhat.com> wrote:
> > Hi Andrew,
> > 
> > On Tue, 2021-03-02 at 18:50 +0000, Andrew Leonard wrote:
> > > Hi,
> > > Please can I get reviews for this patch to fix the creation of
> > jdk8u
> > > Windows debug files (.map, .pdb) when using
> > > --with-native-debug-symbols=external. A recent fix resolved this
> > for
> > > non-Windows (https://bugs.openjdk.java.net/browse/JDK-8252395),
> > this fixes
> > > Windows and also a minor issue with the other platforms that
> > > JDK-8252395 didn't quite fix.
> > 
> > Can you be more specific what this "minor issue" is that you fixed
> > here?
> > 
> > > webrev: https://cr.openjdk.java.net/~aleonard/8262864/webrev.00/
> > 
> > -ifeq ($(OPENJDK_TARGET_OS), windows)
> > -? # On windows, the libraries are in the bin dir, only filter out
> > debuginfo files
> > -? # for executables. "java" is both a library and executable.
> > -? ALL_BIN_EXEC_FILES := $(filter-out java.exe, $(notdir $(filter
> > %.exe, $(ALL_BIN_LIST))))
> > -? ALL_BIN_DEBUG_FILTER := $(addprefix %, $(patsubst %.exe,
> > %.debuginfo, $(ALL_BIN_EXEC_FILES)) \
> > -? ? ? $(patsubst %.exe, %.diz, $(ALL_BIN_EXEC_FILES))) %.pdb
> > -? ALL_BIN_LIST := $(filter-out $(ALL_BIN_DEBUG_FILTER),
> > $(ALL_BIN_LIST))
> > -endif
> > 
> > If I understand Simon correctly then by removing these bits it
> > doesn't
> > change the fact that debuginfo for only one of the files, java.exe
> > OR
> > java.dll, end up in the image. In his case it seemed to be
> > debuginfo
> > for java.dll, but I wonder how predictable is? Isn't that a reason
> > to
> > keep this part of the patch as it makes it more explicit that we
> > prefer
> > debuginfo for java.dll over java.exe as we cannot have both.
> > 
> > Thoughts?
> > 
> > Thanks,
> > Severin
> > 



From anleonar at redhat.com  Wed Mar 10 15:21:25 2021
From: anleonar at redhat.com (Andrew Leonard)
Date: Wed, 10 Mar 2021 15:21:25 +0000
Subject: [8u] RFR: 8262864: No debug symbols in image for Windows
 --with-native-debug-symbols=external
In-Reply-To: <a87ed30a41c2bd81e0e5c565d277346fd9bbeae1.camel@redhat.com>
References: <CAFFhbGM84D=mi2H1emTWiam-Yo29LjqjiHQASov4+AN3bd-tXg@mail.gmail.com>
 <1d1eccc31077996cdb08f1f6e4877df3f8d8c690.camel@redhat.com>
 <CAFFhbGMekTVuW=s4m=h8aAsfp6oK7cpe3LXnvOnZ45kb6QG35A@mail.gmail.com>
 <a87ed30a41c2bd81e0e5c565d277346fd9bbeae1.camel@redhat.com>
Message-ID: <CAFFhbGOFgwLGoM1QQVmtRx0bsXT+5QW+JtaSvDJCUS5RegaikA@mail.gmail.com>

Thank you Severin, I have requested jdk8u-fix-request.
cheers
Andrew

On Wed, Mar 10, 2021 at 1:59 PM Severin Gehwolf <sgehwolf at redhat.com> wrote:

> Hi Andrew,
>
> On Wed, 2021-03-10 at 10:45 +0000, Andrew Leonard wrote:
> > The minor issue on Linux platforms was that it also did not remove
> > the non-jre jdk/jre/bin debug files correctly, it removed them "only"
> > from the JRE_BIN_LIST and not the JDKJRE_BIN_LIST, so we had
> > debuginfo files in jdk/jre/bin for executeable files that were not
> > there, eg.javap.debuginfo, but there is no javap executable in
> > jdk/jre/bin.
>
> Thanks for the explanation. Makes sense.
>
> > The section I removed did not achieve maybe what it was intending,
> > i'm actually not sure what it was intending! but the section was
> > filtering out from ALL_BIN_LIST all *.pdb debug files, ie.removing
> > ALL external debug symbols, hence the problem.. It was also removing
> > *.debuginfo and *.diz files for all .exe files in bin "except" for
> > java.exe. So the "essence" of what it was trying to do was always
> > remove every type of debug file (.diz,.debuginfo,.pdb) except for
> > java.exe. Which didn't make sense, as per the Linux section that was
> > removed in the previous PR.
> > The issue Simon is referring to I think is at the source of the .pdb
> > generation for java.exe/dll (probably in
> > make/common/NativeCompilation.gmk), since they have the same basename
> > one is going to overwrite the other...this behavior is separate to
> > this Image creation copy rules. I've raised a new issue to cover
> > that: https://bugs.openjdk.java.net/browse/JDK-8263356
>
> Thanks, this clarifies things. Yes, what you say makes sense. Consider
> your patch reviewed. Feel free to flag for approval.
>
> Thanks,
> Severin
>
>
> > What do you think?
> > Thanks
> >
> > On Wed, Mar 10, 2021 at 10:15 AM Severin Gehwolf
> > <sgehwolf at redhat.com> wrote:
> > > Hi Andrew,
> > >
> > > On Tue, 2021-03-02 at 18:50 +0000, Andrew Leonard wrote:
> > > > Hi,
> > > > Please can I get reviews for this patch to fix the creation of
> > > jdk8u
> > > > Windows debug files (.map, .pdb) when using
> > > > --with-native-debug-symbols=external. A recent fix resolved this
> > > for
> > > > non-Windows (https://bugs.openjdk.java.net/browse/JDK-8252395),
> > > this fixes
> > > > Windows and also a minor issue with the other platforms that
> > > > JDK-8252395 didn't quite fix.
> > >
> > > Can you be more specific what this "minor issue" is that you fixed
> > > here?
> > >
> > > > webrev: https://cr.openjdk.java.net/~aleonard/8262864/webrev.00/
> > >
> > > -ifeq ($(OPENJDK_TARGET_OS), windows)
> > > -  # On windows, the libraries are in the bin dir, only filter out
> > > debuginfo files
> > > -  # for executables. "java" is both a library and executable.
> > > -  ALL_BIN_EXEC_FILES := $(filter-out java.exe, $(notdir $(filter
> > > %.exe, $(ALL_BIN_LIST))))
> > > -  ALL_BIN_DEBUG_FILTER := $(addprefix %, $(patsubst %.exe,
> > > %.debuginfo, $(ALL_BIN_EXEC_FILES)) \
> > > -      $(patsubst %.exe, %.diz, $(ALL_BIN_EXEC_FILES))) %.pdb
> > > -  ALL_BIN_LIST := $(filter-out $(ALL_BIN_DEBUG_FILTER),
> > > $(ALL_BIN_LIST))
> > > -endif
> > >
> > > If I understand Simon correctly then by removing these bits it
> > > doesn't
> > > change the fact that debuginfo for only one of the files, java.exe
> > > OR
> > > java.dll, end up in the image. In his case it seemed to be
> > > debuginfo
> > > for java.dll, but I wonder how predictable is? Isn't that a reason
> > > to
> > > keep this part of the patch as it makes it more explicit that we
> > > prefer
> > > debuginfo for java.dll over java.exe as we cannot have both.
> > >
> > > Thoughts?
> > >
> > > Thanks,
> > > Severin
> > >
>
>
>

From hohensee at amazon.com  Wed Mar 10 21:05:50 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 10 Mar 2021 21:05:50 +0000
Subject: RFR: 8263099: TimSortStackSize2.java throws OOM when using
 -XX:-UseCompressedOops
Message-ID: <228D8358-EC21-453B-99CF-B7DB2376C826@amazon.com>

Hi, Adam, thanks for taking this on.

I believe the general 8u Maintainer consensus is against ?bulk? backports such as the one you propose, and in favor of doing a backport series, so we don?t lose history in the target jdk. I found only three changesets to backport.

8220613: java/util/Arrays/TimSortStackSize2.java times out with fastdebug build. Can?t backport because 8u doesn?t support vm.debug.

8199265: java/util/Arrays/TimSortStackSize2.java fails with OOM.
Webrev in https://cr.openjdk.java.net/~phh/8199265/webrev.8u.jdk.01/

8201766: Mark TimSortStackSize2.java as intermittently failing. N/A

8190679: java/util/Arrays/TimSortStackSize2.java fails with "Initial heap size set to a larger value than the maximum heap size".
Webrev in https://cr.openjdk.java.net/~phh/8190679/webrev.8u.jdk.01/

8149391: Fix module dependences in java/util tests. N/A

8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests. Incorporated into 8075071 backport in order to make it work.

8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java heap space: MaxHeap shrinked by MaxRAMFraction.
Webrev in https://cr.openjdk.java.net/~phh/8075071/webrev.8u.jdk.03/

I applied the above webrevs for 8075071, 8190679, and 8199265 in order. The result was your patch, except that I included ?@key intermittent? in the 8199265 patch.

Thanks,
Paul

From: Adam Farley <adfarley at redhat.com>
Date: Monday, March 8, 2021 at 10:00 AM
To: "Hohensee, Paul" <hohensee at amazon.com>
Cc: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: RE: RFR: 8263099: TimSortStackSize2.java throws OOM when using -XX:-UseCompressedOops

Hi Paul,
I merged the other four change sets, however 3 of the 4 were not clean backports.

Mainly:

1) /../../test/lib causes errors (and, sans ".."s, is the wrong dir for that lib on jdk8 anyway).
2) ProcessTools lacks executeTestJava(String...), though executeTestJvm seems to do the same thing.
3) TEST.ROOT seems to lack the section required for the vm.debug change.

I don't think any of those is a major loss though, so I added the parts of the change sets I thought were clean.

https://github.com/AdoptOpenJDK/openjdk-jdk8u/compare/master...adamfarley:oom_upstream_merge_fix

Your thoughts?

Best Regards

Adam Farley
Software Developer
Red Hat


On Fri, Mar 5, 2021 at 7:19 PM Hohensee, Paul <hohensee at amazon.com<mailto:hohensee at amazon.com>> wrote:
"hg log" says that this test has had quite a few problems since JDK 8. These are the post JDK 8 ones.

$ hg log test/jdk/java/util/Arrays/TimSortStackSize2.java # after repo consolidation

changeset:   53086:a15200acedcd
user:        andrew
date:        Tue Mar 31 08:08:44 2020 +0100
summary:     8220613: java/util/Arrays/TimSortStackSize2.java times out with fastdebug build

changeset:   50849:9b0e2937fac5
user:        iignatyev
date:        Wed Jun 27 13:43:52 2018 -0700
summary:     8199265: java/util/Arrays/TimSortStackSize2.java fails with OOM

changeset:   49820:663f5d90f0e8
user:        darcy
date:        Wed Apr 18 10:03:49 2018 -0700
summary:     8201766: Mark TimSortStackSize2.java as intermittently failing

changeset:   49178:1836bf0c820a
user:        iignatyev
date:        Tue Feb 27 21:29:08 2018 -0800
summary:     8190679: java/util/Arrays/TimSortStackSize2.java fails with "Initial heap size set to a larger value than the maximum heap size"

changeset:   47216:71c04702a3d5
user:        erikj
date:        Tue Sep 12 19:03:39 2017 +0200
summary:     8187443: Forest Consolidation: Move files to unified layout

% hg log jdk/test/java/util/Arrays/TimSortStackSize2.java # before repo consolidation

changeset:   35768:7066da300a08
parent:      35739:db483b34fa71
user:        shurailine
date:        Mon Feb 08 18:14:48 2016 -0800
summary:     8149391: Fix module dependences in java/util tests

changeset:   33832:7dde7a271492
parent:      33659:400008d8de8c
user:        cjplummer
date:        Thu Oct 29 12:02:53 2015 -0700
summary:     8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests

changeset:   29613:da0ff5cf6e75
user:        lpriima
date:        Tue Mar 24 03:46:57 2015 -0400
summary:     8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java heap space: MaxHeap shrinked by MaxRAMFraction

If at all possible, I'd prefer to see these backported, excepting 8201766, 8187443, 8149391, and probably 8140189. The backports should apply pretty cleanly if done in order.

Thanks,
Paul

-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net<mailto:jdk8u-dev-retn at openjdk.java.net>> on behalf of Adam Farley <adfarley at redhat.com<mailto:adfarley at redhat.com>>
Date: Friday, March 5, 2021 at 8:16 AM
To: "jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>" <jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>>
Subject: RFR: 8263099: TimSortStackSize2.java throws OOM when using -XX:-UseCompressedOops

Hi All,

Simple problem, which is solved on later jdk versions by simply increasing
the heap.

Request reviews and sponsor for this change.

Bug: https://bugs.openjdk.java.net/browse/JDK-8263099

Best Regards

Adam Farley
Software Developer
Red Hat

From gnu.andrew at redhat.com  Thu Mar 11 06:53:02 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 11 Mar 2021 06:53:02 +0000
Subject: [8u] [PROCESS] Removing the Need for Explicit Backport Bugs
Message-ID: <20210311065302.GA2530520@rincewind>

It seems the requirement to explicitly create backport bugs for each
8u backport has caused some confusion.  The process has also not been
adopted by other update streams, such as 11u, creating unnecessary
process differences.

After discussion with those who originally pushed for such bugs, it
seems the requirement is no longer necessary. As a result, I've
reverted the process text on the OpenJDK 8u wiki to much as it was
originally, where fix requests are made on the main bug and backport
bugs are not explicitly created in most circumstances.

Where explicit backport bugs do need to be created - this is usually
the case for filing an associated CSR - the same process should take
place on the backport bug instead, keeping things to a single bug. The
fix version should be set to 'openjdk8ux' where x is the current
development version. Please don't use 'openjdk8u' as the hgupdater
tool does not update these bugs on push.

I hope this helps ease the 8u backporting process.

Thanks,
--
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 stooke at redhat.com  Thu Mar 11 22:27:06 2021
From: stooke at redhat.com (Simon Tooke)
Date: Thu, 11 Mar 2021 17:27:06 -0500
Subject: [8u] RFR: 8262864: No debug symbols in image for Windows
 --with-native-debug-symbols=external
In-Reply-To: <CAFFhbGMekTVuW=s4m=h8aAsfp6oK7cpe3LXnvOnZ45kb6QG35A@mail.gmail.com>
References: <CAFFhbGM84D=mi2H1emTWiam-Yo29LjqjiHQASov4+AN3bd-tXg@mail.gmail.com>
 <1d1eccc31077996cdb08f1f6e4877df3f8d8c690.camel@redhat.com>
 <CAFFhbGMekTVuW=s4m=h8aAsfp6oK7cpe3LXnvOnZ45kb6QG35A@mail.gmail.com>
Message-ID: <5e3b37cc-979a-78df-4a17-3a08e3d468b4@redhat.com>


On 2021-03-10 5:45 a.m., Andrew Leonard wrote:
> The issue Simon is referring to I think is at the source of the .pdb
> generation for java.exe/dll (probably in
> make/common/NativeCompilation.gmk), since they have the same basename one
> is going to overwrite the other...this behavior is separate to this Image
> creation copy rules. I've raised a new issue to cover that:
> https://bugs.openjdk.java.net/browse/JDK-8263356

I have clarified in JBS that this issue is still present in later JDKs, 
although I've only tested 11u and head.

-Simon

--
Simon Tooke
Principal developer, Java Platform
Red Hat Canada, Inc.<https://www.redhat.com>


From ge.guo at huawei.com  Fri Mar 12 01:56:24 2021
From: ge.guo at huawei.com (Guo Ge)
Date: Fri, 12 Mar 2021 09:56:24 +0800
Subject: [8u] RFR: 8031085: DateTimeFormatter won't parse dates with
 custom format "yyyyMMddHHmmssSSS"
In-Reply-To: <d748d177f338cf4b5d5997aaa10e6608e86646bf.camel@redhat.com>
References: <ef2c80ec-ca1f-d1f9-9b44-6326e80cc177@huawei.com>
 <d748d177f338cf4b5d5997aaa10e6608e86646bf.camel@redhat.com>
Message-ID: <fd5f3460-ef24-446e-b7fb-1826d8f564ba@huawei.com>

Hi, Severin

Thanks for your suggestion, we have tested that the fix won't break TCK, 
but since there are several work-arounds, and the patch is more like an 
enhancement rather a bug-fix, we'd better not to backport this patch to 
8u, I have closed the issue.

Best wishes,
Guo Ge

On 2021/3/9 18:20, Severin Gehwolf wrote:
> On Tue, 2021-03-09 at 17:02 +0800, Guo Ge wrote:
>> Hi,
>>
>> I would like to request a review for backport of JDK-8031085.
>>
>> Original bug: https://bugs.openjdk.java.net/browse/JDK-8031085
>> webrev for 8u: http://cr.openjdk.java.net/~gguo/8031085-8u/webrev.00
>>
>> The fix is imperative in product, the original fix is not clean due to
>>   context change, performed jtreg jdk/test/java/time on Linux/x86-64.
> 
> This seems a dangerous change and has been in JDK 8u for a long
> time.?I'm not sure this one is worth fixing.
> 
> It would need a) a CSR (changes public API) b) verification this
> doesn't break TCK. Has that been done?
> 
> Thanks,
> Severin
> 
> 
> 
> .
> 

From gnu.andrew at redhat.com  Fri Mar 12 05:09:40 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 12 Mar 2021 05:09:40 +0000
Subject: OpenJDK 8u292-b06 EA Released
Message-ID: <20210312050940.GC7420@rincewind>

I've made available an early access source bundle for 8u292, based on
the tag jdk8u292-b06:

https://openjdk-sources.osci.io/openjdk8/openjdk8u292-b06-ea.tar.xz

The tarball is accompanied by a digital signature available at:

https://openjdk-sources.osci.io/openjdk8/openjdk8u292-b06-ea.tar.xz.sig

This is signed by our new Red Hat OpenJDK key (openjdk at redhat.com):

PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net)
Fingerprint: CA5F 11C6 CE22 644D 42C6  AC44 92EF 8D39 DC13 168F

SHA256 checksums:

3c5905f1d727e28419304a57e94950db38f9986f1738f58a07ac7af7b5bd759b  openjdk8u292-b06-ea.tar.xz
0c32f0299ab2a3c4de6409cb19bb4d5d7b8ab19ed09bf8e191f5a61ba312a4a0  openjdk8u292-b06-ea.tar.xz.sig

They are listed at
https://openjdk-sources.osci.io/openjdk8/openjdk8u292-b06-ea.sha256

Changes in 8u292-b06:
  - JDK-8259048: (tz) Upgrade time-zone data to tzdata2020f

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 gnu.andrew at redhat.com  Fri Mar 12 05:13:13 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 12 Mar 2021 05:13:13 +0000
Subject: [8u] RFR: 8260356: (tz) Upgrade time-zone data to tzdata2021a
Message-ID: <20210312051313.GD7420@rincewind>

Bug: https://bugs.openjdk.java.net/browse/JDK-8260356
Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8260356/webrev.01/

Usual update for the in-tree tzdata update.

Although I did the update manually from the rearguard version of the
tzdata2021a data, there is no difference between the patch for the
files in make in 11u and those in this 8u patch. The only difference
between the patches as a whole is 8u has the changes duplicated in
the test subdirectory.

Tests for sun.util.calendar and java.time.test all passed on the
patched build.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 dcherepanov at azul.com  Fri Mar 12 08:10:36 2021
From: dcherepanov at azul.com (Dmitry Cherepanov)
Date: Fri, 12 Mar 2021 11:10:36 +0300
Subject: [8u] RFR: 8260356: (tz) Upgrade time-zone data to tzdata2021a
In-Reply-To: <20210312051313.GD7420@rincewind>
References: <20210312051313.GD7420@rincewind>
Message-ID: <d89a05bc-a139-778d-1686-88a93f9f1a3c@azul.com>

Hi Andrew,

Looks good. Thanks.

Dmitry

On 12.03.2021 08:13, Andrew Hughes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8260356
> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8260356/webrev.01/
>
> Usual update for the in-tree tzdata update.
>
> Although I did the update manually from the rearguard version of the
> tzdata2021a data, there is no difference between the patch for the
> files in make in 11u and those in this 8u patch. The only difference
> between the patches as a whole is 8u has the changes duplicated in
> the test subdirectory.
>
> Tests for sun.util.calendar and java.time.test all passed on the
> patched build.
>
> Thanks,



From shade at redhat.com  Fri Mar 12 10:49:46 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 12 Mar 2021 11:49:46 +0100
Subject: [8u] RFR (S) 8042891: Format issues embedded in macros for two g1
 source files
In-Reply-To: <019FCC33-C991-4FF5-9988-865F3948537C@amazon.com>
References: <019FCC33-C991-4FF5-9988-865F3948537C@amazon.com>
Message-ID: <1ae2e9b3-97df-5ffb-b364-e498cbe7ca60@redhat.com>

Thanks, I tagged this for approval.

On 3/3/21 11:22 PM, Hohensee, Paul wrote:
> Lgtm.
> 
> Thanks,
> Paul
> 
> ?-----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Aleksey Shipilev <shade at redhat.com>
> Date: Monday, March 1, 2021 at 10:33 AM
> To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
> Subject: [8u] RFR (S) 8042891: Format issues embedded in macros for two g1 source files
> 
> Original issue:
>     https://bugs.openjdk.java.net/browse/JDK-8042891
>     https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2e360934b0cf
> 
> In our testing, we have seen G1 crashes when it tries to log something, the stack traces leading
> into vnsprintf. I suspect the cause is formatting problems, which are supposed to be resolved by
> this backport.
> 
> There are lots of conflicts when applying the patch, all resolved by hand. Additionally, I built
> with x86_32 and x86_64 with GCC 9, and fixed up a few more formatting warnings. The changes are
> mostly putting p2i() where PTR_FORMAT is expected, matching %u or UINTX_FORMAT where needed, etc.
> 
> 8u variant:
>     https://cr.openjdk.java.net/~shade/8042891/webrev.8u.01/
> 
> Testing: tier1

-- 
Thanks,
-Aleksey


From stooke at redhat.com  Fri Mar 12 13:12:26 2021
From: stooke at redhat.com (Simon Tooke)
Date: Fri, 12 Mar 2021 08:12:26 -0500
Subject: [8u] RFR: 8262864: No debug symbols in image for Windows
 --with-native-debug-symbols=external
In-Reply-To: <5e3b37cc-979a-78df-4a17-3a08e3d468b4@redhat.com>
References: <CAFFhbGM84D=mi2H1emTWiam-Yo29LjqjiHQASov4+AN3bd-tXg@mail.gmail.com>
 <1d1eccc31077996cdb08f1f6e4877df3f8d8c690.camel@redhat.com>
 <CAFFhbGMekTVuW=s4m=h8aAsfp6oK7cpe3LXnvOnZ45kb6QG35A@mail.gmail.com>
 <5e3b37cc-979a-78df-4a17-3a08e3d468b4@redhat.com>
Message-ID: <125ca6d7-b990-80ed-f556-2ba9d261307f@redhat.com>

(usual disclaimer; I am not a reviewer)

 From a comment by Magnus Ihse Bursie on the new issue (8263356), [1] 
this PR (8262864) should not delete the following lines:

-? # for executables. "java" is both a library and executable.
-? ALL_BIN_EXEC_FILES := $(filter-out java.exe, $(notdir $(filter %.exe, 
$(ALL_BIN_LIST))))

As this ensure the debug info for the DLL is copied, by removing 
java.exe from the potential list of debug executables.

I suggest this PR be reworked, and I will also look at closing 8263356 
with an explanation "working as intended"; the proper solutions would 
have been to prefix all JDK DLLs with 'lib' similar to Posix systems, 
but that ship sailed decades ago.

[1] 
https://bugs.openjdk.java.net/browse/JDK-8263356?focusedCommentId=14406720&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14406720

On 2021-03-11 5:27 p.m., Simon Tooke wrote:
>
> On 2021-03-10 5:45 a.m., Andrew Leonard wrote:
>> The issue Simon is referring to I think is at the source of the .pdb
>> generation for java.exe/dll (probably in
>> make/common/NativeCompilation.gmk), since they have the same basename 
>> one
>> is going to overwrite the other...this behavior is separate to this 
>> Image
>> creation copy rules. I've raised a new issue to cover that:
>> https://bugs.openjdk.java.net/browse/JDK-8263356
>
> I have clarified in JBS that this issue is still present in later 
> JDKs, although I've only tested 11u and head.
>
> -Simon
>
> -- 
> Simon Tooke
> Principal developer, Java Platform
> Red Hat Canada, Inc.<https://www.redhat.com>
>


From felix.yang at huawei.com  Mon Mar 15 08:37:42 2021
From: felix.yang at huawei.com (Yangfei (Felix))
Date: Mon, 15 Mar 2021 08:37:42 +0000
Subject: RFR: 8191915: JCK tests produce incorrect results with C2
Message-ID: <DA41BE1DDCA941489001C7FBD7A8820EE8028BA1@dggeml507-mbx.china.huawei.com>

Hi,

  Please review this 8u backport fixing a compatibility issue:

  Original bug: https://bugs.openjdk.java.net/browse/JDK-8191915 
  Original patch: http://hg.openjdk.java.net/jdk/jdk10/rev/4162f740b7bd 
  Webrev for 8u: http://cr.openjdk.java.net/~fyang/8191915-8u/webrev.00/ 

  I am using gcc-7.5 and I find this issue can always be reproduced on both aarch64 and x84_64 linux with the provided jtreg test. 
  Original patch does not apply cleanly after path shuffling, three adaptations for 8u:
  1. Adjusted copyright year update for both mathexactnode.cpp and mathexactnode.hpp;
  2. Adjusted the test command for the jtreg test in the original patch: LongMulOverflowTest.java;
  3. Removed test_mathexact.cpp in the original patch.

  Performed full jtreg test on both aarch64 and x84_64 linux. OK?

Thanks,
Felix

From aph at redhat.com  Mon Mar 15 11:19:55 2021
From: aph at redhat.com (Andrew Haley)
Date: Mon, 15 Mar 2021 11:19:55 +0000
Subject: jdk8u-dev MacOS 10.15+ build environment?
In-Reply-To: <CAFFhbGPPjte_0V5kGxW2bbyodwP6HyR+8acTvv9whR91-sgGdw@mail.gmail.com>
References: <CAFFhbGPPjte_0V5kGxW2bbyodwP6HyR+8acTvv9whR91-sgGdw@mail.gmail.com>
Message-ID: <468297a0-68ef-5e6d-844e-0585391a2b86@redhat.com>

On 3/1/21 2:33 PM, Andrew Leonard wrote:

> I have a Mac OS contribution i've developed and tested at AdoptOpenJDK, I
> would like to contribute it upstream to jdk8u-dev, unfortunately the
> jdk8u-dev supported build platform is MacOS 10.7. Is there a method people
> use to build & test their contributions if you don't have a MacOS 10.7
> environment? The AdoptOpenJDK jdk8u base has patches to allow building
> jdk8u with Xcode 11.5 on 10.15+..

Let's get those patches in, then. Who contributed them? We'd
need to get them to contribute to 8u.

> How do others approach Mac contributions?



-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From vkempik at azul.com  Mon Mar 15 12:02:11 2021
From: vkempik at azul.com (Vladimir Kempik)
Date: Mon, 15 Mar 2021 12:02:11 +0000
Subject: jdk8u-dev MacOS 10.15+ build environment?
In-Reply-To: <CAFFhbGPPjte_0V5kGxW2bbyodwP6HyR+8acTvv9whR91-sgGdw@mail.gmail.com>
References: <CAFFhbGPPjte_0V5kGxW2bbyodwP6HyR+8acTvv9whR91-sgGdw@mail.gmail.com>
Message-ID: <D42FAF12-9E33-4D4E-9B97-D75763BFD4DC@azul.com>

To build openjdk8 on macos currently you would need:
macos 10.9 + xcode 4.6.x + 10.9 macos.sdk from xcode5/6.
Copy 10.9 sdk to xcode 4.6.x then use it to build openjdk8.
It still may have caveats as the upstream is not tested against macos.

> 1 ????? 2021 ?., ? 17:33, Andrew Leonard <anleonar at redhat.com> ???????(?):
> 
> Hi,
> I have a Mac OS contribution i've developed and tested at AdoptOpenJDK, I
> would like to contribute it upstream to jdk8u-dev, unfortunately the
> jdk8u-dev supported build platform is MacOS 10.7. Is there a method people
> use to build & test their contributions if you don't have a MacOS 10.7
> environment? The AdoptOpenJDK jdk8u base has patches to allow building
> jdk8u with Xcode 11.5 on 10.15+..
> How do others approach Mac contributions?
> Thanks
> Andrew


From stooke at redhat.com  Mon Mar 15 12:24:11 2021
From: stooke at redhat.com (Simon Tooke)
Date: Mon, 15 Mar 2021 08:24:11 -0400
Subject: jdk8u-dev MacOS 10.15+ build environment?
In-Reply-To: <468297a0-68ef-5e6d-844e-0585391a2b86@redhat.com>
References: <CAFFhbGPPjte_0V5kGxW2bbyodwP6HyR+8acTvv9whR91-sgGdw@mail.gmail.com>
 <468297a0-68ef-5e6d-844e-0585391a2b86@redhat.com>
Message-ID: <201a3dd8-59fd-86d6-949f-8bdeae66c80c@redhat.com>


On 2021-03-15 7:19 a.m., Andrew Haley wrote:
> On 3/1/21 2:33 PM, Andrew Leonard wrote:
>
>> I have a Mac OS contribution i've developed and tested at AdoptOpenJDK, I
>> would like to contribute it upstream to jdk8u-dev, unfortunately the
>> jdk8u-dev supported build platform is MacOS 10.7. Is there a method people
>> use to build & test their contributions if you don't have a MacOS 10.7
>> environment? The AdoptOpenJDK jdk8u base has patches to allow building
>> jdk8u with Xcode 11.5 on 10.15+..
> Let's get those patches in, then. Who contributed them? We'd
> need to get them to contribute to 8u.

Almost all the patches are backports; as they were not bugfixes per se, 
they rarely got approved.

https://github.com/stooke/jdk8u-xcode10? see especially the patch 
directories.

-Simon

>
>> How do others approach Mac contributions?
>
>


From aph at redhat.com  Mon Mar 15 13:28:20 2021
From: aph at redhat.com (Andrew Haley)
Date: Mon, 15 Mar 2021 13:28:20 +0000
Subject: jdk8u-dev MacOS 10.15+ build environment?
In-Reply-To: <201a3dd8-59fd-86d6-949f-8bdeae66c80c@redhat.com>
References: <CAFFhbGPPjte_0V5kGxW2bbyodwP6HyR+8acTvv9whR91-sgGdw@mail.gmail.com>
 <468297a0-68ef-5e6d-844e-0585391a2b86@redhat.com>
 <201a3dd8-59fd-86d6-949f-8bdeae66c80c@redhat.com>
Message-ID: <502effef-64b2-2878-b37c-b7f515b1c48f@redhat.com>

On 3/15/21 12:24 PM, Simon Tooke wrote:
> 
> On 2021-03-15 7:19 a.m., Andrew Haley wrote:
>> On 3/1/21 2:33 PM, Andrew Leonard wrote:
>>
>>> I have a Mac OS contribution i've developed and tested at AdoptOpenJDK, I
>>> would like to contribute it upstream to jdk8u-dev, unfortunately the
>>> jdk8u-dev supported build platform is MacOS 10.7. Is there a method people
>>> use to build & test their contributions if you don't have a MacOS 10.7
>>> environment? The AdoptOpenJDK jdk8u base has patches to allow building
>>> jdk8u with Xcode 11.5 on 10.15+..
>> Let's get those patches in, then. Who contributed them? We'd
>> need to get them to contribute to 8u.
> 
> Almost all the patches are backports; as they were not bugfixes per se, 
> they rarely got approved.

The rules about backports to new environments tend to be more
relaxed than general enhancements. We want JDK 8u to continue
to be relevant for as long as it is supported; that's why we
allowed AArch64 support to be imported into 8u. So, let's get
this done.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From adfarley at redhat.com  Mon Mar 15 15:29:47 2021
From: adfarley at redhat.com (Adam Farley)
Date: Mon, 15 Mar 2021 15:29:47 +0000
Subject: RFR: 8263099: TimSortStackSize2.java throws OOM when using
 -XX:-UseCompressedOops
In-Reply-To: <228D8358-EC21-453B-99CF-B7DB2376C826@amazon.com>
References: <228D8358-EC21-453B-99CF-B7DB2376C826@amazon.com>
Message-ID: <CANZLDatsqxKx=pOMFR1heF3pA55CXD=ZSbMF3VXSLjvwWsYy3A@mail.gmail.com>

Hi Paul,

Looks good to me, and the test passes without an oom too. Thanks to you as
well for putting the change sets together.

Based on the steps listed here, I think that we've completed 1-5, and that
the next step is 6.

https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix

Will update the three bugs whose changesets we're using (as per step 6), as
well as the 8263099 bug with links to the other 3.

Best Regards

Adam Farley
Software Developer
Red Hat


On Wed, Mar 10, 2021 at 9:06 PM Hohensee, Paul <hohensee at amazon.com> wrote:

> Hi, Adam, thanks for taking this on.
>
>
>
> I believe the general 8u Maintainer consensus is against ?bulk? backports
> such as the one you propose, and in favor of doing a backport series, so we
> don?t lose history in the target jdk. I found only three changesets to
> backport.
>
>
>
> 8220613: java/util/Arrays/TimSortStackSize2.java times out with fastdebug
> build. Can?t backport because 8u doesn?t support vm.debug.
>
>
>
> 8199265: java/util/Arrays/TimSortStackSize2.java fails with OOM.
>
> Webrev in https://cr.openjdk.java.net/~phh/8199265/webrev.8u.jdk.01/
>
>
>
> 8201766: Mark TimSortStackSize2.java as intermittently failing. N/A
>
>
>
> 8190679: java/util/Arrays/TimSortStackSize2.java fails with "Initial heap
> size set to a larger value than the maximum heap size".
>
> Webrev in https://cr.openjdk.java.net/~phh/8190679/webrev.8u.jdk.01/
>
>
>
> 8149391: Fix module dependences in java/util tests. N/A
>
>
>
> 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests.
> Incorporated into 8075071 backport in order to make it work.
>
>
>
> 8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java heap space: MaxHeap
> shrinked by MaxRAMFraction.
>
> Webrev in https://cr.openjdk.java.net/~phh/8075071/webrev.8u.jdk.03/
>
>
>
> I applied the above webrevs for 8075071, 8190679, and 8199265 in order.
> The result was your patch, except that I included ?@key intermittent? in
> the 8199265 patch.
>
>
>
> Thanks,
>
> Paul
>
>
>
> *From: *Adam Farley <adfarley at redhat.com>
> *Date: *Monday, March 8, 2021 at 10:00 AM
> *To: *"Hohensee, Paul" <hohensee at amazon.com>
> *Cc: *"jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
> *Subject: *RE: RFR: 8263099: TimSortStackSize2.java throws OOM when using
> -XX:-UseCompressedOops
>
>
>
> Hi Paul,
>
> I merged the other four change sets, however 3 of the 4 were not clean
> backports.
>
>
>
> Mainly:
>
>
>
> 1) /../../test/lib causes errors (and, sans ".."s, is the wrong dir for
> that lib on jdk8 anyway).
>
> 2) ProcessTools lacks executeTestJava(String...), though executeTestJvm
> seems to do the same thing.
>
> 3) TEST.ROOT seems to lack the section required for the vm.debug change.
>
>
>
> I don't think any of those is a major loss though, so I added the parts of
> the change sets I thought were clean.
>
>
>
>
> https://github.com/AdoptOpenJDK/openjdk-jdk8u/compare/master...adamfarley:oom_upstream_merge_fix
>
>
>
> Your thoughts?
>
>
>
> Best Regards
>
>
>
> Adam Farley
>
> Software Developer
>
> Red Hat
>
>
>
>
>
> On Fri, Mar 5, 2021 at 7:19 PM Hohensee, Paul <hohensee at amazon.com> wrote:
>
> "hg log" says that this test has had quite a few problems since JDK 8.
> These are the post JDK 8 ones.
>
> $ hg log test/jdk/java/util/Arrays/TimSortStackSize2.java # after repo
> consolidation
>
> changeset:   53086:a15200acedcd
> user:        andrew
> date:        Tue Mar 31 08:08:44 2020 +0100
> summary:     8220613: java/util/Arrays/TimSortStackSize2.java times out
> with fastdebug build
>
> changeset:   50849:9b0e2937fac5
> user:        iignatyev
> date:        Wed Jun 27 13:43:52 2018 -0700
> summary:     8199265: java/util/Arrays/TimSortStackSize2.java fails with
> OOM
>
> changeset:   49820:663f5d90f0e8
> user:        darcy
> date:        Wed Apr 18 10:03:49 2018 -0700
> summary:     8201766: Mark TimSortStackSize2.java as intermittently failing
>
> changeset:   49178:1836bf0c820a
> user:        iignatyev
> date:        Tue Feb 27 21:29:08 2018 -0800
> summary:     8190679: java/util/Arrays/TimSortStackSize2.java fails with
> "Initial heap size set to a larger value than the maximum heap size"
>
> changeset:   47216:71c04702a3d5
> user:        erikj
> date:        Tue Sep 12 19:03:39 2017 +0200
> summary:     8187443: Forest Consolidation: Move files to unified layout
>
> % hg log jdk/test/java/util/Arrays/TimSortStackSize2.java # before repo
> consolidation
>
> changeset:   35768:7066da300a08
> parent:      35739:db483b34fa71
> user:        shurailine
> date:        Mon Feb 08 18:14:48 2016 -0800
> summary:     8149391: Fix module dependences in java/util tests
>
> changeset:   33832:7dde7a271492
> parent:      33659:400008d8de8c
> user:        cjplummer
> date:        Thu Oct 29 12:02:53 2015 -0700
> summary:     8140189: [TESTBUG] Get rid of "@library /../../test/lib" in
> jtreg tests
>
> changeset:   29613:da0ff5cf6e75
> user:        lpriima
> date:        Tue Mar 24 03:46:57 2015 -0400
> summary:     8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java heap
> space: MaxHeap shrinked by MaxRAMFraction
>
> If at all possible, I'd prefer to see these backported, excepting 8201766,
> 8187443, 8149391, and probably 8140189. The backports should apply pretty
> cleanly if done in order.
>
> Thanks,
> Paul
>
> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Adam
> Farley <adfarley at redhat.com>
> Date: Friday, March 5, 2021 at 8:16 AM
> To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
> Subject: RFR: 8263099: TimSortStackSize2.java throws OOM when using
> -XX:-UseCompressedOops
>
> Hi All,
>
> Simple problem, which is solved on later jdk versions by simply increasing
> the heap.
>
> Request reviews and sponsor for this change.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8263099
>
> Best Regards
>
> Adam Farley
> Software Developer
> Red Hat
>
>

From hohensee at amazon.com  Mon Mar 15 16:22:23 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 15 Mar 2021 16:22:23 +0000
Subject: RFR: 8263099: TimSortStackSize2.java throws OOM when using
 -XX:-UseCompressedOops
Message-ID: <6A067603-AB9A-4D83-9D1C-C80F31184FB9@amazon.com>

That?s the 11u wiki, the 8u wiki is https://wiki.openjdk.java.net/display/jdk8u, and it?s step 13. :) We might need another review, since both of us worked on the patches. Anyone?

Thanks,
Paul

From: Adam Farley <adfarley at redhat.com>
Date: Monday, March 15, 2021 at 8:30 AM
To: "Hohensee, Paul" <hohensee at amazon.com>
Cc: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: RE: RFR: 8263099: TimSortStackSize2.java throws OOM when using -XX:-UseCompressedOops

Hi Paul,

Looks good to me, and the test passes without an oom too. Thanks to you as well for putting the change sets together.

Based on the steps listed here, I think that we've completed 1-5, and that the next step is 6.

https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix

Will update the three bugs whose changesets we're using (as per step 6), as well as the 8263099 bug with links to the other 3.

Best Regards

Adam Farley
Software Developer
Red Hat


On Wed, Mar 10, 2021 at 9:06 PM Hohensee, Paul <hohensee at amazon.com<mailto:hohensee at amazon.com>> wrote:
Hi, Adam, thanks for taking this on.

I believe the general 8u Maintainer consensus is against ?bulk? backports such as the one you propose, and in favor of doing a backport series, so we don?t lose history in the target jdk. I found only three changesets to backport.

8220613: java/util/Arrays/TimSortStackSize2.java times out with fastdebug build. Can?t backport because 8u doesn?t support vm.debug.

8199265: java/util/Arrays/TimSortStackSize2.java fails with OOM.
Webrev in https://cr.openjdk.java.net/~phh/8199265/webrev.8u.jdk.01/

8201766: Mark TimSortStackSize2.java as intermittently failing. N/A

8190679: java/util/Arrays/TimSortStackSize2.java fails with "Initial heap size set to a larger value than the maximum heap size".
Webrev in https://cr.openjdk.java.net/~phh/8190679/webrev.8u.jdk.01/

8149391: Fix module dependences in java/util tests. N/A

8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests. Incorporated into 8075071 backport in order to make it work.

8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java heap space: MaxHeap shrinked by MaxRAMFraction.
Webrev in https://cr.openjdk.java.net/~phh/8075071/webrev.8u.jdk.03/

I applied the above webrevs for 8075071, 8190679, and 8199265 in order. The result was your patch, except that I included ?@key intermittent? in the 8199265 patch.

Thanks,
Paul

From: Adam Farley <adfarley at redhat.com<mailto:adfarley at redhat.com>>
Date: Monday, March 8, 2021 at 10:00 AM
To: "Hohensee, Paul" <hohensee at amazon.com<mailto:hohensee at amazon.com>>
Cc: "jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>" <jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>>
Subject: RE: RFR: 8263099: TimSortStackSize2.java throws OOM when using -XX:-UseCompressedOops

Hi Paul,
I merged the other four change sets, however 3 of the 4 were not clean backports.

Mainly:

1) /../../test/lib causes errors (and, sans ".."s, is the wrong dir for that lib on jdk8 anyway).
2) ProcessTools lacks executeTestJava(String...), though executeTestJvm seems to do the same thing.
3) TEST.ROOT seems to lack the section required for the vm.debug change.

I don't think any of those is a major loss though, so I added the parts of the change sets I thought were clean.

https://github.com/AdoptOpenJDK/openjdk-jdk8u/compare/master...adamfarley:oom_upstream_merge_fix

Your thoughts?

Best Regards

Adam Farley
Software Developer
Red Hat


On Fri, Mar 5, 2021 at 7:19 PM Hohensee, Paul <hohensee at amazon.com<mailto:hohensee at amazon.com>> wrote:
"hg log" says that this test has had quite a few problems since JDK 8. These are the post JDK 8 ones.

$ hg log test/jdk/java/util/Arrays/TimSortStackSize2.java # after repo consolidation

changeset:   53086:a15200acedcd
user:        andrew
date:        Tue Mar 31 08:08:44 2020 +0100
summary:     8220613: java/util/Arrays/TimSortStackSize2.java times out with fastdebug build

changeset:   50849:9b0e2937fac5
user:        iignatyev
date:        Wed Jun 27 13:43:52 2018 -0700
summary:     8199265: java/util/Arrays/TimSortStackSize2.java fails with OOM

changeset:   49820:663f5d90f0e8
user:        darcy
date:        Wed Apr 18 10:03:49 2018 -0700
summary:     8201766: Mark TimSortStackSize2.java as intermittently failing

changeset:   49178:1836bf0c820a
user:        iignatyev
date:        Tue Feb 27 21:29:08 2018 -0800
summary:     8190679: java/util/Arrays/TimSortStackSize2.java fails with "Initial heap size set to a larger value than the maximum heap size"

changeset:   47216:71c04702a3d5
user:        erikj
date:        Tue Sep 12 19:03:39 2017 +0200
summary:     8187443: Forest Consolidation: Move files to unified layout

% hg log jdk/test/java/util/Arrays/TimSortStackSize2.java # before repo consolidation

changeset:   35768:7066da300a08
parent:      35739:db483b34fa71
user:        shurailine
date:        Mon Feb 08 18:14:48 2016 -0800
summary:     8149391: Fix module dependences in java/util tests

changeset:   33832:7dde7a271492
parent:      33659:400008d8de8c
user:        cjplummer
date:        Thu Oct 29 12:02:53 2015 -0700
summary:     8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests

changeset:   29613:da0ff5cf6e75
user:        lpriima
date:        Tue Mar 24 03:46:57 2015 -0400
summary:     8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java heap space: MaxHeap shrinked by MaxRAMFraction

If at all possible, I'd prefer to see these backported, excepting 8201766, 8187443, 8149391, and probably 8140189. The backports should apply pretty cleanly if done in order.

Thanks,
Paul

-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net<mailto:jdk8u-dev-retn at openjdk.java.net>> on behalf of Adam Farley <adfarley at redhat.com<mailto:adfarley at redhat.com>>
Date: Friday, March 5, 2021 at 8:16 AM
To: "jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>" <jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>>
Subject: RFR: 8263099: TimSortStackSize2.java throws OOM when using -XX:-UseCompressedOops

Hi All,

Simple problem, which is solved on later jdk versions by simply increasing
the heap.

Request reviews and sponsor for this change.

Bug: https://bugs.openjdk.java.net/browse/JDK-8263099

Best Regards

Adam Farley
Software Developer
Red Hat

From zgu at redhat.com  Mon Mar 15 17:20:49 2021
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 15 Mar 2021 13:20:49 -0400
Subject: [8u] RFR 8263601: TEST_BUG: remove ActivationLibrary.DestroyThread
 and have callers call rmid.destroy() instead
Message-ID: <6b7af6c9-3f2e-5141-e8b4-72e147bc38e4@redhat.com>

Hi,

I would like to backport this patch to 8u for parity with Oracle 8u301.

Original bug: https://bugs.openjdk.java.net/browse/JDK-8035000
Original patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/1b599b4755bd

The original patch applies cleanly.

However, patched RMID.java uses waitFor(long timeout) method, that was 
introduced by JDK-8032050 [1] and it is not backported to 8u. Therefore, 
I propose backport this specific function from JDK-8032050 with this patch.


--- old/test/java/rmi/testlibrary/JavaVM.java	2021-03-15 
13:03:32.298020591 -0400
+++ new/test/java/rmi/testlibrary/JavaVM.java	2021-03-15 
13:03:32.157020372 -0400
@@ -26,6 +26,7 @@
  import java.io.OutputStream;
  import java.util.Arrays;
  import java.util.StringTokenizer;
+import java.util.concurrent.TimeoutException;

  /**
   * RMI regression test utility class that uses Runtime.exec to spawn a
@@ -183,6 +184,39 @@
          errPipe.join();
          return status;
      }
+    /**
+     * Causes the current thread to wait the vm process to exit, if 
necessary,
+     * wait until the vm process has terminated, or the specified 
waiting time
+     * elapses. Release allocated input/output after vm process has 
terminated.
+     * @param timeout the maximum milliseconds to wait.
+     * @return exit value for vm process.
+     * @throws InterruptedException if the current thread is interrupted
+     *         while waiting.
+     * @throws TimeoutException if subprocess does not end after timeout
+     *         milliseconds passed
+     */
+     public int waitFor(long timeout)
+            throws InterruptedException, TimeoutException {
+         if (vm == null)
+             throw new IllegalStateException("can't wait for JavaVM 
that isn't running");
+         long startTime = System.currentTimeMillis();
+         long rem = timeout;
+
+         do {
+            try {
+                int status = vm.exitValue();
+                outPipe.join();
+                errPipe.join();
+                return status;
+            } catch (IllegalThreadStateException ex) {
+                if (rem > 0) {
+                    Thread.sleep(Math.min(rem, 100));
+                }
+            }
+            rem = timeout - (System.currentTimeMillis() - startTime);
+         } while (rem > 0);
+         throw new TimeoutException();
+     }

      /**
       * Starts the subprocess, waits for it to exit, and returns its 
exit status.


Thanks,

-Zhengyu

[1] https://bugs.openjdk.java.net/browse/JDK-8032050


From volker.simonis at gmail.com  Mon Mar 15 17:47:04 2021
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 15 Mar 2021 18:47:04 +0100
Subject: RFR: 8263099: TimSortStackSize2.java throws OOM when using
 -XX:-UseCompressedOops
In-Reply-To: <228D8358-EC21-453B-99CF-B7DB2376C826@amazon.com>
References: <228D8358-EC21-453B-99CF-B7DB2376C826@amazon.com>
Message-ID: <CA+3eh10YHTsesK5gKG5yOpyyUgCd56c4vwfrUTqKoK=1uKvL1A@mail.gmail.com>

On Wed, Mar 10, 2021 at 10:06 PM Hohensee, Paul <hohensee at amazon.com> wrote:
>
> Hi, Adam, thanks for taking this on.
>
> I believe the general 8u Maintainer consensus is against ?bulk? backports such as the one you propose, and in favor of doing a backport series, so we don?t lose history in the target jdk. I found only three changesets to backport.
>
> 8220613: java/util/Arrays/TimSortStackSize2.java times out with fastdebug build. Can?t backport because 8u doesn?t support vm.debug.
>
> 8199265: java/util/Arrays/TimSortStackSize2.java fails with OOM.
> Webrev in https://cr.openjdk.java.net/~phh/8199265/webrev.8u.jdk.01/
>

LGTM.

> 8201766: Mark TimSortStackSize2.java as intermittently failing. N/A
>
> 8190679: java/util/Arrays/TimSortStackSize2.java fails with "Initial heap size set to a larger value than the maximum heap size".
> Webrev in https://cr.openjdk.java.net/~phh/8190679/webrev.8u.jdk.01/
>

LGTM.

> 8149391: Fix module dependences in java/util tests. N/A
>
> 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests. Incorporated into 8075071 backport in order to make it work.
>
> 8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java heap space: MaxHeap shrinked by MaxRAMFraction.
> Webrev in https://cr.openjdk.java.net/~phh/8075071/webrev.8u.jdk.03/
>

LGTM.

All the three downports 8075071, 8190679, and 8199265 look good to me.

Thank you and best regards,
Volker

> I applied the above webrevs for 8075071, 8190679, and 8199265 in order. The result was your patch, except that I included ?@key intermittent? in the 8199265 patch.
>
> Thanks,
> Paul
>
> From: Adam Farley <adfarley at redhat.com>
> Date: Monday, March 8, 2021 at 10:00 AM
> To: "Hohensee, Paul" <hohensee at amazon.com>
> Cc: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
> Subject: RE: RFR: 8263099: TimSortStackSize2.java throws OOM when using -XX:-UseCompressedOops
>
> Hi Paul,
> I merged the other four change sets, however 3 of the 4 were not clean backports.
>
> Mainly:
>
> 1) /../../test/lib causes errors (and, sans ".."s, is the wrong dir for that lib on jdk8 anyway).
> 2) ProcessTools lacks executeTestJava(String...), though executeTestJvm seems to do the same thing.
> 3) TEST.ROOT seems to lack the section required for the vm.debug change.
>
> I don't think any of those is a major loss though, so I added the parts of the change sets I thought were clean.
>
> https://github.com/AdoptOpenJDK/openjdk-jdk8u/compare/master...adamfarley:oom_upstream_merge_fix
>
> Your thoughts?
>
> Best Regards
>
> Adam Farley
> Software Developer
> Red Hat
>
>
> On Fri, Mar 5, 2021 at 7:19 PM Hohensee, Paul <hohensee at amazon.com<mailto:hohensee at amazon.com>> wrote:
> "hg log" says that this test has had quite a few problems since JDK 8. These are the post JDK 8 ones.
>
> $ hg log test/jdk/java/util/Arrays/TimSortStackSize2.java # after repo consolidation
>
> changeset:   53086:a15200acedcd
> user:        andrew
> date:        Tue Mar 31 08:08:44 2020 +0100
> summary:     8220613: java/util/Arrays/TimSortStackSize2.java times out with fastdebug build
>
> changeset:   50849:9b0e2937fac5
> user:        iignatyev
> date:        Wed Jun 27 13:43:52 2018 -0700
> summary:     8199265: java/util/Arrays/TimSortStackSize2.java fails with OOM
>
> changeset:   49820:663f5d90f0e8
> user:        darcy
> date:        Wed Apr 18 10:03:49 2018 -0700
> summary:     8201766: Mark TimSortStackSize2.java as intermittently failing
>
> changeset:   49178:1836bf0c820a
> user:        iignatyev
> date:        Tue Feb 27 21:29:08 2018 -0800
> summary:     8190679: java/util/Arrays/TimSortStackSize2.java fails with "Initial heap size set to a larger value than the maximum heap size"
>
> changeset:   47216:71c04702a3d5
> user:        erikj
> date:        Tue Sep 12 19:03:39 2017 +0200
> summary:     8187443: Forest Consolidation: Move files to unified layout
>
> % hg log jdk/test/java/util/Arrays/TimSortStackSize2.java # before repo consolidation
>
> changeset:   35768:7066da300a08
> parent:      35739:db483b34fa71
> user:        shurailine
> date:        Mon Feb 08 18:14:48 2016 -0800
> summary:     8149391: Fix module dependences in java/util tests
>
> changeset:   33832:7dde7a271492
> parent:      33659:400008d8de8c
> user:        cjplummer
> date:        Thu Oct 29 12:02:53 2015 -0700
> summary:     8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests
>
> changeset:   29613:da0ff5cf6e75
> user:        lpriima
> date:        Tue Mar 24 03:46:57 2015 -0400
> summary:     8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java heap space: MaxHeap shrinked by MaxRAMFraction
>
> If at all possible, I'd prefer to see these backported, excepting 8201766, 8187443, 8149391, and probably 8140189. The backports should apply pretty cleanly if done in order.
>
> Thanks,
> Paul
>
> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net<mailto:jdk8u-dev-retn at openjdk.java.net>> on behalf of Adam Farley <adfarley at redhat.com<mailto:adfarley at redhat.com>>
> Date: Friday, March 5, 2021 at 8:16 AM
> To: "jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>" <jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>>
> Subject: RFR: 8263099: TimSortStackSize2.java throws OOM when using -XX:-UseCompressedOops
>
> Hi All,
>
> Simple problem, which is solved on later jdk versions by simply increasing
> the heap.
>
> Request reviews and sponsor for this change.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8263099
>
> Best Regards
>
> Adam Farley
> Software Developer
> Red Hat

From hohensee at amazon.com  Mon Mar 15 17:53:02 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 15 Mar 2021 17:53:02 +0000
Subject: RFR: 8263099: TimSortStackSize2.java throws OOM when using
 -XX:-UseCompressedOops
Message-ID: <6C5D18DD-7C60-4E36-A0DC-CA382C1A683A@amazon.com>

Thanks, Volker!

?-----Original Message-----
From: Volker Simonis <volker.simonis at gmail.com>
Date: Monday, March 15, 2021 at 10:47 AM
To: "Hohensee, Paul" <hohensee at amazon.com>
Cc: Adam Farley <adfarley at redhat.com>, "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: RE: RFR: 8263099: TimSortStackSize2.java throws OOM when using -XX:-UseCompressedOops

On Wed, Mar 10, 2021 at 10:06 PM Hohensee, Paul <hohensee at amazon.com> wrote:
>
> Hi, Adam, thanks for taking this on.
>
> I believe the general 8u Maintainer consensus is against ?bulk? backports such as the one you propose, and in favor of doing a backport series, so we don?t lose history in the target jdk. I found only three changesets to backport.
>
> 8220613: java/util/Arrays/TimSortStackSize2.java times out with fastdebug build. Can?t backport because 8u doesn?t support vm.debug.
>
> 8199265: java/util/Arrays/TimSortStackSize2.java fails with OOM.
> Webrev in https://cr.openjdk.java.net/~phh/8199265/webrev.8u.jdk.01/
>

LGTM.

> 8201766: Mark TimSortStackSize2.java as intermittently failing. N/A
>
> 8190679: java/util/Arrays/TimSortStackSize2.java fails with "Initial heap size set to a larger value than the maximum heap size".
> Webrev in https://cr.openjdk.java.net/~phh/8190679/webrev.8u.jdk.01/
>

LGTM.

> 8149391: Fix module dependences in java/util tests. N/A
>
> 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests. Incorporated into 8075071 backport in order to make it work.
>
> 8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java heap space: MaxHeap shrinked by MaxRAMFraction.
> Webrev in https://cr.openjdk.java.net/~phh/8075071/webrev.8u.jdk.03/
>

LGTM.

All the three downports 8075071, 8190679, and 8199265 look good to me.

Thank you and best regards,
Volker

> I applied the above webrevs for 8075071, 8190679, and 8199265 in order. The result was your patch, except that I included ?@key intermittent? in the 8199265 patch.
>
> Thanks,
> Paul
>
> From: Adam Farley <adfarley at redhat.com>
> Date: Monday, March 8, 2021 at 10:00 AM
> To: "Hohensee, Paul" <hohensee at amazon.com>
> Cc: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
> Subject: RE: RFR: 8263099: TimSortStackSize2.java throws OOM when using -XX:-UseCompressedOops
>
> Hi Paul,
> I merged the other four change sets, however 3 of the 4 were not clean backports.
>
> Mainly:
>
> 1) /../../test/lib causes errors (and, sans ".."s, is the wrong dir for that lib on jdk8 anyway).
> 2) ProcessTools lacks executeTestJava(String...), though executeTestJvm seems to do the same thing.
> 3) TEST.ROOT seems to lack the section required for the vm.debug change.
>
> I don't think any of those is a major loss though, so I added the parts of the change sets I thought were clean.
>
> https://github.com/AdoptOpenJDK/openjdk-jdk8u/compare/master...adamfarley:oom_upstream_merge_fix
>
> Your thoughts?
>
> Best Regards
>
> Adam Farley
> Software Developer
> Red Hat
>
>
> On Fri, Mar 5, 2021 at 7:19 PM Hohensee, Paul <hohensee at amazon.com<mailto:hohensee at amazon.com>> wrote:
> "hg log" says that this test has had quite a few problems since JDK 8. These are the post JDK 8 ones.
>
> $ hg log test/jdk/java/util/Arrays/TimSortStackSize2.java # after repo consolidation
>
> changeset:   53086:a15200acedcd
> user:        andrew
> date:        Tue Mar 31 08:08:44 2020 +0100
> summary:     8220613: java/util/Arrays/TimSortStackSize2.java times out with fastdebug build
>
> changeset:   50849:9b0e2937fac5
> user:        iignatyev
> date:        Wed Jun 27 13:43:52 2018 -0700
> summary:     8199265: java/util/Arrays/TimSortStackSize2.java fails with OOM
>
> changeset:   49820:663f5d90f0e8
> user:        darcy
> date:        Wed Apr 18 10:03:49 2018 -0700
> summary:     8201766: Mark TimSortStackSize2.java as intermittently failing
>
> changeset:   49178:1836bf0c820a
> user:        iignatyev
> date:        Tue Feb 27 21:29:08 2018 -0800
> summary:     8190679: java/util/Arrays/TimSortStackSize2.java fails with "Initial heap size set to a larger value than the maximum heap size"
>
> changeset:   47216:71c04702a3d5
> user:        erikj
> date:        Tue Sep 12 19:03:39 2017 +0200
> summary:     8187443: Forest Consolidation: Move files to unified layout
>
> % hg log jdk/test/java/util/Arrays/TimSortStackSize2.java # before repo consolidation
>
> changeset:   35768:7066da300a08
> parent:      35739:db483b34fa71
> user:        shurailine
> date:        Mon Feb 08 18:14:48 2016 -0800
> summary:     8149391: Fix module dependences in java/util tests
>
> changeset:   33832:7dde7a271492
> parent:      33659:400008d8de8c
> user:        cjplummer
> date:        Thu Oct 29 12:02:53 2015 -0700
> summary:     8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests
>
> changeset:   29613:da0ff5cf6e75
> user:        lpriima
> date:        Tue Mar 24 03:46:57 2015 -0400
> summary:     8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java heap space: MaxHeap shrinked by MaxRAMFraction
>
> If at all possible, I'd prefer to see these backported, excepting 8201766, 8187443, 8149391, and probably 8140189. The backports should apply pretty cleanly if done in order.
>
> Thanks,
> Paul
>
> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net<mailto:jdk8u-dev-retn at openjdk.java.net>> on behalf of Adam Farley <adfarley at redhat.com<mailto:adfarley at redhat.com>>
> Date: Friday, March 5, 2021 at 8:16 AM
> To: "jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>" <jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>>
> Subject: RFR: 8263099: TimSortStackSize2.java throws OOM when using -XX:-UseCompressedOops
>
> Hi All,
>
> Simple problem, which is solved on later jdk versions by simply increasing
> the heap.
>
> Request reviews and sponsor for this change.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8263099
>
> Best Regards
>
> Adam Farley
> Software Developer
> Red Hat


From shade at redhat.com  Mon Mar 15 18:00:48 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 15 Mar 2021 19:00:48 +0100
Subject: [8u] RFR (XS) 8260236: better init AnnotationCollector
 _contended_group
Message-ID: <e82dc969-be06-1ae4-96b5-f4b774f9f356@redhat.com>

Original fix:
   https://bugs.openjdk.java.net/browse/JDK-8260236
   https://github.com/openjdk/jdk/commit/fd2641ed

Unfortunately, this does not apply to 8u cleanly, because the AnnotationProcessor is still in .hpp 
in 8u.

Therefore, 8u variant is:

diff -r b0825e3772d3 src/share/vm/classfile/classFileParser.hpp
--- a/src/share/vm/classfile/classFileParser.hpp        Mon Apr 20 13:34:04 2015 +0200
+++ b/src/share/vm/classfile/classFileParser.hpp        Mon Mar 15 18:59:42 2021 +0100
@@ -1,7 +1,7 @@
  /*
- * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 1997, 2021, Oracle and/or its affiliates. All rights reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
   * under the terms of the GNU General Public License version 2 only, as
   * published by the Free Software Foundation.
@@ -137,11 +137,11 @@
      const Location _location;
      int _annotations_present;
      u2 _contended_group;

      AnnotationCollector(Location location)
-    : _location(location), _annotations_present(0)
+    : _location(location), _annotations_present(0), _contended_group(0)
      {
        assert((int)_annotation_LIMIT <= (int)sizeof(_annotations_present) * BitsPerByte, "");
      }
      // If this annotation name has an ID, report it (or _none).
      ID annotation_index(ClassLoaderData* loader_data, Symbol* name);


Testing: Linux x86_64 build

-- 
Thanks,
-Aleksey


From adfarley at redhat.com  Mon Mar 15 18:01:04 2021
From: adfarley at redhat.com (Adam Farley)
Date: Mon, 15 Mar 2021 18:01:04 +0000
Subject: RFR: 8263099: TimSortStackSize2.java throws OOM when using
 -XX:-UseCompressedOops
In-Reply-To: <6C5D18DD-7C60-4E36-A0DC-CA382C1A683A@amazon.com>
References: <6C5D18DD-7C60-4E36-A0DC-CA382C1A683A@amazon.com>
Message-ID: <CANZLDat_UwA0qE0uGW5GCzcxB+p8j1B9qTMc7MEJkxgP9EHi_w@mail.gmail.com>

Thanks Volker, and also to Paul over the wiki link. :)

Best Regards

Adam Farley
Software Developer
Red Hat


On Mon, Mar 15, 2021 at 5:53 PM Hohensee, Paul <hohensee at amazon.com> wrote:

> Thanks, Volker!
>
> ?-----Original Message-----
> From: Volker Simonis <volker.simonis at gmail.com>
> Date: Monday, March 15, 2021 at 10:47 AM
> To: "Hohensee, Paul" <hohensee at amazon.com>
> Cc: Adam Farley <adfarley at redhat.com>, "jdk8u-dev at openjdk.java.net" <
> jdk8u-dev at openjdk.java.net>
> Subject: RE: RFR: 8263099: TimSortStackSize2.java throws OOM when using
> -XX:-UseCompressedOops
>
> On Wed, Mar 10, 2021 at 10:06 PM Hohensee, Paul <hohensee at amazon.com>
> wrote:
> >
> > Hi, Adam, thanks for taking this on.
> >
> > I believe the general 8u Maintainer consensus is against ?bulk?
> backports such as the one you propose, and in favor of doing a backport
> series, so we don?t lose history in the target jdk. I found only three
> changesets to backport.
> >
> > 8220613: java/util/Arrays/TimSortStackSize2.java times out with
> fastdebug build. Can?t backport because 8u doesn?t support vm.debug.
> >
> > 8199265: java/util/Arrays/TimSortStackSize2.java fails with OOM.
> > Webrev in https://cr.openjdk.java.net/~phh/8199265/webrev.8u.jdk.01/
> >
>
> LGTM.
>
> > 8201766: Mark TimSortStackSize2.java as intermittently failing. N/A
> >
> > 8190679: java/util/Arrays/TimSortStackSize2.java fails with "Initial
> heap size set to a larger value than the maximum heap size".
> > Webrev in https://cr.openjdk.java.net/~phh/8190679/webrev.8u.jdk.01/
> >
>
> LGTM.
>
> > 8149391: Fix module dependences in java/util tests. N/A
> >
> > 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests.
> Incorporated into 8075071 backport in order to make it work.
> >
> > 8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java heap space:
> MaxHeap shrinked by MaxRAMFraction.
> > Webrev in https://cr.openjdk.java.net/~phh/8075071/webrev.8u.jdk.03/
> >
>
> LGTM.
>
> All the three downports 8075071, 8190679, and 8199265 look good to me.
>
> Thank you and best regards,
> Volker
>
> > I applied the above webrevs for 8075071, 8190679, and 8199265 in order.
> The result was your patch, except that I included ?@key intermittent? in
> the 8199265 patch.
> >
> > Thanks,
> > Paul
> >
> > From: Adam Farley <adfarley at redhat.com>
> > Date: Monday, March 8, 2021 at 10:00 AM
> > To: "Hohensee, Paul" <hohensee at amazon.com>
> > Cc: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
> > Subject: RE: RFR: 8263099: TimSortStackSize2.java throws OOM when using
> -XX:-UseCompressedOops
> >
> > Hi Paul,
> > I merged the other four change sets, however 3 of the 4 were not clean
> backports.
> >
> > Mainly:
> >
> > 1) /../../test/lib causes errors (and, sans ".."s, is the wrong dir for
> that lib on jdk8 anyway).
> > 2) ProcessTools lacks executeTestJava(String...), though executeTestJvm
> seems to do the same thing.
> > 3) TEST.ROOT seems to lack the section required for the vm.debug change.
> >
> > I don't think any of those is a major loss though, so I added the parts
> of the change sets I thought were clean.
> >
> >
> https://github.com/AdoptOpenJDK/openjdk-jdk8u/compare/master...adamfarley:oom_upstream_merge_fix
> >
> > Your thoughts?
> >
> > Best Regards
> >
> > Adam Farley
> > Software Developer
> > Red Hat
> >
> >
> > On Fri, Mar 5, 2021 at 7:19 PM Hohensee, Paul <hohensee at amazon.com
> <mailto:hohensee at amazon.com>> wrote:
> > "hg log" says that this test has had quite a few problems since JDK 8.
> These are the post JDK 8 ones.
> >
> > $ hg log test/jdk/java/util/Arrays/TimSortStackSize2.java # after repo
> consolidation
> >
> > changeset:   53086:a15200acedcd
> > user:        andrew
> > date:        Tue Mar 31 08:08:44 2020 +0100
> > summary:     8220613: java/util/Arrays/TimSortStackSize2.java times out
> with fastdebug build
> >
> > changeset:   50849:9b0e2937fac5
> > user:        iignatyev
> > date:        Wed Jun 27 13:43:52 2018 -0700
> > summary:     8199265: java/util/Arrays/TimSortStackSize2.java fails with
> OOM
> >
> > changeset:   49820:663f5d90f0e8
> > user:        darcy
> > date:        Wed Apr 18 10:03:49 2018 -0700
> > summary:     8201766: Mark TimSortStackSize2.java as intermittently
> failing
> >
> > changeset:   49178:1836bf0c820a
> > user:        iignatyev
> > date:        Tue Feb 27 21:29:08 2018 -0800
> > summary:     8190679: java/util/Arrays/TimSortStackSize2.java fails with
> "Initial heap size set to a larger value than the maximum heap size"
> >
> > changeset:   47216:71c04702a3d5
> > user:        erikj
> > date:        Tue Sep 12 19:03:39 2017 +0200
> > summary:     8187443: Forest Consolidation: Move files to unified layout
> >
> > % hg log jdk/test/java/util/Arrays/TimSortStackSize2.java # before repo
> consolidation
> >
> > changeset:   35768:7066da300a08
> > parent:      35739:db483b34fa71
> > user:        shurailine
> > date:        Mon Feb 08 18:14:48 2016 -0800
> > summary:     8149391: Fix module dependences in java/util tests
> >
> > changeset:   33832:7dde7a271492
> > parent:      33659:400008d8de8c
> > user:        cjplummer
> > date:        Thu Oct 29 12:02:53 2015 -0700
> > summary:     8140189: [TESTBUG] Get rid of "@library /../../test/lib" in
> jtreg tests
> >
> > changeset:   29613:da0ff5cf6e75
> > user:        lpriima
> > date:        Tue Mar 24 03:46:57 2015 -0400
> > summary:     8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java heap
> space: MaxHeap shrinked by MaxRAMFraction
> >
> > If at all possible, I'd prefer to see these backported, excepting
> 8201766, 8187443, 8149391, and probably 8140189. The backports should apply
> pretty cleanly if done in order.
> >
> > Thanks,
> > Paul
> >
> > -----Original Message-----
> > From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net<mailto:
> jdk8u-dev-retn at openjdk.java.net>> on behalf of Adam Farley <
> adfarley at redhat.com<mailto:adfarley at redhat.com>>
> > Date: Friday, March 5, 2021 at 8:16 AM
> > To: "jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>" <
> jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>>
> > Subject: RFR: 8263099: TimSortStackSize2.java throws OOM when using
> -XX:-UseCompressedOops
> >
> > Hi All,
> >
> > Simple problem, which is solved on later jdk versions by simply
> increasing
> > the heap.
> >
> > Request reviews and sponsor for this change.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8263099
> >
> > Best Regards
> >
> > Adam Farley
> > Software Developer
> > Red Hat
>
>

From hohensee at amazon.com  Mon Mar 15 18:19:53 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 15 Mar 2021 18:19:53 +0000
Subject: [8u] RFR (XS) 8260236: better init AnnotationCollector
 _contended_group
Message-ID: <5A7617F9-983E-47E3-BDB2-70117A99C029@amazon.com>

Lgtm.

Thanks,
Paul

?-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Aleksey Shipilev <shade at redhat.com>
Date: Monday, March 15, 2021 at 11:02 AM
To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: [8u] RFR (XS) 8260236: better init AnnotationCollector _contended_group

Original fix:
   https://bugs.openjdk.java.net/browse/JDK-8260236
   https://github.com/openjdk/jdk/commit/fd2641ed

Unfortunately, this does not apply to 8u cleanly, because the AnnotationProcessor is still in .hpp
in 8u.

Therefore, 8u variant is:

diff -r b0825e3772d3 src/share/vm/classfile/classFileParser.hpp
--- a/src/share/vm/classfile/classFileParser.hpp        Mon Apr 20 13:34:04 2015 +0200
+++ b/src/share/vm/classfile/classFileParser.hpp        Mon Mar 15 18:59:42 2021 +0100
@@ -1,7 +1,7 @@
  /*
- * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 1997, 2021, Oracle and/or its affiliates. All rights reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
   * under the terms of the GNU General Public License version 2 only, as
   * published by the Free Software Foundation.
@@ -137,11 +137,11 @@
      const Location _location;
      int _annotations_present;
      u2 _contended_group;

      AnnotationCollector(Location location)
-    : _location(location), _annotations_present(0)
+    : _location(location), _annotations_present(0), _contended_group(0)
      {
        assert((int)_annotation_LIMIT <= (int)sizeof(_annotations_present) * BitsPerByte, "");
      }
      // If this annotation name has an ID, report it (or _none).
      ID annotation_index(ClassLoaderData* loader_data, Symbol* name);


Testing: Linux x86_64 build

--
Thanks,
-Aleksey



From shade at redhat.com  Mon Mar 15 18:21:36 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 15 Mar 2021 19:21:36 +0100
Subject: [8u] RFR (XS) 8260236: better init AnnotationCollector
 _contended_group
In-Reply-To: <5A7617F9-983E-47E3-BDB2-70117A99C029@amazon.com>
References: <5A7617F9-983E-47E3-BDB2-70117A99C029@amazon.com>
Message-ID: <5a03b2aa-b9b4-ff1c-2d4e-dcbb88af4fe2@redhat.com>

On 3/15/21 7:19 PM, Hohensee, Paul wrote:
> Lgtm.

Thanks, added tags.

-- 
-Aleksey


From benty at amazon.com  Tue Mar 16 23:47:22 2021
From: benty at amazon.com (Taylor, Ben)
Date: Tue, 16 Mar 2021 23:47:22 +0000
Subject: jdk8u-dev MacOS 10.15+ build environment?
Message-ID: <3FA98C31-3736-4564-99FD-450E6B62C9AC@amazon.com>

Hi,

In parallel with Simon's work [1], we've created a patch set against 8u282 that supports this through a combination of Simon's patches to the build system and a backport of JDK-8182299 [2] and associated follow-up patches. 

The patch set has been uploaded to [3], and includes a markdown document [4] describing the patches and how they were built and applied.

Thanks,
--Ben Taylor (he/him)

[1] https://github.com/stooke/jdk8u-xcode10
[2] https://bugs.openjdk.java.net/browse/JDK-8182299
[3] https://cr.openjdk.java.net/~phh/jdk8u-xcode12-patches/
[4] https://cr.openjdk.java.net/~phh/jdk8u-xcode12-patches/upstream-8u-patches.md

?On 2021/03/15, 06:33, "jdk8u-dev on behalf of Andrew Haley" <jdk8u-dev-retn at openjdk.java.net on behalf of aph at redhat.com> wrote:

    CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



    On 3/15/21 12:24 PM, Simon Tooke wrote:
    >
    > On 2021-03-15 7:19 a.m., Andrew Haley wrote:
    >> On 3/1/21 2:33 PM, Andrew Leonard wrote:
    >>
    >>> I have a Mac OS contribution i've developed and tested at AdoptOpenJDK, I
    >>> would like to contribute it upstream to jdk8u-dev, unfortunately the
    >>> jdk8u-dev supported build platform is MacOS 10.7. Is there a method people
    >>> use to build & test their contributions if you don't have a MacOS 10.7
    >>> environment? The AdoptOpenJDK jdk8u base has patches to allow building
    >>> jdk8u with Xcode 11.5 on 10.15+..
    >> Let's get those patches in, then. Who contributed them? We'd
    >> need to get them to contribute to 8u.
    >
    > Almost all the patches are backports; as they were not bugfixes per se,
    > they rarely got approved.

    The rules about backports to new environments tend to be more
    relaxed than general enhancements. We want JDK 8u to continue
    to be relevant for as long as it is supported; that's why we
    allowed AArch64 support to be imported into 8u. So, let's get
    this done.

    --
    Andrew Haley  (he/him)
    Java Platform Lead Engineer
    Red Hat UK Ltd. <https://www.redhat.com>
    https://keybase.io/andrewhaley
    EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671



From hohensee at amazon.com  Wed Mar 17 02:30:45 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 17 Mar 2021 02:30:45 +0000
Subject: RFR [8u] JDK-8239798 : SSLSocket closes socket both socket
 endpoints on a SocketTimeoutException
In-Reply-To: <12291d48-a1db-66dc-5a14-cfa75ef16cfe@amazon.com>
References: <12291d48-a1db-66dc-5a14-cfa75ef16cfe@amazon.com>
Message-ID: <3B8F9CB4-014C-4386-8508-50CB4DB9A84E@amazon.com>

Lgtm.

Thanks,
Paul

?-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of "Alvarez, David" <alvdavi at amazon.com>
Date: Monday, February 15, 2021 at 9:58 PM
To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: RFR [8u] JDK-8239798 : SSLSocket closes socket both socket endpoints on a SocketTimeoutException

Hi,

I would like to request a review for JDK-8239798

Original bug: https://bugs.openjdk.java.net/browse/JDK-8239798
Webrev:
http://cr.openjdk.java.net/~alvdavi/webrevs/8239798/webrev.8u.jdk.00/

The backport is mostly clean, except for some changes in
SSLSocketInputRecord.java to account for DTLS removal in 8u [1]

This is one of a set of multiple patches TLS1.3 patches that were added
to 11u after 11.0.7 that did not make it into 8u.

All jdk tier1 test pass.

Thanks,

David

--
[1] https://bugs.openjdk.java.net/browse/JDK-8245469



From gnu.andrew at redhat.com  Wed Mar 17 03:42:14 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 17 Mar 2021 03:42:14 +0000
Subject: jdk8u-dev MacOS 10.15+ build environment?
In-Reply-To: <201a3dd8-59fd-86d6-949f-8bdeae66c80c@redhat.com>
References: <CAFFhbGPPjte_0V5kGxW2bbyodwP6HyR+8acTvv9whR91-sgGdw@mail.gmail.com>
 <468297a0-68ef-5e6d-844e-0585391a2b86@redhat.com>
 <201a3dd8-59fd-86d6-949f-8bdeae66c80c@redhat.com>
Message-ID: <20210317034214.GC530498@rincewind>

On 08:24 Mon 15 Mar     , Simon Tooke wrote:
> 
> On 2021-03-15 7:19 a.m., Andrew Haley wrote:
> > On 3/1/21 2:33 PM, Andrew Leonard wrote:
> > 
> > > I have a Mac OS contribution i've developed and tested at AdoptOpenJDK, I
> > > would like to contribute it upstream to jdk8u-dev, unfortunately the
> > > jdk8u-dev supported build platform is MacOS 10.7. Is there a method people
> > > use to build & test their contributions if you don't have a MacOS 10.7
> > > environment? The AdoptOpenJDK jdk8u base has patches to allow building
> > > jdk8u with Xcode 11.5 on 10.15+..
> > Let's get those patches in, then. Who contributed them? We'd
> > need to get them to contribute to 8u.
> 
> Almost all the patches are backports; as they were not bugfixes per se, they
> rarely got approved.
> 
> https://github.com/stooke/jdk8u-xcode10? see especially the patch
> directories.
> 
> -Simon
> 

>From what I remember, they were not proposed as backports but as a separate
patch without the source history.

I can't see a problem with most of the changes proposed, particularly if they
only touch a build configuration (Mac OS) which doesn't work at present.

Patches like https://cr.openjdk.java.net/~phh/jdk8u-xcode12-patches/hotspot/8033289.patch
I've backported myself a long time ago in IcedTea.

Which version of clang are we targetting? As I said before, with the shared code,
a lot of this seems to be warnings from a particular version of clang that will
likely be the same on other platforms, and so can be reproduced without needing
Mac OS.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 gnu.andrew at redhat.com  Wed Mar 17 03:44:05 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 17 Mar 2021 03:44:05 +0000
Subject: jdk8u-dev MacOS 10.15+ build environment?
In-Reply-To: <3FA98C31-3736-4564-99FD-450E6B62C9AC@amazon.com>
References: <3FA98C31-3736-4564-99FD-450E6B62C9AC@amazon.com>
Message-ID: <20210317034405.GD530498@rincewind>

On 23:47 Tue 16 Mar     , Taylor, Ben wrote:
> Hi,
> 
> In parallel with Simon's work [1], we've created a patch set against 8u282 that supports this through a combination of Simon's patches to the build system and a backport of JDK-8182299 [2] and associated follow-up patches. 
> 
> The patch set has been uploaded to [3], and includes a markdown document [4] describing the patches and how they were built and applied.
> 
> Thanks,
> --Ben Taylor (he/him)
> 
> [1] https://github.com/stooke/jdk8u-xcode10
> [2] https://bugs.openjdk.java.net/browse/JDK-8182299
> [3] https://cr.openjdk.java.net/~phh/jdk8u-xcode12-patches/
> [4] https://cr.openjdk.java.net/~phh/jdk8u-xcode12-patches/upstream-8u-patches.md
> 

Is someone planning to propose each of these backports for review?

Is there a particular reason to backport JDK-8182299? From what I can see, it turns
on a number of warnings that were disabled and then fixes the issues that show up.
Is there actually an issue if those warnings are not enabled?

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 gnu.andrew at redhat.com  Wed Mar 17 03:44:34 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 17 Mar 2021 03:44:34 +0000
Subject: [8u] RFR: 8260356: (tz) Upgrade time-zone data to tzdata2021a
In-Reply-To: <d89a05bc-a139-778d-1686-88a93f9f1a3c@azul.com>
References: <20210312051313.GD7420@rincewind>
 <d89a05bc-a139-778d-1686-88a93f9f1a3c@azul.com>
Message-ID: <20210317034434.GE530498@rincewind>

On 11:10 Fri 12 Mar     , Dmitry Cherepanov wrote:
> Hi Andrew,
> 
> Looks good. Thanks.
> 
> Dmitry
> 

Thanks again Dmitry. I'll flag it for jdk8u-critical-request.
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 gnu.andrew at redhat.com  Wed Mar 17 03:46:10 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 17 Mar 2021 03:46:10 +0000
Subject: OpenJDK 8u292-b07 EA Released
Message-ID: <20210317034610.GF530498@rincewind>

I've made available an early access source bundle for 8u292, based on
the tag jdk8u292-b07:

https://openjdk-sources.osci.io/openjdk8/openjdk8u292-b07-ea.tar.xz

The tarball is accompanied by a digital signature available at:

https://openjdk-sources.osci.io/openjdk8/openjdk8u292-b07-ea.tar.xz.sig

This is signed by our new Red Hat OpenJDK key (openjdk at redhat.com):

PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net)
Fingerprint: CA5F 11C6 CE22 644D 42C6  AC44 92EF 8D39 DC13 168F

SHA256 checksums:

c8772ed017ef52cac5621b0738f5c68b8036b65ff7a59017e7337c2c36cdb4bd  openjdk8u292-b07-ea.tar.xz
8cfaee7a716a8eb6a76a5cc51b97ad5488c7fe0f51cbb9a455ac507b3ac4550b  openjdk8u292-b07-ea.tar.xz.sig

They are listed at
https://openjdk-sources.osci.io/openjdk8/openjdk8u292-b07-ea.sha256

Changes in 8u292-b07:
  - JDK-8263008: AARCH64: Add debug info for libsaproc.so
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 kasun.talwatta at steadypay.co  Sun Mar 14 06:43:05 2021
From: kasun.talwatta at steadypay.co (Kasun Talwatta)
Date: Sun, 14 Mar 2021 19:43:05 +1300
Subject: OpenJDK 1.8_275 SIGSEGV error
Message-ID: <B6FCF10D-944F-42D6-80BF-86D189D58C7E@steadypay.co>

We have a 3 node Cassandra 3.11.3 running on OpenJDK 1.8_275. Nodes crash randomly due to SIGSEGV with no obvious information in the stack .
Running with G1GC.

I have attached the heap dump log below.

-------------- next part --------------


Cheers,
Kasun

From preethis00 at gmail.com  Wed Mar 17 10:08:56 2021
From: preethis00 at gmail.com (preethi selvaraj)
Date: Wed, 17 Mar 2021 15:38:56 +0530
Subject: Latest jdk8u faile for Solaris 10 32-bit
In-Reply-To: <89f43965-5d98-512d-d1db-d513715ddc60@redhat.com>
References: <CAF7k0J1sz+CP8rxB3D1EKeVnNxy07TUE6j2s3K_VMrBdTW_tng@mail.gmail.com>
 <89f43965-5d98-512d-d1db-d513715ddc60@redhat.com>
Message-ID: <CAF7k0J38n1KqO1vEx4qEGGiNB_0S2pAVLzWWYDFfQLWux-d+0g@mail.gmail.com>

No. It was not working. 64-bit is building perfectly whereas jdk8u 32-bit
not building. Is jdk8u not supported for 32-bit?

On Mon, Jul 20, 2020, 19:44 Andrew Hughes <gnu.andrew at redhat.com> wrote:

>
>
> On 20/07/2020 07:17, preethi selvaraj wrote:
> > Hi Team,
> > Latest jdk8u source failed to build for 32-bit in Solaris 10 x86 whereas
> in
> > the same system build got succeeded for 64-bit with the same setup/
> > Have pulled latest jdk8u content from
> > http://hg.openjdk.java.net/jdk8u/jdk8u/. When I build in Solaris 10 for
> > 32-bit,
> >
>
> Has this worked for you before?
>
> I'm not aware of anyone testing on Solaris x86, so it may be that 8u has
> been broken for some time.
>
> Thanks,
> --
> Andrew :)
>
> Senior Free Java Software Engineer
> OpenJDK Package Owner
> 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 peter.tribble at gmail.com  Wed Mar 17 11:36:29 2021
From: peter.tribble at gmail.com (Peter Tribble)
Date: Wed, 17 Mar 2021 11:36:29 +0000
Subject: Latest jdk8u faile for Solaris 10 32-bit
In-Reply-To: <CAF7k0J38n1KqO1vEx4qEGGiNB_0S2pAVLzWWYDFfQLWux-d+0g@mail.gmail.com>
References: <CAF7k0J1sz+CP8rxB3D1EKeVnNxy07TUE6j2s3K_VMrBdTW_tng@mail.gmail.com>
 <89f43965-5d98-512d-d1db-d513715ddc60@redhat.com>
 <CAF7k0J38n1KqO1vEx4qEGGiNB_0S2pAVLzWWYDFfQLWux-d+0g@mail.gmail.com>
Message-ID: <CAEgYsbF3B5Twjod2DPz2AJLF8TLGc1hxr1XaPApJKmTVvr_hzA@mail.gmail.com>

On Wed, Mar 17, 2021 at 11:24 AM preethi selvaraj <preethis00 at gmail.com>
wrote:

> No. It was not working. 64-bit is building perfectly whereas jdk8u 32-bit
> not building. Is jdk8u not supported for 32-bit?
>

32-bit Solaris support was removed from jdk8 a very long time ago. I think
8u20 or
thereabouts was the last version that would build in 32-bit mode on Solaris.


> On Mon, Jul 20, 2020, 19:44 Andrew Hughes <gnu.andrew at redhat.com> wrote:
>
> >
> >
> > On 20/07/2020 07:17, preethi selvaraj wrote:
> > > Hi Team,
> > > Latest jdk8u source failed to build for 32-bit in Solaris 10 x86
> whereas
> > in
> > > the same system build got succeeded for 64-bit with the same setup/
> > > Have pulled latest jdk8u content from
> > > http://hg.openjdk.java.net/jdk8u/jdk8u/. When I build in Solaris 10
> for
> > > 32-bit,
> > >
> >
> > Has this worked for you before?
> >
> > I'm not aware of anyone testing on Solaris x86, so it may be that 8u has
> > been broken for some time.
> >
> > Thanks,
> > --
> > Andrew :)
> >
> > Senior Free Java Software Engineer
> > OpenJDK Package Owner
> > 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
> >
> >
>


-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/

From sgehwolf at redhat.com  Wed Mar 17 17:49:21 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 17 Mar 2021 18:49:21 +0100
Subject: RFC: When to include 8243559 in 8u? (Remove root certificates with
 1024-bit keys)
Message-ID: <e30523aaa45d0c06c74e9d823974936527ad657a.camel@redhat.com>

Hi,

I'm currently working on an 8u backport of 8243559[0]. The question 
I'd have for the community is how do people feel about an appropriate
"heads-up" for users that those weak certificates will soon be gone.
How long should the heads-up be? One release cycle (1 quarter), 2
release cycles, 3 release cycles? JDK 11 settled for 3 quarters for the
deprecation warning until weak root certificates got removed.

Mozilla has phased out 1024 bit root certificates in 2015[1].

If we removed root certificates in 8u302, users would have one release
cycle, i.e. one quarter, to notice the planned removal via the
deprecation warning when actually trying to sign jars or use them for
certpath processing. Note that the deprecation warning got added to
8u292 (to be released this April) via JDK-8172404. Since July 2021 will
be when other JDK releases remove them, I propose to remove them in
OpenJDK 8u at that time with 8u302 as well.

Thoughts? Objections?

Thanks,
Severin

[0] https://bugs.openjdk.java.net/browse/JDK-8243559
[1] https://blog.mozilla.org/security/2014/09/08/phasing-out-certificates-with-1024-bit-rsa-keys/


From gnu.andrew at redhat.com  Wed Mar 17 19:46:43 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 17 Mar 2021 19:46:43 +0000
Subject: RFR: 8191915: JCK tests produce incorrect results with C2
In-Reply-To: <DA41BE1DDCA941489001C7FBD7A8820EE8028BA1@dggeml507-mbx.china.huawei.com>
References: <DA41BE1DDCA941489001C7FBD7A8820EE8028BA1@dggeml507-mbx.china.huawei.com>
Message-ID: <20210317194643.GA567290@rincewind>

On 08:37 Mon 15 Mar     , Yangfei (Felix) wrote:
> Hi,
> 
>   Please review this 8u backport fixing a compatibility issue:
> 
>   Original bug: https://bugs.openjdk.java.net/browse/JDK-8191915 
>   Original patch: http://hg.openjdk.java.net/jdk/jdk10/rev/4162f740b7bd 
>   Webrev for 8u: http://cr.openjdk.java.net/~fyang/8191915-8u/webrev.00/ 
> 
>   I am using gcc-7.5 and I find this issue can always be reproduced on both aarch64 and x84_64 linux with the provided jtreg test. 
>   Original patch does not apply cleanly after path shuffling, three adaptations for 8u:
>   1. Adjusted copyright year update for both mathexactnode.cpp and mathexactnode.hpp;
>   2. Adjusted the test command for the jtreg test in the original patch: LongMulOverflowTest.java;
>   3. Removed test_mathexact.cpp in the original patch.
> 
>   Performed full jtreg test on both aarch64 and x84_64 linux. OK?
> 
> Thanks,
> Felix

Looks good to me. Test fails without the patch and passes with here too.
No GTest for the test_mathexact.cpp patch in 8u.

As this apparently affects a JCK test, I think it may be a candidate
for inclusion in 8u292 during rampdown. Please flag with
jdk8u-critical-request if you agree.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 gnu.andrew at redhat.com  Wed Mar 17 20:18:59 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 17 Mar 2021 20:18:59 +0000
Subject: RFC: When to include 8243559 in 8u? (Remove root certificates
 with 1024-bit keys)
In-Reply-To: <e30523aaa45d0c06c74e9d823974936527ad657a.camel@redhat.com>
References: <e30523aaa45d0c06c74e9d823974936527ad657a.camel@redhat.com>
Message-ID: <20210317201859.GB567290@rincewind>

On 18:49 Wed 17 Mar     , Severin Gehwolf wrote:
> Hi,
> 
> I'm currently working on an 8u backport of 8243559[0]. The question 
> I'd have for the community is how do people feel about an appropriate
> "heads-up" for users that those weak certificates will soon be gone.
> How long should the heads-up be? One release cycle (1 quarter), 2
> release cycles, 3 release cycles? JDK 11 settled for 3 quarters for the
> deprecation warning until weak root certificates got removed.
> 
> Mozilla has phased out 1024 bit root certificates in 2015[1].
> 
> If we removed root certificates in 8u302, users would have one release
> cycle, i.e. one quarter, to notice the planned removal via the
> deprecation warning when actually trying to sign jars or use them for
> certpath processing. Note that the deprecation warning got added to
> 8u292 (to be released this April) via JDK-8172404. Since July 2021 will
> be when other JDK releases remove them, I propose to remove them in
> OpenJDK 8u at that time with 8u302 as well.
> 
> Thoughts? Objections?
> 
> Thanks,
> Severin
> 
> [0] https://bugs.openjdk.java.net/browse/JDK-8243559
> [1] https://blog.mozilla.org/security/2014/09/08/phasing-out-certificates-with-1024-bit-rsa-keys/
> 

I agree with removing them in 8u302 to be consistent with other JDK releases.

If users really do need these certificates, they can add them locally.

I suspect the deprecation period was designed with Oracle's JDKs in
mind, intending to apply across the whole range from 7 to 17. Oracle
have been shipping this set of certificates much longer than OpenJDK.

The certificates were not open-sourced until JDK-8189131 [0] in
OpenJDK 10 in late 2017. There were not backported to 8u until 8u222
in July 2019. As a result, the window for adoption is much smaller
with OpenJDK; just over three years for those using 10 and later, and
less than two for those on 8u.

As they are a relatively new addition to OpenJDK, many vendors will
have provided alternative solutions many years earlier and likely have
stuck with those since OpenJDK's introduction of its own
certificates. In our case, with Fedora & RHEL, we generate our own
cacerts from the Mozilla root certificates, so will have removed
1024-bit certificates in 2015 as you mention.

I would need a very strong argument for OpenJDK 8 to be the only JDK
still carrying these certificates after July. It is unfortunate that
the deprecation work wasn't backported earlier, but I don't think this
warrants carrying insecure certificates for longer than other JDKs.

As to the backporting, I think we do need to consider how backports
are prioritised. I'm seeing a few like this that should have been done
earlier (I have a list of ones I have seen in recent 11u build
promotions and intend to look at for 8u), while we seem to be getting
a lot of 8u backports for rather trivial test and build fixes.

[0] https://bugs.openjdk.java.net/browse/JDK-8189131

Thanks,
--
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 Mar 17 23:15:29 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 17 Mar 2021 23:15:29 +0000
Subject: [8u] RFR: JDK-8261867: Backport relevant test changes & additions
 from JDK-8130125
In-Reply-To: <8133E657-B987-4830-8E63-97FA54F79A8B@amazon.com>
References: <1ABCD1CA-2ACE-4894-A4A4-9A0A95C40624@amazon.com>
 <8133E657-B987-4830-8E63-97FA54F79A8B@amazon.com>
Message-ID: <353A970A-4C0A-499E-9B65-7C385C9BCC65@amazon.com>

Another mistake on my part: your webrev includes the comment change in test/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java.

I added the changes to test/java/awt/Focus/8073453/AWTFocusTransitionTest.java, test/java/awt/Focus/8073453/SwingFocusTransitionTest.java, and test/java/awt/xembed/server/TestXEmbedServer.java. The first two pass as before. The third is a bit unstable, but the manual portion seems more stable than before the change. 

Webrev: https://cr.openjdk.java.net/~phh/8261867/webrev.8u.jdk.00/

Thanks,
Paul

?-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of "Hohensee, Paul" <hohensee at amazon.com>
Date: Wednesday, February 17, 2021 at 3:55 PM
To: Andrew Hughes <gnu.andrew at redhat.com>, "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: Re: [8u] RFR: JDK-8261867: Backport relevant test changes & additions from JDK-8130125

Whoops, sent before noted that

test/java/awt/font/GlyphVector/TestLayoutFlags.java
test/java/awt/font/Underline/UnderlineTest.java

are in your webrev. :)

-----Original Message-----
From: "Hohensee, Paul" <hohensee at amazon.com>
Date: Wednesday, February 17, 2021 at 3:53 PM
To: Andrew Hughes <gnu.andrew at redhat.com>, "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: Re: [8u] RFR: JDK-8261867: Backport relevant test changes & additions from JDK-8130125

What you've got looks good.

Do you in addition want to other changes, i.e., the patches that switch from using sun.awt.Toolkit to using the Robot

test/java/awt/Focus/8073453/AWTFocusTransitionTest.java
test/java/awt/Focus/8073453/SwingFocusTransitionTest.java

the comment change in

test/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java

two other new tests

test/java/awt/font/GlyphVector/TestLayoutFlags.java
test/java/awt/font/Underline/UnderlineTest.java

and the patch to

test/java/awt/xembed/server/TestXEmbedServer.java

Thanks,
Paul

-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.

net> on behalf of Andrew Hughes <gnu.andrew at redhat.com>
Date: Tuesday, February 16, 2021 at 9:56 PM
To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: [8u] RFR: JDK-8261867: Backport relevant test changes & additions from JDK-8130125

Bugs: https://bugs.openjdk.java.net/browse/JDK-8261867
      https://bugs.openjdk.java.net/browse/JDK-8130125
Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8261867/webrev.01/

The main focus of JDK-8130125 is irrelevant to 8u, as it concerns the
introduction of the module system. However, the change was also used
to introduce a number of other test changes and open up three tests
[0]. Backporting these tests will increase test coverage in 8u
and ease the backport of JDK-8159690..

The webrev above includes a subset of the changes from JDK-8130125,
suitable for 8u.

[0] https://mail.openjdk.java.net/pipermail/awt-dev/2015-July/009588.html

Thanks,
--
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 felix.yang at huawei.com  Thu Mar 18 01:21:19 2021
From: felix.yang at huawei.com (Yangfei (Felix))
Date: Thu, 18 Mar 2021 01:21:19 +0000
Subject: RFR: 8191915: JCK tests produce incorrect results with C2
In-Reply-To: <20210317194643.GA567290@rincewind>
References: <DA41BE1DDCA941489001C7FBD7A8820EE8028BA1@dggeml507-mbx.china.huawei.com>
 <20210317194643.GA567290@rincewind>
Message-ID: <fd7296ee9dd347c3842b53c484ed7e0e@huawei.com>

Hi,

> -----Original Message-----
> From: Andrew Hughes [mailto:gnu.andrew at redhat.com]
> Sent: Thursday, March 18, 2021 3:47 AM
> To: Yangfei (Felix) <felix.yang at huawei.com>
> Cc: jdk8u-dev at openjdk.java.net; Guoge(JVM) <ge.guo at huawei.com>
> Subject: Re: RFR: 8191915: JCK tests produce incorrect results with C2
> 
> On 08:37 Mon 15 Mar     , Yangfei (Felix) wrote:
> > Hi,
> >
> >   Please review this 8u backport fixing a compatibility issue:
> >
> >   Original bug: https://bugs.openjdk.java.net/browse/JDK-8191915
> >   Original patch: http://hg.openjdk.java.net/jdk/jdk10/rev/4162f740b7bd
> >   Webrev for 8u:
> > http://cr.openjdk.java.net/~fyang/8191915-8u/webrev.00/
> >
> >   I am using gcc-7.5 and I find this issue can always be reproduced on both
> aarch64 and x84_64 linux with the provided jtreg test.
> >   Original patch does not apply cleanly after path shuffling, three
> adaptations for 8u:
> >   1. Adjusted copyright year update for both mathexactnode.cpp and
> mathexactnode.hpp;
> >   2. Adjusted the test command for the jtreg test in the original patch:
> LongMulOverflowTest.java;
> >   3. Removed test_mathexact.cpp in the original patch.
> >
> >   Performed full jtreg test on both aarch64 and x84_64 linux. OK?
> >
> > Thanks,
> > Felix
> 
> Looks good to me. Test fails without the patch and passes with here too.
> No GTest for the test_mathexact.cpp patch in 8u.
> 
> As this apparently affects a JCK test, I think it may be a candidate for inclusion
> in 8u292 during rampdown. Please flag with jdk8u-critical-request if you
> agree.

Yes, I agree we should have this for 8u292.  Flagged for approval.

Thanks,
Felix

From hohensee at amazon.com  Thu Mar 18 20:24:08 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 18 Mar 2021 20:24:08 +0000
Subject: [8u]: 8136592: [TEST_BUG] Fix 2 platform-specific closed regtests
 for jigsaw
In-Reply-To: <23F50014-34FB-425F-84CB-CD8F2BE7A227@amazon.com>
References: <23F50014-34FB-425F-84CB-CD8F2BE7A227@amazon.com>
Message-ID: <1B56790D-8BE9-49AA-A86C-7B0358C5ED22@amazon.com>

Ping. :)

Thanks,
Paul

?-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of "Hohensee, Paul" <hohensee at amazon.com>
Date: Wednesday, February 24, 2021 at 1:42 PM
To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: [8u]: 8136592: [TEST_BUG] Fix 2 platform-specific closed regtests for jigsaw

Please review this test-only backport. The JBS issue is private, so I can?t create a backport issue. We?ll have to rely on hg-updater when pushed, and maintainer approval will have to be on the list.

Original patch: http://hg.openjdk.java.net/jdk-updates/jdk9u/jdk/rev/ddc8bbf88d36
8u webrev: http://cr.openjdk.java.net/~phh/8136592/webrev.8u.jdk.02/

The @modules attributes have been removed, and implicit casts have been replaced by explicit ones to XEmbedCanvasPeer, FramePeer, and ListPeer. The first two required importing sun.awt.X11.*.

The two new tests pass.

Thanks,
Paul



From gnu.andrew at redhat.com  Fri Mar 19 05:41:20 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 19 Mar 2021 05:41:20 +0000
Subject: [8u] RFR: JDK-8258419: RSA cipher buffer cleanup
Message-ID: <20210319054120.GA820910@rincewind>

Bug: https://bugs.openjdk.java.net/browse/JDK-8258419
Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8258419/webrev.01/

This patch cleans up RSA temporary buffers after use and avoids
some unnecessary copying. Fix is backported to all Oracle releases
from 7 to 17.

Patch applies almost cleanly to 8u. Only rejects are the copyright
header changes to RSAPadding.java and RSACipher.java, as they were
already updated to 2020 by JDK-8230978.

Ok for 8u?

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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  Fri Mar 19 14:01:31 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 19 Mar 2021 14:01:31 +0000
Subject: [8u] RFR: JDK-8258419: RSA cipher buffer cleanup
Message-ID: <C8C71900-0960-404E-944C-127A68C78122@amazon.com>

Lgtm.

Thanks,
Paul

?-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Andrew Hughes <gnu.andrew at redhat.com>
Date: Thursday, March 18, 2021 at 10:41 PM
To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: [8u] RFR: JDK-8258419: RSA cipher buffer cleanup

Bug: https://bugs.openjdk.java.net/browse/JDK-8258419
Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8258419/webrev.01/

This patch cleans up RSA temporary buffers after use and avoids
some unnecessary copying. Fix is backported to all Oracle releases
from 7 to 17.

Patch applies almost cleanly to 8u. Only rejects are the copyright
header changes to RSAPadding.java and RSACipher.java, as they were
already updated to 2020 by JDK-8230978.

Ok for 8u?

Thanks,
--
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 sgehwolf at redhat.com  Fri Mar 19 14:57:54 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 19 Mar 2021 15:57:54 +0100
Subject: [8u] RFR: JDK-8258419: RSA cipher buffer cleanup
In-Reply-To: <20210319054120.GA820910@rincewind>
References: <20210319054120.GA820910@rincewind>
Message-ID: <fb2063d63b28ac8b9eac7bb01dd6a3876d47ee37.camel@redhat.com>

On Fri, 2021-03-19 at 05:41 +0000, Andrew Hughes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8258419
> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8258419/webrev.01/
> 
> This patch cleans up RSA temporary buffers after use and avoids
> some unnecessary copying. Fix is backported to all Oracle releases
> from 7 to 17.
> 
> Patch applies almost cleanly to 8u. Only rejects are the copyright
> header changes to RSAPadding.java and RSACipher.java, as they were
> already updated to 2020 by JDK-8230978.
> 
> Ok for 8u?

Looks OK to me.

Thanks,
Severin


From volker.simonis at gmail.com  Fri Mar 19 16:27:18 2021
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 19 Mar 2021 17:27:18 +0100
Subject: [8u]: 8136592: [TEST_BUG] Fix 2 platform-specific closed regtests
 for jigsaw
In-Reply-To: <1B56790D-8BE9-49AA-A86C-7B0358C5ED22@amazon.com>
References: <23F50014-34FB-425F-84CB-CD8F2BE7A227@amazon.com>
 <1B56790D-8BE9-49AA-A86C-7B0358C5ED22@amazon.com>
Message-ID: <CA+3eh129ibtunK+CGBa9UJxrcqxcR-Vmi_i0jDrW+VWAs7+Vyg@mail.gmail.com>

Hi Paul,

the downport looks good to me, but I somehow doubt if we should really
downport test/java/awt/EmbeddedFrame/GraphicsConfigTest/GraphicsConfigTest.java.
The summary mentions that the test is for verifying correct behavior
in multi-screen environments but it fails about 50% of times in
multi-screen environments (Ubuntu 18.04 / Gnome 3.28.2). I could
actually still see the same number of failures with the latest version
of jdk17 but didn't do more research to see if the failure is related
to the test being unstable or if this is a real problem with the
implementation.

But we probably shouldn't downport unstable tests to jdk8u?

Best regards,
Volker

On Thu, Mar 18, 2021 at 9:24 PM Hohensee, Paul <hohensee at amazon.com> wrote:
>
> Ping. :)
>
> Thanks,
> Paul
>
> ?-----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of "Hohensee, Paul" <hohensee at amazon.com>
> Date: Wednesday, February 24, 2021 at 1:42 PM
> To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
> Subject: [8u]: 8136592: [TEST_BUG] Fix 2 platform-specific closed regtests for jigsaw
>
> Please review this test-only backport. The JBS issue is private, so I can?t create a backport issue. We?ll have to rely on hg-updater when pushed, and maintainer approval will have to be on the list.
>
> Original patch: http://hg.openjdk.java.net/jdk-updates/jdk9u/jdk/rev/ddc8bbf88d36
> 8u webrev: http://cr.openjdk.java.net/~phh/8136592/webrev.8u.jdk.02/
>
> The @modules attributes have been removed, and implicit casts have been replaced by explicit ones to XEmbedCanvasPeer, FramePeer, and ListPeer. The first two required importing sun.awt.X11.*.
>
> The two new tests pass.
>
> Thanks,
> Paul
>
>

From hohensee at amazon.com  Fri Mar 19 16:43:48 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 19 Mar 2021 16:43:48 +0000
Subject: [8u]: 8136592: [TEST_BUG] Fix 2 platform-specific closed regtests
 for jigsaw
Message-ID: <EFD92446-DB1D-4540-BDAC-4C5EF4A79012@amazon.com>

I don't have a problem with backporting unstable tests, because if a fix exists, it's motivation for backporting the fix, and if a fix doesn?t exist, it puts 8u even with tip. It's stable in a single-screen env, fwiw.

This backport was requested by Andrew Hughes, see https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-February/013426.html. It's part of a series of swing/awt test backports. Andrew, would you comment please?

Thanks,
Paul

?-----Original Message-----
From: Volker Simonis <volker.simonis at gmail.com>
Date: Friday, March 19, 2021 at 9:28 AM
To: "Hohensee, Paul" <hohensee at amazon.com>
Cc: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: RE: [8u]: 8136592: [TEST_BUG] Fix 2 platform-specific closed regtests for jigsaw

Hi Paul,

the downport looks good to me, but I somehow doubt if we should really
downport test/java/awt/EmbeddedFrame/GraphicsConfigTest/GraphicsConfigTest.java.
The summary mentions that the test is for verifying correct behavior
in multi-screen environments but it fails about 50% of times in
multi-screen environments (Ubuntu 18.04 / Gnome 3.28.2). I could
actually still see the same number of failures with the latest version
of jdk17 but didn't do more research to see if the failure is related
to the test being unstable or if this is a real problem with the
implementation.

But we probably shouldn't downport unstable tests to jdk8u?

Best regards,
Volker

On Thu, Mar 18, 2021 at 9:24 PM Hohensee, Paul <hohensee at amazon.com> wrote:
>
> Ping. :)
>
> Thanks,
> Paul
>
> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of "Hohensee, Paul" <hohensee at amazon.com>
> Date: Wednesday, February 24, 2021 at 1:42 PM
> To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
> Subject: [8u]: 8136592: [TEST_BUG] Fix 2 platform-specific closed regtests for jigsaw
>
> Please review this test-only backport. The JBS issue is private, so I can?t create a backport issue. We?ll have to rely on hg-updater when pushed, and maintainer approval will have to be on the list.
>
> Original patch: http://hg.openjdk.java.net/jdk-updates/jdk9u/jdk/rev/ddc8bbf88d36
> 8u webrev: http://cr.openjdk.java.net/~phh/8136592/webrev.8u.jdk.02/
>
> The @modules attributes have been removed, and implicit casts have been replaced by explicit ones to XEmbedCanvasPeer, FramePeer, and ListPeer. The first two required importing sun.awt.X11.*.
>
> The two new tests pass.
>
> Thanks,
> Paul
>
>


From volker.simonis at gmail.com  Fri Mar 19 17:13:17 2021
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 19 Mar 2021 18:13:17 +0100
Subject: [8u]: 8136592: [TEST_BUG] Fix 2 platform-specific closed regtests
 for jigsaw
In-Reply-To: <EFD92446-DB1D-4540-BDAC-4C5EF4A79012@amazon.com>
References: <EFD92446-DB1D-4540-BDAC-4C5EF4A79012@amazon.com>
Message-ID: <CA+3eh10RafbGRRQRStkVVjAmrRmvZ0Q1=RYchq13MV=_zeggbQ@mail.gmail.com>

Just wanted to confirm that the test is stable in single-screen
environments. That's probably the reason why nobody noticed the
failures because few people seem to run JTreg in multi-screen
environments.

On Fri, Mar 19, 2021 at 5:43 PM Hohensee, Paul <hohensee at amazon.com> wrote:
>
> I don't have a problem with backporting unstable tests, because if a fix exists, it's motivation for backporting the fix, and if a fix doesn?t exist, it puts 8u even with tip. It's stable in a single-screen env, fwiw.
>
> This backport was requested by Andrew Hughes, see https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-February/013426.html. It's part of a series of swing/awt test backports. Andrew, would you comment please?
>
> Thanks,
> Paul
>
> ?-----Original Message-----
> From: Volker Simonis <volker.simonis at gmail.com>
> Date: Friday, March 19, 2021 at 9:28 AM
> To: "Hohensee, Paul" <hohensee at amazon.com>
> Cc: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
> Subject: RE: [8u]: 8136592: [TEST_BUG] Fix 2 platform-specific closed regtests for jigsaw
>
> Hi Paul,
>
> the downport looks good to me, but I somehow doubt if we should really
> downport test/java/awt/EmbeddedFrame/GraphicsConfigTest/GraphicsConfigTest.java.
> The summary mentions that the test is for verifying correct behavior
> in multi-screen environments but it fails about 50% of times in
> multi-screen environments (Ubuntu 18.04 / Gnome 3.28.2). I could
> actually still see the same number of failures with the latest version
> of jdk17 but didn't do more research to see if the failure is related
> to the test being unstable or if this is a real problem with the
> implementation.
>
> But we probably shouldn't downport unstable tests to jdk8u?
>
> Best regards,
> Volker
>
> On Thu, Mar 18, 2021 at 9:24 PM Hohensee, Paul <hohensee at amazon.com> wrote:
> >
> > Ping. :)
> >
> > Thanks,
> > Paul
> >
> > -----Original Message-----
> > From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of "Hohensee, Paul" <hohensee at amazon.com>
> > Date: Wednesday, February 24, 2021 at 1:42 PM
> > To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
> > Subject: [8u]: 8136592: [TEST_BUG] Fix 2 platform-specific closed regtests for jigsaw
> >
> > Please review this test-only backport. The JBS issue is private, so I can?t create a backport issue. We?ll have to rely on hg-updater when pushed, and maintainer approval will have to be on the list.
> >
> > Original patch: http://hg.openjdk.java.net/jdk-updates/jdk9u/jdk/rev/ddc8bbf88d36
> > 8u webrev: http://cr.openjdk.java.net/~phh/8136592/webrev.8u.jdk.02/
> >
> > The @modules attributes have been removed, and implicit casts have been replaced by explicit ones to XEmbedCanvasPeer, FramePeer, and ListPeer. The first two required importing sun.awt.X11.*.
> >
> > The two new tests pass.
> >
> > Thanks,
> > Paul
> >
> >
>

From gnu.andrew at redhat.com  Wed Mar 24 06:42:07 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 24 Mar 2021 06:42:07 +0000
Subject: [8u] RFR: JDK-8261867: Backport relevant test changes &
 additions from JDK-8130125
In-Reply-To: <353A970A-4C0A-499E-9B65-7C385C9BCC65@amazon.com>
References: <1ABCD1CA-2ACE-4894-A4A4-9A0A95C40624@amazon.com>
 <8133E657-B987-4830-8E63-97FA54F79A8B@amazon.com>
 <353A970A-4C0A-499E-9B65-7C385C9BCC65@amazon.com>
Message-ID: <20210324064207.GA15497@rincewind>

On 23:15 Wed 17 Mar     , Hohensee, Paul wrote:
> Another mistake on my part: your webrev includes the comment change in test/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java.
>

Yes, your initial comments did confuse me a little :-)

> I added the changes to test/java/awt/Focus/8073453/AWTFocusTransitionTest.java, test/java/awt/Focus/8073453/SwingFocusTransitionTest.java, and test/java/awt/xembed/server/TestXEmbedServer.java. The first two pass as before. The third is a bit unstable, but the manual portion seems more stable than before the change. 
> 
> Webrev: https://cr.openjdk.java.net/~phh/8261867/webrev.8u.jdk.00/
>

Yes, for some reason, I think I was under the delusion it was JDK code, not test code.
As is, it's cleanup that was done for the modules system, but is applicable even before that.

I'm happy for your version to go in if you want to flag it with jdk8u-fix-request.

> Thanks,
> Paul
>

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 gnu.andrew at redhat.com  Wed Mar 24 07:07:38 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 24 Mar 2021 07:07:38 +0000
Subject: [8u]: 8136592: [TEST_BUG] Fix 2 platform-specific closed
 regtests for jigsaw
In-Reply-To: <1B56790D-8BE9-49AA-A86C-7B0358C5ED22@amazon.com>
References: <23F50014-34FB-425F-84CB-CD8F2BE7A227@amazon.com>
 <1B56790D-8BE9-49AA-A86C-7B0358C5ED22@amazon.com>
Message-ID: <20210324070738.GB15497@rincewind>

On 20:24 Thu 18 Mar     , Hohensee, Paul wrote:
> Ping. :)
> 
> Thanks,
> Paul
> 
> ?-----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of "Hohensee, Paul" <hohensee at amazon.com>
> Date: Wednesday, February 24, 2021 at 1:42 PM
> To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
> Subject: [8u]: 8136592: [TEST_BUG] Fix 2 platform-specific closed regtests for jigsaw
> 
> Please review this test-only backport. The JBS issue is private, so I can?t create a backport issue. We?ll have to rely on hg-updater when pushed, and maintainer approval will have to be on the list.
> 
> Original patch: http://hg.openjdk.java.net/jdk-updates/jdk9u/jdk/rev/ddc8bbf88d36
> 8u webrev: http://cr.openjdk.java.net/~phh/8136592/webrev.8u.jdk.02/
> 
> The @modules attributes have been removed, and implicit casts have been replaced by explicit ones to XEmbedCanvasPeer, FramePeer, and ListPeer. The first two required importing sun.awt.X11.*.
> 
> The two new tests pass.
> 
> Thanks,
> Paul
> 
> 

Patch looks good to me. You can consider this as a review and approval
under the circumstances :-)

I don't see a problem with backporting the test, even though it has
issues in certain environments. As you noted, that's just a reason to
improve it in HEAD and backport the fix too. Most tests can no doubt
be improved. It can still catch some issues in its current form.

Going by the title, this test has existed even longer, but was in
Oracle's closed repositories.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 gnu.andrew at redhat.com  Wed Mar 24 07:07:56 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 24 Mar 2021 07:07:56 +0000
Subject: [8u] RFR: JDK-8258419: RSA cipher buffer cleanup
In-Reply-To: <C8C71900-0960-404E-944C-127A68C78122@amazon.com>
References: <C8C71900-0960-404E-944C-127A68C78122@amazon.com>
Message-ID: <20210324070756.GC15497@rincewind>

On 14:01 Fri 19 Mar     , Hohensee, Paul wrote:
> Lgtm.
> 
> Thanks,
> Paul
> 

Thanks to you and Severin. I'll flag this for approval.
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 gnu.andrew at redhat.com  Wed Mar 24 15:59:34 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 24 Mar 2021 15:59:34 +0000
Subject: RFR [8u] JDK-8239798 : SSLSocket closes socket both socket
 endpoints on a SocketTimeoutException
In-Reply-To: <3B8F9CB4-014C-4386-8508-50CB4DB9A84E@amazon.com>
References: <12291d48-a1db-66dc-5a14-cfa75ef16cfe@amazon.com>
 <3B8F9CB4-014C-4386-8508-50CB4DB9A84E@amazon.com>
Message-ID: <20210324155934.GB38165@rincewind>

On 02:30 Wed 17 Mar     , Hohensee, Paul wrote:
> Lgtm.
> 
> Thanks,
> Paul
> 
> ?-----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of "Alvarez, David" <alvdavi at amazon.com>
> Date: Monday, February 15, 2021 at 9:58 PM
> To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
> Subject: RFR [8u] JDK-8239798 : SSLSocket closes socket both socket endpoints on a SocketTimeoutException
> 
> Hi,
> 
> I would like to request a review for JDK-8239798
> 
> Original bug: https://bugs.openjdk.java.net/browse/JDK-8239798
> Webrev:
> http://cr.openjdk.java.net/~alvdavi/webrevs/8239798/webrev.8u.jdk.00/
> 
> The backport is mostly clean, except for some changes in
> SSLSocketInputRecord.java to account for DTLS removal in 8u [1]
> 
> This is one of a set of multiple patches TLS1.3 patches that were added
> to 11u after 11.0.7 that did not make it into 8u.
> 
> All jdk tier1 test pass.
> 
> Thanks,
> 
> David
> 
> --
> [1] https://bugs.openjdk.java.net/browse/JDK-8245469
> 
> 

Only minor thing is the copyright header is not added to
SSLSocketInputRecord.java.  It's an addition of a different copyright
holder, so should be added despite the Oracle copyright including
2020.

Part of the SSLSocketInputRecord.java diff was a little hard to
compare with the 11u version, presumably due to whitespace issues.
However, the patched version looks the same as 11u, but without the
copyright header, JDK-8171279: "Support X25519 and X448 in TLS" and
JDK-8228757: "Fail fast if the handshake type is unknown".

Is JDK-8228757 on your todo list? It's marked as resolved in Oracle's
8u261. If not, I can take a look.

As to this patch, should be good to go once the copyright header is
added.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 Sergey.Bylokhov at oracle.com  Thu Mar 25 00:22:19 2021
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 24 Mar 2021 17:22:19 -0700
Subject: [8u] RFR: JDK-8261867: Backport relevant test changes & additions
 from JDK-8130125
In-Reply-To: <20210324064207.GA15497@rincewind>
References: <1ABCD1CA-2ACE-4894-A4A4-9A0A95C40624@amazon.com>
 <8133E657-B987-4830-8E63-97FA54F79A8B@amazon.com>
 <353A970A-4C0A-499E-9B65-7C385C9BCC65@amazon.com>
 <20210324064207.GA15497@rincewind>
Message-ID: <7bf651c1-cacb-5451-7d3e-9c6599f88580@oracle.com>

On 23.03.2021 23:42, Andrew Hughes wrote:
> Yes, for some reason, I think I was under the delusion it was JDK code, not test code.
> As is, it's cleanup that was done for the modules system, but is applicable even before that.
> 
> I'm happy for your version to go in if you want to flag it with jdk8u-fix-request.

Just heads up, I see that a variety of tests updated to use the waitForIdle instead
of realsync, are you sure the fix for Robot.waitForIdle() was backported? In jdk 8u
the Robot.waitForIdle() was broken and this is why the realsync was used for testing.


-- 
Best regards, Sergey.

From hedongbo at huawei.com  Thu Mar 25 07:16:11 2021
From: hedongbo at huawei.com (hedongbo)
Date: Thu, 25 Mar 2021 07:16:11 +0000
Subject: [8u] RFR 8236179: C1 register allocation error with T_ADDRESS
Message-ID: <2f30b474ccbe48de8090e166835d7fb0@huawei.com>

Original fix:

  https://hg.openjdk.java.net/jdk/jdk/rev/59ddac265649

  https://bugs.openjdk.java.net/browse/JDK-8236179



8u(aarch64 platforms) webrev:

http://cr.openjdk.java.net/~dongbohe/8236179/webrev.00/







Aleksey's thread(https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-February/011165.html) does not include the aarch64 part.

Testing: tier1









Thanks,

dongbohe



From felix.yang at huawei.com  Thu Mar 25 07:45:17 2021
From: felix.yang at huawei.com (Yangfei (Felix))
Date: Thu, 25 Mar 2021 07:45:17 +0000
Subject: [8u] RFR 8236179: C1 register allocation error with T_ADDRESS
In-Reply-To: <2f30b474ccbe48de8090e166835d7fb0@huawei.com>
References: <2f30b474ccbe48de8090e166835d7fb0@huawei.com>
Message-ID: <c99ce4d81dfd4252898dff3b2795d0ac@huawei.com>

Hi,

  That looks good to me (Not a reviewer). 
  Since this is affecting our normal usage/deployment, I think it may be a candidate for inclusion in 8u292 during rampdown. 
  I will let 8u maintainers to decide. 

Thanks,
Felix

From: hedongbo 
Sent: Thursday, March 25, 2021 3:16 PM
To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject: [8u] RFR 8236179: C1 register allocation error with T_ADDRESS

Original fix:
? https://hg.openjdk.java.net/jdk/jdk/rev/59ddac265649
? https://bugs.openjdk.java.net/browse/JDK-8236179

8u(aarch64 platforms) webrev:
http://cr.openjdk.java.net/~dongbohe/8236179/webrev.00/



Aleksey's thread(https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-February/011165.html) does not include the aarch64 part.
Testing: tier1 




Thanks,
dongbohe



From sgehwolf at redhat.com  Thu Mar 25 09:05:44 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 25 Mar 2021 10:05:44 +0100
Subject: [8u] RFR 8236179: C1 register allocation error with T_ADDRESS
In-Reply-To: <2f30b474ccbe48de8090e166835d7fb0@huawei.com>
References: <2f30b474ccbe48de8090e166835d7fb0@huawei.com>
Message-ID: <45349e14acf2dd7aa269bad434816ec81c5bdc1c.camel@redhat.com>

Hi,

Since JDK-8236179 is already in jdk8u this warants a new, JDK 8u-only
bug for including the aarch64-specific parts.

Thanks,
Severin

On Thu, 2021-03-25 at 07:16 +0000, hedongbo wrote:
> Original fix:
> 
> ? https://hg.openjdk.java.net/jdk/jdk/rev/59ddac265649
> 
> ? https://bugs.openjdk.java.net/browse/JDK-8236179
> 
> 
> 
> 8u(aarch64 platforms) webrev:
> 
> http://cr.openjdk.java.net/~dongbohe/8236179/webrev.00/
> 
> 
> 
> 
> 
> 
> 
> Aleksey's
> thread(https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-February/011165.html
> ) does not include the aarch64 part.
> 
> Testing: tier1
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Thanks,
> 
> dongbohe
> 
> 



From aph at redhat.com  Thu Mar 25 09:36:32 2021
From: aph at redhat.com (Andrew Haley)
Date: Thu, 25 Mar 2021 09:36:32 +0000
Subject: [8u] RFR 8236179: C1 register allocation error with T_ADDRESS
In-Reply-To: <45349e14acf2dd7aa269bad434816ec81c5bdc1c.camel@redhat.com>
References: <2f30b474ccbe48de8090e166835d7fb0@huawei.com>
 <45349e14acf2dd7aa269bad434816ec81c5bdc1c.camel@redhat.com>
Message-ID: <f87d4c30-731e-63c3-09fe-75351be47eab@redhat.com>

On 3/25/21 9:05 AM, Severin Gehwolf wrote:
> Since JDK-8236179 is already in jdk8u this warants a new, JDK 8u-only
> bug for including the aarch64-specific parts.

Sounds good. Do we have a test case for 8u?

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From shade at redhat.com  Thu Mar 25 09:45:09 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 25 Mar 2021 10:45:09 +0100
Subject: [8u] RFR 8236179: C1 register allocation error with T_ADDRESS
In-Reply-To: <2f30b474ccbe48de8090e166835d7fb0@huawei.com>
References: <2f30b474ccbe48de8090e166835d7fb0@huawei.com>
Message-ID: <12671228-7d4a-3041-7da3-20898f1551ac@redhat.com>

On 3/25/21 8:16 AM, hedongbo wrote:
> 8u(aarch64 platforms) webrev:
> http://cr.openjdk.java.net/~dongbohe/8236179/webrev.00/

This looks fine to me. This is looks like a missing aarch64 hunk nearly verbatim.

> Aleksey's thread(https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-February/011165.html) does not include the aarch64 part.

D'oh. I thought I did that patch in aarch64-port/jdk8u downstream too, but apparently I did not. And 
since I filed no aarch64-specific issue against 8-aarch64 at the time, it went unnoticed until now, 
dang. Thanks for picking that up!

I agree with Felix, it is low-risk enough to consider for 8u292 rampdown.

-- 
Thanks,
-Aleksey


From sgehwolf at redhat.com  Thu Mar 25 09:53:43 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 25 Mar 2021 10:53:43 +0100
Subject: [8u] RFR 8236179: C1 register allocation error with T_ADDRESS
In-Reply-To: <f87d4c30-731e-63c3-09fe-75351be47eab@redhat.com>
References: <2f30b474ccbe48de8090e166835d7fb0@huawei.com>
 <45349e14acf2dd7aa269bad434816ec81c5bdc1c.camel@redhat.com>
 <f87d4c30-731e-63c3-09fe-75351be47eab@redhat.com>
Message-ID: <8ca8ff10bf849fdb4020806e0870a6219d7db884.camel@redhat.com>

On Thu, 2021-03-25 at 09:36 +0000, Andrew Haley wrote:
> Do we have a test case for 8u?

I don't think so. At least not that I can see. From the bug it seems to
be reproducible with Shenandoah or some Cassandra workloads (via the
CRC32 intrinsic). Aleksey pointed to this:
https://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/file/6021152f9ff3/src/cpu/x86/vm/c1_LIRGenerator_x86.cpp#l991

Thanks,
Severin



From jdowland at redhat.com  Thu Mar 25 09:58:19 2021
From: jdowland at redhat.com (Jonathan Dowland)
Date: Thu, 25 Mar 2021 09:58:19 +0000
Subject: [8u] RFR: 8187450: JNI local refs exceeds capacity warning in
 NetworkInterface::getAll
Message-ID: <20210325095819.fxhu3d5bjcsssxyl@qusp>

Good morning,

I'm requesting a review of a backport of JDK-8187450 to 8u.

The patch (from 11u backport) does not apply cleanly, just one hunk due
to extra #if defined(AF_INET6) in the context.

Bug: https://bugs.openjdk.java.net/browse/JDK-8187450
Webrev: https://cr.openjdk.java.net/~jdowland/webrevs/JDK-8187450/webrev.jdk8u.00/

Testing notes:

test/java/net/NetworkInterface/Test.java passes.

I had two tier1 failures that I am confident are unrelated, and also
fail for me against a known-good 8u:

    tools/javac/diags/CheckExamples.java: provide examples of code that generate diagnostics
    tools/javac/fatalErrors/NoJavaLangTest.java: Verify that the compiler does not crash when java.lang is not
they fail with jtreg

The rest of tier1 passed.

If you want to check out the impact this change makes, on a Linux host
you can use network namespaces to isolate the number of network
interfaces that are visible to Java, and steadily add more (virtual)
interfaces. There are some shell script snippets in the original GitHub
PR that might be useful:

    https://github.com/openjdk/jdk/pull/2963

My results comparing before/after this patch for 8u are

baseline, 2 network interfaces sufficient to breach the local refs limit:

    $ sudo ip netns exec jbase ip link show | grep UP | wc -l
     2
    $ sudo ip netns exec jbase $JAVA_HOME/bin/java -Xcheck:jni NITest
    WARNING: JNI local refs: 33, exceeds capacity: 32
	at java.net.NetworkInterface.getAll(Native Method)
	at java.net.NetworkInterface.getNetworkInterfaces(NetworkInterface.java:355)
	at NITest.main(NITest.java:4)

after patch, the first local refs breach occurs with 5 interfaces:

    ...
    $ ./addif.sh 4
    5 interfaces
    $ sudo ip netns exec jbase $JAVA_HOME/bin/java -Xcheck:jni NITest
    WARNING: JNI local refs: 33, exceeds capacity: 32
            at java.net.NetworkInterface.getAll(Native Method)
            at java.net.NetworkInterface.getNetworkInterfaces(NetworkInterface.java:355)
            at NITest.main(NITest.java:4)

after patch, it takes 10 interfaces to breach the next limit

    ...
    $ ./addif.sh 9
    10 interfaces
    $ sudo ip netns exec jbase $JAVA_HOME/bin/java -Xcheck:jni NITest
    WARNING: JNI local refs: 33, exceeds capacity: 32
            at java.net.NetworkInterface.getAll(Native Method)
            at java.net.NetworkInterface.getNetworkInterfaces(NetworkInterface.java:355)
            at NITest.main(NITest.java:4)
    WARNING: JNI local refs: 66, exceeds capacity: 65
            at java.net.NetworkInterface.getAll(Native Method)
            at java.net.NetworkInterface.getNetworkInterfaces(NetworkInterface.java:355)
            at NITest.main(NITest.java:4)


-- 
???? Jonathan Dowland <jdowland at redhat.com>
Senior Software Engineer, OpenJDK, Red Hat


From shade at redhat.com  Thu Mar 25 10:01:18 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 25 Mar 2021 11:01:18 +0100
Subject: [8u] RFR 8236179: C1 register allocation error with T_ADDRESS
In-Reply-To: <8ca8ff10bf849fdb4020806e0870a6219d7db884.camel@redhat.com>
References: <2f30b474ccbe48de8090e166835d7fb0@huawei.com>
 <45349e14acf2dd7aa269bad434816ec81c5bdc1c.camel@redhat.com>
 <f87d4c30-731e-63c3-09fe-75351be47eab@redhat.com>
 <8ca8ff10bf849fdb4020806e0870a6219d7db884.camel@redhat.com>
Message-ID: <8d1eb2fc-4d85-3682-07bf-e31d5851c9d2@redhat.com>

On 3/25/21 10:53 AM, Severin Gehwolf wrote:
> On Thu, 2021-03-25 at 09:36 +0000, Andrew Haley wrote:
>> Do we have a test case for 8u?
> 
> I don't think so. At least not that I can see. From the bug it seems to
> be reproducible with Shenandoah or some Cassandra workloads (via the
> CRC32 intrinsic). Aleksey pointed to this:
> https://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/file/6021152f9ff3/src/cpu/x86/vm/c1_LIRGenerator_x86.cpp#l991

Yeah, but that is for x86 CRC32, so we cannot see this on AArch64. I think it would only reproduce 
running Shenandoah. Maybe running jcstress with Shenandoah on current 8u would manifest like this. 
Let me try...

-- 
Thanks,
-Aleksey


From aph at redhat.com  Thu Mar 25 10:49:39 2021
From: aph at redhat.com (Andrew Haley)
Date: Thu, 25 Mar 2021 10:49:39 +0000
Subject: [8u] RFR 8236179: C1 register allocation error with T_ADDRESS
In-Reply-To: <12671228-7d4a-3041-7da3-20898f1551ac@redhat.com>
References: <2f30b474ccbe48de8090e166835d7fb0@huawei.com>
 <12671228-7d4a-3041-7da3-20898f1551ac@redhat.com>
Message-ID: <418e1a38-b91e-fc3c-3ba1-0c3ecda85a5d@redhat.com>

On 3/25/21 9:45 AM, Aleksey Shipilev wrote:
> I agree with Felix, it is low-risk enough to consider for 8u292 rampdown.

Sure. I was just baffled that this is the first time we've noticed this
bug in almost ten years. I guess if it's triggered by Shenandoah that
explains it.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From hedongbo at huawei.com  Thu Mar 25 11:08:35 2021
From: hedongbo at huawei.com (dongbo he)
Date: Thu, 25 Mar 2021 19:08:35 +0800
Subject: [8u] RFR 8236179: C1 register allocation error with T_ADDRESS
In-Reply-To: <f87d4c30-731e-63c3-09fe-75351be47eab@redhat.com>
References: <2f30b474ccbe48de8090e166835d7fb0@huawei.com>
 <45349e14acf2dd7aa269bad434816ec81c5bdc1c.camel@redhat.com>
 <f87d4c30-731e-63c3-09fe-75351be47eab@redhat.com>
Message-ID: <921518c1-3b41-46cb-1fb0-277bdccb11ef@huawei.com>

I created a new bug and webrev:

bug: https://bugs.openjdk.java.net/browse/JDK-8264171 
<https://bugs.openjdk.java.net/browse/JDK-8264171>
webrev: http://cr.openjdk.java.net/~dongbohe/8264171/webrev.00/ 
<http://cr.openjdk.java.net/~dongbohe/8264171/webrev.00/>

We discovered this problem during out internal development, and we 
currently have no reduced test case.

Thanks,
hedongbo

On 3/25/2021 5:36 PM, Andrew Haley wrote:
> On 3/25/21 9:05 AM, Severin Gehwolf wrote:
>> Since JDK-8236179 is already in jdk8u this warants a new, JDK 8u-only
>> bug for including the aarch64-specific parts.
> Sounds good. Do we have a test case for 8u?
>


From shade at redhat.com  Thu Mar 25 11:25:53 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 25 Mar 2021 12:25:53 +0100
Subject: [8u] RFR 8236179: C1 register allocation error with T_ADDRESS
In-Reply-To: <418e1a38-b91e-fc3c-3ba1-0c3ecda85a5d@redhat.com>
References: <2f30b474ccbe48de8090e166835d7fb0@huawei.com>
 <12671228-7d4a-3041-7da3-20898f1551ac@redhat.com>
 <418e1a38-b91e-fc3c-3ba1-0c3ecda85a5d@redhat.com>
Message-ID: <3047fa66-8c6a-45bb-9fbb-b9f7e612d5d9@redhat.com>

On 3/25/21 11:49 AM, Andrew Haley wrote:
> On 3/25/21 9:45 AM, Aleksey Shipilev wrote:
>> I agree with Felix, it is low-risk enough to consider for 8u292 rampdown.
> 
> Sure. I was just baffled that this is the first time we've noticed this
> bug in almost ten years. I guess if it's triggered by Shenandoah that
> explains it.

Yeah, AFAICS, you need to be running on AArch64, with Shenandoah actually entering the LRB slowpath 
under active GC, with C1 actually spilling the address argument on stack (?) due to a register 
pressure (?). This is pretty hard to come by unless you are (un)lucky.

I have not been able to reproduce it just now.

Well, maybe that's an argument to leave it for 8u302, actually.

-- 
Thanks,
-Aleksey


From hohensee at amazon.com  Thu Mar 25 19:46:19 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 25 Mar 2021 19:46:19 +0000
Subject: RFR [8u] JDK-8239798 : SSLSocket closes socket both socket
 endpoints on a SocketTimeoutException
Message-ID: <434E6209-7188-4DD4-BC73-FAB56F6B354D@amazon.com>

Webrev with fixed copyright header (and copyright dates): https://cr.openjdk.java.net/~phh/8239798/webrev.8u.jdk.01/

Thanks,
Paul

?-----Original Message-----
From: Andrew Hughes <gnu.andrew at redhat.com>
Date: Wednesday, March 24, 2021 at 9:00 AM
To: "Hohensee, Paul" <hohensee at amazon.com>
Cc: "Alvarez, David" <alvdavi at amazon.com>, "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: RE: RFR [8u] JDK-8239798 : SSLSocket closes socket both socket endpoints on a SocketTimeoutException

On 02:30 Wed 17 Mar     , Hohensee, Paul wrote:
> Lgtm.
> 
> Thanks,
> Paul
> 
> ?-----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of "Alvarez, David" <alvdavi at amazon.com>
> Date: Monday, February 15, 2021 at 9:58 PM
> To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
> Subject: RFR [8u] JDK-8239798 : SSLSocket closes socket both socket endpoints on a SocketTimeoutException
> 
> Hi,
> 
> I would like to request a review for JDK-8239798
> 
> Original bug: https://bugs.openjdk.java.net/browse/JDK-8239798
> Webrev:
> http://cr.openjdk.java.net/~alvdavi/webrevs/8239798/webrev.8u.jdk.00/
> 
> The backport is mostly clean, except for some changes in
> SSLSocketInputRecord.java to account for DTLS removal in 8u [1]
> 
> This is one of a set of multiple patches TLS1.3 patches that were added
> to 11u after 11.0.7 that did not make it into 8u.
> 
> All jdk tier1 test pass.
> 
> Thanks,
> 
> David
> 
> --
> [1] https://bugs.openjdk.java.net/browse/JDK-8245469
> 
> 

Only minor thing is the copyright header is not added to
SSLSocketInputRecord.java.  It's an addition of a different copyright
holder, so should be added despite the Oracle copyright including
2020.

Part of the SSLSocketInputRecord.java diff was a little hard to
compare with the 11u version, presumably due to whitespace issues.
However, the patched version looks the same as 11u, but without the
copyright header, JDK-8171279: "Support X25519 and X448 in TLS" and
JDK-8228757: "Fail fast if the handshake type is unknown".

Is JDK-8228757 on your todo list? It's marked as resolved in Oracle's
8u261. If not, I can take a look.

As to this patch, should be good to go once the copyright header is
added.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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  Thu Mar 25 20:19:45 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 25 Mar 2021 20:19:45 +0000
Subject: [8u]: 8136592: [TEST_BUG] Fix 2 platform-specific closed regtests
 for jigsaw
Message-ID: <29FF31B0-6D89-46E6-B887-5D48136F543A@amazon.com>

Thanks, Andrew. Pushed.

?-----Original Message-----
From: Andrew Hughes <gnu.andrew at redhat.com>
Date: Wednesday, March 24, 2021 at 12:08 AM
To: "Hohensee, Paul" <hohensee at amazon.com>
Cc: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: RE: [8u]: 8136592: [TEST_BUG] Fix 2 platform-specific closed regtests for jigsaw

On 20:24 Thu 18 Mar     , Hohensee, Paul wrote:
> Ping. :)
> 
> Thanks,
> Paul
> 
> ?-----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of "Hohensee, Paul" <hohensee at amazon.com>
> Date: Wednesday, February 24, 2021 at 1:42 PM
> To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
> Subject: [8u]: 8136592: [TEST_BUG] Fix 2 platform-specific closed regtests for jigsaw
> 
> Please review this test-only backport. The JBS issue is private, so I can?t create a backport issue. We?ll have to rely on hg-updater when pushed, and maintainer approval will have to be on the list.
> 
> Original patch: http://hg.openjdk.java.net/jdk-updates/jdk9u/jdk/rev/ddc8bbf88d36
> 8u webrev: http://cr.openjdk.java.net/~phh/8136592/webrev.8u.jdk.02/
> 
> The @modules attributes have been removed, and implicit casts have been replaced by explicit ones to XEmbedCanvasPeer, FramePeer, and ListPeer. The first two required importing sun.awt.X11.*.
> 
> The two new tests pass.
> 
> Thanks,
> Paul
> 
> 

Patch looks good to me. You can consider this as a review and approval
under the circumstances :-)

I don't see a problem with backporting the test, even though it has
issues in certain environments. As you noted, that's just a reason to
improve it in HEAD and backport the fix too. Most tests can no doubt
be improved. It can still catch some issues in its current form.

Going by the title, this test has existed even longer, but was in
Oracle's closed repositories.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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  Thu Mar 25 20:36:41 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 25 Mar 2021 20:36:41 +0000
Subject: [8u] RFR: JDK-8261867: Backport relevant test changes & additions
 from JDK-8130125
Message-ID: <AE9847B4-5961-4322-8A32-98666AAB7983@amazon.com>

Point to the JBS issues for the fix please?

Thanks,
Paul

?-----Original Message-----
From: Sergey Bylokhov <Sergey.Bylokhov at oracle.com>
Date: Wednesday, March 24, 2021 at 5:23 PM
To: Andrew Hughes <gnu.andrew at redhat.com>, "Hohensee, Paul" <hohensee at amazon.com>
Cc: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: RE: [8u] RFR: JDK-8261867: Backport relevant test changes & additions from JDK-8130125

On 23.03.2021 23:42, Andrew Hughes wrote:
> Yes, for some reason, I think I was under the delusion it was JDK code, not test code.
> As is, it's cleanup that was done for the modules system, but is applicable even before that.
>
> I'm happy for your version to go in if you want to flag it with jdk8u-fix-request.

Just heads up, I see that a variety of tests updated to use the waitForIdle instead
of realsync, are you sure the fix for Robot.waitForIdle() was backported? In jdk 8u
the Robot.waitForIdle() was broken and this is why the realsync was used for testing.


--
Best regards, Sergey.


From hohensee at amazon.com  Thu Mar 25 20:47:11 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 25 Mar 2021 20:47:11 +0000
Subject: [8u] RFR: JDK-8261867: Backport relevant test changes & additions
 from JDK-8130125
Message-ID: <2DB53C2B-BA3D-42AA-BDB0-DAFC7088742F@amazon.com>

Thanks, Andrew. Tagged.

Jonathan Dowland notes that we might have missed backporting fixes to Robot.waitForIdle(). Since we already have tests that use it, I propose we push this patch and do any backports to fix waitForIdle() separately.

Thanks,
Paul

?-----Original Message-----
From: Andrew Hughes <gnu.andrew at redhat.com>
Date: Tuesday, March 23, 2021 at 11:42 PM
To: "Hohensee, Paul" <hohensee at amazon.com>
Cc: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: RE: [8u] RFR: JDK-8261867: Backport relevant test changes & additions from JDK-8130125

On 23:15 Wed 17 Mar     , Hohensee, Paul wrote:
> Another mistake on my part: your webrev includes the comment change in test/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java.
>

Yes, your initial comments did confuse me a little :-)

> I added the changes to test/java/awt/Focus/8073453/AWTFocusTransitionTest.java, test/java/awt/Focus/8073453/SwingFocusTransitionTest.java, and test/java/awt/xembed/server/TestXEmbedServer.java. The first two pass as before. The third is a bit unstable, but the manual portion seems more stable than before the change. 
> 
> Webrev: https://cr.openjdk.java.net/~phh/8261867/webrev.8u.jdk.00/
>

Yes, for some reason, I think I was under the delusion it was JDK code, not test code.
As is, it's cleanup that was done for the modules system, but is applicable even before that.

I'm happy for your version to go in if you want to flag it with jdk8u-fix-request.

> Thanks,
> Paul
>

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 preethis00 at gmail.com  Fri Mar 26 10:12:35 2021
From: preethis00 at gmail.com (preethi selvaraj)
Date: Fri, 26 Mar 2021 15:42:35 +0530
Subject: Jdk8u: libfontmanager.so: symbol FT_Library_SetLcdFilter: Error
In-Reply-To: <CAMjaTRNwHDt6UPnE=q3KTXPC8H6++N7C2Qmq3Ypo9SRS974N6A@mail.gmail.com>
References: <CAMjaTRNwHDt6UPnE=q3KTXPC8H6++N7C2Qmq3Ypo9SRS974N6A@mail.gmail.com>
Message-ID: <CAF7k0J0sz9q=f1DaQ=uB5OFPbYjjRzHn194bRyBfvcefKWeQ-w@mail.gmail.com>

Hi Team,

I've checked out jdk8u292_b07 tag source and created jdk binaries. When
building my project with this jdk, getting below error.

[ia] ld.so.1: java: fatal: relocation error: file
/common/java/jdk1.8.0_292/jre/lib/amd64/libfontmanager.so: symbol
FT_Library_SetLcdFilter: referenced symbol not found

With previously generated jdks(may be prior to 01/2021 security update)
i've never faced any issues like this.

Anything i missed during configure? how to resolve this?

Regards,
Preethi

From Sergey.Bylokhov at oracle.com  Sat Mar 27 04:54:22 2021
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 26 Mar 2021 21:54:22 -0700
Subject: [External] : RE: [8u] RFR: JDK-8261867: Backport relevant test
 changes & additions from JDK-8130125
In-Reply-To: <AE9847B4-5961-4322-8A32-98666AAB7983@amazon.com>
References: <AE9847B4-5961-4322-8A32-98666AAB7983@amazon.com>
Message-ID: <12b6ad47-462a-4f2d-23b7-c87b26c2b8e1@oracle.com>

On 25.03.2021 13:36, Hohensee, Paul wrote:
> Point to the JBS issues for the fix please?

At least these:
JDK-8056911, JDK-8076178

> 
> Thanks,
> Paul
> 
> ?-----Original Message-----
> From: Sergey Bylokhov <Sergey.Bylokhov at oracle.com>
> Date: Wednesday, March 24, 2021 at 5:23 PM
> To: Andrew Hughes <gnu.andrew at redhat.com>, "Hohensee, Paul" <hohensee at amazon.com>
> Cc: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
> Subject: RE: [8u] RFR: JDK-8261867: Backport relevant test changes & additions from JDK-8130125
> 
> On 23.03.2021 23:42, Andrew Hughes wrote:
>> Yes, for some reason, I think I was under the delusion it was JDK code, not test code.
>> As is, it's cleanup that was done for the modules system, but is applicable even before that.
>>
>> I'm happy for your version to go in if you want to flag it with jdk8u-fix-request.
> 
> Just heads up, I see that a variety of tests updated to use the waitForIdle instead
> of realsync, are you sure the fix for Robot.waitForIdle() was backported? In jdk 8u
> the Robot.waitForIdle() was broken and this is why the realsync was used for testing.
> 
> 
> --
> Best regards, Sergey.
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Sat Mar 27 05:11:02 2021
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 26 Mar 2021 22:11:02 -0700
Subject: [External] : RE: [8u] RFR: JDK-8261867: Backport relevant test
 changes & additions from JDK-8130125
In-Reply-To: <12b6ad47-462a-4f2d-23b7-c87b26c2b8e1@oracle.com>
References: <AE9847B4-5961-4322-8A32-98666AAB7983@amazon.com>
 <12b6ad47-462a-4f2d-23b7-c87b26c2b8e1@oracle.com>
Message-ID: <e79f0a43-a3a8-802f-a4fe-b7fbeed1b0e3@oracle.com>

On 26.03.2021 21:54, Sergey Bylokhov wrote:
> On 25.03.2021 13:36, Hohensee, Paul wrote:
>> Point to the JBS issues for the fix please?
> 
> At least these:
> JDK-8056911, JDK-8076178

But it will cause the bugs in the realSync to be visible through the public API(Robot#waitForIdle)
So it is up2to the 8u maintainers to decide what to do.

> 
>>
>> Thanks,
>> Paul
>>
>> ?-----Original Message-----
>> From: Sergey Bylokhov <Sergey.Bylokhov at oracle.com>
>> Date: Wednesday, March 24, 2021 at 5:23 PM
>> To: Andrew Hughes <gnu.andrew at redhat.com>, "Hohensee, Paul" <hohensee at amazon.com>
>> Cc: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
>> Subject: RE: [8u] RFR: JDK-8261867: Backport relevant test changes & additions from JDK-8130125
>>
>> On 23.03.2021 23:42, Andrew Hughes wrote:
>>> Yes, for some reason, I think I was under the delusion it was JDK code, not test code.
>>> As is, it's cleanup that was done for the modules system, but is applicable even before that.
>>>
>>> I'm happy for your version to go in if you want to flag it with jdk8u-fix-request.
>>
>> Just heads up, I see that a variety of tests updated to use the waitForIdle instead
>> of realsync, are you sure the fix for Robot.waitForIdle() was backported? In jdk 8u
>> the Robot.waitForIdle() was broken and this is why the realsync was used for testing.
>>
>>
>> -- 
>> Best regards, Sergey.
>>
> 
> 


-- 
Best regards, Sergey.

From gnu.andrew at redhat.com  Mon Mar 29 02:41:15 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 29 Mar 2021 03:41:15 +0100
Subject: OpenJDK 8u292-b08 EA Released
Message-ID: <20210329024115.GA167024@rincewind>

I've made available an early access source bundle for 8u282, based on
the tag jdk8u292-b08:

https://openjdk-sources.osci.io/openjdk8/openjdk8u292-b08-ea.tar.xz

The tarball is accompanied by a digital signature available at:

https://openjdk-sources.osci.io/openjdk8/openjdk8u292-b08-ea.tar.xz.sig

This is signed by our Red Hat OpenJDK key (openjdk at redhat.com):

PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net)
Fingerprint: CA5F 11C6 CE22 644D 42C6  AC44 92EF 8D39 DC13 168F

SHA256 checksums:

74eef0de6a2d6edf0b4b67d1c91dfcd81bb15b8463dd557dc07ef89301cd4284  openjdk8u292-b08-ea.tar.xz
7031892a756725fdf42d5c22d160f71342db51f017dcb070484d4266b85feacb  openjdk8u292-b08-ea.tar.xz.sig

They are listed at
https://openjdk-sources.osci.io/openjdk8/openjdk8u292-b08-ea.sha256

Changes in 8u292-b08:
  - JDK-8191915: JCK tests produce incorrect results with C2
  - JDK-8256421: Add 2 HARICA roots to cacerts truststore
  - JDK-8260356: (tz) Upgrade time-zone data to tzdata2021a

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 gnu.andrew at redhat.com  Mon Mar 29 02:54:41 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 29 Mar 2021 03:54:41 +0100
Subject: OpenJDK 8u292-b09 EA Released
Message-ID: <20210329025441.GA167732@rincewind>

I've made available an early access source bundle for 8u292, based on
the tag jdk8u292-b09:

https://openjdk-sources.osci.io/openjdk8/openjdk8u292-b09-ea.tar.xz

The tarball is accompanied by a digital signature available at:

https://openjdk-sources.osci.io/openjdk8/openjdk8u292-b09-ea.tar.xz.sig

This is signed by our new Red Hat OpenJDK key (openjdk at redhat.com):

PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net)
Fingerprint: CA5F 11C6 CE22 644D 42C6  AC44 92EF 8D39 DC13 168F

SHA256 checksums:

a16ecf1ad9da781e9951182ddfb79c9a6c2006b095e22ec8950f2d14eaa71f1f  openjdk8u292-b09-ea.tar.xz
1154a1a3cedd66d96b91e8f7e2667f30d861c0ae4cd2e5b225db9cf4eb1fb621  openjdk8u292-b09-ea.tar.xz.sig

They are listed at
https://openjdk-sources.osci.io/openjdk8/openjdk8u292-b09-ea.sha256

Changes in 8u292-b09:
  - JDK-8264171: Missing aarch64 parts of JDK-8236179 (C1 register allocation failure with T_ADDRESS)

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 gnu.andrew at redhat.com  Mon Mar 29 02:57:18 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 29 Mar 2021 03:57:18 +0100
Subject: [FREEZE] 8u292 NOW FROZEN
Message-ID: <20210329025718.GA169007@rincewind>

The release forest:

https://hg.openjdk.java.net/jdk8u/jdk8u (and friends)

is now frozen in preparation for release on 2021-04-20.

The final pre-release tag is jdk8u292-b09.

The final release tag will be no lower than jdk8u292-b10.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 felix.yang at huawei.com  Mon Mar 29 03:12:37 2021
From: felix.yang at huawei.com (Yangfei (Felix))
Date: Mon, 29 Mar 2021 03:12:37 +0000
Subject: RFR: 8182036: Load from initializing arraycopy uses wrong memory state
Message-ID: <53cea81868c34cbc9d90258c8478df19@huawei.com>

Hi,

Please review this 8u backport fixing an user-visible C2 bug.

Original bug: https://bugs.openjdk.java.net/browse/JDK-8182036 
Original patch: http://hg.openjdk.java.net/jdk10/jdk10/hotspot/rev/fe7fdd0fc266 
Original review thread: https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-June/026448.html 

Webrev for 8u: http://cr.openjdk.java.net/~fyang/8182036-8u/webrev.00  

This bug can always reproduced by running the provided test case with 8u on x86_64 or aarch64 linux.
The AArch64 C2 JIT code snippet with & without the fix is shown here [1] [2]. 

I think we only needs this part for 8u (quotation from the original review thread):
"
Initialization of dst is performed by the
arraycopy. PhaseMacroExpand::generate_block_arraycopy() generates a
load/store pair to copy the element at offset 1 so it can bulk copy the
elements starting at offset 2. Both the load and store are on the same
slice which for an initializing arraycopy is raw memory. So the src[1]
load and the src[1] = 0x42 store are not on the same slice and the load
can happen before the store resulting in an incorrect execution.

The fix I propose is for the load to be from the src's slice.
"

The rest of the original fix is not needed for 8u as it's related to the following two issues which is not there in 8u:
    8076188: Optimize arraycopy out for non escaping destination
    8150933: System::arraycopy intrinsic doesn't mark mismatched loads

Performed full jtreg test on both x86_64 and aarch64 Linux.
Newly added jtreg test fails without the patch and passes otherwise.
OK to backport? 

Thanks,
Felix

[1]. AArch64 C2 JIT code without patch:

284   ;; B5: #      N1 <- B9 B4  Freq: 1
285
286   ;; 0x42
287   0x0000ffff8d01e13c: mov       w11, #0x42                      // #66
288   0x0000ffff8d01e140: str       xzr, [x19, #16]  ;*invokestatic arraycopy
289                                                 ; - TestInitializingACLoadWithBadMem::test1 at 25 (line 14)
290
291   0x0000ffff8d01e144: str       w11, [x14, #20]  ;*iastore
292                                                 ; - TestInitializingACLoadWithBadMem::test1 at 18 (line 11)
293
294   0x0000ffff8d01e148: str       wzr, [x19, #20]        <================  store wrong value 0
295   ;; 0x4
296   0x0000ffff8d01e14c: orr       x2, xzr, #0x4
297   0x0000ffff8d01e150: add       x1, x19, #0x18
298   0x0000ffff8d01e154: add       x0, x14, #0x18
299   0x0000ffff8d01e158: bl        Stub::arrayof_jlong_disjoint_arraycopy
300                                                 ;*invokestatic arraycopy
301                                                 ; - TestInitializingACLoadWithBadMem::test1 at 25 (line 14)
302                                                 ;   {runtime_call}

[2]. AArch64 C2 JIT code with patch:

284   ;; B5: #      N1 <- B9 B4  Freq: 1
285
286   ;; 0x42
287   0x0000ffff9d01e03c: mov       w11, #0x42                      // #66
288   0x0000ffff9d01e040: str       xzr, [x19, #16]  ;*invokestatic arraycopy
289                                                 ; - TestInitializingACLoadWithBadMem::test1 at 25 (line 14)
290
291   0x0000ffff9d01e044: str       w11, [x14, #20]  ;*iastore
292                                                 ; - TestInitializingACLoadWithBadMem::test1 at 18 (line 11)
293
294   0x0000ffff9d01e048: str       w11, [x19, #20]        <================  store correct value 0x42
295   ;; 0x4
296   0x0000ffff9d01e04c: orr       x2, xzr, #0x4
297   0x0000ffff9d01e050: add       x1, x19, #0x18
298   0x0000ffff9d01e054: add       x0, x14, #0x18
299   0x0000ffff9d01e058: bl        Stub::arrayof_jlong_disjoint_arraycopy
300                                                 ;*invokestatic arraycopy
301                                                 ; - TestInitializingACLoadWithBadMem::test1 at 25 (line 14)
302                                                 ;   {runtime_call}



From gnu.andrew at redhat.com  Mon Mar 29 03:25:57 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 29 Mar 2021 04:25:57 +0100
Subject: RFR [8u] JDK-8239798 : SSLSocket closes socket both socket
 endpoints on a SocketTimeoutException
In-Reply-To: <434E6209-7188-4DD4-BC73-FAB56F6B354D@amazon.com>
References: <434E6209-7188-4DD4-BC73-FAB56F6B354D@amazon.com>
Message-ID: <20210329032557.GA169175@rincewind>

On 19:46 Thu 25 Mar     , Hohensee, Paul wrote:
> Webrev with fixed copyright header (and copyright dates): https://cr.openjdk.java.net/~phh/8239798/webrev.8u.jdk.01/
> 
> Thanks,
> Paul
> 

SSLSocketInputRecord.java now looks correct.

Why are copyright changes being made to
src/share/classes/sun/security/ssl/SSLTransport.java,
test/sun/security/ssl/SSLSocketImpl/ClientTimeout.java and
test/jdk/sun/security/ssl/SSLSocketImpl/SSLExceptionForIOIssue.java?

These changes are not in the original backport patch and also
not in 11u at all. If this is necessary, it should go to 11u
(and possibly HEAD) first in its own patch, so we don't create
local divergence.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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 jhuttana at redhat.com  Mon Mar 29 06:18:07 2021
From: jhuttana at redhat.com (Jayashree Huttanagoudar)
Date: Mon, 29 Mar 2021 11:48:07 +0530
Subject: Jdk8u: libfontmanager.so: symbol FT_Library_SetLcdFilter: Error
In-Reply-To: <CAF7k0J0sz9q=f1DaQ=uB5OFPbYjjRzHn194bRyBfvcefKWeQ-w@mail.gmail.com>
References: <CAMjaTRNwHDt6UPnE=q3KTXPC8H6++N7C2Qmq3Ypo9SRS974N6A@mail.gmail.com>
 <CAF7k0J0sz9q=f1DaQ=uB5OFPbYjjRzHn194bRyBfvcefKWeQ-w@mail.gmail.com>
Message-ID: <CAJ8kv5O6vWgiKmENjz1sDcwqnKnBEHrBV4XEmJhc1g_Rtv4qng@mail.gmail.com>

Hi Preethi,

On Fri, Mar 26, 2021 at 10:10 PM preethi selvaraj <preethis00 at gmail.com>
wrote:

> Hi Team,
>
> I've checked out jdk8u292_b07 tag source and created jdk binaries. When
> building my project with this jdk, getting below error.
>
> [ia] ld.so.1: java: fatal: relocation error: file
> /common/java/jdk1.8.0_292/jre/lib/amd64/libfontmanager.so: symbol
> FT_Library_SetLcdFilter: referenced symbol not found
>
> With previously generated jdks(may be prior to 01/2021 security update)
> i've never faced any issues like this.
>
> Anything i missed during configure? how to resolve this?
>

Have you set LD_LIBRARY_PATH ?
I don't see any change in readelf output for jdk8u292_b06 and jdk8u292_b07
w.r.t the symbol 'FT_Library_SetLcdFilter' libfontmanager.so.

Thanks & Regards,
Jaya

>
> Regards,
> Preethi
>
>

From alvdavi at amazon.com  Mon Mar 29 08:26:00 2021
From: alvdavi at amazon.com (Alvarez, David)
Date: Mon, 29 Mar 2021 01:26:00 -0700
Subject: Jdk8u: libfontmanager.so: symbol FT_Library_SetLcdFilter: Error
In-Reply-To: <CAJ8kv5O6vWgiKmENjz1sDcwqnKnBEHrBV4XEmJhc1g_Rtv4qng@mail.gmail.com>
References: <CAMjaTRNwHDt6UPnE=q3KTXPC8H6++N7C2Qmq3Ypo9SRS974N6A@mail.gmail.com>
 <CAF7k0J0sz9q=f1DaQ=uB5OFPbYjjRzHn194bRyBfvcefKWeQ-w@mail.gmail.com>
 <CAJ8kv5O6vWgiKmENjz1sDcwqnKnBEHrBV4XEmJhc1g_Rtv4qng@mail.gmail.com>
Message-ID: <873844a7-fc64-372e-01da-714c38749b35@amazon.com>

Hi,

I've seen this issue in the past, basically it means the version of
Freetype in the system is older than the one used to build the JDK (old
enough that it doesn't contain FT_Library_SetLcdFilter). According to
the documentation, this was added in Freetype 2.3.0 [1]. This wasn't an
issue until the dependency of OpenJDK8 on this function was added by
JDK-8212071 [2]. But that was added on 8u242, so when you say prior to
01/2021, we are talking about at least one year.

In order to solve this issue, you have three options:
- Update your system Freetype to 2.3.0 or higher
- Build a 2.3.0 or higher version in your system and play with
LD_LIBRARY_PATH
- Use a JDK that has freetype statically linked, but I'm not aware of
any public distribution that does it.

Regards,

David

---
[1]
https://tools.ietf.org/doc/libfreetype6/reference/ft2-lcd_filtering.html#FT_Library_SetLcdFilter
[2] https://bugs.openjdk.java.net/browse/JDK-8212071


On 3/28/21 11:18 PM, Jayashree Huttanagoudar wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> 
> 
> 
> Hi Preethi,
> 
> On Fri, Mar 26, 2021 at 10:10 PM preethi selvaraj <preethis00 at gmail.com>
> wrote:
> 
>> Hi Team,
>>
>> I've checked out jdk8u292_b07 tag source and created jdk binaries. When
>> building my project with this jdk, getting below error.
>>
>> [ia] ld.so.1: java: fatal: relocation error: file
>> /common/java/jdk1.8.0_292/jre/lib/amd64/libfontmanager.so: symbol
>> FT_Library_SetLcdFilter: referenced symbol not found
>>
>> With previously generated jdks(may be prior to 01/2021 security update)
>> i've never faced any issues like this.
>>
>> Anything i missed during configure? how to resolve this?
>>
> 
> Have you set LD_LIBRARY_PATH ?
> I don't see any change in readelf output for jdk8u292_b06 and jdk8u292_b07
> w.r.t the symbol 'FT_Library_SetLcdFilter' libfontmanager.so.
> 
> Thanks & Regards,
> Jaya
> 
>>
>> Regards,
>> Preethi
>>
>>


From hohensee at amazon.com  Wed Mar 31 20:43:52 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 31 Mar 2021 20:43:52 +0000
Subject: PING? RE: RFR: 8258669: fastdebug jvm crashes when do event based
 tracing for monitor inflation
Message-ID: <F2671424-2E25-4836-A7CA-CCDADF8D6A20@amazon.com>

Lgtm.

Thanks,
Paul

?-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of "Yangfei (Felix)" <felix.yang at huawei.com>
Date: Wednesday, February 17, 2021 at 7:26 PM
To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: RE: PING? RE: RFR: 8258669: fastdebug jvm crashes when do event based tracing for monitor inflation

Hi,

  Anyone want to take a look at this?
  As this adds back "cause" information for the monitor inflation event, it should also improves basic functionality of 8u JFR event-based tracing.

Thanks,
Felix

> -----Original Message-----
> From: Yangfei (Felix)
> Sent: Tuesday, January 12, 2021 3:39 PM
> To: 'jdk8u-dev at openjdk.java.net' <jdk8u-dev at openjdk.java.net>
> Subject: PING? RE: RFR: 8258669: fastdebug jvm crashes when do event
> based tracing for monitor inflation
>
> Any comments?
>
> > -----Original Message-----
> > From: Yangfei (Felix)
> > Sent: Friday, December 18, 2020 8:35 PM
> > To: jdk8u-dev at openjdk.java.net
> > Subject: RFR: 8258669: fastdebug jvm crashes when do event based
> > tracing for monitor inflation
> >
> > Hi,
> >
> >     Bug: https://bugs.openjdk.java.net/browse/JDK-8258669
> >     Webrev: http://cr.openjdk.java.net/~fyang/8258669/webrev.00
> >
> >     By referencing jdk11u, I think the reason is that we are not
> > setting the "cause" in post_monitor_inflate_event for jdk8u.
> >     Proposed patch adds back the missing code changes in: 8138562:
> > Event based tracing should cover monitor inflation. Also enabled code
> > in MonitorInflateCauseConstant::serialize.
> >     Since this only adds some extra "cause" information for the
> > monitor inflation event, I think it should be low risk.
> >     Performed full jtreg test based on the latest jdk8u-dev.  OK?
> >
> > Thanks,
> > Felix