From dholmes at openjdk.java.net  Wed Dec  1 01:32:28 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 1 Dec 2021 01:32:28 GMT
Subject: RFR: 8276901: Implement UseHeavyMonitors consistently [v4]
In-Reply-To: <W4NBmZlPhk5djtaRNtiz-m0-St3wA-izzPOvBUoE9pM=.184c6b8d-7d3b-4371-8b7d-639674e6eaf6@github.com>
References: <CqBVDMLRhPl93f8gcv5VX0Un-fFF5BQtGEwrczIJdp4=.6a50ad8f-3bbe-4075-9f8c-ee4da37e9f8b@github.com>
 <CTfyJ4qGGJKeCJLCEFHdOvcUr_R0WIPTNrkg0G85s5g=.7199fbdd-4f99-4d63-8804-75ec559e05f2@github.com>
 <7GuyRoJ653qrQDv-vEnRU7JMcZU6qZJi0j7Ty1b5PE4=.c7d00b3d-c23b-47f9-bfb6-258623c2faae@github.com>
 <W4NBmZlPhk5djtaRNtiz-m0-St3wA-izzPOvBUoE9pM=.184c6b8d-7d3b-4371-8b7d-639674e6eaf6@github.com>
Message-ID: <amfTSD-WAXfcBUaBNqvf98rEtoOdg1nnyZBHuIv9WUQ=.f4b3accb-ef85-47b4-a8fc-7a225f9f18db@github.com>

On Tue, 30 Nov 2021 17:22:28 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> > IIUC you are only making UseHeavyMonitors work properly on x86_64, but in that case you cannot convert UseFastLocks to UseHeavyMonitors on all platforms as it won't work correctly on those other platforms.
> > Cheers, David
> 
> It would not break as such on other platforms. It would only be partially implemented, that is C1 would emit calls to runtime for and only use monitors while interpreter and C2 would still emit stack locks. That is ok - and that is roughly what +UseFastLocking used to do.

Sorry but I don't see how having the interpreter+C2 use stack-locks while C1 ignores them can possibly be correct. ???

-------------

PR: https://git.openjdk.java.net/jdk/pull/6320

From dholmes at openjdk.java.net  Wed Dec  1 02:21:29 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 1 Dec 2021 02:21:29 GMT
Subject: RFR: 8277946: NMT: Deprecate and remove VM.native_memory shutdown
 jcmd command option
In-Reply-To: <1AUR5fN21yPlHCpFVHUGvMMJm7pJT2NoGTGx2E-tz2o=.c5c66ba5-15f4-4708-a815-b4059039005c@github.com>
References: <1AUR5fN21yPlHCpFVHUGvMMJm7pJT2NoGTGx2E-tz2o=.c5c66ba5-15f4-4708-a815-b4059039005c@github.com>
Message-ID: <qj6QpXuN8iQrbOm_MqMuLwRcYP5jDgLCzwHsRbo2pF8=.c55bbf3e-ac64-4987-a4cc-9d80ea74b3fe@github.com>

On Tue, 30 Nov 2021 15:17:10 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> NMT shutdown functionality is a remnant of its first implementation, which could consume excessive amount of memory, therefore, it needed capability to shut it self down to ensure health of JVM. This is no longer a case for new implementation.
> 
> NMT shutdown can be requested via Jcmd. However, it is rare used.
> 
> We should deprecate for shutdown Jcmd command for removing NMT shutdown functionality.
> 
> Corresponding [CSR](https://bugs.openjdk.java.net/browse/JDK-8277947) has been approved.

Hi Zhengyu,

I am fine with removal of the shutdown option of the jcmd as presented, but as per the CSR request I think "Deprecate" has to be removed from this as nothing has been deprecated.

I'm not at all clear why the actual shutdown mechanics removal has been deferred to another issue - that would make sense if this PR actually just deprecated something, but as it is I would have expected everything to go. With RDP1 upon us I assume the actual removal will now be in 19.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6618

From zgu at openjdk.java.net  Wed Dec  1 03:05:29 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 1 Dec 2021 03:05:29 GMT
Subject: RFR: 8277946: NMT: Deprecate and remove VM.native_memory shutdown
 jcmd command option
In-Reply-To: <qj6QpXuN8iQrbOm_MqMuLwRcYP5jDgLCzwHsRbo2pF8=.c55bbf3e-ac64-4987-a4cc-9d80ea74b3fe@github.com>
References: <1AUR5fN21yPlHCpFVHUGvMMJm7pJT2NoGTGx2E-tz2o=.c5c66ba5-15f4-4708-a815-b4059039005c@github.com>
 <qj6QpXuN8iQrbOm_MqMuLwRcYP5jDgLCzwHsRbo2pF8=.c55bbf3e-ac64-4987-a4cc-9d80ea74b3fe@github.com>
Message-ID: <v66NIk9C8Ye_G8ItXq2E734xChPEswNLY97jYI05mhc=.b61d2a44-a76e-41c9-977d-19c4a33fecd1@github.com>

On Wed, 1 Dec 2021 02:18:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi Zhengyu,
> 
> I am fine with removal of the shutdown option of the jcmd as presented, but as per the CSR request I think "Deprecate" has to be removed from this as nothing has been deprecated.
> 
> I'm not at all clear why the actual shutdown mechanics removal has been deferred to another issue - that would make sense if this PR actually just deprecated something, but as it is I would have expected everything to go. With RDP1 upon us I assume the actual removal will now be in 19.
> 
> Thanks, David

Hi David,

Thanks for the review. I were not sure I should remove shutdown mechanics with this CR, as it only mentions jcmd part and there is auto-shutdown part also. 

I already have the second change ready, will PR tomorrow, it is quite large through.

-Zhengyu

-------------

PR: https://git.openjdk.java.net/jdk/pull/6618

From rkennke at openjdk.java.net  Wed Dec  1 12:36:02 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 1 Dec 2021 12:36:02 GMT
Subject: RFR: 8276901: Implement UseHeavyMonitors consistently [v10]
In-Reply-To: <CqBVDMLRhPl93f8gcv5VX0Un-fFF5BQtGEwrczIJdp4=.6a50ad8f-3bbe-4075-9f8c-ee4da37e9f8b@github.com>
References: <CqBVDMLRhPl93f8gcv5VX0Un-fFF5BQtGEwrczIJdp4=.6a50ad8f-3bbe-4075-9f8c-ee4da37e9f8b@github.com>
Message-ID: <___2nS2ZNEiggHv_C70jADW_cE-T2wUJKqRK_J5gIj0=.23da20f8-ba19-4279-b154-f0a67626ccf4@github.com>

> The flag UseHeavyMonitors seems to imply that it makes Hotspot always use inflated monitors, rather than stack locks. However, it is only implemented in the interpreter that way. When it calls into runtime, it would still happily stack-lock. Even worse, C1 uses another flag UseFastLocking to achieve something similar (with the same caveat that runtime would stack-lock anyway). C2 doesn't have any such mechanism at all.
> I would like to experiment with disabling stack-locking, and thus, having this flag work as expected would seem very useful.
> 
> The change removes the C1 flag UseFastLocking, and replaces its uses with equivalent (i.e. inverted) UseHeavyMonitors instead. I think it makes sense to make UseHeavyMonitors develop (I wouldn't want anybody to use this in production, not currently without this change, and not with this change). I also added a flag VerifyHeavyMonitors to be able to verify that stack-locking is really disabled. We can't currently verify this uncondiftionally (e.g. in debug builds) because all non-x86_64 platforms would need work.
> 
> Testing:
>  - [x] tier1
>  - [x] tier2
>  - [x] tier3
>  - [ ] tier4

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Use heavy monitors in runtime only on supported architectures

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6320/files
  - new: https://git.openjdk.java.net/jdk/pull/6320/files/d1ec5b65..79090ed1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6320&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6320&range=08-09

  Stats: 10 lines in 1 file changed: 8 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6320.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6320/head:pull/6320

PR: https://git.openjdk.java.net/jdk/pull/6320

From rkennke at openjdk.java.net  Wed Dec  1 12:38:26 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 1 Dec 2021 12:38:26 GMT
Subject: RFR: 8276901: Implement UseHeavyMonitors consistently [v4]
In-Reply-To: <amfTSD-WAXfcBUaBNqvf98rEtoOdg1nnyZBHuIv9WUQ=.f4b3accb-ef85-47b4-a8fc-7a225f9f18db@github.com>
References: <CqBVDMLRhPl93f8gcv5VX0Un-fFF5BQtGEwrczIJdp4=.6a50ad8f-3bbe-4075-9f8c-ee4da37e9f8b@github.com>
 <CTfyJ4qGGJKeCJLCEFHdOvcUr_R0WIPTNrkg0G85s5g=.7199fbdd-4f99-4d63-8804-75ec559e05f2@github.com>
 <7GuyRoJ653qrQDv-vEnRU7JMcZU6qZJi0j7Ty1b5PE4=.c7d00b3d-c23b-47f9-bfb6-258623c2faae@github.com>
 <W4NBmZlPhk5djtaRNtiz-m0-St3wA-izzPOvBUoE9pM=.184c6b8d-7d3b-4371-8b7d-639674e6eaf6@github.com>
 <amfTSD-WAXfcBUaBNqvf98rEtoOdg1nnyZBHuIv9WUQ=.f4b3accb-ef85-47b4-a8fc-7a225f9f18db@github.com>
Message-ID: <245yKlIBwKaEFaRmxc3abYF3EveGUgezLqc0Vd7PY54=.912ff7ec-3bf1-46e5-a573-51ac9df83246@github.com>

On Wed, 1 Dec 2021 01:28:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > > IIUC you are only making UseHeavyMonitors work properly on x86_64, but in that case you cannot convert UseFastLocks to UseHeavyMonitors on all platforms as it won't work correctly on those other platforms.
> > > Cheers, David
> > 
> > 
> > It would not break as such on other platforms. It would only be partially implemented, that is C1 would emit calls to runtime for and only use monitors while interpreter and C2 would still emit stack locks. That is ok - and that is roughly what +UseFastLocking used to do.
> 
> Sorry but I don't see how having the interpreter+C2 use stack-locks while C1 ignores them can possibly be correct. ???

Ok, right. It worked before, because -UseFastLocking (C1) and +UseHeavyMonitors (interpreter) would generate runtime calls (instead of fast stack locking paths), and the runtime implementation would still do stack-locking.

For arches where UseHeavyMonitors is not (fully) supported, I am fixing this by letting the runtime do stack-locks.

TBH, it would be nice if this change could be properly implemented on remaining arches... (ping @TheRealMDoerr for PPC, not sure who could do arm or s390).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6320

From zgu at openjdk.java.net  Wed Dec  1 13:17:29 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 1 Dec 2021 13:17:29 GMT
Subject: Integrated: 8277946: NMT: Deprecate and remove VM.native_memory
 shutdown jcmd command option
In-Reply-To: <1AUR5fN21yPlHCpFVHUGvMMJm7pJT2NoGTGx2E-tz2o=.c5c66ba5-15f4-4708-a815-b4059039005c@github.com>
References: <1AUR5fN21yPlHCpFVHUGvMMJm7pJT2NoGTGx2E-tz2o=.c5c66ba5-15f4-4708-a815-b4059039005c@github.com>
Message-ID: <ggV-oGpghbTvqzyoU769DJ4K98BZB9_IZxuLXa-Wxnc=.e647784b-a7b8-4264-8b5d-79419e105cb6@github.com>

On Tue, 30 Nov 2021 15:17:10 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> NMT shutdown functionality is a remnant of its first implementation, which could consume excessive amount of memory, therefore, it needed capability to shut it self down to ensure health of JVM. This is no longer a case for new implementation.
> 
> NMT shutdown can be requested via Jcmd. However, it is rare used.
> 
> We should deprecate for shutdown Jcmd command for removing NMT shutdown functionality.
> 
> Corresponding [CSR](https://bugs.openjdk.java.net/browse/JDK-8277947) has been approved.

This pull request has now been integrated.

Changeset: abaa073b
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/abaa073bcbdb202658c8a97401ffb098d71e0f16
Stats:     133 lines in 5 files changed: 0 ins; 131 del; 2 mod

8277946: NMT: Deprecate and remove VM.native_memory shutdown jcmd command option

Reviewed-by: stuefe, shade, dholmes

-------------

PR: https://git.openjdk.java.net/jdk/pull/6618

From prappo at openjdk.java.net  Wed Dec  1 13:40:21 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 1 Dec 2021 13:40:21 GMT
Subject: RFR: JDK-8276674 : Malformed Javadoc inline tags in JDK source in
 java/util/stream
In-Reply-To: <NMEtofVxulh6JNDcOLF-zGYKB2gnLKUF-9Or07_oJ4k=.ecc5a86f-5d37-415b-a6b6-4104a12d8676@github.com>
References: <NMEtofVxulh6JNDcOLF-zGYKB2gnLKUF-9Or07_oJ4k=.ecc5a86f-5d37-415b-a6b6-4104a12d8676@github.com>
Message-ID: <r-dd6didFJ8p6RLL4EPWmS6JKC5L4HcdJMBUdPZKufY=.585d5650-23cf-4899-9ef8-70ab869c085b@github.com>

On Thu, 18 Nov 2021 03:22:50 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

> JDK-8276674 : Malformed Javadoc inline tags in JDK source in java/util/stream

Given that this PR affects files that aren't rooted under java/util/stream, I would either rename the PR or exclude the unrelated files. If this PR is going to sit there for some more time, I would prefer the latter. This is because the PR has already conflicted with a few other issues related to malformed javadoc tags (e.g. JDK-8276683 and JDK-8276684).

So either rename and integrate soon, or exclude the unrelated files.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6443

From rriggs at openjdk.java.net  Wed Dec  1 14:54:43 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 1 Dec 2021 14:54:43 GMT
Subject: RFR: 8278028: [test-library] Warnings cleanup of the test library
Message-ID: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>

Compilation warnings of the test library introduce noise in test output and should be addressed or suppressed. 
Changes include:
 - SuppressWarnings("deprecation") and SuppressWarnings("removal")
 - Adding type parameters to Raw types
 - Adding a hashCode method where equals was already present

-------------

Commit messages:
 - 8278028: [test-library] Warnings cleanup of the test library

Changes: https://git.openjdk.java.net/jdk/pull/6638/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6638&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278028
  Stats: 23 lines in 14 files changed: 10 ins; 1 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6638.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6638/head:pull/6638

PR: https://git.openjdk.java.net/jdk/pull/6638

From mdoerr at openjdk.java.net  Wed Dec  1 16:44:28 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 1 Dec 2021 16:44:28 GMT
Subject: RFR: 8276901: Implement UseHeavyMonitors consistently [v10]
In-Reply-To: <___2nS2ZNEiggHv_C70jADW_cE-T2wUJKqRK_J5gIj0=.23da20f8-ba19-4279-b154-f0a67626ccf4@github.com>
References: <CqBVDMLRhPl93f8gcv5VX0Un-fFF5BQtGEwrczIJdp4=.6a50ad8f-3bbe-4075-9f8c-ee4da37e9f8b@github.com>
 <___2nS2ZNEiggHv_C70jADW_cE-T2wUJKqRK_J5gIj0=.23da20f8-ba19-4279-b154-f0a67626ccf4@github.com>
Message-ID: <GTg2MG80IVJB8e-aLcFuWpbpXlCTZKufVadA4YX78a4=.adbe6849-e02d-437d-90e0-ee67337b6d0b@github.com>

On Wed, 1 Dec 2021 12:36:02 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> The flag UseHeavyMonitors seems to imply that it makes Hotspot always use inflated monitors, rather than stack locks. However, it is only implemented in the interpreter that way. When it calls into runtime, it would still happily stack-lock. Even worse, C1 uses another flag UseFastLocking to achieve something similar (with the same caveat that runtime would stack-lock anyway). C2 doesn't have any such mechanism at all.
>> I would like to experiment with disabling stack-locking, and thus, having this flag work as expected would seem very useful.
>> 
>> The change removes the C1 flag UseFastLocking, and replaces its uses with equivalent (i.e. inverted) UseHeavyMonitors instead. I think it makes sense to make UseHeavyMonitors develop (I wouldn't want anybody to use this in production, not currently without this change, and not with this change). I also added a flag VerifyHeavyMonitors to be able to verify that stack-locking is really disabled. We can't currently verify this uncondiftionally (e.g. in debug builds) because all non-x86_64 platforms would need work.
>> 
>> Testing:
>>  - [x] tier1
>>  - [x] tier2
>>  - [x] tier3
>>  - [ ] tier4
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use heavy monitors in runtime only on supported architectures

PPC64 could be implemented like this:

diff --git a/src/hotspot/cpu/ppc/ppc.ad b/src/hotspot/cpu/ppc/ppc.ad
index 958059e1ca2..dc96bd15836 100644
--- a/src/hotspot/cpu/ppc/ppc.ad
+++ b/src/hotspot/cpu/ppc/ppc.ad
@@ -12132,7 +12132,7 @@ instruct partialSubtypeCheck(iRegPdst result, iRegP_N2P subklass, iRegP_N2P supe
 instruct cmpFastLock(flagsReg crx, iRegPdst oop, iRegPdst box, iRegPdst tmp1, iRegPdst tmp2) %{
   match(Set crx (FastLock oop box));
   effect(TEMP tmp1, TEMP tmp2);
-  predicate(!Compile::current()->use_rtm());
+  predicate(!Compile::current()->use_rtm() && !UseHeavyMonitors);
 
   format %{ "FASTLOCK  $oop, $box, $tmp1, $tmp2" %}
   ins_encode %{
@@ -12149,7 +12149,7 @@ instruct cmpFastLock(flagsReg crx, iRegPdst oop, iRegPdst box, iRegPdst tmp1, iR
 instruct cmpFastLock_tm(flagsReg crx, iRegPdst oop, rarg2RegP box, iRegPdst tmp1, iRegPdst tmp2, iRegPdst tmp3) %{
   match(Set crx (FastLock oop box));
   effect(TEMP tmp1, TEMP tmp2, TEMP tmp3, USE_KILL box);
-  predicate(Compile::current()->use_rtm());
+  predicate(Compile::current()->use_rtm() && !UseHeavyMonitors);
 
   format %{ "FASTLOCK  $oop, $box, $tmp1, $tmp2, $tmp3 (TM)" %}
   ins_encode %{
@@ -12165,6 +12165,18 @@ instruct cmpFastLock_tm(flagsReg crx, iRegPdst oop, rarg2RegP box, iRegPdst tmp1
   ins_pipe(pipe_class_compare);
 %}
 
+instruct cmpFastLock_hm(flagsReg crx, iRegPdst oop, rarg2RegP box) %{
+  match(Set crx (FastLock oop box));
+  predicate(UseHeavyMonitors);
+
+  format %{ "FASTLOCK  $oop, $box (HM)" %}
+  ins_encode %{
+    // Set NE to indicate 'failure' -> take slow-path.
+    __ crandc($crx$$CondRegister, Assembler::equal, $crx$$CondRegister, Assembler::equal);
+  %}
+  ins_pipe(pipe_class_compare);
+%}
+
 instruct cmpFastUnlock(flagsReg crx, iRegPdst oop, iRegPdst box, iRegPdst tmp1, iRegPdst tmp2, iRegPdst tmp3) %{
   match(Set crx (FastUnlock oop box));
   effect(TEMP tmp1, TEMP tmp2, TEMP tmp3);
diff --git a/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp b/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp
index a834fa1af36..bac8ef164f8 100644
--- a/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp
+++ b/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp
@@ -2014,8 +2014,10 @@ nmethod *SharedRuntime::generate_native_wrapper(MacroAssembler *masm,
 
     // Try fastpath for locking.
     // fast_lock kills r_temp_1, r_temp_2, r_temp_3.
-    __ compiler_fast_lock_object(r_flag, r_oop, r_box, r_temp_1, r_temp_2, r_temp_3);
-    __ beq(r_flag, locked);
+    if (!UseHeavyMonitors) {
+      __ compiler_fast_lock_object(r_flag, r_oop, r_box, r_temp_1, r_temp_2, r_temp_3);
+      __ beq(r_flag, locked);
+    }
 
     // None of the above fast optimizations worked so we have to get into the
     // slow case of monitor enter. Inline a special case of call_VM that
diff --git a/src/hotspot/share/runtime/synchronizer.cpp b/src/hotspot/share/runtime/synchronizer.cpp
index 4c5ea4a6e40..4f9c7c21a9b 100644
--- a/src/hotspot/share/runtime/synchronizer.cpp
+++ b/src/hotspot/share/runtime/synchronizer.cpp
@@ -418,7 +418,7 @@ void ObjectSynchronizer::handle_sync_on_value_based_class(Handle obj, JavaThread
 }
 
 static bool useHeavyMonitors() {
-#if defined(X86) || defined(AARCH64)
+#if defined(X86) || defined(AARCH64) || defined(PPC64)
   return UseHeavyMonitors;
 #else
   return false;


I don't like hacking the regular assembler implementations. Better would be to change C2 such that it doesn't generate FastLockNodes. But that may be a bit cumbersome.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6320

From dfuchs at openjdk.java.net  Wed Dec  1 16:56:28 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 1 Dec 2021 16:56:28 GMT
Subject: RFR: 8278028: [test-library] Warnings cleanup of the test library
In-Reply-To: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
References: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
Message-ID: <mZaHAvVGBjhen4fclGvAVNwBfOOFO19MX3YeOLCo8lU=.5fd51468-1b35-40bf-98c2-25afd0f21801@github.com>

On Wed, 1 Dec 2021 14:47:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Compilation warnings of the test library introduce noise in test output and should be addressed or suppressed. 
> Changes include:
>  - SuppressWarnings("deprecation") and SuppressWarnings("removal")
>  - Adding type parameters to Raw types
>  - Adding a hashCode method where equals was already present

Changes look reasonable to me but since I am not familiar with all those files it might be best to get at least one additional reviewer.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6638

From rkennke at openjdk.java.net  Wed Dec  1 17:18:29 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 1 Dec 2021 17:18:29 GMT
Subject: RFR: 8276901: Implement UseHeavyMonitors consistently [v10]
In-Reply-To: <___2nS2ZNEiggHv_C70jADW_cE-T2wUJKqRK_J5gIj0=.23da20f8-ba19-4279-b154-f0a67626ccf4@github.com>
References: <CqBVDMLRhPl93f8gcv5VX0Un-fFF5BQtGEwrczIJdp4=.6a50ad8f-3bbe-4075-9f8c-ee4da37e9f8b@github.com>
 <___2nS2ZNEiggHv_C70jADW_cE-T2wUJKqRK_J5gIj0=.23da20f8-ba19-4279-b154-f0a67626ccf4@github.com>
Message-ID: <5oeP5b_jS2eu5lsDpNkfIBINEPPT23A-kqeHwOSXrYQ=.e32eb661-903d-4778-a56f-2a1d525d1874@github.com>

On Wed, 1 Dec 2021 12:36:02 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> The flag UseHeavyMonitors seems to imply that it makes Hotspot always use inflated monitors, rather than stack locks. However, it is only implemented in the interpreter that way. When it calls into runtime, it would still happily stack-lock. Even worse, C1 uses another flag UseFastLocking to achieve something similar (with the same caveat that runtime would stack-lock anyway). C2 doesn't have any such mechanism at all.
>> I would like to experiment with disabling stack-locking, and thus, having this flag work as expected would seem very useful.
>> 
>> The change removes the C1 flag UseFastLocking, and replaces its uses with equivalent (i.e. inverted) UseHeavyMonitors instead. I think it makes sense to make UseHeavyMonitors develop (I wouldn't want anybody to use this in production, not currently without this change, and not with this change). I also added a flag VerifyHeavyMonitors to be able to verify that stack-locking is really disabled. We can't currently verify this uncondiftionally (e.g. in debug builds) because all non-x86_64 platforms would need work.
>> 
>> Testing:
>>  - [x] tier1
>>  - [x] tier2
>>  - [x] tier3
>>  - [ ] tier4
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use heavy monitors in runtime only on supported architectures

Thank you, Martin!

> I don't like hacking the regular assembler implementations. Better would be to change C2 such that it doesn't generate FastLockNodes. But that may be a bit cumbersome.

That is a good suggestion, and would help ease the work in the backend.

I believe you still have to change something in sharedRuntime_ppc.cpp, similar to what I did in, e.g., sharedRuntime_aarch64.cpp.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6320

From mdoerr at openjdk.java.net  Wed Dec  1 17:29:30 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 1 Dec 2021 17:29:30 GMT
Subject: RFR: 8276901: Implement UseHeavyMonitors consistently [v10]
In-Reply-To: <5oeP5b_jS2eu5lsDpNkfIBINEPPT23A-kqeHwOSXrYQ=.e32eb661-903d-4778-a56f-2a1d525d1874@github.com>
References: <CqBVDMLRhPl93f8gcv5VX0Un-fFF5BQtGEwrczIJdp4=.6a50ad8f-3bbe-4075-9f8c-ee4da37e9f8b@github.com>
 <___2nS2ZNEiggHv_C70jADW_cE-T2wUJKqRK_J5gIj0=.23da20f8-ba19-4279-b154-f0a67626ccf4@github.com>
 <5oeP5b_jS2eu5lsDpNkfIBINEPPT23A-kqeHwOSXrYQ=.e32eb661-903d-4778-a56f-2a1d525d1874@github.com>
Message-ID: <NegQo7AZ4KAbB_u2-lAUQWfotCebTuHy_v7Bn7ycXy8=.2ac2037f-2fa0-471c-a122-01767cf1bc35@github.com>

On Wed, 1 Dec 2021 17:15:33 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> I believe you still have to change something in sharedRuntime_ppc.cpp, similar to what I did in, e.g., sharedRuntime_aarch64.cpp.

You mean in `generate_native_wrapper`? I already did. It uses the same assembler function as C2 on PPC64. Did I miss anything else? I think hacking `unlock` is optional. The additional checks don't really disturb.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6320

From rkennke at openjdk.java.net  Wed Dec  1 18:00:28 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 1 Dec 2021 18:00:28 GMT
Subject: RFR: 8276901: Implement UseHeavyMonitors consistently [v10]
In-Reply-To: <NegQo7AZ4KAbB_u2-lAUQWfotCebTuHy_v7Bn7ycXy8=.2ac2037f-2fa0-471c-a122-01767cf1bc35@github.com>
References: <CqBVDMLRhPl93f8gcv5VX0Un-fFF5BQtGEwrczIJdp4=.6a50ad8f-3bbe-4075-9f8c-ee4da37e9f8b@github.com>
 <___2nS2ZNEiggHv_C70jADW_cE-T2wUJKqRK_J5gIj0=.23da20f8-ba19-4279-b154-f0a67626ccf4@github.com>
 <5oeP5b_jS2eu5lsDpNkfIBINEPPT23A-kqeHwOSXrYQ=.e32eb661-903d-4778-a56f-2a1d525d1874@github.com>
 <NegQo7AZ4KAbB_u2-lAUQWfotCebTuHy_v7Bn7ycXy8=.2ac2037f-2fa0-471c-a122-01767cf1bc35@github.com>
Message-ID: <DpfOa_DlZZsTutAz0MUg_e5jEtn6sJNSP8COH3jUNMQ=.e9aa3302-6b7b-4986-b609-c43226cebeb7@github.com>

On Wed, 1 Dec 2021 17:26:06 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> > I believe you still have to change something in sharedRuntime_ppc.cpp, similar to what I did in, e.g., sharedRuntime_aarch64.cpp.
> 
> You mean in `generate_native_wrapper`? I already did. It uses the same assembler function as C2 on PPC64. Did I miss anything else? I think hacking `unlock` is optional. The additional checks don't really disturb.

Ah I haven't seen it, sorry.
It turns out, I cannot avoid emitting FastLockNode, some backends (x86 and aarch64) also generate fast-path code that deals with ObjectMonitor, and we want this even when running with +UseHeavyMonitors.

Can you verify the new testcase, and perhaps some test programs that do some locking with -XX:+UseHeavyMonitors -XX:+VerifyHeavyMonitors ? You also need to include PPC in arguments.cpp and synchronizer.cpp changes to enable that stuff on PPC:

-------------

PR: https://git.openjdk.java.net/jdk/pull/6320

From minqi at openjdk.java.net  Wed Dec  1 19:14:29 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 1 Dec 2021 19:14:29 GMT
Subject: RFR: 8276126: Dump time class transformation causes heap objects
 of non-boot classes to be archived [v4]
In-Reply-To: <OMooshS7BJAfQflDa7IzpLIl2UCeJO0xxfMZMzGjhWY=.6255822b-9c52-4296-8e9a-0d1f3f343f36@github.com>
References: <wcTCcSYZsoJCU5ZtXovHwHk0hF6p5FBPcyp0U-EhtQ8=.de3d7c75-f827-411f-973e-132664296dc0@github.com>
 <OMooshS7BJAfQflDa7IzpLIl2UCeJO0xxfMZMzGjhWY=.6255822b-9c52-4296-8e9a-0d1f3f343f36@github.com>
Message-ID: <nD_2VKUSG6qjqImcyS_05ZM-afu6Ul0qD_uQ1rNFr2E=.b314a94f-ea2c-4549-b2e1-9f6f5402d472@github.com>

On Tue, 30 Nov 2021 17:51:46 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> During CDS static dump, if a class loaded by a boot class loader is transformed by a java agent, the transformed class is mistakenly identified as a class loaded by a custom loader. This would cause archiving of the heap objects to fail.
>> 
>> The proposed patch corrects the identification of the transformed class and will not include it in the archive.
>> Also, if a transformed class is detected during dump time, the archiving of the heap objects will be disabled.
>> 
>> Testing: Oracle CI tiers 1-3, tier4 in progress.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove the unused stream parameter in ClassLoaderExt::record_result()

src/hotspot/share/classfile/classLoaderExt.cpp line 250:

> 248:   result->set_shared_class_loader_type(classloader_type);
> 249: #if INCLUDE_CDS_JAVA_HEAP
> 250:   if (DumpSharedSpaces && AllowArchivingWithJavaAgent && classloader_type == ClassLoader::BOOT_LOADER &&

the function is call during dump time (the assert at first line of this function check that) so DumpSharedSpace can be removed.
I am a little confused by this part:  If 'redefined' is 'true', The 'redefined' only should be enough for set disable_writing() whether other conditions stands or not?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6484

From ccheung at openjdk.java.net  Wed Dec  1 19:25:53 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Wed, 1 Dec 2021 19:25:53 GMT
Subject: RFR: 8268288:
 jdk/jfr/api/consumer/streaming/TestOutOfProcessMigration.java fails with
 "Error: ShouldNotReachHere()"
Message-ID: <ZQDhdrk36fVLZlhP7RGhQvlxudfjy1YehtZRKfdDAiA=.3de6c554-ac14-4c25-92c7-c774af13d6fa@github.com>

A small fix to ensure that the globally shared ClassPathImageEntry is not being deleted in CDS code.
The test failure is hard to reproduce. The proposed fix passed CI tiers 1-4 testing.
Currently running the TestOutOfProcessMigration.java test repeatedly on linux-x64 with the vm options in the bug report.

-------------

Commit messages:
 - 8268288: jdk/jfr/api/consumer/streaming/TestOutOfProcessMigration.java fails with "Error: ShouldNotReachHere()"

Changes: https://git.openjdk.java.net/jdk/pull/6651/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6651&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268288
  Stats: 28 lines in 1 file changed: 11 ins; 11 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6651.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6651/head:pull/6651

PR: https://git.openjdk.java.net/jdk/pull/6651

From minqi at openjdk.java.net  Wed Dec  1 20:47:27 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 1 Dec 2021 20:47:27 GMT
Subject: RFR: 8268288:
 jdk/jfr/api/consumer/streaming/TestOutOfProcessMigration.java fails with
 "Error: ShouldNotReachHere()"
In-Reply-To: <ZQDhdrk36fVLZlhP7RGhQvlxudfjy1YehtZRKfdDAiA=.3de6c554-ac14-4c25-92c7-c774af13d6fa@github.com>
References: <ZQDhdrk36fVLZlhP7RGhQvlxudfjy1YehtZRKfdDAiA=.3de6c554-ac14-4c25-92c7-c774af13d6fa@github.com>
Message-ID: <EwKo31k9Q8s1gchxB5AD5TyQFv-7KAeE1sCmARpMftU=.598770a7-de30-4268-af0a-1e36f85c5a3d@github.com>

On Wed, 1 Dec 2021 19:16:11 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> A small fix to ensure that the globally shared ClassPathImageEntry is not being deleted in CDS code.
> The test failure is hard to reproduce. The proposed fix passed CI tiers 1-4 testing.
> Currently running the TestOutOfProcessMigration.java test repeatedly on linux-x64 with the vm options in the bug report.

LGTM. Minor suggestion.

src/hotspot/share/cds/filemap.cpp line 2495:

> 2493:     const char* path = scpe->name();
> 2494:     struct stat st;
> 2495:     if (os::stat(path, &st) != 0) {

Do you check if the file exists? If so please use os::file_exists which is better.

-------------

Marked as reviewed by minqi (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6651

From ccheung at openjdk.java.net  Wed Dec  1 22:05:24 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Wed, 1 Dec 2021 22:05:24 GMT
Subject: RFR: 8276126: Dump time class transformation causes heap objects
 of non-boot classes to be archived [v4]
In-Reply-To: <nD_2VKUSG6qjqImcyS_05ZM-afu6Ul0qD_uQ1rNFr2E=.b314a94f-ea2c-4549-b2e1-9f6f5402d472@github.com>
References: <wcTCcSYZsoJCU5ZtXovHwHk0hF6p5FBPcyp0U-EhtQ8=.de3d7c75-f827-411f-973e-132664296dc0@github.com>
 <OMooshS7BJAfQflDa7IzpLIl2UCeJO0xxfMZMzGjhWY=.6255822b-9c52-4296-8e9a-0d1f3f343f36@github.com>
 <nD_2VKUSG6qjqImcyS_05ZM-afu6Ul0qD_uQ1rNFr2E=.b314a94f-ea2c-4549-b2e1-9f6f5402d472@github.com>
Message-ID: <22ZKGaSYLH7ZuPkzaD0mu1SFsxK1_-9Yzh5hwRwFMzQ=.e4e26785-f60e-457d-9366-259663c5c988@github.com>

On Wed, 1 Dec 2021 19:11:05 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove the unused stream parameter in ClassLoaderExt::record_result()
>
> src/hotspot/share/classfile/classLoaderExt.cpp line 250:
> 
>> 248:   result->set_shared_class_loader_type(classloader_type);
>> 249: #if INCLUDE_CDS_JAVA_HEAP
>> 250:   if (DumpSharedSpaces && AllowArchivingWithJavaAgent && classloader_type == ClassLoader::BOOT_LOADER &&
> 
> the function is call during dump time (the assert at first line of this function check that) so DumpSharedSpace can be removed.
> I am a little confused by this part:  If 'redefined' is 'true', The 'redefined' only should be enough for set disable_writing() whether other conditions stands or not?

The `Arguments::assert_is_dumping_archive()` includes both static and dynamic dumping. The archiving of heap objects is performed only during static dumping. So the check for `DumpShareSpaces` is needed.

The `redefined` flag alone is not enough to disable writing heap objects to archive. If a class loaded by an AppClassLoader and is redefined, it should not disable archiving heap objects. We currently have some test cases under runtime/cds/appcds/javaldr to test that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6484

From minqi at openjdk.java.net  Wed Dec  1 23:20:29 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 1 Dec 2021 23:20:29 GMT
Subject: RFR: 8276126: Dump time class transformation causes heap objects
 of non-boot classes to be archived [v4]
In-Reply-To: <OMooshS7BJAfQflDa7IzpLIl2UCeJO0xxfMZMzGjhWY=.6255822b-9c52-4296-8e9a-0d1f3f343f36@github.com>
References: <wcTCcSYZsoJCU5ZtXovHwHk0hF6p5FBPcyp0U-EhtQ8=.de3d7c75-f827-411f-973e-132664296dc0@github.com>
 <OMooshS7BJAfQflDa7IzpLIl2UCeJO0xxfMZMzGjhWY=.6255822b-9c52-4296-8e9a-0d1f3f343f36@github.com>
Message-ID: <d2woR6v3Gg4_6fG0ch3bAZrXC4909eew19EjurWHqW4=.f3742bd9-bd4a-4a84-8990-fdf0facc89b3@github.com>

On Tue, 30 Nov 2021 17:51:46 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> During CDS static dump, if a class loaded by a boot class loader is transformed by a java agent, the transformed class is mistakenly identified as a class loaded by a custom loader. This would cause archiving of the heap objects to fail.
>> 
>> The proposed patch corrects the identification of the transformed class and will not include it in the archive.
>> Also, if a transformed class is detected during dump time, the archiving of the heap objects will be disabled.
>> 
>> Testing: Oracle CI tiers 1-3, tier4 in progress.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove the unused stream parameter in ClassLoaderExt::record_result()

LGTM.

-------------

Marked as reviewed by minqi (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6484

From minqi at openjdk.java.net  Wed Dec  1 23:20:30 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 1 Dec 2021 23:20:30 GMT
Subject: RFR: 8276126: Dump time class transformation causes heap objects
 of non-boot classes to be archived [v4]
In-Reply-To: <22ZKGaSYLH7ZuPkzaD0mu1SFsxK1_-9Yzh5hwRwFMzQ=.e4e26785-f60e-457d-9366-259663c5c988@github.com>
References: <wcTCcSYZsoJCU5ZtXovHwHk0hF6p5FBPcyp0U-EhtQ8=.de3d7c75-f827-411f-973e-132664296dc0@github.com>
 <OMooshS7BJAfQflDa7IzpLIl2UCeJO0xxfMZMzGjhWY=.6255822b-9c52-4296-8e9a-0d1f3f343f36@github.com>
 <nD_2VKUSG6qjqImcyS_05ZM-afu6Ul0qD_uQ1rNFr2E=.b314a94f-ea2c-4549-b2e1-9f6f5402d472@github.com>
 <22ZKGaSYLH7ZuPkzaD0mu1SFsxK1_-9Yzh5hwRwFMzQ=.e4e26785-f60e-457d-9366-259663c5c988@github.com>
Message-ID: <D3-lfeaXugjxx0ddzg5dSRqDTIkrJXOuAcS9CuA6PW0=.07b63a9a-d662-43c7-884b-926a3cb3a608@github.com>

On Wed, 1 Dec 2021 22:02:14 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> src/hotspot/share/classfile/classLoaderExt.cpp line 250:
>> 
>>> 248:   result->set_shared_class_loader_type(classloader_type);
>>> 249: #if INCLUDE_CDS_JAVA_HEAP
>>> 250:   if (DumpSharedSpaces && AllowArchivingWithJavaAgent && classloader_type == ClassLoader::BOOT_LOADER &&
>> 
>> the function is call during dump time (the assert at first line of this function check that) so DumpSharedSpace can be removed.
>> I am a little confused by this part:  If 'redefined' is 'true', The 'redefined' only should be enough for set disable_writing() whether other conditions stands or not?
>
> The `Arguments::assert_is_dumping_archive()` includes both static and dynamic dumping. The archiving of heap objects is performed only during static dumping. So the check for `DumpShareSpaces` is needed.
> 
> The `redefined` flag alone is not enough to disable writing heap objects to archive. If a class loaded by an AppClassLoader and is redefined, it should not disable archiving heap objects. We currently have some test cases under runtime/cds/appcds/javaldr to test that.

> 

Thanks for the explanation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6484

From iklam at openjdk.java.net  Wed Dec  1 23:39:28 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 1 Dec 2021 23:39:28 GMT
Subject: RFR: 8268288:
 jdk/jfr/api/consumer/streaming/TestOutOfProcessMigration.java fails with
 "Error: ShouldNotReachHere()"
In-Reply-To: <ZQDhdrk36fVLZlhP7RGhQvlxudfjy1YehtZRKfdDAiA=.3de6c554-ac14-4c25-92c7-c774af13d6fa@github.com>
References: <ZQDhdrk36fVLZlhP7RGhQvlxudfjy1YehtZRKfdDAiA=.3de6c554-ac14-4c25-92c7-c774af13d6fa@github.com>
Message-ID: <ICnRBOsmT7VZvS4-IHKvsMqDPpkGVhOGkaPgkUzOUB8=.4c0cc9e1-4ff9-4d58-bf04-537642422b65@github.com>

On Wed, 1 Dec 2021 19:16:11 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> A small fix to ensure that the globally shared ClassPathImageEntry is not being deleted in CDS code.
> The test failure is hard to reproduce. The proposed fix passed CI tiers 1-4 testing.
> Currently running the TestOutOfProcessMigration.java test repeatedly on linux-x64 with the vm options in the bug report.

LGTM

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6651

From zgu at openjdk.java.net  Thu Dec  2 00:12:33 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 2 Dec 2021 00:12:33 GMT
Subject: Withdrawn: 8277486: NMT: Cleanup ThreadStackTracker
In-Reply-To: <vuFBwWcccwyt6rLK0xXdUXeGg14FEsy6TjniZemhO0I=.29917220-3df7-4c80-aca9-5bf9a25ba75d@github.com>
References: <vuFBwWcccwyt6rLK0xXdUXeGg14FEsy6TjniZemhO0I=.29917220-3df7-4c80-aca9-5bf9a25ba75d@github.com>
Message-ID: <HyIbMbw0RH7eRkAzglFA9_vur9-AVlBb5aOUtKksiTI=.cbe3ab4e-43ce-4adc-a1d7-109a75a98def@github.com>

On Mon, 22 Nov 2021 15:36:41 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> There are several issues with `ThreadStackTracker`.
> 
> 1) Following assertion:
>   `assert(MemTracker::tracking_level() >= NMT_summary, "Must be");`
> in `ThreadStackTracker::record/release_thread_stack()` is unreliable. The full fence after downgrading tracking level is *not* sufficient to avoid the racy.
> 
> 2) NMT tracking level is downgraded without `ThreadCritical` lock held. But, it does require `ThreadCritical` lock to be held when it actually downgrade internal tracking data structure, so checking internal state is reliable to determine current tracking state.
> Add assertion to ensure correct tracking state
> 
> 3) `_thread_counter` is updated with `ThreadCritical` lock, but is read without the lock. Change to atomic update to ensure reader will not read stale value.
> 
> 4) NMT events are relative rare. So far, I have yet seen (1) assertion failure but add new test may help to spot such problem.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6504

From mdoerr at openjdk.java.net  Thu Dec  2 00:58:28 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Thu, 2 Dec 2021 00:58:28 GMT
Subject: RFR: 8276901: Implement UseHeavyMonitors consistently [v10]
In-Reply-To: <DpfOa_DlZZsTutAz0MUg_e5jEtn6sJNSP8COH3jUNMQ=.e9aa3302-6b7b-4986-b609-c43226cebeb7@github.com>
References: <CqBVDMLRhPl93f8gcv5VX0Un-fFF5BQtGEwrczIJdp4=.6a50ad8f-3bbe-4075-9f8c-ee4da37e9f8b@github.com>
 <___2nS2ZNEiggHv_C70jADW_cE-T2wUJKqRK_J5gIj0=.23da20f8-ba19-4279-b154-f0a67626ccf4@github.com>
 <5oeP5b_jS2eu5lsDpNkfIBINEPPT23A-kqeHwOSXrYQ=.e32eb661-903d-4778-a56f-2a1d525d1874@github.com>
 <NegQo7AZ4KAbB_u2-lAUQWfotCebTuHy_v7Bn7ycXy8=.2ac2037f-2fa0-471c-a122-01767cf1bc35@github.com>
 <DpfOa_DlZZsTutAz0MUg_e5jEtn6sJNSP8COH3jUNMQ=.e9aa3302-6b7b-4986-b609-c43226cebeb7@github.com>
Message-ID: <zUJcdm1NnPIhddVUsNT8OeBD6Y-3ofsk_v4IqtbFr5w=.9a9bbaf5-0639-4e37-a8d1-0d3c0fd7caae@github.com>

On Wed, 1 Dec 2021 17:57:11 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> It turns out, I cannot avoid emitting FastLockNode, some backends (x86 and aarch64) also generate fast-path code that deals with ObjectMonitor, and we want this even when running with +UseHeavyMonitors.

Ok, thanks for checking. You have convinced me that your version is fine. We should do it the same way on PPC64:

diff --git a/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp b/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
index 98565003691..cb58e775422 100644
--- a/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
+++ b/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
@@ -2660,27 +2660,32 @@ void MacroAssembler::compiler_fast_lock_object(ConditionRegister flag, Register
   andi_(temp, displaced_header, markWord::monitor_value);
   bne(CCR0, object_has_monitor);
 
-  // Set displaced_header to be (markWord of object | UNLOCK_VALUE).
-  ori(displaced_header, displaced_header, markWord::unlocked_value);
-
-  // Load Compare Value application register.
-
-  // Initialize the box. (Must happen before we update the object mark!)
-  std(displaced_header, BasicLock::displaced_header_offset_in_bytes(), box);
-
-  // Must fence, otherwise, preceding store(s) may float below cmpxchg.
-  // Compare object markWord with mark and if equal exchange scratch1 with object markWord.
-  cmpxchgd(/*flag=*/flag,
-           /*current_value=*/current_header,
-           /*compare_value=*/displaced_header,
-           /*exchange_value=*/box,
-           /*where=*/oop,
-           MacroAssembler::MemBarRel | MacroAssembler::MemBarAcq,
-           MacroAssembler::cmpxchgx_hint_acquire_lock(),
-           noreg,
-           &cas_failed,
-           /*check without membar and ldarx first*/true);
-  assert(oopDesc::mark_offset_in_bytes() == 0, "offset of _mark is not 0");
+  if (!UseHeavyMonitors) {
+    // Set displaced_header to be (markWord of object | UNLOCK_VALUE).
+    ori(displaced_header, displaced_header, markWord::unlocked_value);
+
+    // Load Compare Value application register.
+
+    // Initialize the box. (Must happen before we update the object mark!)
+    std(displaced_header, BasicLock::displaced_header_offset_in_bytes(), box);
+
+    // Must fence, otherwise, preceding store(s) may float below cmpxchg.
+    // Compare object markWord with mark and if equal exchange scratch1 with object markWord.
+    cmpxchgd(/*flag=*/flag,
+             /*current_value=*/current_header,
+             /*compare_value=*/displaced_header,
+             /*exchange_value=*/box,
+             /*where=*/oop,
+             MacroAssembler::MemBarRel | MacroAssembler::MemBarAcq,
+             MacroAssembler::cmpxchgx_hint_acquire_lock(),
+             noreg,
+             &cas_failed,
+             /*check without membar and ldarx first*/true);
+    assert(oopDesc::mark_offset_in_bytes() == 0, "offset of _mark is not 0");
+  } else {
+    // Set NE to indicate 'failure' -> take slow-path.
+    crandc(flag, Assembler::equal, flag, Assembler::equal);
+  }
 
   // If the compare-and-exchange succeeded, then we found an unlocked
   // object and we have now locked it.
@@ -2768,12 +2773,14 @@ void MacroAssembler::compiler_fast_unlock_object(ConditionRegister flag, Registe
   }
 #endif
 
-  // Find the lock address and load the displaced header from the stack.
-  ld(displaced_header, BasicLock::displaced_header_offset_in_bytes(), box);
+  if (!UseHeavyMonitors) {
+    // Find the lock address and load the displaced header from the stack.
+    ld(displaced_header, BasicLock::displaced_header_offset_in_bytes(), box);
 
-  // If the displaced header is 0, we have a recursive unlock.
-  cmpdi(flag, displaced_header, 0);
-  beq(flag, cont);
+    // If the displaced header is 0, we have a recursive unlock.
+    cmpdi(flag, displaced_header, 0);
+    beq(flag, cont);
+  }
 
   // Handle existing monitor.
   // The object has an existing monitor iff (mark & monitor_value) != 0.
@@ -2782,20 +2789,24 @@ void MacroAssembler::compiler_fast_unlock_object(ConditionRegister flag, Registe
   andi_(R0, current_header, markWord::monitor_value);
   bne(CCR0, object_has_monitor);
 
-  // Check if it is still a light weight lock, this is is true if we see
-  // the stack address of the basicLock in the markWord of the object.
-  // Cmpxchg sets flag to cmpd(current_header, box).
-  cmpxchgd(/*flag=*/flag,
-           /*current_value=*/current_header,
-           /*compare_value=*/box,
-           /*exchange_value=*/displaced_header,
-           /*where=*/oop,
-           MacroAssembler::MemBarRel,
-           MacroAssembler::cmpxchgx_hint_release_lock(),
-           noreg,
-           &cont);
-
-  assert(oopDesc::mark_offset_in_bytes() == 0, "offset of _mark is not 0");
+  if (!UseHeavyMonitors) {
+    // Check if it is still a light weight lock, this is is true if we see
+    // the stack address of the basicLock in the markWord of the object.
+    // Cmpxchg sets flag to cmpd(current_header, box).
+    cmpxchgd(/*flag=*/flag,
+             /*current_value=*/current_header,
+             /*compare_value=*/box,
+             /*exchange_value=*/displaced_header,
+             /*where=*/oop,
+             MacroAssembler::MemBarRel,
+             MacroAssembler::cmpxchgx_hint_release_lock(),
+             noreg,
+             &cont);
+    assert(oopDesc::mark_offset_in_bytes() == 0, "offset of _mark is not 0");
+  } else {
+    // Set NE to indicate 'failure' -> take slow-path.
+    crandc(flag, Assembler::equal, flag, Assembler::equal);
+  }
 
   // Handle existing monitor.
   b(cont);
diff --git a/src/hotspot/share/runtime/arguments.cpp b/src/hotspot/share/runtime/arguments.cpp
index 3396adc0799..969c8e82b91 100644
--- a/src/hotspot/share/runtime/arguments.cpp
+++ b/src/hotspot/share/runtime/arguments.cpp
@@ -2021,12 +2021,12 @@ bool Arguments::check_vm_args_consistency() {
   }
 #endif
 
-#if !defined(X86) && !defined(AARCH64)
+#if !defined(X86) && !defined(AARCH64) && !defined(PPC64)
   if (UseHeavyMonitors) {
     warning("UseHeavyMonitors is not fully implemented on this architecture");
   }
 #endif
-#ifdef X86
+#if defined(X86) || defined(PPC64)
   if (UseHeavyMonitors && UseRTMForStackLocks) {
     fatal("-XX:+UseHeavyMonitors and -XX:+UseRTMForStackLocks are mutually exclusive");
   }
diff --git a/src/hotspot/share/runtime/synchronizer.cpp b/src/hotspot/share/runtime/synchronizer.cpp
index 4c5ea4a6e40..4f9c7c21a9b 100644
--- a/src/hotspot/share/runtime/synchronizer.cpp
+++ b/src/hotspot/share/runtime/synchronizer.cpp
@@ -418,7 +418,7 @@ void ObjectSynchronizer::handle_sync_on_value_based_class(Handle obj, JavaThread
 }
 
 static bool useHeavyMonitors() {
-#if defined(X86) || defined(AARCH64)
+#if defined(X86) || defined(AARCH64) || defined(PPC64)
   return UseHeavyMonitors;
 #else
   return false;
diff --git a/test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java b/test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java
index cd32e222f68..922b18836dd 100644
--- a/test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java
+++ b/test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java
@@ -48,7 +48,7 @@
 /*
  * @test
  * @summary Exercise multithreaded maps, using only heavy monitors.
- * @requires os.arch=="x86" | os.arch=="i386" | os.arch=="amd64" | os.arch=="x86_64" | os.arch=="aarch64"
+ * @requires os.arch=="x86" | os.arch=="i386" | os.arch=="amd64" | os.arch=="x86_64" | os.arch=="aarch64" | os.arch == "ppc64" | os.arch == "ppc64le"
  * @library /test/lib
  * @run main/othervm/timeout=1600 -XX:+IgnoreUnrecognizedVMOptions -XX:+UseHeavyMonitors -XX:+VerifyHeavyMonitors MapLoops
  */

Note that this version does no longer require changes in sharedRuntime_ppc because the native wrapper generator uses the same code as C2. The test case has passed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6320

From ccheung at openjdk.java.net  Thu Dec  2 01:05:28 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 2 Dec 2021 01:05:28 GMT
Subject: RFR: 8268288:
 jdk/jfr/api/consumer/streaming/TestOutOfProcessMigration.java fails with
 "Error: ShouldNotReachHere()"
In-Reply-To: <EwKo31k9Q8s1gchxB5AD5TyQFv-7KAeE1sCmARpMftU=.598770a7-de30-4268-af0a-1e36f85c5a3d@github.com>
References: <ZQDhdrk36fVLZlhP7RGhQvlxudfjy1YehtZRKfdDAiA=.3de6c554-ac14-4c25-92c7-c774af13d6fa@github.com>
 <EwKo31k9Q8s1gchxB5AD5TyQFv-7KAeE1sCmARpMftU=.598770a7-de30-4268-af0a-1e36f85c5a3d@github.com>
Message-ID: <ZLOuuRkkpLVds0Oi-95nWJgawD4TDOv_1eVaef2UUhg=.2086ddcc-2484-444f-83ab-23e2c3fe57af@github.com>

On Wed, 1 Dec 2021 20:43:38 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> A small fix to ensure that the globally shared ClassPathImageEntry is not being deleted in CDS code.
>> The test failure is hard to reproduce. The proposed fix passed CI tiers 1-4 testing.
>> Currently running the TestOutOfProcessMigration.java test repeatedly on linux-x64 with the vm options in the bug report.
>
> src/hotspot/share/cds/filemap.cpp line 2495:
> 
>> 2493:     const char* path = scpe->name();
>> 2494:     struct stat st;
>> 2495:     if (os::stat(path, &st) != 0) {
> 
> Do you check if the file exists? If so please use os::file_exists which is better.

Using `os::file_exists` won't work because few lines below that I need to use the `st` returned from `os::stat`.

`ent = ClassLoader::create_class_path_entry(THREAD, path, &st, false, false);`

-------------

PR: https://git.openjdk.java.net/jdk/pull/6651

From duke at openjdk.java.net  Thu Dec  2 02:36:47 2021
From: duke at openjdk.java.net (Tim Prinzing)
Date: Thu, 2 Dec 2021 02:36:47 GMT
Subject: RFR: JDK-8276674 : Malformed Javadoc inline tags in JDK source in
 java/util/stream [v2]
In-Reply-To: <NMEtofVxulh6JNDcOLF-zGYKB2gnLKUF-9Or07_oJ4k=.ecc5a86f-5d37-415b-a6b6-4104a12d8676@github.com>
References: <NMEtofVxulh6JNDcOLF-zGYKB2gnLKUF-9Or07_oJ4k=.ecc5a86f-5d37-415b-a6b6-4104a12d8676@github.com>
Message-ID: <TzkyN_WmuxVm2lVTwnD4-AmDckP5HA2HnpzLNxt3wzI=.3e6ca6e7-3d3c-4e68-846e-4e8698dbe1ac@github.com>

> JDK-8276674 : Malformed Javadoc inline tags in JDK source in java/util/stream

Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into JDK-8276674
 - Fixed @code and @link in some javadoc for JDK-8276674

-------------

Changes: https://git.openjdk.java.net/jdk/pull/6443/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6443&range=01
  Stats: 13 lines in 8 files changed: 0 ins; 0 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6443.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6443/head:pull/6443

PR: https://git.openjdk.java.net/jdk/pull/6443

From shade at openjdk.java.net  Thu Dec  2 07:25:42 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 2 Dec 2021 07:25:42 GMT
Subject: RFR: 8278116: runtime/modules/LoadUnloadModuleStress.java has
 duplicate -Xmx
Message-ID: <52ESY-pk36q2NRKF_0-2GEoLKrk-TheGD7yKrrsxwMQ=.5e7b2590-8d2e-488e-b36f-b015f8a4d4a0@github.com>

Spotted by Andrey here:  https://github.com/openjdk/jdk/pull/6574#issuecomment-983959564

Seems to be that way since initial integration in JDK-8142968. 

Additional testing:
 - [x] Affected test still passes on Linux x86_64 fastdebug

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.java.net/jdk/pull/6660/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6660&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278116
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6660.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6660/head:pull/6660

PR: https://git.openjdk.java.net/jdk/pull/6660

From dholmes at openjdk.java.net  Thu Dec  2 07:47:25 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 2 Dec 2021 07:47:25 GMT
Subject: RFR: 8278116: runtime/modules/LoadUnloadModuleStress.java has
 duplicate -Xmx
In-Reply-To: <52ESY-pk36q2NRKF_0-2GEoLKrk-TheGD7yKrrsxwMQ=.5e7b2590-8d2e-488e-b36f-b015f8a4d4a0@github.com>
References: <52ESY-pk36q2NRKF_0-2GEoLKrk-TheGD7yKrrsxwMQ=.5e7b2590-8d2e-488e-b36f-b015f8a4d4a0@github.com>
Message-ID: <1_SyQZwyczp5fwtGnyAkwMPRmr2-8rHrdrTjz9oTK9A=.f45ceb99-f8ed-4740-8b71-1190a51d0cd2@github.com>

On Thu, 2 Dec 2021 07:17:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Spotted by Andrey here:  https://github.com/openjdk/jdk/pull/6574#issuecomment-983959564
> 
> Seems to be that way since initial integration in JDK-8142968. 
> 
> Additional testing:
>  - [x] Affected test still passes on Linux x86_64 fastdebug

Seems fine and trivial.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6660

From yyang at openjdk.java.net  Thu Dec  2 13:31:49 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 2 Dec 2021 13:31:49 GMT
Subject: RFR: 8278125: Some preallocated OOMEs are missing stack trace
Message-ID: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>

Our customer found that the PreallocatedOutOfMemoryErrorCount is 4 by default. It ought to pre-allocate 4 OOMEs with stack trace, but in fact, no matter how many OOMEs are thrown, only 2 OOMEs have proper stack trace. This is because PreallocatedOutOfMemoryErrorCount is consumed multiple times:

VM tries to allocate a huge object while Java heap is insufficient to accommodate, it goes to:

https://github.com/openjdk/jdk/blob/b79554bb5cef14590d427543a40efbcc60c66548/src/hotspot/share/gc/shared/memAllocator.cpp#L115-L136

Line 135(`Universe::out_of_memory_error_java_heap`->`Universe::gen_out_of_memory_error`) and line 136(`THROW_OOP_`->`Exceptions::_throw`->`Exceptions::count_out_of_memory_exceptions`->`Universe::out_of_memory_error_java_heap`->`Universe::gen_out_of_memory_error`) call `Universe::gen_out_of_memory_error` twice in a single OOM event, which leads this unexpected scenario. Proposed fix is to remove such call in `Exceptions::count_out_of_memory_exceptions`.

Thanks.

-------------

Commit messages:
 - whitespace
 - whitespace
 - 8278125 Some preallocated OOMEs are missing stack trace

Changes: https://git.openjdk.java.net/jdk/pull/6672/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6672&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278125
  Stats: 64 lines in 2 files changed: 62 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6672.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6672/head:pull/6672

PR: https://git.openjdk.java.net/jdk/pull/6672

From rkennke at openjdk.java.net  Thu Dec  2 14:41:53 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 2 Dec 2021 14:41:53 GMT
Subject: RFR: 8276901: Implement UseHeavyMonitors consistently [v11]
In-Reply-To: <CqBVDMLRhPl93f8gcv5VX0Un-fFF5BQtGEwrczIJdp4=.6a50ad8f-3bbe-4075-9f8c-ee4da37e9f8b@github.com>
References: <CqBVDMLRhPl93f8gcv5VX0Un-fFF5BQtGEwrczIJdp4=.6a50ad8f-3bbe-4075-9f8c-ee4da37e9f8b@github.com>
Message-ID: <3ij7xShJzxFD9U79iHoJPnHJzg6rPv7T1r67gIqEuD4=.3b964bd4-1374-4d14-a4b3-e209c5954093@github.com>

> The flag UseHeavyMonitors seems to imply that it makes Hotspot always use inflated monitors, rather than stack locks. However, it is only implemented in the interpreter that way. When it calls into runtime, it would still happily stack-lock. Even worse, C1 uses another flag UseFastLocking to achieve something similar (with the same caveat that runtime would stack-lock anyway). C2 doesn't have any such mechanism at all.
> I would like to experiment with disabling stack-locking, and thus, having this flag work as expected would seem very useful.
> 
> The change removes the C1 flag UseFastLocking, and replaces its uses with equivalent (i.e. inverted) UseHeavyMonitors instead. I think it makes sense to make UseHeavyMonitors develop (I wouldn't want anybody to use this in production, not currently without this change, and not with this change). I also added a flag VerifyHeavyMonitors to be able to verify that stack-locking is really disabled. We can't currently verify this uncondiftionally (e.g. in debug builds) because all non-x86_64 platforms would need work.
> 
> Testing:
>  - [x] tier1
>  - [x] tier2
>  - [x] tier3
>  - [ ] tier4

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  PPC port by @TheRealMDoerr

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6320/files
  - new: https://git.openjdk.java.net/jdk/pull/6320/files/79090ed1..706d1e85

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6320&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6320&range=09-10

  Stats: 55 lines in 4 files changed: 11 ins; 0 del; 44 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6320.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6320/head:pull/6320

PR: https://git.openjdk.java.net/jdk/pull/6320

From rkennke at openjdk.java.net  Thu Dec  2 14:41:54 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 2 Dec 2021 14:41:54 GMT
Subject: RFR: 8276901: Implement UseHeavyMonitors consistently [v10]
In-Reply-To: <zUJcdm1NnPIhddVUsNT8OeBD6Y-3ofsk_v4IqtbFr5w=.9a9bbaf5-0639-4e37-a8d1-0d3c0fd7caae@github.com>
References: <CqBVDMLRhPl93f8gcv5VX0Un-fFF5BQtGEwrczIJdp4=.6a50ad8f-3bbe-4075-9f8c-ee4da37e9f8b@github.com>
 <___2nS2ZNEiggHv_C70jADW_cE-T2wUJKqRK_J5gIj0=.23da20f8-ba19-4279-b154-f0a67626ccf4@github.com>
 <5oeP5b_jS2eu5lsDpNkfIBINEPPT23A-kqeHwOSXrYQ=.e32eb661-903d-4778-a56f-2a1d525d1874@github.com>
 <NegQo7AZ4KAbB_u2-lAUQWfotCebTuHy_v7Bn7ycXy8=.2ac2037f-2fa0-471c-a122-01767cf1bc35@github.com>
 <DpfOa_DlZZsTutAz0MUg_e5jEtn6sJNSP8COH3jUNMQ=.e9aa3302-6b7b-4986-b609-c43226cebeb7@github.com>
 <zUJcdm1NnPIhddVUsNT8OeBD6Y-3ofsk_v4IqtbFr5w=.9a9bbaf5-0639-4e37-a8d1-0d3c0fd7caae@github.com>
Message-ID: <YCN1Q3QnrUepgO-lmGSw3bjWNFDoHhda14mpJWI3ap8=.02bec96e-e8ca-4f27-9df5-f65aa6614ba8@github.com>

On Thu, 2 Dec 2021 00:55:02 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>>> > I believe you still have to change something in sharedRuntime_ppc.cpp, similar to what I did in, e.g., sharedRuntime_aarch64.cpp.
>>> 
>>> You mean in `generate_native_wrapper`? I already did. It uses the same assembler function as C2 on PPC64. Did I miss anything else? I think hacking `unlock` is optional. The additional checks don't really disturb.
>> 
>> Ah I haven't seen it, sorry.
>> It turns out, I cannot avoid emitting FastLockNode, some backends (x86 and aarch64) also generate fast-path code that deals with ObjectMonitor, and we want this even when running with +UseHeavyMonitors.
>> 
>> Can you verify the new testcase, and perhaps some test programs that do some locking with -XX:+UseHeavyMonitors -XX:+VerifyHeavyMonitors ? You also need to include PPC in arguments.cpp and synchronizer.cpp changes to enable that stuff on PPC:
>
>> It turns out, I cannot avoid emitting FastLockNode, some backends (x86 and aarch64) also generate fast-path code that deals with ObjectMonitor, and we want this even when running with +UseHeavyMonitors.
> 
> Ok, thanks for checking. You have convinced me that your version is fine. We should do it the same way on PPC64:
> 
> diff --git a/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp b/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
> index 98565003691..cb58e775422 100644
> --- a/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
> +++ b/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
> @@ -2660,27 +2660,32 @@ void MacroAssembler::compiler_fast_lock_object(ConditionRegister flag, Register
>    andi_(temp, displaced_header, markWord::monitor_value);
>    bne(CCR0, object_has_monitor);
>  
> -  // Set displaced_header to be (markWord of object | UNLOCK_VALUE).
> -  ori(displaced_header, displaced_header, markWord::unlocked_value);
> -
> -  // Load Compare Value application register.
> -
> -  // Initialize the box. (Must happen before we update the object mark!)
> -  std(displaced_header, BasicLock::displaced_header_offset_in_bytes(), box);
> -
> -  // Must fence, otherwise, preceding store(s) may float below cmpxchg.
> -  // Compare object markWord with mark and if equal exchange scratch1 with object markWord.
> -  cmpxchgd(/*flag=*/flag,
> -           /*current_value=*/current_header,
> -           /*compare_value=*/displaced_header,
> -           /*exchange_value=*/box,
> -           /*where=*/oop,
> -           MacroAssembler::MemBarRel | MacroAssembler::MemBarAcq,
> -           MacroAssembler::cmpxchgx_hint_acquire_lock(),
> -           noreg,
> -           &cas_failed,
> -           /*check without membar and ldarx first*/true);
> -  assert(oopDesc::mark_offset_in_bytes() == 0, "offset of _mark is not 0");
> +  if (!UseHeavyMonitors) {
> +    // Set displaced_header to be (markWord of object | UNLOCK_VALUE).
> +    ori(displaced_header, displaced_header, markWord::unlocked_value);
> +
> +    // Load Compare Value application register.
> +
> +    // Initialize the box. (Must happen before we update the object mark!)
> +    std(displaced_header, BasicLock::displaced_header_offset_in_bytes(), box);
> +
> +    // Must fence, otherwise, preceding store(s) may float below cmpxchg.
> +    // Compare object markWord with mark and if equal exchange scratch1 with object markWord.
> +    cmpxchgd(/*flag=*/flag,
> +             /*current_value=*/current_header,
> +             /*compare_value=*/displaced_header,
> +             /*exchange_value=*/box,
> +             /*where=*/oop,
> +             MacroAssembler::MemBarRel | MacroAssembler::MemBarAcq,
> +             MacroAssembler::cmpxchgx_hint_acquire_lock(),
> +             noreg,
> +             &cas_failed,
> +             /*check without membar and ldarx first*/true);
> +    assert(oopDesc::mark_offset_in_bytes() == 0, "offset of _mark is not 0");
> +  } else {
> +    // Set NE to indicate 'failure' -> take slow-path.
> +    crandc(flag, Assembler::equal, flag, Assembler::equal);
> +  }
>  
>    // If the compare-and-exchange succeeded, then we found an unlocked
>    // object and we have now locked it.
> @@ -2768,12 +2773,14 @@ void MacroAssembler::compiler_fast_unlock_object(ConditionRegister flag, Registe
>    }
>  #endif
>  
> -  // Find the lock address and load the displaced header from the stack.
> -  ld(displaced_header, BasicLock::displaced_header_offset_in_bytes(), box);
> +  if (!UseHeavyMonitors) {
> +    // Find the lock address and load the displaced header from the stack.
> +    ld(displaced_header, BasicLock::displaced_header_offset_in_bytes(), box);
>  
> -  // If the displaced header is 0, we have a recursive unlock.
> -  cmpdi(flag, displaced_header, 0);
> -  beq(flag, cont);
> +    // If the displaced header is 0, we have a recursive unlock.
> +    cmpdi(flag, displaced_header, 0);
> +    beq(flag, cont);
> +  }
>  
>    // Handle existing monitor.
>    // The object has an existing monitor iff (mark & monitor_value) != 0.
> @@ -2782,20 +2789,24 @@ void MacroAssembler::compiler_fast_unlock_object(ConditionRegister flag, Registe
>    andi_(R0, current_header, markWord::monitor_value);
>    bne(CCR0, object_has_monitor);
>  
> -  // Check if it is still a light weight lock, this is is true if we see
> -  // the stack address of the basicLock in the markWord of the object.
> -  // Cmpxchg sets flag to cmpd(current_header, box).
> -  cmpxchgd(/*flag=*/flag,
> -           /*current_value=*/current_header,
> -           /*compare_value=*/box,
> -           /*exchange_value=*/displaced_header,
> -           /*where=*/oop,
> -           MacroAssembler::MemBarRel,
> -           MacroAssembler::cmpxchgx_hint_release_lock(),
> -           noreg,
> -           &cont);
> -
> -  assert(oopDesc::mark_offset_in_bytes() == 0, "offset of _mark is not 0");
> +  if (!UseHeavyMonitors) {
> +    // Check if it is still a light weight lock, this is is true if we see
> +    // the stack address of the basicLock in the markWord of the object.
> +    // Cmpxchg sets flag to cmpd(current_header, box).
> +    cmpxchgd(/*flag=*/flag,
> +             /*current_value=*/current_header,
> +             /*compare_value=*/box,
> +             /*exchange_value=*/displaced_header,
> +             /*where=*/oop,
> +             MacroAssembler::MemBarRel,
> +             MacroAssembler::cmpxchgx_hint_release_lock(),
> +             noreg,
> +             &cont);
> +    assert(oopDesc::mark_offset_in_bytes() == 0, "offset of _mark is not 0");
> +  } else {
> +    // Set NE to indicate 'failure' -> take slow-path.
> +    crandc(flag, Assembler::equal, flag, Assembler::equal);
> +  }
>  
>    // Handle existing monitor.
>    b(cont);
> diff --git a/src/hotspot/share/runtime/arguments.cpp b/src/hotspot/share/runtime/arguments.cpp
> index 3396adc0799..969c8e82b91 100644
> --- a/src/hotspot/share/runtime/arguments.cpp
> +++ b/src/hotspot/share/runtime/arguments.cpp
> @@ -2021,12 +2021,12 @@ bool Arguments::check_vm_args_consistency() {
>    }
>  #endif
>  
> -#if !defined(X86) && !defined(AARCH64)
> +#if !defined(X86) && !defined(AARCH64) && !defined(PPC64)
>    if (UseHeavyMonitors) {
>      warning("UseHeavyMonitors is not fully implemented on this architecture");
>    }
>  #endif
> -#ifdef X86
> +#if defined(X86) || defined(PPC64)
>    if (UseHeavyMonitors && UseRTMForStackLocks) {
>      fatal("-XX:+UseHeavyMonitors and -XX:+UseRTMForStackLocks are mutually exclusive");
>    }
> diff --git a/src/hotspot/share/runtime/synchronizer.cpp b/src/hotspot/share/runtime/synchronizer.cpp
> index 4c5ea4a6e40..4f9c7c21a9b 100644
> --- a/src/hotspot/share/runtime/synchronizer.cpp
> +++ b/src/hotspot/share/runtime/synchronizer.cpp
> @@ -418,7 +418,7 @@ void ObjectSynchronizer::handle_sync_on_value_based_class(Handle obj, JavaThread
>  }
>  
>  static bool useHeavyMonitors() {
> -#if defined(X86) || defined(AARCH64)
> +#if defined(X86) || defined(AARCH64) || defined(PPC64)
>    return UseHeavyMonitors;
>  #else
>    return false;
> diff --git a/test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java b/test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java
> index cd32e222f68..922b18836dd 100644
> --- a/test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java
> +++ b/test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java
> @@ -48,7 +48,7 @@
>  /*
>   * @test
>   * @summary Exercise multithreaded maps, using only heavy monitors.
> - * @requires os.arch=="x86" | os.arch=="i386" | os.arch=="amd64" | os.arch=="x86_64" | os.arch=="aarch64"
> + * @requires os.arch=="x86" | os.arch=="i386" | os.arch=="amd64" | os.arch=="x86_64" | os.arch=="aarch64" | os.arch == "ppc64" | os.arch == "ppc64le"
>   * @library /test/lib
>   * @run main/othervm/timeout=1600 -XX:+IgnoreUnrecognizedVMOptions -XX:+UseHeavyMonitors -XX:+VerifyHeavyMonitors MapLoops
>   */
> 
> Note that this version does no longer require changes in sharedRuntime_ppc because the native wrapper generator uses the same code as C2. The test case has passed.

Thanks, @TheRealMDoerr ! I've added your PPC port to this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6320

From ccheung at openjdk.java.net  Thu Dec  2 14:43:30 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 2 Dec 2021 14:43:30 GMT
Subject: RFR: 8276126: Dump time class transformation causes heap objects
 of non-boot classes to be archived [v3]
In-Reply-To: <kUEatV3XmWqH-BHI4gT37DZqUWJ9uchbxci5ycrCUF8=.4e89562d-99ae-420f-9d6d-7ca00a15ab2a@github.com>
References: <wcTCcSYZsoJCU5ZtXovHwHk0hF6p5FBPcyp0U-EhtQ8=.de3d7c75-f827-411f-973e-132664296dc0@github.com>
 <rz8ZoBrIj3rC_gKsEyU9UdzkvVc-Pgyh91WGKGYO2Fg=.e6f05f04-834a-4ac0-897f-76827e08c964@github.com>
 <kUEatV3XmWqH-BHI4gT37DZqUWJ9uchbxci5ycrCUF8=.4e89562d-99ae-420f-9d6d-7ca00a15ab2a@github.com>
Message-ID: <AGdFGq3xDfmr2lzHRQdNERCyJC-oRzlQZSmGOe4OIpA=.b18b511c-09d0-479e-84e2-07335d4c8399@github.com>

On Tue, 30 Nov 2021 03:59:13 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify the fix by passing a 'redefined' flag from KlassFactory::create_from_stream() to ClassLoader::record_result()
>
> LGTM. One small nit about unused parameter.

Thanks @iklam and @yminqi for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6484

From ccheung at openjdk.java.net  Thu Dec  2 14:43:31 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 2 Dec 2021 14:43:31 GMT
Subject: Integrated: 8276126: Dump time class transformation causes heap
 objects of non-boot classes to be archived
In-Reply-To: <wcTCcSYZsoJCU5ZtXovHwHk0hF6p5FBPcyp0U-EhtQ8=.de3d7c75-f827-411f-973e-132664296dc0@github.com>
References: <wcTCcSYZsoJCU5ZtXovHwHk0hF6p5FBPcyp0U-EhtQ8=.de3d7c75-f827-411f-973e-132664296dc0@github.com>
Message-ID: <nFXl2F7CpR4IsY-fDa9ymOi6ghG3L8ZZ-wfDZRclFEQ=.8b573ce2-27f7-4ac7-b2c4-441721bf3dd2@github.com>

On Sat, 20 Nov 2021 02:20:17 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> During CDS static dump, if a class loaded by a boot class loader is transformed by a java agent, the transformed class is mistakenly identified as a class loaded by a custom loader. This would cause archiving of the heap objects to fail.
> 
> The proposed patch corrects the identification of the transformed class and will not include it in the archive.
> Also, if a transformed class is detected during dump time, the archiving of the heap objects will be disabled.
> 
> Testing: Oracle CI tiers 1-3, tier4 in progress.

This pull request has now been integrated.

Changeset: d2b16c89
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d2b16c89855d584a563caa4f725802dc91a83407
Stats:     201 lines in 11 files changed: 191 ins; 0 del; 10 mod

8276126: Dump time class transformation causes heap objects of non-boot classes to be archived

Reviewed-by: iklam, minqi

-------------

PR: https://git.openjdk.java.net/jdk/pull/6484

From darcy at openjdk.java.net  Thu Dec  2 18:29:41 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 2 Dec 2021 18:29:41 GMT
Subject: RFR: JDK-8273146: Start of release updates for JDK 19 [v7]
In-Reply-To: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
References: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
Message-ID: <VyhYwb8d_zFqpeKiat7Gi4ooytJrD6Lb-NdvUkHFcrA=.d22c2f8c-8eda-409c-ab3b-35d7ba34c3ad@github.com>

> The time to get JDK 19 underway draws nigh, please review this usual set of start-of-release updates, including CSRs for the javac and javax.lang.model updates:
> 
> JDK-8277512: Add SourceVersion.RELEASE_19
> https://bugs.openjdk.java.net/browse/JDK-8277512
> 
> JDK-8277514: Add source 19 and target 19 to javac
> https://bugs.openjdk.java.net/browse/JDK-8277514
> 
> Clean local tier 1 test runs for langtools, jdk, and hotspot.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Update symbol information for JDK 18 b25.
 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Remove SharedSpaces options from VMDeprecatedOptions.java.
 - Merge branch 'master' into JDK-8273146
 - Respond to review feedback.
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/8b042d14...b1b4ae2b

-------------

Changes: https://git.openjdk.java.net/jdk/pull/6493/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6493&range=06
  Stats: 3280 lines in 67 files changed: 3237 ins; 4 del; 39 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6493.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6493/head:pull/6493

PR: https://git.openjdk.java.net/jdk/pull/6493

From hseigel at openjdk.java.net  Thu Dec  2 19:29:45 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 2 Dec 2021 19:29:45 GMT
Subject: RFR: 8276241: JVM does not flag constant class entries ending in '/'
Message-ID: <ntwDBwQxjsc7-e3DRMF4wP_MtuK4Y-uGOsFUmKURVyc=.df230152-3ae4-4fc4-b506-0e25d4edb391@github.com>

Please review this small fix for JDK-8276241.  The fix ensures that a ClassFormatError exception gets thrown for classes whose name ends in a '/' and are class file version less than 49 (JDK 1.5).  (A CFE already gets thrown for newer class file versions.)  The regression test class was written using a byte array because neither jcod nor jasm could handle a class name ending in '/'.

The fix was tested by running JCK lang and VM tests on Linux x64, Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.

Thanks, Harold

-------------

Commit messages:
 - 8276241: JVM does not flag constant class entries ending in '/'

Changes: https://git.openjdk.java.net/jdk/pull/6678/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6678&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276241
  Stats: 87 lines in 2 files changed: 84 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6678.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6678/head:pull/6678

PR: https://git.openjdk.java.net/jdk/pull/6678

From bchristi at openjdk.java.net  Thu Dec  2 20:44:19 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Thu, 2 Dec 2021 20:44:19 GMT
Subject: RFR: JDK-8276674 : Malformed Javadoc inline tags in JDK source
 [v2]
In-Reply-To: <TzkyN_WmuxVm2lVTwnD4-AmDckP5HA2HnpzLNxt3wzI=.3e6ca6e7-3d3c-4e68-846e-4e8698dbe1ac@github.com>
References: <NMEtofVxulh6JNDcOLF-zGYKB2gnLKUF-9Or07_oJ4k=.ecc5a86f-5d37-415b-a6b6-4104a12d8676@github.com>
 <TzkyN_WmuxVm2lVTwnD4-AmDckP5HA2HnpzLNxt3wzI=.3e6ca6e7-3d3c-4e68-846e-4e8698dbe1ac@github.com>
Message-ID: <0gXyEfJJNpaLR25-eBZpRR-Jn8dX0LCYxsEdBI3u5DA=.79af9dd2-895d-4f8c-b853-78a5d1ee2015@github.com>

On Thu, 2 Dec 2021 02:36:47 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

>> JDK-8276674 : Malformed Javadoc inline tags in JDK source
>
> Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into JDK-8276674
>  - Fixed @code and @link in some javadoc for JDK-8276674

Looks good.  Thanks for renaming, per Pavel's suggestion.  I can sponsor this.

-------------

Marked as reviewed by bchristi (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6443

From duke at openjdk.java.net  Thu Dec  2 20:52:18 2021
From: duke at openjdk.java.net (Tim Prinzing)
Date: Thu, 2 Dec 2021 20:52:18 GMT
Subject: Integrated: JDK-8276674 : Malformed Javadoc inline tags in JDK source
In-Reply-To: <NMEtofVxulh6JNDcOLF-zGYKB2gnLKUF-9Or07_oJ4k=.ecc5a86f-5d37-415b-a6b6-4104a12d8676@github.com>
References: <NMEtofVxulh6JNDcOLF-zGYKB2gnLKUF-9Or07_oJ4k=.ecc5a86f-5d37-415b-a6b6-4104a12d8676@github.com>
Message-ID: <TIDuuTFNp21jEDE1HwoI-nTiN8C2ePPoBZFDvmt2aUE=.cbbf6a77-afb1-49a9-bf90-8994656e8c8d@github.com>

On Thu, 18 Nov 2021 03:22:50 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

> JDK-8276674 : Malformed Javadoc inline tags in JDK source

This pull request has now been integrated.

Changeset: 652b5f85
Author:    Tim Prinzing <tim at prinzing.net>
Committer: Brent Christian <bchristi at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/652b5f8546d0453238166f8fcd0cd3d882886bb4
Stats:     13 lines in 8 files changed: 0 ins; 0 del; 13 mod

8276674: Malformed Javadoc inline tags in JDK source

Reviewed-by: jjg, rriggs, prappo, bchristi

-------------

PR: https://git.openjdk.java.net/jdk/pull/6443

From jiefu at openjdk.java.net  Thu Dec  2 23:40:40 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 2 Dec 2021 23:40:40 GMT
Subject: RFR: 8278174: runtime/cds/appcds/LambdaWithJavaAgent.java fails with
 release VMs
Message-ID: <b98UZsyGwftWV3jo4aoOQAf1mM0RTsu6aHCKZPWE208=.1e44df4f-2ebc-4154-800f-fbaeabc50363@github.com>

Hi all,

runtime/cds/appcds/LambdaWithJavaAgent.java fails with release VMs.
This is because VM option 'AllowArchivingWithJavaAgent' is diagnostic and must be enabled via -XX:+UnlockDiagnosticVMOptions.
So let's add -XX:+UnlockDiagnosticVMOptions to fix it.

Thanks.
Best regards,
Jie

-------------

Commit messages:
 - 8278174: runtime/cds/appcds/LambdaWithJavaAgent.java fails with release VMs

Changes: https://git.openjdk.java.net/jdk/pull/6684/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6684&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278174
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6684.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6684/head:pull/6684

PR: https://git.openjdk.java.net/jdk/pull/6684

From dholmes at openjdk.java.net  Fri Dec  3 03:37:16 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 3 Dec 2021 03:37:16 GMT
Subject: RFR: 8276241: JVM does not flag constant class entries ending in
 '/'
In-Reply-To: <ntwDBwQxjsc7-e3DRMF4wP_MtuK4Y-uGOsFUmKURVyc=.df230152-3ae4-4fc4-b506-0e25d4edb391@github.com>
References: <ntwDBwQxjsc7-e3DRMF4wP_MtuK4Y-uGOsFUmKURVyc=.df230152-3ae4-4fc4-b506-0e25d4edb391@github.com>
Message-ID: <qusHluSB_knsl-lPtRhTFR1k65MogHnvbOlPbUUuI5E=.83fca2a5-3d3a-4eba-a86e-e1cf5170cfb0@github.com>

On Thu, 2 Dec 2021 19:22:20 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix for JDK-8276241.  The fix ensures that a ClassFormatError exception gets thrown for classes whose name ends in a '/' and are class file version less than 49 (JDK 1.5).  (A CFE already gets thrown for newer class file versions.)  The regression test class was written using a byte array because neither jcod nor jasm could handle a class name ending in '/'.
> 
> The fix was tested by running JCK lang and VM tests on Linux x64, Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.
> 
> Thanks, Harold

Hi Harold,

Fix seems fine, but this kind of change needs a CSR request.

I can't imagine how one might use a class with a name ending in slash, but this is an incompatible change that affects really old classfiles.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6678

From dholmes at openjdk.java.net  Fri Dec  3 04:24:14 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 3 Dec 2021 04:24:14 GMT
Subject: RFR: 8278125: Some preallocated OOMEs are missing stack trace
In-Reply-To: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
References: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
Message-ID: <FGT0HSPFcmazWxZcjV1tWqJIZxvgsf0QQKc755HQh4Y=.870114bb-a141-4412-942c-0b49fd0e7dc9@github.com>

On Thu, 2 Dec 2021 12:54:31 GMT, Yi Yang <yyang at openjdk.org> wrote:

> Our customer found that the PreallocatedOutOfMemoryErrorCount is 4 by default. It ought to pre-allocate 4 OOMEs with stack trace, but in fact, no matter how many OOMEs are thrown, only 2 OOMEs have proper stack trace. This is because PreallocatedOutOfMemoryErrorCount is consumed multiple times:
> 
> VM tries to allocate a huge object while Java heap is insufficient to accommodate, it goes to:
> 
> https://github.com/openjdk/jdk/blob/b79554bb5cef14590d427543a40efbcc60c66548/src/hotspot/share/gc/shared/memAllocator.cpp#L115-L136
> 
> Line 135(`Universe::out_of_memory_error_java_heap`->`Universe::gen_out_of_memory_error`) and line 136(`THROW_OOP_`->`Exceptions::_throw`->`Exceptions::count_out_of_memory_exceptions`->`Universe::out_of_memory_error_java_heap`->`Universe::gen_out_of_memory_error`) call `Universe::gen_out_of_memory_error` twice in a single OOM event, which leads this unexpected scenario. Proposed fix is to remove such call in `Exceptions::count_out_of_memory_exceptions`.
> 
> Thanks.

Good find!

`count_out_of_memory_exceptions` is obviously confused as to how pre-allocated exceptions work! The logic will not only create new exception objects, consuming the preallocated allotment, but it won't start counting correctly until all the mutable preallocated exceptions are consumed and the default stacktrace-less one is passed in.

I'm not sure about using the strcmp directly in that method though as it requires knowledge of how the strings are defined in universe.cpp. Adding `Universe::is_an_out_of_memory_metaspace(Handle exception)` etc provides better encapsulation.

Thanks,
David

-------------

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6672

From dholmes at openjdk.java.net  Fri Dec  3 05:12:16 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 3 Dec 2021 05:12:16 GMT
Subject: RFR: 8278174: runtime/cds/appcds/LambdaWithJavaAgent.java fails
 with release VMs
In-Reply-To: <b98UZsyGwftWV3jo4aoOQAf1mM0RTsu6aHCKZPWE208=.1e44df4f-2ebc-4154-800f-fbaeabc50363@github.com>
References: <b98UZsyGwftWV3jo4aoOQAf1mM0RTsu6aHCKZPWE208=.1e44df4f-2ebc-4154-800f-fbaeabc50363@github.com>
Message-ID: <43QyjYV1jVeyNNIj1Ne0yok2reuBgqz0IHPL1cIm_jg=.a343ccf9-d7e9-4925-be96-30977bf3a0a7@github.com>

On Thu, 2 Dec 2021 23:32:09 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> runtime/cds/appcds/LambdaWithJavaAgent.java fails with release VMs.
> This is because VM option 'AllowArchivingWithJavaAgent' is diagnostic and must be enabled via -XX:+UnlockDiagnosticVMOptions.
> So let's add -XX:+UnlockDiagnosticVMOptions to fix it.
> 
> Thanks.
> Best regards,
> Jie

Looks good and trivial.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6684

From yyang at openjdk.java.net  Fri Dec  3 05:51:48 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Fri, 3 Dec 2021 05:51:48 GMT
Subject: RFR: 8278125: Some preallocated OOMEs are missing stack trace [v2]
In-Reply-To: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
References: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
Message-ID: <AV2S-29XpWTCQh7mToBLRWh4bVMo_BygEMA44T_bXkc=.a38aa64b-0a70-4b63-b8d7-b646de83e936@github.com>

> Our customer found that the PreallocatedOutOfMemoryErrorCount is 4 by default. It ought to pre-allocate 4 OOMEs with stack trace, but in fact, no matter how many OOMEs are thrown, only 2 OOMEs have proper stack trace. This is because PreallocatedOutOfMemoryErrorCount is consumed multiple times:
> 
> VM tries to allocate a huge object while Java heap is insufficient to accommodate, it goes to:
> 
> https://github.com/openjdk/jdk/blob/b79554bb5cef14590d427543a40efbcc60c66548/src/hotspot/share/gc/shared/memAllocator.cpp#L115-L136
> 
> Line 135(`Universe::out_of_memory_error_java_heap`->`Universe::gen_out_of_memory_error`) and line 136(`THROW_OOP_`->`Exceptions::_throw`->`Exceptions::count_out_of_memory_exceptions`->`Universe::out_of_memory_error_java_heap`->`Universe::gen_out_of_memory_error`) call `Universe::gen_out_of_memory_error` twice in a single OOM event, which leads this unexpected scenario. Proposed fix is to remove such call in `Exceptions::count_out_of_memory_exceptions`.
> 
> Thanks.

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  Universe::is_out_of_memory_xx

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6672/files
  - new: https://git.openjdk.java.net/jdk/pull/6672/files/b14e2d8d..b60d2d9f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6672&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6672&range=00-01

  Stats: 40 lines in 3 files changed: 27 ins; 2 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6672.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6672/head:pull/6672

PR: https://git.openjdk.java.net/jdk/pull/6672

From jiefu at openjdk.java.net  Fri Dec  3 06:05:16 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 3 Dec 2021 06:05:16 GMT
Subject: RFR: 8278174: runtime/cds/appcds/LambdaWithJavaAgent.java fails
 with release VMs
In-Reply-To: <43QyjYV1jVeyNNIj1Ne0yok2reuBgqz0IHPL1cIm_jg=.a343ccf9-d7e9-4925-be96-30977bf3a0a7@github.com>
References: <b98UZsyGwftWV3jo4aoOQAf1mM0RTsu6aHCKZPWE208=.1e44df4f-2ebc-4154-800f-fbaeabc50363@github.com>
 <43QyjYV1jVeyNNIj1Ne0yok2reuBgqz0IHPL1cIm_jg=.a343ccf9-d7e9-4925-be96-30977bf3a0a7@github.com>
Message-ID: <uSdOr2fy8dPdta50XbT8gB4kcRuboVH-uTkK3X6twAw=.1e20dfe6-d35a-40de-8b0d-9157e4ba1068@github.com>

On Fri, 3 Dec 2021 05:09:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Looks good and trivial.
> 
> Thanks, David

Thanks @dholmes-ora .

-------------

PR: https://git.openjdk.java.net/jdk/pull/6684

From jiefu at openjdk.java.net  Fri Dec  3 06:05:17 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 3 Dec 2021 06:05:17 GMT
Subject: Integrated: 8278174: runtime/cds/appcds/LambdaWithJavaAgent.java fails
 with release VMs
In-Reply-To: <b98UZsyGwftWV3jo4aoOQAf1mM0RTsu6aHCKZPWE208=.1e44df4f-2ebc-4154-800f-fbaeabc50363@github.com>
References: <b98UZsyGwftWV3jo4aoOQAf1mM0RTsu6aHCKZPWE208=.1e44df4f-2ebc-4154-800f-fbaeabc50363@github.com>
Message-ID: <FbKuf0ML2raG1WCvLG9OJeBCn-Wkv-5wGnVBlLXc1O4=.3ce67ffc-20de-4b49-a17b-2fd8c34e2657@github.com>

On Thu, 2 Dec 2021 23:32:09 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> runtime/cds/appcds/LambdaWithJavaAgent.java fails with release VMs.
> This is because VM option 'AllowArchivingWithJavaAgent' is diagnostic and must be enabled via -XX:+UnlockDiagnosticVMOptions.
> So let's add -XX:+UnlockDiagnosticVMOptions to fix it.
> 
> Thanks.
> Best regards,
> Jie

This pull request has now been integrated.

Changeset: 473ececa
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/473ececaf5df8392e76d022d7126770526be31f7
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8278174: runtime/cds/appcds/LambdaWithJavaAgent.java fails with release VMs

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.java.net/jdk/pull/6684

From darcy at openjdk.java.net  Fri Dec  3 06:45:45 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 3 Dec 2021 06:45:45 GMT
Subject: RFR: JDK-8273146: Start of release updates for JDK 19 [v8]
In-Reply-To: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
References: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
Message-ID: <iVjwPPaqi-iB1ndHo7Qjil89hrQang7YS_MmMYyWK0g=.9f7e829b-e635-4ad5-a13b-ed369c0a231e@github.com>

> The time to get JDK 19 underway draws nigh, please review this usual set of start-of-release updates, including CSRs for the javac and javax.lang.model updates:
> 
> JDK-8277512: Add SourceVersion.RELEASE_19
> https://bugs.openjdk.java.net/browse/JDK-8277512
> 
> JDK-8277514: Add source 19 and target 19 to javac
> https://bugs.openjdk.java.net/browse/JDK-8277514
> 
> Clean local tier 1 test runs for langtools, jdk, and hotspot.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Update symbol files to JDK 18 b26.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6493/files
  - new: https://git.openjdk.java.net/jdk/pull/6493/files/b1b4ae2b..88273596

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6493&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6493&range=06-07

  Stats: 610 lines in 3 files changed: 593 ins; 3 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6493.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6493/head:pull/6493

PR: https://git.openjdk.java.net/jdk/pull/6493

From shade at openjdk.java.net  Fri Dec  3 07:22:19 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 3 Dec 2021 07:22:19 GMT
Subject: RFR: 8278116: runtime/modules/LoadUnloadModuleStress.java has
 duplicate -Xmx
In-Reply-To: <52ESY-pk36q2NRKF_0-2GEoLKrk-TheGD7yKrrsxwMQ=.5e7b2590-8d2e-488e-b36f-b015f8a4d4a0@github.com>
References: <52ESY-pk36q2NRKF_0-2GEoLKrk-TheGD7yKrrsxwMQ=.5e7b2590-8d2e-488e-b36f-b015f8a4d4a0@github.com>
Message-ID: <_oDcD4wSyNf5QS7iA42NI9HeKlFB7TyOf5M9UY9ut3w=.b8c46449-87bd-498d-b75d-44980c39236e@github.com>

On Thu, 2 Dec 2021 07:17:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Spotted by Andrey here:  https://github.com/openjdk/jdk/pull/6574#issuecomment-983959564
> 
> Seems to be that way since initial integration in JDK-8142968. 
> 
> Additional testing:
>  - [x] Affected test still passes on Linux x86_64 fastdebug

Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/6660

From shade at openjdk.java.net  Fri Dec  3 07:22:20 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 3 Dec 2021 07:22:20 GMT
Subject: Integrated: 8278116: runtime/modules/LoadUnloadModuleStress.java has
 duplicate -Xmx
In-Reply-To: <52ESY-pk36q2NRKF_0-2GEoLKrk-TheGD7yKrrsxwMQ=.5e7b2590-8d2e-488e-b36f-b015f8a4d4a0@github.com>
References: <52ESY-pk36q2NRKF_0-2GEoLKrk-TheGD7yKrrsxwMQ=.5e7b2590-8d2e-488e-b36f-b015f8a4d4a0@github.com>
Message-ID: <wp9g7hixnWSbxW9_ACYxXYSR8XeJx5lDbjkQN3cmIIs=.0bcb3667-5e3d-4f66-8527-b57df8ab9a54@github.com>

On Thu, 2 Dec 2021 07:17:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Spotted by Andrey here:  https://github.com/openjdk/jdk/pull/6574#issuecomment-983959564
> 
> Seems to be that way since initial integration in JDK-8142968. 
> 
> Additional testing:
>  - [x] Affected test still passes on Linux x86_64 fastdebug

This pull request has now been integrated.

Changeset: bef5c7a2
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bef5c7a2865e53778e9e476e57c31c0b0f98bcb1
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8278116: runtime/modules/LoadUnloadModuleStress.java has duplicate -Xmx

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.java.net/jdk/pull/6660

From duke at openjdk.java.net  Fri Dec  3 09:33:15 2021
From: duke at openjdk.java.net (KIRIYAMA Takuya)
Date: Fri, 3 Dec 2021 09:33:15 GMT
Subject: RFR: 8277531: Print actual default stacksize on Windows thread
 logging
In-Reply-To: <75bf40e6-bf11-28b4-16e7-11e21a1d0ca0@oracle.com>
References: <L2wrxWhTIPTC8xeV3zrOnk46JIQrpf1m7iB9m6_sl34=.d7c9f526-85da-43e0-b516-291113f58192@github.com>
 <75bf40e6-bf11-28b4-16e7-11e21a1d0ca0@oracle.com>
Message-ID: <T3OAJTDch_ipEVaPCRnH4nwLEnITj0wgty2DFgrkxoA=.2bdac040-f380-4844-835a-3f5b31921e13@github.com>

On Fri, 26 Nov 2021 13:55:32 GMT, David Holmes <david.holmes at oracle.com> wrote:

> The problem is that os:;win32::default_stack_size() doesn't necessarily
> report the default stack size - it simply reports the stackSize of the
> initial main JavaThread thread. So if you print it, it should only be
> for JavaThreads that are not CompilerThreads.

In either case of JavaThreads or CompilerThreads,the stack_size argument of _beginthreadex() must be 0 when this code is executed.
According to MSDN document, If the stack_size argument can be 0, the operating system uses the same value as the stack that's specified for the main thread.
default_stack_size is specified in create_vm() which runs in the main thread, so we use default_stack_size() for CompilerThreads.

> But if you run "java -Xss256k -XX:ThreadStackSize=512K" it will print
> 256K as the default stack size when in fact all JavaThreads except the
> main thread will get a 512K stack because of ThreadStackSize.

Yes,this behavior is odd. However, this fix executed only if stacksize is not specified.
This problem should be fixed in another issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6495

From stuefe at openjdk.java.net  Fri Dec  3 10:04:10 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 3 Dec 2021 10:04:10 GMT
Subject: RFR: 8277531: Print actual default stacksize on Windows thread
 logging
In-Reply-To: <T3OAJTDch_ipEVaPCRnH4nwLEnITj0wgty2DFgrkxoA=.2bdac040-f380-4844-835a-3f5b31921e13@github.com>
References: <L2wrxWhTIPTC8xeV3zrOnk46JIQrpf1m7iB9m6_sl34=.d7c9f526-85da-43e0-b516-291113f58192@github.com>
 <75bf40e6-bf11-28b4-16e7-11e21a1d0ca0@oracle.com>
 <T3OAJTDch_ipEVaPCRnH4nwLEnITj0wgty2DFgrkxoA=.2bdac040-f380-4844-835a-3f5b31921e13@github.com>
Message-ID: <RAZoGS3tta9FVpbkdRSq2dA1BZpVXP9C1HRS-HxlR8M=.13074a86-d9f1-4243-8b00-573186ef9833@github.com>

On Fri, 3 Dec 2021 09:29:59 GMT, KIRIYAMA Takuya <duke at openjdk.java.net> wrote:

>> On 26\/11\/2021 10\:33 pm\, Takuya Kiriyama wrote\:
>>> On Mon\, 22 Nov 2021 09\:22\:39 GMT\, Takuya Kiriyama \<duke at openjdk\.java\.net> wrote\:
>>> 
>>>> I modified to log actual stack size on Windows by using \`os\:\:win32\:\:default\_stack\_size\(\)\`\.
>>>> Could you please review this fix\?
>>> 
>>> Thank you so much for your review\.
>>> Sorry it took me so long to understand discussion\.
>>> 
>>> Is there something wrong to print out the value of default\_stack\_size\?
>>> I could not confirm the problem when I combine \-Xss with \-XX\:ThreadStackSize\.\, but it doesn\'t affect this patch\.
>> 
>> The problem is that os\:\;win32\:\:default\_stack\_size\(\) doesn\'t necessarily 
>> report the default stack size \- it simply reports the stackSize of the 
>> initial main JavaThread thread\. So if you print it\, it should only be 
>> for JavaThreads that are not CompilerThreads\.
>> 
>> But if you run \"java \-Xss256k \-XX\:ThreadStackSize\=512K\" it will print 
>> 256K as the default stack size when in fact all JavaThreads except the 
>> main thread will get a 512K stack because of ThreadStackSize\.
>> 
>> So given you can\'t actually print a value that you know to be correct\, 
>> it may be best just to leave this as \"default\" \- and perhaps this is why 
>> it was that way to begin with\.
>> 
>> Cheers\,
>> David
>
>> The problem is that os:;win32::default_stack_size() doesn't necessarily
>> report the default stack size - it simply reports the stackSize of the
>> initial main JavaThread thread. So if you print it, it should only be
>> for JavaThreads that are not CompilerThreads.
> 
> In either case of JavaThreads or CompilerThreads,the stack_size argument of _beginthreadex() must be 0 when this code is executed.
> According to MSDN document, If the stack_size argument can be 0, the operating system uses the same value as the stack that's specified for the main thread.
> default_stack_size is specified in create_vm() which runs in the main thread, so we use default_stack_size() for CompilerThreads.
> 
>> But if you run "java -Xss256k -XX:ThreadStackSize=512K" it will print
>> 256K as the default stack size when in fact all JavaThreads except the
>> main thread will get a 512K stack because of ThreadStackSize.
> 
> Yes,this behavior is odd. However, this fix executed only if stacksize is not specified.
> This problem should be fixed in another issue.

Hi, @tkiriyama,

> > The problem is that os:;win32::default_stack_size() doesn't necessarily
> > report the default stack size - it simply reports the stackSize of the
> > initial main JavaThread thread. So if you print it, it should only be
> > for JavaThreads that are not CompilerThreads.
> 
> In either case of JavaThreads or CompilerThreads,the stack_size argument of _beginthreadex() must be 0 when this code is executed. According to MSDN document, If the stack_size argument can be 0, the operating system uses the same value as the stack that's specified for the main thread. default_stack_size is specified in create_vm() which runs in the main thread, so we use default_stack_size() for CompilerThreads.

Nope, unfortunately not. It runs on the thread invoking CreateJavaVM(). That is usually not the OS main thread (aka primordial thread). In the case of the standard java launcher, the primordial thread spawns a second thread to invoke CreateJavaVM() in, mainly to impose -Xss. In the case of a custom launcher, all bets are open which thread invokes CreateJavaVM(), but typically it's not the primordial thread either. In fact, we have platforms that explicitly forbid invoking CreateJavaVM() on the primordial thread.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6495

From duke at openjdk.java.net  Fri Dec  3 16:24:30 2021
From: duke at openjdk.java.net (Tobias Holenstein)
Date: Fri, 3 Dec 2021 16:24:30 GMT
Subject: RFR: JDK-8154011: Make TraceDeoptimization a diagnostic flag
Message-ID: <Ukrn4-xlVC_9jOUincD44R6jn27tccslziubVV8c4CU=.ecf0d4ba-73a4-4086-877c-d0ac5f03ab6d@github.com>

Make TraceDeoptimization available in a product build.

I checked that performance is not affected on Aurora.

-------------

Commit messages:
 - JDK-8154011: Make TraceDeoptimization a diagnostic flag

Changes: https://git.openjdk.java.net/jdk/pull/6703/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6703&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8154011
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6703.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6703/head:pull/6703

PR: https://git.openjdk.java.net/jdk/pull/6703

From ccheung at openjdk.java.net  Fri Dec  3 16:42:19 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 3 Dec 2021 16:42:19 GMT
Subject: RFR: 8268288:
 jdk/jfr/api/consumer/streaming/TestOutOfProcessMigration.java fails with
 "Error: ShouldNotReachHere()"
In-Reply-To: <ICnRBOsmT7VZvS4-IHKvsMqDPpkGVhOGkaPgkUzOUB8=.4c0cc9e1-4ff9-4d58-bf04-537642422b65@github.com>
References: <ZQDhdrk36fVLZlhP7RGhQvlxudfjy1YehtZRKfdDAiA=.3de6c554-ac14-4c25-92c7-c774af13d6fa@github.com>
 <ICnRBOsmT7VZvS4-IHKvsMqDPpkGVhOGkaPgkUzOUB8=.4c0cc9e1-4ff9-4d58-bf04-537642422b65@github.com>
Message-ID: <RkK86V8NEOl1A2MKU8X_aAjPUE_9iqqy25w3_hCjHjw=.57636af5-c52f-47c7-a641-d5b3057daa4a@github.com>

On Wed, 1 Dec 2021 23:36:05 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> A small fix to ensure that the globally shared ClassPathImageEntry is not being deleted in CDS code.
>> The test failure is hard to reproduce. The proposed fix passed CI tiers 1-4 testing.
>> Currently running the TestOutOfProcessMigration.java test repeatedly on linux-x64 with the vm options in the bug report.
>
> LGTM

Thanks @iklam and @yminqi for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6651

From ccheung at openjdk.java.net  Fri Dec  3 16:42:20 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 3 Dec 2021 16:42:20 GMT
Subject: Integrated: 8268288:
 jdk/jfr/api/consumer/streaming/TestOutOfProcessMigration.java fails with
 "Error: ShouldNotReachHere()"
In-Reply-To: <ZQDhdrk36fVLZlhP7RGhQvlxudfjy1YehtZRKfdDAiA=.3de6c554-ac14-4c25-92c7-c774af13d6fa@github.com>
References: <ZQDhdrk36fVLZlhP7RGhQvlxudfjy1YehtZRKfdDAiA=.3de6c554-ac14-4c25-92c7-c774af13d6fa@github.com>
Message-ID: <f9tNwKjwXxqTJdzhCnAo4WjukoDbdZfea5cUiqakvbo=.a9b30675-cec0-44ec-9946-34116f608dc1@github.com>

On Wed, 1 Dec 2021 19:16:11 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> A small fix to ensure that the globally shared ClassPathImageEntry is not being deleted in CDS code.
> The test failure is hard to reproduce. The proposed fix passed CI tiers 1-4 testing.
> Currently running the TestOutOfProcessMigration.java test repeatedly on linux-x64 with the vm options in the bug report.

This pull request has now been integrated.

Changeset: 0a090926
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0a0909263194032ae7d8348484e3638f84090233
Stats:     28 lines in 1 file changed: 11 ins; 11 del; 6 mod

8268288: jdk/jfr/api/consumer/streaming/TestOutOfProcessMigration.java fails with "Error: ShouldNotReachHere()"

Reviewed-by: minqi, iklam

-------------

PR: https://git.openjdk.java.net/jdk/pull/6651

From kvn at openjdk.java.net  Fri Dec  3 17:04:08 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 3 Dec 2021 17:04:08 GMT
Subject: RFR: JDK-8154011: Make TraceDeoptimization a diagnostic flag
In-Reply-To: <Ukrn4-xlVC_9jOUincD44R6jn27tccslziubVV8c4CU=.ecf0d4ba-73a4-4086-877c-d0ac5f03ab6d@github.com>
References: <Ukrn4-xlVC_9jOUincD44R6jn27tccslziubVV8c4CU=.ecf0d4ba-73a4-4086-877c-d0ac5f03ab6d@github.com>
Message-ID: <_VHs6xJHEd7pD-7jD0ZM0A5ZgipFCa8eZ5qym-iQsmw=.a09c8a28-8f79-4ffd-8a3d-2a7b293d9c6e@github.com>

On Fri, 3 Dec 2021 16:14:50 GMT, Tobias Holenstein <duke at openjdk.java.net> wrote:

> Make TraceDeoptimization available in a product build.
> 
> I checked that performance is not affected on Aurora.

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6703

From dcubed at openjdk.java.net  Fri Dec  3 17:26:33 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 3 Dec 2021 17:26:33 GMT
Subject: Integrated: 8278240: ProblemList containers/docker/TestJcmd.java on
 linux-aarch64
Message-ID: <emF9BBXcAfp1RAnJJbit07nASYT14aSiNzuPQNX_d1A=.a3a535db-0fae-48a2-baba-840801daa52f@github.com>

A trivial fix to ProblemList containers/docker/TestJcmd.java on linux-aarch64.

-------------

Commit messages:
 - 8278240: ProblemList containers/docker/TestJcmd.java on linux-aarch64

Changes: https://git.openjdk.java.net/jdk/pull/6705/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6705&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278240
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6705.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6705/head:pull/6705

PR: https://git.openjdk.java.net/jdk/pull/6705

From mseledtsov at openjdk.java.net  Fri Dec  3 17:26:33 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Fri, 3 Dec 2021 17:26:33 GMT
Subject: Integrated: 8278240: ProblemList containers/docker/TestJcmd.java
 on linux-aarch64
In-Reply-To: <emF9BBXcAfp1RAnJJbit07nASYT14aSiNzuPQNX_d1A=.a3a535db-0fae-48a2-baba-840801daa52f@github.com>
References: <emF9BBXcAfp1RAnJJbit07nASYT14aSiNzuPQNX_d1A=.a3a535db-0fae-48a2-baba-840801daa52f@github.com>
Message-ID: <6yMquTUJFYApZKkqOb2FrA0vLpyi5WVvmMeqUAPKWwI=.ede13868-816a-4a7f-95b3-9e3d4bfc3cad@github.com>

On Fri, 3 Dec 2021 17:10:02 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList containers/docker/TestJcmd.java on linux-aarch64.

Marked as reviewed by mseledtsov (Committer).

The change looks good to me, thank you.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6705

From tschatzl at openjdk.java.net  Fri Dec  3 17:26:33 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 3 Dec 2021 17:26:33 GMT
Subject: Integrated: 8278240: ProblemList containers/docker/TestJcmd.java
 on linux-aarch64
In-Reply-To: <emF9BBXcAfp1RAnJJbit07nASYT14aSiNzuPQNX_d1A=.a3a535db-0fae-48a2-baba-840801daa52f@github.com>
References: <emF9BBXcAfp1RAnJJbit07nASYT14aSiNzuPQNX_d1A=.a3a535db-0fae-48a2-baba-840801daa52f@github.com>
Message-ID: <3whQZdgxnFtwefKSWBlTsL30T0UZTrw1PZpPlcFsOWg=.a9b6128f-a81d-414c-a299-fb9ff1c82008@github.com>

On Fri, 3 Dec 2021 17:10:02 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList containers/docker/TestJcmd.java on linux-aarch64.

Marked as reviewed by tschatzl (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6705

From dcubed at openjdk.java.net  Fri Dec  3 17:26:33 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 3 Dec 2021 17:26:33 GMT
Subject: Integrated: 8278240: ProblemList containers/docker/TestJcmd.java
 on linux-aarch64
In-Reply-To: <6yMquTUJFYApZKkqOb2FrA0vLpyi5WVvmMeqUAPKWwI=.ede13868-816a-4a7f-95b3-9e3d4bfc3cad@github.com>
References: <emF9BBXcAfp1RAnJJbit07nASYT14aSiNzuPQNX_d1A=.a3a535db-0fae-48a2-baba-840801daa52f@github.com>
 <6yMquTUJFYApZKkqOb2FrA0vLpyi5WVvmMeqUAPKWwI=.ede13868-816a-4a7f-95b3-9e3d4bfc3cad@github.com>
Message-ID: <SM-Su5fwCznLT_gXjG4f5OYBFFwLmzPK0X9DnUfUzks=.1a589180-0f55-4ab2-9a0c-4f12fadd0d18@github.com>

On Fri, 3 Dec 2021 17:16:58 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

>> A trivial fix to ProblemList containers/docker/TestJcmd.java on linux-aarch64.
>
> The change looks good to me, thank you.

@mseledts and @tschatzl - Thanks for the lightning fast reviews!

-------------

PR: https://git.openjdk.java.net/jdk/pull/6705

From dcubed at openjdk.java.net  Fri Dec  3 17:26:34 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 3 Dec 2021 17:26:34 GMT
Subject: Integrated: 8278240: ProblemList containers/docker/TestJcmd.java on
 linux-aarch64
In-Reply-To: <emF9BBXcAfp1RAnJJbit07nASYT14aSiNzuPQNX_d1A=.a3a535db-0fae-48a2-baba-840801daa52f@github.com>
References: <emF9BBXcAfp1RAnJJbit07nASYT14aSiNzuPQNX_d1A=.a3a535db-0fae-48a2-baba-840801daa52f@github.com>
Message-ID: <3uC36Hkbds4EjTHm7g0oh54pYvlq2VMjg7R-79NNTK8=.93608a33-19ad-4b82-9224-15cb9b736ed6@github.com>

On Fri, 3 Dec 2021 17:10:02 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList containers/docker/TestJcmd.java on linux-aarch64.

This pull request has now been integrated.

Changeset: 678ac589
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/678ac589adeba0e9c2ae6d123f05ff20f02082c8
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8278240: ProblemList containers/docker/TestJcmd.java on linux-aarch64

Reviewed-by: mseledtsov, tschatzl

-------------

PR: https://git.openjdk.java.net/jdk/pull/6705

From duke at openjdk.java.net  Sat Dec  4 18:47:18 2021
From: duke at openjdk.java.net (duke)
Date: Sat, 4 Dec 2021 18:47:18 GMT
Subject: Withdrawn: 8271598: CDS classlist file should support uber JARs
In-Reply-To: <opq7VcOgSqCUpO1JKo5u9LpYRP5ihFFI8hWkT24lTqo=.946ce71f-98aa-4120-a210-f9f127f81e0f@github.com>
References: <opq7VcOgSqCUpO1JKo5u9LpYRP5ihFFI8hWkT24lTqo=.946ce71f-98aa-4120-a210-f9f127f81e0f@github.com>
Message-ID: <kYdparqwuanoUKLGJ3sXCZPm6K3o1IWWDL15AKflBiA=.e000661a-6787-4876-b836-7579527f49e6@github.com>

On Sat, 9 Oct 2021 00:15:43 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Currently, for archive classes for custom loaders, CDS supports the following source locations in the classlist:

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5876

From coleenp at openjdk.java.net  Sat Dec  4 18:53:17 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Sat, 4 Dec 2021 18:53:17 GMT
Subject: RFR: 8278125: Some preallocated OOMEs are missing stack trace [v2]
In-Reply-To: <AV2S-29XpWTCQh7mToBLRWh4bVMo_BygEMA44T_bXkc=.a38aa64b-0a70-4b63-b8d7-b646de83e936@github.com>
References: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
 <AV2S-29XpWTCQh7mToBLRWh4bVMo_BygEMA44T_bXkc=.a38aa64b-0a70-4b63-b8d7-b646de83e936@github.com>
Message-ID: <JI4SopPkSGJetYlJz7IYDcYU9vrumqm-MMx6m6QtqvI=.ed6b31c3-dca3-4e76-9829-505590a79a3a@github.com>

On Fri, 3 Dec 2021 05:51:48 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> Our customer found that the PreallocatedOutOfMemoryErrorCount is 4 by default. It ought to pre-allocate 4 OOMEs with stack trace, but in fact, no matter how many OOMEs are thrown, only 2 OOMEs have proper stack trace. This is because PreallocatedOutOfMemoryErrorCount is consumed multiple times:
>> 
>> VM tries to allocate a huge object while Java heap is insufficient to accommodate, it goes to:
>> 
>> https://github.com/openjdk/jdk/blob/b79554bb5cef14590d427543a40efbcc60c66548/src/hotspot/share/gc/shared/memAllocator.cpp#L115-L136
>> 
>> Line 135(`Universe::out_of_memory_error_java_heap`->`Universe::gen_out_of_memory_error`) and line 136(`THROW_OOP_`->`Exceptions::_throw`->`Exceptions::count_out_of_memory_exceptions`->`Universe::out_of_memory_error_java_heap`->`Universe::gen_out_of_memory_error`) call `Universe::gen_out_of_memory_error` twice in a single OOM event, which leads this unexpected scenario. Proposed fix is to remove such call in `Exceptions::count_out_of_memory_exceptions`.
>> 
>> Thanks.
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Universe::is_out_of_memory_xx

Changes requested by coleenp (Reviewer).

src/hotspot/share/memory/universe.cpp line 597:

> 595:   const char * msg_str = java_lang_String::as_utf8_string(msg_oop);
> 596:   return strcmp(msg, msg_str) == 0;
> 597: }

Yes, I agree with David about strcmp.  Could you add this instead (it was trying to compare the oops for equality, and unintentionally generated a new one).

oop Universe::is_out_of_memory_error_metaspace(oop exception) {
  return out_of_memory_errors()->obj_at(_oom_metaspace)) == exception;
}

src/hotspot/share/utilities/exceptions.cpp line 466:

> 464:   if (Universe::is_out_of_memory_error_metaspace(exception())) {
> 465:      Atomic::inc(&_out_of_memory_error_metaspace_errors, memory_order_relaxed);
> 466:   } else if (Universe::is_out_of_memory_error_class_metaspace(exception())) {

It was me.  I was confused by the function name and thought it just returned the oop.

test/hotspot/jtreg/runtime/ErrorHandling/GenOutOfMemoryError.java line 60:

> 58:         Asserts.assertTrue(4/*PreallocatedOutOfMemoryErrorCount is default to 4*/ == OOME_HAS_STACK_CNT, "Some OOMEs do not have stacktraces");
> 59:     }
> 60: }

missing newline apparently.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6672

From david.holmes at oracle.com  Sun Dec  5 12:00:16 2021
From: david.holmes at oracle.com (David Holmes)
Date: Sun, 5 Dec 2021 22:00:16 +1000
Subject: RFR: 8278125: Some preallocated OOMEs are missing stack trace [v2]
In-Reply-To: <JI4SopPkSGJetYlJz7IYDcYU9vrumqm-MMx6m6QtqvI=.ed6b31c3-dca3-4e76-9829-505590a79a3a@github.com>
References: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
 <AV2S-29XpWTCQh7mToBLRWh4bVMo_BygEMA44T_bXkc=.a38aa64b-0a70-4b63-b8d7-b646de83e936@github.com>
 <JI4SopPkSGJetYlJz7IYDcYU9vrumqm-MMx6m6QtqvI=.ed6b31c3-dca3-4e76-9829-505590a79a3a@github.com>
Message-ID: <a0907f25-0430-57f6-1684-96417ceac0ec@oracle.com>

On 5/12/2021 4:53 am, Coleen Phillimore wrote:
> On Fri, 3 Dec 2021 05:51:48 GMT, Yi Yang <yyang at openjdk.org> wrote:
> 
>>> Our customer found that the PreallocatedOutOfMemoryErrorCount is 4 by default. It ought to pre-allocate 4 OOMEs with stack trace, but in fact, no matter how many OOMEs are thrown, only 2 OOMEs have proper stack trace. This is because PreallocatedOutOfMemoryErrorCount is consumed multiple times:
>>>
>>> VM tries to allocate a huge object while Java heap is insufficient to accommodate, it goes to:
>>>
>>> https://github.com/openjdk/jdk/blob/b79554bb5cef14590d427543a40efbcc60c66548/src/hotspot/share/gc/shared/memAllocator.cpp#L115-L136
>>>
>>> Line 135(`Universe::out_of_memory_error_java_heap`->`Universe::gen_out_of_memory_error`) and line 136(`THROW_OOP_`->`Exceptions::_throw`->`Exceptions::count_out_of_memory_exceptions`->`Universe::out_of_memory_error_java_heap`->`Universe::gen_out_of_memory_error`) call `Universe::gen_out_of_memory_error` twice in a single OOM event, which leads this unexpected scenario. Proposed fix is to remove such call in `Exceptions::count_out_of_memory_exceptions`.
>>>
>>> Thanks.
>>
>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    Universe::is_out_of_memory_xx
> 
> Changes requested by coleenp (Reviewer).
> 
> src/hotspot/share/memory/universe.cpp line 597:
> 
>> 595:   const char * msg_str = java_lang_String::as_utf8_string(msg_oop);
>> 596:   return strcmp(msg, msg_str) == 0;
>> 597: }
> 
> Yes, I agree with David about strcmp.

I was only commenting on its placement, not its use.

> Could you add this instead (it was trying to compare the oops for equality, and unintentionally generated a new one).
> 
> oop Universe::is_out_of_memory_error_metaspace(oop exception) {
>    return out_of_memory_errors()->obj_at(_oom_metaspace)) == exception;
> }

This isn't correct. This will only match with the "default" exception 
object that gets created and which is only used after the pre-allocated 
exceptions (which can still have their stacktrace set) have been used 
up. So the count would be off by up to PreallocatedOutOfMemoryErrorCount.

David
-----

> src/hotspot/share/utilities/exceptions.cpp line 466:
> 
>> 464:   if (Universe::is_out_of_memory_error_metaspace(exception())) {
>> 465:      Atomic::inc(&_out_of_memory_error_metaspace_errors, memory_order_relaxed);
>> 466:   } else if (Universe::is_out_of_memory_error_class_metaspace(exception())) {
> 
> It was me.  I was confused by the function name and thought it just returned the oop.
> 
> test/hotspot/jtreg/runtime/ErrorHandling/GenOutOfMemoryError.java line 60:
> 
>> 58:         Asserts.assertTrue(4/*PreallocatedOutOfMemoryErrorCount is default to 4*/ == OOME_HAS_STACK_CNT, "Some OOMEs do not have stacktraces");
>> 59:     }
>> 60: }
> 
> missing newline apparently.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/6672
> 

From dholmes at openjdk.java.net  Sun Dec  5 12:08:15 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 5 Dec 2021 12:08:15 GMT
Subject: RFR: JDK-8154011: Make TraceDeoptimization a diagnostic flag
In-Reply-To: <Ukrn4-xlVC_9jOUincD44R6jn27tccslziubVV8c4CU=.ecf0d4ba-73a4-4086-877c-d0ac5f03ab6d@github.com>
References: <Ukrn4-xlVC_9jOUincD44R6jn27tccslziubVV8c4CU=.ecf0d4ba-73a4-4086-877c-d0ac5f03ab6d@github.com>
Message-ID: <rnPf78nPy2OOjXPWXnuI5S_qSd8GgOdwOQ-7xFUQIGY=.3390ce86-243d-4146-9412-88a039d70f63@github.com>

On Fri, 3 Dec 2021 16:14:50 GMT, Tobias Holenstein <duke at openjdk.java.net> wrote:

> Make TraceDeoptimization available in a product build.
> 
> I checked that performance is not affected on Aurora.

Change looks fine, though as I mention in JBS maybe this could be converted to unified logging?

Cheers,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6703

From yyang at openjdk.java.net  Mon Dec  6 06:08:10 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 6 Dec 2021 06:08:10 GMT
Subject: RFR: 8278125: Some preallocated OOMEs are missing stack trace
In-Reply-To: <a0907f25-0430-57f6-1684-96417ceac0ec@oracle.com>
References: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
 <a0907f25-0430-57f6-1684-96417ceac0ec@oracle.com>
Message-ID: <X4kO3cgun1EcGE97rOT7r-pAqTfwe9DoAGSV9uMl8D0=.22d3ac25-c64a-4aa1-99fd-e039ee70f72b@github.com>

On Sun, 5 Dec 2021 12:01:38 GMT, David Holmes <david.holmes at oracle.com> wrote:

> This isn't correct. This will only match with the "default" exception
> object that gets created and which is only used after the pre-allocated
> exceptions (which can still have their stacktrace set) have been used
> up. So the count would be off by up to PreallocatedOutOfMemoryErrorCount.

Yes, that's the reason why I try to identify these objects by checking their detail message string.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6672

From dholmes at openjdk.java.net  Mon Dec  6 07:03:16 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 6 Dec 2021 07:03:16 GMT
Subject: RFR: 8278125: Some preallocated OOMEs are missing stack trace [v2]
In-Reply-To: <JI4SopPkSGJetYlJz7IYDcYU9vrumqm-MMx6m6QtqvI=.ed6b31c3-dca3-4e76-9829-505590a79a3a@github.com>
References: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
 <AV2S-29XpWTCQh7mToBLRWh4bVMo_BygEMA44T_bXkc=.a38aa64b-0a70-4b63-b8d7-b646de83e936@github.com>
 <JI4SopPkSGJetYlJz7IYDcYU9vrumqm-MMx6m6QtqvI=.ed6b31c3-dca3-4e76-9829-505590a79a3a@github.com>
Message-ID: <Y60qENpD9K18xiDtHd0gqZmzzc3i_48z8opgpk9aggI=.4ba9eee7-369f-4641-b642-4e411c85e8e8@github.com>

On Sat, 4 Dec 2021 18:50:36 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Universe::is_out_of_memory_xx
>
> Changes requested by coleenp (Reviewer).

@coleenp  Also note that the detail message is obtained from those "default" instances, so they are guaranteed to be the same.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6672

From thartmann at openjdk.java.net  Mon Dec  6 07:59:10 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 6 Dec 2021 07:59:10 GMT
Subject: RFR: JDK-8154011: Make TraceDeoptimization a diagnostic flag
In-Reply-To: <Ukrn4-xlVC_9jOUincD44R6jn27tccslziubVV8c4CU=.ecf0d4ba-73a4-4086-877c-d0ac5f03ab6d@github.com>
References: <Ukrn4-xlVC_9jOUincD44R6jn27tccslziubVV8c4CU=.ecf0d4ba-73a4-4086-877c-d0ac5f03ab6d@github.com>
Message-ID: <TCKHRWPlV9i7UiIlTsUR1ggflO43kU92THD7DyTb-bM=.928a6603-7a4d-4e08-a5ea-e26bd5e769dc@github.com>

On Fri, 3 Dec 2021 16:14:50 GMT, Tobias Holenstein <duke at openjdk.java.net> wrote:

> Make TraceDeoptimization available in a product build.
> 
> I checked that performance is not affected on Aurora.

Looks good to me and as discussed in JIRA, this can't be easily converted to UL.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6703

From yyang at openjdk.java.net  Mon Dec  6 08:02:50 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 6 Dec 2021 08:02:50 GMT
Subject: RFR: 8278125: Some preallocated OOMEs are missing stack trace [v3]
In-Reply-To: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
References: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
Message-ID: <yoaT87337KQzVF-xRpopBnEIMf6YQNV9Ec1Gs4n2ewI=.55c29c27-27fd-4d77-b6d8-fd466be6ca9e@github.com>

> Our customer found that the PreallocatedOutOfMemoryErrorCount is 4 by default. It ought to pre-allocate 4 OOMEs with stack trace, but in fact, no matter how many OOMEs are thrown, only 2 OOMEs have proper stack trace. This is because PreallocatedOutOfMemoryErrorCount is consumed multiple times:
> 
> VM tries to allocate a huge object while Java heap is insufficient to accommodate, it goes to:
> 
> https://github.com/openjdk/jdk/blob/b79554bb5cef14590d427543a40efbcc60c66548/src/hotspot/share/gc/shared/memAllocator.cpp#L115-L136
> 
> Line 135(`Universe::out_of_memory_error_java_heap`->`Universe::gen_out_of_memory_error`) and line 136(`THROW_OOP_`->`Exceptions::_throw`->`Exceptions::count_out_of_memory_exceptions`->`Universe::out_of_memory_error_java_heap`->`Universe::gen_out_of_memory_error`) call `Universe::gen_out_of_memory_error` twice in a single OOM event, which leads this unexpected scenario. Proposed fix is to remove such call in `Exceptions::count_out_of_memory_exceptions`.
> 
> Thanks.

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  newline before eof

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6672/files
  - new: https://git.openjdk.java.net/jdk/pull/6672/files/b60d2d9f..9e4ff230

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6672&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6672&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6672.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6672/head:pull/6672

PR: https://git.openjdk.java.net/jdk/pull/6672

From yyang at openjdk.java.net  Mon Dec  6 08:02:53 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 6 Dec 2021 08:02:53 GMT
Subject: RFR: 8278125: Some preallocated OOMEs are missing stack trace [v2]
In-Reply-To: <JI4SopPkSGJetYlJz7IYDcYU9vrumqm-MMx6m6QtqvI=.ed6b31c3-dca3-4e76-9829-505590a79a3a@github.com>
References: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
 <AV2S-29XpWTCQh7mToBLRWh4bVMo_BygEMA44T_bXkc=.a38aa64b-0a70-4b63-b8d7-b646de83e936@github.com>
 <JI4SopPkSGJetYlJz7IYDcYU9vrumqm-MMx6m6QtqvI=.ed6b31c3-dca3-4e76-9829-505590a79a3a@github.com>
Message-ID: <YTK1a8z7eRwkhB0CsGbvE9TWucoyBDFXHtgrZ_jtl3Y=.eb959d39-9a2a-4550-b9bf-9edbb9cf5e9a@github.com>

On Sat, 4 Dec 2021 18:17:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Universe::is_out_of_memory_xx
>
> test/hotspot/jtreg/runtime/ErrorHandling/GenOutOfMemoryError.java line 60:
> 
>> 58:         Asserts.assertTrue(4/*PreallocatedOutOfMemoryErrorCount is default to 4*/ == OOME_HAS_STACK_CNT, "Some OOMEs do not have stacktraces");
>> 59:     }
>> 60: }
> 
> missing newline apparently.

Added

-------------

PR: https://git.openjdk.java.net/jdk/pull/6672

From duke at openjdk.java.net  Mon Dec  6 08:27:14 2021
From: duke at openjdk.java.net (Tobias Holenstein)
Date: Mon, 6 Dec 2021 08:27:14 GMT
Subject: Integrated: JDK-8154011: Make TraceDeoptimization a diagnostic flag
In-Reply-To: <Ukrn4-xlVC_9jOUincD44R6jn27tccslziubVV8c4CU=.ecf0d4ba-73a4-4086-877c-d0ac5f03ab6d@github.com>
References: <Ukrn4-xlVC_9jOUincD44R6jn27tccslziubVV8c4CU=.ecf0d4ba-73a4-4086-877c-d0ac5f03ab6d@github.com>
Message-ID: <zcuEG2dZPGtDQ5ASo9sZulU6a4FijaR6Y4pW9QGzEq4=.a618d060-3fda-4bfb-b680-41b8fe0da306@github.com>

On Fri, 3 Dec 2021 16:14:50 GMT, Tobias Holenstein <duke at openjdk.java.net> wrote:

> Make TraceDeoptimization available in a product build.
> 
> I checked that performance is not affected on Aurora.

This pull request has now been integrated.

Changeset: f39fe5b3
Author:    Tobias Holenstein <tobias.holenstein at oracle.com>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f39fe5b3d629c6d557eb7bab8d1ff81350c616cc
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8154011: Make TraceDeoptimization a diagnostic flag

Reviewed-by: kvn, dholmes, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/6703

From rkennke at openjdk.java.net  Mon Dec  6 12:14:15 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 6 Dec 2021 12:14:15 GMT
Subject: RFR: 8276901: Implement UseHeavyMonitors consistently [v11]
In-Reply-To: <3ij7xShJzxFD9U79iHoJPnHJzg6rPv7T1r67gIqEuD4=.3b964bd4-1374-4d14-a4b3-e209c5954093@github.com>
References: <CqBVDMLRhPl93f8gcv5VX0Un-fFF5BQtGEwrczIJdp4=.6a50ad8f-3bbe-4075-9f8c-ee4da37e9f8b@github.com>
 <3ij7xShJzxFD9U79iHoJPnHJzg6rPv7T1r67gIqEuD4=.3b964bd4-1374-4d14-a4b3-e209c5954093@github.com>
Message-ID: <MS_ojOtLjLtIaSwt9ptkEwHT4PmgtydeZvqCp4mIWqA=.0c5545b6-8b50-4886-92e5-48920a0daa13@github.com>

On Thu, 2 Dec 2021 14:41:53 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> The flag UseHeavyMonitors seems to imply that it makes Hotspot always use inflated monitors, rather than stack locks. However, it is only implemented in the interpreter that way. When it calls into runtime, it would still happily stack-lock. Even worse, C1 uses another flag UseFastLocking to achieve something similar (with the same caveat that runtime would stack-lock anyway). C2 doesn't have any such mechanism at all.
>> I would like to experiment with disabling stack-locking, and thus, having this flag work as expected would seem very useful.
>> 
>> The change removes the C1 flag UseFastLocking, and replaces its uses with equivalent (i.e. inverted) UseHeavyMonitors instead. I think it makes sense to make UseHeavyMonitors develop (I wouldn't want anybody to use this in production, not currently without this change, and not with this change). I also added a flag VerifyHeavyMonitors to be able to verify that stack-locking is really disabled. We can't currently verify this uncondiftionally (e.g. in debug builds) because all non-x86_64 platforms would need work.
>> 
>> Testing:
>>  - [x] tier1
>>  - [x] tier2
>>  - [x] tier3
>>  - [ ] tier4
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   PPC port by @TheRealMDoerr

Can I get more reviews for this PR before the JDK18 window closes? I suggest to not wait for arm or s390 ports for now. Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/6320

From mdoerr at openjdk.java.net  Mon Dec  6 13:37:12 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Mon, 6 Dec 2021 13:37:12 GMT
Subject: RFR: 8276901: Implement UseHeavyMonitors consistently [v11]
In-Reply-To: <3ij7xShJzxFD9U79iHoJPnHJzg6rPv7T1r67gIqEuD4=.3b964bd4-1374-4d14-a4b3-e209c5954093@github.com>
References: <CqBVDMLRhPl93f8gcv5VX0Un-fFF5BQtGEwrczIJdp4=.6a50ad8f-3bbe-4075-9f8c-ee4da37e9f8b@github.com>
 <3ij7xShJzxFD9U79iHoJPnHJzg6rPv7T1r67gIqEuD4=.3b964bd4-1374-4d14-a4b3-e209c5954093@github.com>
Message-ID: <FJt7xcI88CXZW3esPioduHxRo8QVj_bGvRfb8VdA9WY=.e586f9c7-9738-4777-bb68-ca7ce9bac69d@github.com>

On Thu, 2 Dec 2021 14:41:53 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> The flag UseHeavyMonitors seems to imply that it makes Hotspot always use inflated monitors, rather than stack locks. However, it is only implemented in the interpreter that way. When it calls into runtime, it would still happily stack-lock. Even worse, C1 uses another flag UseFastLocking to achieve something similar (with the same caveat that runtime would stack-lock anyway). C2 doesn't have any such mechanism at all.
>> I would like to experiment with disabling stack-locking, and thus, having this flag work as expected would seem very useful.
>> 
>> The change removes the C1 flag UseFastLocking, and replaces its uses with equivalent (i.e. inverted) UseHeavyMonitors instead. I think it makes sense to make UseHeavyMonitors develop (I wouldn't want anybody to use this in production, not currently without this change, and not with this change). I also added a flag VerifyHeavyMonitors to be able to verify that stack-locking is really disabled. We can't currently verify this uncondiftionally (e.g. in debug builds) because all non-x86_64 platforms would need work.
>> 
>> Testing:
>>  - [x] tier1
>>  - [x] tier2
>>  - [x] tier3
>>  - [ ] tier4
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   PPC port by @TheRealMDoerr

This version LGTM.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6320

From dcubed at openjdk.java.net  Mon Dec  6 16:51:13 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 6 Dec 2021 16:51:13 GMT
Subject: RFR: 8276901: Implement UseHeavyMonitors consistently [v11]
In-Reply-To: <3ij7xShJzxFD9U79iHoJPnHJzg6rPv7T1r67gIqEuD4=.3b964bd4-1374-4d14-a4b3-e209c5954093@github.com>
References: <CqBVDMLRhPl93f8gcv5VX0Un-fFF5BQtGEwrczIJdp4=.6a50ad8f-3bbe-4075-9f8c-ee4da37e9f8b@github.com>
 <3ij7xShJzxFD9U79iHoJPnHJzg6rPv7T1r67gIqEuD4=.3b964bd4-1374-4d14-a4b3-e209c5954093@github.com>
Message-ID: <4D7syupp5pCK0i_VGPAzbt8DFJOz1TOe2jn1Kjz6O0c=.0ed2ca51-0a95-45e9-a279-68952683ba2d@github.com>

On Thu, 2 Dec 2021 14:41:53 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> The flag UseHeavyMonitors seems to imply that it makes Hotspot always use inflated monitors, rather than stack locks. However, it is only implemented in the interpreter that way. When it calls into runtime, it would still happily stack-lock. Even worse, C1 uses another flag UseFastLocking to achieve something similar (with the same caveat that runtime would stack-lock anyway). C2 doesn't have any such mechanism at all.
>> I would like to experiment with disabling stack-locking, and thus, having this flag work as expected would seem very useful.
>> 
>> The change removes the C1 flag UseFastLocking, and replaces its uses with equivalent (i.e. inverted) UseHeavyMonitors instead. I think it makes sense to make UseHeavyMonitors develop (I wouldn't want anybody to use this in production, not currently without this change, and not with this change). I also added a flag VerifyHeavyMonitors to be able to verify that stack-locking is really disabled. We can't currently verify this uncondiftionally (e.g. in debug builds) because all non-x86_64 platforms would need work.
>> 
>> Testing:
>>  - [x] tier1
>>  - [x] tier2
>>  - [x] tier3
>>  - [ ] tier4
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   PPC port by @TheRealMDoerr

Thumbs up. I'm going to kick off some Mach5 testing for
this change or at least try to...

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6320

From rkennke at openjdk.java.net  Mon Dec  6 18:43:23 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 6 Dec 2021 18:43:23 GMT
Subject: RFR: 8276901: Implement UseHeavyMonitors consistently [v11]
In-Reply-To: <4D7syupp5pCK0i_VGPAzbt8DFJOz1TOe2jn1Kjz6O0c=.0ed2ca51-0a95-45e9-a279-68952683ba2d@github.com>
References: <CqBVDMLRhPl93f8gcv5VX0Un-fFF5BQtGEwrczIJdp4=.6a50ad8f-3bbe-4075-9f8c-ee4da37e9f8b@github.com>
 <3ij7xShJzxFD9U79iHoJPnHJzg6rPv7T1r67gIqEuD4=.3b964bd4-1374-4d14-a4b3-e209c5954093@github.com>
 <4D7syupp5pCK0i_VGPAzbt8DFJOz1TOe2jn1Kjz6O0c=.0ed2ca51-0a95-45e9-a279-68952683ba2d@github.com>
Message-ID: <WHnZmH6F-4s6n9GFbXCcdR2CX8L83Fn_mD3VntP1bMs=.bf6aaf2c-6be5-4e0f-994f-5913aa41306b@github.com>

On Mon, 6 Dec 2021 16:47:39 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Thumbs up. I'm going to kick off some Mach5 testing for this change or at least try to...

Alright, I will wait for it! Thanks for testing!

-------------

PR: https://git.openjdk.java.net/jdk/pull/6320

From dnsimon at openjdk.java.net  Mon Dec  6 21:03:17 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Mon, 6 Dec 2021 21:03:17 GMT
Subject: RFR: JDK-8154011: Make TraceDeoptimization a diagnostic flag
In-Reply-To: <Ukrn4-xlVC_9jOUincD44R6jn27tccslziubVV8c4CU=.ecf0d4ba-73a4-4086-877c-d0ac5f03ab6d@github.com>
References: <Ukrn4-xlVC_9jOUincD44R6jn27tccslziubVV8c4CU=.ecf0d4ba-73a4-4086-877c-d0ac5f03ab6d@github.com>
Message-ID: <wwXYRJG8J-dDVv82XVdO6ouE2EYqf0Fcbajv-EWBXi0=.ad4202cf-f6e7-4f80-bb95-9bce76cd12d9@github.com>

On Fri, 3 Dec 2021 16:14:50 GMT, Tobias Holenstein <duke at openjdk.java.net> wrote:

> Make TraceDeoptimization available in a product build.
> 
> I checked that performance is not affected on Aurora.

Sorry for only bringing it up now, but @tkrodriguez just observed that several of the places that test `TraceDeoptimization` aren't included in a `PRODUCT` build. In particular, [here](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/vframeArray.cpp#L443), [here](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/deoptimization.cpp#L265), and [here](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/deoptimization.cpp#L731). Without these bits of code included, the functionality of `TraceDeoptimzation` is somewhat compromised.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6703

From kvn at openjdk.java.net  Mon Dec  6 21:12:20 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 6 Dec 2021 21:12:20 GMT
Subject: RFR: JDK-8154011: Make TraceDeoptimization a diagnostic flag
In-Reply-To: <Ukrn4-xlVC_9jOUincD44R6jn27tccslziubVV8c4CU=.ecf0d4ba-73a4-4086-877c-d0ac5f03ab6d@github.com>
References: <Ukrn4-xlVC_9jOUincD44R6jn27tccslziubVV8c4CU=.ecf0d4ba-73a4-4086-877c-d0ac5f03ab6d@github.com>
Message-ID: <B9-rVOAckBukkeMpvlaPhKtq3duTWGLnkgA7kxmlyt8=.10b3f994-e62d-4657-864d-0e108f43ca13@github.com>

On Fri, 3 Dec 2021 16:14:50 GMT, Tobias Holenstein <duke at openjdk.java.net> wrote:

> Make TraceDeoptimization available in a product build.
> 
> I checked that performance is not affected on Aurora.

@tobiasholenstein please file follow up bug and fix places pointed by Doug.
Also make sure run testing to find and fix affected tests.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6703

From never at openjdk.java.net  Mon Dec  6 21:12:20 2021
From: never at openjdk.java.net (Tom Rodriguez)
Date: Mon, 6 Dec 2021 21:12:20 GMT
Subject: RFR: JDK-8154011: Make TraceDeoptimization a diagnostic flag
In-Reply-To: <Ukrn4-xlVC_9jOUincD44R6jn27tccslziubVV8c4CU=.ecf0d4ba-73a4-4086-877c-d0ac5f03ab6d@github.com>
References: <Ukrn4-xlVC_9jOUincD44R6jn27tccslziubVV8c4CU=.ecf0d4ba-73a4-4086-877c-d0ac5f03ab6d@github.com>
Message-ID: <We-UamYtukc7F2Y838Dgwbgshbo6KJRuFlZi68i_dmY=.4bcd6ee4-702d-4d52-902a-fd8e2162efa7@github.com>

On Fri, 3 Dec 2021 16:14:50 GMT, Tobias Holenstein <duke at openjdk.java.net> wrote:

> Make TraceDeoptimization available in a product build.
> 
> I checked that performance is not affected on Aurora.

Some of those might be benign, thought they are inconsistent.  The DEOPT PACKING messages are controlled by PrintDeoptimizationDetails, but DEOPT UNPACKING is controlled by TraceDeoptimization.  The REALLOC messages could likely be under PrintDeoptimizationDetails.  Maybe it would make sense to rationalize them a bit and make PrintDeoptimizationDetails diagnostic as well.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6703

From darcy at openjdk.java.net  Mon Dec  6 21:52:37 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 6 Dec 2021 21:52:37 GMT
Subject: RFR: JDK-8273146: Start of release updates for JDK 19 [v9]
In-Reply-To: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
References: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
Message-ID: <BEusjHE7fm_NEwQ_f8OXu9JsbamDJicDAIidVxJnHU8=.94cbc3cc-5e3e-447c-b86d-463e971bc506@github.com>

> The time to get JDK 19 underway draws nigh, please review this usual set of start-of-release updates, including CSRs for the javac and javax.lang.model updates:
> 
> JDK-8277512: Add SourceVersion.RELEASE_19
> https://bugs.openjdk.java.net/browse/JDK-8277512
> 
> JDK-8277514: Add source 19 and target 19 to javac
> https://bugs.openjdk.java.net/browse/JDK-8277514
> 
> Clean local tier 1 test runs for langtools, jdk, and hotspot.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Update symbol files to JDK 18 b26.
 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Update symbol information for JDK 18 b25.
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/ea8d3c92...9f68398a

-------------

Changes: https://git.openjdk.java.net/jdk/pull/6493/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6493&range=08
  Stats: 3870 lines in 67 files changed: 3827 ins; 4 del; 39 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6493.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6493/head:pull/6493

PR: https://git.openjdk.java.net/jdk/pull/6493

From minqi at openjdk.java.net  Tue Dec  7 02:01:32 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 7 Dec 2021 02:01:32 GMT
Subject: RFR: 8276769: -Xshare:auto should tolerate problems in the CDS archive
Message-ID: <ds7xSWBAJwciyfpI3juHlMDp_Otqzl5MXZOVvsRGZNM=.0c8199db-08a6-4a32-a3e1-c25342f1123e@github.com>

Hi, Please review

  -Xshare:auto, which is the default, is supposed to use the specified archive if possible, but otherwise the VM should continue normal execution and ignore the specified archive(s). But current code in some case will fail and exit. Fixed to allow vm continue without abnormal exit, fixed related tests and added new tests to check various scenarios.

  Tests: tier1-4

Thanks
Yumin

-------------

Commit messages:
 - 8276769: -Xshare:auto should tolerate problems in the CDS archive

Changes: https://git.openjdk.java.net/jdk/pull/6731/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6731&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276769
  Stats: 317 lines in 7 files changed: 182 ins; 58 del; 77 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6731.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6731/head:pull/6731

PR: https://git.openjdk.java.net/jdk/pull/6731

From xliu at openjdk.java.net  Tue Dec  7 02:59:41 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 7 Dec 2021 02:59:41 GMT
Subject: RFR: 8267517: async logging for stdout and stderr
Message-ID: <Nv1V5JHKgJh0NtqijGmWmI9Kh2VgDxgDIOAdfCtOavA=.503f41c2-a5d1-4a25-ab90-00252814a9bf@github.com>

This patch refactors LogFileStreamOutput so stdout/stderr can support support -Xlog:async.
LogFileStreamOutput::flush() is virtual. 

With  `-Xlog:all=trace:stdout`, the helloworld in Java outputs 16520 log entries to stdout.  We are see that the wall time reduces from  86.977ms to 72.436ms, or the throughput increases 20% because of async logging.


$perf stat -r 300 ./build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -Xlog:async -XX:AsyncLogBufferSize=48M HelloWorld > /dev/null

 Performance counter stats for './build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -Xlog:async -XX:AsyncLogBufferSize=48M HelloWorld' (300 runs):

            112.59 msec task-clock                #    1.554 CPUs utilized            ( +-  0.15% )
             1,517      context-switches          #    0.013 M/sec                    ( +-  0.61% )
                 1      cpu-migrations            #    0.010 K/sec                    ( +-  4.80% )
             4,014      page-faults               #    0.036 M/sec                    ( +-  0.01% )
...
          0.072436 +- 0.000135 seconds time elapsed  ( +-  0.19% )

 Performance counter stats for 'java -Xlog:all=trace:stdout  HelloWorld' (300 runs):

             90.73 msec task-clock                #    1.043 CPUs utilized            ( +-  0.11% )
               318      context-switches          #    0.004 M/sec                    ( +-  0.32% )
                 1      cpu-migrations            #    0.009 K/sec                    ( +-  4.80% )
             4,010      page-faults               #    0.044 M/sec                    ( +-  0.00% )
...
         0.0869777 +- 0.0000979 seconds time elapsed  ( +-  0.11% )


In this patch, we also fold two locks(RotationLocker and FileLock) of LogFileOutput into one. FileLocker now can protect _stream from multiplexing and log rotation.  The other change is that AsyncLog writing doesn't require any lock protection because it's single-threaded. 

Add a new jtreg to cover a scenario that the blocked stdout doesn't freeze the JVM application.

-------------

Commit messages:
 - Remove the unused semaphore in LogFileOutput.
 - Merge branch 'master' into JDK-8267517
 - Fixed the regression test.
 - Fix the deadlock issue on single core.
 - Update the jtreg test.
 - Merge branch 'master' into JDK-8267517
 - Add a jtreg test to demonstrate -Xlog:async can prevent JVM from blocking
 - _locking_thread_id should be a member data of LogFileStreamOutput.
 - Make FileLocker an inner class of LogFileStreamOutput.
 - make LogFileStreamOutput::flush() virtual.
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/ea8d3c92...45e15916

Changes: https://git.openjdk.java.net/jdk/pull/6132/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6132&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267517
  Stats: 416 lines in 9 files changed: 285 ins; 79 del; 52 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6132.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6132/head:pull/6132

PR: https://git.openjdk.java.net/jdk/pull/6132

From thomas.stuefe at gmail.com  Tue Dec  7 06:30:32 2021
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 7 Dec 2021 07:30:32 +0100
Subject: Why does OSThread exist?
Message-ID: <CAA-vtUwd2cx3n8CZ4pxusYMpqZ4xVSAMAguvwU7hU9C1iwq==w@mail.gmail.com>

Hi,

does anybody know what the point is of a separate OSThread companion class
to Thread? I understand that there is OS-specific information one wants to
factor out on a per-platform base, but why two physically separate
structures? AFAICS they never exist separately (an OSThread makes no sense
without a Thread, and vice versa). We pay unnecessarily for two
allocations, C-heap fragmentation, and for one additional dereferencing hop
when accessing OSThread.

Thanks, Thomas

From david.holmes at oracle.com  Tue Dec  7 09:25:32 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 7 Dec 2021 19:25:32 +1000
Subject: Why does OSThread exist?
In-Reply-To: <CAA-vtUwd2cx3n8CZ4pxusYMpqZ4xVSAMAguvwU7hU9C1iwq==w@mail.gmail.com>
References: <CAA-vtUwd2cx3n8CZ4pxusYMpqZ4xVSAMAguvwU7hU9C1iwq==w@mail.gmail.com>
Message-ID: <e43fdfc4-b215-bfc7-90e2-16733dc30fc8@oracle.com>

Hi Thomas,

On 7/12/2021 4:30 pm, Thomas St?fe wrote:
> Hi,
> 
> does anybody know what the point is of a separate OSThread companion class
> to Thread? I understand that there is OS-specific information one wants to
> factor out on a per-platform base, but why two physically separate
> structures? AFAICS they never exist separately (an OSThread makes no sense
> without a Thread, and vice versa). We pay unnecessarily for two
> allocations, C-heap fragmentation, and for one additional dereferencing hop
> when accessing OSThread.

Can say for sure as it is historical - it's just the way the OS specific 
part was factored out.

We had a project to try and get rid of it a few years ago but it wasn't 
a clean/simple as thought at the time and the project was dropped. But 
Solaris complicated things and now that's gone so ...

Cheers,
David

> Thanks, Thomas
> 

From duke at openjdk.java.net  Tue Dec  7 09:45:17 2021
From: duke at openjdk.java.net (Tobias Holenstein)
Date: Tue, 7 Dec 2021 09:45:17 GMT
Subject: RFR: JDK-8154011: Make TraceDeoptimization a diagnostic flag
In-Reply-To: <Ukrn4-xlVC_9jOUincD44R6jn27tccslziubVV8c4CU=.ecf0d4ba-73a4-4086-877c-d0ac5f03ab6d@github.com>
References: <Ukrn4-xlVC_9jOUincD44R6jn27tccslziubVV8c4CU=.ecf0d4ba-73a4-4086-877c-d0ac5f03ab6d@github.com>
Message-ID: <NZfyVStXb7m024cq1dDmdshIsa3bANvHSGi1_tQiaN0=.2e63e6b2-53aa-49b6-9814-7a6a1d9e6378@github.com>

On Fri, 3 Dec 2021 16:14:50 GMT, Tobias Holenstein <duke at openjdk.java.net> wrote:

> Make TraceDeoptimization available in a product build.
> 
> I checked that performance is not affected on Aurora.

Thanks for catching that! I filed a Bug on JIRA (JDK-8278329)

-------------

PR: https://git.openjdk.java.net/jdk/pull/6703

From gdub at openjdk.java.net  Tue Dec  7 11:16:17 2021
From: gdub at openjdk.java.net (Gilles Duboscq)
Date: Tue, 7 Dec 2021 11:16:17 GMT
Subject: RFR: JDK-8277029: JMM GetDiagnosticXXXInfo APIs should verify
 output array sizes [v2]
In-Reply-To: <7BKPwCXf1m9wKd5yOJaWg6ZyCCSvZwgZdOz7Z_tFf9U=.a506a1cf-524a-4e8a-a0fd-145766d3ef34@github.com>
References: <THfykOI9_zZq-f1l_FnpmW2_GVtVm6LCwPwHxmormv8=.1f3f36ed-0bc1-4e2e-8ccf-eae940b98f45@github.com>
 <7BKPwCXf1m9wKd5yOJaWg6ZyCCSvZwgZdOz7Z_tFf9U=.a506a1cf-524a-4e8a-a0fd-145766d3ef34@github.com>
Message-ID: <qjt1x5oCW5R2A-ZiVwSv71KNTZo_ypzq4uq0j7esxMI=.763df120-436a-4a89-93c9-c130608314c1@github.com>

On Tue, 16 Nov 2021 06:26:08 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> jmm_GetDiagnosticCommandArgumentsInfo and jmm_GetDiagnosticCommandInfo are used to query the hotspot about diagnostic commands. They provide output arrays for the information:
>> 
>> 
>> void jmm_GetDiagnosticCommandArgumentsInfo(JNIEnv *env,
>>           jstring command, dcmdArgInfo* infoArray)
>> 
>> 
>> but array size is implicitly assumed to be known to both caller and callee. Caller and callee negotiate those sizes in prior steps, but things can go wrong. E.g. I recently hunted a bug where `DCmd::number_arguments()` was off - did not reflect the real number of its jcmd parameters - which led to a hidden memory overwriter.
>> 
>> Thankfully, JDK-8264565 rewrote the dcmd framework to deal with this particular issue (The VM I analyzed was older). Still, it would be good if we had additional safety measures here.
>> 
>> -------------
>> 
>> Testing:
>> - manual tests with artificially induced error in one dcmd for debug, release
>> - GHAs (which include tier1 serviceability jcmd tests which use JMX and exercise these APIs)
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove changes to GetDiagnosticCommandInfo

Just out of curiosity, for such changes, should we in principle bump `JMM_VERSION`? Or do we not care because libjvm and libmanagement are always shipped together?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6363

From stuefe at openjdk.java.net  Tue Dec  7 13:11:13 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 7 Dec 2021 13:11:13 GMT
Subject: RFR: JDK-8277029: JMM GetDiagnosticXXXInfo APIs should verify
 output array sizes [v2]
In-Reply-To: <qjt1x5oCW5R2A-ZiVwSv71KNTZo_ypzq4uq0j7esxMI=.763df120-436a-4a89-93c9-c130608314c1@github.com>
References: <THfykOI9_zZq-f1l_FnpmW2_GVtVm6LCwPwHxmormv8=.1f3f36ed-0bc1-4e2e-8ccf-eae940b98f45@github.com>
 <7BKPwCXf1m9wKd5yOJaWg6ZyCCSvZwgZdOz7Z_tFf9U=.a506a1cf-524a-4e8a-a0fd-145766d3ef34@github.com>
 <qjt1x5oCW5R2A-ZiVwSv71KNTZo_ypzq4uq0j7esxMI=.763df120-436a-4a89-93c9-c130608314c1@github.com>
Message-ID: <MEqiuhiJSQ82g-TTz48xcp3ZbFf0mj8GhGVQ1ZWUsRM=.42037e57-6620-47a6-a886-6a41f4eee6f9@github.com>

On Tue, 7 Dec 2021 11:13:01 GMT, Gilles Duboscq <gdub at openjdk.org> wrote:

> Just out of curiosity, for such changes, should we in principle bump `JMM_VERSION`? Or do we not care because libjvm and libmanagement are always shipped together?

Hmm, maybe you are right, though someone from Oracle may answer that better. However, seeing that JMM is an internal interface between two internal components, I am not even sure why this version check is needed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6363

From stuefe at openjdk.java.net  Tue Dec  7 13:56:15 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 7 Dec 2021 13:56:15 GMT
Subject: RFR: JDK-8277383: VM.metaspace optionally show chunk freelist
 details [v2]
In-Reply-To: <MmB2_ByoKqMlIEfEFf8hDTW5SWXpo82j4F38MqgUq_A=.3cd5a682-7375-4823-9f95-2b992fdbf109@github.com>
References: <xaBHW3XUY_T_YESFLtLNNs9UPACVYMbv5igcO0Co8AQ=.3f81b9d5-ee87-4995-a78b-6910ee615124@github.com>
 <MmB2_ByoKqMlIEfEFf8hDTW5SWXpo82j4F38MqgUq_A=.3cd5a682-7375-4823-9f95-2b992fdbf109@github.com>
Message-ID: <0HX4cdmzAUUaXmS7DBu4TzGTV6EbK-xyG_HvE-3UiA4=.a24fd6c1-d2cb-4159-aa40-d68c864f1fda@github.com>

On Fri, 26 Nov 2021 14:41:47 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> A tiny patch to add an optional suboption to print out chunk freelist details with VM.metaspace; this is a followup from analyzing https://bugs.openjdk.java.net/browse/JDK-8277092.
>> 
>> -----
>> 
>> Tested: GHA, SAP nightlies, manual on x64, x86 Linux
>> Failing compiler test on x86-32 (compiler/c2/irTests/TestUnsignedComparison.java) unrelated, see JDK-8277324
>> "C2 compilation fails with "bad AD file" on x86-32 after JDK-8276162 due to missing match rule"
>> 
>> -----
>> 
>> Example use:
>> 
>> 
>> jcmd  HelloWorld VM.metaspace chunkfreelist
>> 
>>  ...
>>  
>> Chunk freelist details:
>>    Non-Class:
>> cm non-class-space: 7 chunks, total word size: 326144.
>> -- List[lv00]: empty
>> -- List[lv01]:  - <Chunk @0x00007f50d8122db0, state f, base 0x00007f5084600000, level lv01 (262144 words), used 0 words, committed 0 words.> - total : 1 chunks.
>> -- List[lv02]: empty
>> -- List[lv03]: empty
>> -- List[lv04]:  - <Chunk @0x00007f50d8122e88, state f, base 0x00007f5084540000, level lv04 (32768 words), used 0 words, committed 0 words.> - total : 1 chunks.
>> -- List[lv05]:  - <Chunk @0x00007f50d8122ed0, state f, base 0x00007f5084520000, level lv05 (16384 words), used 0 words, committed 0 words.> - total : 1 chunks.
>> -- List[lv06]:  - <Chunk @0x00007f50d8122f18, state f, base 0x00007f5084510000, level lv06 (8192 words), used 0 words, committed 0 words.> - total : 1 chunks.
>> -- List[lv07]:  - <Chunk @0x00007f50d8122f60, state f, base 0x00007f5084508000, level lv07 (4096 words), used 0 words, committed 0 words.> - total : 1 chunks.
>> -- List[lv08]:  - <Chunk @0x00007f50d8122fa8, state f, base 0x00007f5084504000, level lv08 (2048 words), used 0 words, committed 0 words.> - total : 1 chunks.
>> -- List[lv09]: empty
>> -- List[lv10]:  - <Chunk @0x00007f50d8123038, state f, base 0x00007f5084503000, level lv10 (512 words), used 0 words, committed 0 words.> - total : 1 chunks.
>> -- List[lv11]: empty
>> -- List[lv12]: empty
>> total chunks: 7, total word size: 326144.
>> 
>>        Class:
>> cm class-space: 6 chunks, total word size: 465920.
>> -- List[lv00]: empty
>> -- List[lv01]:  - <Chunk @0x00007f50d81229c0, state f, base 0x00000007c0200000, level lv01 (262144 words), used 0 words, committed 0 words.> - total : 1 chunks.
>> -- List[lv02]:  - <Chunk @0x00007f50d8122a08, state f, base 0x00000007c0100000, level lv02 (131072 words), used 0 words, committed 0 words.> - total : 1 chunks.
>> -- List[lv03]:  - <Chunk @0x00007f50d8122a50, state f, base 0x00000007c0080000, level lv03 (65536 words), used 0 words, committed 0 words.> - total : 1 chunks.
>> -- List[lv04]: empty
>> -- List[lv05]: empty
>> -- List[lv06]: empty
>> -- List[lv07]:  - <Chunk @0x00007f50d8122b70, state f, base 0x00000007c0008000, level lv07 (4096 words), used 0 words, committed 0 words.> - total : 1 chunks.
>> -- List[lv08]:  - <Chunk @0x00007f50d8122bb8, state f, base 0x00000007c0004000, level lv08 (2048 words), used 0 words, committed 0 words.> - total : 1 chunks.
>> -- List[lv09]:  - <Chunk @0x00007f50d8122c00, state f, base 0x00000007c0002000, level lv09 (1024 words), used 0 words, committed 0 words.> - total : 1 chunks.
>> -- List[lv10]: empty
>> -- List[lv11]: empty
>> -- List[lv12]: empty
>> total chunks: 6, total word size: 465920.
>
> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   JDK-8277383-VM-metaspace-optionally-show-chunk-freelist-details

Ping... may I have a quick second review, this change is really simple.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6452

From thomas.stuefe at gmail.com  Tue Dec  7 13:56:41 2021
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 7 Dec 2021 14:56:41 +0100
Subject: Why does OSThread exist?
In-Reply-To: <e43fdfc4-b215-bfc7-90e2-16733dc30fc8@oracle.com>
References: <CAA-vtUwd2cx3n8CZ4pxusYMpqZ4xVSAMAguvwU7hU9C1iwq==w@mail.gmail.com>
 <e43fdfc4-b215-bfc7-90e2-16733dc30fc8@oracle.com>
Message-ID: <CAA-vtUxkvu6yVZfr2mUZX8M7dAhu0RJKnfsqUvzh1eH9FCqLtA@mail.gmail.com>

Hi David,

On Tue, Dec 7, 2021 at 10:25 AM David Holmes <david.holmes at oracle.com>
wrote:

> Hi Thomas,
>
> On 7/12/2021 4:30 pm, Thomas St?fe wrote:
> > Hi,
> >
> > does anybody know what the point is of a separate OSThread companion
> class
> > to Thread? I understand that there is OS-specific information one wants
> to
> > factor out on a per-platform base, but why two physically separate
> > structures? AFAICS they never exist separately (an OSThread makes no
> sense
> > without a Thread, and vice versa). We pay unnecessarily for two
> > allocations, C-heap fragmentation, and for one additional dereferencing
> hop
> > when accessing OSThread.
>
> Can say for sure as it is historical - it's just the way the OS specific
> part was factored out.
>
> We had a project to try and get rid of it a few years ago but it wasn't
> a clean/simple as thought at the time and the project was dropped. But
> Solaris complicated things and now that's gone so ...
>
>
Thanks for the explanation. This tickles my cleanup sense and maybe I try
my hands on it, now Solaris is gone.

Cheers, Thomas



> Cheers,
> David
>
> > Thanks, Thomas
> >
>

From shade at openjdk.java.net  Tue Dec  7 14:12:15 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 7 Dec 2021 14:12:15 GMT
Subject: RFR: JDK-8277383: VM.metaspace optionally show chunk freelist
 details [v2]
In-Reply-To: <MmB2_ByoKqMlIEfEFf8hDTW5SWXpo82j4F38MqgUq_A=.3cd5a682-7375-4823-9f95-2b992fdbf109@github.com>
References: <xaBHW3XUY_T_YESFLtLNNs9UPACVYMbv5igcO0Co8AQ=.3f81b9d5-ee87-4995-a78b-6910ee615124@github.com>
 <MmB2_ByoKqMlIEfEFf8hDTW5SWXpo82j4F38MqgUq_A=.3cd5a682-7375-4823-9f95-2b992fdbf109@github.com>
Message-ID: <j2eigslbRjDTzGaV1VWjaFwvwNqmHSLCXVQ9cYB3L6E=.03b99b05-71c9-4e0f-b45b-52bc8e68f1f4@github.com>

On Fri, 26 Nov 2021 14:41:47 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> A tiny patch to add an optional suboption to print out chunk freelist details with VM.metaspace; this is a followup from analyzing https://bugs.openjdk.java.net/browse/JDK-8277092.
>> 
>> -----
>> 
>> Tested: GHA, SAP nightlies, manual on x64, x86 Linux
>> Failing compiler test on x86-32 (compiler/c2/irTests/TestUnsignedComparison.java) unrelated, see JDK-8277324
>> "C2 compilation fails with "bad AD file" on x86-32 after JDK-8276162 due to missing match rule"
>> 
>> -----
>> 
>> Example use:
>> 
>> 
>> jcmd  HelloWorld VM.metaspace chunkfreelist
>> 
>>  ...
>>  
>> Chunk freelist details:
>>    Non-Class:
>> cm non-class-space: 7 chunks, total word size: 326144.
>> -- List[lv00]: empty
>> -- List[lv01]:  - <Chunk @0x00007f50d8122db0, state f, base 0x00007f5084600000, level lv01 (262144 words), used 0 words, committed 0 words.> - total : 1 chunks.
>> -- List[lv02]: empty
>> -- List[lv03]: empty
>> -- List[lv04]:  - <Chunk @0x00007f50d8122e88, state f, base 0x00007f5084540000, level lv04 (32768 words), used 0 words, committed 0 words.> - total : 1 chunks.
>> -- List[lv05]:  - <Chunk @0x00007f50d8122ed0, state f, base 0x00007f5084520000, level lv05 (16384 words), used 0 words, committed 0 words.> - total : 1 chunks.
>> -- List[lv06]:  - <Chunk @0x00007f50d8122f18, state f, base 0x00007f5084510000, level lv06 (8192 words), used 0 words, committed 0 words.> - total : 1 chunks.
>> -- List[lv07]:  - <Chunk @0x00007f50d8122f60, state f, base 0x00007f5084508000, level lv07 (4096 words), used 0 words, committed 0 words.> - total : 1 chunks.
>> -- List[lv08]:  - <Chunk @0x00007f50d8122fa8, state f, base 0x00007f5084504000, level lv08 (2048 words), used 0 words, committed 0 words.> - total : 1 chunks.
>> -- List[lv09]: empty
>> -- List[lv10]:  - <Chunk @0x00007f50d8123038, state f, base 0x00007f5084503000, level lv10 (512 words), used 0 words, committed 0 words.> - total : 1 chunks.
>> -- List[lv11]: empty
>> -- List[lv12]: empty
>> total chunks: 7, total word size: 326144.
>> 
>>        Class:
>> cm class-space: 6 chunks, total word size: 465920.
>> -- List[lv00]: empty
>> -- List[lv01]:  - <Chunk @0x00007f50d81229c0, state f, base 0x00000007c0200000, level lv01 (262144 words), used 0 words, committed 0 words.> - total : 1 chunks.
>> -- List[lv02]:  - <Chunk @0x00007f50d8122a08, state f, base 0x00000007c0100000, level lv02 (131072 words), used 0 words, committed 0 words.> - total : 1 chunks.
>> -- List[lv03]:  - <Chunk @0x00007f50d8122a50, state f, base 0x00000007c0080000, level lv03 (65536 words), used 0 words, committed 0 words.> - total : 1 chunks.
>> -- List[lv04]: empty
>> -- List[lv05]: empty
>> -- List[lv06]: empty
>> -- List[lv07]:  - <Chunk @0x00007f50d8122b70, state f, base 0x00000007c0008000, level lv07 (4096 words), used 0 words, committed 0 words.> - total : 1 chunks.
>> -- List[lv08]:  - <Chunk @0x00007f50d8122bb8, state f, base 0x00000007c0004000, level lv08 (2048 words), used 0 words, committed 0 words.> - total : 1 chunks.
>> -- List[lv09]:  - <Chunk @0x00007f50d8122c00, state f, base 0x00000007c0002000, level lv09 (1024 words), used 0 words, committed 0 words.> - total : 1 chunks.
>> -- List[lv10]: empty
>> -- List[lv11]: empty
>> -- List[lv12]: empty
>> total chunks: 6, total word size: 465920.
>
> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   JDK-8277383-VM-metaspace-optionally-show-chunk-freelist-details

Looks fine.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6452

From coleen.phillimore at oracle.com  Tue Dec  7 14:13:05 2021
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Tue, 7 Dec 2021 09:13:05 -0500
Subject: Why does OSThread exist?
In-Reply-To: <CAA-vtUxkvu6yVZfr2mUZX8M7dAhu0RJKnfsqUvzh1eH9FCqLtA@mail.gmail.com>
References: <CAA-vtUwd2cx3n8CZ4pxusYMpqZ4xVSAMAguvwU7hU9C1iwq==w@mail.gmail.com>
 <e43fdfc4-b215-bfc7-90e2-16733dc30fc8@oracle.com>
 <CAA-vtUxkvu6yVZfr2mUZX8M7dAhu0RJKnfsqUvzh1eH9FCqLtA@mail.gmail.com>
Message-ID: <435756e5-297e-cb91-7f71-e3068bfb0c5a@oracle.com>


I've been unhappy with thread.hpp being catch-all for everything with 
nothing factored out.? Thread can still point to things but I'd hate to 
see more stuff go into thread.hpp/cpp.? Please don't go in this direction.

See also: https://bugs.openjdk.java.net/browse/JDK-8264145

thanks,
Coleen

On 12/7/21 8:56 AM, Thomas St?fe wrote:
> Hi David,
>
> On Tue, Dec 7, 2021 at 10:25 AM David Holmes <david.holmes at oracle.com>
> wrote:
>
>> Hi Thomas,
>>
>> On 7/12/2021 4:30 pm, Thomas St?fe wrote:
>>> Hi,
>>>
>>> does anybody know what the point is of a separate OSThread companion
>> class
>>> to Thread? I understand that there is OS-specific information one wants
>> to
>>> factor out on a per-platform base, but why two physically separate
>>> structures? AFAICS they never exist separately (an OSThread makes no
>> sense
>>> without a Thread, and vice versa). We pay unnecessarily for two
>>> allocations, C-heap fragmentation, and for one additional dereferencing
>> hop
>>> when accessing OSThread.
>> Can say for sure as it is historical - it's just the way the OS specific
>> part was factored out.
>>
>> We had a project to try and get rid of it a few years ago but it wasn't
>> a clean/simple as thought at the time and the project was dropped. But
>> Solaris complicated things and now that's gone so ...
>>
>>
> Thanks for the explanation. This tickles my cleanup sense and maybe I try
> my hands on it, now Solaris is gone.
>
> Cheers, Thomas
>
>
>
>> Cheers,
>> David
>>
>>> Thanks, Thomas
>>>


From stuefe at openjdk.java.net  Tue Dec  7 14:17:43 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 7 Dec 2021 14:17:43 GMT
Subject: RFR: JDK-8277822: Remove debug-only heap overrun checks in
 os::malloc and friends [v2]
In-Reply-To: <QB-uUEEjCyl1YGZ9iPScKbhViCyFQp_jiGth3fmSV-Q=.521cb003-455a-4256-b91e-838d52cb1a27@github.com>
References: <QB-uUEEjCyl1YGZ9iPScKbhViCyFQp_jiGth3fmSV-Q=.521cb003-455a-4256-b91e-838d52cb1a27@github.com>
Message-ID: <_8xnvs-FNkVwcvetXp7xhDhTuBbGNFeL_JKGKJYaGuI=.a15b6db5-6d79-4fe0-8baa-98879a45b0f7@github.com>

> After integrating C heap overrun checks into NMT (https://bugs.openjdk.java.net/browse/JDK-8275320), we can now remove debug-only guarding memory for os::malloc() and friends.
> 
> This will:
> - reduce complexity of `os::malloc`, `os::free`, `os::realloc` (especially that one since realloc is tricky)
> - saves *48 bytes per malloc* in debug builds. In my experiences this can sum up to a quite substantial overhead compared to release builds, especially since malloc allocations are often fine grained.
> - reduce behavioral differences between debug and release builds wrt memory layout and allocation paths.
> 
> Currently, we have always-on heap overrun checks in debug VMs. In order to preserve this feature after the patch, NMT is switched always on per default in debug builds (but can be switched off if needed, as opposed to the baked-in debug-only guards today).
> 
> We use NMT level summary here, which is very cheap since we don't track stacks, we just count some numbers in NMT categories. Memory overhead will still be a lot less than what we paid before with the quite generous debug-only guards.
> 
> Finally, this would also be a good coverage test for NMT.
> 
> For more information, please refer to the umbrella JBS (https://bugs.openjdk.java.net/browse/JDK-8275301).
> 
> -----------
> 
> Memory stomp reports are better now since NMT buffer overrun reporting (see JDK-8275320) is better. 
> 
> Before:
> 
> 
> [0.051s][warning][malloc,free] ## nof_mallocs = 11948, nof_frees = 2017
> [0.051s][warning][malloc,free] ## memory stomp:
> [0.051s][warning][malloc,free] GuardedMemory(0x00007fb3115ea560) base_addr=0x00007fb30c1df630 tag=0x0000000000000000 user_size=4096 user_data=0x00007fb30c1df650
> [0.051s][warning][malloc,free]   Header guard @0x00007fb30c1df630 is OK
> [0.051s][warning][malloc,free]   Trailer guard @0x00007fb30c1e0650 is BROKEN
> [0.051s][warning][malloc,free]   User data appears to be in use
> # To suppress the following error report, specify this argument
> 
> 
> Old reporting was susceptible to C-heap corruption: a sufficiently corrupted C-heap caused the libc to abort before reporting was completed:
> 
> 
> thomas at starfish:/shared/projects/openjdk/jdk-jdk/output-fastdebug$ ./images/jdk/bin/java -XX:+UseNewCode
> [0.047s][warning][malloc,free] ## nof_mallocs = 11948, nof_frees = 2017
> [0.047s][warning][malloc,free] ## memory stomp:
> java: malloc.c:2379: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed.
> Aborted (core dumped)
> 
> 
> The new reports, done by NMT, print out a hex dump of the corrupted area, before calling into libc. So this printout is something we always get, even if C-heap is corrupted beyond help:
> 
> 
> thomas at starfish:/shared/projects/openjdk/jdk-jdk/output-fastdebug$ ./images/jdk/bin/java -XX:+UseNewCode
> NMT Block at 0x00007f33c01a8e70, corruption at: 0x00007f33c01a9e80: 
> 0x00007f33c01a8df0:   00 00 00 00 00 00 00 00 75 00 00 00 00 00 00 00
> 0x00007f33c01a8e00:   50 00 00 00 00 00 00 00 00 00 00 00 01 00 9e e9
> 0x00007f33c01a8e10:   a8 b2 46 c6 33 7f 00 00 d0 7a 11 c0 33 7f 00 00
> 0x00007f33c01a8e20:   f0 4e 11 c0 33 7f 00 00 50 50 52 c6 33 7f 00 00
> 0x00007f33c01a8e30:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x00007f33c01a8e40:   00 00 00 00 00 00 00 00 a0 ae 52 c6 33 7f 00 00
> 0x00007f33c01a8e50:   ff b7 f7 c5 33 7f 00 00 00 00 00 00 00 00 00 00
> 0x00007f33c01a8e60:   e8 8e 00 00 00 00 00 00 25 10 00 00 00 00 00 00
> 0x00007f33c01a8e70:   00 10 00 00 00 00 00 00 00 00 00 00 0f 00 9e e9
> 0x00007f33c01a8e80:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x00007f33c01a8e90:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x00007f33c01a8ea0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x00007f33c01a8eb0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x00007f33c01a8ec0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x00007f33c01a8ed0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x00007f33c01a8ee0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> ...
> 0x00007f33c01a9e00:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x00007f33c01a9e10:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x00007f33c01a9e20:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x00007f33c01a9e30:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x00007f33c01a9e40:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x00007f33c01a9e50:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x00007f33c01a9e60:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x00007f33c01a9e70:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x00007f33c01a9e80:   00 00 00 00 00 00 00 00 81 01 00 00 00 00 00 00
> 0x00007f33c01a9e90:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x00007f33c01a9ea0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x00007f33c01a9eb0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x00007f33c01a9ec0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x00007f33c01a9ed0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x00007f33c01a9ee0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x00007f33c01a9ef0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> # To suppress the following error report, specify this argument
> 
> 
> At first glance it seems that "nof_mallocs" etc are missing from this output. This is true, I removed them. They are not needed since the hs-err file contains an NMT summary report, which has more and finer grained information than that.
> 
> -----------
> 
> 
> Tests: 
> - GHAs (the windows failures are related to 8241403: "JavaThread::get_thread_name() should be ThreadSMR-aware")
> - we tested this patch for several days in SAP nightlies
> - manual tests x64 and x86 Linux

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  initialize newly malloced memory

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6554/files
  - new: https://git.openjdk.java.net/jdk/pull/6554/files/a571f6de..0085c241

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6554&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6554&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6554.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6554/head:pull/6554

PR: https://git.openjdk.java.net/jdk/pull/6554

From stuefe at openjdk.java.net  Tue Dec  7 14:18:20 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 7 Dec 2021 14:18:20 GMT
Subject: RFR: JDK-8277383: VM.metaspace optionally show chunk freelist
 details [v2]
In-Reply-To: <j2eigslbRjDTzGaV1VWjaFwvwNqmHSLCXVQ9cYB3L6E=.03b99b05-71c9-4e0f-b45b-52bc8e68f1f4@github.com>
References: <xaBHW3XUY_T_YESFLtLNNs9UPACVYMbv5igcO0Co8AQ=.3f81b9d5-ee87-4995-a78b-6910ee615124@github.com>
 <MmB2_ByoKqMlIEfEFf8hDTW5SWXpo82j4F38MqgUq_A=.3cd5a682-7375-4823-9f95-2b992fdbf109@github.com>
 <j2eigslbRjDTzGaV1VWjaFwvwNqmHSLCXVQ9cYB3L6E=.03b99b05-71c9-4e0f-b45b-52bc8e68f1f4@github.com>
Message-ID: <urfc2aIx8LjUsyicRB2ExyjnF1pu1G9xLnxIreuFH28=.6d0442d9-73ba-4a56-a2d4-1f363aa1f2d9@github.com>

On Tue, 7 Dec 2021 14:09:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision:
>> 
>>   JDK-8277383-VM-metaspace-optionally-show-chunk-freelist-details
>
> Looks fine.

Thank you  @shipilev .

-------------

PR: https://git.openjdk.java.net/jdk/pull/6452

From stuefe at openjdk.java.net  Tue Dec  7 14:18:21 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 7 Dec 2021 14:18:21 GMT
Subject: Integrated: JDK-8277383: VM.metaspace optionally show chunk freelist
 details
In-Reply-To: <xaBHW3XUY_T_YESFLtLNNs9UPACVYMbv5igcO0Co8AQ=.3f81b9d5-ee87-4995-a78b-6910ee615124@github.com>
References: <xaBHW3XUY_T_YESFLtLNNs9UPACVYMbv5igcO0Co8AQ=.3f81b9d5-ee87-4995-a78b-6910ee615124@github.com>
Message-ID: <fHb2Vd0rIiYqzSIRDGlbQf0GZ64bepd-mppDCX16U5w=.3036af40-8fa3-4459-8d27-f1b3f46522db@github.com>

On Thu, 18 Nov 2021 11:32:51 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> A tiny patch to add an optional suboption to print out chunk freelist details with VM.metaspace; this is a followup from analyzing https://bugs.openjdk.java.net/browse/JDK-8277092.
> 
> -----
> 
> Tested: GHA, SAP nightlies, manual on x64, x86 Linux
> Failing compiler test on x86-32 (compiler/c2/irTests/TestUnsignedComparison.java) unrelated, see JDK-8277324
> "C2 compilation fails with "bad AD file" on x86-32 after JDK-8276162 due to missing match rule"
> 
> -----
> 
> Example use:
> 
> 
> jcmd  HelloWorld VM.metaspace chunkfreelist
> 
>  ...
>  
> Chunk freelist details:
>    Non-Class:
> cm non-class-space: 7 chunks, total word size: 326144.
> -- List[lv00]: empty
> -- List[lv01]:  - <Chunk @0x00007f50d8122db0, state f, base 0x00007f5084600000, level lv01 (262144 words), used 0 words, committed 0 words.> - total : 1 chunks.
> -- List[lv02]: empty
> -- List[lv03]: empty
> -- List[lv04]:  - <Chunk @0x00007f50d8122e88, state f, base 0x00007f5084540000, level lv04 (32768 words), used 0 words, committed 0 words.> - total : 1 chunks.
> -- List[lv05]:  - <Chunk @0x00007f50d8122ed0, state f, base 0x00007f5084520000, level lv05 (16384 words), used 0 words, committed 0 words.> - total : 1 chunks.
> -- List[lv06]:  - <Chunk @0x00007f50d8122f18, state f, base 0x00007f5084510000, level lv06 (8192 words), used 0 words, committed 0 words.> - total : 1 chunks.
> -- List[lv07]:  - <Chunk @0x00007f50d8122f60, state f, base 0x00007f5084508000, level lv07 (4096 words), used 0 words, committed 0 words.> - total : 1 chunks.
> -- List[lv08]:  - <Chunk @0x00007f50d8122fa8, state f, base 0x00007f5084504000, level lv08 (2048 words), used 0 words, committed 0 words.> - total : 1 chunks.
> -- List[lv09]: empty
> -- List[lv10]:  - <Chunk @0x00007f50d8123038, state f, base 0x00007f5084503000, level lv10 (512 words), used 0 words, committed 0 words.> - total : 1 chunks.
> -- List[lv11]: empty
> -- List[lv12]: empty
> total chunks: 7, total word size: 326144.
> 
>        Class:
> cm class-space: 6 chunks, total word size: 465920.
> -- List[lv00]: empty
> -- List[lv01]:  - <Chunk @0x00007f50d81229c0, state f, base 0x00000007c0200000, level lv01 (262144 words), used 0 words, committed 0 words.> - total : 1 chunks.
> -- List[lv02]:  - <Chunk @0x00007f50d8122a08, state f, base 0x00000007c0100000, level lv02 (131072 words), used 0 words, committed 0 words.> - total : 1 chunks.
> -- List[lv03]:  - <Chunk @0x00007f50d8122a50, state f, base 0x00000007c0080000, level lv03 (65536 words), used 0 words, committed 0 words.> - total : 1 chunks.
> -- List[lv04]: empty
> -- List[lv05]: empty
> -- List[lv06]: empty
> -- List[lv07]:  - <Chunk @0x00007f50d8122b70, state f, base 0x00000007c0008000, level lv07 (4096 words), used 0 words, committed 0 words.> - total : 1 chunks.
> -- List[lv08]:  - <Chunk @0x00007f50d8122bb8, state f, base 0x00000007c0004000, level lv08 (2048 words), used 0 words, committed 0 words.> - total : 1 chunks.
> -- List[lv09]:  - <Chunk @0x00007f50d8122c00, state f, base 0x00000007c0002000, level lv09 (1024 words), used 0 words, committed 0 words.> - total : 1 chunks.
> -- List[lv10]: empty
> -- List[lv11]: empty
> -- List[lv12]: empty
> total chunks: 6, total word size: 465920.

This pull request has now been integrated.

Changeset: 35361270
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/35361270cb3aae9fa560736f8d05f1b258704c87
Stats:     48 lines in 5 files changed: 47 ins; 0 del; 1 mod

8277383: VM.metaspace optionally show chunk freelist details

Reviewed-by: coleenp, shade

-------------

PR: https://git.openjdk.java.net/jdk/pull/6452

From dcubed at openjdk.java.net  Tue Dec  7 14:40:25 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 7 Dec 2021 14:40:25 GMT
Subject: RFR: 8276901: Implement UseHeavyMonitors consistently [v11]
In-Reply-To: <3ij7xShJzxFD9U79iHoJPnHJzg6rPv7T1r67gIqEuD4=.3b964bd4-1374-4d14-a4b3-e209c5954093@github.com>
References: <CqBVDMLRhPl93f8gcv5VX0Un-fFF5BQtGEwrczIJdp4=.6a50ad8f-3bbe-4075-9f8c-ee4da37e9f8b@github.com>
 <3ij7xShJzxFD9U79iHoJPnHJzg6rPv7T1r67gIqEuD4=.3b964bd4-1374-4d14-a4b3-e209c5954093@github.com>
Message-ID: <A6J_n5kJKwEWrraZv_00ygcXaJOUqC8uKAmooAlr6bg=.440ed584-e386-48c3-8e33-0731831f4c64@github.com>

On Thu, 2 Dec 2021 14:41:53 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> The flag UseHeavyMonitors seems to imply that it makes Hotspot always use inflated monitors, rather than stack locks. However, it is only implemented in the interpreter that way. When it calls into runtime, it would still happily stack-lock. Even worse, C1 uses another flag UseFastLocking to achieve something similar (with the same caveat that runtime would stack-lock anyway). C2 doesn't have any such mechanism at all.
>> I would like to experiment with disabling stack-locking, and thus, having this flag work as expected would seem very useful.
>> 
>> The change removes the C1 flag UseFastLocking, and replaces its uses with equivalent (i.e. inverted) UseHeavyMonitors instead. I think it makes sense to make UseHeavyMonitors develop (I wouldn't want anybody to use this in production, not currently without this change, and not with this change). I also added a flag VerifyHeavyMonitors to be able to verify that stack-locking is really disabled. We can't currently verify this uncondiftionally (e.g. in debug builds) because all non-x86_64 platforms would need work.
>> 
>> Testing:
>>  - [x] tier1
>>  - [x] tier2
>>  - [x] tier3
>>  - [ ] tier4
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   PPC port by @TheRealMDoerr

Mach5 Tier1:
- dcubed-8276901_for_jdk18.git-20211206-1656-26967213
- no test failures

Mach5 Tier2:
- dcubed-8276901_for_jdk18.git-20211206-2009-26973681
- 2 known, unrelated test failures

Mach5 Tier3:
- dcubed-8276901_for_jdk18.git-20211206-2009-26973700
- no failures

Mach5 Tier4:
- dcubed-8276901_for_jdk18.git-20211206-2124-26976450
- 11 known, unrelated test failures

Mach5 Tier5:
- dcubed-8276901_for_jdk18.git-20211206-2125-26976484
- 3 known, unrelated failures
- still running macosx-x64 tasks

Mach5 Tier6:
- dcubed-8276901_for_jdk18.git-20211206-2220-26978292
- still running

Mach5 Tier7:
- dcubed-8276901_for_jdk18.git-20211207-0044-26982843
- 2 known, unrelated failures
- still running macosx-x64 tasks

Mach5 Tier8:
- dcubed-8276901_for_jdk18.git-20211207-0045-26982871
- still running 24 hour tasks and macosx-x64 tasks

So Tier[1-4] are complete and look fine. Mach5 is a bit over loaded at the
moment so Tier[5-8] are still running. I think the Tier[1-4] results and the
partial Tier[5-8] are good enough to say that these bits are okay.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6320

From rkennke at openjdk.java.net  Tue Dec  7 14:40:25 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 7 Dec 2021 14:40:25 GMT
Subject: RFR: 8276901: Implement UseHeavyMonitors consistently [v11]
In-Reply-To: <A6J_n5kJKwEWrraZv_00ygcXaJOUqC8uKAmooAlr6bg=.440ed584-e386-48c3-8e33-0731831f4c64@github.com>
References: <CqBVDMLRhPl93f8gcv5VX0Un-fFF5BQtGEwrczIJdp4=.6a50ad8f-3bbe-4075-9f8c-ee4da37e9f8b@github.com>
 <3ij7xShJzxFD9U79iHoJPnHJzg6rPv7T1r67gIqEuD4=.3b964bd4-1374-4d14-a4b3-e209c5954093@github.com>
 <A6J_n5kJKwEWrraZv_00ygcXaJOUqC8uKAmooAlr6bg=.440ed584-e386-48c3-8e33-0731831f4c64@github.com>
Message-ID: <uAsWBHXfrk349Nkr5w8cuDqXO_-dXWIQ3gLWxedrN0I=.2595b2ca-dc86-496f-b4d0-4590c575de2d@github.com>

On Tue, 7 Dec 2021 14:34:48 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> So Tier[1-4] are complete and look fine. Mach5 is a bit over loaded at the moment so Tier[5-8] are still running. I think the Tier[1-4] results and the partial Tier[5-8] are good enough to say that these bits are okay.

Thanks, David! I will then go ahead and integrate this PR.

Cheers,
Roman

-------------

PR: https://git.openjdk.java.net/jdk/pull/6320

From thomas.stuefe at gmail.com  Tue Dec  7 14:42:06 2021
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 7 Dec 2021 15:42:06 +0100
Subject: Why does OSThread exist?
In-Reply-To: <435756e5-297e-cb91-7f71-e3068bfb0c5a@oracle.com>
References: <CAA-vtUwd2cx3n8CZ4pxusYMpqZ4xVSAMAguvwU7hU9C1iwq==w@mail.gmail.com>
 <e43fdfc4-b215-bfc7-90e2-16733dc30fc8@oracle.com>
 <CAA-vtUxkvu6yVZfr2mUZX8M7dAhu0RJKnfsqUvzh1eH9FCqLtA@mail.gmail.com>
 <435756e5-297e-cb91-7f71-e3068bfb0c5a@oracle.com>
Message-ID: <CAA-vtUy-dkSC+mWCzGH=_M-auAgU4-tR9qJ==bcDOEfOHQvVsw@mail.gmail.com>

Hi Coleen,

I agree that Thread is a monster. Cleanup would be nice. But what is your
concern, footprint of this structure, or code complexity?

Footprint-wise, OSThread contains information that is vital for any thread
(thread state, thread id etc). You always need those, so you always need to
store them. By keeping them in a physically separated structure we don't
gain anything. We still pay for the storage. We pay more, actually, since
there is the per-structure overhead incurred by the libc. Also, runtime
overhead for mallocs. And runtime overhead for the unnecessary indirection
when accessing the thread id or thread state, both of which are at least
warm.

If it is about code complexity, and separation of concerns, I think it
makes sense to factor some things out of Thread. E.g. by composition or
inheritance. But IMHO moving things physically out of Thread only makes
sense if the parts you move out are optional and not always needed.

Also, this may be just me but it seems weird to have Thread/JavaThread
chock-full of all kinds of members but have the thread id of all things
factored out into a companion structure.

Cheers, Thomas



On Tue, Dec 7, 2021 at 3:13 PM <coleen.phillimore at oracle.com> wrote:

>
> I've been unhappy with thread.hpp being catch-all for everything with
> nothing factored out.  Thread can still point to things but I'd hate to
> see more stuff go into thread.hpp/cpp.  Please don't go in this direction.
>
> See also: https://bugs.openjdk.java.net/browse/JDK-8264145
>
> thanks,
> Coleen
>
> On 12/7/21 8:56 AM, Thomas St?fe wrote:
> > Hi David,
> >
> > On Tue, Dec 7, 2021 at 10:25 AM David Holmes <david.holmes at oracle.com>
> > wrote:
> >
> >> Hi Thomas,
> >>
> >> On 7/12/2021 4:30 pm, Thomas St?fe wrote:
> >>> Hi,
> >>>
> >>> does anybody know what the point is of a separate OSThread companion
> >> class
> >>> to Thread? I understand that there is OS-specific information one wants
> >> to
> >>> factor out on a per-platform base, but why two physically separate
> >>> structures? AFAICS they never exist separately (an OSThread makes no
> >> sense
> >>> without a Thread, and vice versa). We pay unnecessarily for two
> >>> allocations, C-heap fragmentation, and for one additional dereferencing
> >> hop
> >>> when accessing OSThread.
> >> Can say for sure as it is historical - it's just the way the OS specific
> >> part was factored out.
> >>
> >> We had a project to try and get rid of it a few years ago but it wasn't
> >> a clean/simple as thought at the time and the project was dropped. But
> >> Solaris complicated things and now that's gone so ...
> >>
> >>
> > Thanks for the explanation. This tickles my cleanup sense and maybe I try
> > my hands on it, now Solaris is gone.
> >
> > Cheers, Thomas
> >
> >
> >
> >> Cheers,
> >> David
> >>
> >>> Thanks, Thomas
> >>>
>
>

From rkennke at openjdk.java.net  Tue Dec  7 14:45:20 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 7 Dec 2021 14:45:20 GMT
Subject: Integrated: 8276901: Implement UseHeavyMonitors consistently
In-Reply-To: <CqBVDMLRhPl93f8gcv5VX0Un-fFF5BQtGEwrczIJdp4=.6a50ad8f-3bbe-4075-9f8c-ee4da37e9f8b@github.com>
References: <CqBVDMLRhPl93f8gcv5VX0Un-fFF5BQtGEwrczIJdp4=.6a50ad8f-3bbe-4075-9f8c-ee4da37e9f8b@github.com>
Message-ID: <kSIm1yvUfhYRSoK_aN6uqhRtqpi83xyjWcRzx6e9-s0=.f9871b0f-4a26-4f71-9131-297504c0b828@github.com>

On Tue, 9 Nov 2021 21:54:58 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> The flag UseHeavyMonitors seems to imply that it makes Hotspot always use inflated monitors, rather than stack locks. However, it is only implemented in the interpreter that way. When it calls into runtime, it would still happily stack-lock. Even worse, C1 uses another flag UseFastLocking to achieve something similar (with the same caveat that runtime would stack-lock anyway). C2 doesn't have any such mechanism at all.
> I would like to experiment with disabling stack-locking, and thus, having this flag work as expected would seem very useful.
> 
> The change removes the C1 flag UseFastLocking, and replaces its uses with equivalent (i.e. inverted) UseHeavyMonitors instead. I think it makes sense to make UseHeavyMonitors develop (I wouldn't want anybody to use this in production, not currently without this change, and not with this change). I also added a flag VerifyHeavyMonitors to be able to verify that stack-locking is really disabled. We can't currently verify this uncondiftionally (e.g. in debug builds) because all non-x86_64 platforms would need work.
> 
> Testing:
>  - [x] tier1
>  - [x] tier2
>  - [x] tier3
>  - [ ] tier4

This pull request has now been integrated.

Changeset: 5b81d5ee
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5b81d5eeb4124ff04dc3b9a96d0b53edcfa07c5f
Stats:     462 lines in 19 files changed: 144 ins; 20 del; 298 mod

8276901: Implement UseHeavyMonitors consistently

Reviewed-by: coleenp, mdoerr, dcubed

-------------

PR: https://git.openjdk.java.net/jdk/pull/6320

From coleen.phillimore at oracle.com  Tue Dec  7 14:55:57 2021
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Tue, 7 Dec 2021 09:55:57 -0500
Subject: [External] : Re: Why does OSThread exist?
In-Reply-To: <CAA-vtUy-dkSC+mWCzGH=_M-auAgU4-tR9qJ==bcDOEfOHQvVsw@mail.gmail.com>
References: <CAA-vtUwd2cx3n8CZ4pxusYMpqZ4xVSAMAguvwU7hU9C1iwq==w@mail.gmail.com>
 <e43fdfc4-b215-bfc7-90e2-16733dc30fc8@oracle.com>
 <CAA-vtUxkvu6yVZfr2mUZX8M7dAhu0RJKnfsqUvzh1eH9FCqLtA@mail.gmail.com>
 <435756e5-297e-cb91-7f71-e3068bfb0c5a@oracle.com>
 <CAA-vtUy-dkSC+mWCzGH=_M-auAgU4-tR9qJ==bcDOEfOHQvVsw@mail.gmail.com>
Message-ID: <76068243-db8e-1672-232d-dcc4065b4ea0@oracle.com>



On 12/7/21 9:42 AM, Thomas St?fe wrote:
> Hi Coleen,
>
> I agree that Thread is a monster. Cleanup would be nice. But what is 
> your concern, footprint of this structure, or code complexity?
Mostly code complexity and modularity.? Which is why I factored out the 
stack overflow code. If we can save some alignment gaps, that'd be good too.
>
> Footprint-wise, OSThread contains information that is vital for any 
> thread (thread state, thread id etc). You always need those, so you 
> always need to store them. By keeping them in a physically separated 
> structure we don't gain anything. We still pay for the storage. We pay 
> more, actually, since there is the per-structure overhead incurred by 
> the libc. Also, runtime overhead for mallocs. And runtime overhead for 
> the unnecessary indirection when accessing the thread id or thread 
> state, both of which are at least warm.

Unnecessary indirection is bad but indirection for locality is okay 
(imo).? But I agree this indirection for osthread might not make sense.

>
> If it is?about code complexity, and separation of concerns, I think it 
> makes sense to factor some things out of Thread. E.g. by composition 
> or inheritance. But IMHO moving things physically out of Thread only 
> makes sense if the parts you move out are optional and not always needed.

I agree and I agree that osthread structure might be best factored 
directly in Thread.

My biggest thing I don't like is that in gdb print *thread is gives me a 
whole page of things that I don't care about to parse with my eyes, even 
with statics turned off.

What you're suggesting makes sense and I'll be glad to see it.

Coleen
>
> Also, this may be just me but it seems weird to have Thread/JavaThread 
> chock-full of all kinds of members but have the thread id of all 
> things factored out into a companion structure.
>
> Cheers, Thomas
>
>
>
> On Tue, Dec 7, 2021 at 3:13 PM <coleen.phillimore at oracle.com> wrote:
>
>
>     I've been unhappy with thread.hpp being catch-all for everything with
>     nothing factored out.? Thread can still point to things but I'd
>     hate to
>     see more stuff go into thread.hpp/cpp.? Please don't go in this
>     direction.
>
>     See also: https://bugs.openjdk.java.net/browse/JDK-8264145
>
>     thanks,
>     Coleen
>
>     On 12/7/21 8:56 AM, Thomas St?fe wrote:
>     > Hi David,
>     >
>     > On Tue, Dec 7, 2021 at 10:25 AM David Holmes
>     <david.holmes at oracle.com>
>     > wrote:
>     >
>     >> Hi Thomas,
>     >>
>     >> On 7/12/2021 4:30 pm, Thomas St?fe wrote:
>     >>> Hi,
>     >>>
>     >>> does anybody know what the point is of a separate OSThread
>     companion
>     >> class
>     >>> to Thread? I understand that there is OS-specific information
>     one wants
>     >> to
>     >>> factor out on a per-platform base, but why two physically separate
>     >>> structures? AFAICS they never exist separately (an OSThread
>     makes no
>     >> sense
>     >>> without a Thread, and vice versa). We pay unnecessarily for two
>     >>> allocations, C-heap fragmentation, and for one additional
>     dereferencing
>     >> hop
>     >>> when accessing OSThread.
>     >> Can say for sure as it is historical - it's just the way the OS
>     specific
>     >> part was factored out.
>     >>
>     >> We had a project to try and get rid of it a few years ago but
>     it wasn't
>     >> a clean/simple as thought at the time and the project was
>     dropped. But
>     >> Solaris complicated things and now that's gone so ...
>     >>
>     >>
>     > Thanks for the explanation. This tickles my cleanup sense and
>     maybe I try
>     > my hands on it, now Solaris is gone.
>     >
>     > Cheers, Thomas
>     >
>     >
>     >
>     >> Cheers,
>     >> David
>     >>
>     >>> Thanks, Thomas
>     >>>
>

From darcy at openjdk.java.net  Thu Dec  9 17:07:18 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 9 Dec 2021 17:07:18 GMT
Subject: Integrated: JDK-8273146: Start of release updates for JDK 19
In-Reply-To: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
References: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
Message-ID: <qJE3l7bbGSefMtF1mI5-Sd-2nDoul8oEzCgvQr4LMis=.1f8167ad-2d8f-4c84-b3a1-afa5493430e1@github.com>

On Mon, 22 Nov 2021 03:15:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The time to get JDK 19 underway draws nigh, please review this usual set of start-of-release updates, including CSRs for the javac and javax.lang.model updates:
> 
> JDK-8277512: Add SourceVersion.RELEASE_19
> https://bugs.openjdk.java.net/browse/JDK-8277512
> 
> JDK-8277514: Add source 19 and target 19 to javac
> https://bugs.openjdk.java.net/browse/JDK-8277514
> 
> Clean local tier 1 test runs for langtools, jdk, and hotspot.

This pull request has now been integrated.

Changeset: 09831e7a
Author:    Joe Darcy <darcy at openjdk.org>
Committer: Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/09831e7aa47ebe41eab2f3014ebbacf338097ef6
Stats:     4252 lines in 67 files changed: 4206 ins; 7 del; 39 mod

8273146: Start of release updates for JDK 19
8277511: Add SourceVersion.RELEASE_19
8277513: Add source 19 and target 19 to javac

Reviewed-by: dholmes, alanb, erikj, iris, mikael, ihse

-------------

PR: https://git.openjdk.java.net/jdk/pull/6493

From dcubed at openjdk.java.net  Thu Dec  9 22:06:00 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 9 Dec 2021 22:06:00 GMT
Subject: [jdk18] Integrated: 8278521: ProblemList
 java/lang/management/ThreadMXBean/ThreadLists.java
Message-ID: <OUokkXJ17o8TBCliBNn0XqemYhro75Tw7dBibLGV-hA=.116e96ac-7f87-44ee-a825-90690a8e77e2@github.com>

A trivial fix to ProblemList java/lang/management/ThreadMXBean/ThreadLists.java on all configs.

-------------

Commit messages:
 - 8278521: ProblemList java/lang/management/ThreadMXBean/ThreadLists.java

Changes: https://git.openjdk.java.net/jdk18/pull/3/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=3&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278521
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/3.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/3/head:pull/3

PR: https://git.openjdk.java.net/jdk18/pull/3

From bpb at openjdk.java.net  Thu Dec  9 22:06:00 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 9 Dec 2021 22:06:00 GMT
Subject: [jdk18] Integrated: 8278521: ProblemList
 java/lang/management/ThreadMXBean/ThreadLists.java
In-Reply-To: <OUokkXJ17o8TBCliBNn0XqemYhro75Tw7dBibLGV-hA=.116e96ac-7f87-44ee-a825-90690a8e77e2@github.com>
References: <OUokkXJ17o8TBCliBNn0XqemYhro75Tw7dBibLGV-hA=.116e96ac-7f87-44ee-a825-90690a8e77e2@github.com>
Message-ID: <Lfuxjoao6DLZFR16eLgodv_LvLuYDTYqok86LmCGgSs=.1790acab-da15-4ddd-b9a6-da2827e78e02@github.com>

On Thu, 9 Dec 2021 21:57:13 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/lang/management/ThreadMXBean/ThreadLists.java on all configs.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk18/pull/3

From dcubed at openjdk.java.net  Thu Dec  9 22:06:01 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 9 Dec 2021 22:06:01 GMT
Subject: [jdk18] Integrated: 8278521: ProblemList
 java/lang/management/ThreadMXBean/ThreadLists.java
In-Reply-To: <Lfuxjoao6DLZFR16eLgodv_LvLuYDTYqok86LmCGgSs=.1790acab-da15-4ddd-b9a6-da2827e78e02@github.com>
References: <OUokkXJ17o8TBCliBNn0XqemYhro75Tw7dBibLGV-hA=.116e96ac-7f87-44ee-a825-90690a8e77e2@github.com>
 <Lfuxjoao6DLZFR16eLgodv_LvLuYDTYqok86LmCGgSs=.1790acab-da15-4ddd-b9a6-da2827e78e02@github.com>
Message-ID: <n7rnjyr0udhYqos1xiva6gs5DjO_uVBahveNKgDc-L4=.a99bad16-ce73-42e5-8d9d-c7fd4c9b67aa@github.com>

On Thu, 9 Dec 2021 21:59:19 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> A trivial fix to ProblemList java/lang/management/ThreadMXBean/ThreadLists.java on all configs.
>
> Marked as reviewed by bpb (Reviewer).

@bplb - Thanks for the lightning fast review!

-------------

PR: https://git.openjdk.java.net/jdk18/pull/3

From dcubed at openjdk.java.net  Thu Dec  9 22:06:02 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 9 Dec 2021 22:06:02 GMT
Subject: [jdk18] Integrated: 8278521: ProblemList
 java/lang/management/ThreadMXBean/ThreadLists.java
In-Reply-To: <OUokkXJ17o8TBCliBNn0XqemYhro75Tw7dBibLGV-hA=.116e96ac-7f87-44ee-a825-90690a8e77e2@github.com>
References: <OUokkXJ17o8TBCliBNn0XqemYhro75Tw7dBibLGV-hA=.116e96ac-7f87-44ee-a825-90690a8e77e2@github.com>
Message-ID: <hrjKO3g8KoZ84C3nxNVFDQqvLc6zENCupI2GTO9b4wk=.f126d854-9a63-4ea3-b7a1-05fd2b7b9ed3@github.com>

On Thu, 9 Dec 2021 21:57:13 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/lang/management/ThreadMXBean/ThreadLists.java on all configs.

This pull request has now been integrated.

Changeset: d40e90b4
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/d40e90b4a1b55753a178d824c4c60209bc46efac
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8278521: ProblemList java/lang/management/ThreadMXBean/ThreadLists.java

Reviewed-by: bpb

-------------

PR: https://git.openjdk.java.net/jdk18/pull/3

From david.holmes at oracle.com  Thu Dec  9 22:07:55 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 10 Dec 2021 08:07:55 +1000
Subject: RFR: 8276901: Implement UseHeavyMonitors consistently [v11]
In-Reply-To: <uAsWBHXfrk349Nkr5w8cuDqXO_-dXWIQ3gLWxedrN0I=.2595b2ca-dc86-496f-b4d0-4590c575de2d@github.com>
References: <CqBVDMLRhPl93f8gcv5VX0Un-fFF5BQtGEwrczIJdp4=.6a50ad8f-3bbe-4075-9f8c-ee4da37e9f8b@github.com>
 <3ij7xShJzxFD9U79iHoJPnHJzg6rPv7T1r67gIqEuD4=.3b964bd4-1374-4d14-a4b3-e209c5954093@github.com>
 <A6J_n5kJKwEWrraZv_00ygcXaJOUqC8uKAmooAlr6bg=.440ed584-e386-48c3-8e33-0731831f4c64@github.com>
 <uAsWBHXfrk349Nkr5w8cuDqXO_-dXWIQ3gLWxedrN0I=.2595b2ca-dc86-496f-b4d0-4590c575de2d@github.com>
Message-ID: <7864a525-2d4b-9e97-de45-800e56ddd277@oracle.com>

(re-sending for the mailing lists as previous mail seems lost)

On 8/12/2021 12:40 am, Roman Kennke wrote:
> On Tue, 7 Dec 2021 14:34:48 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:
> 
>> So Tier[1-4] are complete and look fine. Mach5 is a bit over loaded at the moment so Tier[5-8] are still running. I think the Tier[1-4] results and the partial Tier[5-8] are good enough to say that these bits are okay.
> 
> Thanks, David! I will then go ahead and integrate this PR.

That was Daniel not David.

Sorry I didn't get back to this sooner but ...

I am not happy with the argument processing in 
Arguments::check_vm_args_consistency. This method does not call fatal(), 
it reports a warning or error message and returns false if VM 
initialization should not continue. Also for platforms where 
UseHeavyMonitors is not fully implemented it should not just be a 
warning IMO but also cause initialization to not continue. If we are 
going to return false then the error message should go to the error 
stream not be issued as a warning(). Please file a fillow up issue and 
fix this.

I remain concerned about the impact of this change on platforms that 
don't support UseHeavyMonitors fully.

David

> Cheers,
> Roman
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/6320

From duke at openjdk.java.net  Fri Dec 10 10:43:16 2021
From: duke at openjdk.java.net (KIRIYAMA Takuya)
Date: Fri, 10 Dec 2021 10:43:16 GMT
Subject: RFR: 8277531: Print actual default stacksize on Windows thread
 logging
In-Reply-To: <RAZoGS3tta9FVpbkdRSq2dA1BZpVXP9C1HRS-HxlR8M=.13074a86-d9f1-4243-8b00-573186ef9833@github.com>
References: <L2wrxWhTIPTC8xeV3zrOnk46JIQrpf1m7iB9m6_sl34=.d7c9f526-85da-43e0-b516-291113f58192@github.com>
 <75bf40e6-bf11-28b4-16e7-11e21a1d0ca0@oracle.com>
 <T3OAJTDch_ipEVaPCRnH4nwLEnITj0wgty2DFgrkxoA=.2bdac040-f380-4844-835a-3f5b31921e13@github.com>
 <RAZoGS3tta9FVpbkdRSq2dA1BZpVXP9C1HRS-HxlR8M=.13074a86-d9f1-4243-8b00-573186ef9833@github.com>
Message-ID: <QEfEUieGckXrK7UeBbGevSheppIpb2mTTVQQRSXxzA8=.c92b21ee-2167-4d26-ae87-9a4da8bacc62@github.com>

On Fri, 3 Dec 2021 10:01:27 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> The problem is that os:;win32::default_stack_size() doesn't necessarily
>>> report the default stack size - it simply reports the stackSize of the
>>> initial main JavaThread thread. So if you print it, it should only be
>>> for JavaThreads that are not CompilerThreads.
>> 
>> In either case of JavaThreads or CompilerThreads,the stack_size argument of _beginthreadex() must be 0 when this code is executed.
>> According to MSDN document, If the stack_size argument can be 0, the operating system uses the same value as the stack that's specified for the main thread.
>> default_stack_size is specified in create_vm() which runs in the main thread, so we use default_stack_size() for CompilerThreads.
>> 
>>> But if you run "java -Xss256k -XX:ThreadStackSize=512K" it will print
>>> 256K as the default stack size when in fact all JavaThreads except the
>>> main thread will get a 512K stack because of ThreadStackSize.
>> 
>> Yes,this behavior is odd. However, this fix executed only if stacksize is not specified.
>> This problem should be fixed in another issue.
>
> Hi, @tkiriyama,
> 
>> > The problem is that os:;win32::default_stack_size() doesn't necessarily
>> > report the default stack size - it simply reports the stackSize of the
>> > initial main JavaThread thread. So if you print it, it should only be
>> > for JavaThreads that are not CompilerThreads.
>> 
>> In either case of JavaThreads or CompilerThreads,the stack_size argument of _beginthreadex() must be 0 when this code is executed. According to MSDN document, If the stack_size argument can be 0, the operating system uses the same value as the stack that's specified for the main thread. default_stack_size is specified in create_vm() which runs in the main thread, so we use default_stack_size() for CompilerThreads.
> 
> Nope, unfortunately not. It runs on the thread invoking CreateJavaVM(). That is usually not the OS main thread (aka primordial thread). In the case of the standard java launcher, the primordial thread spawns a second thread to invoke CreateJavaVM() in, mainly to impose -Xss. In the case of a custom launcher, all bets are open which thread invokes CreateJavaVM(), but typically it's not the primordial thread either. In fact, we have platforms that explicitly forbid invoking CreateJavaVM() on the primordial thread.

Hi, @tstuefe ,

It?s exactly as you said.  
I tried to change _default_stack_size to be set in the main thread or get the stack size of other thread, but it doesn't work well.
I wonder if there might be another way to do this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6495

From stuefe at openjdk.java.net  Fri Dec 10 12:42:15 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 10 Dec 2021 12:42:15 GMT
Subject: RFR: 8277531: Print actual default stacksize on Windows thread
 logging
In-Reply-To: <RAZoGS3tta9FVpbkdRSq2dA1BZpVXP9C1HRS-HxlR8M=.13074a86-d9f1-4243-8b00-573186ef9833@github.com>
References: <L2wrxWhTIPTC8xeV3zrOnk46JIQrpf1m7iB9m6_sl34=.d7c9f526-85da-43e0-b516-291113f58192@github.com>
 <75bf40e6-bf11-28b4-16e7-11e21a1d0ca0@oracle.com>
 <T3OAJTDch_ipEVaPCRnH4nwLEnITj0wgty2DFgrkxoA=.2bdac040-f380-4844-835a-3f5b31921e13@github.com>
 <RAZoGS3tta9FVpbkdRSq2dA1BZpVXP9C1HRS-HxlR8M=.13074a86-d9f1-4243-8b00-573186ef9833@github.com>
Message-ID: <nPLiKHHVp_wadIaFmXMga93KEqlDOiY2lOxc9_YM_4E=.1f3c8f08-d069-4d70-8901-217972bf2137@github.com>

On Fri, 3 Dec 2021 10:01:27 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> The problem is that os:;win32::default_stack_size() doesn't necessarily
>>> report the default stack size - it simply reports the stackSize of the
>>> initial main JavaThread thread. So if you print it, it should only be
>>> for JavaThreads that are not CompilerThreads.
>> 
>> In either case of JavaThreads or CompilerThreads,the stack_size argument of _beginthreadex() must be 0 when this code is executed.
>> According to MSDN document, If the stack_size argument can be 0, the operating system uses the same value as the stack that's specified for the main thread.
>> default_stack_size is specified in create_vm() which runs in the main thread, so we use default_stack_size() for CompilerThreads.
>> 
>>> But if you run "java -Xss256k -XX:ThreadStackSize=512K" it will print
>>> 256K as the default stack size when in fact all JavaThreads except the
>>> main thread will get a 512K stack because of ThreadStackSize.
>> 
>> Yes,this behavior is odd. However, this fix executed only if stacksize is not specified.
>> This problem should be fixed in another issue.
>
> Hi, @tkiriyama,
> 
>> > The problem is that os:;win32::default_stack_size() doesn't necessarily
>> > report the default stack size - it simply reports the stackSize of the
>> > initial main JavaThread thread. So if you print it, it should only be
>> > for JavaThreads that are not CompilerThreads.
>> 
>> In either case of JavaThreads or CompilerThreads,the stack_size argument of _beginthreadex() must be 0 when this code is executed. According to MSDN document, If the stack_size argument can be 0, the operating system uses the same value as the stack that's specified for the main thread. default_stack_size is specified in create_vm() which runs in the main thread, so we use default_stack_size() for CompilerThreads.
> 
> Nope, unfortunately not. It runs on the thread invoking CreateJavaVM(). That is usually not the OS main thread (aka primordial thread). In the case of the standard java launcher, the primordial thread spawns a second thread to invoke CreateJavaVM() in, mainly to impose -Xss. In the case of a custom launcher, all bets are open which thread invokes CreateJavaVM(), but typically it's not the primordial thread either. In fact, we have platforms that explicitly forbid invoking CreateJavaVM() on the primordial thread.

> Hi, @tstuefe ,
> 
> It?s exactly as you said. I tried to change _default_stack_size to be set in the main thread or get the stack size of other thread, but it doesn't work well. I wonder if there might be another way to do this.

I only have bad ideas:

Bad idea:
1) start a thread on windows with stacksize 0. Measure stack size. Now you know the stack size. Obviously bad since we pay for the startup of one whole thread, pointlessly. Whose only point of existing is to tell us its stack size. 

Slightly better idea, but still bad:

2) set _default_stack_size=0 meaning unknown. The first thread created with stacksize=0 measures its own stack and updates that variable. Obviously bad because: too much complexity (e.g. how does the child know it was created with stacksize=0), and at least the first stacksize=0 thread will still be printed with "stacksize=0" by its parent.

Also bad, but differently bad :-) :

3) Just measure default stack size on a developer machine, assume it is the same as on every runtime machine. Hard-code that into the VM. Obviously also bad.

So, for now I don't see a good idea. If you come up with something better, feel free. But its not a big problem tbh, so probably not worth many brain cycles.

Cheers, Thomas

-------------

PR: https://git.openjdk.java.net/jdk/pull/6495

From lfoltan at openjdk.java.net  Fri Dec 10 14:44:13 2021
From: lfoltan at openjdk.java.net (Lois Foltan)
Date: Fri, 10 Dec 2021 14:44:13 GMT
Subject: RFR: 8276241: JVM does not flag constant class entries ending in
 '/'
In-Reply-To: <ntwDBwQxjsc7-e3DRMF4wP_MtuK4Y-uGOsFUmKURVyc=.df230152-3ae4-4fc4-b506-0e25d4edb391@github.com>
References: <ntwDBwQxjsc7-e3DRMF4wP_MtuK4Y-uGOsFUmKURVyc=.df230152-3ae4-4fc4-b506-0e25d4edb391@github.com>
Message-ID: <0joaN8vivjBG4eq0Q7atcP1Su9qgLBrk7VLJOKCZQqQ=.e638424c-c032-4d97-8e78-7e6dc364431c@github.com>

On Thu, 2 Dec 2021 19:22:20 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix for JDK-8276241.  The fix ensures that a ClassFormatError exception gets thrown for classes whose name ends in a '/' and are class file version less than 49 (JDK 1.5).  (A CFE already gets thrown for newer class file versions.)  The regression test class was written using a byte array because neither jcod nor jasm could handle a class name ending in '/'.
> 
> The fix was tested by running JCK lang and VM tests on Linux x64, Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.
> 
> Thanks, Harold

Looks good.
Lois

-------------

Marked as reviewed by lfoltan (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6678

From phh at openjdk.java.net  Fri Dec 10 15:32:10 2021
From: phh at openjdk.java.net (Paul Hohensee)
Date: Fri, 10 Dec 2021 15:32:10 GMT
Subject: RFR: 8278415: [TESTBUG] vmTestbase/nsk/stress/stack/stack018.java
 fails with "java.lang.Error: TEST_RFE"
In-Reply-To: <Ua16MzSZ3W6_2N-_xhkuogM5-qHYOlu7TlkVUGjRkL4=.aa599ebd-c720-4d8a-a78f-54af01266a99@github.com>
References: <Ua16MzSZ3W6_2N-_xhkuogM5-qHYOlu7TlkVUGjRkL4=.aa599ebd-c720-4d8a-a78f-54af01266a99@github.com>
Message-ID: <adzSL10fkHFV-WBEUVsU5JCFWv7b7lpPOqQuDc7JGqg=.fb56e523-fd27-4f0d-9d21-62437d93ce4e@github.com>

On Wed, 8 Dec 2021 14:42:17 GMT, Evgeny Astigeevich <duke at openjdk.java.net> wrote:

> Fix `vmTestbase/nsk/stress/stack/stack018.java` to have `maxDepth` equal to `STEP(100)` if the depth `STEP` causes stack overflow.
> 
> Testing: `vmTestbase/nsk/stress/stack/stack018.java`
> - `fastdebug` build: Passed.
> - `release` build: Passed.

Lgtm.

-------------

Marked as reviewed by phh (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6767

From xliu at openjdk.java.net  Fri Dec 10 17:23:20 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Fri, 10 Dec 2021 17:23:20 GMT
Subject: RFR: 8267517: async logging for stdout and stderr
In-Reply-To: <Nv1V5JHKgJh0NtqijGmWmI9Kh2VgDxgDIOAdfCtOavA=.503f41c2-a5d1-4a25-ab90-00252814a9bf@github.com>
References: <Nv1V5JHKgJh0NtqijGmWmI9Kh2VgDxgDIOAdfCtOavA=.503f41c2-a5d1-4a25-ab90-00252814a9bf@github.com>
Message-ID: <-3Db_4ErLy0J9SggYcFNrxOGrkR5ziyaN4cAQ7mCFkg=.cbcf080b-6aff-4315-bb38-3246a4c45684@github.com>

On Wed, 27 Oct 2021 08:22:12 GMT, Xin Liu <xliu at openjdk.org> wrote:

> This patch refactors LogFileStreamOutput so stdout/stderr can support support -Xlog:async.
> LogFileStreamOutput::flush() is virtual. 
> 
> With  `-Xlog:all=trace:stdout`, the helloworld in Java outputs 16520 log entries to stdout.  We are see that the wall time reduces from  86.977ms to 72.436ms, or the throughput increases 20% because of async logging.
> 
> 
> $perf stat -r 300 ./build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -Xlog:async -XX:AsyncLogBufferSize=48M HelloWorld > /dev/null
> 
>  Performance counter stats for './build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -Xlog:async -XX:AsyncLogBufferSize=48M HelloWorld' (300 runs):
> 
>             112.59 msec task-clock                #    1.554 CPUs utilized            ( +-  0.15% )
>              1,517      context-switches          #    0.013 M/sec                    ( +-  0.61% )
>                  1      cpu-migrations            #    0.010 K/sec                    ( +-  4.80% )
>              4,014      page-faults               #    0.036 M/sec                    ( +-  0.01% )
> ...
>           0.072436 +- 0.000135 seconds time elapsed  ( +-  0.19% )
> 
>  Performance counter stats for 'java -Xlog:all=trace:stdout  HelloWorld' (300 runs):
> 
>              90.73 msec task-clock                #    1.043 CPUs utilized            ( +-  0.11% )
>                318      context-switches          #    0.004 M/sec                    ( +-  0.32% )
>                  1      cpu-migrations            #    0.009 K/sec                    ( +-  4.80% )
>              4,010      page-faults               #    0.044 M/sec                    ( +-  0.00% )
> ...
>          0.0869777 +- 0.0000979 seconds time elapsed  ( +-  0.11% )
> 
> 
> In this patch, we also fold two locks(RotationLocker and FileLock) of LogFileOutput into one. FileLocker now can protect _stream from multiplexing and log rotation.  The other change is that AsyncLog writing doesn't require any lock protection because it's single-threaded. 
> 
> Add a new jtreg to cover a scenario that the blocked stdout doesn't freeze the JVM application.

Hello, 
May I ping this?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6132

From duke at openjdk.java.net  Fri Dec 10 18:31:15 2021
From: duke at openjdk.java.net (Evgeny Astigeevich)
Date: Fri, 10 Dec 2021 18:31:15 GMT
Subject: Integrated: 8278415: [TESTBUG]
 vmTestbase/nsk/stress/stack/stack018.java fails with
 "java.lang.Error: TEST_RFE"
In-Reply-To: <Ua16MzSZ3W6_2N-_xhkuogM5-qHYOlu7TlkVUGjRkL4=.aa599ebd-c720-4d8a-a78f-54af01266a99@github.com>
References: <Ua16MzSZ3W6_2N-_xhkuogM5-qHYOlu7TlkVUGjRkL4=.aa599ebd-c720-4d8a-a78f-54af01266a99@github.com>
Message-ID: <7Sjr293u36AdDa9rJfAITFwt4ASBoiWQFxC6UkxKMIY=.4191fcc4-047d-4111-879a-d9e2c9db4857@github.com>

On Wed, 8 Dec 2021 14:42:17 GMT, Evgeny Astigeevich <duke at openjdk.java.net> wrote:

> Fix `vmTestbase/nsk/stress/stack/stack018.java` to have `maxDepth` equal to `STEP(100)` if the depth `STEP` causes stack overflow.
> 
> Testing: `vmTestbase/nsk/stress/stack/stack018.java`
> - `fastdebug` build: Passed.
> - `release` build: Passed.

This pull request has now been integrated.

Changeset: afd065b3
Author:    Evgeny Astigeevich <eastig at amazon.com>
Committer: Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/afd065b3684f7b87563961c2b7a6ee6a354dbdf9
Stats:     9 lines in 1 file changed: 6 ins; 0 del; 3 mod

8278415: [TESTBUG] vmTestbase/nsk/stress/stack/stack018.java fails with "java.lang.Error: TEST_RFE"

Reviewed-by: phh

-------------

PR: https://git.openjdk.java.net/jdk/pull/6767

From xliu at openjdk.java.net  Fri Dec 10 18:50:16 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Fri, 10 Dec 2021 18:50:16 GMT
Subject: RFR: 8278415: [TESTBUG] vmTestbase/nsk/stress/stack/stack018.java
 fails with "java.lang.Error: TEST_RFE"
In-Reply-To: <Ua16MzSZ3W6_2N-_xhkuogM5-qHYOlu7TlkVUGjRkL4=.aa599ebd-c720-4d8a-a78f-54af01266a99@github.com>
References: <Ua16MzSZ3W6_2N-_xhkuogM5-qHYOlu7TlkVUGjRkL4=.aa599ebd-c720-4d8a-a78f-54af01266a99@github.com>
Message-ID: <F4gfKy7IdgixV5L_R03wd9Eo8saRwi4___8Gcn8Z1i4=.94cef5ee-5b42-4d56-a133-3381f58adb7b@github.com>

On Wed, 8 Dec 2021 14:42:17 GMT, Evgeny Astigeevich <duke at openjdk.java.net> wrote:

> Fix `vmTestbase/nsk/stress/stack/stack018.java` to have `maxDepth` equal to `STEP(100)` if the depth `STEP` causes stack overflow.
> 
> Testing: `vmTestbase/nsk/stress/stack/stack018.java`
> - `fastdebug` build: Passed.
> - `release` build: Passed.

I see. This is a corner case. If stack size is very small, it may throw the exception in its first trial.

Lgtm

-------------

PR: https://git.openjdk.java.net/jdk/pull/6767

From dcubed at openjdk.java.net  Sat Dec 11 15:05:30 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 11 Dec 2021 15:05:30 GMT
Subject: RFR: 8278580: ProblemList javax/swing/JTree/4908142/bug4908142.java on
 macosx-x64
Message-ID: <X85XL6rsPOX7jgUGkLnLcdwPPi6n-sV-h83AuKcjmc8=.02a6a7a7-2b3f-46b7-81fa-a4e7f75df403@github.com>

A trivial fix to ProblemList javax/swing/JTree/4908142/bug4908142.java on macosx-x64.

-------------

Commit messages:
 - 8278580: ProblemList javax/swing/JTree/4908142/bug4908142.java on macosx-x64

Changes: https://git.openjdk.java.net/jdk/pull/6805/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6805&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278580
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6805.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6805/head:pull/6805

PR: https://git.openjdk.java.net/jdk/pull/6805

From dfuchs at openjdk.java.net  Sat Dec 11 15:37:13 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Sat, 11 Dec 2021 15:37:13 GMT
Subject: RFR: 8278580: ProblemList
 javax/swing/JTree/4908142/bug4908142.java on macosx-x64
In-Reply-To: <X85XL6rsPOX7jgUGkLnLcdwPPi6n-sV-h83AuKcjmc8=.02a6a7a7-2b3f-46b7-81fa-a4e7f75df403@github.com>
References: <X85XL6rsPOX7jgUGkLnLcdwPPi6n-sV-h83AuKcjmc8=.02a6a7a7-2b3f-46b7-81fa-a4e7f75df403@github.com>
Message-ID: <wZv9ZXfrMiPtC4yj2-YC2wkNHxEEX0OVq0xDchsEz7k=.d3fa8529-fc06-4616-a847-9e3603644081@github.com>

On Sat, 11 Dec 2021 14:56:23 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList javax/swing/JTree/4908142/bug4908142.java on macosx-x64.

LGTM

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6805

From jdv at openjdk.java.net  Sat Dec 11 15:37:13 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Sat, 11 Dec 2021 15:37:13 GMT
Subject: RFR: 8278580: ProblemList
 javax/swing/JTree/4908142/bug4908142.java on macosx-x64
In-Reply-To: <X85XL6rsPOX7jgUGkLnLcdwPPi6n-sV-h83AuKcjmc8=.02a6a7a7-2b3f-46b7-81fa-a4e7f75df403@github.com>
References: <X85XL6rsPOX7jgUGkLnLcdwPPi6n-sV-h83AuKcjmc8=.02a6a7a7-2b3f-46b7-81fa-a4e7f75df403@github.com>
Message-ID: <3qxLkgEYe9MNEjw4xPU-EDyHpyKPOZ1JPZIsdSOiuWc=.295c1304-aa07-486b-be25-6c31eaab9452@github.com>

On Sat, 11 Dec 2021 14:56:23 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList javax/swing/JTree/4908142/bug4908142.java on macosx-x64.

Marked as reviewed by jdv (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6805

From dcubed at openjdk.java.net  Sat Dec 11 15:37:13 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 11 Dec 2021 15:37:13 GMT
Subject: RFR: 8278580: ProblemList
 javax/swing/JTree/4908142/bug4908142.java on macosx-x64
In-Reply-To: <X85XL6rsPOX7jgUGkLnLcdwPPi6n-sV-h83AuKcjmc8=.02a6a7a7-2b3f-46b7-81fa-a4e7f75df403@github.com>
References: <X85XL6rsPOX7jgUGkLnLcdwPPi6n-sV-h83AuKcjmc8=.02a6a7a7-2b3f-46b7-81fa-a4e7f75df403@github.com>
Message-ID: <USCzx-O1Q8SUhN_tKx4lfL_PTrZk4LzYv9UIRB5ybws=.1c6f0b44-91e9-4c73-b607-ddf40b9423f9@github.com>

On Sat, 11 Dec 2021 14:56:23 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList javax/swing/JTree/4908142/bug4908142.java on macosx-x64.

I just realized that I did this ProblemListing in the wrong repo.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6805

From dcubed at openjdk.java.net  Sat Dec 11 15:37:13 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 11 Dec 2021 15:37:13 GMT
Subject: Withdrawn: 8278580: ProblemList
 javax/swing/JTree/4908142/bug4908142.java on macosx-x64
In-Reply-To: <X85XL6rsPOX7jgUGkLnLcdwPPi6n-sV-h83AuKcjmc8=.02a6a7a7-2b3f-46b7-81fa-a4e7f75df403@github.com>
References: <X85XL6rsPOX7jgUGkLnLcdwPPi6n-sV-h83AuKcjmc8=.02a6a7a7-2b3f-46b7-81fa-a4e7f75df403@github.com>
Message-ID: <LUxeZYju2Q5uzFnvjgtzLsv2RvCJxyZDwRcwek3rLWM=.3deff2f5-94fa-4235-90a5-413e2f6c1a21@github.com>

On Sat, 11 Dec 2021 14:56:23 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList javax/swing/JTree/4908142/bug4908142.java on macosx-x64.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6805

From dcubed at openjdk.java.net  Sat Dec 11 15:43:14 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 11 Dec 2021 15:43:14 GMT
Subject: RFR: 8278580: ProblemList
 javax/swing/JTree/4908142/bug4908142.java on macosx-x64
In-Reply-To: <wZv9ZXfrMiPtC4yj2-YC2wkNHxEEX0OVq0xDchsEz7k=.d3fa8529-fc06-4616-a847-9e3603644081@github.com>
References: <X85XL6rsPOX7jgUGkLnLcdwPPi6n-sV-h83AuKcjmc8=.02a6a7a7-2b3f-46b7-81fa-a4e7f75df403@github.com>
 <wZv9ZXfrMiPtC4yj2-YC2wkNHxEEX0OVq0xDchsEz7k=.d3fa8529-fc06-4616-a847-9e3603644081@github.com>
Message-ID: <nduDgmQjsXaPt-XMI5TDmq2OfN52MTXksT2WswkDz6M=.912ec782-5ffa-47c9-8606-63a82276bb6c@github.com>

On Sat, 11 Dec 2021 15:29:36 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> A trivial fix to ProblemList javax/swing/JTree/4908142/bug4908142.java on macosx-x64.
>
> LGTM

@dfuch and @jayathirthrao - Can you please review this PR instead? Thanks!

https://github.com/openjdk/jdk18/pull/13

-------------

PR: https://git.openjdk.java.net/jdk/pull/6805

From dcubed at openjdk.java.net  Sat Dec 11 15:52:36 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 11 Dec 2021 15:52:36 GMT
Subject: [jdk18] RFR: 8278580: ProblemList
 javax/swing/JTree/4908142/bug4908142.java on macosx-x64
Message-ID: <4uStyfL8U-xmT4oVR6e347jHn6qDxI32zZHrJ2-VPv8=.87709800-cb76-47c8-89d6-9013b202b6c4@github.com>

A trivial fix to ProblemList javax/swing/JTree/4908142/bug4908142.java on macosx-x64.

-------------

Commit messages:
 - 8278580: ProblemList javax/swing/JTree/4908142/bug4908142.java on macosx-x64

Changes: https://git.openjdk.java.net/jdk18/pull/13/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=13&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278580
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/13.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/13/head:pull/13

PR: https://git.openjdk.java.net/jdk18/pull/13

From alanb at openjdk.java.net  Sat Dec 11 15:52:37 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 11 Dec 2021 15:52:37 GMT
Subject: [jdk18] RFR: 8278580: ProblemList
 javax/swing/JTree/4908142/bug4908142.java on macosx-x64
In-Reply-To: <4uStyfL8U-xmT4oVR6e347jHn6qDxI32zZHrJ2-VPv8=.87709800-cb76-47c8-89d6-9013b202b6c4@github.com>
References: <4uStyfL8U-xmT4oVR6e347jHn6qDxI32zZHrJ2-VPv8=.87709800-cb76-47c8-89d6-9013b202b6c4@github.com>
Message-ID: <DcQ9BkekVQlE_YR6HmOCrCg-BMtTfYqQECGnUK9HoPw=.3d4babe4-364f-487f-b8f8-2504e92cdd32@github.com>

On Sat, 11 Dec 2021 15:37:33 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList javax/swing/JTree/4908142/bug4908142.java on macosx-x64.

Approving to allow Dan exclude this test.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/13

From dcubed at openjdk.java.net  Sat Dec 11 15:52:38 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 11 Dec 2021 15:52:38 GMT
Subject: [jdk18] RFR: 8278580: ProblemList
 javax/swing/JTree/4908142/bug4908142.java on macosx-x64
In-Reply-To: <4uStyfL8U-xmT4oVR6e347jHn6qDxI32zZHrJ2-VPv8=.87709800-cb76-47c8-89d6-9013b202b6c4@github.com>
References: <4uStyfL8U-xmT4oVR6e347jHn6qDxI32zZHrJ2-VPv8=.87709800-cb76-47c8-89d6-9013b202b6c4@github.com>
Message-ID: <AnI0yI8CwY3XA4zn65GGVtpcfjrywZBiMlCwGymj3ts=.3f056d8d-ed23-4754-a744-b8c098b31386@github.com>

On Sat, 11 Dec 2021 15:37:33 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList javax/swing/JTree/4908142/bug4908142.java on macosx-x64.

@dfuch and @jayathirthrao - Can you please review this PR instead? Thanks!

-------------

PR: https://git.openjdk.java.net/jdk18/pull/13

From dcubed at openjdk.java.net  Sat Dec 11 15:57:13 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 11 Dec 2021 15:57:13 GMT
Subject: [jdk18] RFR: 8278580: ProblemList
 javax/swing/JTree/4908142/bug4908142.java on macosx-x64
In-Reply-To: <DcQ9BkekVQlE_YR6HmOCrCg-BMtTfYqQECGnUK9HoPw=.3d4babe4-364f-487f-b8f8-2504e92cdd32@github.com>
References: <4uStyfL8U-xmT4oVR6e347jHn6qDxI32zZHrJ2-VPv8=.87709800-cb76-47c8-89d6-9013b202b6c4@github.com>
 <DcQ9BkekVQlE_YR6HmOCrCg-BMtTfYqQECGnUK9HoPw=.3d4babe4-364f-487f-b8f8-2504e92cdd32@github.com>
Message-ID: <yfnJwAykINj_jZsEAqtq0bukAbo3UBH413wZ9T1GXUQ=.56d53392-9e6b-4288-ace5-f499f2245b8d@github.com>

On Sat, 11 Dec 2021 15:47:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> A trivial fix to ProblemList javax/swing/JTree/4908142/bug4908142.java on macosx-x64.
>
> Approving to allow Dan exclude this test.

@AlanBateman - Thanks for the review!

-------------

PR: https://git.openjdk.java.net/jdk18/pull/13

From dcubed at openjdk.java.net  Sat Dec 11 15:57:14 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 11 Dec 2021 15:57:14 GMT
Subject: [jdk18] Integrated: 8278580: ProblemList
 javax/swing/JTree/4908142/bug4908142.java on macosx-x64
In-Reply-To: <4uStyfL8U-xmT4oVR6e347jHn6qDxI32zZHrJ2-VPv8=.87709800-cb76-47c8-89d6-9013b202b6c4@github.com>
References: <4uStyfL8U-xmT4oVR6e347jHn6qDxI32zZHrJ2-VPv8=.87709800-cb76-47c8-89d6-9013b202b6c4@github.com>
Message-ID: <ErRfzzrfQOBT5cfqQHln-wQwBumwM6BvnNDdttL2Gag=.7ccb3c34-3254-423c-bf44-8b10819fe5b8@github.com>

On Sat, 11 Dec 2021 15:37:33 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList javax/swing/JTree/4908142/bug4908142.java on macosx-x64.

This pull request has now been integrated.

Changeset: 9b99cbe7
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/9b99cbe7abf56d3ad5231a68b6506e35b89133c9
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8278580: ProblemList javax/swing/JTree/4908142/bug4908142.java on macosx-x64

Reviewed-by: alanb

-------------

PR: https://git.openjdk.java.net/jdk18/pull/13

From fweimer at redhat.com  Mon Dec 13 13:21:23 2021
From: fweimer at redhat.com (Florian Weimer)
Date: Mon, 13 Dec 2021 14:21:23 +0100
Subject: glibc 2.12 support
Message-ID: <87ilvszlm4.fsf@oldenburg.str.redhat.com>

It seems that building against glibc 2.12 is still supported.  Is this
something that is still needed?

I'm mostly concerned with this fallback code on x86-64:

// Unfortunately we have to bring all these macros here from vsyscall.h
// to be able to compile on old linuxes.
  #define __NR_vgetcpu 2
  #define VSYSCALL_START (-10UL << 20)
  #define VSYSCALL_SIZE 1024
  #define VSYSCALL_ADDR(vsyscall_nr) (VSYSCALL_START+VSYSCALL_SIZE*(vsyscall_nr))
  typedef long (*vgetcpu_t)(unsigned int *cpu, unsigned int *node, unsigned long *tcache);
  vgetcpu_t vgetcpu = (vgetcpu_t)VSYSCALL_ADDR(__NR_vgetcpu);
  retval = vgetcpu(&cpu, NULL, NULL);

There is no way to check that the kernel actually supports vsyscall, and
on some kernels, this will crash because they have disabled vsyscall.

I would like to remove this or switch over to the system call (as
already used on i386).  This is fallback code only, so performance does
not really matter: on newer glibc (starting with 2.14), sched_getcpu
will be found, and it will use vDSO or rseq as appropriate.

Thanks,
Florian


From hseigel at openjdk.java.net  Mon Dec 13 13:44:13 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 13 Dec 2021 13:44:13 GMT
Subject: RFR: 8276241: JVM does not flag constant class entries ending in
 '/'
In-Reply-To: <ntwDBwQxjsc7-e3DRMF4wP_MtuK4Y-uGOsFUmKURVyc=.df230152-3ae4-4fc4-b506-0e25d4edb391@github.com>
References: <ntwDBwQxjsc7-e3DRMF4wP_MtuK4Y-uGOsFUmKURVyc=.df230152-3ae4-4fc4-b506-0e25d4edb391@github.com>
Message-ID: <04-ixhLIhdo3amGw7AFt-VLmfV6VqdzvCvPABQM9BQI=.6735e669-0e9c-43c1-9f16-9f1dc43f612f@github.com>

On Thu, 2 Dec 2021 19:22:20 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix for JDK-8276241.  The fix ensures that a ClassFormatError exception gets thrown for classes whose name ends in a '/' and are class file version less than 49 (JDK 1.5).  (A CFE already gets thrown for newer class file versions.)  The regression test class was written using a byte array because neither jcod nor jasm could handle a class name ending in '/'.
> 
> The fix was tested by running JCK lang and VM tests on Linux x64, Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.
> 
> Thanks, Harold

Thanks David and Lois for the reviews!

-------------

PR: https://git.openjdk.java.net/jdk/pull/6678

From hseigel at openjdk.java.net  Mon Dec 13 13:44:15 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 13 Dec 2021 13:44:15 GMT
Subject: Integrated: 8276241: JVM does not flag constant class entries ending
 in '/'
In-Reply-To: <ntwDBwQxjsc7-e3DRMF4wP_MtuK4Y-uGOsFUmKURVyc=.df230152-3ae4-4fc4-b506-0e25d4edb391@github.com>
References: <ntwDBwQxjsc7-e3DRMF4wP_MtuK4Y-uGOsFUmKURVyc=.df230152-3ae4-4fc4-b506-0e25d4edb391@github.com>
Message-ID: <0RaO6SZ4BRIy29eqvMKF-9fK3zN1897msZzOhf8LNT0=.c42c567a-0614-4426-8d09-47f43098a678@github.com>

On Thu, 2 Dec 2021 19:22:20 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix for JDK-8276241.  The fix ensures that a ClassFormatError exception gets thrown for classes whose name ends in a '/' and are class file version less than 49 (JDK 1.5).  (A CFE already gets thrown for newer class file versions.)  The regression test class was written using a byte array because neither jcod nor jasm could handle a class name ending in '/'.
> 
> The fix was tested by running JCK lang and VM tests on Linux x64, Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.
> 
> Thanks, Harold

This pull request has now been integrated.

Changeset: 15996e40
Author:    Harold Seigel <hseigel at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/15996e407563eda844266f1cbcdc20be74b4b4e4
Stats:     87 lines in 2 files changed: 84 ins; 1 del; 2 mod

8276241: JVM does not flag constant class entries ending in '/'

Reviewed-by: dholmes, lfoltan

-------------

PR: https://git.openjdk.java.net/jdk/pull/6678

From erik.joelsson at oracle.com  Mon Dec 13 13:58:44 2021
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Mon, 13 Dec 2021 05:58:44 -0800
Subject: glibc 2.12 support
In-Reply-To: <87ilvszlm4.fsf@oldenburg.str.redhat.com>
References: <87ilvszlm4.fsf@oldenburg.str.redhat.com>
Message-ID: <f530db55-bd47-69be-476b-80757ac9711b@oracle.com>

Hello Florian,

We still build with glibc 2.12 in the sysroot at Oracle as we still 
support Oracle Linux 6 (which uses glibc 2.12), so I'm afraid we still 
need it.

/Erik

On 2021-12-13 05:21, Florian Weimer wrote:
> It seems that building against glibc 2.12 is still supported.  Is this
> something that is still needed?
>
> I'm mostly concerned with this fallback code on x86-64:
>
> // Unfortunately we have to bring all these macros here from vsyscall.h
> // to be able to compile on old linuxes.
>    #define __NR_vgetcpu 2
>    #define VSYSCALL_START (-10UL << 20)
>    #define VSYSCALL_SIZE 1024
>    #define VSYSCALL_ADDR(vsyscall_nr) (VSYSCALL_START+VSYSCALL_SIZE*(vsyscall_nr))
>    typedef long (*vgetcpu_t)(unsigned int *cpu, unsigned int *node, unsigned long *tcache);
>    vgetcpu_t vgetcpu = (vgetcpu_t)VSYSCALL_ADDR(__NR_vgetcpu);
>    retval = vgetcpu(&cpu, NULL, NULL);
>
> There is no way to check that the kernel actually supports vsyscall, and
> on some kernels, this will crash because they have disabled vsyscall.
>
> I would like to remove this or switch over to the system call (as
> already used on i386).  This is fallback code only, so performance does
> not really matter: on newer glibc (starting with 2.14), sched_getcpu
> will be found, and it will use vDSO or rseq as appropriate.
>
> Thanks,
> Florian
>

From fweimer at redhat.com  Mon Dec 13 15:38:31 2021
From: fweimer at redhat.com (Florian Weimer)
Date: Mon, 13 Dec 2021 16:38:31 +0100
Subject: glibc 2.12 support
In-Reply-To: <f530db55-bd47-69be-476b-80757ac9711b@oracle.com> (erik
 joelsson's message of "Mon, 13 Dec 2021 05:58:44 -0800")
References: <87ilvszlm4.fsf@oldenburg.str.redhat.com>
 <f530db55-bd47-69be-476b-80757ac9711b@oracle.com>
Message-ID: <87mtl4y0p4.fsf@oldenburg.str.redhat.com>

* erik joelsson:

> Hello Florian,
>
> We still build with glibc 2.12 in the sysroot at Oracle as we still
> support Oracle Linux 6 (which uses glibc 2.12), so I'm afraid we still 
> need it.

Fair enough.  I will tack another thing to the side of this then. 8->

Thanks,
Florian


From rriggs at openjdk.java.net  Mon Dec 13 19:11:12 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 13 Dec 2021 19:11:12 GMT
Subject: RFR: 8278028: [test-library] Warnings cleanup of the test library
In-Reply-To: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
References: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
Message-ID: <Ls7C1bPBzJZa8vwz5FZEuSODWcYoQETlIdhyu5pQaew=.ed156553-2284-4dfa-9eab-8e9162d7a416@github.com>

On Wed, 1 Dec 2021 14:47:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Compilation warnings of the test library introduce noise in test output and should be addressed or suppressed. 
> Changes include:
>  - SuppressWarnings("deprecation") and SuppressWarnings("removal")
>  - Adding type parameters to Raw types
>  - Adding a hashCode method where equals was already present

Can another reviewer take a look at this?  Thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/6638

From mchung at openjdk.java.net  Mon Dec 13 19:17:15 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 13 Dec 2021 19:17:15 GMT
Subject: RFR: 8278028: [test-library] Warnings cleanup of the test library
In-Reply-To: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
References: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
Message-ID: <f93hCeC6zF4FbBaDdoKDYKVQ3Hokd_bTTFDCX3xd9_U=.21c7546b-7e83-4639-b68c-b856751fa1b8@github.com>

On Wed, 1 Dec 2021 14:47:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Compilation warnings of the test library introduce noise in test output and should be addressed or suppressed. 
> Changes include:
>  - SuppressWarnings("deprecation") and SuppressWarnings("removal")
>  - Adding type parameters to Raw types
>  - Adding a hashCode method where equals was already present

Looks okay to me.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6638

From naoto at openjdk.java.net  Mon Dec 13 19:22:15 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 13 Dec 2021 19:22:15 GMT
Subject: RFR: 8278028: [test-library] Warnings cleanup of the test library
In-Reply-To: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
References: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
Message-ID: <uxy-LBLE6w7tDiUcqM1SYLVPNCajMSeCijHvDIQNtq8=.1b52596a-0232-454d-a2b3-15e1e38713f3@github.com>

On Wed, 1 Dec 2021 14:47:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Compilation warnings of the test library introduce noise in test output and should be addressed or suppressed. 
> Changes include:
>  - SuppressWarnings("deprecation") and SuppressWarnings("removal")
>  - Adding type parameters to Raw types
>  - Adding a hashCode method where equals was already present

LGTM. Nit: Some of the files need copyright year updates.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6638

From lancea at openjdk.java.net  Mon Dec 13 20:32:22 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 13 Dec 2021 20:32:22 GMT
Subject: RFR: 8278028: [test-library] Warnings cleanup of the test library
In-Reply-To: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
References: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
Message-ID: <xiZX1XGf86fQXiJHBbuA_x8Sfw1mvdjf9ZQSPWEB6fs=.012a3461-0f30-4817-b5f5-a955db2266f3@github.com>

On Wed, 1 Dec 2021 14:47:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Compilation warnings of the test library introduce noise in test output and should be addressed or suppressed. 
> Changes include:
>  - SuppressWarnings("deprecation") and SuppressWarnings("removal")
>  - Adding type parameters to Raw types
>  - Adding a hashCode method where equals was already present

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6638

From dcubed at openjdk.java.net  Mon Dec 13 20:39:47 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 13 Dec 2021 20:39:47 GMT
Subject: Integrated: 8278630: ProblemList
 compiler/vectorapi/reshape/TestVectorCastAVX512.java on X64
Message-ID: <hEBd-Yt71rL9ro7Io7atrgJsF8bDJi8qwHmAKtqXQU0=.c0f57dfc-28ec-4c81-bdbc-74bf42e1436c@github.com>

A trivial fix to ProblemList compiler/vectorapi/reshape/TestVectorCastAVX512.java on X64.

-------------

Commit messages:
 - 8278630: ProblemList compiler/vectorapi/reshape/TestVectorCastAVX512.java on X64

Changes: https://git.openjdk.java.net/jdk/pull/6817/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6817&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278630
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6817.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6817/head:pull/6817

PR: https://git.openjdk.java.net/jdk/pull/6817

From psandoz at openjdk.java.net  Mon Dec 13 20:39:48 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 13 Dec 2021 20:39:48 GMT
Subject: Integrated: 8278630: ProblemList
 compiler/vectorapi/reshape/TestVectorCastAVX512.java on X64
In-Reply-To: <hEBd-Yt71rL9ro7Io7atrgJsF8bDJi8qwHmAKtqXQU0=.c0f57dfc-28ec-4c81-bdbc-74bf42e1436c@github.com>
References: <hEBd-Yt71rL9ro7Io7atrgJsF8bDJi8qwHmAKtqXQU0=.c0f57dfc-28ec-4c81-bdbc-74bf42e1436c@github.com>
Message-ID: <FNjqSDqh41qRwXwWgZ9UYW9mbmnyk_ntUkp_7PzbN_s=.83341aed-f108-44c1-8482-2637d1166a6a@github.com>

On Mon, 13 Dec 2021 20:29:54 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList compiler/vectorapi/reshape/TestVectorCastAVX512.java on X64.

Marked as reviewed by psandoz (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6817

From dcubed at openjdk.java.net  Mon Dec 13 20:39:49 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 13 Dec 2021 20:39:49 GMT
Subject: Integrated: 8278630: ProblemList
 compiler/vectorapi/reshape/TestVectorCastAVX512.java on X64
In-Reply-To: <FNjqSDqh41qRwXwWgZ9UYW9mbmnyk_ntUkp_7PzbN_s=.83341aed-f108-44c1-8482-2637d1166a6a@github.com>
References: <hEBd-Yt71rL9ro7Io7atrgJsF8bDJi8qwHmAKtqXQU0=.c0f57dfc-28ec-4c81-bdbc-74bf42e1436c@github.com>
 <FNjqSDqh41qRwXwWgZ9UYW9mbmnyk_ntUkp_7PzbN_s=.83341aed-f108-44c1-8482-2637d1166a6a@github.com>
Message-ID: <_nQyUOJpn1Zs-9PQvbW9wczzhfmZat-iQAnjRjXHCZw=.4a60d8d6-14fa-404f-b428-35f5049e758d@github.com>

On Mon, 13 Dec 2021 20:31:32 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> A trivial fix to ProblemList compiler/vectorapi/reshape/TestVectorCastAVX512.java on X64.
>
> Marked as reviewed by psandoz (Reviewer).

@PaulSandoz - Thanks for the fast review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6817

From dcubed at openjdk.java.net  Mon Dec 13 20:39:50 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 13 Dec 2021 20:39:50 GMT
Subject: Integrated: 8278630: ProblemList
 compiler/vectorapi/reshape/TestVectorCastAVX512.java on X64
In-Reply-To: <hEBd-Yt71rL9ro7Io7atrgJsF8bDJi8qwHmAKtqXQU0=.c0f57dfc-28ec-4c81-bdbc-74bf42e1436c@github.com>
References: <hEBd-Yt71rL9ro7Io7atrgJsF8bDJi8qwHmAKtqXQU0=.c0f57dfc-28ec-4c81-bdbc-74bf42e1436c@github.com>
Message-ID: <fBL2ePmU_qQ7195tukxwDWnMeIZElGlpH-_pybfMQk8=.6b6a2da9-2bdb-474f-867e-ee1506e52a0c@github.com>

On Mon, 13 Dec 2021 20:29:54 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList compiler/vectorapi/reshape/TestVectorCastAVX512.java on X64.

This pull request has now been integrated.

Changeset: bdc784c0
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bdc784c0cb02d76c6d3a1608a89f4b64f86253eb
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8278630: ProblemList compiler/vectorapi/reshape/TestVectorCastAVX512.java on X64

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.java.net/jdk/pull/6817

From rriggs at openjdk.java.net  Mon Dec 13 20:58:50 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 13 Dec 2021 20:58:50 GMT
Subject: RFR: 8278028: [test-library] Warnings cleanup of the test library
 [v2]
In-Reply-To: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
References: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
Message-ID: <34TQtKxHSIllteIJhiytv6QkmZm4X3wuXgZXbg6S9OE=.2f67a728-9d12-45f4-88dd-4beff430b4aa@github.com>

> Compilation warnings of the test library introduce noise in test output and should be addressed or suppressed. 
> Changes include:
>  - SuppressWarnings("deprecation") and SuppressWarnings("removal")
>  - Adding type parameters to Raw types
>  - Adding a hashCode method where equals was already present

Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' into 8278028-test-warning-cleanup
 - Update copyrights
 - 8278028: [test-library] Warnings cleanup of the test library

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6638/files
  - new: https://git.openjdk.java.net/jdk/pull/6638/files/0f445b4a..b1bbdfc7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6638&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6638&range=00-01

  Stats: 30109 lines in 1016 files changed: 21851 ins; 3569 del; 4689 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6638.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6638/head:pull/6638

PR: https://git.openjdk.java.net/jdk/pull/6638

From dholmes at openjdk.java.net  Mon Dec 13 22:24:49 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 13 Dec 2021 22:24:49 GMT
Subject: RFR: 8268573: Remove expired flags in JDK 19
Message-ID: <1JzfCm_-QMikvfVrn1AdEFlYOS8KaPgEO2ZzaC3Smw8=.b43f45af-62e6-4561-a202-25c17a706d2f@github.com>

Please review this simple change to remove all the flags that expired in JDK 19 from the flag table in arguments.cpp.

The java manpage is also updated as the UseBiasedLocking flag is moved from the "obsoleted" section, to the "removed" section. Plus we update the list of previous release docs.

Testing: local - all the runtime/CommandLine tests

Thanks,
David

-------------

Commit messages:
 - 8268573: Remove expired flags in JDK 19

Changes: https://git.openjdk.java.net/jdk/pull/6819/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6819&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268573
  Stats: 29 lines in 2 files changed: 11 ins; 17 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6819.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6819/head:pull/6819

PR: https://git.openjdk.java.net/jdk/pull/6819

From dholmes at openjdk.java.net  Tue Dec 14 02:04:19 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 14 Dec 2021 02:04:19 GMT
Subject: RFR: 8267517: async logging for stdout and stderr
In-Reply-To: <Nv1V5JHKgJh0NtqijGmWmI9Kh2VgDxgDIOAdfCtOavA=.503f41c2-a5d1-4a25-ab90-00252814a9bf@github.com>
References: <Nv1V5JHKgJh0NtqijGmWmI9Kh2VgDxgDIOAdfCtOavA=.503f41c2-a5d1-4a25-ab90-00252814a9bf@github.com>
Message-ID: <w0aDpgQFJScFf8yb7YQgdwDzm5PMcYm7M0x3AtYy2u8=.39bc3371-1df0-4a20-9c2f-ce4444d4b1e6@github.com>

On Wed, 27 Oct 2021 08:22:12 GMT, Xin Liu <xliu at openjdk.org> wrote:

> This patch refactors LogFileStreamOutput so stdout/stderr can support support -Xlog:async.
> LogFileStreamOutput::flush() is virtual. 
> 
> With  `-Xlog:all=trace:stdout`, the helloworld in Java outputs 16520 log entries to stdout.  We are see that the wall time reduces from  86.977ms to 72.436ms, or the throughput increases 20% because of async logging.
> 
> 
> $perf stat -r 300 ./build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -Xlog:async -XX:AsyncLogBufferSize=48M HelloWorld > /dev/null
> 
>  Performance counter stats for './build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -Xlog:async -XX:AsyncLogBufferSize=48M HelloWorld' (300 runs):
> 
>             112.59 msec task-clock                #    1.554 CPUs utilized            ( +-  0.15% )
>              1,517      context-switches          #    0.013 M/sec                    ( +-  0.61% )
>                  1      cpu-migrations            #    0.010 K/sec                    ( +-  4.80% )
>              4,014      page-faults               #    0.036 M/sec                    ( +-  0.01% )
> ...
>           0.072436 +- 0.000135 seconds time elapsed  ( +-  0.19% )
> 
>  Performance counter stats for 'java -Xlog:all=trace:stdout  HelloWorld' (300 runs):
> 
>              90.73 msec task-clock                #    1.043 CPUs utilized            ( +-  0.11% )
>                318      context-switches          #    0.004 M/sec                    ( +-  0.32% )
>                  1      cpu-migrations            #    0.009 K/sec                    ( +-  4.80% )
>              4,010      page-faults               #    0.044 M/sec                    ( +-  0.00% )
> ...
>          0.0869777 +- 0.0000979 seconds time elapsed  ( +-  0.11% )
> 
> 
> In this patch, we also fold two locks(RotationLocker and FileLock) of LogFileOutput into one. FileLocker now can protect _stream from multiplexing and log rotation.  The other change is that AsyncLog writing doesn't require any lock protection because it's single-threaded. 
> 
> Add a new jtreg to cover a scenario that the blocked stdout doesn't freeze the JVM application.

Hi Xin,

I took a look at this but to be honest I couldn't work out what most of the changes actually had to do with the topic of adding async logging for stdout/stderr.  IIUC the change from `LogFileOutput` to `LogFileStreamOutput` in the API now enables it to be used for stdout/stderr - right?  But most of the changes seemed to relate to log file rotation which doesn't even apply to stdout/stderr! What has force_rotation got to do with things?

David

src/hotspot/share/logging/logFileStreamOutput.hpp line 69:

> 67:   class FileLocker : public StackObj {
> 68:     Semaphore& _sem;
> 69:     debug_only(intx& _locking_thread_id;)

This seems unused even in debug builds- it is set but never inspected. ??

test/hotspot/jtreg/runtime/logging/BlockedLoggingTest.java line 51:

> 49: 
> 50:     // process 0 emits unified log to stdout. We must ensure that nobody except for UL emits to stdout.
> 51:     // we expect to demonstrate that process 0 with -Xlog:async can still terminate even though its

Nit: if your comments are sentences then they should start with capital letters. This applies all through this code.

test/hotspot/jtreg/runtime/logging/BlockedLoggingTest.java line 60:

> 58:             Thread[] threads = new Thread[ThreadNum];
> 59:             // the size of pipe buffer is hard to tell. just churn many gc-related logs
> 60:             // in ChurnThread.Duration sececonds. it's presumably 64k on Linux.

typo: sececonds

test/hotspot/jtreg/runtime/logging/BlockedLoggingTest.java line 140:

> 138:                     while (true) {
> 139:                         Thread.yield();
> 140:                     }

Don't do a busy wait - use a sleep() or a wait().

-------------

PR: https://git.openjdk.java.net/jdk/pull/6132

From lmesnik at openjdk.java.net  Tue Dec 14 03:17:35 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 14 Dec 2021 03:17:35 GMT
Subject: RFR: 8278028: [test-library] Warnings cleanup of the test library
 [v2]
In-Reply-To: <34TQtKxHSIllteIJhiytv6QkmZm4X3wuXgZXbg6S9OE=.2f67a728-9d12-45f4-88dd-4beff430b4aa@github.com>
References: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
 <34TQtKxHSIllteIJhiytv6QkmZm4X3wuXgZXbg6S9OE=.2f67a728-9d12-45f4-88dd-4beff430b4aa@github.com>
Message-ID: <5I7sZItyG10RIu7IrWqtJElr62FMSxmtY7JDqFKXYbg=.6db7fbe4-69c1-42d1-a293-780184bdf8f8@github.com>

On Mon, 13 Dec 2021 20:58:50 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Compilation warnings of the test library introduce noise in test output and should be addressed or suppressed. 
>> Changes include:
>>  - SuppressWarnings("deprecation") and SuppressWarnings("removal")
>>  - Adding type parameters to Raw types
>>  - Adding a hashCode method where equals was already present
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into 8278028-test-warning-cleanup
>  - Update copyrights
>  - 8278028: [test-library] Warnings cleanup of the test library

Is test/micro/org/openjdk/bench/java/io/SerialFilterOverhead.java  added accidentally or by purpose?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6638

From alanb at openjdk.java.net  Tue Dec 14 07:57:13 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 14 Dec 2021 07:57:13 GMT
Subject: RFR: 8268573: Remove expired flags in JDK 19
In-Reply-To: <1JzfCm_-QMikvfVrn1AdEFlYOS8KaPgEO2ZzaC3Smw8=.b43f45af-62e6-4561-a202-25c17a706d2f@github.com>
References: <1JzfCm_-QMikvfVrn1AdEFlYOS8KaPgEO2ZzaC3Smw8=.b43f45af-62e6-4561-a202-25c17a706d2f@github.com>
Message-ID: <GNLZvSb33eky0qdMNp0Rn_SzY74kaUY_lzAHqnFZ6Lk=.fb875f95-dc02-4e11-a424-6b31f1fe3369@github.com>

On Mon, 13 Dec 2021 22:17:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this simple change to remove all the flags that expired in JDK 19 from the flag table in arguments.cpp.
> 
> The java manpage is also updated as the UseBiasedLocking flag is moved from the "obsoleted" section, to the "removed" section. Plus we update the list of previous release docs.
> 
> Testing: local - all the runtime/CommandLine tests
> 
> Thanks,
> David

src/hotspot/share/runtime/arguments.cpp line 551:

> 549:   { "G1RSetSparseRegionEntries",    JDK_Version::undefined(), JDK_Version::jdk(18), JDK_Version::jdk(19) },
> 550:   { "AlwaysLockClassLoader",        JDK_Version::jdk(17), JDK_Version::jdk(18), JDK_Version::jdk(19) },
> 551:   { "UseBiasedLocking",             JDK_Version::jdk(15), JDK_Version::jdk(18), JDK_Version::jdk(19) },

There are a number of servers with start scripts that specify -XX:-UseBiasedLocking. The option may be obsolete and I wonder if better to leave it as obsolete until there is more uptake of JDK 17 which does not need to disable it explicitly.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6819

From jiefu at openjdk.java.net  Tue Dec 14 11:27:46 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 14 Dec 2021 11:27:46 GMT
Subject: [jdk18] RFR: 8278758: runtime/BootstrapMethod/BSMCalledTwice.java
 fails with release VMs after JDK-8262134
Message-ID: <ZreviSuHSofHh9h93qWs3jo-tjHnyDrumFC6ZLDffh8=.2e6dfb95-8924-4619-ba75-96ebe6020d44@github.com>

Hi all,

runtime/BootstrapMethod/BSMCalledTwice.java fails with release VMs due to 'DeoptimizeALot' is develop after JDK-8262134.
This is because `-XX:+DeoptimizeALot` and `-XX:+VerifyStack` are develop and are available only in debug version.

The fix only run the test config added by JDK-8262134 with debug VMs.

Thanks.
Best regards,
Jie

-------------

Commit messages:
 - 8278758: runtime/BootstrapMethod/BSMCalledTwice.java fails with release VMs after JDK-8262134

Changes: https://git.openjdk.java.net/jdk18/pull/21/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=21&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278758
  Stats: 11 lines in 1 file changed: 9 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/21.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/21/head:pull/21

PR: https://git.openjdk.java.net/jdk18/pull/21

From dholmes at openjdk.java.net  Tue Dec 14 12:50:08 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 14 Dec 2021 12:50:08 GMT
Subject: RFR: 8268573: Remove expired flags in JDK 19
In-Reply-To: <GNLZvSb33eky0qdMNp0Rn_SzY74kaUY_lzAHqnFZ6Lk=.fb875f95-dc02-4e11-a424-6b31f1fe3369@github.com>
References: <1JzfCm_-QMikvfVrn1AdEFlYOS8KaPgEO2ZzaC3Smw8=.b43f45af-62e6-4561-a202-25c17a706d2f@github.com>
 <GNLZvSb33eky0qdMNp0Rn_SzY74kaUY_lzAHqnFZ6Lk=.fb875f95-dc02-4e11-a424-6b31f1fe3369@github.com>
Message-ID: <AlbwfzgOLnDawkaJgRmuQ3wOidKbyQm5-y9ujNDSF80=.712a1a1f-72ee-4722-bcd3-5af7c161500e@github.com>

On Tue, 14 Dec 2021 07:53:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please review this simple change to remove all the flags that expired in JDK 19 from the flag table in arguments.cpp.
>> 
>> The java manpage is also updated as the UseBiasedLocking flag is moved from the "obsoleted" section, to the "removed" section. Plus we update the list of previous release docs.
>> 
>> Testing: local - all the runtime/CommandLine tests
>> 
>> Thanks,
>> David
>
> src/hotspot/share/runtime/arguments.cpp line 551:
> 
>> 549:   { "G1RSetSparseRegionEntries",    JDK_Version::undefined(), JDK_Version::jdk(18), JDK_Version::jdk(19) },
>> 550:   { "AlwaysLockClassLoader",        JDK_Version::jdk(17), JDK_Version::jdk(18), JDK_Version::jdk(19) },
>> 551:   { "UseBiasedLocking",             JDK_Version::jdk(15), JDK_Version::jdk(18), JDK_Version::jdk(19) },
> 
> There are a number of servers with start scripts that specify -XX:-UseBiasedLocking. The option may be obsolete and I wonder if better to leave it as obsolete until there is more uptake of JDK 17 which does not need to disable it explicitly.

I don't understand the relevance of "uptake of JDK 17" - this change only affects 19. Anyone on 17 will get the deprecation warning as we deliberately deferred obsoleting the flag until JDK 18.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6819

From alanb at openjdk.java.net  Tue Dec 14 13:14:17 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 14 Dec 2021 13:14:17 GMT
Subject: RFR: 8268573: Remove expired flags in JDK 19
In-Reply-To: <AlbwfzgOLnDawkaJgRmuQ3wOidKbyQm5-y9ujNDSF80=.712a1a1f-72ee-4722-bcd3-5af7c161500e@github.com>
References: <1JzfCm_-QMikvfVrn1AdEFlYOS8KaPgEO2ZzaC3Smw8=.b43f45af-62e6-4561-a202-25c17a706d2f@github.com>
 <GNLZvSb33eky0qdMNp0Rn_SzY74kaUY_lzAHqnFZ6Lk=.fb875f95-dc02-4e11-a424-6b31f1fe3369@github.com>
 <AlbwfzgOLnDawkaJgRmuQ3wOidKbyQm5-y9ujNDSF80=.712a1a1f-72ee-4722-bcd3-5af7c161500e@github.com>
Message-ID: <nRGtoSFRMsR5eKkYbYM9JbA2ktz_EqmGQMGqn_1fDR0=.c5358a70-2056-4d51-8aa7-fa2b378f6ae7@github.com>

On Tue, 14 Dec 2021 12:47:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/arguments.cpp line 551:
>> 
>>> 549:   { "G1RSetSparseRegionEntries",    JDK_Version::undefined(), JDK_Version::jdk(18), JDK_Version::jdk(19) },
>>> 550:   { "AlwaysLockClassLoader",        JDK_Version::jdk(17), JDK_Version::jdk(18), JDK_Version::jdk(19) },
>>> 551:   { "UseBiasedLocking",             JDK_Version::jdk(15), JDK_Version::jdk(18), JDK_Version::jdk(19) },
>> 
>> There are a number of servers with start scripts that specify -XX:-UseBiasedLocking. The option may be obsolete and I wonder if better to leave it as obsolete until there is more uptake of JDK 17 which does not need to disable it explicitly.
>
> I don't understand the relevance of "uptake of JDK 17" - this change only affects 19. Anyone on 17 will get the deprecation warning as we deliberately deferred obsoleting the flag until JDK 18.

It means the start scripts won't be usable with JDK 19+ builds so it complicates testing with those servers. Once these servers get to JDK 17 (actually JDK 15+) then they should be able to drop this option. I think the more general point is that we could be less aggressive about removing obsolete VM options when we know they are being used. In the past, the PermGen options were left as obsolete options for a long time because there were widely used.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6819

From lmesnik at openjdk.java.net  Tue Dec 14 15:23:48 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 14 Dec 2021 15:23:48 GMT
Subject: RFR: 8278028: [test-library] Warnings cleanup of the test library
 [v3]
In-Reply-To: <oKn373zoGIRF2O0ba0gsn0LvavfyUr6_rrXev6cUZbE=.b8c20feb-139d-472c-863a-3bb15966a733@github.com>
References: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
 <oKn373zoGIRF2O0ba0gsn0LvavfyUr6_rrXev6cUZbE=.b8c20feb-139d-472c-863a-3bb15966a733@github.com>
Message-ID: <NtwcOf4syrU8sHafxEq0t33YYEJOW12-TOfGXaT82EU=.77dddc0f-7536-4749-a033-b0b739048632@github.com>

On Tue, 14 Dec 2021 15:20:31 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Compilation warnings of the test library introduce noise in test output and should be addressed or suppressed. 
>> Changes include:
>>  - SuppressWarnings("deprecation") and SuppressWarnings("removal")
>>  - Adding type parameters to Raw types
>>  - Adding a hashCode method where equals was already present
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove a test/micro file added by mistake.

Marked as reviewed by lmesnik (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6638

From rriggs at openjdk.java.net  Tue Dec 14 15:23:47 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 14 Dec 2021 15:23:47 GMT
Subject: RFR: 8278028: [test-library] Warnings cleanup of the test library
 [v3]
In-Reply-To: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
References: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
Message-ID: <oKn373zoGIRF2O0ba0gsn0LvavfyUr6_rrXev6cUZbE=.b8c20feb-139d-472c-863a-3bb15966a733@github.com>

> Compilation warnings of the test library introduce noise in test output and should be addressed or suppressed. 
> Changes include:
>  - SuppressWarnings("deprecation") and SuppressWarnings("removal")
>  - Adding type parameters to Raw types
>  - Adding a hashCode method where equals was already present

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Remove a test/micro file added by mistake.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6638/files
  - new: https://git.openjdk.java.net/jdk/pull/6638/files/b1bbdfc7..895acede

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6638&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6638&range=01-02

  Stats: 129 lines in 1 file changed: 0 ins; 129 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6638.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6638/head:pull/6638

PR: https://git.openjdk.java.net/jdk/pull/6638

From rriggs at openjdk.java.net  Tue Dec 14 15:23:50 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 14 Dec 2021 15:23:50 GMT
Subject: RFR: 8278028: [test-library] Warnings cleanup of the test library
 [v2]
In-Reply-To: <5I7sZItyG10RIu7IrWqtJElr62FMSxmtY7JDqFKXYbg=.6db7fbe4-69c1-42d1-a293-780184bdf8f8@github.com>
References: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
 <34TQtKxHSIllteIJhiytv6QkmZm4X3wuXgZXbg6S9OE=.2f67a728-9d12-45f4-88dd-4beff430b4aa@github.com>
 <5I7sZItyG10RIu7IrWqtJElr62FMSxmtY7JDqFKXYbg=.6db7fbe4-69c1-42d1-a293-780184bdf8f8@github.com>
Message-ID: <2AldylG79vmQABcXw3_k6iXKj9Y0nImbOeOePJIzxw0=.f886f9cd-fc34-49af-b293-fbf326e5ce5c@github.com>

On Tue, 14 Dec 2021 03:14:10 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Is test/micro/org/openjdk/bench/java/io/SerialFilterOverhead.java added accidentally or by purpose?

By mistake, thanks for noticing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6638

From dcubed at openjdk.java.net  Tue Dec 14 15:54:13 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 14 Dec 2021 15:54:13 GMT
Subject: [jdk18] RFR: 8278758: runtime/BootstrapMethod/BSMCalledTwice.java
 fails with release VMs after JDK-8262134
In-Reply-To: <ZreviSuHSofHh9h93qWs3jo-tjHnyDrumFC6ZLDffh8=.2e6dfb95-8924-4619-ba75-96ebe6020d44@github.com>
References: <ZreviSuHSofHh9h93qWs3jo-tjHnyDrumFC6ZLDffh8=.2e6dfb95-8924-4619-ba75-96ebe6020d44@github.com>
Message-ID: <nWOJCuSzELbYqrowQniBObJnmTotP_rwyDq3u9MAPuA=.87704f7d-847f-43a5-aa1f-776b762ee4c5@github.com>

On Tue, 14 Dec 2021 11:18:54 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> runtime/BootstrapMethod/BSMCalledTwice.java fails with release VMs due to 'DeoptimizeALot' is develop after JDK-8262134.
> This is because `-XX:+DeoptimizeALot` and `-XX:+VerifyStack` are develop and are available only in debug version.
> 
> The fix only run the test config added by JDK-8262134 with debug VMs.
> 
> Thanks.
> Best regards,
> Jie

Thumbs up. This is a trivial fix.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/21

From hseigel at openjdk.java.net  Tue Dec 14 16:14:31 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 14 Dec 2021 16:14:31 GMT
Subject: RFR: 8278638: Remove FLAG_IS_CMDLINE(UseSharedSpaces)
Message-ID: <s6XwnSm9_IZX-4Q3R6aQkzbf4-rqTjKHbH3e9gSUss8=.ad88724b-d5ff-4a4c-a547-352bb29ddbd9@github.com>

Please review this small fix for bug JDK-827638.  The fix was tested by running Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, Mach5 tier 4 on Linux x64, and by building on linux-aarch64-zero and linux-x64-zero.

Thanks, Harold

-------------

Commit messages:
 - 8278638: Remove FLAG_IS_CMDLINE(UseSharedSpaces)

Changes: https://git.openjdk.java.net/jdk/pull/6835/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6835&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278638
  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6835.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6835/head:pull/6835

PR: https://git.openjdk.java.net/jdk/pull/6835

From dcubed at openjdk.java.net  Tue Dec 14 16:21:06 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 14 Dec 2021 16:21:06 GMT
Subject: RFR: 8278638: Remove FLAG_IS_CMDLINE(UseSharedSpaces)
In-Reply-To: <s6XwnSm9_IZX-4Q3R6aQkzbf4-rqTjKHbH3e9gSUss8=.ad88724b-d5ff-4a4c-a547-352bb29ddbd9@github.com>
References: <s6XwnSm9_IZX-4Q3R6aQkzbf4-rqTjKHbH3e9gSUss8=.ad88724b-d5ff-4a4c-a547-352bb29ddbd9@github.com>
Message-ID: <lkvMlcao1Igj3bz-PGYtaxi3TYw9i3aQw-D0-HIlsA8=.43ea05cf-5773-4862-bd10-8cf61d5abf85@github.com>

On Tue, 14 Dec 2021 16:06:28 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix for bug JDK-827638.  The fix was tested by running Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, Mach5 tier 4 on Linux x64, and by building on linux-aarch64-zero and linux-x64-zero.
> 
> Thanks, Harold

Thumbs up. I think this is a trivial fix.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6835

From minqi at openjdk.java.net  Tue Dec 14 17:41:28 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 14 Dec 2021 17:41:28 GMT
Subject: RFR: 8278638: Remove FLAG_IS_CMDLINE(UseSharedSpaces)
In-Reply-To: <s6XwnSm9_IZX-4Q3R6aQkzbf4-rqTjKHbH3e9gSUss8=.ad88724b-d5ff-4a4c-a547-352bb29ddbd9@github.com>
References: <s6XwnSm9_IZX-4Q3R6aQkzbf4-rqTjKHbH3e9gSUss8=.ad88724b-d5ff-4a4c-a547-352bb29ddbd9@github.com>
Message-ID: <OX41drG8EkMSvtTG2lvaHLi2-xVcZ1XZkZX4ckLFPlk=.6ad0295c-8881-4196-aac8-9050811d8cd0@github.com>

On Tue, 14 Dec 2021 16:06:28 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix for bug JDK-827638.  The fix was tested by running Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, Mach5 tier 4 on Linux x64, and by building on linux-aarch64-zero and linux-x64-zero.
> 
> Thanks, Harold

src/hotspot/share/runtime/arguments.cpp line 3999:

> 3997:     return JNI_ERR;
> 3998:   }
> 3999:   if ((UseSharedSpaces && xshare_auto_cmd_line) ||

xshare_auto_cmd_line is set with UseSharedSpaces (line 2715) so it should be OK to check only for itself.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6835

From coleenp at openjdk.java.net  Tue Dec 14 17:47:20 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 14 Dec 2021 17:47:20 GMT
Subject: RFR: 8278638: Remove FLAG_IS_CMDLINE(UseSharedSpaces)
In-Reply-To: <s6XwnSm9_IZX-4Q3R6aQkzbf4-rqTjKHbH3e9gSUss8=.ad88724b-d5ff-4a4c-a547-352bb29ddbd9@github.com>
References: <s6XwnSm9_IZX-4Q3R6aQkzbf4-rqTjKHbH3e9gSUss8=.ad88724b-d5ff-4a4c-a547-352bb29ddbd9@github.com>
Message-ID: <gyztgAArtlqN--nBfsO3w0hG_RE_wwReNoH1cOMToMs=.5aa00832-9fef-4e94-9ad8-8f3db1622056@github.com>

On Tue, 14 Dec 2021 16:06:28 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix for bug JDK-827638.  The fix was tested by running Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, Mach5 tier 4 on Linux x64, and by building on linux-aarch64-zero and linux-x64-zero.
> 
> Thanks, Harold

Looks good, also trivial. Thanks for fixing it.

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6835

From hseigel at openjdk.java.net  Tue Dec 14 18:35:36 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 14 Dec 2021 18:35:36 GMT
Subject: RFR: 8278638: Remove FLAG_IS_CMDLINE(UseSharedSpaces)
In-Reply-To: <OX41drG8EkMSvtTG2lvaHLi2-xVcZ1XZkZX4ckLFPlk=.6ad0295c-8881-4196-aac8-9050811d8cd0@github.com>
References: <s6XwnSm9_IZX-4Q3R6aQkzbf4-rqTjKHbH3e9gSUss8=.ad88724b-d5ff-4a4c-a547-352bb29ddbd9@github.com>
 <OX41drG8EkMSvtTG2lvaHLi2-xVcZ1XZkZX4ckLFPlk=.6ad0295c-8881-4196-aac8-9050811d8cd0@github.com>
Message-ID: <iRJCJQQ4zhTOw3tnA6XR79Gj5rUuQzfRq4TBIFYV560=.9289acec-415d-43a2-9632-3bcd0a449905@github.com>

On Tue, 14 Dec 2021 17:37:25 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Please review this small fix for bug JDK-827638.  The fix was tested by running Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, Mach5 tier 4 on Linux x64, and by building on linux-aarch64-zero and linux-x64-zero.
>> 
>> Thanks, Harold
>
> src/hotspot/share/runtime/arguments.cpp line 3999:
> 
>> 3997:     return JNI_ERR;
>> 3998:   }
>> 3999:   if ((UseSharedSpaces && xshare_auto_cmd_line) ||
> 
> xshare_auto_cmd_line is set with UseSharedSpaces (line 2715) so it should be OK to check only for itself.

Hi Yumin, thanks for looking at this.  If someone had a command line that contained the equivalent of -Xshare:auto ... -Xshare:off then, if only xshare_auto_cmd_line was checked, they would get the warning even though UseSharedSpaces was false.  So, I'd like to keep the existing check.  Thanks, Harold

-------------

PR: https://git.openjdk.java.net/jdk/pull/6835

From rriggs at openjdk.java.net  Tue Dec 14 19:58:35 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 14 Dec 2021 19:58:35 GMT
Subject: Integrated: 8278028: [test-library] Warnings cleanup of the test
 library
In-Reply-To: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
References: <EwvqWTQC4sgY5t4H-PZBzxjqnoVFfSRwutVj09VTpZY=.08d4e25b-2c0e-4fe1-b457-254a9a979014@github.com>
Message-ID: <w1VrX5JcIghP67qCkL0KR-IKADo6GDNrz318MXWaX7c=.20d3978d-043a-4492-a4dd-11b278555745@github.com>

On Wed, 1 Dec 2021 14:47:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Compilation warnings of the test library introduce noise in test output and should be addressed or suppressed. 
> Changes include:
>  - SuppressWarnings("deprecation") and SuppressWarnings("removal")
>  - Adding type parameters to Raw types
>  - Adding a hashCode method where equals was already present

This pull request has now been integrated.

Changeset: 03f647f4
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/03f647f4bb640bf5df1c461eec9860c7ac3eb076
Stats:     28 lines in 14 files changed: 10 ins; 1 del; 17 mod

8278028: [test-library] Warnings cleanup of the test library

Reviewed-by: dfuchs, mchung, naoto, lancea, lmesnik

-------------

PR: https://git.openjdk.java.net/jdk/pull/6638

From hseigel at openjdk.java.net  Tue Dec 14 20:39:05 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 14 Dec 2021 20:39:05 GMT
Subject: RFR: 8278638: Remove FLAG_IS_CMDLINE(UseSharedSpaces)
In-Reply-To: <s6XwnSm9_IZX-4Q3R6aQkzbf4-rqTjKHbH3e9gSUss8=.ad88724b-d5ff-4a4c-a547-352bb29ddbd9@github.com>
References: <s6XwnSm9_IZX-4Q3R6aQkzbf4-rqTjKHbH3e9gSUss8=.ad88724b-d5ff-4a4c-a547-352bb29ddbd9@github.com>
Message-ID: <G1q4ja6AzyuqisPRb5WFtHzzqZviGVfJCD4s1O-Fxxs=.c2c0c157-836e-4d4f-a18f-67bef00b9194@github.com>

On Tue, 14 Dec 2021 16:06:28 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix for bug JDK-827638.  The fix was tested by running Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, Mach5 tier 4 on Linux x64, and by building on linux-aarch64-zero and linux-x64-zero.
> 
> Thanks, Harold

Thanks Dan, Coleen, and Yumin for looking at this.  Pushing now to fix the build issues.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6835

From hseigel at openjdk.java.net  Tue Dec 14 20:39:06 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 14 Dec 2021 20:39:06 GMT
Subject: Integrated: 8278638: Remove FLAG_IS_CMDLINE(UseSharedSpaces)
In-Reply-To: <s6XwnSm9_IZX-4Q3R6aQkzbf4-rqTjKHbH3e9gSUss8=.ad88724b-d5ff-4a4c-a547-352bb29ddbd9@github.com>
References: <s6XwnSm9_IZX-4Q3R6aQkzbf4-rqTjKHbH3e9gSUss8=.ad88724b-d5ff-4a4c-a547-352bb29ddbd9@github.com>
Message-ID: <vp59-RfhAfLFgsSG7vbiq7HH6iGea2TQR8WIQaJy2uY=.31b11240-c5f8-4ed8-ab01-d7a72107f842@github.com>

On Tue, 14 Dec 2021 16:06:28 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix for bug JDK-827638.  The fix was tested by running Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, Mach5 tier 4 on Linux x64, and by building on linux-aarch64-zero and linux-x64-zero.
> 
> Thanks, Harold

This pull request has now been integrated.

Changeset: 98a8d446
Author:    Harold Seigel <hseigel at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/98a8d446b69fd84355731a8a3192cbd42671abb8
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8278638: Remove FLAG_IS_CMDLINE(UseSharedSpaces)

Reviewed-by: dcubed, coleenp

-------------

PR: https://git.openjdk.java.net/jdk/pull/6835

From dholmes at openjdk.java.net  Tue Dec 14 21:42:00 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 14 Dec 2021 21:42:00 GMT
Subject: RFR: 8278638: Remove FLAG_IS_CMDLINE(UseSharedSpaces)
In-Reply-To: <s6XwnSm9_IZX-4Q3R6aQkzbf4-rqTjKHbH3e9gSUss8=.ad88724b-d5ff-4a4c-a547-352bb29ddbd9@github.com>
References: <s6XwnSm9_IZX-4Q3R6aQkzbf4-rqTjKHbH3e9gSUss8=.ad88724b-d5ff-4a4c-a547-352bb29ddbd9@github.com>
Message-ID: <pNHdiKqfWHjWLWACv4VqXxCdI3QabdDpxDzMVS0VAaY=.fe3c1646-449c-4cf6-a2bb-8bf617a112e3@github.com>

On Tue, 14 Dec 2021 16:06:28 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix for bug JDK-827638.  The fix was tested by running Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, Mach5 tier 4 on Linux x64, and by building on linux-aarch64-zero and linux-x64-zero.
> 
> Thanks, Harold

Do we need to warn in this case? The original gave a warning because the user explicitly set UseSharedSpaces=true but CDS was not usable. But Xshare:auto just says "use CDS if you can", so if CDS is not available it is no big deal. The equivalent to the old code with be if the user set Xshare:on. Do we warn in other situations if Xshare:auto doesn't lead to sharing being enabled?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6835

From hseigel at openjdk.java.net  Tue Dec 14 21:53:11 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 14 Dec 2021 21:53:11 GMT
Subject: RFR: 8278638: Remove FLAG_IS_CMDLINE(UseSharedSpaces)
In-Reply-To: <s6XwnSm9_IZX-4Q3R6aQkzbf4-rqTjKHbH3e9gSUss8=.ad88724b-d5ff-4a4c-a547-352bb29ddbd9@github.com>
References: <s6XwnSm9_IZX-4Q3R6aQkzbf4-rqTjKHbH3e9gSUss8=.ad88724b-d5ff-4a4c-a547-352bb29ddbd9@github.com>
Message-ID: <mNEg931fdclFHOg29S2CUYgNX7nk1ehhu00dcIpEwsc=.9141f5f6-8a78-488c-93ef-594e10912d99@github.com>

On Tue, 14 Dec 2021 16:06:28 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix for bug JDK-827638.  The fix was tested by running Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, Mach5 tier 4 on Linux x64, and by building on linux-aarch64-zero and linux-x64-zero.
> 
> Thanks, Harold

If the user specified -Xshare:on then both UseSharedSpaces and RequireSharedSpaces would get set to TRUE (both before and after this change).  This would cause the JNI_ERR to be returned before the check if UseSharedSpaces was specified:


  if (DumpSharedSpaces || RequireSharedSpaces) {
    jio_fprintf(defaultStream::error_stream(),
      "Shared spaces are not supported in this VM\n");
    return JNI_ERR;
  }
           ...
  if ((UseSharedSpaces && FLAG_IS_CMDLINE(UseSharedSpaces)) ||
      log_is_enabled(Info, cds)) {
    warning("Shared spaces are not supported in this VM");
    FLAG_SET_DEFAULT(UseSharedSpaces, false);
    LogConfiguration::configure_stdout(LogLevel::Off, true, LOG_TAGS(cds));
  }
  no_shared_spaces("CDS Disabled");



So, I think that specifying -Xshare:auto is equivalent to the old -XX:+UseSharedSpace.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6835

From jiefu at openjdk.java.net  Tue Dec 14 22:54:10 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 14 Dec 2021 22:54:10 GMT
Subject: [jdk18] RFR: 8278758: runtime/BootstrapMethod/BSMCalledTwice.java
 fails with release VMs after JDK-8262134
In-Reply-To: <nWOJCuSzELbYqrowQniBObJnmTotP_rwyDq3u9MAPuA=.87704f7d-847f-43a5-aa1f-776b762ee4c5@github.com>
References: <ZreviSuHSofHh9h93qWs3jo-tjHnyDrumFC6ZLDffh8=.2e6dfb95-8924-4619-ba75-96ebe6020d44@github.com>
 <nWOJCuSzELbYqrowQniBObJnmTotP_rwyDq3u9MAPuA=.87704f7d-847f-43a5-aa1f-776b762ee4c5@github.com>
Message-ID: <RKMk2pT1KOlQ7U-ARR4nUW6Te61lhQ1iDSP3Mm9bvd0=.9167ad72-f08e-4764-850a-32ee86573916@github.com>

On Tue, 14 Dec 2021 15:50:52 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Thumbs up. This is a trivial fix.

Thanks @dcubed-ojdk .

-------------

PR: https://git.openjdk.java.net/jdk18/pull/21

From jiefu at openjdk.java.net  Tue Dec 14 22:54:11 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 14 Dec 2021 22:54:11 GMT
Subject: [jdk18] Integrated: 8278758:
 runtime/BootstrapMethod/BSMCalledTwice.java fails with release VMs after
 JDK-8262134
In-Reply-To: <ZreviSuHSofHh9h93qWs3jo-tjHnyDrumFC6ZLDffh8=.2e6dfb95-8924-4619-ba75-96ebe6020d44@github.com>
References: <ZreviSuHSofHh9h93qWs3jo-tjHnyDrumFC6ZLDffh8=.2e6dfb95-8924-4619-ba75-96ebe6020d44@github.com>
Message-ID: <-0C6lb1MgaeQ6Ryd2IdxfkEkvU-Rw_AbgiszTVQYAMo=.e2e312d2-8fe6-41a3-b263-8ec6f8d0f23d@github.com>

On Tue, 14 Dec 2021 11:18:54 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> runtime/BootstrapMethod/BSMCalledTwice.java fails with release VMs due to 'DeoptimizeALot' is develop after JDK-8262134.
> This is because `-XX:+DeoptimizeALot` and `-XX:+VerifyStack` are develop and are available only in debug version.
> 
> The fix only run the test config added by JDK-8262134 with debug VMs.
> 
> Thanks.
> Best regards,
> Jie

This pull request has now been integrated.

Changeset: f48a3e86
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/f48a3e86d0274912160f3c415f92741eefa1cb1d
Stats:     11 lines in 1 file changed: 9 ins; 1 del; 1 mod

8278758: runtime/BootstrapMethod/BSMCalledTwice.java fails with release VMs after JDK-8262134

Reviewed-by: dcubed

-------------

PR: https://git.openjdk.java.net/jdk18/pull/21

From ccheung at openjdk.java.net  Tue Dec 14 23:30:19 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Tue, 14 Dec 2021 23:30:19 GMT
Subject: RFR: 8278131: runtime/cds/appcds/dynamicArchive/* tests failing in
 loom repo
Message-ID: <dPGGxsZSwThTwo85qWFR4oz8_S0ih-2JNZyzWlFJkBg=.101bbb14-8898-437a-a693-fb6b5ff6fe2c@github.com>

A few dynamic archive CDS tests are failing in the loom repo due to more aggressive GC of code cache
which leads to unloading of some classes before being written into a dynamic CDS archive.

This change is to make the affected tests more reliable by ensuring the test classes are not unloaded
during dynamic CDS dump time.

Testing: Oracle CI tiers 1,2,4.

-------------

Commit messages:
 - fix trailing whitespace
 - 8278131: runtime/cds/appcds/dynamicArchive/* tests failing in loom repo

Changes: https://git.openjdk.java.net/jdk/pull/6843/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6843&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278131
  Stats: 57 lines in 9 files changed: 45 ins; 0 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6843.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6843/head:pull/6843

PR: https://git.openjdk.java.net/jdk/pull/6843

From dholmes at openjdk.java.net  Wed Dec 15 00:18:58 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 15 Dec 2021 00:18:58 GMT
Subject: RFR: 8268573: Remove expired flags in JDK 19
In-Reply-To: <nRGtoSFRMsR5eKkYbYM9JbA2ktz_EqmGQMGqn_1fDR0=.c5358a70-2056-4d51-8aa7-fa2b378f6ae7@github.com>
References: <1JzfCm_-QMikvfVrn1AdEFlYOS8KaPgEO2ZzaC3Smw8=.b43f45af-62e6-4561-a202-25c17a706d2f@github.com>
 <GNLZvSb33eky0qdMNp0Rn_SzY74kaUY_lzAHqnFZ6Lk=.fb875f95-dc02-4e11-a424-6b31f1fe3369@github.com>
 <AlbwfzgOLnDawkaJgRmuQ3wOidKbyQm5-y9ujNDSF80=.712a1a1f-72ee-4722-bcd3-5af7c161500e@github.com>
 <nRGtoSFRMsR5eKkYbYM9JbA2ktz_EqmGQMGqn_1fDR0=.c5358a70-2056-4d51-8aa7-fa2b378f6ae7@github.com>
Message-ID: <xAm4OS8eJztanUjBhmet0EygnST_SaKw5rAhTOpS_zA=.b27a708b-9356-4547-8190-42e2cec69f2c@github.com>

On Tue, 14 Dec 2021 13:11:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I don't understand the relevance of "uptake of JDK 17" - this change only affects 19. Anyone on 17 will get the deprecation warning as we deliberately deferred obsoleting the flag until JDK 18.
>
> It means the start scripts won't be usable with JDK 19+ builds so it complicates testing with those servers. Once these servers get to JDK 17 (actually JDK 15+) then they should be able to drop this option. I think the more general point is that we could be less aggressive about removing obsolete VM options when we know they are being used. In the past, the PermGen options were left as obsolete options for a long time because there were widely used.

The roadmap for the deprecation, obsoletion and expiration(removal) of UseBiasedLocking has already been extensively discussed and agreed upon - ref JDK-8256253. Anyone who decides they want to try JDK 19 and have not yet updated a startup script will now be forced to do so - I don't see that as a bad thing. Anyone who has been ignoring the obsoletion warning in 18 testing is just as likely to keep ignoring it in 19 so I don't think we need to keep kicking this can down the road.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6819

From dcubed at openjdk.java.net  Wed Dec 15 01:15:25 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 15 Dec 2021 01:15:25 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null
Message-ID: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>

RunThese24H sometimes times out with a couple of error msgs:
- "java.lang.management.ThreadInfo.getLockName()" is null
- ForkJoin common pool thread stuck

The '"java.lang.management.ThreadInfo.getLockName()" is null' error msg was
due to RunThese's use of an older JCK test suite which has since been fixed.

The 'ForkJoin common pool thread stuck' failure mode is likely due to a thread
spending a lot of time in ObjectSynchronizer::monitors_iterate() due to a
VM_ThreadDump::doit() call. I say "likely" because I've never been able to
reproduce this failure mode in testing outside of Mach5. With the Mach5
sightings, all we have are thread dumps and core files and not a live process.

The VM_ThreadDump::doit() call is trying to gather owned monitor information
for all threads in the system. I've seen sightings of this failure mode with > 2000
threads. I've also seen passing runs with > 1.7 million monitors on the in-use list.
Imagine searching a larger in-use list for > 2000 threads. It just doesn't scale.

-------------

Commit messages:
 - 8273107.open.exp.00

Changes: https://git.openjdk.java.net/jdk18/pull/25/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=25&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273107
  Stats: 187 lines in 8 files changed: 164 ins; 0 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/25.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/25/head:pull/25

PR: https://git.openjdk.java.net/jdk18/pull/25

From dcubed at openjdk.java.net  Wed Dec 15 01:15:25 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 15 Dec 2021 01:15:25 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null
In-Reply-To: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
Message-ID: <XNxbuBp9UK6GhJzVgiX70KDy1hddn-5lCfHjn0_BgyA=.e467492d-5cc3-4ecf-8ce2-6f5f8608d516@github.com>

On Tue, 14 Dec 2021 21:16:02 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> RunThese24H sometimes times out with a couple of error msgs:
> - "java.lang.management.ThreadInfo.getLockName()" is null
> - ForkJoin common pool thread stuck
> 
> The '"java.lang.management.ThreadInfo.getLockName()" is null' error msg was
> due to RunThese's use of an older JCK test suite which has since been fixed.
> 
> The 'ForkJoin common pool thread stuck' failure mode is likely due to a thread
> spending a lot of time in ObjectSynchronizer::monitors_iterate() due to a
> VM_ThreadDump::doit() call. I say "likely" because I've never been able to
> reproduce this failure mode in testing outside of Mach5. With the Mach5
> sightings, all we have are thread dumps and core files and not a live process.
> 
> The VM_ThreadDump::doit() call is trying to gather owned monitor information
> for all threads in the system. I've seen sightings of this failure mode with > 2000
> threads. I've also seen passing runs with > 1.7 million monitors on the in-use list.
> Imagine searching a larger in-use list for > 2000 threads. It just doesn't scale.

I have logging in place for all of the RunThese configs to gather a little
bit of 'monitorinflation' info. So far a new sighting has not happened,
but I'm hopeful that the stars will align sometime soon.

I have learned thru my own test jobs that a RunThese24H job doesn't
always include calls to VM_ThreadDump::doit() so it seems that there's
yet another factor in these RunThese24H failures.

The proposed solution in this patch is to call deflate_idle_monitors() from
VM_ThreadDump::doit() with a new and optional ObjectMonitorsHashtable
parameter. As deflate_idle_monitors() and deflate_monitor_list() do their
work, owned ObjectMonitors are added to the ObjectMonitorsHashtable
indexed by the owning JavaThread. After the deflate_idle_monitors() call
is finished VM_ThreadDump::doit() can find and return information about
the owned ObjectMonitors for each JavaThread without doing a linear walk
of the in-use monitor list for each JavaThread. A JavaThread* is used to
lookup a LinkedList in the ObjectMonitorsHashtable and if one exists, then
the JavaThread* owns all the ObjectMonitors on that LinkedList.

Also, the usual work done by deflate_idle_monitors() and deflate_monitor_list()
will serve to reduce the length of the in-use monitor list which makes the
in-use monitor list more efficient for other parts of the system.

This fix has been tested with Mach5 Tier[1-8]. I've also done some targeted
memory leak testing since ObjectMonitorsHashtable is new (see the bug
report for details). I've rebased the fix to the latest JDK18 repo as of 2021.12.14
mid-day and I'm doing some sanity checking with Mach5 Tier[1-3].

It would be good to hear from @dholmes-ora, @coleenp, @fisk and @robehn
since they were my reviewers on:

JDK-8253064 monitor list simplifications and getting rid of TSM
https://bugs.openjdk.java.net/browse/JDK-8253064

-------------

PR: https://git.openjdk.java.net/jdk18/pull/25

From coleenp at openjdk.java.net  Wed Dec 15 01:15:26 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 15 Dec 2021 01:15:26 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null
In-Reply-To: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
Message-ID: <nu8LbJxHbVrxUj8VFjBq4-eysW0zbHQkxzB7N2lC5FU=.50479592-394f-4f05-9b01-8ed1765f79a4@github.com>

On Tue, 14 Dec 2021 21:16:02 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> RunThese24H sometimes times out with a couple of error msgs:
> - "java.lang.management.ThreadInfo.getLockName()" is null
> - ForkJoin common pool thread stuck
> 
> The '"java.lang.management.ThreadInfo.getLockName()" is null' error msg was
> due to RunThese's use of an older JCK test suite which has since been fixed.
> 
> The 'ForkJoin common pool thread stuck' failure mode is likely due to a thread
> spending a lot of time in ObjectSynchronizer::monitors_iterate() due to a
> VM_ThreadDump::doit() call. I say "likely" because I've never been able to
> reproduce this failure mode in testing outside of Mach5. With the Mach5
> sightings, all we have are thread dumps and core files and not a live process.
> 
> The VM_ThreadDump::doit() call is trying to gather owned monitor information
> for all threads in the system. I've seen sightings of this failure mode with > 2000
> threads. I've also seen passing runs with > 1.7 million monitors on the in-use list.
> Imagine searching a larger in-use list for > 2000 threads. It just doesn't scale.

This looks good to me.  You solved both the problem of the very long monitor list and the per-thread iteration too. I like it!

-------------

PR: https://git.openjdk.java.net/jdk18/pull/25

From dcubed at openjdk.java.net  Wed Dec 15 01:15:27 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 15 Dec 2021 01:15:27 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null
In-Reply-To: <nu8LbJxHbVrxUj8VFjBq4-eysW0zbHQkxzB7N2lC5FU=.50479592-394f-4f05-9b01-8ed1765f79a4@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
 <nu8LbJxHbVrxUj8VFjBq4-eysW0zbHQkxzB7N2lC5FU=.50479592-394f-4f05-9b01-8ed1765f79a4@github.com>
Message-ID: <loDDC4vybtAlmBnGDTiiQ_F6GdBqbeFlTLQa1DsbLpM=.8a978ad5-6992-477b-ab4a-1612e4b75a8a@github.com>

On Tue, 14 Dec 2021 22:52:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> RunThese24H sometimes times out with a couple of error msgs:
>> - "java.lang.management.ThreadInfo.getLockName()" is null
>> - ForkJoin common pool thread stuck
>> 
>> The '"java.lang.management.ThreadInfo.getLockName()" is null' error msg was
>> due to RunThese's use of an older JCK test suite which has since been fixed.
>> 
>> The 'ForkJoin common pool thread stuck' failure mode is likely due to a thread
>> spending a lot of time in ObjectSynchronizer::monitors_iterate() due to a
>> VM_ThreadDump::doit() call. I say "likely" because I've never been able to
>> reproduce this failure mode in testing outside of Mach5. With the Mach5
>> sightings, all we have are thread dumps and core files and not a live process.
>> 
>> The VM_ThreadDump::doit() call is trying to gather owned monitor information
>> for all threads in the system. I've seen sightings of this failure mode with > 2000
>> threads. I've also seen passing runs with > 1.7 million monitors on the in-use list.
>> Imagine searching a larger in-use list for > 2000 threads. It just doesn't scale.
>
> This looks good to me.  You solved both the problem of the very long monitor list and the per-thread iteration too. I like it!

@coleenp - Thanks for the draft review! It's now officially ready...

-------------

PR: https://git.openjdk.java.net/jdk18/pull/25

From dholmes at openjdk.java.net  Wed Dec 15 01:43:58 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 15 Dec 2021 01:43:58 GMT
Subject: RFR: 8278131: runtime/cds/appcds/dynamicArchive/* tests failing in
 loom repo
In-Reply-To: <dPGGxsZSwThTwo85qWFR4oz8_S0ih-2JNZyzWlFJkBg=.101bbb14-8898-437a-a693-fb6b5ff6fe2c@github.com>
References: <dPGGxsZSwThTwo85qWFR4oz8_S0ih-2JNZyzWlFJkBg=.101bbb14-8898-437a-a693-fb6b5ff6fe2c@github.com>
Message-ID: <pI5w9XVHTpCrJNlJC8j0c7RgFjumZWW_q8TFfho1uqU=.c6044e5e-4234-4010-8155-cc7a50e244c7@github.com>

On Tue, 14 Dec 2021 23:14:38 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> A few dynamic archive CDS tests are failing in the loom repo due to more aggressive GC of code cache
> which leads to unloading of some classes before being written into a dynamic CDS archive.
> 
> This change is to make the affected tests more reliable by ensuring the test classes are not unloaded
> during dynamic CDS dump time.
> 
> Testing: Oracle CI tiers 1,2,4.

Sorry but this isn't making any sense to me. You can't GC a class until its classloader becomes unreachable - at which point the classloader and all its loaded classes become unreachable together. So you can't keep a class alive by storing a reference to it in a static field of a class loaded by the same classloader - it was already kept alive.

David

-------------

PR: https://git.openjdk.java.net/jdk/pull/6843

From dholmes at openjdk.java.net  Wed Dec 15 02:38:08 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 15 Dec 2021 02:38:08 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null
In-Reply-To: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
Message-ID: <m9Swza4RGmWKBctK1Dr6Q-lR-30rk8N0OnARQHGRqVE=.192c810f-b171-43fb-8c38-2defe30dc913@github.com>

On Tue, 14 Dec 2021 21:16:02 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> RunThese24H sometimes times out with a couple of error msgs:
> - "java.lang.management.ThreadInfo.getLockName()" is null
> - ForkJoin common pool thread stuck
> 
> The '"java.lang.management.ThreadInfo.getLockName()" is null' error msg was
> due to RunThese's use of an older JCK test suite which has since been fixed.
> 
> The 'ForkJoin common pool thread stuck' failure mode is likely due to a thread
> spending a lot of time in ObjectSynchronizer::monitors_iterate() due to a
> VM_ThreadDump::doit() call. I say "likely" because I've never been able to
> reproduce this failure mode in testing outside of Mach5. With the Mach5
> sightings, all we have are thread dumps and core files and not a live process.
> 
> The VM_ThreadDump::doit() call is trying to gather owned monitor information
> for all threads in the system. I've seen sightings of this failure mode with > 2000
> threads. I've also seen passing runs with > 1.7 million monitors on the in-use list.
> Imagine searching a larger in-use list for > 2000 threads. It just doesn't scale.

src/hotspot/share/runtime/synchronizer.cpp line 62:

> 60: class CleanupObjectMonitorsHashtable: StackObj {
> 61:  public:
> 62:   bool do_entry(JavaThread*& key, ObjectMonitorsHashtable::PtrList*& list) {

I don't see this being called by anything ???

-------------

PR: https://git.openjdk.java.net/jdk18/pull/25

From cjplummer at openjdk.java.net  Wed Dec 15 03:16:17 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 15 Dec 2021 03:16:17 GMT
Subject: RFR: 8276982: VM.class_hierarchy jcmd help output and man page text
 needs clarifications/improvements
Message-ID: <c2IkwHnl-Ktgth7fGN-f7MrHogrJoaU23WSQITNzxek=.1a559555-ac71-4d9d-a7da-cf31694cb6bb@github.com>

Clarify the help output for VM.class_hierarchy. The old jcmd help output was misleading, and because of this got translated incorrectly for the man page.

-------------

Commit messages:
 - Fix VM.class_hierarchy help output and man page.

Changes: https://git.openjdk.java.net/jdk/pull/6845/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6845&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276982
  Stats: 6 lines in 2 files changed: 1 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6845.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6845/head:pull/6845

PR: https://git.openjdk.java.net/jdk/pull/6845

From xliu at openjdk.java.net  Wed Dec 15 03:29:00 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 15 Dec 2021 03:29:00 GMT
Subject: RFR: 8267517: async logging for stdout and stderr
In-Reply-To: <w0aDpgQFJScFf8yb7YQgdwDzm5PMcYm7M0x3AtYy2u8=.39bc3371-1df0-4a20-9c2f-ce4444d4b1e6@github.com>
References: <Nv1V5JHKgJh0NtqijGmWmI9Kh2VgDxgDIOAdfCtOavA=.503f41c2-a5d1-4a25-ab90-00252814a9bf@github.com>
 <w0aDpgQFJScFf8yb7YQgdwDzm5PMcYm7M0x3AtYy2u8=.39bc3371-1df0-4a20-9c2f-ce4444d4b1e6@github.com>
Message-ID: <kiEozTS09lXx-HroZOFfmIChG3iRngXZLzrHmlIS2HM=.e1dcbfbb-d815-41f9-a588-6cdce7b46493@github.com>

On Tue, 14 Dec 2021 02:01:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi Xin,
> 
> I took a look at this but to be honest I couldn't work out what most of the changes actually had to do with the topic of adding async logging for stdout/stderr. IIUC the change from `LogFileOutput` to `LogFileStreamOutput` in the API now enables it to be used for stdout/stderr - right? But most of the changes seemed to relate to log file rotation which doesn't even apply to stdout/stderr! What has force_rotation got to do with things?
> 
> David

Sorry, this is my fault. This patch incorporates with JDK-8275083. They are so intertwined that I can't split them. 
So far, I fail to measure any meaningful performance gain from JDK-8275083, so let me refactor the code and remove JDK-8275083.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6132

From dcubed at openjdk.java.net  Wed Dec 15 03:34:14 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 15 Dec 2021 03:34:14 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null
In-Reply-To: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
Message-ID: <IlATkE0oJ7LmVWOeL34LYfplTsCTJYaLXIKw3U3CGYQ=.b5234169-cbfe-4af3-9492-fd4a0bb855cc@github.com>

On Tue, 14 Dec 2021 21:16:02 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> RunThese24H sometimes times out with a couple of error msgs:
> - "java.lang.management.ThreadInfo.getLockName()" is null
> - ForkJoin common pool thread stuck
> 
> The '"java.lang.management.ThreadInfo.getLockName()" is null' error msg was
> due to RunThese's use of an older JCK test suite which has since been fixed.
> 
> The 'ForkJoin common pool thread stuck' failure mode is likely due to a thread
> spending a lot of time in ObjectSynchronizer::monitors_iterate() due to a
> VM_ThreadDump::doit() call. I say "likely" because I've never been able to
> reproduce this failure mode in testing outside of Mach5. With the Mach5
> sightings, all we have are thread dumps and core files and not a live process.
> 
> The VM_ThreadDump::doit() call is trying to gather owned monitor information
> for all threads in the system. I've seen sightings of this failure mode with > 2000
> threads. I've also seen passing runs with > 1.7 million monitors on the in-use list.
> Imagine searching a larger in-use list for > 2000 threads. It just doesn't scale.

@dholmes-ora - Thanks for reviewing!

-------------

PR: https://git.openjdk.java.net/jdk18/pull/25

From dcubed at openjdk.java.net  Wed Dec 15 03:34:14 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 15 Dec 2021 03:34:14 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null
In-Reply-To: <m9Swza4RGmWKBctK1Dr6Q-lR-30rk8N0OnARQHGRqVE=.192c810f-b171-43fb-8c38-2defe30dc913@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
 <m9Swza4RGmWKBctK1Dr6Q-lR-30rk8N0OnARQHGRqVE=.192c810f-b171-43fb-8c38-2defe30dc913@github.com>
Message-ID: <DwZirNI75MGJVPwbxQ2xDd8pmQn0TxfyedWTaiq_SpI=.16722216-5e7a-4bff-b699-9f734b5b9316@github.com>

On Wed, 15 Dec 2021 02:34:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> RunThese24H sometimes times out with a couple of error msgs:
>> - "java.lang.management.ThreadInfo.getLockName()" is null
>> - ForkJoin common pool thread stuck
>> 
>> The '"java.lang.management.ThreadInfo.getLockName()" is null' error msg was
>> due to RunThese's use of an older JCK test suite which has since been fixed.
>> 
>> The 'ForkJoin common pool thread stuck' failure mode is likely due to a thread
>> spending a lot of time in ObjectSynchronizer::monitors_iterate() due to a
>> VM_ThreadDump::doit() call. I say "likely" because I've never been able to
>> reproduce this failure mode in testing outside of Mach5. With the Mach5
>> sightings, all we have are thread dumps and core files and not a live process.
>> 
>> The VM_ThreadDump::doit() call is trying to gather owned monitor information
>> for all threads in the system. I've seen sightings of this failure mode with > 2000
>> threads. I've also seen passing runs with > 1.7 million monitors on the in-use list.
>> Imagine searching a larger in-use list for > 2000 threads. It just doesn't scale.
>
> src/hotspot/share/runtime/synchronizer.cpp line 62:
> 
>> 60: class CleanupObjectMonitorsHashtable: StackObj {
>> 61:  public:
>> 62:   bool do_entry(JavaThread*& key, ObjectMonitorsHashtable::PtrList*& list) {
> 
> I don't see this being called by anything ???

See L71 below:   _ptrs->unlink(&cleanup);  // cleanup the LinkedLists
That passes the cleanup object to ResourceHashtable::unlink()
function which calls the do_entry() function in the cleanup object.

-------------

PR: https://git.openjdk.java.net/jdk18/pull/25

From dholmes at openjdk.java.net  Wed Dec 15 04:09:08 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 15 Dec 2021 04:09:08 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null
In-Reply-To: <DwZirNI75MGJVPwbxQ2xDd8pmQn0TxfyedWTaiq_SpI=.16722216-5e7a-4bff-b699-9f734b5b9316@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
 <m9Swza4RGmWKBctK1Dr6Q-lR-30rk8N0OnARQHGRqVE=.192c810f-b171-43fb-8c38-2defe30dc913@github.com>
 <DwZirNI75MGJVPwbxQ2xDd8pmQn0TxfyedWTaiq_SpI=.16722216-5e7a-4bff-b699-9f734b5b9316@github.com>
Message-ID: <BvSsdyWQUD7r7j9Yo9F8GyoEaCrjY5shQmC-zqss3VU=.b82640ee-cb1e-452d-bcb5-7714ad2929c7@github.com>

On Wed, 15 Dec 2021 03:30:34 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> src/hotspot/share/runtime/synchronizer.cpp line 62:
>> 
>>> 60: class CleanupObjectMonitorsHashtable: StackObj {
>>> 61:  public:
>>> 62:   bool do_entry(JavaThread*& key, ObjectMonitorsHashtable::PtrList*& list) {
>> 
>> I don't see this being called by anything ???
>
> See L71 below:   _ptrs->unlink(&cleanup);  // cleanup the LinkedLists
> That passes the cleanup object to ResourceHashtable::unlink()
> function which calls the do_entry() function in the cleanup object.

Ah I see (well I don't really see as this is very obscure). I would have expected `CleanupObjectMonitorsHashtable` to be a subtype of something that I could then see is used by the ResourceHashtable. I'm going to guess that there is some template usage here that ensures the passed in object has the right API even if there is no subtyping relationship. Hard to see these connections at a distance.

To be clear not a review as I don't understand our Hashtable's enough to make much sense of what is actually happening here.

-------------

PR: https://git.openjdk.java.net/jdk18/pull/25

From iklam at openjdk.java.net  Wed Dec 15 04:38:03 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 15 Dec 2021 04:38:03 GMT
Subject: RFR: 8278131: runtime/cds/appcds/dynamicArchive/* tests failing in
 loom repo
In-Reply-To: <dPGGxsZSwThTwo85qWFR4oz8_S0ih-2JNZyzWlFJkBg=.101bbb14-8898-437a-a693-fb6b5ff6fe2c@github.com>
References: <dPGGxsZSwThTwo85qWFR4oz8_S0ih-2JNZyzWlFJkBg=.101bbb14-8898-437a-a693-fb6b5ff6fe2c@github.com>
Message-ID: <CoJ_aKzZQ2tTb-1e3sNV00-sMo4riEQXecD1rEYBJPM=.3cae9889-4959-4727-bfde-061421649cb9@github.com>

On Tue, 14 Dec 2021 23:14:38 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> A few dynamic archive CDS tests are failing in the loom repo due to more aggressive GC of code cache
> which leads to unloading of some classes before being written into a dynamic CDS archive.
> 
> This change is to make the affected tests more reliable by ensuring the test classes are not unloaded
> during dynamic CDS dump time.
> 
> Testing: Oracle CI tiers 1,2,4.

LGTM

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6843

From iklam at openjdk.java.net  Wed Dec 15 04:38:04 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 15 Dec 2021 04:38:04 GMT
Subject: RFR: 8278131: runtime/cds/appcds/dynamicArchive/* tests failing in
 loom repo
In-Reply-To: <pI5w9XVHTpCrJNlJC8j0c7RgFjumZWW_q8TFfho1uqU=.c6044e5e-4234-4010-8155-cc7a50e244c7@github.com>
References: <dPGGxsZSwThTwo85qWFR4oz8_S0ih-2JNZyzWlFJkBg=.101bbb14-8898-437a-a693-fb6b5ff6fe2c@github.com>
 <pI5w9XVHTpCrJNlJC8j0c7RgFjumZWW_q8TFfho1uqU=.c6044e5e-4234-4010-8155-cc7a50e244c7@github.com>
Message-ID: <ng857wISz3L81sE0NFr1W9PWLKHtdHS1HsxOossg0Bk=.e7722c23-a54d-4991-b0d2-44b2301444e0@github.com>

On Wed, 15 Dec 2021 01:40:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sorry but this isn't making any sense to me. You can't GC a class until its classloader becomes unreachable - at which point the classloader and all its loaded classes become unreachable together. So you can't keep a class alive by storing a reference to it in a static field of a class loaded by the same classloader - it was already kept alive.
> 
> David

Hi David,


        URLClassLoader urlClassLoader =
            new URLClassLoader("HelloClassLoader", urls, null);
        Class c = Class.forName(className, true, urlClassLoader);
+       if (keepAlive) {
+           keptC = c;
+       }

The class `c` is defined by a custom class loader (`urlClassLoader`). Before this patch, when `urlClassLoader` and `c` fall out of scope, this class becomes eligible for garbage collection.

The class that runs the above code (`HelloUnload`) is loaded by the app class loader. By referencing `c` in a static field of `HelloUnload`, we make sure `c` is never unloaded.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6843

From dholmes at openjdk.java.net  Wed Dec 15 05:30:57 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 15 Dec 2021 05:30:57 GMT
Subject: RFR: 8278131: runtime/cds/appcds/dynamicArchive/* tests failing in
 loom repo
In-Reply-To: <dPGGxsZSwThTwo85qWFR4oz8_S0ih-2JNZyzWlFJkBg=.101bbb14-8898-437a-a693-fb6b5ff6fe2c@github.com>
References: <dPGGxsZSwThTwo85qWFR4oz8_S0ih-2JNZyzWlFJkBg=.101bbb14-8898-437a-a693-fb6b5ff6fe2c@github.com>
Message-ID: <-z8bbD6miRc-sxR8ChxpNdmAvCItIqy2irsoR0jvPtU=.54db43fe-e4af-4dd8-9cbe-6a0bd6c0fc89@github.com>

On Tue, 14 Dec 2021 23:14:38 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> A few dynamic archive CDS tests are failing in the loom repo due to more aggressive GC of code cache
> which leads to unloading of some classes before being written into a dynamic CDS archive.
> 
> This change is to make the affected tests more reliable by ensuring the test classes are not unloaded
> during dynamic CDS dump time.
> 
> Testing: Oracle CI tiers 1,2,4.

Sorry should have been more specific. I'm looking at  test/hotspot/jtreg/runtime/HiddenClasses/InstantiateHiddenClass.java where the hidden class is stored in the new field.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6843

From dholmes at openjdk.java.net  Wed Dec 15 05:46:57 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 15 Dec 2021 05:46:57 GMT
Subject: RFR: 8278131: runtime/cds/appcds/dynamicArchive/* tests failing in
 loom repo
In-Reply-To: <-z8bbD6miRc-sxR8ChxpNdmAvCItIqy2irsoR0jvPtU=.54db43fe-e4af-4dd8-9cbe-6a0bd6c0fc89@github.com>
References: <dPGGxsZSwThTwo85qWFR4oz8_S0ih-2JNZyzWlFJkBg=.101bbb14-8898-437a-a693-fb6b5ff6fe2c@github.com>
 <-z8bbD6miRc-sxR8ChxpNdmAvCItIqy2irsoR0jvPtU=.54db43fe-e4af-4dd8-9cbe-6a0bd6c0fc89@github.com>
Message-ID: <NaIFG9tIaCsNIF3LbyqbJZY3d4Reu3W0IWvQBVtOePE=.756e0bf6-12f1-4065-9315-a63c913c5b5f@github.com>

On Wed, 15 Dec 2021 05:27:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sorry should have been more specific. I'm looking at test/hotspot/jtreg/runtime/HiddenClasses/InstantiateHiddenClass.java where the hidden class is stored in the new field.

Okay so that test has nothing to do with dynamic dumping. But if you wanted to keep the hidden classes alive you create with STRONG so they are strongly associated with their classloader. But I can't see why that test would need that anyway.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6843

From stuefe at openjdk.java.net  Wed Dec 15 05:56:58 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 15 Dec 2021 05:56:58 GMT
Subject: RFR: 8276982: VM.class_hierarchy jcmd help output and man page
 text needs clarifications/improvements
In-Reply-To: <c2IkwHnl-Ktgth7fGN-f7MrHogrJoaU23WSQITNzxek=.1a559555-ac71-4d9d-a7da-cf31694cb6bb@github.com>
References: <c2IkwHnl-Ktgth7fGN-f7MrHogrJoaU23WSQITNzxek=.1a559555-ac71-4d9d-a7da-cf31694cb6bb@github.com>
Message-ID: <tXF_qlAKCubPFW7iZuSftcQXYwqzGpWwpCqiCdfd9gk=.c853573e-18a3-4b51-bc74-e2098fe8f7e8@github.com>

On Wed, 15 Dec 2021 03:08:40 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Clarify the help output for VM.class_hierarchy. The old jcmd help output was misleading, and because of this got translated incorrectly for the man page.

Looks good and trivial.

Thanks, Thomas

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6845

From dholmes at openjdk.java.net  Wed Dec 15 06:54:58 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 15 Dec 2021 06:54:58 GMT
Subject: RFR: 8276982: VM.class_hierarchy jcmd help output and man page
 text needs clarifications/improvements
In-Reply-To: <c2IkwHnl-Ktgth7fGN-f7MrHogrJoaU23WSQITNzxek=.1a559555-ac71-4d9d-a7da-cf31694cb6bb@github.com>
References: <c2IkwHnl-Ktgth7fGN-f7MrHogrJoaU23WSQITNzxek=.1a559555-ac71-4d9d-a7da-cf31694cb6bb@github.com>
Message-ID: <FwCgMlNkrHgyaCcS0_moaPgIA7VTFUvWOqKACtay85A=.f071979e-b622-478c-9691-f393f5fedb5b@github.com>

On Wed, 15 Dec 2021 03:08:40 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Clarify the help output for VM.class_hierarchy. The old jcmd help output was misleading, and because of this got translated incorrectly for the man page.

LGTM 2.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6845

From sspitsyn at openjdk.java.net  Wed Dec 15 07:33:00 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 15 Dec 2021 07:33:00 GMT
Subject: RFR: 8276982: VM.class_hierarchy jcmd help output and man page
 text needs clarifications/improvements
In-Reply-To: <c2IkwHnl-Ktgth7fGN-f7MrHogrJoaU23WSQITNzxek=.1a559555-ac71-4d9d-a7da-cf31694cb6bb@github.com>
References: <c2IkwHnl-Ktgth7fGN-f7MrHogrJoaU23WSQITNzxek=.1a559555-ac71-4d9d-a7da-cf31694cb6bb@github.com>
Message-ID: <v_o7Vt8pWGDn6shWo7Tv3wX9L-hjjDTU4AiJX_Ty7nY=.df776209-5aae-472c-8370-04a603a40718@github.com>

On Wed, 15 Dec 2021 03:08:40 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Clarify the help output for VM.class_hierarchy. The old jcmd help output was misleading, and because of this got translated incorrectly for the man page.

Marked as reviewed by sspitsyn (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6845

From alanb at openjdk.java.net  Wed Dec 15 07:35:01 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 15 Dec 2021 07:35:01 GMT
Subject: RFR: 8268573: Remove expired flags in JDK 19
In-Reply-To: <xAm4OS8eJztanUjBhmet0EygnST_SaKw5rAhTOpS_zA=.b27a708b-9356-4547-8190-42e2cec69f2c@github.com>
References: <1JzfCm_-QMikvfVrn1AdEFlYOS8KaPgEO2ZzaC3Smw8=.b43f45af-62e6-4561-a202-25c17a706d2f@github.com>
 <GNLZvSb33eky0qdMNp0Rn_SzY74kaUY_lzAHqnFZ6Lk=.fb875f95-dc02-4e11-a424-6b31f1fe3369@github.com>
 <AlbwfzgOLnDawkaJgRmuQ3wOidKbyQm5-y9ujNDSF80=.712a1a1f-72ee-4722-bcd3-5af7c161500e@github.com>
 <nRGtoSFRMsR5eKkYbYM9JbA2ktz_EqmGQMGqn_1fDR0=.c5358a70-2056-4d51-8aa7-fa2b378f6ae7@github.com>
 <xAm4OS8eJztanUjBhmet0EygnST_SaKw5rAhTOpS_zA=.b27a708b-9356-4547-8190-42e2cec69f2c@github.com>
Message-ID: <8Tiy7IDR9DiXZ272dLS9Rclaqm7OV6I6WZKoQSFAQE4=.afa211d1-5a2f-4726-82bf-bc2b5e93d3d3@github.com>

On Wed, 15 Dec 2021 00:15:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The roadmap for the deprecation, obsoletion and expiration(removal) of UseBiasedLocking has already been extensively discussed and agreed upon - ref JDK-8256253. Anyone who decides they want to try JDK 19 and have not yet updated a startup script will now be forced to do so - I don't see that as a bad thing. Anyone who has been ignoring the obsoletion warning in 18 testing is just as likely to keep ignoring it in 19 so I don't think we need to keep kicking this can down the road.

The roadmap is clear, no issue there. I'm just saying that aggressive removal of obsolete options that are used in important servers is a PITA for testing. It's important to be able to run as many existing applications as possible with the JDK 19 EA builds, we just make it harder when it requires digging into scripts and configuration to remove options that would prevent the VM from starting.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6819

From alanb at openjdk.java.net  Wed Dec 15 07:43:58 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 15 Dec 2021 07:43:58 GMT
Subject: RFR: 8278131: runtime/cds/appcds/dynamicArchive/* tests failing in
 loom repo
In-Reply-To: <ng857wISz3L81sE0NFr1W9PWLKHtdHS1HsxOossg0Bk=.e7722c23-a54d-4991-b0d2-44b2301444e0@github.com>
References: <dPGGxsZSwThTwo85qWFR4oz8_S0ih-2JNZyzWlFJkBg=.101bbb14-8898-437a-a693-fb6b5ff6fe2c@github.com>
 <pI5w9XVHTpCrJNlJC8j0c7RgFjumZWW_q8TFfho1uqU=.c6044e5e-4234-4010-8155-cc7a50e244c7@github.com>
 <ng857wISz3L81sE0NFr1W9PWLKHtdHS1HsxOossg0Bk=.e7722c23-a54d-4991-b0d2-44b2301444e0@github.com>
Message-ID: <OkkdOv2F7oO0pojMnoy5Z_7ua-owdi5omh_RhnZPSlM=.4748e40c-50e3-4f4a-b70e-88f7f0966199@github.com>

On Wed, 15 Dec 2021 04:34:23 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The class `c` is defined by a custom class loader (`urlClassLoader`). Before this patch, when `urlClassLoader` and `c` fall out of scope, this class becomes eligible for garbage collection.

Using a static field in this context is okay. Another useful approach would be use Reference.reachabilityFence at the end of the method to keep c alive.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6843

From rehn at openjdk.java.net  Wed Dec 15 08:45:09 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 15 Dec 2021 08:45:09 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null
In-Reply-To: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
Message-ID: <dG3-urCe2g2-F3KIdlJG7banTn17ovSO0Q7OpHFILHc=.c5baa018-6fb4-4364-84a5-98abc6fee0ff@github.com>

On Tue, 14 Dec 2021 21:16:02 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> RunThese24H sometimes times out with a couple of error msgs:
> - "java.lang.management.ThreadInfo.getLockName()" is null
> - ForkJoin common pool thread stuck
> 
> The '"java.lang.management.ThreadInfo.getLockName()" is null' error msg was
> due to RunThese's use of an older JCK test suite which has since been fixed.
> 
> The 'ForkJoin common pool thread stuck' failure mode is likely due to a thread
> spending a lot of time in ObjectSynchronizer::monitors_iterate() due to a
> VM_ThreadDump::doit() call. I say "likely" because I've never been able to
> reproduce this failure mode in testing outside of Mach5. With the Mach5
> sightings, all we have are thread dumps and core files and not a live process.
> 
> The VM_ThreadDump::doit() call is trying to gather owned monitor information
> for all threads in the system. I've seen sightings of this failure mode with > 2000
> threads. I've also seen passing runs with > 1.7 million monitors on the in-use list.
> Imagine searching a larger in-use list for > 2000 threads. It just doesn't scale.

Marked as reviewed by rehn (Reviewer).

src/hotspot/share/runtime/vmOperations.cpp line 283:

> 281: 
> 282:   ObjectMonitorsHashtable table;
> 283:   ObjectMonitorsHashtable* tablep = nullptr;

It looks like you can remove this pointer.
ThreadStackTrace::dump_stack_at_safepoint also looks at "with_locked_monitors", if false it ignores the table.
So there should not be any need to pass in null.

src/hotspot/share/services/threadService.cpp line 692:

> 690:       ObjectMonitorsHashtable::PtrList* list = table->get_entry(_thread);
> 691:       if (list != nullptr) {
> 692:         ObjectSynchronizer::monitors_iterate(&imc, list, _thread);

The InflatedMonitorsClosure walks the stack until object is found with this method:
ThreadStackTrace::is_owned_monitor_on_stack(oop object)
for every object...

If you instead just collect all locks on stack with one pass you don't have to walk the stack over and over, which should be major speedup.

-------------

PR: https://git.openjdk.java.net/jdk18/pull/25

From dholmes at openjdk.java.net  Wed Dec 15 09:59:59 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 15 Dec 2021 09:59:59 GMT
Subject: RFR: 8268573: Remove expired flags in JDK 19
In-Reply-To: <8Tiy7IDR9DiXZ272dLS9Rclaqm7OV6I6WZKoQSFAQE4=.afa211d1-5a2f-4726-82bf-bc2b5e93d3d3@github.com>
References: <1JzfCm_-QMikvfVrn1AdEFlYOS8KaPgEO2ZzaC3Smw8=.b43f45af-62e6-4561-a202-25c17a706d2f@github.com>
 <GNLZvSb33eky0qdMNp0Rn_SzY74kaUY_lzAHqnFZ6Lk=.fb875f95-dc02-4e11-a424-6b31f1fe3369@github.com>
 <AlbwfzgOLnDawkaJgRmuQ3wOidKbyQm5-y9ujNDSF80=.712a1a1f-72ee-4722-bcd3-5af7c161500e@github.com>
 <nRGtoSFRMsR5eKkYbYM9JbA2ktz_EqmGQMGqn_1fDR0=.c5358a70-2056-4d51-8aa7-fa2b378f6ae7@github.com>
 <xAm4OS8eJztanUjBhmet0EygnST_SaKw5rAhTOpS_zA=.b27a708b-9356-4547-8190-42e2cec69f2c@github.com>
 <8Tiy7IDR9DiXZ272dLS9Rclaqm7OV6I6WZKoQSFAQE4=.afa211d1-5a2f-4726-82bf-bc2b5e93d3d3@github.com>
Message-ID: <gid5G2ZXMZC4Jc9mR6PJ0lTZV5Ul8xmW_EkT_8sh5T0=.701006f5-a1f5-4791-9465-251784a5ec20@github.com>

On Wed, 15 Dec 2021 07:31:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The roadmap for the deprecation, obsoletion and expiration(removal) of UseBiasedLocking has already been extensively discussed and agreed upon - ref JDK-8256253. Anyone who decides they want to try JDK 19 and have not yet updated a startup script will now be forced to do so - I don't see that as a bad thing. Anyone who has been ignoring the obsoletion warning in 18 testing is just as likely to keep ignoring it in 19 so I don't think we need to keep kicking this can down the road.
>
>> The roadmap for the deprecation, obsoletion and expiration(removal) of UseBiasedLocking has already been extensively discussed and agreed upon - ref JDK-8256253. Anyone who decides they want to try JDK 19 and have not yet updated a startup script will now be forced to do so - I don't see that as a bad thing. Anyone who has been ignoring the obsoletion warning in 18 testing is just as likely to keep ignoring it in 19 so I don't think we need to keep kicking this can down the road.
> 
> The roadmap is clear, no issue there. I'm just saying that aggressive removal of obsolete options that are used in important servers is a PITA for testing. It's important to be able to run as many existing applications as possible with the JDK 19 EA builds, we just make it harder when it requires digging into scripts and configuration to remove options that would prevent the VM from starting.

Sorry but unless there are issues filed to have those scripts updated then what you say will apply the same in 6 months time. And if there are issues filed then they should be fixed now. So I don't see any point in changing the roadmap.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6819

From coleenp at openjdk.java.net  Wed Dec 15 14:06:01 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 15 Dec 2021 14:06:01 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null
In-Reply-To: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
Message-ID: <fHT_HAOzTfSWkxjybH0U6TRqPuZIdZOHd-dPRsp6Ekw=.fb38663f-6e20-41d9-8f41-bd93a938827f@github.com>

On Tue, 14 Dec 2021 21:16:02 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> RunThese24H sometimes times out with a couple of error msgs:
> - "java.lang.management.ThreadInfo.getLockName()" is null
> - ForkJoin common pool thread stuck
> 
> The '"java.lang.management.ThreadInfo.getLockName()" is null' error msg was
> due to RunThese's use of an older JCK test suite which has since been fixed.
> 
> The 'ForkJoin common pool thread stuck' failure mode is likely due to a thread
> spending a lot of time in ObjectSynchronizer::monitors_iterate() due to a
> VM_ThreadDump::doit() call. I say "likely" because I've never been able to
> reproduce this failure mode in testing outside of Mach5. With the Mach5
> sightings, all we have are thread dumps and core files and not a live process.
> 
> The VM_ThreadDump::doit() call is trying to gather owned monitor information
> for all threads in the system. I've seen sightings of this failure mode with > 2000
> threads. I've also seen passing runs with > 1.7 million monitors on the in-use list.
> Imagine searching a larger in-use list for > 2000 threads. It just doesn't scale.

This looks good.

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/25

From coleenp at openjdk.java.net  Wed Dec 15 14:06:02 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 15 Dec 2021 14:06:02 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null
In-Reply-To: <BvSsdyWQUD7r7j9Yo9F8GyoEaCrjY5shQmC-zqss3VU=.b82640ee-cb1e-452d-bcb5-7714ad2929c7@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
 <m9Swza4RGmWKBctK1Dr6Q-lR-30rk8N0OnARQHGRqVE=.192c810f-b171-43fb-8c38-2defe30dc913@github.com>
 <DwZirNI75MGJVPwbxQ2xDd8pmQn0TxfyedWTaiq_SpI=.16722216-5e7a-4bff-b699-9f734b5b9316@github.com>
 <BvSsdyWQUD7r7j9Yo9F8GyoEaCrjY5shQmC-zqss3VU=.b82640ee-cb1e-452d-bcb5-7714ad2929c7@github.com>
Message-ID: <x-a2lEhNdvfRCl3LG3gnFJD4vSb6i3-CbXqSuKgp6aw=.68f50921-94cd-4baa-87e2-d57804d569b1@github.com>

On Wed, 15 Dec 2021 04:06:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> See L71 below:   _ptrs->unlink(&cleanup);  // cleanup the LinkedLists
>> That passes the cleanup object to ResourceHashtable::unlink()
>> function which calls the do_entry() function in the cleanup object.
>
> Ah I see (well I don't really see as this is very obscure). I would have expected `CleanupObjectMonitorsHashtable` to be a subtype of something that I could then see is used by the ResourceHashtable. I'm going to guess that there is some template usage here that ensures the passed in object has the right API even if there is no subtyping relationship. Hard to see these connections at a distance.
> 
> To be clear not a review as I don't understand our Hashtable's enough to make much sense of what is actually happening here.

It would be a nice place for a lambda (on the list of future RFEs).  You could also put this class in scope of the function that calls it which might help.  (optional)

-------------

PR: https://git.openjdk.java.net/jdk18/pull/25

From coleenp at openjdk.java.net  Wed Dec 15 16:55:59 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 15 Dec 2021 16:55:59 GMT
Subject: RFR: 8278125: Some preallocated OOMEs are missing stack trace [v2]
In-Reply-To: <JI4SopPkSGJetYlJz7IYDcYU9vrumqm-MMx6m6QtqvI=.ed6b31c3-dca3-4e76-9829-505590a79a3a@github.com>
References: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
 <AV2S-29XpWTCQh7mToBLRWh4bVMo_BygEMA44T_bXkc=.a38aa64b-0a70-4b63-b8d7-b646de83e936@github.com>
 <JI4SopPkSGJetYlJz7IYDcYU9vrumqm-MMx6m6QtqvI=.ed6b31c3-dca3-4e76-9829-505590a79a3a@github.com>
Message-ID: <qmqXtfjVDPZMAMACTGIIXBuYkt5kL46o3zWf-6TKbWk=.b2c40abc-779d-43a5-a8d2-e18723181985@github.com>

On Sat, 4 Dec 2021 18:50:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Universe::is_out_of_memory_xx
>
> src/hotspot/share/memory/universe.cpp line 597:
> 
>> 595:   const char * msg_str = java_lang_String::as_utf8_string(msg_oop);
>> 596:   return strcmp(msg, msg_str) == 0;
>> 597: }
> 
> Yes, I agree with David about strcmp.  Could you add this instead (it was trying to compare the oops for equality, and unintentionally generated a new one).
> 
> oop Universe::is_out_of_memory_error_metaspace(oop exception) {
>   return out_of_memory_errors()->obj_at(_oom_metaspace)) == exception;
> }

Ok, I see how this isn't right, but I still don't like the strcmp.  Can the string be interned and checked for equality?  Otherwise you also need a ResourceMark here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6672

From ccheung at openjdk.java.net  Wed Dec 15 17:38:58 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Wed, 15 Dec 2021 17:38:58 GMT
Subject: RFR: 8278131: runtime/cds/appcds/dynamicArchive/* tests failing in
 loom repo
In-Reply-To: <NaIFG9tIaCsNIF3LbyqbJZY3d4Reu3W0IWvQBVtOePE=.756e0bf6-12f1-4065-9315-a63c913c5b5f@github.com>
References: <dPGGxsZSwThTwo85qWFR4oz8_S0ih-2JNZyzWlFJkBg=.101bbb14-8898-437a-a693-fb6b5ff6fe2c@github.com>
 <-z8bbD6miRc-sxR8ChxpNdmAvCItIqy2irsoR0jvPtU=.54db43fe-e4af-4dd8-9cbe-6a0bd6c0fc89@github.com>
 <NaIFG9tIaCsNIF3LbyqbJZY3d4Reu3W0IWvQBVtOePE=.756e0bf6-12f1-4065-9315-a63c913c5b5f@github.com>
Message-ID: <VzEwUrvJM-Aug1_qZ7xKQmfK7mGPTG8JkxF7xwb8ns8=.721866dd-6146-46e5-85dc-61b6dc1bbc0c@github.com>

On Wed, 15 Dec 2021 05:44:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > Sorry should have been more specific. I'm looking at test/hotspot/jtreg/runtime/HiddenClasses/InstantiateHiddenClass.java where the hidden class is stored in the new field.
> 
> Okay so that test has nothing to do with dynamic dumping. But if you wanted to keep the hidden classes alive you create with STRONG so they are strongly associated with their classloader. But I can't see why that test would need that anyway.

The appcds/dynamicArchive/RegularHiddenClass.java test makes use of the InstantitateHiddenClass and attempts
to dump a hidden class into the dynamic archive.

I've tried your suggestion on using the STRONG `ClassOption` as follows and it also works. Will update the webrev.


-        Class<?> c1 = lookup.defineHiddenClass(klassbuf, false, NESTMATE).lookupClass();
-        Class<?> c2 = lookup.defineHiddenClass(klassbuf, false, NESTMATE).lookupClass();
+        ClassOption classOption = keepAlive ? STRONG : NESTMATE;
+        Class<?> c1 = lookup.defineHiddenClass(klassbuf, false, classOption).lookupClass();
+        Class<?> c2 = lookup.defineHiddenClass(klassbuf, false, classOption).lookupClass();

-------------

PR: https://git.openjdk.java.net/jdk/pull/6843

From ccheung at openjdk.java.net  Wed Dec 15 18:22:33 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Wed, 15 Dec 2021 18:22:33 GMT
Subject: RFR: 8278131: runtime/cds/appcds/dynamicArchive/* tests failing in
 loom repo [v2]
In-Reply-To: <dPGGxsZSwThTwo85qWFR4oz8_S0ih-2JNZyzWlFJkBg=.101bbb14-8898-437a-a693-fb6b5ff6fe2c@github.com>
References: <dPGGxsZSwThTwo85qWFR4oz8_S0ih-2JNZyzWlFJkBg=.101bbb14-8898-437a-a693-fb6b5ff6fe2c@github.com>
Message-ID: <y7atwl9H_MbduLV1-x0cYFC5iTLMiibL13jMzpjnwEI=.7cd821b9-ec8d-4861-904e-ac7ab6cb2c3f@github.com>

> A few dynamic archive CDS tests are failing in the loom repo due to more aggressive GC of code cache
> which leads to unloading of some classes before being written into a dynamic CDS archive.
> 
> This change is to make the affected tests more reliable by ensuring the test classes are not unloaded
> during dynamic CDS dump time.
> 
> Testing: Oracle CI tiers 1,2,4.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  use the STRONG ClassOption to create a hidden class if the keepAlive is set

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6843/files
  - new: https://git.openjdk.java.net/jdk/pull/6843/files/998817f4..e947fe06

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6843&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6843&range=00-01

  Stats: 10 lines in 1 file changed: 1 ins; 6 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6843.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6843/head:pull/6843

PR: https://git.openjdk.java.net/jdk/pull/6843

From dcubed at openjdk.java.net  Wed Dec 15 18:36:05 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 15 Dec 2021 18:36:05 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null
In-Reply-To: <nu8LbJxHbVrxUj8VFjBq4-eysW0zbHQkxzB7N2lC5FU=.50479592-394f-4f05-9b01-8ed1765f79a4@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
 <nu8LbJxHbVrxUj8VFjBq4-eysW0zbHQkxzB7N2lC5FU=.50479592-394f-4f05-9b01-8ed1765f79a4@github.com>
Message-ID: <9pSag4bs9fmFZrfj3wHtVfzPFukEdQDpzVAnCJJoJBU=.86e401e1-17c1-4d00-9a28-c35a287869b2@github.com>

On Tue, 14 Dec 2021 22:52:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> RunThese24H sometimes times out with a couple of error msgs:
>> - "java.lang.management.ThreadInfo.getLockName()" is null
>> - ForkJoin common pool thread stuck
>> 
>> The '"java.lang.management.ThreadInfo.getLockName()" is null' error msg was
>> due to RunThese's use of an older JCK test suite which has since been fixed.
>> 
>> The 'ForkJoin common pool thread stuck' failure mode is likely due to a thread
>> spending a lot of time in ObjectSynchronizer::monitors_iterate() due to a
>> VM_ThreadDump::doit() call. I say "likely" because I've never been able to
>> reproduce this failure mode in testing outside of Mach5. With the Mach5
>> sightings, all we have are thread dumps and core files and not a live process.
>> 
>> The VM_ThreadDump::doit() call is trying to gather owned monitor information
>> for all threads in the system. I've seen sightings of this failure mode with > 2000
>> threads. I've also seen passing runs with > 1.7 million monitors on the in-use list.
>> Imagine searching a larger in-use list for > 2000 threads. It just doesn't scale.
>
> This looks good to me.  You solved both the problem of the very long monitor list and the per-thread iteration too. I like it!

@coleenp - Thanks for chiming in on the official review.

@robehn - Thanks for reviewing!

-------------

PR: https://git.openjdk.java.net/jdk18/pull/25

From dcubed at openjdk.java.net  Wed Dec 15 18:36:06 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 15 Dec 2021 18:36:06 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null
In-Reply-To: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
Message-ID: <VScylpD-Ao3vGMwbmLfyQc0HMdEeDkt12cd6FaYEHtU=.47a1f379-b190-450f-8cd6-3b1c330c2957@github.com>

On Tue, 14 Dec 2021 21:16:02 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> RunThese24H sometimes times out with a couple of error msgs:
> - "java.lang.management.ThreadInfo.getLockName()" is null
> - ForkJoin common pool thread stuck
> 
> The '"java.lang.management.ThreadInfo.getLockName()" is null' error msg was
> due to RunThese's use of an older JCK test suite which has since been fixed.
> 
> The 'ForkJoin common pool thread stuck' failure mode is likely due to a thread
> spending a lot of time in ObjectSynchronizer::monitors_iterate() due to a
> VM_ThreadDump::doit() call. I say "likely" because I've never been able to
> reproduce this failure mode in testing outside of Mach5. With the Mach5
> sightings, all we have are thread dumps and core files and not a live process.
> 
> The VM_ThreadDump::doit() call is trying to gather owned monitor information
> for all threads in the system. I've seen sightings of this failure mode with > 2000
> threads. I've also seen passing runs with > 1.7 million monitors on the in-use list.
> Imagine searching a larger in-use list for > 2000 threads. It just doesn't scale.

Mach5 Tier[4567] testing looks good.
Mach5 Tier8 is still running and won't finish for at least another day or two.

-------------

PR: https://git.openjdk.java.net/jdk18/pull/25

From dcubed at openjdk.java.net  Wed Dec 15 18:36:06 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 15 Dec 2021 18:36:06 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null
In-Reply-To: <x-a2lEhNdvfRCl3LG3gnFJD4vSb6i3-CbXqSuKgp6aw=.68f50921-94cd-4baa-87e2-d57804d569b1@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
 <m9Swza4RGmWKBctK1Dr6Q-lR-30rk8N0OnARQHGRqVE=.192c810f-b171-43fb-8c38-2defe30dc913@github.com>
 <DwZirNI75MGJVPwbxQ2xDd8pmQn0TxfyedWTaiq_SpI=.16722216-5e7a-4bff-b699-9f734b5b9316@github.com>
 <BvSsdyWQUD7r7j9Yo9F8GyoEaCrjY5shQmC-zqss3VU=.b82640ee-cb1e-452d-bcb5-7714ad2929c7@github.com>
 <x-a2lEhNdvfRCl3LG3gnFJD4vSb6i3-CbXqSuKgp6aw=.68f50921-94cd-4baa-87e2-d57804d569b1@github.com>
Message-ID: <xO0Yd9kEapWI1ag-vAsH21_kzY8FpXrUKOjr6FrANFc=.127f84ad-b5f9-48a5-bef3-43f35c039a20@github.com>

On Wed, 15 Dec 2021 13:49:02 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ah I see (well I don't really see as this is very obscure). I would have expected `CleanupObjectMonitorsHashtable` to be a subtype of something that I could then see is used by the ResourceHashtable. I'm going to guess that there is some template usage here that ensures the passed in object has the right API even if there is no subtyping relationship. Hard to see these connections at a distance.
>> 
>> To be clear not a review as I don't understand our Hashtable's enough to make much sense of what is actually happening here.
>
> It would be a nice place for a lambda (on the list of future RFEs).  You could also put this class in scope of the function that calls it which might help.  (optional)

ResourceHashtable::unlink() is definitely one of those template
things that I don't really like, but I have to use it... All that stuff
is in src/hotspot/share/utilities/resourceHash.hpp, but I don't
see any precedent for putting the CleanupObjectMonitorsHashtable
definition in there. I think I'll leave it where it is.

-------------

PR: https://git.openjdk.java.net/jdk18/pull/25

From dcubed at openjdk.java.net  Wed Dec 15 18:36:08 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 15 Dec 2021 18:36:08 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null
In-Reply-To: <dG3-urCe2g2-F3KIdlJG7banTn17ovSO0Q7OpHFILHc=.c5baa018-6fb4-4364-84a5-98abc6fee0ff@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
 <dG3-urCe2g2-F3KIdlJG7banTn17ovSO0Q7OpHFILHc=.c5baa018-6fb4-4364-84a5-98abc6fee0ff@github.com>
Message-ID: <t1tGZVjK08iZD-be7vMS4k8g62tfn7PLVTSSz47jrvs=.506920ed-94b0-43ab-83d9-afacfb0ae09c@github.com>

On Wed, 15 Dec 2021 08:34:28 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> RunThese24H sometimes times out with a couple of error msgs:
>> - "java.lang.management.ThreadInfo.getLockName()" is null
>> - ForkJoin common pool thread stuck
>> 
>> The '"java.lang.management.ThreadInfo.getLockName()" is null' error msg was
>> due to RunThese's use of an older JCK test suite which has since been fixed.
>> 
>> The 'ForkJoin common pool thread stuck' failure mode is likely due to a thread
>> spending a lot of time in ObjectSynchronizer::monitors_iterate() due to a
>> VM_ThreadDump::doit() call. I say "likely" because I've never been able to
>> reproduce this failure mode in testing outside of Mach5. With the Mach5
>> sightings, all we have are thread dumps and core files and not a live process.
>> 
>> The VM_ThreadDump::doit() call is trying to gather owned monitor information
>> for all threads in the system. I've seen sightings of this failure mode with > 2000
>> threads. I've also seen passing runs with > 1.7 million monitors on the in-use list.
>> Imagine searching a larger in-use list for > 2000 threads. It just doesn't scale.
>
> src/hotspot/share/runtime/vmOperations.cpp line 283:
> 
>> 281: 
>> 282:   ObjectMonitorsHashtable table;
>> 283:   ObjectMonitorsHashtable* tablep = nullptr;
> 
> It looks like you can remove this pointer.
> ThreadStackTrace::dump_stack_at_safepoint also looks at "with_locked_monitors", if false it ignores the table.
> So there should not be any need to pass in null.

Right now `ThreadStackTrace::dump_stack_at_safepoint()` is flexible in
that it does not require `ObjectMonitorsHashtable* table` to be non-null
when `_with_locked_monitors` is true. 

>From this call site, when `_with_locked_monitors` is true we always pass
a non-nullptr `ObjectMonitorsHashtable* table` and we do that because
we're at a safepoint and likely have to deal with a lot of threads if not all
the threads in the system.

For other `ThreadStackTrace::dump_stack_at_safepoint()` call sites,
I want things to be more flexible. Mostly because I haven't done
detailed analysis of them to justify changing their behavior.

> src/hotspot/share/services/threadService.cpp line 692:
> 
>> 690:       ObjectMonitorsHashtable::PtrList* list = table->get_entry(_thread);
>> 691:       if (list != nullptr) {
>> 692:         ObjectSynchronizer::monitors_iterate(&imc, list, _thread);
> 
> The InflatedMonitorsClosure walks the stack until object is found with this method:
> ThreadStackTrace::is_owned_monitor_on_stack(oop object)
> for every object...
> 
> If you instead just collect all locks on stack with one pass you don't have to walk the stack over and over, which should be major speedup.

Sounds like an interesting RFE, but I'd prefer that be investigated
separately from this bug.

-------------

PR: https://git.openjdk.java.net/jdk18/pull/25

From dcubed at openjdk.java.net  Wed Dec 15 21:48:01 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 15 Dec 2021 21:48:01 GMT
Subject: RFR: 8268573: Remove expired flags in JDK 19
In-Reply-To: <1JzfCm_-QMikvfVrn1AdEFlYOS8KaPgEO2ZzaC3Smw8=.b43f45af-62e6-4561-a202-25c17a706d2f@github.com>
References: <1JzfCm_-QMikvfVrn1AdEFlYOS8KaPgEO2ZzaC3Smw8=.b43f45af-62e6-4561-a202-25c17a706d2f@github.com>
Message-ID: <iAdp5PVW2PMrYdJctsJNkJef1zT0-ADugBuaBb7nyj8=.7e826e15-f7fd-4196-a79e-7e82cf316d0e@github.com>

On Mon, 13 Dec 2021 22:17:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this simple change to remove all the flags that expired in JDK 19 from the flag table in arguments.cpp.
> 
> The java manpage is also updated as the UseBiasedLocking flag is moved from the "obsoleted" section, to the "removed" section. Plus we update the list of previous release docs.
> 
> Testing: local - all the runtime/CommandLine tests
> 
> Thanks,
> David

Thumbs up.

I agree that it's time for the 'UseBiasedLocking' option to be removed.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6819

From dholmes at openjdk.java.net  Wed Dec 15 21:56:02 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 15 Dec 2021 21:56:02 GMT
Subject: RFR: 8268573: Remove expired flags in JDK 19
In-Reply-To: <iAdp5PVW2PMrYdJctsJNkJef1zT0-ADugBuaBb7nyj8=.7e826e15-f7fd-4196-a79e-7e82cf316d0e@github.com>
References: <1JzfCm_-QMikvfVrn1AdEFlYOS8KaPgEO2ZzaC3Smw8=.b43f45af-62e6-4561-a202-25c17a706d2f@github.com>
 <iAdp5PVW2PMrYdJctsJNkJef1zT0-ADugBuaBb7nyj8=.7e826e15-f7fd-4196-a79e-7e82cf316d0e@github.com>
Message-ID: <Hs9VergWtPv5sFW8S0pSjgXmEWwFdbNvfC2lWRnfpsY=.bfbe9eaa-68d1-472e-855e-dfd91623ec95@github.com>

On Wed, 15 Dec 2021 21:44:29 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Please review this simple change to remove all the flags that expired in JDK 19 from the flag table in arguments.cpp.
>> 
>> The java manpage is also updated as the UseBiasedLocking flag is moved from the "obsoleted" section, to the "removed" section. Plus we update the list of previous release docs.
>> 
>> Testing: local - all the runtime/CommandLine tests
>> 
>> Thanks,
>> David
>
> Thumbs up.
> 
> I agree that it's time for the 'UseBiasedLocking' option to be removed.

Thanks for the review @dcubed-ojdk !

-------------

PR: https://git.openjdk.java.net/jdk/pull/6819

From dcubed at openjdk.java.net  Wed Dec 15 22:30:07 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 15 Dec 2021 22:30:07 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null
In-Reply-To: <t1tGZVjK08iZD-be7vMS4k8g62tfn7PLVTSSz47jrvs=.506920ed-94b0-43ab-83d9-afacfb0ae09c@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
 <dG3-urCe2g2-F3KIdlJG7banTn17ovSO0Q7OpHFILHc=.c5baa018-6fb4-4364-84a5-98abc6fee0ff@github.com>
 <t1tGZVjK08iZD-be7vMS4k8g62tfn7PLVTSSz47jrvs=.506920ed-94b0-43ab-83d9-afacfb0ae09c@github.com>
Message-ID: <vTZzBhPz75XGSC6kXyC-dPEsyqqTldB3-amUvI6DArs=.36b56079-9ed0-4ee1-ad23-1d808f95751f@github.com>

On Wed, 15 Dec 2021 18:28:58 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> src/hotspot/share/services/threadService.cpp line 692:
>> 
>>> 690:       ObjectMonitorsHashtable::PtrList* list = table->get_entry(_thread);
>>> 691:       if (list != nullptr) {
>>> 692:         ObjectSynchronizer::monitors_iterate(&imc, list, _thread);
>> 
>> The InflatedMonitorsClosure walks the stack until object is found with this method:
>> ThreadStackTrace::is_owned_monitor_on_stack(oop object)
>> for every object...
>> 
>> If you instead just collect all locks on stack with one pass you don't have to walk the stack over and over, which should be major speedup.
>
> Sounds like an interesting RFE, but I'd prefer that be investigated
> separately from this bug.

Clarification: ThreadStackTrace::is_owned_monitor_on_stack() is not actually
walking the (JavaThread's) stack, but it is walking the collection of
StackFrameInfo objects that was gathered earlier in
ThreadStackTrace::dump_stack_at_safepoint(). Adding a gather-locked-monitor
helper object to the "add_stack_frame()" call would provide an easy hook and
then InflatedMonitorsClosure could use the new helper object. Something like
that anyway...

-------------

PR: https://git.openjdk.java.net/jdk18/pull/25

From pchilanomate at openjdk.java.net  Wed Dec 15 22:33:06 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Wed, 15 Dec 2021 22:33:06 GMT
Subject: RFR: 8268573: Remove expired flags in JDK 19
In-Reply-To: <1JzfCm_-QMikvfVrn1AdEFlYOS8KaPgEO2ZzaC3Smw8=.b43f45af-62e6-4561-a202-25c17a706d2f@github.com>
References: <1JzfCm_-QMikvfVrn1AdEFlYOS8KaPgEO2ZzaC3Smw8=.b43f45af-62e6-4561-a202-25c17a706d2f@github.com>
Message-ID: <ODC_c8Mps8qEaYzhdmoRyqBTQoDawUbS2OYGaBv4hHY=.13cdcbe1-31e1-438b-9c41-ffd86c440d82@github.com>

On Mon, 13 Dec 2021 22:17:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this simple change to remove all the flags that expired in JDK 19 from the flag table in arguments.cpp.
> 
> The java manpage is also updated as the UseBiasedLocking flag is moved from the "obsoleted" section, to the "removed" section. Plus we update the list of previous release docs.
> 
> Testing: local - all the runtime/CommandLine tests
> 
> Thanks,
> David

Changes look good to me. I don't have a strong opinion about leaving UseBiasedLocking as obsoleted for now instead of removing it. Either way seems fine.

Thanks,
Patricio

-------------

Marked as reviewed by pchilanomate (Committer).

PR: https://git.openjdk.java.net/jdk/pull/6819

From dholmes at openjdk.java.net  Wed Dec 15 22:37:05 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 15 Dec 2021 22:37:05 GMT
Subject: RFR: 8278131: runtime/cds/appcds/dynamicArchive/* tests failing in
 loom repo
In-Reply-To: <VzEwUrvJM-Aug1_qZ7xKQmfK7mGPTG8JkxF7xwb8ns8=.721866dd-6146-46e5-85dc-61b6dc1bbc0c@github.com>
References: <dPGGxsZSwThTwo85qWFR4oz8_S0ih-2JNZyzWlFJkBg=.101bbb14-8898-437a-a693-fb6b5ff6fe2c@github.com>
 <-z8bbD6miRc-sxR8ChxpNdmAvCItIqy2irsoR0jvPtU=.54db43fe-e4af-4dd8-9cbe-6a0bd6c0fc89@github.com>
 <NaIFG9tIaCsNIF3LbyqbJZY3d4Reu3W0IWvQBVtOePE=.756e0bf6-12f1-4065-9315-a63c913c5b5f@github.com>
 <VzEwUrvJM-Aug1_qZ7xKQmfK7mGPTG8JkxF7xwb8ns8=.721866dd-6146-46e5-85dc-61b6dc1bbc0c@github.com>
Message-ID: <bwsC1W1lFDyN1hYIpLJ5VtSBFEMpkONTD_1tXMxyMv8=.4d7773ea-bbc9-4e06-bc7c-b37a604482d6@github.com>

On Wed, 15 Dec 2021 17:35:24 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> The appcds/dynamicArchive/RegularHiddenClass.java test makes use of the InstantitateHiddenClass and attempts
to dump a hidden class into the dynamic archive.

Ah I see - that makes more sense. May I suggest that a comment is added in InstantiateHiddenClass.java to indicate that it is also used by RegularHiddenClass which will pass the keep-alive option. Otherwise it looks very odd to expect a parameter that is seemingly not passed and for which there is no obvious reason for passing. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6843

From dholmes at openjdk.java.net  Wed Dec 15 22:44:01 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 15 Dec 2021 22:44:01 GMT
Subject: RFR: 8278131: runtime/cds/appcds/dynamicArchive/* tests failing in
 loom repo [v2]
In-Reply-To: <y7atwl9H_MbduLV1-x0cYFC5iTLMiibL13jMzpjnwEI=.7cd821b9-ec8d-4861-904e-ac7ab6cb2c3f@github.com>
References: <dPGGxsZSwThTwo85qWFR4oz8_S0ih-2JNZyzWlFJkBg=.101bbb14-8898-437a-a693-fb6b5ff6fe2c@github.com>
 <y7atwl9H_MbduLV1-x0cYFC5iTLMiibL13jMzpjnwEI=.7cd821b9-ec8d-4861-904e-ac7ab6cb2c3f@github.com>
Message-ID: <dG2pMLwsyG4FWe85Ivn-VNOziOrTEEM7BCQaY1fbCEs=.0a42c009-2da2-415a-9ef8-7f0100b5aef4@github.com>

On Wed, 15 Dec 2021 18:22:33 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> A few dynamic archive CDS tests are failing in the loom repo due to more aggressive GC of code cache
>> which leads to unloading of some classes before being written into a dynamic CDS archive.
>> 
>> This change is to make the affected tests more reliable by ensuring the test classes are not unloaded
>> during dynamic CDS dump time.
>> 
>> Testing: Oracle CI tiers 1,2,4.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use the STRONG ClassOption to create a hidden class if the keepAlive is set

I find the overall handling of the extra keep-alive parameter somewhat awkward. It is far from clear which tests will be invoked with what set of parameters, and whether "keep-alive" is always passed, or only sometimes. If none of these tests actually rely on performing class unloading, then it would be simpler if they all unconditionally keep the classes alive.

David

-------------

PR: https://git.openjdk.java.net/jdk/pull/6843

From dholmes at openjdk.java.net  Wed Dec 15 22:46:01 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 15 Dec 2021 22:46:01 GMT
Subject: RFR: 8268573: Remove expired flags in JDK 19
In-Reply-To: <ODC_c8Mps8qEaYzhdmoRyqBTQoDawUbS2OYGaBv4hHY=.13cdcbe1-31e1-438b-9c41-ffd86c440d82@github.com>
References: <1JzfCm_-QMikvfVrn1AdEFlYOS8KaPgEO2ZzaC3Smw8=.b43f45af-62e6-4561-a202-25c17a706d2f@github.com>
 <ODC_c8Mps8qEaYzhdmoRyqBTQoDawUbS2OYGaBv4hHY=.13cdcbe1-31e1-438b-9c41-ffd86c440d82@github.com>
Message-ID: <BleSxm_uc4tnqm-Fuf8sIxnTyeo0lPkcfMRtdoFNCWg=.71e6e1b2-ac3e-41b6-85db-1715f6644823@github.com>

On Wed, 15 Dec 2021 22:29:53 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review this simple change to remove all the flags that expired in JDK 19 from the flag table in arguments.cpp.
>> 
>> The java manpage is also updated as the UseBiasedLocking flag is moved from the "obsoleted" section, to the "removed" section. Plus we update the list of previous release docs.
>> 
>> Testing: local - all the runtime/CommandLine tests
>> 
>> Thanks,
>> David
>
> Changes look good to me. I don't have a strong opinion about leaving UseBiasedLocking as obsoleted for now instead of removing it. Either way seems fine.
> 
> Thanks,
> Patricio

Thanks @pchilano !

-------------

PR: https://git.openjdk.java.net/jdk/pull/6819

From ccheung at openjdk.java.net  Wed Dec 15 23:35:58 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Wed, 15 Dec 2021 23:35:58 GMT
Subject: RFR: 8278131: runtime/cds/appcds/dynamicArchive/* tests failing in
 loom repo
In-Reply-To: <bwsC1W1lFDyN1hYIpLJ5VtSBFEMpkONTD_1tXMxyMv8=.4d7773ea-bbc9-4e06-bc7c-b37a604482d6@github.com>
References: <dPGGxsZSwThTwo85qWFR4oz8_S0ih-2JNZyzWlFJkBg=.101bbb14-8898-437a-a693-fb6b5ff6fe2c@github.com>
 <-z8bbD6miRc-sxR8ChxpNdmAvCItIqy2irsoR0jvPtU=.54db43fe-e4af-4dd8-9cbe-6a0bd6c0fc89@github.com>
 <NaIFG9tIaCsNIF3LbyqbJZY3d4Reu3W0IWvQBVtOePE=.756e0bf6-12f1-4065-9315-a63c913c5b5f@github.com>
 <VzEwUrvJM-Aug1_qZ7xKQmfK7mGPTG8JkxF7xwb8ns8=.721866dd-6146-46e5-85dc-61b6dc1bbc0c@github.com>
 <bwsC1W1lFDyN1hYIpLJ5VtSBFEMpkONTD_1tXMxyMv8=.4d7773ea-bbc9-4e06-bc7c-b37a604482d6@github.com>
Message-ID: <oOPPp8Ms-96KVf5mC8Cl6baf71Snq9yuhC9lynLjc1o=.b0649d45-d5c9-49f8-b7e0-509110a6021d@github.com>

On Wed, 15 Dec 2021 22:33:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > The appcds/dynamicArchive/RegularHiddenClass.java test makes use of the InstantitateHiddenClass and attempts
> > to dump a hidden class into the dynamic archive.
> 
> Ah I see - that makes more sense. May I suggest that a comment is added in InstantiateHiddenClass.java to indicate that it is also used by RegularHiddenClass which will pass the keep-alive option. Otherwise it looks very odd to expect a parameter that is seemingly not passed and for which there is no obvious reason for passing. Thanks.

I've added the following comment:

    public static void main(String[] args) throws Throwable {
        // This class is also used by the appcds/dynamicArchive/RegularHiddenClass.java
        // test which will pass the "keep-alive" argument during dynamic CDS dump
        // for preventing from being GC'ed prior to the dumping operation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6843

From ccheung at openjdk.java.net  Wed Dec 15 23:35:59 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Wed, 15 Dec 2021 23:35:59 GMT
Subject: RFR: 8278131: runtime/cds/appcds/dynamicArchive/* tests failing in
 loom repo [v2]
In-Reply-To: <dG2pMLwsyG4FWe85Ivn-VNOziOrTEEM7BCQaY1fbCEs=.0a42c009-2da2-415a-9ef8-7f0100b5aef4@github.com>
References: <dPGGxsZSwThTwo85qWFR4oz8_S0ih-2JNZyzWlFJkBg=.101bbb14-8898-437a-a693-fb6b5ff6fe2c@github.com>
 <y7atwl9H_MbduLV1-x0cYFC5iTLMiibL13jMzpjnwEI=.7cd821b9-ec8d-4861-904e-ac7ab6cb2c3f@github.com>
 <dG2pMLwsyG4FWe85Ivn-VNOziOrTEEM7BCQaY1fbCEs=.0a42c009-2da2-415a-9ef8-7f0100b5aef4@github.com>
Message-ID: <Wlvr5FGKhYEs3wPiIayJkCFJaN0QQuJjmUx_ezcWxpo=.223cc30e-7c41-41d2-9d6e-7aa53cff2e32@github.com>

On Wed, 15 Dec 2021 22:40:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I find the overall handling of the extra keep-alive parameter somewhat awkward. It is far from clear which tests will be invoked with what set of parameters, and whether "keep-alive" is always passed, or only sometimes. If none of these tests actually rely on performing class unloading, then it would be simpler if they all unconditionally keep the classes alive.
> 
> David

The "keep-alive" is needed only for dynamic CDS dumping; it is not required during runtime or static dumping. So I think
it is better to keep the "keep-alive" parameter so that other tests won't be impacted.
I've added some comments to the help classes.

thanks,
Calvin

-------------

PR: https://git.openjdk.java.net/jdk/pull/6843

From ccheung at openjdk.java.net  Wed Dec 15 23:57:36 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Wed, 15 Dec 2021 23:57:36 GMT
Subject: RFR: 8278131: runtime/cds/appcds/dynamicArchive/* tests failing in
 loom repo [v3]
In-Reply-To: <dPGGxsZSwThTwo85qWFR4oz8_S0ih-2JNZyzWlFJkBg=.101bbb14-8898-437a-a693-fb6b5ff6fe2c@github.com>
References: <dPGGxsZSwThTwo85qWFR4oz8_S0ih-2JNZyzWlFJkBg=.101bbb14-8898-437a-a693-fb6b5ff6fe2c@github.com>
Message-ID: <8nvPoqP24j5-kaqqJ-npvMHc3SVKbVAon_d0Y1_9-rY=.f876502c-e555-4a50-90a0-1d11876985a9@github.com>

> A few dynamic archive CDS tests are failing in the loom repo due to more aggressive GC of code cache
> which leads to unloading of some classes before being written into a dynamic CDS archive.
> 
> This change is to make the affected tests more reliable by ensuring the test classes are not unloaded
> during dynamic CDS dump time.
> 
> Testing: Oracle CI tiers 1,2,4.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  add comments to helper classes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6843/files
  - new: https://git.openjdk.java.net/jdk/pull/6843/files/e947fe06..736a5129

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6843&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6843&range=01-02

  Stats: 12 lines in 4 files changed: 12 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6843.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6843/head:pull/6843

PR: https://git.openjdk.java.net/jdk/pull/6843

From smarks at openjdk.java.net  Thu Dec 16 01:02:19 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 16 Dec 2021 01:02:19 GMT
Subject: [jdk18] RFR: 8278575: update jcmd GC.finalizer_info to list
 finalization status
Message-ID: <cDYfPAJOAqbqgM4joZ1T_9Dr3WcTV0-9rvoVB97YA4U=.08c96392-1860-49e8-94af-3c5f3e5d0780@github.com>

A simple patch that I inadvertently omitted from the original integration.

-------------

Commit messages:
 - Missing include
 - Update GC.finalizer_info dcmd

Changes: https://git.openjdk.java.net/jdk18/pull/33/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=33&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278575
  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/33.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/33/head:pull/33

PR: https://git.openjdk.java.net/jdk18/pull/33

From dholmes at openjdk.java.net  Thu Dec 16 01:02:19 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 16 Dec 2021 01:02:19 GMT
Subject: [jdk18] RFR: 8278575: update jcmd GC.finalizer_info to list
 finalization status
In-Reply-To: <cDYfPAJOAqbqgM4joZ1T_9Dr3WcTV0-9rvoVB97YA4U=.08c96392-1860-49e8-94af-3c5f3e5d0780@github.com>
References: <cDYfPAJOAqbqgM4joZ1T_9Dr3WcTV0-9rvoVB97YA4U=.08c96392-1860-49e8-94af-3c5f3e5d0780@github.com>
Message-ID: <FQR6RsHiqSi6rXgX-hbr53ujJtZDAnNCJDqiTHqFPhU=.6fffeb00-8226-453f-8e32-7fdaba2572f0@github.com>

On Thu, 16 Dec 2021 00:48:49 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> A simple patch that I inadvertently omitted from the original integration.

Looks good to me. :)

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/33

From kbarrett at openjdk.java.net  Thu Dec 16 01:26:04 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 16 Dec 2021 01:26:04 GMT
Subject: [jdk18] RFR: 8278575: update jcmd GC.finalizer_info to list
 finalization status
In-Reply-To: <cDYfPAJOAqbqgM4joZ1T_9Dr3WcTV0-9rvoVB97YA4U=.08c96392-1860-49e8-94af-3c5f3e5d0780@github.com>
References: <cDYfPAJOAqbqgM4joZ1T_9Dr3WcTV0-9rvoVB97YA4U=.08c96392-1860-49e8-94af-3c5f3e5d0780@github.com>
Message-ID: <Rgvr4SbZA_qw1Q4V8ksVnNqnFEadoR6WceDkZqP8vvQ=.01dcb3c3-872e-44e7-bf72-6ea9573626bc@github.com>

On Thu, 16 Dec 2021 00:48:49 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> A simple patch that I inadvertently omitted from the original integration.

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/33

From smarks at openjdk.java.net  Thu Dec 16 01:30:02 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 16 Dec 2021 01:30:02 GMT
Subject: [jdk18] Integrated: 8278575: update jcmd GC.finalizer_info to list
 finalization status
In-Reply-To: <cDYfPAJOAqbqgM4joZ1T_9Dr3WcTV0-9rvoVB97YA4U=.08c96392-1860-49e8-94af-3c5f3e5d0780@github.com>
References: <cDYfPAJOAqbqgM4joZ1T_9Dr3WcTV0-9rvoVB97YA4U=.08c96392-1860-49e8-94af-3c5f3e5d0780@github.com>
Message-ID: <fhdmF_HTAeQ6uuZ_iCf4o1UYFnQcNjBeI5fD1XFf9z4=.c4efc556-ac59-493f-abaa-fff01b00f049@github.com>

On Thu, 16 Dec 2021 00:48:49 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> A simple patch that I inadvertently omitted from the original integration.

This pull request has now been integrated.

Changeset: e82310f3
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/e82310f3605b37519129ea34b2a6f99ee3ccc63a
Stats:     6 lines in 1 file changed: 6 ins; 0 del; 0 mod

8278575: update jcmd GC.finalizer_info to list finalization status

Co-authored-by: David Holmes <dholmes at openjdk.org>
Reviewed-by: dholmes, kbarrett

-------------

PR: https://git.openjdk.java.net/jdk18/pull/33

From dholmes at openjdk.java.net  Thu Dec 16 01:31:58 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 16 Dec 2021 01:31:58 GMT
Subject: RFR: 8278131: runtime/cds/appcds/dynamicArchive/* tests failing in
 loom repo [v3]
In-Reply-To: <8nvPoqP24j5-kaqqJ-npvMHc3SVKbVAon_d0Y1_9-rY=.f876502c-e555-4a50-90a0-1d11876985a9@github.com>
References: <dPGGxsZSwThTwo85qWFR4oz8_S0ih-2JNZyzWlFJkBg=.101bbb14-8898-437a-a693-fb6b5ff6fe2c@github.com>
 <8nvPoqP24j5-kaqqJ-npvMHc3SVKbVAon_d0Y1_9-rY=.f876502c-e555-4a50-90a0-1d11876985a9@github.com>
Message-ID: <10nmqOotS4vGQvqNAYeV73PouBOW_PfmixlctH-ygxo=.6808f32b-73c5-47cc-a59c-7770fc1e3e68@github.com>

On Wed, 15 Dec 2021 23:57:36 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> A few dynamic archive CDS tests are failing in the loom repo due to more aggressive GC of code cache
>> which leads to unloading of some classes before being written into a dynamic CDS archive.
>> 
>> This change is to make the affected tests more reliable by ensuring the test classes are not unloaded
>> during dynamic CDS dump time.
>> 
>> Testing: Oracle CI tiers 1,2,4.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comments to helper classes

The test changes are acceptable and so the PR "approved" on that basis.

But I can't help but wonder what this class unloading issue means for dynamic dumping in general? Seems like the dump contents will depend on a GC race.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6843

From minqi at openjdk.java.net  Thu Dec 16 02:07:57 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 16 Dec 2021 02:07:57 GMT
Subject: RFR: 8278131: runtime/cds/appcds/dynamicArchive/* tests failing in
 loom repo [v2]
In-Reply-To: <y7atwl9H_MbduLV1-x0cYFC5iTLMiibL13jMzpjnwEI=.7cd821b9-ec8d-4861-904e-ac7ab6cb2c3f@github.com>
References: <dPGGxsZSwThTwo85qWFR4oz8_S0ih-2JNZyzWlFJkBg=.101bbb14-8898-437a-a693-fb6b5ff6fe2c@github.com>
 <y7atwl9H_MbduLV1-x0cYFC5iTLMiibL13jMzpjnwEI=.7cd821b9-ec8d-4861-904e-ac7ab6cb2c3f@github.com>
Message-ID: <Jb-TTMeNU7Lu_lBV15Y0GBjUK5StVFnVaKzAqcQmiGY=.ee683393-bd13-4867-9eda-1dba55423df2@github.com>

On Wed, 15 Dec 2021 18:22:33 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> A few dynamic archive CDS tests are failing in the loom repo due to more aggressive GC of code cache
>> which leads to unloading of some classes before being written into a dynamic CDS archive.
>> 
>> This change is to make the affected tests more reliable by ensuring the test classes are not unloaded
>> during dynamic CDS dump time.
>> 
>> Testing: Oracle CI tiers 1,2,4.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use the STRONG ClassOption to create a hidden class if the keepAlive is set

LGTM.

-------------

Marked as reviewed by minqi (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6843

From ccheung at openjdk.java.net  Thu Dec 16 02:19:58 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 16 Dec 2021 02:19:58 GMT
Subject: RFR: 8278131: runtime/cds/appcds/dynamicArchive/* tests failing in
 loom repo [v3]
In-Reply-To: <10nmqOotS4vGQvqNAYeV73PouBOW_PfmixlctH-ygxo=.6808f32b-73c5-47cc-a59c-7770fc1e3e68@github.com>
References: <dPGGxsZSwThTwo85qWFR4oz8_S0ih-2JNZyzWlFJkBg=.101bbb14-8898-437a-a693-fb6b5ff6fe2c@github.com>
 <8nvPoqP24j5-kaqqJ-npvMHc3SVKbVAon_d0Y1_9-rY=.f876502c-e555-4a50-90a0-1d11876985a9@github.com>
 <10nmqOotS4vGQvqNAYeV73PouBOW_PfmixlctH-ygxo=.6808f32b-73c5-47cc-a59c-7770fc1e3e68@github.com>
Message-ID: <fQEhTgew_szYU6h5ktrqFxkXTsG4H-U119aaxJL5d_g=.c8a6eccc-b289-4525-8262-c049a9f2d75b@github.com>

On Thu, 16 Dec 2021 01:28:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The test changes are acceptable and so the PR "approved" on that basis.

Thanks!

> 
> But I can't help but wonder what this class unloading issue means for dynamic dumping in general? Seems like the dump contents will depend on a GC race.
> 
Yes, there have been couple of bugs in this area. Hopefully the upcoming fix for [JDK-8278602](https://bugs.openjdk.java.net/browse/JDK-8278602)
will address this issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6843

From ccheung at openjdk.java.net  Thu Dec 16 02:36:00 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 16 Dec 2021 02:36:00 GMT
Subject: RFR: 8278131: runtime/cds/appcds/dynamicArchive/* tests failing in
 loom repo
In-Reply-To: <ng857wISz3L81sE0NFr1W9PWLKHtdHS1HsxOossg0Bk=.e7722c23-a54d-4991-b0d2-44b2301444e0@github.com>
References: <dPGGxsZSwThTwo85qWFR4oz8_S0ih-2JNZyzWlFJkBg=.101bbb14-8898-437a-a693-fb6b5ff6fe2c@github.com>
 <pI5w9XVHTpCrJNlJC8j0c7RgFjumZWW_q8TFfho1uqU=.c6044e5e-4234-4010-8155-cc7a50e244c7@github.com>
 <ng857wISz3L81sE0NFr1W9PWLKHtdHS1HsxOossg0Bk=.e7722c23-a54d-4991-b0d2-44b2301444e0@github.com>
Message-ID: <nIV2EP18a6IltibdrSM-DqtzOHCWT3kkANEkVmZYbSs=.a388f66a-d311-4137-856e-00f079e15187@github.com>

On Wed, 15 Dec 2021 04:34:23 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Sorry but this isn't making any sense to me. You can't GC a class until its classloader becomes unreachable - at which point the classloader and all its loaded classes become unreachable together. So you can't keep a class alive by storing a reference to it in a static field of a class loaded by the same classloader - it was already kept alive.
>> 
>> David
>
>> Sorry but this isn't making any sense to me. You can't GC a class until its classloader becomes unreachable - at which point the classloader and all its loaded classes become unreachable together. So you can't keep a class alive by storing a reference to it in a static field of a class loaded by the same classloader - it was already kept alive.
>> 
>> David
> 
> Hi David,
> 
> 
>         URLClassLoader urlClassLoader =
>             new URLClassLoader("HelloClassLoader", urls, null);
>         Class c = Class.forName(className, true, urlClassLoader);
> +       if (keepAlive) {
> +           keptC = c;
> +       }
> 
> The class `c` is defined by a custom class loader (`urlClassLoader`). Before this patch, when `urlClassLoader` and `c` fall out of scope, this class becomes eligible for garbage collection.
> 
> The class that runs the above code (`HelloUnload`) is loaded by the app class loader. By referencing `c` in a static field of `HelloUnload`, we make sure `c` is never unloaded.

@iklam, @dholmes-ora, @yminqi Thanks for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6843

From ccheung at openjdk.java.net  Thu Dec 16 02:36:01 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 16 Dec 2021 02:36:01 GMT
Subject: Integrated: 8278131: runtime/cds/appcds/dynamicArchive/* tests failing
 in loom repo
In-Reply-To: <dPGGxsZSwThTwo85qWFR4oz8_S0ih-2JNZyzWlFJkBg=.101bbb14-8898-437a-a693-fb6b5ff6fe2c@github.com>
References: <dPGGxsZSwThTwo85qWFR4oz8_S0ih-2JNZyzWlFJkBg=.101bbb14-8898-437a-a693-fb6b5ff6fe2c@github.com>
Message-ID: <wGcahMoCe6VPqQriAVM47ZL5CQb2AUEIctp50KgzAF4=.367dbc3b-43d5-4cb6-bd2f-1c2658afdac9@github.com>

On Tue, 14 Dec 2021 23:14:38 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> A few dynamic archive CDS tests are failing in the loom repo due to more aggressive GC of code cache
> which leads to unloading of some classes before being written into a dynamic CDS archive.
> 
> This change is to make the affected tests more reliable by ensuring the test classes are not unloaded
> during dynamic CDS dump time.
> 
> Testing: Oracle CI tiers 1,2,4.

This pull request has now been integrated.

Changeset: 0dbe4c5d
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0dbe4c5d516a5e43934cb18f3becaf2a7f90999f
Stats:     66 lines in 9 files changed: 52 ins; 0 del; 14 mod

8278131: runtime/cds/appcds/dynamicArchive/* tests failing in loom repo

Reviewed-by: iklam, dholmes, minqi

-------------

PR: https://git.openjdk.java.net/jdk/pull/6843

From eosterlund at openjdk.java.net  Thu Dec 16 06:47:00 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 16 Dec 2021 06:47:00 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null
In-Reply-To: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
Message-ID: <dFnv0X9ls1jMp2OnZlNeTyHmEt1XBq2VPO1uUQ_Hrh0=.63e27e6c-8bde-4ddd-844d-2120f7ef6249@github.com>

On Tue, 14 Dec 2021 21:16:02 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> RunThese24H sometimes times out with a couple of error msgs:
> - "java.lang.management.ThreadInfo.getLockName()" is null
> - ForkJoin common pool thread stuck
> 
> The '"java.lang.management.ThreadInfo.getLockName()" is null' error msg was
> due to RunThese's use of an older JCK test suite which has since been fixed.
> 
> The 'ForkJoin common pool thread stuck' failure mode is likely due to a thread
> spending a lot of time in ObjectSynchronizer::monitors_iterate() due to a
> VM_ThreadDump::doit() call. I say "likely" because I've never been able to
> reproduce this failure mode in testing outside of Mach5. With the Mach5
> sightings, all we have are thread dumps and core files and not a live process.
> 
> The VM_ThreadDump::doit() call is trying to gather owned monitor information
> for all threads in the system. I've seen sightings of this failure mode with > 2000
> threads. I've also seen passing runs with > 1.7 million monitors on the in-use list.
> Imagine searching a larger in-use list for > 2000 threads. It just doesn't scale.

Looks okay, but I found a potential issue.

src/hotspot/share/runtime/synchronizer.cpp line 79:

> 77:   if (list != nullptr) {
> 78:     // Add to existing list from the hash table:
> 79:     list->add(om);

These two lines are executed in both the if and else clause. Consider putting it after instead.

src/hotspot/share/runtime/synchronizer.cpp line 1062:

> 1060:                                           JavaThread* thread) {
> 1061:   typedef LinkedListIterator<ObjectMonitor*> ObjectMonitorIterator;
> 1062:   ObjectMonitorIterator iter = ObjectMonitorIterator(list->head());

This seems to create an object and then copy it to iter. I think the more obvious syntax is ObjectMonitorIterator iter(list->head());

src/hotspot/share/runtime/synchronizer.cpp line 1423:

> 1421:       // deflate_idle_monitors() and deflate_monitor_list() can be called more than
> 1422:       // once, we have to make sure the entry has not already been added.
> 1423:       JavaThread* jt = (JavaThread*)mid->owner();

Hmmmm. I'm not sure this is correct. The owned of an ObjectMonitor is a JavaThread most of the time, but not always. I think that if the owner started off with a stack lock, and another thread inflated the lock due to contention, then the ObjectMonitor will get the stack lock as the owner, as the random other thread is too lazy to look up which thread stack the stack lock belongs to.

Because of that, I think we might miss locks that really are owned by a thread, as the thread key now will not map to such locks. Some kind of ownership lookup probably needs to happen here.

-------------

Changes requested by eosterlund (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/25

From xliu at openjdk.java.net  Thu Dec 16 06:50:41 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 16 Dec 2021 06:50:41 GMT
Subject: RFR: 8267517: async logging for stdout and stderr [v2]
In-Reply-To: <Nv1V5JHKgJh0NtqijGmWmI9Kh2VgDxgDIOAdfCtOavA=.503f41c2-a5d1-4a25-ab90-00252814a9bf@github.com>
References: <Nv1V5JHKgJh0NtqijGmWmI9Kh2VgDxgDIOAdfCtOavA=.503f41c2-a5d1-4a25-ab90-00252814a9bf@github.com>
Message-ID: <bClHRLnW6nYXU1OtsoS-vfQb9GjiP0OGY8cC5BsCTx0=.b085d99d-cf70-4d0c-988a-dd341a607680@github.com>

> This patch refactors LogFileStreamOutput so stdout/stderr can support support -Xlog:async.
> LogFileStreamOutput::flush() is virtual. 
> 
> With  `-Xlog:all=trace:stdout`, the helloworld in Java outputs 16520 log entries to stdout.  We are see that the wall time reduces from  86.977ms to 72.436ms, or the throughput increases 20% because of async logging.
> 
> 
> $perf stat -r 300 ./build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -Xlog:async -XX:AsyncLogBufferSize=48M HelloWorld > /dev/null
> 
>  Performance counter stats for './build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -Xlog:async -XX:AsyncLogBufferSize=48M HelloWorld' (300 runs):
> 
>             112.59 msec task-clock                #    1.554 CPUs utilized            ( +-  0.15% )
>              1,517      context-switches          #    0.013 M/sec                    ( +-  0.61% )
>                  1      cpu-migrations            #    0.010 K/sec                    ( +-  4.80% )
>              4,014      page-faults               #    0.036 M/sec                    ( +-  0.01% )
> ...
>           0.072436 +- 0.000135 seconds time elapsed  ( +-  0.19% )
> 
>  Performance counter stats for 'java -Xlog:all=trace:stdout  HelloWorld' (300 runs):
> 
>              90.73 msec task-clock                #    1.043 CPUs utilized            ( +-  0.11% )
>                318      context-switches          #    0.004 M/sec                    ( +-  0.32% )
>                  1      cpu-migrations            #    0.009 K/sec                    ( +-  4.80% )
>              4,010      page-faults               #    0.044 M/sec                    ( +-  0.00% )
> ...
>          0.0869777 +- 0.0000979 seconds time elapsed  ( +-  0.11% )
> 
> 
> In this patch, we also fold two locks(RotationLocker and FileLock) of LogFileOutput into one. FileLocker now can protect _stream from multiplexing and log rotation.  The other change is that AsyncLog writing doesn't require any lock protection because it's single-threaded. 
> 
> Add a new jtreg to cover a scenario that the blocked stdout doesn't freeze the JVM application.

Xin Liu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:

 - Refactor code. Remove JDK-8275083.
 - Merge branch 'master' into JDK-8267517
 - Remove the unused semaphore in LogFileOutput.
 - Merge branch 'master' into JDK-8267517
 - Fixed the regression test.
 - Fix the deadlock issue on single core.
   
   taskset 0x1 make test TEST='runtime/logging/BlockedLoggingTest.java'
 - Update the jtreg test.
 - Merge branch 'master' into JDK-8267517
 - Add a jtreg test to demonstrate -Xlog:async can prevent JVM from blocking
 - _locking_thread_id should be a member data of LogFileStreamOutput.
   
   This patch fixes two regressions. they have more than 1 active logging outputs.
   serviceability/logging/TestFullNames.java
   serviceability/logging/TestQuotedLogOutputs.java
   
    Please enter the commit message for your changes. Lines starting
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/d1013795...119a51dc

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6132/files
  - new: https://git.openjdk.java.net/jdk/pull/6132/files/45e15916..119a51dc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6132&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6132&range=00-01

  Stats: 23344 lines in 667 files changed: 17674 ins; 2610 del; 3060 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6132.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6132/head:pull/6132

PR: https://git.openjdk.java.net/jdk/pull/6132

From eosterlund at openjdk.java.net  Thu Dec 16 07:13:54 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 16 Dec 2021 07:13:54 GMT
Subject: RFR: 8268573: Remove expired flags in JDK 19
In-Reply-To: <1JzfCm_-QMikvfVrn1AdEFlYOS8KaPgEO2ZzaC3Smw8=.b43f45af-62e6-4561-a202-25c17a706d2f@github.com>
References: <1JzfCm_-QMikvfVrn1AdEFlYOS8KaPgEO2ZzaC3Smw8=.b43f45af-62e6-4561-a202-25c17a706d2f@github.com>
Message-ID: <-xiyIZW2CqQCIzccvzkU-gciX5Q3hgLP06lEBTE1270=.eb58fd86-5210-4607-afa0-4995c32ba9a8@github.com>

On Mon, 13 Dec 2021 22:17:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this simple change to remove all the flags that expired in JDK 19 from the flag table in arguments.cpp.
> 
> The java manpage is also updated as the UseBiasedLocking flag is moved from the "obsoleted" section, to the "removed" section. Plus we update the list of previous release docs.
> 
> Testing: local - all the runtime/CommandLine tests
> 
> Thanks,
> David

Looks good. Ship it!

-------------

Marked as reviewed by eosterlund (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6819

From rehn at openjdk.java.net  Thu Dec 16 07:30:00 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Thu, 16 Dec 2021 07:30:00 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null
In-Reply-To: <vTZzBhPz75XGSC6kXyC-dPEsyqqTldB3-amUvI6DArs=.36b56079-9ed0-4ee1-ad23-1d808f95751f@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
 <dG3-urCe2g2-F3KIdlJG7banTn17ovSO0Q7OpHFILHc=.c5baa018-6fb4-4364-84a5-98abc6fee0ff@github.com>
 <t1tGZVjK08iZD-be7vMS4k8g62tfn7PLVTSSz47jrvs=.506920ed-94b0-43ab-83d9-afacfb0ae09c@github.com>
 <vTZzBhPz75XGSC6kXyC-dPEsyqqTldB3-amUvI6DArs=.36b56079-9ed0-4ee1-ad23-1d808f95751f@github.com>
Message-ID: <p-wpXtGgeUmFbFTjmjXXmxGaJp2bU4G9ruPRNTdOso4=.f5727eb0-72b7-4402-9b3f-52115863c2d7@github.com>

On Wed, 15 Dec 2021 22:26:47 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Sounds like an interesting RFE, but I'd prefer that be investigated
>> separately from this bug.
>
> Clarification: ThreadStackTrace::is_owned_monitor_on_stack() is not actually
> walking the (JavaThread's) stack, but it is walking the collection of
> StackFrameInfo objects that was gathered earlier in
> ThreadStackTrace::dump_stack_at_safepoint(). Adding a gather-locked-monitor
> helper object to the "add_stack_frame()" call would provide an easy hook and
> then InflatedMonitorsClosure could use the new helper object. Something like
> that anyway...

Yes, sorry, we loop the stack frame info for every object. I.e. a loop in a loop which  is bad for time-complexity.
If the we created a sorted list from the frame info, we can binary search it instead.
Since a thread often only have at max a few locks, but could have hundreds of frames, just to be able skip looping over all frames without locks would be very beneficial.

-------------

PR: https://git.openjdk.java.net/jdk18/pull/25

From xliu at openjdk.java.net  Thu Dec 16 09:01:28 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 16 Dec 2021 09:01:28 GMT
Subject: RFR: 8267517: async logging for stdout and stderr [v3]
In-Reply-To: <Nv1V5JHKgJh0NtqijGmWmI9Kh2VgDxgDIOAdfCtOavA=.503f41c2-a5d1-4a25-ab90-00252814a9bf@github.com>
References: <Nv1V5JHKgJh0NtqijGmWmI9Kh2VgDxgDIOAdfCtOavA=.503f41c2-a5d1-4a25-ab90-00252814a9bf@github.com>
Message-ID: <ddwRuorCLqbH2zmw-PktIT9bm13hJ2jvNWJMX_1XQpo=.4f426bfb-b843-44c7-b935-fd748dd25db7@github.com>

> This patch refactors LogFileStreamOutput so stdout/stderr can support support -Xlog:async.
> 
> With  `-Xlog:all=trace:stdout`, the helloworld in Java outputs 16520 log entries to stdout.  We are see that the wall time reduces from  84.138ms to 72.914ms, or the throughput increases 15% because of async logging.
> 
> 
> $perf stat -r 300 ./build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -Xlog:async -XX:AsyncLogBufferSize=48M HelloWorld > /dev/null
> 
>  Performance counter stats for './build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -Xlog:async -XX:AsyncLogBufferSize=48M HelloWorld' (300 runs):
> 
>             107.21 msec task-clock                #    1.470 CPUs utilized            ( +-  0.17% )
>              2,681      context-switches          #    0.025 M/sec                    ( +-  0.32% )
>                  1      cpu-migrations            #    0.011 K/sec                    ( +-  4.56% )
>              4,006      page-faults               #    0.037 M/sec                    ( +-  0.01% )
> ...
>           0.072914 +- 0.000126 seconds time elapsed  ( +-  0.17% )
> 
>  Performance counter stats for './build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -XX:AsyncLogBufferSize=48M HelloWorld' (300 runs):
> 
>              88.04 msec task-clock                #    1.046 CPUs utilized            ( +-  0.10% )
>                310      context-switches          #    0.004 M/sec                    ( +-  0.31% )
>                  1      cpu-migrations            #    0.008 K/sec                    ( +-  5.07% )
>              4,004      page-faults               #    0.045 M/sec                    ( +-  0.01% )
> ...
>           0.084138 +- 0.000111 seconds time elapsed  ( +-  0.13% )
> 
> 
> The easiest test of stdout with AsyncLogging is to use tty and XOFF Ctrl^s. Java applications with UL to stdout were blocked by Ctrl-s. The entire java process will be frozen.  -Xlog:async now cover both stdout and stderr. It can circumvent this issue.  
> 
> Add a new jtreg to cover a scenario that unified logging with -Xlog:async will not be frozen even when stdout is blocked.

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo and the building eror on MacOS.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6132/files
  - new: https://git.openjdk.java.net/jdk/pull/6132/files/119a51dc..396f7cd1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6132&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6132&range=01-02

  Stats: 8 lines in 5 files changed: 2 ins; 1 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6132.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6132/head:pull/6132

PR: https://git.openjdk.java.net/jdk/pull/6132

From hseigel at openjdk.java.net  Thu Dec 16 13:47:15 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 16 Dec 2021 13:47:15 GMT
Subject: RFR: 8278384: Bytecodes::result_type() for arraylength returns T_VOID
 instead of T_INT
Message-ID: <SH69nDCYXXxfny7vxoENei0RSqJjvjafILRcSc62NQc=.289cf018-c6fb-4eda-b2cf-778ef9bac69f@github.com>

Please review this small change to specify T_INT instead of T_VOID as the return type for the arraylength bytecode.  The fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Solaris, and Mach5 tiers 3-5 on Linux x64.

Thanks, Harold

-------------

Commit messages:
 - 8278384: Bytecodes::result_type() for arraylength returns T_VOID instead of T_INT

Changes: https://git.openjdk.java.net/jdk/pull/6863/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6863&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278384
  Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6863.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6863/head:pull/6863

PR: https://git.openjdk.java.net/jdk/pull/6863

From lfoltan at openjdk.java.net  Thu Dec 16 14:38:53 2021
From: lfoltan at openjdk.java.net (Lois Foltan)
Date: Thu, 16 Dec 2021 14:38:53 GMT
Subject: RFR: 8278384: Bytecodes::result_type() for arraylength returns
 T_VOID instead of T_INT
In-Reply-To: <SH69nDCYXXxfny7vxoENei0RSqJjvjafILRcSc62NQc=.289cf018-c6fb-4eda-b2cf-778ef9bac69f@github.com>
References: <SH69nDCYXXxfny7vxoENei0RSqJjvjafILRcSc62NQc=.289cf018-c6fb-4eda-b2cf-778ef9bac69f@github.com>
Message-ID: <TMKYFZ2kiynKrs4ISNU6f-vjfO9OgVawB1i-3xGTrOs=.13142e33-5083-40ca-9d5f-3a1d253b7412@github.com>

On Thu, 16 Dec 2021 13:39:18 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small change to specify T_INT instead of T_VOID as the return type for the arraylength bytecode.  The fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Solaris, and Mach5 tiers 3-5 on Linux x64.
> 
> Thanks, Harold

Looks good.
Lois

-------------

Marked as reviewed by lfoltan (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6863

From dcubed at openjdk.java.net  Thu Dec 16 16:26:00 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 16 Dec 2021 16:26:00 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null
In-Reply-To: <dFnv0X9ls1jMp2OnZlNeTyHmEt1XBq2VPO1uUQ_Hrh0=.63e27e6c-8bde-4ddd-844d-2120f7ef6249@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
 <dFnv0X9ls1jMp2OnZlNeTyHmEt1XBq2VPO1uUQ_Hrh0=.63e27e6c-8bde-4ddd-844d-2120f7ef6249@github.com>
Message-ID: <FVBy2a7FRXjTYmxl1k6B8wkAOe3DV-wOe2k-kYZHayc=.c928da5e-6c62-4a68-a744-a90bab4cb8d2@github.com>

On Thu, 16 Dec 2021 06:44:03 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> RunThese24H sometimes times out with a couple of error msgs:
>> - "java.lang.management.ThreadInfo.getLockName()" is null
>> - ForkJoin common pool thread stuck
>> 
>> The '"java.lang.management.ThreadInfo.getLockName()" is null' error msg was
>> due to RunThese's use of an older JCK test suite which has since been fixed.
>> 
>> The 'ForkJoin common pool thread stuck' failure mode is likely due to a thread
>> spending a lot of time in ObjectSynchronizer::monitors_iterate() due to a
>> VM_ThreadDump::doit() call. I say "likely" because I've never been able to
>> reproduce this failure mode in testing outside of Mach5. With the Mach5
>> sightings, all we have are thread dumps and core files and not a live process.
>> 
>> The VM_ThreadDump::doit() call is trying to gather owned monitor information
>> for all threads in the system. I've seen sightings of this failure mode with > 2000
>> threads. I've also seen passing runs with > 1.7 million monitors on the in-use list.
>> Imagine searching a larger in-use list for > 2000 threads. It just doesn't scale.
>
> Looks okay, but I found a potential issue.

@fisk - Thanks for the review!

> src/hotspot/share/runtime/synchronizer.cpp line 79:
> 
>> 77:   if (list != nullptr) {
>> 78:     // Add to existing list from the hash table:
>> 79:     list->add(om);
> 
> These two lines are executed in both the if and else clause. Consider putting it after instead.

I'll take a look at doing that. Thanks for the suggestion.

> src/hotspot/share/runtime/synchronizer.cpp line 1062:
> 
>> 1060:                                           JavaThread* thread) {
>> 1061:   typedef LinkedListIterator<ObjectMonitor*> ObjectMonitorIterator;
>> 1062:   ObjectMonitorIterator iter = ObjectMonitorIterator(list->head());
> 
> This seems to create an object and then copy it to iter. I think the more obvious syntax is ObjectMonitorIterator iter(list->head());

Nice catch. I'll fix that.

> src/hotspot/share/runtime/synchronizer.cpp line 1423:
> 
>> 1421:       // deflate_idle_monitors() and deflate_monitor_list() can be called more than
>> 1422:       // once, we have to make sure the entry has not already been added.
>> 1423:       JavaThread* jt = (JavaThread*)mid->owner();
> 
> Hmmmm. I'm not sure this is correct. The owned of an ObjectMonitor is a JavaThread most of the time, but not always. I think that if the owner started off with a stack lock, and another thread inflated the lock due to contention, then the ObjectMonitor will get the stack lock as the owner, as the random other thread is too lazy to look up which thread stack the stack lock belongs to.
> 
> Because of that, I think we might miss locks that really are owned by a thread, as the thread key now will not map to such locks. Some kind of ownership lookup probably needs to happen here.

Nice catch on an oddity of ObjectMonitor ownership!

The baseline code has the same "issue":

`void ObjectSynchronizer::monitors_iterate(MonitorClosure* closure, JavaThread* thread) {`

`<snip>`


    ObjectMonitor* mid = iter.next();
    if (mid->owner() != thread) {
      continue;
    }


Please notice that I said "issue" and not "bug". This isn't a bug and you really
won't like the reason that it's not a bug. I know that I don't like it...

Because of this ownership check `monitors_iterate()` won't apply the closure
(InflatedMonitorsClosure in this case) to an ObjectMonitor that is marked as
owned by a stack lock address because it will never match the target JavaThread*.

Here's the closure:

// Iterate through monitor cache to find JNI locked monitors
class InflatedMonitorsClosure: public MonitorClosure {
private:
  ThreadStackTrace* _stack_trace;
public:
  InflatedMonitorsClosure(ThreadStackTrace* st) {
    _stack_trace = st;
  }
  void do_monitor(ObjectMonitor* mid) {
    oop object = mid->object();
    if (!_stack_trace->is_owned_monitor_on_stack(object)) {
      _stack_trace->add_jni_locked_monitor(object);
    }
  }
};


This particular monitors_iterate() call uses InflatedMonitorsClosure to
gather just the JNI locked monitors owned by the target JavaThread*.
A JNI locked monitor will never have a stack lock address as its owner
marking. It will always have a JavaThread*. So the baseline code isn't
"broken" because it will find the JNI locked monitors just fine. Similarly
the new code isn't "broken" because it will also find the JNI locked
monitors just fine.

I definitely need to clarify the baseline comments and the new code
comments to make this subtlety much more clear.

-------------

PR: https://git.openjdk.java.net/jdk18/pull/25

From hseigel at openjdk.java.net  Thu Dec 16 17:46:33 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 16 Dec 2021 17:46:33 GMT
Subject: RFR: 8225093: Special property jdk.boot.class.path.append should not
 default to empty string
Message-ID: <y8hiMnue6abZa0qUYXJOFg9sXbIYQ0x1LPCCId1z-oY=.359e3ed8-2fae-430c-9066-6e71ebea5027@github.com>

Please review this fix for JDK-8225093 to set the default value of property jdk.boot.class.path.append to NULL instead of "".  This fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.  The fix was also tested by running the agent.c example in JDK-8224791.

Thanks! Harold

-------------

Commit messages:
 - 8225093: Special property jdk.boot.class.path.append should not default to empty string

Changes: https://git.openjdk.java.net/jdk/pull/6868/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6868&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8225093
  Stats: 116 lines in 4 files changed: 114 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6868.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6868/head:pull/6868

PR: https://git.openjdk.java.net/jdk/pull/6868

From dcubed at openjdk.java.net  Thu Dec 16 20:08:24 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 16 Dec 2021 20:08:24 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null [v2]
In-Reply-To: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
Message-ID: <fwqIQm7WHmiaGjIrDiG2k9qy0MadREXK0P8lfvkfcno=.736de497-b55d-49a1-b220-afb583eab90e@github.com>

> RunThese24H sometimes times out with a couple of error msgs:
> - "java.lang.management.ThreadInfo.getLockName()" is null
> - ForkJoin common pool thread stuck
> 
> The '"java.lang.management.ThreadInfo.getLockName()" is null' error msg was
> due to RunThese's use of an older JCK test suite which has since been fixed.
> 
> The 'ForkJoin common pool thread stuck' failure mode is likely due to a thread
> spending a lot of time in ObjectSynchronizer::monitors_iterate() due to a
> VM_ThreadDump::doit() call. I say "likely" because I've never been able to
> reproduce this failure mode in testing outside of Mach5. With the Mach5
> sightings, all we have are thread dumps and core files and not a live process.
> 
> The VM_ThreadDump::doit() call is trying to gather owned monitor information
> for all threads in the system. I've seen sightings of this failure mode with > 2000
> threads. I've also seen passing runs with > 1.7 million monitors on the in-use list.
> Imagine searching a larger in-use list for > 2000 threads. It just doesn't scale.

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  fisk CR

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk18/pull/25/files
  - new: https://git.openjdk.java.net/jdk18/pull/25/files/ea4d83e9..3fac3684

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk18&pr=25&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk18&pr=25&range=00-01

  Stats: 40 lines in 3 files changed: 25 ins; 6 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/25.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/25/head:pull/25

PR: https://git.openjdk.java.net/jdk18/pull/25

From dcubed at openjdk.java.net  Thu Dec 16 20:12:04 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 16 Dec 2021 20:12:04 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null [v2]
In-Reply-To: <dFnv0X9ls1jMp2OnZlNeTyHmEt1XBq2VPO1uUQ_Hrh0=.63e27e6c-8bde-4ddd-844d-2120f7ef6249@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
 <dFnv0X9ls1jMp2OnZlNeTyHmEt1XBq2VPO1uUQ_Hrh0=.63e27e6c-8bde-4ddd-844d-2120f7ef6249@github.com>
Message-ID: <9uVyKAAArPQvaZSJ2q80ha3u0T8eaef8zyjcO0fDQFs=.d85ce855-96e6-4aa3-a318-ea6d35144080@github.com>

On Thu, 16 Dec 2021 06:44:03 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fisk CR
>
> Looks okay, but I found a potential issue.

I made changes to address @fisk's review. I've also included comment
updates to make clear the limitations of monitors_iterate(). I need a
re-review from @fisk and a re-review from @coleenp would also be
a nice thing to have. Thanks, in advance, for the re-review(s)...

Tested this latest patch with Mach5 Tier1. Mach5 Tier[23] are running now.

-------------

PR: https://git.openjdk.java.net/jdk18/pull/25

From dholmes at openjdk.java.net  Thu Dec 16 22:35:38 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 16 Dec 2021 22:35:38 GMT
Subject: RFR: 8268573: Remove expired flags in JDK 19
In-Reply-To: <-xiyIZW2CqQCIzccvzkU-gciX5Q3hgLP06lEBTE1270=.eb58fd86-5210-4607-afa0-4995c32ba9a8@github.com>
References: <1JzfCm_-QMikvfVrn1AdEFlYOS8KaPgEO2ZzaC3Smw8=.b43f45af-62e6-4561-a202-25c17a706d2f@github.com>
 <-xiyIZW2CqQCIzccvzkU-gciX5Q3hgLP06lEBTE1270=.eb58fd86-5210-4607-afa0-4995c32ba9a8@github.com>
Message-ID: <aHHIFn47gkwmKit1WO__2EX_0Onfoz8tqCxh3lPNELs=.7f3f5b5e-4cc1-4bb5-9c35-5b283d1fdd03@github.com>

On Thu, 16 Dec 2021 07:11:07 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Please review this simple change to remove all the flags that expired in JDK 19 from the flag table in arguments.cpp.
>> 
>> The java manpage is also updated as the UseBiasedLocking flag is moved from the "obsoleted" section, to the "removed" section. Plus we update the list of previous release docs.
>> 
>> Testing: local - all the runtime/CommandLine tests
>> 
>> Thanks,
>> David
>
> Looks good. Ship it!

Thanks @fisk !

-------------

PR: https://git.openjdk.java.net/jdk/pull/6819

From dholmes at openjdk.java.net  Thu Dec 16 22:35:44 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 16 Dec 2021 22:35:44 GMT
Subject: Integrated: 8268573: Remove expired flags in JDK 19
In-Reply-To: <1JzfCm_-QMikvfVrn1AdEFlYOS8KaPgEO2ZzaC3Smw8=.b43f45af-62e6-4561-a202-25c17a706d2f@github.com>
References: <1JzfCm_-QMikvfVrn1AdEFlYOS8KaPgEO2ZzaC3Smw8=.b43f45af-62e6-4561-a202-25c17a706d2f@github.com>
Message-ID: <APjv0VHR3ndAPaqBOg6RxhpI_hQdkilP9VXKVlW7qpU=.e45e6a64-9638-4ca5-87b0-3e8b36c4c230@github.com>

On Mon, 13 Dec 2021 22:17:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this simple change to remove all the flags that expired in JDK 19 from the flag table in arguments.cpp.
> 
> The java manpage is also updated as the UseBiasedLocking flag is moved from the "obsoleted" section, to the "removed" section. Plus we update the list of previous release docs.
> 
> Testing: local - all the runtime/CommandLine tests
> 
> Thanks,
> David

This pull request has now been integrated.

Changeset: 197c9f5a
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/197c9f5ac8cc0ebfcd9f33415b0dcd382cd8d15e
Stats:     29 lines in 2 files changed: 11 ins; 17 del; 1 mod

8268573: Remove expired flags in JDK 19

Reviewed-by: dcubed, pchilanomate, eosterlund

-------------

PR: https://git.openjdk.java.net/jdk/pull/6819

From dholmes at openjdk.java.net  Thu Dec 16 23:10:21 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 16 Dec 2021 23:10:21 GMT
Subject: RFR: 8270929: Obsolete the FilterSpuriousWakeups flag in JDK 19
Message-ID: <7B1TeSf9_w0oXtye1veIu-eMWwk9fMKTAZ454izOnV0=.b904c956-df22-4eca-a34f-61f2330ebd92@github.com>

Please review this small change to obsolete the `FilterSpuriousWakeups` flag that was deprecated in JDK 18.

There are no associated doc changes, nor test changes.

Testing: tier1-5 builds (in progress)

Thanks,
David

-------------

Commit messages:
 - 8270929: Obsolete the FilterSpuriousWakeups flag in JDK 19

Changes: https://git.openjdk.java.net/jdk/pull/6871/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6871&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8270929
  Stats: 9 lines in 3 files changed: 1 ins; 7 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6871.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6871/head:pull/6871

PR: https://git.openjdk.java.net/jdk/pull/6871

From cjplummer at openjdk.java.net  Thu Dec 16 23:28:37 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 16 Dec 2021 23:28:37 GMT
Subject: Integrated: 8276982: VM.class_hierarchy jcmd help output and man page
 text needs clarifications/improvements
In-Reply-To: <c2IkwHnl-Ktgth7fGN-f7MrHogrJoaU23WSQITNzxek=.1a559555-ac71-4d9d-a7da-cf31694cb6bb@github.com>
References: <c2IkwHnl-Ktgth7fGN-f7MrHogrJoaU23WSQITNzxek=.1a559555-ac71-4d9d-a7da-cf31694cb6bb@github.com>
Message-ID: <sr6scXkcqvscDse7zT0KG6Vd2koBHvjgSBFIvMPRFA0=.c7c5d83e-7fb8-48b9-8c11-e363929ed13f@github.com>

On Wed, 15 Dec 2021 03:08:40 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Clarify the help output for VM.class_hierarchy. The old jcmd help output was misleading, and because of this got translated incorrectly for the man page.

This pull request has now been integrated.

Changeset: 7ce4aa89
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7ce4aa894279b76b6033bb4a1d0caa00d4213406
Stats:     6 lines in 2 files changed: 1 ins; 0 del; 5 mod

8276982: VM.class_hierarchy jcmd help output and man page text needs clarifications/improvements

Reviewed-by: stuefe, dholmes, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/6845

From dcubed at openjdk.java.net  Fri Dec 17 01:25:00 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 17 Dec 2021 01:25:00 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null [v3]
In-Reply-To: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
Message-ID: <W10Y3Tx2ozTToMB_ucnBxraM23OR9n_GXh0Q674nJAE=.c9368675-91d8-4f14-9680-bdeaad1b7fd0@github.com>

> RunThese24H sometimes times out with a couple of error msgs:
> - "java.lang.management.ThreadInfo.getLockName()" is null
> - ForkJoin common pool thread stuck
> 
> The '"java.lang.management.ThreadInfo.getLockName()" is null' error msg was
> due to RunThese's use of an older JCK test suite which has since been fixed.
> 
> The 'ForkJoin common pool thread stuck' failure mode is likely due to a thread
> spending a lot of time in ObjectSynchronizer::monitors_iterate() due to a
> VM_ThreadDump::doit() call. I say "likely" because I've never been able to
> reproduce this failure mode in testing outside of Mach5. With the Mach5
> sightings, all we have are thread dumps and core files and not a live process.
> 
> The VM_ThreadDump::doit() call is trying to gather owned monitor information
> for all threads in the system. I've seen sightings of this failure mode with > 2000
> threads. I've also seen passing runs with > 1.7 million monitors on the in-use list.
> Imagine searching a larger in-use list for > 2000 threads. It just doesn't scale.

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  coleenp CR - cleanup type safety

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk18/pull/25/files
  - new: https://git.openjdk.java.net/jdk18/pull/25/files/3fac3684..d1ca83e7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk18&pr=25&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk18&pr=25&range=01-02

  Stats: 23 lines in 2 files changed: 2 ins; 1 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/25.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/25/head:pull/25

PR: https://git.openjdk.java.net/jdk18/pull/25

From dcubed at openjdk.java.net  Fri Dec 17 01:33:25 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 17 Dec 2021 01:33:25 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null [v3]
In-Reply-To: <W10Y3Tx2ozTToMB_ucnBxraM23OR9n_GXh0Q674nJAE=.c9368675-91d8-4f14-9680-bdeaad1b7fd0@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
 <W10Y3Tx2ozTToMB_ucnBxraM23OR9n_GXh0Q674nJAE=.c9368675-91d8-4f14-9680-bdeaad1b7fd0@github.com>
Message-ID: <aFcEVStmTgDHYnessdfRrr15sBO9ry-NINJ5QLcyXts=.990fbfa2-7a02-466a-bfae-853d8d57859b@github.com>

On Fri, 17 Dec 2021 01:25:00 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> RunThese24H sometimes times out with a couple of error msgs:
>> - "java.lang.management.ThreadInfo.getLockName()" is null
>> - ForkJoin common pool thread stuck
>> 
>> The '"java.lang.management.ThreadInfo.getLockName()" is null' error msg was
>> due to RunThese's use of an older JCK test suite which has since been fixed.
>> 
>> The 'ForkJoin common pool thread stuck' failure mode is likely due to a thread
>> spending a lot of time in ObjectSynchronizer::monitors_iterate() due to a
>> VM_ThreadDump::doit() call. I say "likely" because I've never been able to
>> reproduce this failure mode in testing outside of Mach5. With the Mach5
>> sightings, all we have are thread dumps and core files and not a live process.
>> 
>> The VM_ThreadDump::doit() call is trying to gather owned monitor information
>> for all threads in the system. I've seen sightings of this failure mode with > 2000
>> threads. I've also seen passing runs with > 1.7 million monitors on the in-use list.
>> Imagine searching a larger in-use list for > 2000 threads. It just doesn't scale.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   coleenp CR - cleanup type safety

The `ObjectMonitor::_owner` field can contain a `JavaThread*`, the address of
a `BasicLock` on a JavaThread's stack, `nullptr` or `DEFLATER_MARKER` so the
`_owner` field is of type `void*`.

@coleenp pointed out off-line that I had a bit of type confusion in my new
`ObjectMonitorsHashtable`. Instead of indexing the Hashtable with a
`JavaThread*`, I should be indexing the Hashtable with a `void*` to reflect
the fact that my `_owner` field can be a `JavaThread*` or the address of a
`BasicLock` on the JavaThread's stack.

My most recent push to this PR cleans up the type confusion. This update
is tested with Mach5 Tier1 as a sanity check.

-------------

PR: https://git.openjdk.java.net/jdk18/pull/25

From dholmes at openjdk.java.net  Fri Dec 17 02:26:25 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 17 Dec 2021 02:26:25 GMT
Subject: RFR: 8225093: Special property jdk.boot.class.path.append should
 not default to empty string
In-Reply-To: <y8hiMnue6abZa0qUYXJOFg9sXbIYQ0x1LPCCId1z-oY=.359e3ed8-2fae-430c-9066-6e71ebea5027@github.com>
References: <y8hiMnue6abZa0qUYXJOFg9sXbIYQ0x1LPCCId1z-oY=.359e3ed8-2fae-430c-9066-6e71ebea5027@github.com>
Message-ID: <CzBxog1NDOJ1e5Zb6nKmQn0jyUpy0U3KXXjd2Vyv17g=.bd0f62cc-cbf5-4463-a97f-6c8aaeba4796@github.com>

On Thu, 16 Dec 2021 17:33:29 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this fix for JDK-8225093 to set the default value of property jdk.boot.class.path.append to NULL instead of "".  This fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.  The fix was also tested by running the agent.c example in JDK-8224791.
> 
> Thanks! Harold

Hi Harold,

Change looks good and I've Reviewed the CSR request.

One nit in the test.

Thanks,
David

test/hotspot/jtreg/runtime/BootClassAppendProp/GetBootClassPathAppendProp.java line 40:

> 38: 
> 39:     public static void main(String[] args) throws Exception {
> 40:         String vm_info_jvmti = getSystemProperty();

Nit: strange name and doesn't follow Java style rules. Won't "path" suffice?

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6868

From dholmes at openjdk.java.net  Fri Dec 17 02:36:25 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 17 Dec 2021 02:36:25 GMT
Subject: RFR: 8278125: Some preallocated OOMEs are missing stack trace [v3]
In-Reply-To: <yoaT87337KQzVF-xRpopBnEIMf6YQNV9Ec1Gs4n2ewI=.55c29c27-27fd-4d77-b6d8-fd466be6ca9e@github.com>
References: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
 <yoaT87337KQzVF-xRpopBnEIMf6YQNV9Ec1Gs4n2ewI=.55c29c27-27fd-4d77-b6d8-fd466be6ca9e@github.com>
Message-ID: <okBlPMjEWBDcUtfQupEXJ5miYRRclGA2S8PiF1UL2bs=.2653a4af-a39a-4f8a-9786-e24d2a3cbc33@github.com>

On Mon, 6 Dec 2021 08:02:50 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> Our customer found that the PreallocatedOutOfMemoryErrorCount is 4 by default. It ought to pre-allocate 4 OOMEs with stack trace, but in fact, no matter how many OOMEs are thrown, only 2 OOMEs have proper stack trace. This is because PreallocatedOutOfMemoryErrorCount is consumed multiple times:
>> 
>> VM tries to allocate a huge object while Java heap is insufficient to accommodate, it goes to:
>> 
>> https://github.com/openjdk/jdk/blob/b79554bb5cef14590d427543a40efbcc60c66548/src/hotspot/share/gc/shared/memAllocator.cpp#L115-L136
>> 
>> Line 135(`Universe::out_of_memory_error_java_heap`->`Universe::gen_out_of_memory_error`) and line 136(`THROW_OOP_`->`Exceptions::_throw`->`Exceptions::count_out_of_memory_exceptions`->`Universe::out_of_memory_error_java_heap`->`Universe::gen_out_of_memory_error`) call `Universe::gen_out_of_memory_error` twice in a single OOM event, which leads this unexpected scenario. Proposed fix is to remove such call in `Exceptions::count_out_of_memory_exceptions`.
>> 
>> Thanks.
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   newline before eof

Github UI is making the review comments appear in strange order/places. See the "files" view to see the comments in context.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6672

From dholmes at openjdk.java.net  Fri Dec 17 02:36:27 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 17 Dec 2021 02:36:27 GMT
Subject: RFR: 8278125: Some preallocated OOMEs are missing stack trace [v2]
In-Reply-To: <AV2S-29XpWTCQh7mToBLRWh4bVMo_BygEMA44T_bXkc=.a38aa64b-0a70-4b63-b8d7-b646de83e936@github.com>
References: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
 <AV2S-29XpWTCQh7mToBLRWh4bVMo_BygEMA44T_bXkc=.a38aa64b-0a70-4b63-b8d7-b646de83e936@github.com>
Message-ID: <6jsGoTLd2APHWBC-qKAErwJvGl4ykjuSFSBiswNiP2o=.6cb86838-23c9-4fdb-a4d8-05e50bc80f10@github.com>

On Fri, 3 Dec 2021 05:51:48 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> Our customer found that the PreallocatedOutOfMemoryErrorCount is 4 by default. It ought to pre-allocate 4 OOMEs with stack trace, but in fact, no matter how many OOMEs are thrown, only 2 OOMEs have proper stack trace. This is because PreallocatedOutOfMemoryErrorCount is consumed multiple times:
>> 
>> VM tries to allocate a huge object while Java heap is insufficient to accommodate, it goes to:
>> 
>> https://github.com/openjdk/jdk/blob/b79554bb5cef14590d427543a40efbcc60c66548/src/hotspot/share/gc/shared/memAllocator.cpp#L115-L136
>> 
>> Line 135(`Universe::out_of_memory_error_java_heap`->`Universe::gen_out_of_memory_error`) and line 136(`THROW_OOP_`->`Exceptions::_throw`->`Exceptions::count_out_of_memory_exceptions`->`Universe::out_of_memory_error_java_heap`->`Universe::gen_out_of_memory_error`) call `Universe::gen_out_of_memory_error` twice in a single OOM event, which leads this unexpected scenario. Proposed fix is to remove such call in `Exceptions::count_out_of_memory_exceptions`.
>> 
>> Thanks.
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Universe::is_out_of_memory_xx

test/hotspot/jtreg/runtime/ErrorHandling/GenOutOfMemoryError.java line 60:

> 58:         Asserts.assertTrue(4/*PreallocatedOutOfMemoryErrorCount is default to 4*/ == OOME_HAS_STACK_CNT, "Some OOMEs do not have stacktraces");
> 59:     }
> 60: }

You need a newline at the end of the file

-------------

PR: https://git.openjdk.java.net/jdk/pull/6672

From dholmes at openjdk.java.net  Fri Dec 17 02:36:26 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 17 Dec 2021 02:36:26 GMT
Subject: RFR: 8278125: Some preallocated OOMEs are missing stack trace [v2]
In-Reply-To: <qmqXtfjVDPZMAMACTGIIXBuYkt5kL46o3zWf-6TKbWk=.b2c40abc-779d-43a5-a8d2-e18723181985@github.com>
References: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
 <AV2S-29XpWTCQh7mToBLRWh4bVMo_BygEMA44T_bXkc=.a38aa64b-0a70-4b63-b8d7-b646de83e936@github.com>
 <JI4SopPkSGJetYlJz7IYDcYU9vrumqm-MMx6m6QtqvI=.ed6b31c3-dca3-4e76-9829-505590a79a3a@github.com>
 <qmqXtfjVDPZMAMACTGIIXBuYkt5kL46o3zWf-6TKbWk=.b2c40abc-779d-43a5-a8d2-e18723181985@github.com>
Message-ID: <r0HXlP6H30peMpZq5UpF5oWrVMP0qLN9XM6hQrwPZC8=.3b387880-bfc7-41fa-8534-07d6c942393e@github.com>

On Wed, 15 Dec 2021 16:52:32 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/memory/universe.cpp line 597:
>> 
>>> 595:   const char * msg_str = java_lang_String::as_utf8_string(msg_oop);
>>> 596:   return strcmp(msg, msg_str) == 0;
>>> 597: }
>> 
>> Yes, I agree with David about strcmp.  Could you add this instead (it was trying to compare the oops for equality, and unintentionally generated a new one).
>> 
>> oop Universe::is_out_of_memory_error_metaspace(oop exception) {
>>   return out_of_memory_errors()->obj_at(_oom_metaspace)) == exception;
>> }
>
> Ok, I see how this isn't right, but I still don't like the strcmp.  Can the string be interned and checked for equality?  Otherwise you also need a ResourceMark here.

We are comparing a `char*` and a Java String (the message from the Exception oop), so we either convert the Java String to a `char*` and compare them with `strcmp` as shown; or we turn the incoming `char*` into a Java String and then use `java_lang_String::equals`. The latter is an expensive operation and more importantly creating the String requires an allocation when we are trying to throw an OutOfMemoryError! So I don't see a reasonable alternative to the `strcmp`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6672

From dholmes at openjdk.java.net  Fri Dec 17 02:39:29 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 17 Dec 2021 02:39:29 GMT
Subject: RFR: 8278384: Bytecodes::result_type() for arraylength returns
 T_VOID instead of T_INT
In-Reply-To: <SH69nDCYXXxfny7vxoENei0RSqJjvjafILRcSc62NQc=.289cf018-c6fb-4eda-b2cf-778ef9bac69f@github.com>
References: <SH69nDCYXXxfny7vxoENei0RSqJjvjafILRcSc62NQc=.289cf018-c6fb-4eda-b2cf-778ef9bac69f@github.com>
Message-ID: <EgYxyI-vI92EL6Gwlk9jcMOMGebeWbsigNGUMY_U9zE=.5a7601e0-cb18-4704-aedf-67ad6bbd9398@github.com>

On Thu, 16 Dec 2021 13:39:18 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small change to specify T_INT instead of T_VOID as the return type for the arraylength bytecode.  The fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.
> 
> Thanks, Harold

Fix looks fine but I have to wonder what the actual affect is? Shouldn't this wrong type have been detected somewhere or caused an error ??

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6863

From sspitsyn at openjdk.java.net  Fri Dec 17 03:21:32 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Fri, 17 Dec 2021 03:21:32 GMT
Subject: RFR: 8225093: Special property jdk.boot.class.path.append should
 not default to empty string
In-Reply-To: <y8hiMnue6abZa0qUYXJOFg9sXbIYQ0x1LPCCId1z-oY=.359e3ed8-2fae-430c-9066-6e71ebea5027@github.com>
References: <y8hiMnue6abZa0qUYXJOFg9sXbIYQ0x1LPCCId1z-oY=.359e3ed8-2fae-430c-9066-6e71ebea5027@github.com>
Message-ID: <3kIIfQj2ARKIReNLCxZHDypdwn5V25xrfuzSBhB8QWo=.64e91214-5a8e-4e47-a784-3413b7098f27@github.com>

On Thu, 16 Dec 2021 17:33:29 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this fix for JDK-8225093 to set the default value of property jdk.boot.class.path.append to NULL instead of "".  This fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.  The fix was also tested by running the agent.c example in JDK-8224791.
> 
> Thanks! Harold

Hi Harold,
The fix looks good to me.
Thanks,
Serguei

test/hotspot/jtreg/runtime/BootClassAppendProp/GetBootClassPathAppendProp.java line 26:

> 24: /**
> 25:  * @test
> 26:  * @bug 8224791

The 8224791 has been closed. Should it be replaced with 8225093?

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6868

From eosterlund at openjdk.java.net  Fri Dec 17 07:21:23 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 17 Dec 2021 07:21:23 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null [v3]
In-Reply-To: <dFnv0X9ls1jMp2OnZlNeTyHmEt1XBq2VPO1uUQ_Hrh0=.63e27e6c-8bde-4ddd-844d-2120f7ef6249@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
 <dFnv0X9ls1jMp2OnZlNeTyHmEt1XBq2VPO1uUQ_Hrh0=.63e27e6c-8bde-4ddd-844d-2120f7ef6249@github.com>
Message-ID: <3RHtIcIafNrBeuv1sZtRUFHRhhi91wd5JUGKmOPCWc0=.6809d6a6-e4c8-4891-bc6a-3eeab72b57df@github.com>

On Thu, 16 Dec 2021 06:44:03 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   coleenp CR - cleanup type safety
>
> Looks okay, but I found a potential issue.

> I made changes to address @fisk's review. I've also included comment
> 
> updates to make clear the limitations of monitors_iterate(). I need a
> 
> re-review from @fisk and a re-review from @coleenp would also be
> 
> a nice thing to have. Thanks, in advance, for the re-review(s)...
> 
> 
> 
> Tested this latest patch with Mach5 Tier1. Mach5 Tier[23] are running now.
> 
> 
> 
> Update: Mach5 Tier[1-5] look good.

When the owner field of an ObjectMonitor is the address of a stack lock instead of a thread, it doesn't mean that it is a stack lock. It means that it *was* a stack lock when it was acquired by that thread, but has since then been upgraded to a full ObjectMonitor (by another thread), due to contention. But the fact that it *was* a stack lock is irrelevant in this context; we care about what it is now. And it is an inflated lock that just happens to have a slightly obscured owner field, as the owner thread was not easily available when it was inflated.

In other words, I still believe this is a bug. Such a monitor that gets upgraded from a stack lock to a full ObjectMonitor, can - unline actual stack locks - be involved in a deadlock that we are trying to find. If we don't associate such ObjectMonitor objects with its owner thread, then we will not be able to find the deadlock as we are supposed to with this code.

-------------

PR: https://git.openjdk.java.net/jdk18/pull/25

From hseigel at openjdk.java.net  Fri Dec 17 13:44:01 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 17 Dec 2021 13:44:01 GMT
Subject: RFR: 8225093: Special property jdk.boot.class.path.append should
 not default to empty string [v2]
In-Reply-To: <y8hiMnue6abZa0qUYXJOFg9sXbIYQ0x1LPCCId1z-oY=.359e3ed8-2fae-430c-9066-6e71ebea5027@github.com>
References: <y8hiMnue6abZa0qUYXJOFg9sXbIYQ0x1LPCCId1z-oY=.359e3ed8-2fae-430c-9066-6e71ebea5027@github.com>
Message-ID: <YaHH68n9B3rV1b9aMsevk9J2XILFHZIlQdy8jPFhXJI=.529e9d6f-aa76-476d-9ce7-5f6caa4af807@github.com>

> Please review this fix for JDK-8225093 to set the default value of property jdk.boot.class.path.append to NULL instead of "".  This fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.  The fix was also tested by running the agent.c example in JDK-8224791.
> 
> Thanks! Harold

Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:

  fix test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6868/files
  - new: https://git.openjdk.java.net/jdk/pull/6868/files/bd80b91b..a1c9218b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6868&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6868&range=00-01

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6868.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6868/head:pull/6868

PR: https://git.openjdk.java.net/jdk/pull/6868

From hseigel at openjdk.java.net  Fri Dec 17 13:44:03 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 17 Dec 2021 13:44:03 GMT
Subject: RFR: 8225093: Special property jdk.boot.class.path.append should
 not default to empty string
In-Reply-To: <y8hiMnue6abZa0qUYXJOFg9sXbIYQ0x1LPCCId1z-oY=.359e3ed8-2fae-430c-9066-6e71ebea5027@github.com>
References: <y8hiMnue6abZa0qUYXJOFg9sXbIYQ0x1LPCCId1z-oY=.359e3ed8-2fae-430c-9066-6e71ebea5027@github.com>
Message-ID: <ywwVKDCoQP9taCaDltzqRbghTG_13rfMvZ1x83w1nxA=.3d904b91-2f2f-4336-b5f3-a81f6dbe290e@github.com>

On Thu, 16 Dec 2021 17:33:29 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this fix for JDK-8225093 to set the default value of property jdk.boot.class.path.append to NULL instead of "".  This fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.  The fix was also tested by running the agent.c example in JDK-8224791.
> 
> Thanks! Harold

Thanks David and Serguei for reviewing this, and thanks David for reviewing the CSR.

Harold

-------------

PR: https://git.openjdk.java.net/jdk/pull/6868

From hseigel at openjdk.java.net  Fri Dec 17 13:44:06 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 17 Dec 2021 13:44:06 GMT
Subject: RFR: 8225093: Special property jdk.boot.class.path.append should
 not default to empty string [v2]
In-Reply-To: <3kIIfQj2ARKIReNLCxZHDypdwn5V25xrfuzSBhB8QWo=.64e91214-5a8e-4e47-a784-3413b7098f27@github.com>
References: <y8hiMnue6abZa0qUYXJOFg9sXbIYQ0x1LPCCId1z-oY=.359e3ed8-2fae-430c-9066-6e71ebea5027@github.com>
 <3kIIfQj2ARKIReNLCxZHDypdwn5V25xrfuzSBhB8QWo=.64e91214-5a8e-4e47-a784-3413b7098f27@github.com>
Message-ID: <m2F5pPvaL24b9yQ9qV7tcaYKIrxIz6vcWJRXAgZXKoI=.b445983d-844c-4349-98c4-bebecd128852@github.com>

On Fri, 17 Dec 2021 03:17:23 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix test
>
> test/hotspot/jtreg/runtime/BootClassAppendProp/GetBootClassPathAppendProp.java line 26:
> 
>> 24: /**
>> 25:  * @test
>> 26:  * @bug 8224791
> 
> The 8224791 has been closed. Should it be replaced with 8225093?

Yes!  Thanks for pointing that out.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6868

From hseigel at openjdk.java.net  Fri Dec 17 13:44:08 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 17 Dec 2021 13:44:08 GMT
Subject: RFR: 8225093: Special property jdk.boot.class.path.append should
 not default to empty string [v2]
In-Reply-To: <CzBxog1NDOJ1e5Zb6nKmQn0jyUpy0U3KXXjd2Vyv17g=.bd0f62cc-cbf5-4463-a97f-6c8aaeba4796@github.com>
References: <y8hiMnue6abZa0qUYXJOFg9sXbIYQ0x1LPCCId1z-oY=.359e3ed8-2fae-430c-9066-6e71ebea5027@github.com>
 <CzBxog1NDOJ1e5Zb6nKmQn0jyUpy0U3KXXjd2Vyv17g=.bd0f62cc-cbf5-4463-a97f-6c8aaeba4796@github.com>
Message-ID: <UueO4Jj5kV7X52wrDN3MYhcIUilZVmw9wvqvSuEErq8=.c116499f-c281-4650-9a7a-a15b2c29043a@github.com>

On Fri, 17 Dec 2021 02:18:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix test
>
> test/hotspot/jtreg/runtime/BootClassAppendProp/GetBootClassPathAppendProp.java line 40:
> 
>> 38: 
>> 39:     public static void main(String[] args) throws Exception {
>> 40:         String vm_info_jvmti = getSystemProperty();
> 
> Nit: strange name and doesn't follow Java style rules. Won't "path" suffice?

The strange name comes from the test that I copied to write this one.  I'll change it to 'path'.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6868

From coleenp at openjdk.java.net  Fri Dec 17 14:38:30 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 17 Dec 2021 14:38:30 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null [v3]
In-Reply-To: <W10Y3Tx2ozTToMB_ucnBxraM23OR9n_GXh0Q674nJAE=.c9368675-91d8-4f14-9680-bdeaad1b7fd0@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
 <W10Y3Tx2ozTToMB_ucnBxraM23OR9n_GXh0Q674nJAE=.c9368675-91d8-4f14-9680-bdeaad1b7fd0@github.com>
Message-ID: <OPKmF_l6m9TI4_ms0S4OZqUBUoefM6YhQKU6ia90v9g=.d416306d-dbff-4c6c-accf-363cd5b5249d@github.com>

On Fri, 17 Dec 2021 01:25:00 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> RunThese24H sometimes times out with a couple of error msgs:
>> - "java.lang.management.ThreadInfo.getLockName()" is null
>> - ForkJoin common pool thread stuck
>> 
>> The '"java.lang.management.ThreadInfo.getLockName()" is null' error msg was
>> due to RunThese's use of an older JCK test suite which has since been fixed.
>> 
>> The 'ForkJoin common pool thread stuck' failure mode is likely due to a thread
>> spending a lot of time in ObjectSynchronizer::monitors_iterate() due to a
>> VM_ThreadDump::doit() call. I say "likely" because I've never been able to
>> reproduce this failure mode in testing outside of Mach5. With the Mach5
>> sightings, all we have are thread dumps and core files and not a live process.
>> 
>> The VM_ThreadDump::doit() call is trying to gather owned monitor information
>> for all threads in the system. I've seen sightings of this failure mode with > 2000
>> threads. I've also seen passing runs with > 1.7 million monitors on the in-use list.
>> Imagine searching a larger in-use list for > 2000 threads. It just doesn't scale.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   coleenp CR - cleanup type safety

Approve again. This makes me a lot happier.

Re: both Robbin's and Erik's comments. I think Robbin's should be an RFE and Erik's should be another bug report and fixed separately.  This change fixes the timeout that's been observed multiple times and preserves existing behavior (with existing bugs). I think some redesign is in order to make this correct all the time.

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/25

From hseigel at openjdk.java.net  Fri Dec 17 14:51:21 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 17 Dec 2021 14:51:21 GMT
Subject: RFR: 8270929: Obsolete the FilterSpuriousWakeups flag in JDK 19
In-Reply-To: <7B1TeSf9_w0oXtye1veIu-eMWwk9fMKTAZ454izOnV0=.b904c956-df22-4eca-a34f-61f2330ebd92@github.com>
References: <7B1TeSf9_w0oXtye1veIu-eMWwk9fMKTAZ454izOnV0=.b904c956-df22-4eca-a34f-61f2330ebd92@github.com>
Message-ID: <LeVuypetgccBv6Spk5YJtKmSuyFpJojENHdw_i8hmCs=.b11b35f0-7478-4030-b0fb-149c848fbb59@github.com>

On Thu, 16 Dec 2021 23:03:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this small change to obsolete the `FilterSpuriousWakeups` flag that was deprecated in JDK 18.
> 
> There are no associated doc changes, nor test changes.
> 
> Testing: tier1-5 builds (in progress)
> 
> Thanks,
> David

Changes look good and trivial.
Thanks, Harold

-------------

Marked as reviewed by hseigel (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6871

From hseigel at openjdk.java.net  Fri Dec 17 15:14:29 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 17 Dec 2021 15:14:29 GMT
Subject: RFR: 8278384: Bytecodes::result_type() for arraylength returns
 T_VOID instead of T_INT
In-Reply-To: <SH69nDCYXXxfny7vxoENei0RSqJjvjafILRcSc62NQc=.289cf018-c6fb-4eda-b2cf-778ef9bac69f@github.com>
References: <SH69nDCYXXxfny7vxoENei0RSqJjvjafILRcSc62NQc=.289cf018-c6fb-4eda-b2cf-778ef9bac69f@github.com>
Message-ID: <t7NmM_zalTJGEM7bOVcKJZS9gCStQkeuITwe7XBAyWM=.29303ce0-6cd4-48a4-a7db-deb7373d4bd1@github.com>

On Thu, 16 Dec 2021 13:39:18 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small change to specify T_INT instead of T_VOID as the return type for the arraylength bytecode.  The fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.
> 
> Thanks, Harold

Thanks Lois and David for the reviews.

In some cases, such as in this code in ExceptionMessageBuilder::do_instruction(int bci), a work-around was used to avoid the bug:


    case Bytecodes::_newarray:
    case Bytecodes::_anewarray:
    case Bytecodes::_instanceof:
      stack->pop(1);
      stack->push(bci, Bytecodes::result_type(code));
      break;

    case Bytecodes::_arraylength:
      // The return type of arraylength is wrong in the bytecodes table (T_VOID).
      stack->pop(1);
      stack->push(bci, T_INT);
      break;


In other cases, as mentioned in JBS-8278384, this issue caused a crash when running test CanonicalizeArrayLength.java with options -XX:+DeoptimizeALot -XX:+VerifyStack.  I ran test CanonicalizeArrayLength.java with those options several times, with the fix, and was unable to reproduce the crash.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6863

From hseigel at openjdk.java.net  Fri Dec 17 15:14:30 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 17 Dec 2021 15:14:30 GMT
Subject: Integrated: 8278384: Bytecodes::result_type() for arraylength returns
 T_VOID instead of T_INT
In-Reply-To: <SH69nDCYXXxfny7vxoENei0RSqJjvjafILRcSc62NQc=.289cf018-c6fb-4eda-b2cf-778ef9bac69f@github.com>
References: <SH69nDCYXXxfny7vxoENei0RSqJjvjafILRcSc62NQc=.289cf018-c6fb-4eda-b2cf-778ef9bac69f@github.com>
Message-ID: <F9aYVhhkhnUeSuY9WSma_9nzy1K_9Lcu0s5sJcFx5Y8=.0fabcfff-475d-4d33-85f5-fc96997c5fa5@github.com>

On Thu, 16 Dec 2021 13:39:18 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small change to specify T_INT instead of T_VOID as the return type for the arraylength bytecode.  The fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.
> 
> Thanks, Harold

This pull request has now been integrated.

Changeset: 769f14db
Author:    Harold Seigel <hseigel at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/769f14db847813f5a3601e9ec21e6cadbd99ee96
Stats:     3 lines in 2 files changed: 0 ins; 1 del; 2 mod

8278384: Bytecodes::result_type() for arraylength returns T_VOID instead of T_INT

Reviewed-by: lfoltan, dholmes

-------------

PR: https://git.openjdk.java.net/jdk/pull/6863

From eosterlund at openjdk.java.net  Fri Dec 17 15:28:29 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 17 Dec 2021 15:28:29 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null [v3]
In-Reply-To: <W10Y3Tx2ozTToMB_ucnBxraM23OR9n_GXh0Q674nJAE=.c9368675-91d8-4f14-9680-bdeaad1b7fd0@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
 <W10Y3Tx2ozTToMB_ucnBxraM23OR9n_GXh0Q674nJAE=.c9368675-91d8-4f14-9680-bdeaad1b7fd0@github.com>
Message-ID: <5DPCYJroGcR0n5Zk21lmBdGSjt-yM-4dUyfe4WkY4Qs=.87af3be6-b454-46e7-b434-0a3e2f2d1cbe@github.com>

On Fri, 17 Dec 2021 01:25:00 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> RunThese24H sometimes times out with a couple of error msgs:
>> - "java.lang.management.ThreadInfo.getLockName()" is null
>> - ForkJoin common pool thread stuck
>> 
>> The '"java.lang.management.ThreadInfo.getLockName()" is null' error msg was
>> due to RunThese's use of an older JCK test suite which has since been fixed.
>> 
>> The 'ForkJoin common pool thread stuck' failure mode is likely due to a thread
>> spending a lot of time in ObjectSynchronizer::monitors_iterate() due to a
>> VM_ThreadDump::doit() call. I say "likely" because I've never been able to
>> reproduce this failure mode in testing outside of Mach5. With the Mach5
>> sightings, all we have are thread dumps and core files and not a live process.
>> 
>> The VM_ThreadDump::doit() call is trying to gather owned monitor information
>> for all threads in the system. I've seen sightings of this failure mode with > 2000
>> threads. I've also seen passing runs with > 1.7 million monitors on the in-use list.
>> Imagine searching a larger in-use list for > 2000 threads. It just doesn't scale.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   coleenp CR - cleanup type safety

If the bug I pointed out is filed separately, then this looks good.

-------------

Marked as reviewed by eosterlund (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/25

From rehn at openjdk.java.net  Fri Dec 17 15:28:30 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Fri, 17 Dec 2021 15:28:30 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null [v3]
In-Reply-To: <W10Y3Tx2ozTToMB_ucnBxraM23OR9n_GXh0Q674nJAE=.c9368675-91d8-4f14-9680-bdeaad1b7fd0@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
 <W10Y3Tx2ozTToMB_ucnBxraM23OR9n_GXh0Q674nJAE=.c9368675-91d8-4f14-9680-bdeaad1b7fd0@github.com>
Message-ID: <_FcgMruJwBvYo8Yq4KdvPYWw8yxFaLDfM4LdVGMR0BI=.88c78584-bacf-4eb1-83e5-8577af84d6d1@github.com>

On Fri, 17 Dec 2021 01:25:00 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> RunThese24H sometimes times out with a couple of error msgs:
>> - "java.lang.management.ThreadInfo.getLockName()" is null
>> - ForkJoin common pool thread stuck
>> 
>> The '"java.lang.management.ThreadInfo.getLockName()" is null' error msg was
>> due to RunThese's use of an older JCK test suite which has since been fixed.
>> 
>> The 'ForkJoin common pool thread stuck' failure mode is likely due to a thread
>> spending a lot of time in ObjectSynchronizer::monitors_iterate() due to a
>> VM_ThreadDump::doit() call. I say "likely" because I've never been able to
>> reproduce this failure mode in testing outside of Mach5. With the Mach5
>> sightings, all we have are thread dumps and core files and not a live process.
>> 
>> The VM_ThreadDump::doit() call is trying to gather owned monitor information
>> for all threads in the system. I've seen sightings of this failure mode with > 2000
>> threads. I've also seen passing runs with > 1.7 million monitors on the in-use list.
>> Imagine searching a larger in-use list for > 2000 threads. It just doesn't scale.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   coleenp CR - cleanup type safety

Marked as reviewed by rehn (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk18/pull/25

From eosterlund at openjdk.java.net  Fri Dec 17 15:28:30 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 17 Dec 2021 15:28:30 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null [v3]
In-Reply-To: <OPKmF_l6m9TI4_ms0S4OZqUBUoefM6YhQKU6ia90v9g=.d416306d-dbff-4c6c-accf-363cd5b5249d@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
 <W10Y3Tx2ozTToMB_ucnBxraM23OR9n_GXh0Q674nJAE=.c9368675-91d8-4f14-9680-bdeaad1b7fd0@github.com>
 <OPKmF_l6m9TI4_ms0S4OZqUBUoefM6YhQKU6ia90v9g=.d416306d-dbff-4c6c-accf-363cd5b5249d@github.com>
Message-ID: <o4MwobEZcaMnTzWsWKEPfP02l7PQkEGg4ggU3DX3Eaw=.e92f3d33-d561-4867-9db0-fe10377d8ba9@github.com>

On Fri, 17 Dec 2021 14:34:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Re: both Robbin's and Erik's comments. I think Robbin's should be an RFE and Erik's should be another bug report and fixed separately. This change fixes the timeout that's been observed multiple times and preserves existing behavior (with existing bugs). I think some redesign is in order to make this correct all the time.

I'm okay with fixing the other bug in a separate RFR.

-------------

PR: https://git.openjdk.java.net/jdk18/pull/25

From eosterlund at openjdk.java.net  Fri Dec 17 15:55:24 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 17 Dec 2021 15:55:24 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null [v3]
In-Reply-To: <W10Y3Tx2ozTToMB_ucnBxraM23OR9n_GXh0Q674nJAE=.c9368675-91d8-4f14-9680-bdeaad1b7fd0@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
 <W10Y3Tx2ozTToMB_ucnBxraM23OR9n_GXh0Q674nJAE=.c9368675-91d8-4f14-9680-bdeaad1b7fd0@github.com>
Message-ID: <25sIgWO6dSAS2aWetASPMI39sNFCmLWbL_epHxicZ-U=.f1b5b8f5-8ac3-4c6f-836e-fae0cf113101@github.com>

On Fri, 17 Dec 2021 01:25:00 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> RunThese24H sometimes times out with a couple of error msgs:
>> - "java.lang.management.ThreadInfo.getLockName()" is null
>> - ForkJoin common pool thread stuck
>> 
>> The '"java.lang.management.ThreadInfo.getLockName()" is null' error msg was
>> due to RunThese's use of an older JCK test suite which has since been fixed.
>> 
>> The 'ForkJoin common pool thread stuck' failure mode is likely due to a thread
>> spending a lot of time in ObjectSynchronizer::monitors_iterate() due to a
>> VM_ThreadDump::doit() call. I say "likely" because I've never been able to
>> reproduce this failure mode in testing outside of Mach5. With the Mach5
>> sightings, all we have are thread dumps and core files and not a live process.
>> 
>> The VM_ThreadDump::doit() call is trying to gather owned monitor information
>> for all threads in the system. I've seen sightings of this failure mode with > 2000
>> threads. I've also seen passing runs with > 1.7 million monitors on the in-use list.
>> Imagine searching a larger in-use list for > 2000 threads. It just doesn't scale.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   coleenp CR - cleanup type safety

For the record, Threads::owning_thread_from_monitor_owner seems to be the function to look up who *really* own an ObjectMonitor, based on the value in the owner field, to deal with the stuff I talked about.

-------------

PR: https://git.openjdk.java.net/jdk18/pull/25

From dcubed at openjdk.java.net  Fri Dec 17 19:56:36 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 17 Dec 2021 19:56:36 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null [v3]
In-Reply-To: <OPKmF_l6m9TI4_ms0S4OZqUBUoefM6YhQKU6ia90v9g=.d416306d-dbff-4c6c-accf-363cd5b5249d@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
 <W10Y3Tx2ozTToMB_ucnBxraM23OR9n_GXh0Q674nJAE=.c9368675-91d8-4f14-9680-bdeaad1b7fd0@github.com>
 <OPKmF_l6m9TI4_ms0S4OZqUBUoefM6YhQKU6ia90v9g=.d416306d-dbff-4c6c-accf-363cd5b5249d@github.com>
Message-ID: <xyLa8lLF617NPO4nVPXcon21YjvZ3BTkP5f2xf7NC2s=.813eb350-1410-41f8-a1f7-309fe90a753d@github.com>

On Fri, 17 Dec 2021 14:34:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   coleenp CR - cleanup type safety
>
> Re: both Robbin's and Erik's comments. I think Robbin's should be an RFE and Erik's should be another bug report and fixed separately.  This change fixes the timeout that's been observed multiple times and preserves existing behavior (with existing bugs). I think some redesign is in order to make this correct all the time.

@coleenp, @fisk and @robehn - Thanks for the re-reviews and the approvals.

-------------

PR: https://git.openjdk.java.net/jdk18/pull/25

From dcubed at openjdk.java.net  Fri Dec 17 20:43:30 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 17 Dec 2021 20:43:30 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null [v3]
In-Reply-To: <25sIgWO6dSAS2aWetASPMI39sNFCmLWbL_epHxicZ-U=.f1b5b8f5-8ac3-4c6f-836e-fae0cf113101@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
 <W10Y3Tx2ozTToMB_ucnBxraM23OR9n_GXh0Q674nJAE=.c9368675-91d8-4f14-9680-bdeaad1b7fd0@github.com>
 <25sIgWO6dSAS2aWetASPMI39sNFCmLWbL_epHxicZ-U=.f1b5b8f5-8ac3-4c6f-836e-fae0cf113101@github.com>
Message-ID: <anaRF8-j8CxM4H31k-ArpSe7iXi_psq7idkVvcolPkE=.e626b4b8-dec6-47d0-82cd-34058dbe9b98@github.com>

On Fri, 17 Dec 2021 15:52:31 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   coleenp CR - cleanup type safety
>
> For the record, Threads::owning_thread_from_monitor_owner seems to be the function to look up who *really* own an ObjectMonitor, based on the value in the owner field, to deal with the stuff I talked about.

I need to address these comments from @fisk:

> When the owner field of an ObjectMonitor is the address of a stack lock instead
> of a thread, it doesn't mean that it is a stack lock. It means that it was a stack
> lock when it was acquired by that thread, but has since then been upgraded to
> a full ObjectMonitor (by another thread), due to contention. But the fact that it
> was a stack lock is irrelevant in this context; we care about what it is now. And
> it is an inflated lock that just happens to have a slightly obscured owner field,
> as the owner thread was not easily available when it was inflated.

What @fisk says here is correct and I'm probably guilty of over simplifying what
I was trying to explain earlier. Here's what I said earlier for context:

>> The baseline code has the same "issue":
>>
>> void ObjectSynchronizer::monitors_iterate(MonitorClosure* closure, JavaThread* thread) {
>>
>> <snip>
>>
>>     ObjectMonitor* mid = iter.next();
>>     if (mid->owner() != thread) {
>>       continue;
>>     }
>> Please notice that I said "issue" and not "bug". This isn't a bug and you really
>> won't like the reason that it's not a bug. I know that I don't like it...
>> 
>> Because of this ownership check monitors_iterate() won't apply the closure
>> (InflatedMonitorsClosure in this case) to an ObjectMonitor that is marked as
>> owned by a stack lock address because it will never match the target JavaThread*.

@fisk, please notice that I don't say that this is a stack lock. I say this is

>> an ObjectMonitor that is marked as owned by a stack lock address

and that is the "bug" in your opinion. The baseline code and new code
do not recognize that the owner is not a JavaThread* and don't apply
the closure even though the stack lock address might belong to the
current target JavaThread.

I think we are in strong agreement about what the attributes of the "bug" are.


> In other words, I still believe this is a bug. Such a monitor that gets upgraded
> from a stack lock to a full ObjectMonitor, can - unline actual stack locks - be
> involved in a deadlock that we are trying to find. If we don't associate such
> ObjectMonitor objects with its owner thread, then we will not be able to find
> the deadlock as we are supposed to with this code.

You are missing part of the algorithm in the code that calls monitors_iterate().
The monitors_iterate() part ONLY EXISTS to find the JNI locked ObjectMonitors.
It does that by finding all of the ObjectMonitors on the in-use list that are owned
by the target JavaThread* (and by owned I mean _owner == JavaThread*). It uses
the closure to search for each matched ObjectMonitor* in the JavaThread's stack
info that it squirreled away before making the call to monitors_iterate(). If it finds
the ObjectMonitor* on the JavaThread's stack, then that ObjectMonitor* IS NOT
a JNI locked ObjectMonitor and monitors_iterate() ignores it.

If monitors_iterate() does not find the ObjectMonitor* in the JavaThread's stack
info, then it assumes that the ObjectMonitor* is a JNI locked monitor and it adds
that ObjectMonitor* to the thread dump info.

Because an ObjectMonitor that is marked as owned by a stack lock address won't
match the target JavaThread*, it won't get processed by the closure that is called
by monitors_iterate(). However, we don't care because that ObjectMonitor* IS NOT
a JNI locked monitor and that is what monitors_iterate() is looking for. It must be a
monitor that is mentioned in the JavaThread's stack because it was acquired that
way originally so it will ALREADY be included in the thread's info that was gathered
before we made the monitors_iterate() call. Nothing is missed here!

I have tried to clarify this in the comments that I added as part of this patch. I'll
re-review the comments again and see if there is anything else I can add or change.

-------------

PR: https://git.openjdk.java.net/jdk18/pull/25

From dcubed at openjdk.java.net  Fri Dec 17 20:51:24 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 17 Dec 2021 20:51:24 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null [v3]
In-Reply-To: <_FcgMruJwBvYo8Yq4KdvPYWw8yxFaLDfM4LdVGMR0BI=.88c78584-bacf-4eb1-83e5-8577af84d6d1@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
 <W10Y3Tx2ozTToMB_ucnBxraM23OR9n_GXh0Q674nJAE=.c9368675-91d8-4f14-9680-bdeaad1b7fd0@github.com>
 <_FcgMruJwBvYo8Yq4KdvPYWw8yxFaLDfM4LdVGMR0BI=.88c78584-bacf-4eb1-83e5-8577af84d6d1@github.com>
Message-ID: <I5EreosAAkEe3gJsEfFXnvagjilqjEbv1obhRcrQlYk=.66501562-ba18-4400-a062-97b33eee558c@github.com>

On Fri, 17 Dec 2021 15:25:32 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   coleenp CR - cleanup type safety
>
> Marked as reviewed by rehn (Reviewer).

I've filed the following RFE for @robehn's improvement:

JDK-8278968 InflatedMonitorsClosure repeats walks of StackFrameInfo and should cache instead
https://bugs.openjdk.java.net/browse/JDK-8278968

-------------

PR: https://git.openjdk.java.net/jdk18/pull/25

From dcubed at openjdk.java.net  Fri Dec 17 21:24:03 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 17 Dec 2021 21:24:03 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null [v4]
In-Reply-To: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
Message-ID: <LJO33_9Y4qxETy89efSgypta2PU_noWYaqqzUB_YT4k=.e6554aec-ebb6-4217-a7bf-6f853948b8bc@github.com>

> RunThese24H sometimes times out with a couple of error msgs:
> - "java.lang.management.ThreadInfo.getLockName()" is null
> - ForkJoin common pool thread stuck
> 
> The '"java.lang.management.ThreadInfo.getLockName()" is null' error msg was
> due to RunThese's use of an older JCK test suite which has since been fixed.
> 
> The 'ForkJoin common pool thread stuck' failure mode is likely due to a thread
> spending a lot of time in ObjectSynchronizer::monitors_iterate() due to a
> VM_ThreadDump::doit() call. I say "likely" because I've never been able to
> reproduce this failure mode in testing outside of Mach5. With the Mach5
> sightings, all we have are thread dumps and core files and not a live process.
> 
> The VM_ThreadDump::doit() call is trying to gather owned monitor information
> for all threads in the system. I've seen sightings of this failure mode with > 2000
> threads. I've also seen passing runs with > 1.7 million monitors on the in-use list.
> Imagine searching a larger in-use list for > 2000 threads. It just doesn't scale.

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  Rename 'jt_count' to 'key_count'.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk18/pull/25/files
  - new: https://git.openjdk.java.net/jdk18/pull/25/files/d1ca83e7..d980013e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk18&pr=25&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk18&pr=25&range=02-03

  Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/25.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/25/head:pull/25

PR: https://git.openjdk.java.net/jdk18/pull/25

From dcubed at openjdk.java.net  Fri Dec 17 21:28:30 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 17 Dec 2021 21:28:30 GMT
Subject: [jdk18] Integrated: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null
In-Reply-To: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
Message-ID: <QQbZh9dR4mGK1qTSUzU8o5kC3qoL1Ipx84oQV0WIRGk=.6e4af6fa-25c1-4ddc-ac97-73871cf30c66@github.com>

On Tue, 14 Dec 2021 21:16:02 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> RunThese24H sometimes times out with a couple of error msgs:
> - "java.lang.management.ThreadInfo.getLockName()" is null
> - ForkJoin common pool thread stuck
> 
> The '"java.lang.management.ThreadInfo.getLockName()" is null' error msg was
> due to RunThese's use of an older JCK test suite which has since been fixed.
> 
> The 'ForkJoin common pool thread stuck' failure mode is likely due to a thread
> spending a lot of time in ObjectSynchronizer::monitors_iterate() due to a
> VM_ThreadDump::doit() call. I say "likely" because I've never been able to
> reproduce this failure mode in testing outside of Mach5. With the Mach5
> sightings, all we have are thread dumps and core files and not a live process.
> 
> The VM_ThreadDump::doit() call is trying to gather owned monitor information
> for all threads in the system. I've seen sightings of this failure mode with > 2000
> threads. I've also seen passing runs with > 1.7 million monitors on the in-use list.
> Imagine searching a larger in-use list for > 2000 threads. It just doesn't scale.

This pull request has now been integrated.

Changeset: a5f5d60f
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/a5f5d60f2529bb28eee6d309bfbde904e188e540
Stats:     207 lines in 8 files changed: 184 ins; 0 del; 23 mod

8273107: RunThese24H times out with "java.lang.management.ThreadInfo.getLockName()" is null

Reviewed-by: rehn, coleenp, eosterlund

-------------

PR: https://git.openjdk.java.net/jdk18/pull/25

From dlong at openjdk.java.net  Fri Dec 17 21:40:30 2021
From: dlong at openjdk.java.net (Dean Long)
Date: Fri, 17 Dec 2021 21:40:30 GMT
Subject: RFR: 8278384: Bytecodes::result_type() for arraylength returns
 T_VOID instead of T_INT
In-Reply-To: <EgYxyI-vI92EL6Gwlk9jcMOMGebeWbsigNGUMY_U9zE=.5a7601e0-cb18-4704-aedf-67ad6bbd9398@github.com>
References: <SH69nDCYXXxfny7vxoENei0RSqJjvjafILRcSc62NQc=.289cf018-c6fb-4eda-b2cf-778ef9bac69f@github.com>
 <EgYxyI-vI92EL6Gwlk9jcMOMGebeWbsigNGUMY_U9zE=.5a7601e0-cb18-4704-aedf-67ad6bbd9398@github.com>
Message-ID: <2-9stCDzBt9-EypqwqlJRbzmkAq00YPQwV3QpsOiimY=.b2921fab-5123-47de-b62b-4cb318a17b37@github.com>

On Fri, 17 Dec 2021 02:36:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Fix looks fine but I have to wonder what the actual affect is? Shouldn't this wrong type have been detected somewhere or caused an error ??
> 
> Thanks, David

(Sorry for the late comment, just saw this)

Yes, FTR, the effects were mostly unobservable because of workarounds.  There was an off-by-one problem with C1 debug info that could only be observed with -XX:+VerifyStack and stricter verification logic I was working on.

After this change, we could remove the workarounds.  For example, in the switch example above, the case for  Bytecodes::_arraylength can be combined with the group above.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6863

From eosterlund at openjdk.java.net  Fri Dec 17 21:43:24 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 17 Dec 2021 21:43:24 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null [v4]
In-Reply-To: <LJO33_9Y4qxETy89efSgypta2PU_noWYaqqzUB_YT4k=.e6554aec-ebb6-4217-a7bf-6f853948b8bc@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
 <LJO33_9Y4qxETy89efSgypta2PU_noWYaqqzUB_YT4k=.e6554aec-ebb6-4217-a7bf-6f853948b8bc@github.com>
Message-ID: <KzWaM452kbuAYIDzLgkwHorC8epNvVvMaGxtK-RwKQA=.7674bb7f-1ef5-47f7-84e4-39ceefdc15a2@github.com>

On Fri, 17 Dec 2021 21:24:03 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> RunThese24H sometimes times out with a couple of error msgs:
>> - "java.lang.management.ThreadInfo.getLockName()" is null
>> - ForkJoin common pool thread stuck
>> 
>> The '"java.lang.management.ThreadInfo.getLockName()" is null' error msg was
>> due to RunThese's use of an older JCK test suite which has since been fixed.
>> 
>> The 'ForkJoin common pool thread stuck' failure mode is likely due to a thread
>> spending a lot of time in ObjectSynchronizer::monitors_iterate() due to a
>> VM_ThreadDump::doit() call. I say "likely" because I've never been able to
>> reproduce this failure mode in testing outside of Mach5. With the Mach5
>> sightings, all we have are thread dumps and core files and not a live process.
>> 
>> The VM_ThreadDump::doit() call is trying to gather owned monitor information
>> for all threads in the system. I've seen sightings of this failure mode with > 2000
>> threads. I've also seen passing runs with > 1.7 million monitors on the in-use list.
>> Imagine searching a larger in-use list for > 2000 threads. It just doesn't scale.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename 'jt_count' to 'key_count'.

I guess you can recursively JNI lock an ObjectMonitor, that has been promoted from a stack lock. Then it's a lock held by JNI and we won't report it here.

But this is JVMTI code so there is probably some other random check somewhere else that checks for that so I'm just going to assume this works somehow.

Ship it!

-------------

Marked as reviewed by eosterlund (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/25

From dcubed at openjdk.java.net  Fri Dec 17 21:52:34 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 17 Dec 2021 21:52:34 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null [v3]
In-Reply-To: <25sIgWO6dSAS2aWetASPMI39sNFCmLWbL_epHxicZ-U=.f1b5b8f5-8ac3-4c6f-836e-fae0cf113101@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
 <W10Y3Tx2ozTToMB_ucnBxraM23OR9n_GXh0Q674nJAE=.c9368675-91d8-4f14-9680-bdeaad1b7fd0@github.com>
 <25sIgWO6dSAS2aWetASPMI39sNFCmLWbL_epHxicZ-U=.f1b5b8f5-8ac3-4c6f-836e-fae0cf113101@github.com>
Message-ID: <bxL4BJVbh9uX7NNpf95UzNRRqdt9kKFvaNTMfSU-4ko=.aa5cc4a1-e6d2-4487-b9d0-79ad21f4e0d0@github.com>

On Fri, 17 Dec 2021 15:52:31 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   coleenp CR - cleanup type safety
>
> For the record, Threads::owning_thread_from_monitor_owner seems to be the function to look up who *really* own an ObjectMonitor, based on the value in the owner field, to deal with the stuff I talked about.

@fisk - Thanks for closing the loop on this thread.

-------------

PR: https://git.openjdk.java.net/jdk18/pull/25

From dcubed at openjdk.java.net  Fri Dec 17 21:52:34 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 17 Dec 2021 21:52:34 GMT
Subject: [jdk18] RFR: 8273107: RunThese24H times out with
 "java.lang.management.ThreadInfo.getLockName()" is null [v4]
In-Reply-To: <LJO33_9Y4qxETy89efSgypta2PU_noWYaqqzUB_YT4k=.e6554aec-ebb6-4217-a7bf-6f853948b8bc@github.com>
References: <tSS9j_9HYjJRA17AUzFjOU4ceHjAj2J8TMPfEb9BD7I=.8208ea8a-9f83-4b34-8b30-4bcff31c0edb@github.com>
 <LJO33_9Y4qxETy89efSgypta2PU_noWYaqqzUB_YT4k=.e6554aec-ebb6-4217-a7bf-6f853948b8bc@github.com>
Message-ID: <zkvWRxOgrFlGGSi0J6VkJMaAj4RoAPYATFnFtpy6bxQ=.ba88f02f-e586-4d93-83ae-11b2ac766e16@github.com>

On Fri, 17 Dec 2021 21:24:03 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> RunThese24H sometimes times out with a couple of error msgs:
>> - "java.lang.management.ThreadInfo.getLockName()" is null
>> - ForkJoin common pool thread stuck
>> 
>> The '"java.lang.management.ThreadInfo.getLockName()" is null' error msg was
>> due to RunThese's use of an older JCK test suite which has since been fixed.
>> 
>> The 'ForkJoin common pool thread stuck' failure mode is likely due to a thread
>> spending a lot of time in ObjectSynchronizer::monitors_iterate() due to a
>> VM_ThreadDump::doit() call. I say "likely" because I've never been able to
>> reproduce this failure mode in testing outside of Mach5. With the Mach5
>> sightings, all we have are thread dumps and core files and not a live process.
>> 
>> The VM_ThreadDump::doit() call is trying to gather owned monitor information
>> for all threads in the system. I've seen sightings of this failure mode with > 2000
>> threads. I've also seen passing runs with > 1.7 million monitors on the in-use list.
>> Imagine searching a larger in-use list for > 2000 threads. It just doesn't scale.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename 'jt_count' to 'key_count'.

If you recursively JNI lock an ObjectMonitor that has been promoted from a stack lock,
then I think the code will update the _owner field from the address of the original stack
lock to the owning JavaThread*. Only the owning JavaThread can recursively enter an
existing ObjectMonitor and only the owning JavaThread can update that _owner field...

-------------

PR: https://git.openjdk.java.net/jdk18/pull/25

From dholmes at openjdk.java.net  Fri Dec 17 22:49:24 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 17 Dec 2021 22:49:24 GMT
Subject: RFR: 8270929: Obsolete the FilterSpuriousWakeups flag in JDK 19
In-Reply-To: <LeVuypetgccBv6Spk5YJtKmSuyFpJojENHdw_i8hmCs=.b11b35f0-7478-4030-b0fb-149c848fbb59@github.com>
References: <7B1TeSf9_w0oXtye1veIu-eMWwk9fMKTAZ454izOnV0=.b904c956-df22-4eca-a34f-61f2330ebd92@github.com>
 <LeVuypetgccBv6Spk5YJtKmSuyFpJojENHdw_i8hmCs=.b11b35f0-7478-4030-b0fb-149c848fbb59@github.com>
Message-ID: <J5GVMwzQjDbqiM3BWMZyFAJV7Wv34TzEKD8DziOhwYU=.5477fac5-3562-49bf-b414-3bbcaff84d12@github.com>

On Fri, 17 Dec 2021 14:47:57 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this small change to obsolete the `FilterSpuriousWakeups` flag that was deprecated in JDK 18.
>> 
>> There are no associated doc changes, nor test changes.
>> 
>> Testing: tier1-5 builds (in progress)
>> 
>> Thanks,
>> David
>
> Changes look good and trivial.
> Thanks, Harold

Thanks @hseigel ! It is a simple change but not quite trivial per the guidelines, so I'll wait for a second review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6871

From dholmes at openjdk.java.net  Sat Dec 18 00:47:28 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 18 Dec 2021 00:47:28 GMT
Subject: RFR: 8225093: Special property jdk.boot.class.path.append should
 not default to empty string [v2]
In-Reply-To: <YaHH68n9B3rV1b9aMsevk9J2XILFHZIlQdy8jPFhXJI=.529e9d6f-aa76-476d-9ce7-5f6caa4af807@github.com>
References: <y8hiMnue6abZa0qUYXJOFg9sXbIYQ0x1LPCCId1z-oY=.359e3ed8-2fae-430c-9066-6e71ebea5027@github.com>
 <YaHH68n9B3rV1b9aMsevk9J2XILFHZIlQdy8jPFhXJI=.529e9d6f-aa76-476d-9ce7-5f6caa4af807@github.com>
Message-ID: <KjwZ4PV_Iayio7auM1ORfnNP68IjjPAki_0zLTP7IOs=.4bf2e5a8-88f1-4826-a7a6-97f4b84fa20d@github.com>

On Fri, 17 Dec 2021 13:44:01 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this fix for JDK-8225093 to set the default value of property jdk.boot.class.path.append to NULL instead of "".  This fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.  The fix was also tested by running the agent.c example in JDK-8224791.
>> 
>> Thanks! Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix test

Marked as reviewed by dholmes (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6868

From rehn at openjdk.java.net  Mon Dec 20 07:43:23 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Mon, 20 Dec 2021 07:43:23 GMT
Subject: RFR: 8270929: Obsolete the FilterSpuriousWakeups flag in JDK 19
In-Reply-To: <7B1TeSf9_w0oXtye1veIu-eMWwk9fMKTAZ454izOnV0=.b904c956-df22-4eca-a34f-61f2330ebd92@github.com>
References: <7B1TeSf9_w0oXtye1veIu-eMWwk9fMKTAZ454izOnV0=.b904c956-df22-4eca-a34f-61f2330ebd92@github.com>
Message-ID: <Ywk1u2_4gkl3UTFqxeYm2Fyh13NCRLpxT9seFz9QaNY=.9c601367-d056-49cf-b935-1ab747fdc4d7@github.com>

On Thu, 16 Dec 2021 23:03:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this small change to obsolete the `FilterSpuriousWakeups` flag that was deprecated in JDK 18.
> 
> There are no associated doc changes, nor test changes.
> 
> Testing: tier1-5 builds (in progress)
> 
> Thanks,
> David

Ship it!

-------------

Marked as reviewed by rehn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6871

From sspitsyn at openjdk.java.net  Mon Dec 20 09:47:25 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Mon, 20 Dec 2021 09:47:25 GMT
Subject: RFR: 8225093: Special property jdk.boot.class.path.append should
 not default to empty string [v2]
In-Reply-To: <YaHH68n9B3rV1b9aMsevk9J2XILFHZIlQdy8jPFhXJI=.529e9d6f-aa76-476d-9ce7-5f6caa4af807@github.com>
References: <y8hiMnue6abZa0qUYXJOFg9sXbIYQ0x1LPCCId1z-oY=.359e3ed8-2fae-430c-9066-6e71ebea5027@github.com>
 <YaHH68n9B3rV1b9aMsevk9J2XILFHZIlQdy8jPFhXJI=.529e9d6f-aa76-476d-9ce7-5f6caa4af807@github.com>
Message-ID: <uA5IJ6tEnEOpgZjwsM6DjDYbsMngPizqpwfwHVAdwA4=.1ee4d4b8-b521-415d-9bba-336aad23a40e@github.com>

On Fri, 17 Dec 2021 13:44:01 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this fix for JDK-8225093 to set the default value of property jdk.boot.class.path.append to NULL instead of "".  This fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.  The fix was also tested by running the agent.c example in JDK-8224791.
>> 
>> Thanks! Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix test

Marked as reviewed by sspitsyn (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6868

From dholmes at openjdk.java.net  Mon Dec 20 10:51:26 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 20 Dec 2021 10:51:26 GMT
Subject: RFR: 8270929: Obsolete the FilterSpuriousWakeups flag in JDK 19
In-Reply-To: <Ywk1u2_4gkl3UTFqxeYm2Fyh13NCRLpxT9seFz9QaNY=.9c601367-d056-49cf-b935-1ab747fdc4d7@github.com>
References: <7B1TeSf9_w0oXtye1veIu-eMWwk9fMKTAZ454izOnV0=.b904c956-df22-4eca-a34f-61f2330ebd92@github.com>
 <Ywk1u2_4gkl3UTFqxeYm2Fyh13NCRLpxT9seFz9QaNY=.9c601367-d056-49cf-b935-1ab747fdc4d7@github.com>
Message-ID: <pEIRM2t9kJIxWbk6-sIXO3aaIqu7G8azVXOnOJLC4Ek=.b41d2ea7-4d45-418b-af16-d36b9528b23a@github.com>

On Mon, 20 Dec 2021 07:40:14 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Please review this small change to obsolete the `FilterSpuriousWakeups` flag that was deprecated in JDK 18.
>> 
>> There are no associated doc changes, nor test changes.
>> 
>> Testing: tier1-5 builds (in progress)
>> 
>> Thanks,
>> David
>
> Ship it!

Thanks @robehn !

-------------

PR: https://git.openjdk.java.net/jdk/pull/6871

From dholmes at openjdk.java.net  Mon Dec 20 10:51:27 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 20 Dec 2021 10:51:27 GMT
Subject: Integrated: 8270929: Obsolete the FilterSpuriousWakeups flag in JDK 19
In-Reply-To: <7B1TeSf9_w0oXtye1veIu-eMWwk9fMKTAZ454izOnV0=.b904c956-df22-4eca-a34f-61f2330ebd92@github.com>
References: <7B1TeSf9_w0oXtye1veIu-eMWwk9fMKTAZ454izOnV0=.b904c956-df22-4eca-a34f-61f2330ebd92@github.com>
Message-ID: <PhYd8UQnWZ0pL3O33qG3Uuu3UXUMVIXrRC2bcBCj6MQ=.3e699a04-abb5-4cbb-b0f5-5949f5658461@github.com>

On Thu, 16 Dec 2021 23:03:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this small change to obsolete the `FilterSpuriousWakeups` flag that was deprecated in JDK 18.
> 
> There are no associated doc changes, nor test changes.
> 
> Testing: tier1-5 builds (in progress)
> 
> Thanks,
> David

This pull request has now been integrated.

Changeset: 4c78c9ab
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4c78c9ab80202b426efd8f6cc3533d642ae9ba19
Stats:     9 lines in 3 files changed: 1 ins; 7 del; 1 mod

8270929: Obsolete the FilterSpuriousWakeups flag in JDK 19

Reviewed-by: hseigel, rehn

-------------

PR: https://git.openjdk.java.net/jdk/pull/6871

From alanb at openjdk.java.net  Mon Dec 20 17:37:22 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 20 Dec 2021 17:37:22 GMT
Subject: RFR: 8225093: Special property jdk.boot.class.path.append should
 not default to empty string [v2]
In-Reply-To: <YaHH68n9B3rV1b9aMsevk9J2XILFHZIlQdy8jPFhXJI=.529e9d6f-aa76-476d-9ce7-5f6caa4af807@github.com>
References: <y8hiMnue6abZa0qUYXJOFg9sXbIYQ0x1LPCCId1z-oY=.359e3ed8-2fae-430c-9066-6e71ebea5027@github.com>
 <YaHH68n9B3rV1b9aMsevk9J2XILFHZIlQdy8jPFhXJI=.529e9d6f-aa76-476d-9ce7-5f6caa4af807@github.com>
Message-ID: <utajbk5GFZuQ7Typ8RksN45Byc2il61fsllA12yUJcA=.addb4580-1b10-4c9c-9cce-7d45af40a600@github.com>

On Fri, 17 Dec 2021 13:44:01 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this fix for JDK-8225093 to set the default value of property jdk.boot.class.path.append to NULL instead of "".  This fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.  The fix was also tested by running the agent.c example in JDK-8224791.
>> 
>> Thanks! Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix test

Marked as reviewed by alanb (Reviewer).

test/hotspot/jtreg/runtime/BootClassAppendProp/libGetBootClassPathAppendProp.c line 53:

> 51:   if (err != JVMTI_ERROR_NONE) {
> 52:     return (*env)->NewStringUTF(env, "wrong error code");
> 53:   }

For diagnosability it may be helpful to have this native method throw an exception with the JVMTI error code or alternatively have the return String include the error code rather than a generic message "wrong error code".

-------------

PR: https://git.openjdk.java.net/jdk/pull/6868

From hseigel at openjdk.java.net  Mon Dec 20 18:36:45 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 20 Dec 2021 18:36:45 GMT
Subject: RFR: 8225093: Special property jdk.boot.class.path.append should
 not default to empty string [v3]
In-Reply-To: <y8hiMnue6abZa0qUYXJOFg9sXbIYQ0x1LPCCId1z-oY=.359e3ed8-2fae-430c-9066-6e71ebea5027@github.com>
References: <y8hiMnue6abZa0qUYXJOFg9sXbIYQ0x1LPCCId1z-oY=.359e3ed8-2fae-430c-9066-6e71ebea5027@github.com>
Message-ID: <yjY_zdrZ9PLqc4oqmpjA0qhLY2klpV1xTMFRA-LWdBA=.31cdd09b-636e-4be9-a639-417b910a38b0@github.com>

> Please review this fix for JDK-8225093 to set the default value of property jdk.boot.class.path.append to NULL instead of "".  This fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.  The fix was also tested by running the agent.c example in JDK-8224791.
> 
> Thanks! Harold

Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:

  Add error code to test failure message

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6868/files
  - new: https://git.openjdk.java.net/jdk/pull/6868/files/a1c9218b..97d60c7e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6868&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6868&range=01-02

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6868.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6868/head:pull/6868

PR: https://git.openjdk.java.net/jdk/pull/6868

From hseigel at openjdk.java.net  Mon Dec 20 18:36:49 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 20 Dec 2021 18:36:49 GMT
Subject: RFR: 8225093: Special property jdk.boot.class.path.append should
 not default to empty string [v2]
In-Reply-To: <utajbk5GFZuQ7Typ8RksN45Byc2il61fsllA12yUJcA=.addb4580-1b10-4c9c-9cce-7d45af40a600@github.com>
References: <y8hiMnue6abZa0qUYXJOFg9sXbIYQ0x1LPCCId1z-oY=.359e3ed8-2fae-430c-9066-6e71ebea5027@github.com>
 <YaHH68n9B3rV1b9aMsevk9J2XILFHZIlQdy8jPFhXJI=.529e9d6f-aa76-476d-9ce7-5f6caa4af807@github.com>
 <utajbk5GFZuQ7Typ8RksN45Byc2il61fsllA12yUJcA=.addb4580-1b10-4c9c-9cce-7d45af40a600@github.com>
Message-ID: <ViK2h_gXHMQbk1H3_eJ4Bij0LHMivMTXkYByWWJkKfo=.fad03764-d849-4206-9d34-fc9b2e8e4897@github.com>

On Mon, 20 Dec 2021 17:33:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix test
>
> test/hotspot/jtreg/runtime/BootClassAppendProp/libGetBootClassPathAppendProp.c line 53:
> 
>> 51:   if (err != JVMTI_ERROR_NONE) {
>> 52:     return (*env)->NewStringUTF(env, "wrong error code");
>> 53:   }
> 
> For diagnosability it may be helpful to have this native method throw an exception with the JVMTI error code or alternatively have the return String include the error code rather than a generic message "wrong error code".

Thanks Alan!  I updated the test to include the JVM TI error code in the above 'wrong error code' message.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6868

From ccheung at openjdk.java.net  Mon Dec 20 18:47:31 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Mon, 20 Dec 2021 18:47:31 GMT
Subject: RFR: 8277100: Dynamic dump can inadvertently overwrite default CDS
 archive
Message-ID: <KmWdyQ-tGiaTecJto9VrG4JB2xBmuZE608B6a294lY0=.348ec53f-b54c-45a0-846e-439ca149a270@github.com>

Please review this small fix for preventing the default CDS archive from being overwritten via the
-XX:ArchiveClassesAtExit VM option.

If the user sets the -XX:ArchiveClassesAtExit option pointing to the default CDS archive, VM will
exit with the following message:

`Cannot specify the default CDS archive for -XX:ArchiveClassesAtExit: <path to classes.jsa>`

Passed CI tiers 1 and 2 tests.

-------------

Commit messages:
 - 8277100: Dynamic dump can inadvertently overwrite default CDS archive

Changes: https://git.openjdk.java.net/jdk/pull/6896/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6896&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277100
  Stats: 63 lines in 2 files changed: 63 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6896.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6896/head:pull/6896

PR: https://git.openjdk.java.net/jdk/pull/6896

From alanb at openjdk.java.net  Mon Dec 20 18:49:31 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 20 Dec 2021 18:49:31 GMT
Subject: RFR: 8225093: Special property jdk.boot.class.path.append should
 not default to empty string [v3]
In-Reply-To: <yjY_zdrZ9PLqc4oqmpjA0qhLY2klpV1xTMFRA-LWdBA=.31cdd09b-636e-4be9-a639-417b910a38b0@github.com>
References: <y8hiMnue6abZa0qUYXJOFg9sXbIYQ0x1LPCCId1z-oY=.359e3ed8-2fae-430c-9066-6e71ebea5027@github.com>
 <yjY_zdrZ9PLqc4oqmpjA0qhLY2klpV1xTMFRA-LWdBA=.31cdd09b-636e-4be9-a639-417b910a38b0@github.com>
Message-ID: <hlE6VpEngXftO9R48KdQwbJgXt98peKbbvTo8GLNiJQ=.c4de9641-7713-4fe3-a743-80963287bc2b@github.com>

On Mon, 20 Dec 2021 18:36:45 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this fix for JDK-8225093 to set the default value of property jdk.boot.class.path.append to NULL instead of "".  This fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.  The fix was also tested by running the agent.c example in JDK-8224791.
>> 
>> Thanks! Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add error code to test failure message

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6868

From iklam at openjdk.java.net  Mon Dec 20 20:01:30 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 20 Dec 2021 20:01:30 GMT
Subject: RFR: 8277100: Dynamic dump can inadvertently overwrite default CDS
 archive
In-Reply-To: <KmWdyQ-tGiaTecJto9VrG4JB2xBmuZE608B6a294lY0=.348ec53f-b54c-45a0-846e-439ca149a270@github.com>
References: <KmWdyQ-tGiaTecJto9VrG4JB2xBmuZE608B6a294lY0=.348ec53f-b54c-45a0-846e-439ca149a270@github.com>
Message-ID: <cviqrQznKI30bRATP0UC62oUjB4V1rrdksH8nVz-5vc=.c8f15ed7-7cfe-4cd8-be9a-3f93271bc896@github.com>

On Mon, 20 Dec 2021 18:14:05 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Please review this small fix for preventing the default CDS archive from being overwritten via the
> -XX:ArchiveClassesAtExit VM option.
> 
> If the user sets the -XX:ArchiveClassesAtExit option pointing to the default CDS archive, VM will
> exit with the following message:
> 
> `Cannot specify the default CDS archive for -XX:ArchiveClassesAtExit: <path to classes.jsa>`
> 
> Passed CI tiers 1 and 2 tests.

LGTM

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6896

From minqi at openjdk.java.net  Mon Dec 20 20:01:31 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Mon, 20 Dec 2021 20:01:31 GMT
Subject: RFR: 8277100: Dynamic dump can inadvertently overwrite default CDS
 archive
In-Reply-To: <KmWdyQ-tGiaTecJto9VrG4JB2xBmuZE608B6a294lY0=.348ec53f-b54c-45a0-846e-439ca149a270@github.com>
References: <KmWdyQ-tGiaTecJto9VrG4JB2xBmuZE608B6a294lY0=.348ec53f-b54c-45a0-846e-439ca149a270@github.com>
Message-ID: <slmVhoPeKMHdbJ7YBlPak_pEiC_r5z9JCKAukOD-h9g=.903c0e76-02b6-4668-961e-c29c230c1afb@github.com>

On Mon, 20 Dec 2021 18:14:05 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Please review this small fix for preventing the default CDS archive from being overwritten via the
> -XX:ArchiveClassesAtExit VM option.
> 
> If the user sets the -XX:ArchiveClassesAtExit option pointing to the default CDS archive, VM will
> exit with the following message:
> 
> `Cannot specify the default CDS archive for -XX:ArchiveClassesAtExit: <path to classes.jsa>`
> 
> Passed CI tiers 1 and 2 tests.

LGTM.

-------------

Marked as reviewed by minqi (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6896

From minqi at openjdk.java.net  Mon Dec 20 20:39:04 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Mon, 20 Dec 2021 20:39:04 GMT
Subject: RFR: 8279018: CRC calculation in CDS should not include _version and
 _head_size
Message-ID: <Z1Fof383_r1H31EUrl1q2RWSBd1JDQYSZBOxRCv4hRs=.80548e3e-9a38-431f-89e6-621b0d5eb13c@github.com>

Please review the simple change for not including _version and _header_size in crc computation. These two fields are checked separately and they should not affect crc.

tests: tier1,tier4

Thanks
Yumin

-------------

Commit messages:
 - 8279018: CRC calculation in CDS should not include _version and _head_size

Changes: https://git.openjdk.java.net/jdk/pull/6899/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6899&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279018
  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6899.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6899/head:pull/6899

PR: https://git.openjdk.java.net/jdk/pull/6899

From dcubed at openjdk.java.net  Mon Dec 20 21:29:50 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 20 Dec 2021 21:29:50 GMT
Subject: [jdk18] RFR: 8272058: 25 Null pointer dereference defect groups in 4
 files
Message-ID: <TwIvJ3FE4o5AqZ38OQaZhzhB5Ctdph9LYLcQOEZswPk=.14774a97-d3e1-44e1-8a91-568c9d632334@github.com>

A small refactoring to resolve a Parfait complaint about the return value from
`MacroAssembler::target_addr_for_insn(address insn_addr, unsigned insn)`
on AARCH64. The logic that supports returning `nullptr` as the target addr for
a particular instruction is moved from
`MacroAssembler::target_addr_for_insn(address insn_addr, unsigned insn)` to
`MacroAssembler::target_addr_for_insn_allow_null_ret(address insn_addr, unsigned insn)`.
A couple of `target_addr_for_insn()` call sites that can tolerate a `nullptr` are
converted to use `target_addr_for_insn_allow_null_ret()`.

This fix has been tested with Mach5 Tier[1-3].

-------------

Commit messages:
 - 8272058.exp1.patch

Changes: https://git.openjdk.java.net/jdk18/pull/51/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=51&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272058
  Stats: 18 lines in 3 files changed: 13 ins; 3 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/51.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/51/head:pull/51

PR: https://git.openjdk.java.net/jdk18/pull/51

From dcubed at openjdk.java.net  Mon Dec 20 21:29:51 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 20 Dec 2021 21:29:51 GMT
Subject: [jdk18] RFR: 8272058: 25 Null pointer dereference defect groups in
 4 files
In-Reply-To: <TwIvJ3FE4o5AqZ38OQaZhzhB5Ctdph9LYLcQOEZswPk=.14774a97-d3e1-44e1-8a91-568c9d632334@github.com>
References: <TwIvJ3FE4o5AqZ38OQaZhzhB5Ctdph9LYLcQOEZswPk=.14774a97-d3e1-44e1-8a91-568c9d632334@github.com>
Message-ID: <qPIGUj021o2PgCtxvDZtSmmYTZlutxqor9bg-RVIAyc=.d1d59719-359a-4df4-8fc2-fb553cba3339@github.com>

On Mon, 20 Dec 2021 20:50:14 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A small refactoring to resolve a Parfait complaint about the return value from
> `MacroAssembler::target_addr_for_insn(address insn_addr, unsigned insn)`
> on AARCH64. The logic that supports returning `nullptr` as the target addr for
> a particular instruction is moved from
> `MacroAssembler::target_addr_for_insn(address insn_addr, unsigned insn)` to
> `MacroAssembler::target_addr_for_insn_allow_null_ret(address insn_addr, unsigned insn)`.
> A couple of `target_addr_for_insn()` call sites that can tolerate a `nullptr` are
> converted to use `target_addr_for_insn_allow_null_ret()`.
> 
> This fix has been tested with Mach5 Tier[1-3].

The Parfait complaint at the root of this issue is:

MacroAssembler::target_addr_for_insn
open/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp


286. | } else if (Instruction_aarch64::extract(insn, 31, 22) == 0b1011100101 &&
287. |            Instruction_aarch64::extract(insn, 4, 0) == 0b11111) {
288. |   return 0;  // Null pointer introduced .
289. | } else {
290. |   ShouldNotReachHere();

-------------

PR: https://git.openjdk.java.net/jdk18/pull/51

From iklam at openjdk.java.net  Mon Dec 20 22:07:32 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 20 Dec 2021 22:07:32 GMT
Subject: RFR: 8279018: CRC calculation in CDS should not include _version
 and _head_size
In-Reply-To: <Z1Fof383_r1H31EUrl1q2RWSBd1JDQYSZBOxRCv4hRs=.80548e3e-9a38-431f-89e6-621b0d5eb13c@github.com>
References: <Z1Fof383_r1H31EUrl1q2RWSBd1JDQYSZBOxRCv4hRs=.80548e3e-9a38-431f-89e6-621b0d5eb13c@github.com>
Message-ID: <ifYCKNLH9-Gozx_PfDnOai2i3VyG1H06kk9uANDMtXQ=.67b0b9eb-8ca9-45ef-95cf-5456de5414c4@github.com>

On Mon, 20 Dec 2021 20:30:15 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Please review the simple change for not including _version and _header_size in crc computation. These two fields are checked separately and they should not affect crc.
> 
> tests: tier1,tier4
> 
> Thanks
> Yumin

Hi Yumin, because the layout of the header has changed, CURRENT_CDS_ARCHIVE_VERSION needs to be updated to 13.

Also, CDS_GENERIC_HEADER_SUPPORTED_MIN_VERSION needs to be updated to 13, since this PR changes the layout of GenericCDSFileMapHeader.

-------------

Changes requested by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6899

From coleenp at openjdk.java.net  Mon Dec 20 22:10:34 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 20 Dec 2021 22:10:34 GMT
Subject: RFR: 8278125: Some preallocated OOMEs are missing stack trace [v3]
In-Reply-To: <yoaT87337KQzVF-xRpopBnEIMf6YQNV9Ec1Gs4n2ewI=.55c29c27-27fd-4d77-b6d8-fd466be6ca9e@github.com>
References: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
 <yoaT87337KQzVF-xRpopBnEIMf6YQNV9Ec1Gs4n2ewI=.55c29c27-27fd-4d77-b6d8-fd466be6ca9e@github.com>
Message-ID: <A2gIo3dxLcZIvg5Q13H0nSmMQ3O4FpuxuSc000AYgxw=.7e602907-2942-47b0-9311-57155d630c6e@github.com>

On Mon, 6 Dec 2021 08:02:50 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> Our customer found that the PreallocatedOutOfMemoryErrorCount is 4 by default. It ought to pre-allocate 4 OOMEs with stack trace, but in fact, no matter how many OOMEs are thrown, only 2 OOMEs have proper stack trace. This is because PreallocatedOutOfMemoryErrorCount is consumed multiple times:
>> 
>> VM tries to allocate a huge object while Java heap is insufficient to accommodate, it goes to:
>> 
>> https://github.com/openjdk/jdk/blob/b79554bb5cef14590d427543a40efbcc60c66548/src/hotspot/share/gc/shared/memAllocator.cpp#L115-L136
>> 
>> Line 135(`Universe::out_of_memory_error_java_heap`->`Universe::gen_out_of_memory_error`) and line 136(`THROW_OOP_`->`Exceptions::_throw`->`Exceptions::count_out_of_memory_exceptions`->`Universe::out_of_memory_error_java_heap`->`Universe::gen_out_of_memory_error`) call `Universe::gen_out_of_memory_error` twice in a single OOM event, which leads this unexpected scenario. Proposed fix is to remove such call in `Exceptions::count_out_of_memory_exceptions`.
>> 
>> Thanks.
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   newline before eof

One last try to avoid strcmp...

src/hotspot/share/memory/universe.cpp line 606:

> 604:   return is_out_of_memory_error(obj, MSG_CLASS_METASPACE);
> 605: }
> 606: 

You only need the const strings for these two strings, so could you just change these two?

src/hotspot/share/memory/universe.cpp line 688:

> 686:   java_lang_Throwable::set_message(oom_array->obj_at(_oom_metaspace), msg());
> 687: 
> 688:   msg = java_lang_String::create_from_str(MSG_CLASS_METASPACE, CHECK);

I meant intern these two strings here and check for equality?  Save the interned string in a static OopHandle in the Universe class.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6672

From dholmes at openjdk.java.net  Mon Dec 20 22:29:32 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 20 Dec 2021 22:29:32 GMT
Subject: [jdk18] RFR: 8272058: 25 Null pointer dereference defect groups in
 4 files
In-Reply-To: <TwIvJ3FE4o5AqZ38OQaZhzhB5Ctdph9LYLcQOEZswPk=.14774a97-d3e1-44e1-8a91-568c9d632334@github.com>
References: <TwIvJ3FE4o5AqZ38OQaZhzhB5Ctdph9LYLcQOEZswPk=.14774a97-d3e1-44e1-8a91-568c9d632334@github.com>
Message-ID: <Ul_41165_KtzEaYgmg81fQFPjnOdlTxMm0SAHGRX6QI=.28f3b327-de87-4d8d-b3d5-715130859eb4@github.com>

On Mon, 20 Dec 2021 20:50:14 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A small refactoring to resolve a Parfait complaint about the return value from
> `MacroAssembler::target_addr_for_insn(address insn_addr, unsigned insn)`
> on AARCH64. The logic that supports returning `nullptr` as the target addr for
> a particular instruction is moved from
> `MacroAssembler::target_addr_for_insn(address insn_addr, unsigned insn)` to
> `MacroAssembler::target_addr_for_insn_allow_null_ret(address insn_addr, unsigned insn)`.
> A couple of `target_addr_for_insn()` call sites that can tolerate a `nullptr` are
> converted to use `target_addr_for_insn_allow_null_ret()`.
> 
> This fix has been tested with Mach5 Tier[1-3].

Hi Dan,

In terms of the refactoring and addressing the warning this seems reasonable. But in terms of semantics this claims that all the remaining callsites for `target_addr_for_insn` can never pass an `insn` that can lead to a NULL address. I can't verify that claim. This needs some Aarch64 experts to chime in - perhaps @theRealAph?

Thanks,
David

-------------

PR: https://git.openjdk.java.net/jdk18/pull/51

From iklam at openjdk.java.net  Mon Dec 20 22:34:31 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 20 Dec 2021 22:34:31 GMT
Subject: RFR: 8279018: CRC calculation in CDS should not include _version
 and _head_size
In-Reply-To: <Z1Fof383_r1H31EUrl1q2RWSBd1JDQYSZBOxRCv4hRs=.80548e3e-9a38-431f-89e6-621b0d5eb13c@github.com>
References: <Z1Fof383_r1H31EUrl1q2RWSBd1JDQYSZBOxRCv4hRs=.80548e3e-9a38-431f-89e6-621b0d5eb13c@github.com>
Message-ID: <0S37pzh3QvwrdXDwTGRlQnjLSQqqFA3VV819VHSxc4s=.4753a53b-27df-4fdd-b643-448f152f054e@github.com>

On Mon, 20 Dec 2021 20:30:15 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Please review the simple change for not including _version and _header_size in crc computation. These two fields are checked separately and they should not affect crc.
> 
> tests: tier1,tier4
> 
> Thanks
> Yumin

Also, I think the _crc field should not be moved. That's because all previous version of CDS (since JDK 8) have the following 3 fields at the beginning of the CDS archive file:


    int    _magic;                    // identify file type.
    int    _crc;                      // header crc checksum.
    int    _version;                  // (from enum, above.)


If we move the `_crc` field,  the VM will not be correctly reading the `_version` of a CDS file generated by an older version of the JDK. This will make it difficult to implement [JDK-8261455](https://bugs.openjdk.java.net/browse/JDK-8261455) - Automatically generate the CDS archive if necessary.

I think the correct fix of this bug is to change the following:


int FileMapHeader::compute_crc() {
  char* start = (char*)this;
  // start computing from the field after _crc to end of base archive name.
-  char* buf = (char*)&(_generic_header._crc) + sizeof(_generic_header._crc);
+  char* buf = (char*)&(_generic_header._header_size) + sizeof(_generic_header._header_size);


Also, CURRENT_CDS_ARCHIVE_VERSION and CDS_GENERIC_HEADER_SUPPORTED_MIN_VERSION 
need to be updated to 13 because the meaning of the `_crc` field has changed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6899

From dholmes at openjdk.java.net  Mon Dec 20 22:36:33 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 20 Dec 2021 22:36:33 GMT
Subject: RFR: 8225093: Special property jdk.boot.class.path.append should
 not default to empty string [v3]
In-Reply-To: <yjY_zdrZ9PLqc4oqmpjA0qhLY2klpV1xTMFRA-LWdBA=.31cdd09b-636e-4be9-a639-417b910a38b0@github.com>
References: <y8hiMnue6abZa0qUYXJOFg9sXbIYQ0x1LPCCId1z-oY=.359e3ed8-2fae-430c-9066-6e71ebea5027@github.com>
 <yjY_zdrZ9PLqc4oqmpjA0qhLY2klpV1xTMFRA-LWdBA=.31cdd09b-636e-4be9-a639-417b910a38b0@github.com>
Message-ID: <wHGOgDkWhFKaq3ESJrQ0xyUlL9MdDri-GUniiZw6PMQ=.3d5a96a1-a1ce-4950-9870-ed4c88838ddf@github.com>

On Mon, 20 Dec 2021 18:36:45 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this fix for JDK-8225093 to set the default value of property jdk.boot.class.path.append to NULL instead of "".  This fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.  The fix was also tested by running the agent.c example in JDK-8224791.
>> 
>> Thanks! Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add error code to test failure message

Marked as reviewed by dholmes (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6868

From dcubed at openjdk.java.net  Mon Dec 20 22:37:40 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 20 Dec 2021 22:37:40 GMT
Subject: [jdk18] RFR: 8272058: 25 Null pointer dereference defect groups in
 4 files
In-Reply-To: <Ul_41165_KtzEaYgmg81fQFPjnOdlTxMm0SAHGRX6QI=.28f3b327-de87-4d8d-b3d5-715130859eb4@github.com>
References: <TwIvJ3FE4o5AqZ38OQaZhzhB5Ctdph9LYLcQOEZswPk=.14774a97-d3e1-44e1-8a91-568c9d632334@github.com>
 <Ul_41165_KtzEaYgmg81fQFPjnOdlTxMm0SAHGRX6QI=.28f3b327-de87-4d8d-b3d5-715130859eb4@github.com>
Message-ID: <tvUtSGlFDwwFTF5xEF0Z44g-odeexX0XdZf0d8TzdZA=.1fb8049e-18e0-4525-aa45-eca4c1925714@github.com>

On Mon, 20 Dec 2021 22:26:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> A small refactoring to resolve a Parfait complaint about the return value from
>> `MacroAssembler::target_addr_for_insn(address insn_addr, unsigned insn)`
>> on AARCH64. The logic that supports returning `nullptr` as the target addr for
>> a particular instruction is moved from
>> `MacroAssembler::target_addr_for_insn(address insn_addr, unsigned insn)` to
>> `MacroAssembler::target_addr_for_insn_allow_null_ret(address insn_addr, unsigned insn)`.
>> A couple of `target_addr_for_insn()` call sites that can tolerate a `nullptr` are
>> converted to use `target_addr_for_insn_allow_null_ret()`.
>> 
>> This fix has been tested with Mach5 Tier[1-3].
>
> Hi Dan,
> 
> In terms of the refactoring and addressing the warning this seems reasonable. But in terms of semantics this claims that all the remaining callsites for `target_addr_for_insn` can never pass an `insn` that can lead to a NULL address. I can't verify that claim. This needs some Aarch64 experts to chime in - perhaps @theRealAph?
> 
> Thanks,
> David

@dholmes-ora - Thanks for taking a look. I did take the time to look at all the
remaining call sites for `target_addr_for_insn` and, in some cases, their callers
and I didn't see anything where it made sense to run into an `insn` that could
lead to a `nullptr` address. Of course, that's just code inspection on my part
so I also created `guarantee()` traps at all the call-sites and ran those bits
thru Mach5 Tier[1-8] testing without hitting any of the traps. As you pointed
out in the bug report, that kind of testing isn't proof either, but it helps me
believe that I didn't miss anything too obvious.

Having @theRealAph chime in here would be wonderful!

-------------

PR: https://git.openjdk.java.net/jdk18/pull/51

From dholmes at openjdk.java.net  Mon Dec 20 22:46:31 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 20 Dec 2021 22:46:31 GMT
Subject: RFR: 8277100: Dynamic dump can inadvertently overwrite default CDS
 archive
In-Reply-To: <KmWdyQ-tGiaTecJto9VrG4JB2xBmuZE608B6a294lY0=.348ec53f-b54c-45a0-846e-439ca149a270@github.com>
References: <KmWdyQ-tGiaTecJto9VrG4JB2xBmuZE608B6a294lY0=.348ec53f-b54c-45a0-846e-439ca149a270@github.com>
Message-ID: <YcVJJ6T9E6H5PHVV7bmUOjdWH8bfyD-XbudE69id33A=.742bc60c-914c-4ffd-92d4-fc613605a418@github.com>

On Mon, 20 Dec 2021 18:14:05 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Please review this small fix for preventing the default CDS archive from being overwritten via the
> -XX:ArchiveClassesAtExit VM option.
> 
> If the user sets the -XX:ArchiveClassesAtExit option pointing to the default CDS archive, VM will
> exit with the following message:
> 
> `Cannot specify the default CDS archive for -XX:ArchiveClassesAtExit: <path to classes.jsa>`
> 
> Passed CI tiers 1 and 2 tests.

Hi Calvin,

Fix is good, but I have to query whether this is just a P4? I suppose anyone who can overwrite the default archive this way can also restore it with -Xdump, but still this seems a bit of a usability issue worthy of a P3 and fixing in 18.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6896

From dholmes at openjdk.java.net  Mon Dec 20 22:54:29 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 20 Dec 2021 22:54:29 GMT
Subject: RFR: 8278125: Some preallocated OOMEs are missing stack trace [v3]
In-Reply-To: <A2gIo3dxLcZIvg5Q13H0nSmMQ3O4FpuxuSc000AYgxw=.7e602907-2942-47b0-9311-57155d630c6e@github.com>
References: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
 <yoaT87337KQzVF-xRpopBnEIMf6YQNV9Ec1Gs4n2ewI=.55c29c27-27fd-4d77-b6d8-fd466be6ca9e@github.com>
 <A2gIo3dxLcZIvg5Q13H0nSmMQ3O4FpuxuSc000AYgxw=.7e602907-2942-47b0-9311-57155d630c6e@github.com>
Message-ID: <bKDxvVnTSiep-DUaxM8j452mC2xp4GNCzwXFIustLDY=.17ec4a9b-8598-46e4-b59f-35439a92f048@github.com>

On Mon, 20 Dec 2021 22:06:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   newline before eof
>
> src/hotspot/share/memory/universe.cpp line 688:
> 
>> 686:   java_lang_Throwable::set_message(oom_array->obj_at(_oom_metaspace), msg());
>> 687: 
>> 688:   msg = java_lang_String::create_from_str(MSG_CLASS_METASPACE, CHECK);
> 
> I meant intern these two strings here and check for equality?  Save the interned string in a static OopHandle in the Universe class.

Sorry Coleen I do not understand what you mean by this. How do you compare the "interned" oop String with the incoming `char*` text?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6672

From ccheung at openjdk.java.net  Mon Dec 20 23:05:31 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Mon, 20 Dec 2021 23:05:31 GMT
Subject: RFR: 8277100: Dynamic dump can inadvertently overwrite default CDS
 archive
In-Reply-To: <YcVJJ6T9E6H5PHVV7bmUOjdWH8bfyD-XbudE69id33A=.742bc60c-914c-4ffd-92d4-fc613605a418@github.com>
References: <KmWdyQ-tGiaTecJto9VrG4JB2xBmuZE608B6a294lY0=.348ec53f-b54c-45a0-846e-439ca149a270@github.com>
 <YcVJJ6T9E6H5PHVV7bmUOjdWH8bfyD-XbudE69id33A=.742bc60c-914c-4ffd-92d4-fc613605a418@github.com>
Message-ID: <J-Nx_xROVou8cjRBNfH39xoz6enrSNxJ8JtFuFx_g_U=.d82bc4a1-d1b4-4711-99bb-67850648e2ee@github.com>

On Mon, 20 Dec 2021 22:43:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi Calvin,
> 
> Fix is good, but I have to query whether this is just a P4? I suppose anyone who can overwrite the default archive this way can also restore it with -Xdump, but still this seems a bit of a usability issue worthy of a P3 and fixing in 18.
> 
> Thanks, David

Hi David,

I've added a comment to the bug report justifying why this is a P4.
I can backport the fix to 18.

Thanks,
Calvin

-------------

PR: https://git.openjdk.java.net/jdk/pull/6896

From ccheung at openjdk.java.net  Mon Dec 20 23:05:31 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Mon, 20 Dec 2021 23:05:31 GMT
Subject: RFR: 8277100: Dynamic dump can inadvertently overwrite default CDS
 archive
In-Reply-To: <cviqrQznKI30bRATP0UC62oUjB4V1rrdksH8nVz-5vc=.c8f15ed7-7cfe-4cd8-be9a-3f93271bc896@github.com>
References: <KmWdyQ-tGiaTecJto9VrG4JB2xBmuZE608B6a294lY0=.348ec53f-b54c-45a0-846e-439ca149a270@github.com>
 <cviqrQznKI30bRATP0UC62oUjB4V1rrdksH8nVz-5vc=.c8f15ed7-7cfe-4cd8-be9a-3f93271bc896@github.com>
Message-ID: <KvS3JQO39DRd77axQxy29V71uokKr3wVPnGu8t-9zog=.31280f19-ad95-4375-b5c7-4e7dd68d6ce7@github.com>

On Mon, 20 Dec 2021 19:57:50 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Please review this small fix for preventing the default CDS archive from being overwritten via the
>> -XX:ArchiveClassesAtExit VM option.
>> 
>> If the user sets the -XX:ArchiveClassesAtExit option pointing to the default CDS archive, VM will
>> exit with the following message:
>> 
>> `Cannot specify the default CDS archive for -XX:ArchiveClassesAtExit: <path to classes.jsa>`
>> 
>> Passed CI tiers 1 and 2 tests.
>
> LGTM

@iklam, @yminqi, @dholmes-ora Thanks for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6896

From coleenp at openjdk.java.net  Mon Dec 20 23:19:46 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 20 Dec 2021 23:19:46 GMT
Subject: RFR: 8278125: Some preallocated OOMEs are missing stack trace [v2]
In-Reply-To: <r0HXlP6H30peMpZq5UpF5oWrVMP0qLN9XM6hQrwPZC8=.3b387880-bfc7-41fa-8534-07d6c942393e@github.com>
References: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
 <AV2S-29XpWTCQh7mToBLRWh4bVMo_BygEMA44T_bXkc=.a38aa64b-0a70-4b63-b8d7-b646de83e936@github.com>
 <JI4SopPkSGJetYlJz7IYDcYU9vrumqm-MMx6m6QtqvI=.ed6b31c3-dca3-4e76-9829-505590a79a3a@github.com>
 <qmqXtfjVDPZMAMACTGIIXBuYkt5kL46o3zWf-6TKbWk=.b2c40abc-779d-43a5-a8d2-e18723181985@github.com>
 <r0HXlP6H30peMpZq5UpF5oWrVMP0qLN9XM6hQrwPZC8=.3b387880-bfc7-41fa-8534-07d6c942393e@github.com>
Message-ID: <qohCVQe5hRRo8V2ZYSpxjtr8I2LDN3jyMQpJf7yRjnk=.034f0070-2f34-444f-b68f-a509532c78bb@github.com>

On Thu, 16 Dec 2021 04:41:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ok, I see how this isn't right, but I still don't like the strcmp.  Can the string be interned and checked for equality?  Otherwise you also need a ResourceMark here.
>
> We are comparing a `char*` and a Java String (the message from the Exception oop), so we either convert the Java String to a `char*` and compare them with `strcmp` as shown; or we turn the incoming `char*` into a Java String and then use `java_lang_String::equals`. The latter is an expensive operation and more importantly creating the String requires an allocation when we are trying to throw an OutOfMemoryError! So I don't see a reasonable alternative to the `strcmp`.

This would still need a ResourceMark, since java_lang_String::as_utf8_string() allocates into a resource allocated array.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6672

From coleenp at openjdk.java.net  Mon Dec 20 23:19:51 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 20 Dec 2021 23:19:51 GMT
Subject: RFR: 8278125: Some preallocated OOMEs are missing stack trace [v3]
In-Reply-To: <bKDxvVnTSiep-DUaxM8j452mC2xp4GNCzwXFIustLDY=.17ec4a9b-8598-46e4-b59f-35439a92f048@github.com>
References: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
 <yoaT87337KQzVF-xRpopBnEIMf6YQNV9Ec1Gs4n2ewI=.55c29c27-27fd-4d77-b6d8-fd466be6ca9e@github.com>
 <A2gIo3dxLcZIvg5Q13H0nSmMQ3O4FpuxuSc000AYgxw=.7e602907-2942-47b0-9311-57155d630c6e@github.com>
 <bKDxvVnTSiep-DUaxM8j452mC2xp4GNCzwXFIustLDY=.17ec4a9b-8598-46e4-b59f-35439a92f048@github.com>
Message-ID: <LGrdOxElkNdwe078_cI7BrB1xDJe7T9NmRtOYAqFQQ8=.fb09be89-b4e6-4b31-a6bd-edcc77b17fcf@github.com>

On Mon, 20 Dec 2021 22:50:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/memory/universe.cpp line 688:
>> 
>>> 686:   java_lang_Throwable::set_message(oom_array->obj_at(_oom_metaspace), msg());
>>> 687: 
>>> 688:   msg = java_lang_String::create_from_str(MSG_CLASS_METASPACE, CHECK);
>> 
>> I meant intern these two strings here and check for equality?  Save the interned string in a static OopHandle in the Universe class.
>
> Sorry Coleen I do not understand what you mean by this. How do you compare the "interned" oop String with the incoming `char*` text?

OopHandle Universe::_metaspace_string;
...
msg = String::intern("Metaspace", CHECK);
java_lang_Throwable::set_message(oom_array->obj_at(_oom_metaspace, msg());
Universe::_metaspace_string = OopHandle(vm_global(), msg);
...
bool Universe::is_metaspace_oome(oop exc) {
  return java_lang_Throwable::get_message(exc) == _metaspace_string.resolve();
}

-------------

PR: https://git.openjdk.java.net/jdk/pull/6672

From coleenp at openjdk.java.net  Mon Dec 20 23:19:52 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 20 Dec 2021 23:19:52 GMT
Subject: RFR: 8278125: Some preallocated OOMEs are missing stack trace [v3]
In-Reply-To: <LGrdOxElkNdwe078_cI7BrB1xDJe7T9NmRtOYAqFQQ8=.fb09be89-b4e6-4b31-a6bd-edcc77b17fcf@github.com>
References: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
 <yoaT87337KQzVF-xRpopBnEIMf6YQNV9Ec1Gs4n2ewI=.55c29c27-27fd-4d77-b6d8-fd466be6ca9e@github.com>
 <A2gIo3dxLcZIvg5Q13H0nSmMQ3O4FpuxuSc000AYgxw=.7e602907-2942-47b0-9311-57155d630c6e@github.com>
 <bKDxvVnTSiep-DUaxM8j452mC2xp4GNCzwXFIustLDY=.17ec4a9b-8598-46e4-b59f-35439a92f048@github.com>
 <LGrdOxElkNdwe078_cI7BrB1xDJe7T9NmRtOYAqFQQ8=.fb09be89-b4e6-4b31-a6bd-edcc77b17fcf@github.com>
Message-ID: <U6lgqfW8v-e-XhR-HwP30p30Ay605QhKouUA2sxhLF4=.459514e1-6a55-4472-966e-3629eecbd6fa@github.com>

On Mon, 20 Dec 2021 23:11:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Sorry Coleen I do not understand what you mean by this. How do you compare the "interned" oop String with the incoming `char*` text?
>
> OopHandle Universe::_metaspace_string;
> ...
> msg = String::intern("Metaspace", CHECK);
> java_lang_Throwable::set_message(oom_array->obj_at(_oom_metaspace, msg());
> Universe::_metaspace_string = OopHandle(vm_global(), msg);
> ...
> bool Universe::is_metaspace_oome(oop exc) {
>   return java_lang_Throwable::get_message(exc) == _metaspace_string.resolve();
> }

Maybe not.  Maybe the exception you're checking could be newly allocated and not use an interned string.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6672

From coleenp at openjdk.java.net  Mon Dec 20 23:19:54 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 20 Dec 2021 23:19:54 GMT
Subject: RFR: 8278125: Some preallocated OOMEs are missing stack trace [v3]
In-Reply-To: <U6lgqfW8v-e-XhR-HwP30p30Ay605QhKouUA2sxhLF4=.459514e1-6a55-4472-966e-3629eecbd6fa@github.com>
References: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
 <yoaT87337KQzVF-xRpopBnEIMf6YQNV9Ec1Gs4n2ewI=.55c29c27-27fd-4d77-b6d8-fd466be6ca9e@github.com>
 <A2gIo3dxLcZIvg5Q13H0nSmMQ3O4FpuxuSc000AYgxw=.7e602907-2942-47b0-9311-57155d630c6e@github.com>
 <bKDxvVnTSiep-DUaxM8j452mC2xp4GNCzwXFIustLDY=.17ec4a9b-8598-46e4-b59f-35439a92f048@github.com>
 <LGrdOxElkNdwe078_cI7BrB1xDJe7T9NmRtOYAqFQQ8=.fb09be89-b4e6-4b31-a6bd-edcc77b17fcf@github.com>
 <U6lgqfW8v-e-XhR-HwP30p30Ay605QhKouUA2sxhLF4=.459514e1-6a55-4472-966e-3629eecbd6fa@github.com>
Message-ID: <6Uy6A9xOJmY_WW8IXTGf1pA1i_td4OTgzVRfJPuEbRk=.a11eccf8-cc76-4e02-b8f7-069951ab0e0b@github.com>

On Mon, 20 Dec 2021 23:14:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> OopHandle Universe::_metaspace_string;
>> ...
>> msg = String::intern("Metaspace", CHECK);
>> java_lang_Throwable::set_message(oom_array->obj_at(_oom_metaspace, msg());
>> Universe::_metaspace_string = OopHandle(vm_global(), msg);
>> ...
>> bool Universe::is_metaspace_oome(oop exc) {
>>   return java_lang_Throwable::get_message(exc) == _metaspace_string.resolve();
>> }
>
> Maybe not.  Maybe the exception you're checking could be newly allocated and not use an interned string.

This code could also increment the counter and it might be much cleaner.
  if (out_of_compressed_class_space) {
    THROW_OOP(Universe::out_of_memory_error_class_metaspace());
  } else {
    THROW_OOP(Universe::out_of_memory_error_metaspace());
  }

-------------

PR: https://git.openjdk.java.net/jdk/pull/6672

From ccheung at openjdk.java.net  Mon Dec 20 23:22:06 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Mon, 20 Dec 2021 23:22:06 GMT
Subject: Integrated: 8277100: Dynamic dump can inadvertently overwrite default
 CDS archive
In-Reply-To: <KmWdyQ-tGiaTecJto9VrG4JB2xBmuZE608B6a294lY0=.348ec53f-b54c-45a0-846e-439ca149a270@github.com>
References: <KmWdyQ-tGiaTecJto9VrG4JB2xBmuZE608B6a294lY0=.348ec53f-b54c-45a0-846e-439ca149a270@github.com>
Message-ID: <5SaJA0MhQVc0gi0TYOXlTuGvlk8Ow42uLBgtpmgsp84=.b4f80732-5e43-45c6-a538-644c3a17868c@github.com>

On Mon, 20 Dec 2021 18:14:05 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Please review this small fix for preventing the default CDS archive from being overwritten via the
> -XX:ArchiveClassesAtExit VM option.
> 
> If the user sets the -XX:ArchiveClassesAtExit option pointing to the default CDS archive, VM will
> exit with the following message:
> 
> `Cannot specify the default CDS archive for -XX:ArchiveClassesAtExit: <path to classes.jsa>`
> 
> Passed CI tiers 1 and 2 tests.

This pull request has now been integrated.

Changeset: 8549d8b5
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8549d8b5697606ef87bb3f72abcf14dd7eb8a151
Stats:     63 lines in 2 files changed: 63 ins; 0 del; 0 mod

8277100: Dynamic dump can inadvertently overwrite default CDS archive

Reviewed-by: iklam, minqi, dholmes

-------------

PR: https://git.openjdk.java.net/jdk/pull/6896

From coleenp at openjdk.java.net  Mon Dec 20 23:42:17 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 20 Dec 2021 23:42:17 GMT
Subject: RFR: 8278125: Some preallocated OOMEs are missing stack trace [v3]
In-Reply-To: <U6lgqfW8v-e-XhR-HwP30p30Ay605QhKouUA2sxhLF4=.459514e1-6a55-4472-966e-3629eecbd6fa@github.com>
References: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
 <yoaT87337KQzVF-xRpopBnEIMf6YQNV9Ec1Gs4n2ewI=.55c29c27-27fd-4d77-b6d8-fd466be6ca9e@github.com>
 <A2gIo3dxLcZIvg5Q13H0nSmMQ3O4FpuxuSc000AYgxw=.7e602907-2942-47b0-9311-57155d630c6e@github.com>
 <bKDxvVnTSiep-DUaxM8j452mC2xp4GNCzwXFIustLDY=.17ec4a9b-8598-46e4-b59f-35439a92f048@github.com>
 <LGrdOxElkNdwe078_cI7BrB1xDJe7T9NmRtOYAqFQQ8=.fb09be89-b4e6-4b31-a6bd-edcc77b17fcf@github.com>
 <U6lgqfW8v-e-XhR-HwP30p30Ay605QhKouUA2sxhLF4=.459514e1-6a55-4472-966e-3629eecbd6fa@github.com>
Message-ID: <Lgw6KK7r51Xnkv5BYBjorL6nvmEHufoxoSxj3OI2BHw=.4e3317d4-e651-49c8-8739-85292881a4d8@github.com>

On Mon, 20 Dec 2021 23:14:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> OopHandle Universe::_metaspace_string;
>> ...
>> msg = String::intern("Metaspace", CHECK);
>> java_lang_Throwable::set_message(oom_array->obj_at(_oom_metaspace, msg());
>> Universe::_metaspace_string = OopHandle(vm_global(), msg);
>> ...
>> bool Universe::is_metaspace_oome(oop exc) {
>>   return java_lang_Throwable::get_message(exc) == _metaspace_string.resolve();
>> }
>
> Maybe not.  Maybe the exception you're checking could be newly allocated and not use an interned string.

sorry I deleted my last comment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6672

From dholmes at openjdk.java.net  Mon Dec 20 23:42:18 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 20 Dec 2021 23:42:18 GMT
Subject: RFR: 8278125: Some preallocated OOMEs are missing stack trace [v3]
In-Reply-To: <Lgw6KK7r51Xnkv5BYBjorL6nvmEHufoxoSxj3OI2BHw=.4e3317d4-e651-49c8-8739-85292881a4d8@github.com>
References: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
 <yoaT87337KQzVF-xRpopBnEIMf6YQNV9Ec1Gs4n2ewI=.55c29c27-27fd-4d77-b6d8-fd466be6ca9e@github.com>
 <A2gIo3dxLcZIvg5Q13H0nSmMQ3O4FpuxuSc000AYgxw=.7e602907-2942-47b0-9311-57155d630c6e@github.com>
 <bKDxvVnTSiep-DUaxM8j452mC2xp4GNCzwXFIustLDY=.17ec4a9b-8598-46e4-b59f-35439a92f048@github.com>
 <LGrdOxElkNdwe078_cI7BrB1xDJe7T9NmRtOYAqFQQ8=.fb09be89-b4e6-4b31-a6bd-edcc77b17fcf@github.com>
 <U6lgqfW8v-e-XhR-HwP30p30Ay605QhKouUA2sxhLF4=.459514e1-6a55-4472-966e-3629eecbd6fa@github.com>
 <Lgw6KK7r51Xnkv5BYBjorL6nvmEHufoxoSxj3OI2BHw=.4e3317d4-e651-49c8-8739-85292881a4d8@github.com>
Message-ID: <o63-YtxgLMQN62_ZnuOLBiFkuppVXSsOl3PK89Yzj8o=.1de7fe61-9029-4c9c-8fee-dc269a3b267f@github.com>

On Mon, 20 Dec 2021 23:37:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Maybe not.  Maybe the exception you're checking could be newly allocated and not use an interned string.
>
> sorry I deleted my last comment.

I'm getting completely lost on the suggestions now sorry. The logic of this code is really convoluted.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6672

From coleenp at openjdk.java.net  Mon Dec 20 23:54:15 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 20 Dec 2021 23:54:15 GMT
Subject: RFR: 8278125: Some preallocated OOMEs are missing stack trace [v3]
In-Reply-To: <o63-YtxgLMQN62_ZnuOLBiFkuppVXSsOl3PK89Yzj8o=.1de7fe61-9029-4c9c-8fee-dc269a3b267f@github.com>
References: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
 <yoaT87337KQzVF-xRpopBnEIMf6YQNV9Ec1Gs4n2ewI=.55c29c27-27fd-4d77-b6d8-fd466be6ca9e@github.com>
 <A2gIo3dxLcZIvg5Q13H0nSmMQ3O4FpuxuSc000AYgxw=.7e602907-2942-47b0-9311-57155d630c6e@github.com>
 <bKDxvVnTSiep-DUaxM8j452mC2xp4GNCzwXFIustLDY=.17ec4a9b-8598-46e4-b59f-35439a92f048@github.com>
 <LGrdOxElkNdwe078_cI7BrB1xDJe7T9NmRtOYAqFQQ8=.fb09be89-b4e6-4b31-a6bd-edcc77b17fcf@github.com>
 <U6lgqfW8v-e-XhR-HwP30p30Ay605QhKouUA2sxhLF4=.459514e1-6a55-4472-966e-3629eecbd6fa@github.com>
 <Lgw6KK7r51Xnkv5BYBjorL6nvmEHufoxoSxj3OI2BHw=.4e3317d4-e651-49c8-8739-85292881a4d8@github.com>
 <o63-YtxgLMQN62_ZnuOLBiFkuppVXSsOl3PK89Yzj8o=.1de7fe61-9029-4c9c-8fee-dc269a3b267f@github.com>
Message-ID: <jZS99U1IQmir95UzX8vq6LCbcUEZqrZvN5H5n7tab6s=.f3e276e7-44fa-42af-82fe-2c0b75c65b92@github.com>

On Mon, 20 Dec 2021 23:39:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> sorry I deleted my last comment.
>
> I'm getting completely lost on the suggestions now sorry. The logic of this code is really convoluted.

Yes, I agree. I figured it out once and had to start from scratch to try to figure it out again.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6672

From coleenp at openjdk.java.net  Tue Dec 21 00:19:40 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 21 Dec 2021 00:19:40 GMT
Subject: RFR: 8278125: Some preallocated OOMEs are missing stack trace [v3]
In-Reply-To: <jZS99U1IQmir95UzX8vq6LCbcUEZqrZvN5H5n7tab6s=.f3e276e7-44fa-42af-82fe-2c0b75c65b92@github.com>
References: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
 <yoaT87337KQzVF-xRpopBnEIMf6YQNV9Ec1Gs4n2ewI=.55c29c27-27fd-4d77-b6d8-fd466be6ca9e@github.com>
 <A2gIo3dxLcZIvg5Q13H0nSmMQ3O4FpuxuSc000AYgxw=.7e602907-2942-47b0-9311-57155d630c6e@github.com>
 <bKDxvVnTSiep-DUaxM8j452mC2xp4GNCzwXFIustLDY=.17ec4a9b-8598-46e4-b59f-35439a92f048@github.com>
 <LGrdOxElkNdwe078_cI7BrB1xDJe7T9NmRtOYAqFQQ8=.fb09be89-b4e6-4b31-a6bd-edcc77b17fcf@github.com>
 <U6lgqfW8v-e-XhR-HwP30p30Ay605QhKouUA2sxhLF4=.459514e1-6a55-4472-966e-3629eecbd6fa@github.com>
 <Lgw6KK7r51Xnkv5BYBjorL6nvmEHufoxoSxj3OI2BHw=.4e3317d4-e651-49c8-8739-85292881a4d8@github.com>
 <o63-YtxgLMQN62_ZnuOLBiFkuppVXSsOl3PK89Yzj8o=.1de7fe61-9029-4c9c-8fee-dc269a3b267f@github.com>
 <jZS99U1IQmir95UzX8vq6LCbcUEZqrZvN5H5n7tab6s=.f3e276e7-44fa-42af-82fe-2c0b75c65b92@github.com>
Message-ID: <XIPkCtkB8bGV7peqsrhOsmS_8_fG7podUU_1Bx88vLM=.1a2fe5cd-cc41-453e-ac0d-0d33144bcc0e@github.com>

On Mon, 20 Dec 2021 23:51:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I'm getting completely lost on the suggestions now sorry. The logic of this code is really convoluted.
>
> Yes, I agree. I figured it out once and had to start from scratch to try to figure it out again.

Like this: https://github.com/openjdk/jdk/pull/6901

-------------

PR: https://git.openjdk.java.net/jdk/pull/6672

From dholmes at openjdk.java.net  Tue Dec 21 01:18:16 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 21 Dec 2021 01:18:16 GMT
Subject: RFR: 8278125: Some preallocated OOMEs are missing stack trace [v3]
In-Reply-To: <XIPkCtkB8bGV7peqsrhOsmS_8_fG7podUU_1Bx88vLM=.1a2fe5cd-cc41-453e-ac0d-0d33144bcc0e@github.com>
References: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
 <yoaT87337KQzVF-xRpopBnEIMf6YQNV9Ec1Gs4n2ewI=.55c29c27-27fd-4d77-b6d8-fd466be6ca9e@github.com>
 <A2gIo3dxLcZIvg5Q13H0nSmMQ3O4FpuxuSc000AYgxw=.7e602907-2942-47b0-9311-57155d630c6e@github.com>
 <bKDxvVnTSiep-DUaxM8j452mC2xp4GNCzwXFIustLDY=.17ec4a9b-8598-46e4-b59f-35439a92f048@github.com>
 <LGrdOxElkNdwe078_cI7BrB1xDJe7T9NmRtOYAqFQQ8=.fb09be89-b4e6-4b31-a6bd-edcc77b17fcf@github.com>
 <U6lgqfW8v-e-XhR-HwP30p30Ay605QhKouUA2sxhLF4=.459514e1-6a55-4472-966e-3629eecbd6fa@github.com>
 <Lgw6KK7r51Xnkv5BYBjorL6nvmEHufoxoSxj3OI2BHw=.4e3317d4-e651-49c8-8739-85292881a4d8@github.com>
 <o63-YtxgLMQN62_ZnuOLBiFkuppVXSsOl3PK89Yzj8o=.1de7fe61-9029-4c9c-8fee-dc269a3b267f@github.com>
 <jZS99U1IQmir95UzX8vq6LCbcUEZqrZvN5H5n7tab6s=.f3e276e7-44fa-42af-82fe-2c0b75c65b92@github.com>
 <XIPkCtkB8bGV7peqsrhOsmS_8_fG7podUU_1Bx88vLM=.1a2fe5cd-cc41-453e-ac0d-0d33144bcc0e@github.com>
Message-ID: <tOC-2Ci-QZ4f5UpBpD8V-mrg1rsznto3TFhhAHBiPCg=.2004ef91-2a7a-478e-adcc-05ace5efe95f@github.com>

On Tue, 21 Dec 2021 00:15:41 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Yes, I agree. I figured it out once and had to start from scratch to try to figure it out again.
>
> Like this: https://github.com/openjdk/jdk/pull/6901

Okay - yes that looks reasonably simple. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6672

From xliu at openjdk.java.net  Tue Dec 21 02:35:13 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 21 Dec 2021 02:35:13 GMT
Subject: RFR: 8267517: async logging for stdout and stderr [v3]
In-Reply-To: <w0aDpgQFJScFf8yb7YQgdwDzm5PMcYm7M0x3AtYy2u8=.39bc3371-1df0-4a20-9c2f-ce4444d4b1e6@github.com>
References: <Nv1V5JHKgJh0NtqijGmWmI9Kh2VgDxgDIOAdfCtOavA=.503f41c2-a5d1-4a25-ab90-00252814a9bf@github.com>
 <w0aDpgQFJScFf8yb7YQgdwDzm5PMcYm7M0x3AtYy2u8=.39bc3371-1df0-4a20-9c2f-ce4444d4b1e6@github.com>
Message-ID: <NCcZKZmUiGkzFDdxwQ2RFufVTsvATzkMdk-CyiPKcEQ=.6a6cb7da-1e56-4fbd-826c-fb176bc0ce7c@github.com>

On Tue, 14 Dec 2021 02:01:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo and the building eror on MacOS.
>
> Hi Xin,
> 
> I took a look at this but to be honest I couldn't work out what most of the changes actually had to do with the topic of adding async logging for stdout/stderr.  IIUC the change from `LogFileOutput` to `LogFileStreamOutput` in the API now enables it to be used for stdout/stderr - right?  But most of the changes seemed to relate to log file rotation which doesn't even apply to stdout/stderr! What has force_rotation got to do with things?
> 
> David

hi, @dholmes-ora , 
I update the the PR, stripping JDK-8275083.  As a result,  UL throughput to STDOUT increases 15% with -Xlog:async. 
It was 20% with JDK-8275083 but I don't think the 5% gain justifies the bigger patch.  This patch is now smaller. Could you take a look?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6132

From minqi at openjdk.java.net  Tue Dec 21 03:12:32 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 21 Dec 2021 03:12:32 GMT
Subject: RFR: 8279022: JCmdTestFileSafety.java should check file time stamp for
 test result
Message-ID: <Qh-8hNJgPf8_JS6dvx_5-hNCkmGN2qKUYGC7dk9L4Pc=.ead68363-0097-4e96-96ac-ad58ddb60fbd@github.com>

When test finished, the created archive file should be checked after  the first run for existence, and checked for time stamp after second run.  Since the file name is same, this method is more accurate than the existing checking, only checking the existence of the file. Since jcmd can do repeat dynamic dump to same java process now, removed unnecessary restart process code.

Tests: tier1, jtreg on local linux-x64.

Thanks
Yumin

-------------

Commit messages:
 - Revise output message
 - 8279022: JCmdTestFileSafety.java should check file time stamp for test result

Changes: https://git.openjdk.java.net/jdk/pull/6904/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6904&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279022
  Stats: 29 lines in 1 file changed: 18 ins; 2 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6904.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6904/head:pull/6904

PR: https://git.openjdk.java.net/jdk/pull/6904

From minqi at openjdk.java.net  Tue Dec 21 04:17:50 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 21 Dec 2021 04:17:50 GMT
Subject: RFR: 8279018: CRC calculation in CDS should not include _version
 and _head_size [v2]
In-Reply-To: <Z1Fof383_r1H31EUrl1q2RWSBd1JDQYSZBOxRCv4hRs=.80548e3e-9a38-431f-89e6-621b0d5eb13c@github.com>
References: <Z1Fof383_r1H31EUrl1q2RWSBd1JDQYSZBOxRCv4hRs=.80548e3e-9a38-431f-89e6-621b0d5eb13c@github.com>
Message-ID: <BDK-dsu8t4KQTUpF76Iia0VkqJMbLXplqBwUgR1w0cA=.cbd1ecd4-f6ae-421a-9a7a-0f9ce7f28b5e@github.com>

> Please review the simple change for not including _version and _header_size in crc computation. These two fields are checked separately and they should not affect crc.
> 
> tests: tier1,tier4
> 
> Thanks
> Yumin

Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:

  Restore GenericCDSFileMapHeader data layout, change compute_crc instead, add code to WhiteBox to get versions instead of hard code

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6899/files
  - new: https://git.openjdk.java.net/jdk/pull/6899/files/77eb6c44..56e42768

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6899&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6899&range=00-01

  Stats: 46 lines in 7 files changed: 33 ins; 1 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6899.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6899/head:pull/6899

PR: https://git.openjdk.java.net/jdk/pull/6899

From dholmes at openjdk.java.net  Tue Dec 21 05:12:17 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 21 Dec 2021 05:12:17 GMT
Subject: RFR: 8267517: async logging for stdout and stderr [v3]
In-Reply-To: <ddwRuorCLqbH2zmw-PktIT9bm13hJ2jvNWJMX_1XQpo=.4f426bfb-b843-44c7-b935-fd748dd25db7@github.com>
References: <Nv1V5JHKgJh0NtqijGmWmI9Kh2VgDxgDIOAdfCtOavA=.503f41c2-a5d1-4a25-ab90-00252814a9bf@github.com>
 <ddwRuorCLqbH2zmw-PktIT9bm13hJ2jvNWJMX_1XQpo=.4f426bfb-b843-44c7-b935-fd748dd25db7@github.com>
Message-ID: <n4MKggE1CsTP9F4f3vYXt-AyaP_TMmF2px-XuxaB2EI=.3efa60a5-a850-4139-81fe-6be8be576d38@github.com>

On Thu, 16 Dec 2021 09:01:28 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch refactors LogFileStreamOutput so stdout/stderr can support support -Xlog:async.
>> 
>> With  `-Xlog:all=trace:stdout`, the helloworld in Java outputs 16520 log entries to stdout.  We are see that the wall time reduces from  84.138ms to 72.914ms, or the throughput increases 15% because of async logging.
>> 
>> 
>> $perf stat -r 300 ./build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -Xlog:async -XX:AsyncLogBufferSize=48M HelloWorld > /dev/null
>> 
>>  Performance counter stats for './build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -Xlog:async -XX:AsyncLogBufferSize=48M HelloWorld' (300 runs):
>> 
>>             107.21 msec task-clock                #    1.470 CPUs utilized            ( +-  0.17% )
>>              2,681      context-switches          #    0.025 M/sec                    ( +-  0.32% )
>>                  1      cpu-migrations            #    0.011 K/sec                    ( +-  4.56% )
>>              4,006      page-faults               #    0.037 M/sec                    ( +-  0.01% )
>> ...
>>           0.072914 +- 0.000126 seconds time elapsed  ( +-  0.17% )
>> 
>>  Performance counter stats for './build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -XX:AsyncLogBufferSize=48M HelloWorld' (300 runs):
>> 
>>              88.04 msec task-clock                #    1.046 CPUs utilized            ( +-  0.10% )
>>                310      context-switches          #    0.004 M/sec                    ( +-  0.31% )
>>                  1      cpu-migrations            #    0.008 K/sec                    ( +-  5.07% )
>>              4,004      page-faults               #    0.045 M/sec                    ( +-  0.01% )
>> ...
>>           0.084138 +- 0.000111 seconds time elapsed  ( +-  0.13% )
>> 
>> 
>> The easiest test of stdout with AsyncLogging is to use tty and XOFF Ctrl^s. Java applications with UL to stdout were blocked by Ctrl-s. The entire java process will be frozen.  -Xlog:async now cover both stdout and stderr. It can circumvent this issue.  
>> 
>> Add a new jtreg to cover a scenario that unified logging with -Xlog:async will not be frozen even when stdout is blocked.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo and the building eror on MacOS.

Hi Xin,

I think I get the gist of what this is doing now - thanks. A few minor comments below. I'm not sure about the robustness of the test, in particular whether destroyForcibly will be reliable enough on all platform. I will take it for a spin through our CI system.

Thanks,
David

src/hotspot/share/logging/logAsyncWriter.cpp line 154:

> 152:     assert(req == 1, "AsyncLogWriter::flush() is NOT MT-safe!");
> 153:     // LogFileOutput::write_block() has called fflush().
> 154:     // stderr does not cache.

cache? Do you mean "buffer"?

src/hotspot/share/logging/logAsyncWriter.cpp line 155:

> 153:     // LogFileOutput::write_block() has called fflush().
> 154:     // stderr does not cache.
> 155:     fflush(stdout);

if `LogFileOutput::write_block() has called fflush()` why are we calling it here?

src/hotspot/share/logging/logAsyncWriter.hpp line 31:

> 29: #include "memory/resourceArea.hpp"
> 30: #include "runtime/nonJavaThread.hpp"
> 31: #include "runtime/semaphore.hpp"

Seems unneeded by the other changes in this file.

test/hotspot/jtreg/runtime/logging/BlockedLoggingTest.java line 58:

> 56:             // The size of pipe buffer is indeterminate. It is presumably 64k on many Linux distros.
> 57:             // We just churn many gc-related logs in ChurnThread.Duration seconds.
> 58:             for(int i = 0; i < ThreadNum; ++i) {

Style nit: need space after 'for'

-------------

PR: https://git.openjdk.java.net/jdk/pull/6132

From ccheung at openjdk.java.net  Tue Dec 21 05:25:14 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Tue, 21 Dec 2021 05:25:14 GMT
Subject: RFR: 8279022: JCmdTestFileSafety.java should check file time stamp
 for test result
In-Reply-To: <Qh-8hNJgPf8_JS6dvx_5-hNCkmGN2qKUYGC7dk9L4Pc=.ead68363-0097-4e96-96ac-ad58ddb60fbd@github.com>
References: <Qh-8hNJgPf8_JS6dvx_5-hNCkmGN2qKUYGC7dk9L4Pc=.ead68363-0097-4e96-96ac-ad58ddb60fbd@github.com>
Message-ID: <IqMQTBcoxhJ3R3sLnrGacZtTKdRJonICgkwVidYGZcw=.6210b79e-c45a-4867-b3f7-25053618d07e@github.com>

On Tue, 21 Dec 2021 02:45:35 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> When test finished, the created archive file should be checked after  the first run for existence, and checked for time stamp after second run.  Since the file name is same, this method is more accurate than the existing checking, only checking the existence of the file. Since jcmd can do repeat dynamic dump to same java process now, removed unnecessary restart process code.
> 
> Tests: tier1, jtreg on local linux-x64.
> 
> Thanks
> Yumin

Looks good. Just one comment.

test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSafety.java line 104:

> 102:             fileLocal.delete();
> 103:         }
> 104:         outputDirFile.setWritable(true);

Since you've added the `setWritable(true)` here, do you still need the existing one at line 116?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6904

From dholmes at openjdk.java.net  Tue Dec 21 06:00:17 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 21 Dec 2021 06:00:17 GMT
Subject: RFR: 8267517: async logging for stdout and stderr [v3]
In-Reply-To: <ddwRuorCLqbH2zmw-PktIT9bm13hJ2jvNWJMX_1XQpo=.4f426bfb-b843-44c7-b935-fd748dd25db7@github.com>
References: <Nv1V5JHKgJh0NtqijGmWmI9Kh2VgDxgDIOAdfCtOavA=.503f41c2-a5d1-4a25-ab90-00252814a9bf@github.com>
 <ddwRuorCLqbH2zmw-PktIT9bm13hJ2jvNWJMX_1XQpo=.4f426bfb-b843-44c7-b935-fd748dd25db7@github.com>
Message-ID: <mH1OjVRTKcIYq6v5C3kXo55IY9kle2ENu--FP1tvnFg=.f0b9f96a-ecee-411a-ae38-3c509c019510@github.com>

On Thu, 16 Dec 2021 09:01:28 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch refactors LogFileStreamOutput so stdout/stderr can support support -Xlog:async.
>> 
>> With  `-Xlog:all=trace:stdout`, the helloworld in Java outputs 16520 log entries to stdout.  We are see that the wall time reduces from  84.138ms to 72.914ms, or the throughput increases 15% because of async logging.
>> 
>> 
>> $perf stat -r 300 ./build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -Xlog:async -XX:AsyncLogBufferSize=48M HelloWorld > /dev/null
>> 
>>  Performance counter stats for './build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -Xlog:async -XX:AsyncLogBufferSize=48M HelloWorld' (300 runs):
>> 
>>             107.21 msec task-clock                #    1.470 CPUs utilized            ( +-  0.17% )
>>              2,681      context-switches          #    0.025 M/sec                    ( +-  0.32% )
>>                  1      cpu-migrations            #    0.011 K/sec                    ( +-  4.56% )
>>              4,006      page-faults               #    0.037 M/sec                    ( +-  0.01% )
>> ...
>>           0.072914 +- 0.000126 seconds time elapsed  ( +-  0.17% )
>> 
>>  Performance counter stats for './build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -XX:AsyncLogBufferSize=48M HelloWorld' (300 runs):
>> 
>>              88.04 msec task-clock                #    1.046 CPUs utilized            ( +-  0.10% )
>>                310      context-switches          #    0.004 M/sec                    ( +-  0.31% )
>>                  1      cpu-migrations            #    0.008 K/sec                    ( +-  5.07% )
>>              4,004      page-faults               #    0.045 M/sec                    ( +-  0.01% )
>> ...
>>           0.084138 +- 0.000111 seconds time elapsed  ( +-  0.13% )
>> 
>> 
>> The easiest test of stdout with AsyncLogging is to use tty and XOFF Ctrl^s. Java applications with UL to stdout were blocked by Ctrl-s. The entire java process will be frozen.  -Xlog:async now cover both stdout and stderr. It can circumvent this issue.  
>> 
>> Add a new jtreg to cover a scenario that unified logging with -Xlog:async will not be frozen even when stdout is blocked.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo and the building eror on MacOS.

Sorry Xin, the test is timing out on Linux-x64. There's no information to diagnose any problems though.

David

-------------

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6132

From minqi at openjdk.java.net  Tue Dec 21 16:31:17 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 21 Dec 2021 16:31:17 GMT
Subject: RFR: 8279022: JCmdTestFileSafety.java should check file time stamp
 for test result
In-Reply-To: <IqMQTBcoxhJ3R3sLnrGacZtTKdRJonICgkwVidYGZcw=.6210b79e-c45a-4867-b3f7-25053618d07e@github.com>
References: <Qh-8hNJgPf8_JS6dvx_5-hNCkmGN2qKUYGC7dk9L4Pc=.ead68363-0097-4e96-96ac-ad58ddb60fbd@github.com>
 <IqMQTBcoxhJ3R3sLnrGacZtTKdRJonICgkwVidYGZcw=.6210b79e-c45a-4867-b3f7-25053618d07e@github.com>
Message-ID: <372gEoZTQbyGtI5jl72ElLszEFa0olUjf6wvjhXHVZk=.5fa3e709-6237-4cfb-bde3-56fb44bcbbc5@github.com>

On Tue, 21 Dec 2021 05:21:39 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> When test finished, the created archive file should be checked after  the first run for existence, and checked for time stamp after second run.  Since the file name is same, this method is more accurate than the existing checking, only checking the existence of the file. Since jcmd can do repeat dynamic dump to same java process now, removed unnecessary restart process code.
>> 
>> Tests: tier1, jtreg on local linux-x64.
>> 
>> Thanks
>> Yumin
>
> test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSafety.java line 104:
> 
>> 102:             fileLocal.delete();
>> 103:         }
>> 104:         outputDirFile.setWritable(true);
> 
> Since you've added the `setWritable(true)` here, do you still need the existing one at line 116?

It can be removed, but better keep it --- the testing result of last step is deleted just in case it could affect next test. I would like remove the result file anyway. Since the file name keep changing, I will update with a function with the file name (String) to delete the file. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6904

From minqi at openjdk.java.net  Tue Dec 21 16:51:36 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 21 Dec 2021 16:51:36 GMT
Subject: RFR: 8279022: JCmdTestFileSafety.java should check file time stamp
 for test result [v2]
In-Reply-To: <Qh-8hNJgPf8_JS6dvx_5-hNCkmGN2qKUYGC7dk9L4Pc=.ead68363-0097-4e96-96ac-ad58ddb60fbd@github.com>
References: <Qh-8hNJgPf8_JS6dvx_5-hNCkmGN2qKUYGC7dk9L4Pc=.ead68363-0097-4e96-96ac-ad58ddb60fbd@github.com>
Message-ID: <j1cVNG-fJ2TACsof7Se4a253JrPPJjoOg1MbSEOlJfQ=.61eae03d-757b-4b79-884d-501184f1c004@github.com>

> When test finished, the created archive file should be checked after  the first run for existence, and checked for time stamp after second run.  Since the file name is same, this method is more accurate than the existing checking, only checking the existence of the file. Since jcmd can do repeat dynamic dump to same java process now, removed unnecessary restart process code.
> 
> Tests: tier1, jtreg on local linux-x64.
> 
> Thanks
> Yumin

Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:

  Refactor remove file code

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6904/files
  - new: https://git.openjdk.java.net/jdk/pull/6904/files/4735d3ce..aad77282

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6904&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6904&range=00-01

  Stats: 21 lines in 1 file changed: 10 ins; 9 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6904.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6904/head:pull/6904

PR: https://git.openjdk.java.net/jdk/pull/6904

From dcubed at openjdk.java.net  Tue Dec 21 17:29:39 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 21 Dec 2021 17:29:39 GMT
Subject: [jdk18] RFR: 8279074: ProblemList
 compiler/codecache/jmx/PoolsIndependenceTest.java on macosx-aarch64
Message-ID: <Fcd_a3LXDzP14DiqO0fHDec8j0xYrznGje8GfngSlIg=.01ed5c58-c843-4f0d-a451-cbc300158c08@github.com>

A trivial fix to ProblemList compiler/codecache/jmx/PoolsIndependenceTest.java on macosx-aarch64.

-------------

Commit messages:
 - 8279074: ProblemList compiler/codecache/jmx/PoolsIndependenceTest.java on macosx-aarch64

Changes: https://git.openjdk.java.net/jdk18/pull/59/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=59&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279074
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/59.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/59/head:pull/59

PR: https://git.openjdk.java.net/jdk18/pull/59

From ccheung at openjdk.java.net  Tue Dec 21 17:42:17 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Tue, 21 Dec 2021 17:42:17 GMT
Subject: [jdk18] RFR: 8279074: ProblemList
 compiler/codecache/jmx/PoolsIndependenceTest.java on macosx-aarch64
In-Reply-To: <Fcd_a3LXDzP14DiqO0fHDec8j0xYrznGje8GfngSlIg=.01ed5c58-c843-4f0d-a451-cbc300158c08@github.com>
References: <Fcd_a3LXDzP14DiqO0fHDec8j0xYrznGje8GfngSlIg=.01ed5c58-c843-4f0d-a451-cbc300158c08@github.com>
Message-ID: <aHcfmzWcLZuAAv9KyXwY_EDDacRbRWtpjsJVcQznYs8=.d8d8464b-f120-41a6-8a60-4d87b91f3adc@github.com>

On Tue, 21 Dec 2021 17:14:50 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList compiler/codecache/jmx/PoolsIndependenceTest.java on macosx-aarch64.

LGTM.

-------------

Marked as reviewed by ccheung (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/59

From dcubed at openjdk.java.net  Tue Dec 21 17:42:17 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 21 Dec 2021 17:42:17 GMT
Subject: [jdk18] RFR: 8279074: ProblemList
 compiler/codecache/jmx/PoolsIndependenceTest.java on macosx-aarch64
In-Reply-To: <aHcfmzWcLZuAAv9KyXwY_EDDacRbRWtpjsJVcQznYs8=.d8d8464b-f120-41a6-8a60-4d87b91f3adc@github.com>
References: <Fcd_a3LXDzP14DiqO0fHDec8j0xYrznGje8GfngSlIg=.01ed5c58-c843-4f0d-a451-cbc300158c08@github.com>
 <aHcfmzWcLZuAAv9KyXwY_EDDacRbRWtpjsJVcQznYs8=.d8d8464b-f120-41a6-8a60-4d87b91f3adc@github.com>
Message-ID: <UDPQwK3mmwXnfn7seCauUG6ws_VOBpZV8mzjSOFVLlk=.9d0d1d93-794a-484c-b1fb-7f469026d272@github.com>

On Tue, 21 Dec 2021 17:39:00 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> A trivial fix to ProblemList compiler/codecache/jmx/PoolsIndependenceTest.java on macosx-aarch64.
>
> LGTM.

@calvinccheung - Thanks for the review!

-------------

PR: https://git.openjdk.java.net/jdk18/pull/59

From dcubed at openjdk.java.net  Tue Dec 21 17:46:18 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 21 Dec 2021 17:46:18 GMT
Subject: [jdk18] Integrated: 8279074: ProblemList
 compiler/codecache/jmx/PoolsIndependenceTest.java on macosx-aarch64
In-Reply-To: <Fcd_a3LXDzP14DiqO0fHDec8j0xYrznGje8GfngSlIg=.01ed5c58-c843-4f0d-a451-cbc300158c08@github.com>
References: <Fcd_a3LXDzP14DiqO0fHDec8j0xYrznGje8GfngSlIg=.01ed5c58-c843-4f0d-a451-cbc300158c08@github.com>
Message-ID: <5WVYUKB0NSQx1wq_Tk_giapnvx_6KmXvqDk9qwGjZoQ=.b6a4b574-34e7-438d-83a5-79e97fa78775@github.com>

On Tue, 21 Dec 2021 17:14:50 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList compiler/codecache/jmx/PoolsIndependenceTest.java on macosx-aarch64.

This pull request has now been integrated.

Changeset: 54517fa3
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/54517fa3d80b50bfa8a4f6b7937b95e379a1dfeb
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8279074: ProblemList compiler/codecache/jmx/PoolsIndependenceTest.java on macosx-aarch64

Reviewed-by: ccheung

-------------

PR: https://git.openjdk.java.net/jdk18/pull/59

From ccheung at openjdk.java.net  Tue Dec 21 18:02:12 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Tue, 21 Dec 2021 18:02:12 GMT
Subject: RFR: 8279022: JCmdTestFileSafety.java should check file time stamp
 for test result [v2]
In-Reply-To: <j1cVNG-fJ2TACsof7Se4a253JrPPJjoOg1MbSEOlJfQ=.61eae03d-757b-4b79-884d-501184f1c004@github.com>
References: <Qh-8hNJgPf8_JS6dvx_5-hNCkmGN2qKUYGC7dk9L4Pc=.ead68363-0097-4e96-96ac-ad58ddb60fbd@github.com>
 <j1cVNG-fJ2TACsof7Se4a253JrPPJjoOg1MbSEOlJfQ=.61eae03d-757b-4b79-884d-501184f1c004@github.com>
Message-ID: <hjGqXCtXws5DunmlmhznO9keUE5f13Y0zqhxOmtUm2I=.124844f5-0c9a-4a87-8737-c45c08892a6f@github.com>

On Tue, 21 Dec 2021 16:51:36 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> When test finished, the created archive file should be checked after  the first run for existence, and checked for time stamp after second run.  Since the file name is same, this method is more accurate than the existing checking, only checking the existence of the file. Since jcmd can do repeat dynamic dump to same java process now, removed unnecessary restart process code.
>> 
>> Tests: tier1, jtreg on local linux-x64.
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor remove file code

Update looks good.

-------------

Marked as reviewed by ccheung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6904

From dcubed at openjdk.java.net  Tue Dec 21 18:38:17 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 21 Dec 2021 18:38:17 GMT
Subject: [jdk18] RFR: 8272058: 25 Null pointer dereference defect groups in
 4 files
In-Reply-To: <TwIvJ3FE4o5AqZ38OQaZhzhB5Ctdph9LYLcQOEZswPk=.14774a97-d3e1-44e1-8a91-568c9d632334@github.com>
References: <TwIvJ3FE4o5AqZ38OQaZhzhB5Ctdph9LYLcQOEZswPk=.14774a97-d3e1-44e1-8a91-568c9d632334@github.com>
Message-ID: <axbnUJl1CBuRMuYaZwtzNDpX3G7r_dzMhm9hSFYqz1A=.1b213f92-1b84-4e82-9d28-336894d1fa23@github.com>

On Mon, 20 Dec 2021 20:50:14 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A small refactoring to resolve a Parfait complaint about the return value from
> `MacroAssembler::target_addr_for_insn(address insn_addr, unsigned insn)`
> on AARCH64. The logic that supports returning `nullptr` as the target addr for
> a particular instruction is moved from
> `MacroAssembler::target_addr_for_insn(address insn_addr, unsigned insn)` to
> `MacroAssembler::target_addr_for_insn_allow_null_ret(address insn_addr, unsigned insn)`.
> A couple of `target_addr_for_insn()` call sites that can tolerate a `nullptr` are
> converted to use `target_addr_for_insn_allow_null_ret()`.
> 
> This fix has been tested with Mach5 Tier[1-3].

@gerard-ziemski - When you have a chance, could you take a look at this one?

-------------

PR: https://git.openjdk.java.net/jdk18/pull/51

From xliu at openjdk.java.net  Tue Dec 21 19:30:17 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 21 Dec 2021 19:30:17 GMT
Subject: RFR: 8267517: async logging for stdout and stderr [v3]
In-Reply-To: <n4MKggE1CsTP9F4f3vYXt-AyaP_TMmF2px-XuxaB2EI=.3efa60a5-a850-4139-81fe-6be8be576d38@github.com>
References: <Nv1V5JHKgJh0NtqijGmWmI9Kh2VgDxgDIOAdfCtOavA=.503f41c2-a5d1-4a25-ab90-00252814a9bf@github.com>
 <ddwRuorCLqbH2zmw-PktIT9bm13hJ2jvNWJMX_1XQpo=.4f426bfb-b843-44c7-b935-fd748dd25db7@github.com>
 <n4MKggE1CsTP9F4f3vYXt-AyaP_TMmF2px-XuxaB2EI=.3efa60a5-a850-4139-81fe-6be8be576d38@github.com>
Message-ID: <xE9tclSchzt2MOn0RFfWMmjjkhWC5lCCr1SKbwp-k5I=.efaf2fc3-c5bf-42ae-a7bf-ce3a39145fe0@github.com>

On Tue, 21 Dec 2021 02:39:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo and the building eror on MacOS.
>
> src/hotspot/share/logging/logAsyncWriter.cpp line 154:
> 
>> 152:     assert(req == 1, "AsyncLogWriter::flush() is NOT MT-safe!");
>> 153:     // LogFileOutput::write_block() has called fflush().
>> 154:     // stderr does not cache.
> 
> cache? Do you mean "buffer"?

`buffer` is the right word.LogFileOut::write_block() has called fflush() to flush all file-based streams.
LogStdoutOutput/LogFileStreamOutput haven't because of `LogFileStreamOutput::write_blocking()`. 

stderr is unbuffered, so I think we only need to flush stdout here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6132

From dcubed at openjdk.java.net  Tue Dec 21 20:05:42 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 21 Dec 2021 20:05:42 GMT
Subject: [jdk18] RFR: 8279081: ProblemList
 jdk/jfr/event/oldobject/TestLargeRootSet.java on 2 platforms
Message-ID: <0z7Mol-zO4V_CMCcotDf_72hW4-tuyEvrXbO1WI5RJk=.d7d9c5c4-c325-400f-9639-ab1beced5b2d@github.com>

A trivial fix to ProblemList jdk/jfr/event/oldobject/TestLargeRootSet.java on 2 platforms

-------------

Commit messages:
 - 8279081: ProblemList jdk/jfr/event/oldobject/TestLargeRootSet.java on 2 platforms

Changes: https://git.openjdk.java.net/jdk18/pull/61/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=61&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279081
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/61.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/61/head:pull/61

PR: https://git.openjdk.java.net/jdk18/pull/61

From azvegint at openjdk.java.net  Tue Dec 21 20:42:18 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 21 Dec 2021 20:42:18 GMT
Subject: [jdk18] RFR: 8279081: ProblemList
 jdk/jfr/event/oldobject/TestLargeRootSet.java on 2 platforms
In-Reply-To: <0z7Mol-zO4V_CMCcotDf_72hW4-tuyEvrXbO1WI5RJk=.d7d9c5c4-c325-400f-9639-ab1beced5b2d@github.com>
References: <0z7Mol-zO4V_CMCcotDf_72hW4-tuyEvrXbO1WI5RJk=.d7d9c5c4-c325-400f-9639-ab1beced5b2d@github.com>
Message-ID: <LwZe120n0y33DXad8BYp6yhjktW3uqne4ud38Jo796A=.a214f312-75c6-4f4c-b722-288abc0502c5@github.com>

On Tue, 21 Dec 2021 19:56:07 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/jfr/event/oldobject/TestLargeRootSet.java on 2 platforms

Marked as reviewed by azvegint (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk18/pull/61

From sspitsyn at openjdk.java.net  Tue Dec 21 20:42:18 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 21 Dec 2021 20:42:18 GMT
Subject: [jdk18] RFR: 8279081: ProblemList
 jdk/jfr/event/oldobject/TestLargeRootSet.java on 2 platforms
In-Reply-To: <0z7Mol-zO4V_CMCcotDf_72hW4-tuyEvrXbO1WI5RJk=.d7d9c5c4-c325-400f-9639-ab1beced5b2d@github.com>
References: <0z7Mol-zO4V_CMCcotDf_72hW4-tuyEvrXbO1WI5RJk=.d7d9c5c4-c325-400f-9639-ab1beced5b2d@github.com>
Message-ID: <SlYPYeNZbp70c-NQE0A1AMSQCNGwhKVoT5lj6CiSYLc=.871f1a3b-19b4-4ab1-be76-1dee711954f4@github.com>

On Tue, 21 Dec 2021 19:56:07 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/jfr/event/oldobject/TestLargeRootSet.java on 2 platforms

Hi Dan,
This is good and trivial.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/61

From dcubed at openjdk.java.net  Tue Dec 21 20:42:18 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 21 Dec 2021 20:42:18 GMT
Subject: [jdk18] RFR: 8279081: ProblemList
 jdk/jfr/event/oldobject/TestLargeRootSet.java on 2 platforms
In-Reply-To: <LwZe120n0y33DXad8BYp6yhjktW3uqne4ud38Jo796A=.a214f312-75c6-4f4c-b722-288abc0502c5@github.com>
References: <0z7Mol-zO4V_CMCcotDf_72hW4-tuyEvrXbO1WI5RJk=.d7d9c5c4-c325-400f-9639-ab1beced5b2d@github.com>
 <LwZe120n0y33DXad8BYp6yhjktW3uqne4ud38Jo796A=.a214f312-75c6-4f4c-b722-288abc0502c5@github.com>
Message-ID: <vcMC-8YmaXVTlkzdTKJmZ9lXJXyiiy6m2HER_AvAuNw=.e3e41566-6b44-412b-a3a4-702da9d74b85@github.com>

On Tue, 21 Dec 2021 20:36:05 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> A trivial fix to ProblemList jdk/jfr/event/oldobject/TestLargeRootSet.java on 2 platforms
>
> Marked as reviewed by azvegint (Reviewer).

@azvegint and @sspitsyn - Thanks for the reviews!

-------------

PR: https://git.openjdk.java.net/jdk18/pull/61

From dcubed at openjdk.java.net  Tue Dec 21 20:42:18 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 21 Dec 2021 20:42:18 GMT
Subject: [jdk18] Integrated: 8279081: ProblemList
 jdk/jfr/event/oldobject/TestLargeRootSet.java on 2 platforms
In-Reply-To: <0z7Mol-zO4V_CMCcotDf_72hW4-tuyEvrXbO1WI5RJk=.d7d9c5c4-c325-400f-9639-ab1beced5b2d@github.com>
References: <0z7Mol-zO4V_CMCcotDf_72hW4-tuyEvrXbO1WI5RJk=.d7d9c5c4-c325-400f-9639-ab1beced5b2d@github.com>
Message-ID: <Vf3wTLpvRVMTAHXkO6XKW6OkYKDUxmhWOdRzYrNO33k=.0790b1ff-cffe-4d65-9a20-abbc3f49b72e@github.com>

On Tue, 21 Dec 2021 19:56:07 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/jfr/event/oldobject/TestLargeRootSet.java on 2 platforms

This pull request has now been integrated.

Changeset: 84d3333c
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/84d3333c7a979742021e759766a7290539b569f4
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8279081: ProblemList jdk/jfr/event/oldobject/TestLargeRootSet.java on 2 platforms

Reviewed-by: azvegint, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk18/pull/61

From xliu at openjdk.java.net  Tue Dec 21 20:46:20 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 21 Dec 2021 20:46:20 GMT
Subject: RFR: 8267517: async logging for stdout and stderr [v3]
In-Reply-To: <n4MKggE1CsTP9F4f3vYXt-AyaP_TMmF2px-XuxaB2EI=.3efa60a5-a850-4139-81fe-6be8be576d38@github.com>
References: <Nv1V5JHKgJh0NtqijGmWmI9Kh2VgDxgDIOAdfCtOavA=.503f41c2-a5d1-4a25-ab90-00252814a9bf@github.com>
 <ddwRuorCLqbH2zmw-PktIT9bm13hJ2jvNWJMX_1XQpo=.4f426bfb-b843-44c7-b935-fd748dd25db7@github.com>
 <n4MKggE1CsTP9F4f3vYXt-AyaP_TMmF2px-XuxaB2EI=.3efa60a5-a850-4139-81fe-6be8be576d38@github.com>
Message-ID: <RESIrLuJHJVL5o9LGaW9jUfyT9if-lZySWuuQ4FatFg=.ad85dafe-978f-433b-bb34-4d117e8fa5c2@github.com>

On Tue, 21 Dec 2021 02:44:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo and the building eror on MacOS.
>
> src/hotspot/share/logging/logAsyncWriter.hpp line 31:
> 
>> 29: #include "memory/resourceArea.hpp"
>> 30: #include "runtime/nonJavaThread.hpp"
>> 31: #include "runtime/semaphore.hpp"
> 
> Seems unneeded by the other changes in this file.

We  can't compile without this header file. The definition of Semaphore is needed (145: Semaphore _flush_sem;) and it was drag in from logFileOutput.hpp. 

This is a cleanup.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6132

From xliu at openjdk.java.net  Tue Dec 21 21:51:48 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 21 Dec 2021 21:51:48 GMT
Subject: RFR: 8267517: async logging for stdout and stderr [v4]
In-Reply-To: <Nv1V5JHKgJh0NtqijGmWmI9Kh2VgDxgDIOAdfCtOavA=.503f41c2-a5d1-4a25-ab90-00252814a9bf@github.com>
References: <Nv1V5JHKgJh0NtqijGmWmI9Kh2VgDxgDIOAdfCtOavA=.503f41c2-a5d1-4a25-ab90-00252814a9bf@github.com>
Message-ID: <cxfd45Cht-cjdQo39E2z23a8ER69BGNupAnWfqAUx-s=.73d8f4e2-60dc-4bc8-b256-be1e97263f2c@github.com>

> This patch refactors LogFileStreamOutput so stdout/stderr can support support -Xlog:async.
> 
> With  `-Xlog:all=trace:stdout`, the helloworld in Java outputs 16520 log entries to stdout.  We are see that the wall time reduces from  84.138ms to 72.914ms, or the throughput increases 15% because of async logging.
> 
> 
> $perf stat -r 300 ./build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -Xlog:async -XX:AsyncLogBufferSize=48M HelloWorld > /dev/null
> 
>  Performance counter stats for './build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -Xlog:async -XX:AsyncLogBufferSize=48M HelloWorld' (300 runs):
> 
>             107.21 msec task-clock                #    1.470 CPUs utilized            ( +-  0.17% )
>              2,681      context-switches          #    0.025 M/sec                    ( +-  0.32% )
>                  1      cpu-migrations            #    0.011 K/sec                    ( +-  4.56% )
>              4,006      page-faults               #    0.037 M/sec                    ( +-  0.01% )
> ...
>           0.072914 +- 0.000126 seconds time elapsed  ( +-  0.17% )
> 
>  Performance counter stats for './build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -XX:AsyncLogBufferSize=48M HelloWorld' (300 runs):
> 
>              88.04 msec task-clock                #    1.046 CPUs utilized            ( +-  0.10% )
>                310      context-switches          #    0.004 M/sec                    ( +-  0.31% )
>                  1      cpu-migrations            #    0.008 K/sec                    ( +-  5.07% )
>              4,004      page-faults               #    0.045 M/sec                    ( +-  0.01% )
> ...
>           0.084138 +- 0.000111 seconds time elapsed  ( +-  0.13% )
> 
> 
> The easiest test of stdout with AsyncLogging is to use tty and XOFF Ctrl^s. Java applications with UL to stdout were blocked by Ctrl-s. The entire java process will be frozen.  -Xlog:async now cover both stdout and stderr. It can circumvent this issue.  
> 
> Add a new jtreg to cover a scenario that unified logging with -Xlog:async will not be frozen even when stdout is blocked.

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  Sideline BlockedLoggingTest.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6132/files
  - new: https://git.openjdk.java.net/jdk/pull/6132/files/396f7cd1..769110a2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6132&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6132&range=02-03

  Stats: 4 lines in 3 files changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6132.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6132/head:pull/6132

PR: https://git.openjdk.java.net/jdk/pull/6132

From xliu at openjdk.java.net  Tue Dec 21 22:15:28 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 21 Dec 2021 22:15:28 GMT
Subject: RFR: 8267517: async logging for stdout and stderr [v3]
In-Reply-To: <n4MKggE1CsTP9F4f3vYXt-AyaP_TMmF2px-XuxaB2EI=.3efa60a5-a850-4139-81fe-6be8be576d38@github.com>
References: <Nv1V5JHKgJh0NtqijGmWmI9Kh2VgDxgDIOAdfCtOavA=.503f41c2-a5d1-4a25-ab90-00252814a9bf@github.com>
 <ddwRuorCLqbH2zmw-PktIT9bm13hJ2jvNWJMX_1XQpo=.4f426bfb-b843-44c7-b935-fd748dd25db7@github.com>
 <n4MKggE1CsTP9F4f3vYXt-AyaP_TMmF2px-XuxaB2EI=.3efa60a5-a850-4139-81fe-6be8be576d38@github.com>
Message-ID: <nNJfsPEuz1jJsvAhtVc_GbC2v7rjsBrybot4nTNHIeU=.9b61e42f-d160-4437-8258-ff9e3e1fdbf5@github.com>

On Tue, 21 Dec 2021 02:43:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo and the building eror on MacOS.
>
> src/hotspot/share/logging/logAsyncWriter.cpp line 155:
> 
>> 153:     // LogFileOutput::write_block() has called fflush().
>> 154:     // stderr does not cache.
>> 155:     fflush(stdout);
> 
> if `LogFileOutput::write_block() has called fflush()` why are we calling it here?

because `LogFileStreamOutput::write_blocking()` doesn't call fflush(), therefore, we need to do special treat for STDOUT here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6132

From ccheung at openjdk.java.net  Tue Dec 21 22:23:16 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Tue, 21 Dec 2021 22:23:16 GMT
Subject: RFR: 8279018: CRC calculation in CDS should not include _version
 and _head_size [v2]
In-Reply-To: <BDK-dsu8t4KQTUpF76Iia0VkqJMbLXplqBwUgR1w0cA=.cbd1ecd4-f6ae-421a-9a7a-0f9ce7f28b5e@github.com>
References: <Z1Fof383_r1H31EUrl1q2RWSBd1JDQYSZBOxRCv4hRs=.80548e3e-9a38-431f-89e6-621b0d5eb13c@github.com>
 <BDK-dsu8t4KQTUpF76Iia0VkqJMbLXplqBwUgR1w0cA=.cbd1ecd4-f6ae-421a-9a7a-0f9ce7f28b5e@github.com>
Message-ID: <_g88eLxLqv2lPog8hhKTrJh360HI6bzTr9sbCW9MRz0=.11d024d8-b28c-43ed-bfff-85166c251c36@github.com>

On Tue, 21 Dec 2021 04:17:50 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Please review the simple change for not including _version and _header_size in crc computation. These two fields are checked separately and they should not affect crc.
>> 
>> tests: tier1,tier4
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore GenericCDSFileMapHeader data layout, change compute_crc instead, add code to WhiteBox to get versions instead of hard code

I have couple of comments in whitebox.cpp.

src/hotspot/share/prims/whitebox.cpp line 1972:

> 1970:   return (jint)CURRENT_CDS_ARCHIVE_VERSION;
> 1971: WB_END
> 1972: 

Should these two functions be inside a `#if INCLUDE_CDS` block?

src/hotspot/share/prims/whitebox.cpp line 2696:

> 2694:                                                       (void*)&WB_GetDefaultArchivePath},
> 2695:   {CC"getCDSGenericHeaderMinVersion",     CC"()I",    (void*)&WB_GetCDSGenericHeaderMinVersion},
> 2696:   {CC"getCurrentCDSVersion",              CC"()I",    (void*)&WB_GetCDSCurrentVersion},

I think the above should also be inside a `#if INCLUDE_CDS` block.

Also, I think the cds.h should be included explicitly; currently it is included transitively via filemap.hpp.

Pre-existing issue: below CDS specific include statements should be inside a `#if INCLUDE_CDS` block.

  27 #include "cds/cdsConstants.hpp"
  28 #include "cds/filemap.hpp"
  29 #include "cds/heapShared.inline.hpp"
  30 #include "cds/metaspaceShared.hpp"

-------------

PR: https://git.openjdk.java.net/jdk/pull/6899

From iklam at openjdk.java.net  Tue Dec 21 22:27:14 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 21 Dec 2021 22:27:14 GMT
Subject: RFR: 8279018: CRC calculation in CDS should not include _version
 and _head_size [v2]
In-Reply-To: <BDK-dsu8t4KQTUpF76Iia0VkqJMbLXplqBwUgR1w0cA=.cbd1ecd4-f6ae-421a-9a7a-0f9ce7f28b5e@github.com>
References: <Z1Fof383_r1H31EUrl1q2RWSBd1JDQYSZBOxRCv4hRs=.80548e3e-9a38-431f-89e6-621b0d5eb13c@github.com>
 <BDK-dsu8t4KQTUpF76Iia0VkqJMbLXplqBwUgR1w0cA=.cbd1ecd4-f6ae-421a-9a7a-0f9ce7f28b5e@github.com>
Message-ID: <8cl-CaNCE63-j-Vb8Zo3GvjFRDUozBge5lZivWuOTMI=.3d4aad2a-4f29-4e43-a4b3-0e9afdc006b3@github.com>

On Tue, 21 Dec 2021 04:17:50 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Please review the simple change for not including _version and _header_size in crc computation. These two fields are checked separately and they should not affect crc.
>> 
>> tests: tier1,tier4
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore GenericCDSFileMapHeader data layout, change compute_crc instead, add code to WhiteBox to get versions instead of hard code

LGTM

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6899

From dholmes at openjdk.java.net  Tue Dec 21 22:39:18 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 21 Dec 2021 22:39:18 GMT
Subject: RFR: 8267517: async logging for stdout and stderr [v4]
In-Reply-To: <cxfd45Cht-cjdQo39E2z23a8ER69BGNupAnWfqAUx-s=.73d8f4e2-60dc-4bc8-b256-be1e97263f2c@github.com>
References: <Nv1V5JHKgJh0NtqijGmWmI9Kh2VgDxgDIOAdfCtOavA=.503f41c2-a5d1-4a25-ab90-00252814a9bf@github.com>
 <cxfd45Cht-cjdQo39E2z23a8ER69BGNupAnWfqAUx-s=.73d8f4e2-60dc-4bc8-b256-be1e97263f2c@github.com>
Message-ID: <UX1Jrh43107AowN2U2a4vdB67FU7iFhyNxmcYcrojvA=.95ad706a-927d-4cb6-8aa9-208796af82f9@github.com>

On Tue, 21 Dec 2021 21:51:48 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch refactors LogFileStreamOutput so stdout/stderr can support support -Xlog:async.
>> 
>> With  `-Xlog:all=trace:stdout`, the helloworld in Java outputs 16520 log entries to stdout.  We are see that the wall time reduces from  84.138ms to 72.914ms, or the throughput increases 15% because of async logging.
>> 
>> 
>> $perf stat -r 300 ./build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -Xlog:async -XX:AsyncLogBufferSize=48M HelloWorld > /dev/null
>> 
>>  Performance counter stats for './build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -Xlog:async -XX:AsyncLogBufferSize=48M HelloWorld' (300 runs):
>> 
>>             107.21 msec task-clock                #    1.470 CPUs utilized            ( +-  0.17% )
>>              2,681      context-switches          #    0.025 M/sec                    ( +-  0.32% )
>>                  1      cpu-migrations            #    0.011 K/sec                    ( +-  4.56% )
>>              4,006      page-faults               #    0.037 M/sec                    ( +-  0.01% )
>> ...
>>           0.072914 +- 0.000126 seconds time elapsed  ( +-  0.17% )
>> 
>>  Performance counter stats for './build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -XX:AsyncLogBufferSize=48M HelloWorld' (300 runs):
>> 
>>              88.04 msec task-clock                #    1.046 CPUs utilized            ( +-  0.10% )
>>                310      context-switches          #    0.004 M/sec                    ( +-  0.31% )
>>                  1      cpu-migrations            #    0.008 K/sec                    ( +-  5.07% )
>>              4,004      page-faults               #    0.045 M/sec                    ( +-  0.01% )
>> ...
>>           0.084138 +- 0.000111 seconds time elapsed  ( +-  0.13% )
>> 
>> 
>> The easiest test of stdout with AsyncLogging is to use tty and XOFF Ctrl^s. Java applications with UL to stdout were blocked by Ctrl-s. The entire java process will be frozen.  -Xlog:async now cover both stdout and stderr. It can circumvent this issue.  
>> 
>> Add a new jtreg to cover a scenario that unified logging with -Xlog:async will not be frozen even when stdout is blocked.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sideline BlockedLoggingTest.java

src/hotspot/share/logging/logAsyncWriter.cpp line 153:

> 151:   if (req > 0) {
> 152:     assert(req == 1, "AsyncLogWriter::flush() is NOT MT-safe!");
> 153:     // LogFileOutput::write_block() has called fflush().

write_block or write_blocking?

test/hotspot/jtreg/ProblemList.txt line 113:

> 111: containers/docker/TestJcmd.java 8278102 linux-aarch64
> 112: 
> 113: runtime/logging/BlockedLoggingTest.java 8267517 generic-all

First you can't ProblemList a test using the bug id of the bug that added the test - it would need to have  a separate bug id as when that bug is fixed then you remove the entry from the problem-list.

But second you can't add a test and immediately ProblemList it. The test needs to be fixed or dropped completely. A minimal test that shows you can now use stdout/stderr with async logging, even if you can't prove the logging was actually async, would be better than nothing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6132

From dholmes at openjdk.java.net  Tue Dec 21 22:39:19 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 21 Dec 2021 22:39:19 GMT
Subject: RFR: 8267517: async logging for stdout and stderr [v3]
In-Reply-To: <nNJfsPEuz1jJsvAhtVc_GbC2v7rjsBrybot4nTNHIeU=.9b61e42f-d160-4437-8258-ff9e3e1fdbf5@github.com>
References: <Nv1V5JHKgJh0NtqijGmWmI9Kh2VgDxgDIOAdfCtOavA=.503f41c2-a5d1-4a25-ab90-00252814a9bf@github.com>
 <ddwRuorCLqbH2zmw-PktIT9bm13hJ2jvNWJMX_1XQpo=.4f426bfb-b843-44c7-b935-fd748dd25db7@github.com>
 <n4MKggE1CsTP9F4f3vYXt-AyaP_TMmF2px-XuxaB2EI=.3efa60a5-a850-4139-81fe-6be8be576d38@github.com>
 <nNJfsPEuz1jJsvAhtVc_GbC2v7rjsBrybot4nTNHIeU=.9b61e42f-d160-4437-8258-ff9e3e1fdbf5@github.com>
Message-ID: <vDLjYnXX2GN7mCoiYT6Ebr1jVl_cqQVXH8SrElpF2fc=.a79f95a4-a463-4ff0-afc3-9b3f70d39683@github.com>

On Tue, 21 Dec 2021 22:11:48 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> src/hotspot/share/logging/logAsyncWriter.cpp line 155:
>> 
>>> 153:     // LogFileOutput::write_block() has called fflush().
>>> 154:     // stderr does not cache.
>>> 155:     fflush(stdout);
>> 
>> if `LogFileOutput::write_block() has called fflush()` why are we calling it here?
>
> because `LogFileStreamOutput::write_blocking()` doesn't call fflush(), therefore, we need to do special treat for STDOUT here.

Okay so why does LFO::write_blocking call fflush but LFSO::write_blocking does not? Shouldn't the two methods have the same general semantics?

>> src/hotspot/share/logging/logAsyncWriter.hpp line 31:
>> 
>>> 29: #include "memory/resourceArea.hpp"
>>> 30: #include "runtime/nonJavaThread.hpp"
>>> 31: #include "runtime/semaphore.hpp"
>> 
>> Seems unneeded by the other changes in this file.
>
> We  can't compile without this header file. The definition of Semaphore is needed (145: Semaphore _flush_sem;) and it was drag in from logFileOutput.hpp. 
> 
> This is a cleanup.

Okay.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6132

From minqi at openjdk.java.net  Wed Dec 22 00:46:18 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 22 Dec 2021 00:46:18 GMT
Subject: RFR: 8279018: CRC calculation in CDS should not include _version
 and _head_size [v2]
In-Reply-To: <_g88eLxLqv2lPog8hhKTrJh360HI6bzTr9sbCW9MRz0=.11d024d8-b28c-43ed-bfff-85166c251c36@github.com>
References: <Z1Fof383_r1H31EUrl1q2RWSBd1JDQYSZBOxRCv4hRs=.80548e3e-9a38-431f-89e6-621b0d5eb13c@github.com>
 <BDK-dsu8t4KQTUpF76Iia0VkqJMbLXplqBwUgR1w0cA=.cbd1ecd4-f6ae-421a-9a7a-0f9ce7f28b5e@github.com>
 <_g88eLxLqv2lPog8hhKTrJh360HI6bzTr9sbCW9MRz0=.11d024d8-b28c-43ed-bfff-85166c251c36@github.com>
Message-ID: <qMHRLQGl5phNs2WB_TCKZishNL203KYSIKcn-X0VDAk=.7e98ab08-c629-4b75-b1dc-efa139dab84b@github.com>

On Tue, 21 Dec 2021 22:19:15 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restore GenericCDSFileMapHeader data layout, change compute_crc instead, add code to WhiteBox to get versions instead of hard code
>
> src/hotspot/share/prims/whitebox.cpp line 1972:
> 
>> 1970:   return (jint)CURRENT_CDS_ARCHIVE_VERSION;
>> 1971: WB_END
>> 1972: 
> 
> Should these two functions be inside a `#if INCLUDE_CDS` block?

We can return different values if INCLUDE_CDS is not defined. The functions should be available for java native functions, or a link error will be thrown when they are linked. Same answer to your next question.

> src/hotspot/share/prims/whitebox.cpp line 2696:
> 
>> 2694:                                                       (void*)&WB_GetDefaultArchivePath},
>> 2695:   {CC"getCDSGenericHeaderMinVersion",     CC"()I",    (void*)&WB_GetCDSGenericHeaderMinVersion},
>> 2696:   {CC"getCurrentCDSVersion",              CC"()I",    (void*)&WB_GetCDSCurrentVersion},
> 
> I think the above should also be inside a `#if INCLUDE_CDS` block.
> 
> Also, I think the cds.h should be included explicitly; currently it is included transitively via filemap.hpp.
> 
> Pre-existing issue: below CDS specific include statements should be inside a `#if INCLUDE_CDS` block.
> 
>   27 #include "cds/cdsConstants.hpp"
>   28 #include "cds/filemap.hpp"
>   29 #include "cds/heapShared.inline.hpp"
>   30 #include "cds/metaspaceShared.hpp"

I will add include "cds.h". Those including, should be cleaned up in a separate issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6899

From xliu at openjdk.java.net  Wed Dec 22 01:36:17 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 22 Dec 2021 01:36:17 GMT
Subject: RFR: 8267517: async logging for stdout and stderr [v4]
In-Reply-To: <cxfd45Cht-cjdQo39E2z23a8ER69BGNupAnWfqAUx-s=.73d8f4e2-60dc-4bc8-b256-be1e97263f2c@github.com>
References: <Nv1V5JHKgJh0NtqijGmWmI9Kh2VgDxgDIOAdfCtOavA=.503f41c2-a5d1-4a25-ab90-00252814a9bf@github.com>
 <cxfd45Cht-cjdQo39E2z23a8ER69BGNupAnWfqAUx-s=.73d8f4e2-60dc-4bc8-b256-be1e97263f2c@github.com>
Message-ID: <QUUc0VBr33PS5LEQqv7F6OdWkFt_JgCXW3cd3bPAmrc=.0dcbfbd5-1df1-46e3-ad29-703758c3c997@github.com>

On Tue, 21 Dec 2021 21:51:48 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch refactors LogFileStreamOutput so stdout/stderr can support support -Xlog:async.
>> 
>> With  `-Xlog:all=trace:stdout`, the helloworld in Java outputs 16520 log entries to stdout.  We are see that the wall time reduces from  84.138ms to 72.914ms, or the throughput increases 15% because of async logging.
>> 
>> 
>> $perf stat -r 300 ./build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -Xlog:async -XX:AsyncLogBufferSize=48M HelloWorld > /dev/null
>> 
>>  Performance counter stats for './build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -Xlog:async -XX:AsyncLogBufferSize=48M HelloWorld' (300 runs):
>> 
>>             107.21 msec task-clock                #    1.470 CPUs utilized            ( +-  0.17% )
>>              2,681      context-switches          #    0.025 M/sec                    ( +-  0.32% )
>>                  1      cpu-migrations            #    0.011 K/sec                    ( +-  4.56% )
>>              4,006      page-faults               #    0.037 M/sec                    ( +-  0.01% )
>> ...
>>           0.072914 +- 0.000126 seconds time elapsed  ( +-  0.17% )
>> 
>>  Performance counter stats for './build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -XX:AsyncLogBufferSize=48M HelloWorld' (300 runs):
>> 
>>              88.04 msec task-clock                #    1.046 CPUs utilized            ( +-  0.10% )
>>                310      context-switches          #    0.004 M/sec                    ( +-  0.31% )
>>                  1      cpu-migrations            #    0.008 K/sec                    ( +-  5.07% )
>>              4,004      page-faults               #    0.045 M/sec                    ( +-  0.01% )
>> ...
>>           0.084138 +- 0.000111 seconds time elapsed  ( +-  0.13% )
>> 
>> 
>> The easiest test of stdout with AsyncLogging is to use tty and XOFF Ctrl^s. Java applications with UL to stdout were blocked by Ctrl-s. The entire java process will be frozen.  -Xlog:async now cover both stdout and stderr. It can circumvent this issue.  
>> 
>> Add a new jtreg to cover a scenario that unified logging with -Xlog:async will not be frozen even when stdout is blocked.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sideline BlockedLoggingTest.java

> Okay so why does LFO::write_blocking call fflush but LFSO::write_blocking does not? Shouldn't the two methods have the same general semantics?

This is a good question! `LFSO::write(LogMessageBuffer::Iterator msg_iterator)` only flushes after it writes a chain of messages.  `LSO::write(LogMessageBuffer::Iterator msg_iterator)` drops this semantic because of log rotation for files.

you are right.  I shouldn't provide "write_blocking" functions with 2 different semantics. That will confuse everybody including me. This can be done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6132

From duke at openjdk.java.net  Wed Dec 22 02:49:45 2021
From: duke at openjdk.java.net (Tyler)
Date: Wed, 22 Dec 2021 02:49:45 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712 (Flight
 Recorder)
Message-ID: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>

Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ??

### Implementation notes and alternatives considered

After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.

### Testing

Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).

### More notes

I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.

-------------

Commit messages:
 - 8203290: Implements Java Flight Recorder on AIX

Changes: https://git.openjdk.java.net/jdk/pull/6885/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6885&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8203290
  Stats: 1090 lines in 7 files changed: 425 ins; 500 del; 165 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6885.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6885/head:pull/6885

PR: https://git.openjdk.java.net/jdk/pull/6885

From egahlin at openjdk.java.net  Wed Dec 22 03:03:16 2021
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 22 Dec 2021 03:03:16 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder)
In-Reply-To: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
Message-ID: <o5DhRkluWTfQ0_RVyQBv2CE2HdG8rHDrXrPmxKgHjao=.1cb763ff-3e99-4fb4-b669-8563f8ec96a3@github.com>

On Fri, 17 Dec 2021 19:07:54 GMT, Tyler <duke at openjdk.java.net> wrote:

> Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ??
> 
> ### Implementation notes and alternatives considered
> 
> After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.
> 
> ### Testing
> 
> Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).
> 
> ### More notes
> 
> I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.

I don't have access to AIX, but there are 500+ tests in test/jdk/jdk/jfr you might want to try out.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6885

From minqi at openjdk.java.net  Wed Dec 22 03:16:55 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 22 Dec 2021 03:16:55 GMT
Subject: RFR: 8279018: CRC calculation in CDS should not include _version
 and _head_size [v3]
In-Reply-To: <Z1Fof383_r1H31EUrl1q2RWSBd1JDQYSZBOxRCv4hRs=.80548e3e-9a38-431f-89e6-621b0d5eb13c@github.com>
References: <Z1Fof383_r1H31EUrl1q2RWSBd1JDQYSZBOxRCv4hRs=.80548e3e-9a38-431f-89e6-621b0d5eb13c@github.com>
Message-ID: <c2qxlk0ECbJxG8pjYZkuyTT6s5W0CRNpdtCK1kf4rOY=.7eac927b-7832-41a3-bd97-9968f2f72fa5@github.com>

> Please review the simple change for not including _version and _header_size in crc computation. These two fields are checked separately and they should not affect crc.
> 
> tests: tier1,tier4
> 
> Thanks
> Yumin

Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:

  Explicitly include cds.h and add INCLUDE_CDS for CDS only code

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6899/files
  - new: https://git.openjdk.java.net/jdk/pull/6899/files/56e42768..1276cace

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6899&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6899&range=01-02

  Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6899.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6899/head:pull/6899

PR: https://git.openjdk.java.net/jdk/pull/6899

From ccheung at openjdk.java.net  Wed Dec 22 03:35:15 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Wed, 22 Dec 2021 03:35:15 GMT
Subject: RFR: 8279018: CRC calculation in CDS should not include _version
 and _head_size [v3]
In-Reply-To: <c2qxlk0ECbJxG8pjYZkuyTT6s5W0CRNpdtCK1kf4rOY=.7eac927b-7832-41a3-bd97-9968f2f72fa5@github.com>
References: <Z1Fof383_r1H31EUrl1q2RWSBd1JDQYSZBOxRCv4hRs=.80548e3e-9a38-431f-89e6-621b0d5eb13c@github.com>
 <c2qxlk0ECbJxG8pjYZkuyTT6s5W0CRNpdtCK1kf4rOY=.7eac927b-7832-41a3-bd97-9968f2f72fa5@github.com>
Message-ID: <9Gt8yv_pxO5ax8GpV_R6gmOiQwc0mbVo6jIeuDgZN-4=.19a6d1f1-3101-44f7-8858-5e86a0086d26@github.com>

On Wed, 22 Dec 2021 03:16:55 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Please review the simple change for not including _version and _header_size in crc computation. These two fields are checked separately and they should not affect crc.
>> 
>> tests: tier1,tier4
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Explicitly include cds.h and add INCLUDE_CDS for CDS only code

Update seems fine.

-------------

Marked as reviewed by ccheung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6899

From dholmes at openjdk.java.net  Wed Dec 22 04:20:19 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 22 Dec 2021 04:20:19 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder)
In-Reply-To: <o5DhRkluWTfQ0_RVyQBv2CE2HdG8rHDrXrPmxKgHjao=.1cb763ff-3e99-4fb4-b669-8563f8ec96a3@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <o5DhRkluWTfQ0_RVyQBv2CE2HdG8rHDrXrPmxKgHjao=.1cb763ff-3e99-4fb4-b669-8563f8ec96a3@github.com>
Message-ID: <fb3uQAhT9A0eUXpBqOWPfzfOGmAJDs1nQRUz4wkfc_M=.95066e8a-e6a9-4ecf-ae36-c9e6fc7615a2@github.com>

On Wed, 22 Dec 2021 02:59:43 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ??
>> 
>> ### Implementation notes and alternatives considered
>> 
>> After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.
>> 
>> ### Testing
>> 
>> Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).
>> 
>> ### More notes
>> 
>> I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.
>
> I don't have access to AIX, but there are 500+ tests in test/jdk/jdk/jfr you might want to try out.

@egahlin  beat me to it - yes the JFR testing is primarily under jdk not hotspot, so we don't really need the new sanity tests.

Also are you aware that we have `src/hotspot/os/aix/libperfstat_aix.*` ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6885

From yyang at openjdk.java.net  Wed Dec 22 08:12:58 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 22 Dec 2021 08:12:58 GMT
Subject: RFR: 8278125: Some preallocated OOMEs are missing stack trace [v4]
In-Reply-To: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
References: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
Message-ID: <s7wCpFOmdv0zEN6IKUY97BSbLdnh-UoKd6yePeFkslM=.19519fb6-83bd-4dcd-a45e-b442a15c20f9@github.com>

> Our customer found that the PreallocatedOutOfMemoryErrorCount is 4 by default. It ought to pre-allocate 4 OOMEs with stack trace, but in fact, no matter how many OOMEs are thrown, only 2 OOMEs have proper stack trace. This is because PreallocatedOutOfMemoryErrorCount is consumed multiple times:
> 
> VM tries to allocate a huge object while Java heap is insufficient to accommodate, it goes to:
> 
> https://github.com/openjdk/jdk/blob/b79554bb5cef14590d427543a40efbcc60c66548/src/hotspot/share/gc/shared/memAllocator.cpp#L115-L136
> 
> Line 135(`Universe::out_of_memory_error_java_heap`->`Universe::gen_out_of_memory_error`) and line 136(`THROW_OOP_`->`Exceptions::_throw`->`Exceptions::count_out_of_memory_exceptions`->`Universe::out_of_memory_error_java_heap`->`Universe::gen_out_of_memory_error`) call `Universe::gen_out_of_memory_error` twice in a single OOM event, which leads this unexpected scenario. Proposed fix is to remove such call in `Exceptions::count_out_of_memory_exceptions`.
> 
> Thanks.

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  preallocate oome message objects

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6672/files
  - new: https://git.openjdk.java.net/jdk/pull/6672/files/9e4ff230..b3f0e0e3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6672&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6672&range=02-03

  Stats: 56 lines in 3 files changed: 23 ins; 24 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6672.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6672/head:pull/6672

PR: https://git.openjdk.java.net/jdk/pull/6672

From yyang at openjdk.java.net  Wed Dec 22 08:20:51 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 22 Dec 2021 08:20:51 GMT
Subject: RFR: 8278125: Some preallocated OOMEs are missing stack trace [v5]
In-Reply-To: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
References: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
Message-ID: <J844bFLwRCUg-3lNXzTstJqTo5yN05dBTiBGyBjp7Vk=.1392a674-3297-44d5-8e2a-4fc968539d87@github.com>

> Our customer found that the PreallocatedOutOfMemoryErrorCount is 4 by default. It ought to pre-allocate 4 OOMEs with stack trace, but in fact, no matter how many OOMEs are thrown, only 2 OOMEs have proper stack trace. This is because PreallocatedOutOfMemoryErrorCount is consumed multiple times:
> 
> VM tries to allocate a huge object while Java heap is insufficient to accommodate, it goes to:
> 
> https://github.com/openjdk/jdk/blob/b79554bb5cef14590d427543a40efbcc60c66548/src/hotspot/share/gc/shared/memAllocator.cpp#L115-L136
> 
> Line 135(`Universe::out_of_memory_error_java_heap`->`Universe::gen_out_of_memory_error`) and line 136(`THROW_OOP_`->`Exceptions::_throw`->`Exceptions::count_out_of_memory_exceptions`->`Universe::out_of_memory_error_java_heap`->`Universe::gen_out_of_memory_error`) call `Universe::gen_out_of_memory_error` twice in a single OOM event, which leads this unexpected scenario. Proposed fix is to remove such call in `Exceptions::count_out_of_memory_exceptions`.
> 
> Thanks.

Yi Yang has updated the pull request incrementally with two additional commits since the last revision:

 - typo
 - cleanup

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6672/files
  - new: https://git.openjdk.java.net/jdk/pull/6672/files/b3f0e0e3..a05703b9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6672&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6672&range=03-04

  Stats: 15 lines in 3 files changed: 4 ins; 8 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6672.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6672/head:pull/6672

PR: https://git.openjdk.java.net/jdk/pull/6672

From yyang at openjdk.java.net  Wed Dec 22 08:20:52 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 22 Dec 2021 08:20:52 GMT
Subject: RFR: 8278125: Some preallocated OOMEs are missing stack trace [v3]
In-Reply-To: <XIPkCtkB8bGV7peqsrhOsmS_8_fG7podUU_1Bx88vLM=.1a2fe5cd-cc41-453e-ac0d-0d33144bcc0e@github.com>
References: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
 <yoaT87337KQzVF-xRpopBnEIMf6YQNV9Ec1Gs4n2ewI=.55c29c27-27fd-4d77-b6d8-fd466be6ca9e@github.com>
 <A2gIo3dxLcZIvg5Q13H0nSmMQ3O4FpuxuSc000AYgxw=.7e602907-2942-47b0-9311-57155d630c6e@github.com>
 <bKDxvVnTSiep-DUaxM8j452mC2xp4GNCzwXFIustLDY=.17ec4a9b-8598-46e4-b59f-35439a92f048@github.com>
 <LGrdOxElkNdwe078_cI7BrB1xDJe7T9NmRtOYAqFQQ8=.fb09be89-b4e6-4b31-a6bd-edcc77b17fcf@github.com>
 <U6lgqfW8v-e-XhR-HwP30p30Ay605QhKouUA2sxhLF4=.459514e1-6a55-4472-966e-3629eecbd6fa@github.com>
 <Lgw6KK7r51Xnkv5BYBjorL6nvmEHufoxoSxj3OI2BHw=.4e3317d4-e651-49c8-8739-85292881a4d8@github.com>
 <o63-YtxgLMQN62_ZnuOLBiFkuppVXSsOl3PK89Yzj8o=.1de7fe61-9029-4c9c-8fee-dc269a3b267f@github.com>
 <jZS99U1IQmir95UzX8vq6LCbcUEZqrZvN5H5n7tab6s=.f3e276e7-44fa-42af-82fe-2c0b75c65b92@github.com>
 <XIPkCtkB8bGV7peqsrhOsmS_8_fG7podUU_1Bx88vLM=.1a2fe5cd-cc41-453e-ac0d-0d33144bcc0e@github.com>
Message-ID: <ovz9SD7RSOfyy0FUF3hIzbUyDacdhTGvJyV0zGDtqo4=.10483481-05fd-4a40-91b3-5349f51e62fc@github.com>

On Tue, 21 Dec 2021 00:15:41 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Yes, I agree. I figured it out once and had to start from scratch to try to figure it out again.
>
> Like this: https://github.com/openjdk/jdk/pull/6901

@coleenp @dholmes-ora  Thanks for commenting on this. I make some changes according to review feedback.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6672

From xliu at openjdk.java.net  Wed Dec 22 09:05:55 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 22 Dec 2021 09:05:55 GMT
Subject: RFR: 8267517: async logging for stdout and stderr [v5]
In-Reply-To: <Nv1V5JHKgJh0NtqijGmWmI9Kh2VgDxgDIOAdfCtOavA=.503f41c2-a5d1-4a25-ab90-00252814a9bf@github.com>
References: <Nv1V5JHKgJh0NtqijGmWmI9Kh2VgDxgDIOAdfCtOavA=.503f41c2-a5d1-4a25-ab90-00252814a9bf@github.com>
Message-ID: <-JCBht0sipE70KzadQ-t4BCohscGC76Sz9GwTC0V6sw=.0d76d735-ac3d-4260-8747-763c72793bf9@github.com>

> This patch refactors LogFileStreamOutput so stdout/stderr can support support -Xlog:async.
> 
> With  `-Xlog:all=trace:stdout`, the helloworld in Java outputs 16520 log entries to stdout.  We are see that the wall time reduces from  84.138ms to 72.914ms, or the throughput increases 15% because of async logging.
> 
> 
> $perf stat -r 300 ./build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -Xlog:async -XX:AsyncLogBufferSize=48M HelloWorld > /dev/null
> 
>  Performance counter stats for './build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -Xlog:async -XX:AsyncLogBufferSize=48M HelloWorld' (300 runs):
> 
>             107.21 msec task-clock                #    1.470 CPUs utilized            ( +-  0.17% )
>              2,681      context-switches          #    0.025 M/sec                    ( +-  0.32% )
>                  1      cpu-migrations            #    0.011 K/sec                    ( +-  4.56% )
>              4,006      page-faults               #    0.037 M/sec                    ( +-  0.01% )
> ...
>           0.072914 +- 0.000126 seconds time elapsed  ( +-  0.17% )
> 
>  Performance counter stats for './build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -XX:AsyncLogBufferSize=48M HelloWorld' (300 runs):
> 
>              88.04 msec task-clock                #    1.046 CPUs utilized            ( +-  0.10% )
>                310      context-switches          #    0.004 M/sec                    ( +-  0.31% )
>                  1      cpu-migrations            #    0.008 K/sec                    ( +-  5.07% )
>              4,004      page-faults               #    0.045 M/sec                    ( +-  0.01% )
> ...
>           0.084138 +- 0.000111 seconds time elapsed  ( +-  0.13% )
> 
> 
> The easiest test of stdout with AsyncLogging is to use tty and XOFF Ctrl^s. Java applications with UL to stdout were blocked by Ctrl-s. The entire java process will be frozen.  -Xlog:async now cover both stdout and stderr. It can circumvent this issue.  
> 
> Add a new jtreg to cover a scenario that unified logging with -Xlog:async will not be frozen even when stdout is blocked.

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  Remove BlockedLoggingTest.java and add test for stdout/err in test_asynclog.cpp.
  
  This patch also adds to flushing semantic to LogFileStreamOutput::write_blocking().
  It aligns with LogFileOutput::write_blocking().

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6132/files
  - new: https://git.openjdk.java.net/jdk/pull/6132/files/769110a2..eed6f8ad

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6132&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6132&range=03-04

  Stats: 242 lines in 5 files changed: 62 ins; 169 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6132.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6132/head:pull/6132

PR: https://git.openjdk.java.net/jdk/pull/6132

From coleenp at openjdk.java.net  Wed Dec 22 13:37:11 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 22 Dec 2021 13:37:11 GMT
Subject: RFR: 8278125: Some preallocated OOMEs are missing stack trace [v5]
In-Reply-To: <J844bFLwRCUg-3lNXzTstJqTo5yN05dBTiBGyBjp7Vk=.1392a674-3297-44d5-8e2a-4fc968539d87@github.com>
References: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
 <J844bFLwRCUg-3lNXzTstJqTo5yN05dBTiBGyBjp7Vk=.1392a674-3297-44d5-8e2a-4fc968539d87@github.com>
Message-ID: <_cA1fMC8tApMNSjdAwBYCu43Yok-mKa1TX5bKZ1NK0M=.19a57d74-8f5b-4367-8ffb-4881369f0909@github.com>

On Wed, 22 Dec 2021 08:20:51 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> Our customer found that the PreallocatedOutOfMemoryErrorCount is 4 by default. It ought to pre-allocate 4 OOMEs with stack trace, but in fact, no matter how many OOMEs are thrown, only 2 OOMEs have proper stack trace. This is because PreallocatedOutOfMemoryErrorCount is consumed multiple times:
>> 
>> VM tries to allocate a huge object while Java heap is insufficient to accommodate, it goes to:
>> 
>> https://github.com/openjdk/jdk/blob/b79554bb5cef14590d427543a40efbcc60c66548/src/hotspot/share/gc/shared/memAllocator.cpp#L115-L136
>> 
>> Line 135(`Universe::out_of_memory_error_java_heap`->`Universe::gen_out_of_memory_error`) and line 136(`THROW_OOP_`->`Exceptions::_throw`->`Exceptions::count_out_of_memory_exceptions`->`Universe::out_of_memory_error_java_heap`->`Universe::gen_out_of_memory_error`) call `Universe::gen_out_of_memory_error` twice in a single OOM event, which leads this unexpected scenario. Proposed fix is to remove such call in `Exceptions::count_out_of_memory_exceptions`.
>> 
>> Thanks.
>
> Yi Yang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - typo
>  - cleanup

I like this.  No more strcmp where I have to worry whether you should have had strncmp, or not.  Thanks!

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6672

From minqi at openjdk.java.net  Wed Dec 22 16:18:19 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 22 Dec 2021 16:18:19 GMT
Subject: RFR: 8279018: CRC calculation in CDS should not include _version
 and _head_size [v3]
In-Reply-To: <9Gt8yv_pxO5ax8GpV_R6gmOiQwc0mbVo6jIeuDgZN-4=.19a6d1f1-3101-44f7-8858-5e86a0086d26@github.com>
References: <Z1Fof383_r1H31EUrl1q2RWSBd1JDQYSZBOxRCv4hRs=.80548e3e-9a38-431f-89e6-621b0d5eb13c@github.com>
 <c2qxlk0ECbJxG8pjYZkuyTT6s5W0CRNpdtCK1kf4rOY=.7eac927b-7832-41a3-bd97-9968f2f72fa5@github.com>
 <9Gt8yv_pxO5ax8GpV_R6gmOiQwc0mbVo6jIeuDgZN-4=.19a6d1f1-3101-44f7-8858-5e86a0086d26@github.com>
Message-ID: <uQZgk9nYeu9mYeddnIEHyI5377AoRhzSSFBzbAYAtzk=.7cf1f552-4836-440f-b98f-5ab728ae83b6@github.com>

On Wed, 22 Dec 2021 03:32:01 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Explicitly include cds.h and add INCLUDE_CDS for CDS only code
>
> Update seems fine.

@calvinccheung @iklam Thanks for review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/6899

From minqi at openjdk.java.net  Wed Dec 22 16:18:19 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 22 Dec 2021 16:18:19 GMT
Subject: Integrated: 8279018: CRC calculation in CDS should not include
 _version and _head_size
In-Reply-To: <Z1Fof383_r1H31EUrl1q2RWSBd1JDQYSZBOxRCv4hRs=.80548e3e-9a38-431f-89e6-621b0d5eb13c@github.com>
References: <Z1Fof383_r1H31EUrl1q2RWSBd1JDQYSZBOxRCv4hRs=.80548e3e-9a38-431f-89e6-621b0d5eb13c@github.com>
Message-ID: <6KLePJQkgo8kGSku0ni7xDGd-uX9ByBfaWzmtAG5_W0=.643c0af1-ee04-46b2-991e-9e6c930d13f8@github.com>

On Mon, 20 Dec 2021 20:30:15 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Please review the simple change for not including _version and _header_size in crc computation. These two fields are checked separately and they should not affect crc.
> 
> tests: tier1,tier4
> 
> Thanks
> Yumin

This pull request has now been integrated.

Changeset: a6903f80
Author:    Yumin Qi <minqi at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a6903f806a9071b2c6c4dbb190b0041867e5bb80
Stats:     56 lines in 7 files changed: 43 ins; 0 del; 13 mod

8279018: CRC calculation in CDS should not include _version and _head_size

Reviewed-by: iklam, ccheung

-------------

PR: https://git.openjdk.java.net/jdk/pull/6899

From minqi at openjdk.java.net  Wed Dec 22 16:21:17 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 22 Dec 2021 16:21:17 GMT
Subject: RFR: 8279022: JCmdTestFileSafety.java should check file time stamp
 for test result [v2]
In-Reply-To: <hjGqXCtXws5DunmlmhznO9keUE5f13Y0zqhxOmtUm2I=.124844f5-0c9a-4a87-8737-c45c08892a6f@github.com>
References: <Qh-8hNJgPf8_JS6dvx_5-hNCkmGN2qKUYGC7dk9L4Pc=.ead68363-0097-4e96-96ac-ad58ddb60fbd@github.com>
 <j1cVNG-fJ2TACsof7Se4a253JrPPJjoOg1MbSEOlJfQ=.61eae03d-757b-4b79-884d-501184f1c004@github.com>
 <hjGqXCtXws5DunmlmhznO9keUE5f13Y0zqhxOmtUm2I=.124844f5-0c9a-4a87-8737-c45c08892a6f@github.com>
Message-ID: <B6X3ABsOvi86TybIPayIHmtmyUgBF4WgPivf5JStN1A=.a80918ab-fd1b-465b-8170-f8dd0d60c517@github.com>

On Tue, 21 Dec 2021 17:58:57 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor remove file code
>
> Update looks good.

@calvinccheung thanks for review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/6904

From minqi at openjdk.java.net  Wed Dec 22 16:21:17 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 22 Dec 2021 16:21:17 GMT
Subject: Integrated: 8279022: JCmdTestFileSafety.java should check file time
 stamp for test result
In-Reply-To: <Qh-8hNJgPf8_JS6dvx_5-hNCkmGN2qKUYGC7dk9L4Pc=.ead68363-0097-4e96-96ac-ad58ddb60fbd@github.com>
References: <Qh-8hNJgPf8_JS6dvx_5-hNCkmGN2qKUYGC7dk9L4Pc=.ead68363-0097-4e96-96ac-ad58ddb60fbd@github.com>
Message-ID: <MXdmRiG4Yalrug1kHCf6_cjL7vesjYPMgXzFdR8Sn7k=.6eb08da6-4cc1-4af8-84bb-70485127b18f@github.com>

On Tue, 21 Dec 2021 02:45:35 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> When test finished, the created archive file should be checked after  the first run for existence, and checked for time stamp after second run.  Since the file name is same, this method is more accurate than the existing checking, only checking the existence of the file. Since jcmd can do repeat dynamic dump to same java process now, removed unnecessary restart process code.
> 
> Tests: tier1, jtreg on local linux-x64.
> 
> Thanks
> Yumin

This pull request has now been integrated.

Changeset: 9a478b34
Author:    Yumin Qi <minqi at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9a478b347e1ef7aecfc8bbc2e3c5e6ac7c23ba36
Stats:     32 lines in 1 file changed: 22 ins; 5 del; 5 mod

8279022: JCmdTestFileSafety.java should check file time stamp for test result

Reviewed-by: ccheung

-------------

PR: https://git.openjdk.java.net/jdk/pull/6904

From duke at openjdk.java.net  Wed Dec 22 17:10:15 2021
From: duke at openjdk.java.net (Tyler)
Date: Wed, 22 Dec 2021 17:10:15 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder)
In-Reply-To: <o5DhRkluWTfQ0_RVyQBv2CE2HdG8rHDrXrPmxKgHjao=.1cb763ff-3e99-4fb4-b669-8563f8ec96a3@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <o5DhRkluWTfQ0_RVyQBv2CE2HdG8rHDrXrPmxKgHjao=.1cb763ff-3e99-4fb4-b669-8563f8ec96a3@github.com>
Message-ID: <x-O_NAiGxSl5YQByRytVg01TXp-FNd2u2dMbC0sbAt4=.b590e2e0-b355-49e1-87bf-1539eda9566a@github.com>

On Wed, 22 Dec 2021 02:59:43 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ??
>> 
>> ### Implementation notes and alternatives considered
>> 
>> After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.
>> 
>> ### Testing
>> 
>> Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).
>> 
>> ### More notes
>> 
>> I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.
>
> I don't have access to AIX, but there are 500+ tests in test/jdk/jdk/jfr you might want to try out.

Thanks @egahlin and @dholmes-ora. Responses to your comments below:


> I don't have access to AIX, but there are 500+ tests in test/jdk/jdk/jfr you might want to try out.


I definitely missed these! I ran them on my AIX testing machine and found a few failures. I'll look into them. 



> Also are you aware that we have `src/hotspot/os/aix/libperfstat_aix.*` ?


Thanks for pointing me to this, I was not aware of it. I will spend some time to assess whether I can make use of it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6885

From gziemski at openjdk.java.net  Wed Dec 22 17:49:24 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Wed, 22 Dec 2021 17:49:24 GMT
Subject: [jdk18] RFR: 8272058: 25 Null pointer dereference defect groups in
 4 files
In-Reply-To: <TwIvJ3FE4o5AqZ38OQaZhzhB5Ctdph9LYLcQOEZswPk=.14774a97-d3e1-44e1-8a91-568c9d632334@github.com>
References: <TwIvJ3FE4o5AqZ38OQaZhzhB5Ctdph9LYLcQOEZswPk=.14774a97-d3e1-44e1-8a91-568c9d632334@github.com>
Message-ID: <0U_sVzhLsz9_Bz3kkE5MW9xw4Bq_NLlXztl1X5DW2BU=.9bb6f8ae-bda9-41be-80a0-6451558d40bf@github.com>

On Mon, 20 Dec 2021 20:50:14 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A small refactoring to resolve a Parfait complaint about the return value from
> `MacroAssembler::target_addr_for_insn(address insn_addr, unsigned insn)`
> on AARCH64. The logic that supports returning `nullptr` as the target addr for
> a particular instruction is moved from
> `MacroAssembler::target_addr_for_insn(address insn_addr, unsigned insn)` to
> `MacroAssembler::target_addr_for_insn_allow_null_ret(address insn_addr, unsigned insn)`.
> A couple of `target_addr_for_insn()` call sites that can tolerate a `nullptr` are
> converted to use `target_addr_for_insn_allow_null_ret()`.
> 
> This fix has been tested with Mach5 Tier[1-3].

I don't understand the underlying code, but from a big picture point of view, splitting the call into "null not allowed" and "null allowed" makes sense. If the testing came back fine, then that's the best we can do, without asking someone who wrote this code to chime in.

Just one question: why do we need the "null allowed" version here?

void NativeMovRegMem::verify() {
 #ifdef ASSERT
   address dest = MacroAssembler::target_addr_for_insn_allow_null_ret(instruction_address());
 #endif
 }

-------------

Marked as reviewed by gziemski (Committer).

PR: https://git.openjdk.java.net/jdk18/pull/51

From dcubed at openjdk.java.net  Wed Dec 22 18:06:26 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 22 Dec 2021 18:06:26 GMT
Subject: [jdk18] RFR: 8272058: 25 Null pointer dereference defect groups in
 4 files
In-Reply-To: <0U_sVzhLsz9_Bz3kkE5MW9xw4Bq_NLlXztl1X5DW2BU=.9bb6f8ae-bda9-41be-80a0-6451558d40bf@github.com>
References: <TwIvJ3FE4o5AqZ38OQaZhzhB5Ctdph9LYLcQOEZswPk=.14774a97-d3e1-44e1-8a91-568c9d632334@github.com>
 <0U_sVzhLsz9_Bz3kkE5MW9xw4Bq_NLlXztl1X5DW2BU=.9bb6f8ae-bda9-41be-80a0-6451558d40bf@github.com>
Message-ID: <w8upKM3XBcGOO9O4_4REx85MdmOrLtRGvh4wTXYANus=.33646fe5-82c6-4546-b85e-f474b214c6e0@github.com>

On Wed, 22 Dec 2021 17:45:48 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> A small refactoring to resolve a Parfait complaint about the return value from
>> `MacroAssembler::target_addr_for_insn(address insn_addr, unsigned insn)`
>> on AARCH64. The logic that supports returning `nullptr` as the target addr for
>> a particular instruction is moved from
>> `MacroAssembler::target_addr_for_insn(address insn_addr, unsigned insn)` to
>> `MacroAssembler::target_addr_for_insn_allow_null_ret(address insn_addr, unsigned insn)`.
>> A couple of `target_addr_for_insn()` call sites that can tolerate a `nullptr` are
>> converted to use `target_addr_for_insn_allow_null_ret()`.
>> 
>> This fix has been tested with Mach5 Tier[1-3].
>
> I don't understand the underlying code, but from a big picture point of view, splitting the call into "null not allowed" and "null allowed" makes sense. If the testing came back fine, then that's the best we can do, without asking someone who wrote this code to chime in.
> 
> Just one question: why do we need the "null allowed" version here?
> 
> void NativeMovRegMem::verify() {
>  #ifdef ASSERT
>    address dest = MacroAssembler::target_addr_for_insn_allow_null_ret(instruction_address());
>  #endif
>  }

@gerard-ziemski - Thanks for the review.

According to "git blame", the original author is:

9c458decf5f1 hotspot/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp (Andrew Haley           2015-01-20 11:34:17 -0800  211) address MacroAssembler::target_addr_for_insn(address insn_addr, unsigned insn) {

which I believe is why @dholmes-ora pinged @theRealAPH on this PR...

As for this function:


void NativeMovRegMem::verify() {
#ifdef ASSERT
  address dest = MacroAssembler::target_addr_for_insn_allow_null_ret(instruction_address());
#endif
}


I did not see any harm in converting to `target_addr_for_insn_allow_null_ret`.
The baseline code worked just fine before I refactored it so I'm giving
the function equivalence. In other words, if `NativeMovRegMem::verify()`
was previous called with an `instruction_address()` value that leads to
a nullptr, then baseline `verify()` would work without error. I wanted the
new `verify()` to also work the same.

-------------

PR: https://git.openjdk.java.net/jdk18/pull/51

From gziemski at openjdk.java.net  Wed Dec 22 18:46:16 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Wed, 22 Dec 2021 18:46:16 GMT
Subject: [jdk18] RFR: 8272058: 25 Null pointer dereference defect groups in
 4 files
In-Reply-To: <0U_sVzhLsz9_Bz3kkE5MW9xw4Bq_NLlXztl1X5DW2BU=.9bb6f8ae-bda9-41be-80a0-6451558d40bf@github.com>
References: <TwIvJ3FE4o5AqZ38OQaZhzhB5Ctdph9LYLcQOEZswPk=.14774a97-d3e1-44e1-8a91-568c9d632334@github.com>
 <0U_sVzhLsz9_Bz3kkE5MW9xw4Bq_NLlXztl1X5DW2BU=.9bb6f8ae-bda9-41be-80a0-6451558d40bf@github.com>
Message-ID: <QHOsYJ1R6V_wwZWmr58wqH4LtcChtcx_hLTOQ1LW5p4=.8b1c7d63-4d42-4797-aa03-092db37ed767@github.com>

On Wed, 22 Dec 2021 17:45:48 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> A small refactoring to resolve a Parfait complaint about the return value from
>> `MacroAssembler::target_addr_for_insn(address insn_addr, unsigned insn)`
>> on AARCH64. The logic that supports returning `nullptr` as the target addr for
>> a particular instruction is moved from
>> `MacroAssembler::target_addr_for_insn(address insn_addr, unsigned insn)` to
>> `MacroAssembler::target_addr_for_insn_allow_null_ret(address insn_addr, unsigned insn)`.
>> A couple of `target_addr_for_insn()` call sites that can tolerate a `nullptr` are
>> converted to use `target_addr_for_insn_allow_null_ret()`.
>> 
>> This fix has been tested with Mach5 Tier[1-3].
>
> I don't understand the underlying code, but from a big picture point of view, splitting the call into "null not allowed" and "null allowed" makes sense. If the testing came back fine, then that's the best we can do, without asking someone who wrote this code to chime in.
> 
> Just one question: why do we need the "null allowed" version here?
> 
> void NativeMovRegMem::verify() {
>  #ifdef ASSERT
>    address dest = MacroAssembler::target_addr_for_insn_allow_null_ret(instruction_address());
>  #endif
>  }

> @gerard-ziemski - Thanks for the review.
> 
> According to "git blame", the original author is:
> 
> [9c458de](https://github.com/openjdk/jdk18/commit/9c458decf5f1ed468639de57f9f34adab98a593d) hotspot/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp (Andrew Haley 2015-01-20 11:34:17 -0800 211) address MacroAssembler::target_addr_for_insn(address insn_addr, unsigned insn) {
> 
> which I believe is why @dholmes-ora pinged @theRealAph on this PR...
> 
> As for this function:
> 
> ```
> void NativeMovRegMem::verify() {
> #ifdef ASSERT
>   address dest = MacroAssembler::target_addr_for_insn_allow_null_ret(instruction_address());
> #endif
> }
> ```
> 
> I did not see any harm in converting to `target_addr_for_insn_allow_null_ret`. The baseline code worked just fine before I refactored it so I'm giving the function equivalence. In other words, if `NativeMovRegMem::verify()` was previous called with an `instruction_address()` value that leads to a nullptr, then baseline `verify()` would work without error. I wanted the new `verify()` to also work the same.

As long as parfait doesn't complain here - I didn't see where we checked for NULL explicitly in this case.  I assume that parfait skips the ASSERT parts?

-------------

PR: https://git.openjdk.java.net/jdk18/pull/51

From dcubed at openjdk.java.net  Wed Dec 22 18:53:22 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 22 Dec 2021 18:53:22 GMT
Subject: [jdk18] RFR: 8272058: 25 Null pointer dereference defect groups in
 4 files
In-Reply-To: <QHOsYJ1R6V_wwZWmr58wqH4LtcChtcx_hLTOQ1LW5p4=.8b1c7d63-4d42-4797-aa03-092db37ed767@github.com>
References: <TwIvJ3FE4o5AqZ38OQaZhzhB5Ctdph9LYLcQOEZswPk=.14774a97-d3e1-44e1-8a91-568c9d632334@github.com>
 <0U_sVzhLsz9_Bz3kkE5MW9xw4Bq_NLlXztl1X5DW2BU=.9bb6f8ae-bda9-41be-80a0-6451558d40bf@github.com>
 <QHOsYJ1R6V_wwZWmr58wqH4LtcChtcx_hLTOQ1LW5p4=.8b1c7d63-4d42-4797-aa03-092db37ed767@github.com>
Message-ID: <2qKPQVKQyRORoNLu4SU-REm_7Kx4sikMPvCt233xays=.dfce0322-6cf4-44c0-9dfe-40329f723fe3@github.com>

On Wed, 22 Dec 2021 18:43:36 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> As long as parfait doesn't complain here - I didn't see where we checked for NULL
> explicitly in this case. I assume that parfait skips the ASSERT parts?

Parfait does not complain anymore. The key about this call is that we don't de-reference
the return value from `target_addr_for_insn_allow_null_ret`. So we allow nullptr to be
returned, but we don't use it.

-------------

PR: https://git.openjdk.java.net/jdk18/pull/51

From xliu at openjdk.java.net  Wed Dec 22 20:03:21 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 22 Dec 2021 20:03:21 GMT
Subject: RFR: 8267517: async logging for stdout and stderr [v3]
In-Reply-To: <mH1OjVRTKcIYq6v5C3kXo55IY9kle2ENu--FP1tvnFg=.f0b9f96a-ecee-411a-ae38-3c509c019510@github.com>
References: <Nv1V5JHKgJh0NtqijGmWmI9Kh2VgDxgDIOAdfCtOavA=.503f41c2-a5d1-4a25-ab90-00252814a9bf@github.com>
 <ddwRuorCLqbH2zmw-PktIT9bm13hJ2jvNWJMX_1XQpo=.4f426bfb-b843-44c7-b935-fd748dd25db7@github.com>
 <mH1OjVRTKcIYq6v5C3kXo55IY9kle2ENu--FP1tvnFg=.f0b9f96a-ecee-411a-ae38-3c509c019510@github.com>
Message-ID: <3VUTplGGnDTrFc8wTdrpvMdrhWpCgzE5ZKvTZBl3-OM=.553f3e2b-0276-47fe-b0b4-9418d6c0b827@github.com>

On Tue, 21 Dec 2021 05:56:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo and the building eror on MacOS.
>
> Sorry Xin, the test is timing out on Linux-x64. There's no information to diagnose any problems though.
> 
> David

hi, @dholmes-ora , 

I come up an idea to prove that -Xlog:async at work. In gtest `test_asynclog.cpp`, I use `testing::internal::GetCapturedStdout/err()` to get the contents of stdout/err. Only AsyncLog will drop messages because of the buffer size.  freopen is simpler, however I found "freopen(TestLogFileName, stdout)` would mess with other testsuites because all TEST_VM_F run in a same process. 

In this revision,  write_blocking() has flushing semantic for both LFO and LFSO.  Could you take a look?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6132

From xliu at openjdk.java.net  Wed Dec 22 20:03:22 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 22 Dec 2021 20:03:22 GMT
Subject: RFR: 8267517: async logging for stdout and stderr [v4]
In-Reply-To: <UX1Jrh43107AowN2U2a4vdB67FU7iFhyNxmcYcrojvA=.95ad706a-927d-4cb6-8aa9-208796af82f9@github.com>
References: <Nv1V5JHKgJh0NtqijGmWmI9Kh2VgDxgDIOAdfCtOavA=.503f41c2-a5d1-4a25-ab90-00252814a9bf@github.com>
 <cxfd45Cht-cjdQo39E2z23a8ER69BGNupAnWfqAUx-s=.73d8f4e2-60dc-4bc8-b256-be1e97263f2c@github.com>
 <UX1Jrh43107AowN2U2a4vdB67FU7iFhyNxmcYcrojvA=.95ad706a-927d-4cb6-8aa9-208796af82f9@github.com>
Message-ID: <e0trbszDlzN-BC0oFlTY2dPnk5Da3mhCr-hNjiUUH6c=.9f62d065-0566-4054-aec9-fbee6b49d4fa@github.com>

On Tue, 21 Dec 2021 22:29:20 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Sideline BlockedLoggingTest.java
>
> src/hotspot/share/logging/logAsyncWriter.cpp line 153:
> 
>> 151:   if (req > 0) {
>> 152:     assert(req == 1, "AsyncLogWriter::flush() is NOT MT-safe!");
>> 153:     // LogFileOutput::write_block() has called fflush().
> 
> write_block or write_blocking?

delete this. 
now both LFO and LFSO do fflush() in write_blocking(), we don't need the special treatment here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6132

From minqi at openjdk.java.net  Thu Dec 23 00:35:41 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 23 Dec 2021 00:35:41 GMT
Subject: RFR: 8261455: Automatically generate the CDS archive if necessary
Message-ID: <0V7F_B4KQSngtk3LRpCO3cw0nGgUELyY3H6sGqva8J4=.6c61f0be-3bf0-43d1-8a33-899a1cb88161@github.com>

This patch is re-coded after serial fixes related: 8275846, 8276787, 8279018 etc.
original description(PR 5997):
`----------------------------------------------------------------------------------`
When shared archive (dynamic archive) failed to map due to damage of the archive file, dump/run jdk version mismatch or non-existence file etc, the new patch will automatically create a new shared archive if -XX:+AutoCreateSharedArchive specified with the name based on SharedArchiveFile.
This is a revised patch based on the old PR: 5077 and after bug 8273152 integrated.
`-----------------------------------------------------------------------------------`

Tests: tier1,tier2,tier3,tier4

Thanks
Yumin

-------------

Commit messages:
 - 8261455: Automatically generate the CDS archive if necessary

Changes: https://git.openjdk.java.net/jdk/pull/6920/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6920&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261455
  Stats: 727 lines in 11 files changed: 704 ins; 9 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6920.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6920/head:pull/6920

PR: https://git.openjdk.java.net/jdk/pull/6920

From xliu at openjdk.java.net  Thu Dec 23 01:22:36 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 23 Dec 2021 01:22:36 GMT
Subject: RFR: 8279189: Inaccurate comment about class VMThread
Message-ID: <OXbWm67Og9ooBs8AASjp2hcdT-nSD0IwNPN34rDYEWw=.571e4fd3-05e0-4712-bc00-bab8eded8dab@github.com>

The comment is inaccurate now. VMThread is different from the primordial thread. I guess the comment is based on the old codebase.
Because VMThread is singleton, I put the Constructor and Destructor in "private" section. clients use static member functions create/destroy.

-------------

Commit messages:
 - 8279189: Inaccurate comment about class VMThread

Changes: https://git.openjdk.java.net/jdk/pull/6922/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6922&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279189
  Stats: 4 lines in 1 file changed: 1 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6922.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6922/head:pull/6922

PR: https://git.openjdk.java.net/jdk/pull/6922

From dholmes at openjdk.java.net  Thu Dec 23 01:58:13 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 23 Dec 2021 01:58:13 GMT
Subject: RFR: 8278125: Some preallocated OOMEs are missing stack trace [v5]
In-Reply-To: <J844bFLwRCUg-3lNXzTstJqTo5yN05dBTiBGyBjp7Vk=.1392a674-3297-44d5-8e2a-4fc968539d87@github.com>
References: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
 <J844bFLwRCUg-3lNXzTstJqTo5yN05dBTiBGyBjp7Vk=.1392a674-3297-44d5-8e2a-4fc968539d87@github.com>
Message-ID: <D4ItmXvjf7yr42iQ6y598Uoyro1hlwmS3J39SPnE6JI=.6ea094a4-7e36-49c8-9673-64618cb5ac84@github.com>

On Wed, 22 Dec 2021 08:20:51 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> Our customer found that the PreallocatedOutOfMemoryErrorCount is 4 by default. It ought to pre-allocate 4 OOMEs with stack trace, but in fact, no matter how many OOMEs are thrown, only 2 OOMEs have proper stack trace. This is because PreallocatedOutOfMemoryErrorCount is consumed multiple times:
>> 
>> VM tries to allocate a huge object while Java heap is insufficient to accommodate, it goes to:
>> 
>> https://github.com/openjdk/jdk/blob/b79554bb5cef14590d427543a40efbcc60c66548/src/hotspot/share/gc/shared/memAllocator.cpp#L115-L136
>> 
>> Line 135(`Universe::out_of_memory_error_java_heap`->`Universe::gen_out_of_memory_error`) and line 136(`THROW_OOP_`->`Exceptions::_throw`->`Exceptions::count_out_of_memory_exceptions`->`Universe::out_of_memory_error_java_heap`->`Universe::gen_out_of_memory_error`) call `Universe::gen_out_of_memory_error` twice in a single OOM event, which leads this unexpected scenario. Proposed fix is to remove such call in `Exceptions::count_out_of_memory_exceptions`.
>> 
>> Thanks.
>
> Yi Yang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - typo
>  - cleanup

Functional fix looks good. A couple of minor nits in the test.

Thanks,
David

test/hotspot/jtreg/runtime/ErrorHandling/GenOutOfMemoryError.java line 41:

> 39:         try {
> 40:             System.out.format("bad method was invoked %n", n);
> 41:             Integer[] array = new Integer[1000 * 1000 * 100];

Please add a comment:

// Try to allocate an array the same size as the heap - it will throw OOME without
// actually consuming available memory.

test/hotspot/jtreg/runtime/ErrorHandling/GenOutOfMemoryError.java line 58:

> 56:             genOutOfMemoryError.badMethod(i + 1);
> 57:         }
> 58:         Asserts.assertTrue(4/*PreallocatedOutOfMemoryErrorCount is default to 4*/ == OOME_HAS_STACK_CNT, "Some OOMEs do not have stacktraces");

s/is default to/defaults to/

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6672

From dholmes at openjdk.java.net  Thu Dec 23 02:07:14 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 23 Dec 2021 02:07:14 GMT
Subject: RFR: 8279189: Inaccurate comment about class VMThread
In-Reply-To: <OXbWm67Og9ooBs8AASjp2hcdT-nSD0IwNPN34rDYEWw=.571e4fd3-05e0-4712-bc00-bab8eded8dab@github.com>
References: <OXbWm67Og9ooBs8AASjp2hcdT-nSD0IwNPN34rDYEWw=.571e4fd3-05e0-4712-bc00-bab8eded8dab@github.com>
Message-ID: <28nO8ympcYMIaALgrX5QLCjnXURoeT_ap-kVhnBWIxU=.0df67176-e7fd-40e2-8ec1-f15267d1f478@github.com>

On Thu, 23 Dec 2021 01:14:50 GMT, Xin Liu <xliu at openjdk.org> wrote:

> The comment is inaccurate now. VMThread is different from the primordial thread. I guess the comment is based on the old codebase.
> Because VMThread is singleton, I put the Constructor and Destructor in "private" section. clients use static member functions create/destroy.

I don't know if that comment has ever been accurate :)

Changes look fine and trivial IMO. I think loop() could/should also be private.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6922

From yyang at openjdk.java.net  Thu Dec 23 02:20:55 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 23 Dec 2021 02:20:55 GMT
Subject: RFR: 8278125: Some preallocated OOMEs are missing stack trace [v6]
In-Reply-To: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
References: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
Message-ID: <uf0UbaxEAU0ZwyJ--7-0Cr4EuquqSNPmiVAoAmSzAKA=.532751aa-dc30-45f9-9871-1d39084ed9d4@github.com>

> Our customer found that the PreallocatedOutOfMemoryErrorCount is 4 by default. It ought to pre-allocate 4 OOMEs with stack trace, but in fact, no matter how many OOMEs are thrown, only 2 OOMEs have proper stack trace. This is because PreallocatedOutOfMemoryErrorCount is consumed multiple times:
> 
> VM tries to allocate a huge object while Java heap is insufficient to accommodate, it goes to:
> 
> https://github.com/openjdk/jdk/blob/b79554bb5cef14590d427543a40efbcc60c66548/src/hotspot/share/gc/shared/memAllocator.cpp#L115-L136
> 
> Line 135(`Universe::out_of_memory_error_java_heap`->`Universe::gen_out_of_memory_error`) and line 136(`THROW_OOP_`->`Exceptions::_throw`->`Exceptions::count_out_of_memory_exceptions`->`Universe::out_of_memory_error_java_heap`->`Universe::gen_out_of_memory_error`) call `Universe::gen_out_of_memory_error` twice in a single OOM event, which leads this unexpected scenario. Proposed fix is to remove such call in `Exceptions::count_out_of_memory_exceptions`.
> 
> Thanks.

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  test tweak

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6672/files
  - new: https://git.openjdk.java.net/jdk/pull/6672/files/a05703b9..368762fd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6672&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6672&range=04-05

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6672.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6672/head:pull/6672

PR: https://git.openjdk.java.net/jdk/pull/6672

From yyang at openjdk.java.net  Thu Dec 23 02:20:57 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 23 Dec 2021 02:20:57 GMT
Subject: RFR: 8278125: Some preallocated OOMEs are missing stack trace [v3]
In-Reply-To: <okBlPMjEWBDcUtfQupEXJ5miYRRclGA2S8PiF1UL2bs=.2653a4af-a39a-4f8a-9786-e24d2a3cbc33@github.com>
References: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
 <yoaT87337KQzVF-xRpopBnEIMf6YQNV9Ec1Gs4n2ewI=.55c29c27-27fd-4d77-b6d8-fd466be6ca9e@github.com>
 <okBlPMjEWBDcUtfQupEXJ5miYRRclGA2S8PiF1UL2bs=.2653a4af-a39a-4f8a-9786-e24d2a3cbc33@github.com>
Message-ID: <uXl_eT5RmmjrMJpI3XWeYQG7vCwG8aHAuFiPGAN0IQU=.ebeedd20-59f2-488e-8a39-4fc4438e8d3a@github.com>

On Fri, 17 Dec 2021 02:33:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   newline before eof
>
> Github UI is making the review comments appear in strange order/places. See the "files" view to see the comments in context.

Thanks @dholmes-ora and @coleenp for reviews!

-------------

PR: https://git.openjdk.java.net/jdk/pull/6672

From yyang at openjdk.java.net  Thu Dec 23 02:21:01 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 23 Dec 2021 02:21:01 GMT
Subject: RFR: 8278125: Some preallocated OOMEs are missing stack trace [v5]
In-Reply-To: <D4ItmXvjf7yr42iQ6y598Uoyro1hlwmS3J39SPnE6JI=.6ea094a4-7e36-49c8-9673-64618cb5ac84@github.com>
References: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
 <J844bFLwRCUg-3lNXzTstJqTo5yN05dBTiBGyBjp7Vk=.1392a674-3297-44d5-8e2a-4fc968539d87@github.com>
 <D4ItmXvjf7yr42iQ6y598Uoyro1hlwmS3J39SPnE6JI=.6ea094a4-7e36-49c8-9673-64618cb5ac84@github.com>
Message-ID: <YRPDQyq56e8o0vD3ykcb_eBiUQTzCeECVmqRgiSnZtI=.fe546f8a-7d4c-479b-9d4d-bceae0dd195a@github.com>

On Thu, 23 Dec 2021 01:54:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Yi Yang has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - typo
>>  - cleanup
>
> test/hotspot/jtreg/runtime/ErrorHandling/GenOutOfMemoryError.java line 41:
> 
>> 39:         try {
>> 40:             System.out.format("bad method was invoked %n", n);
>> 41:             Integer[] array = new Integer[1000 * 1000 * 100];
> 
> Please add a comment:
> 
> // Try to allocate an array the same size as the heap - it will throw OOME without
> // actually consuming available memory.

All done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6672

From yyang at openjdk.java.net  Thu Dec 23 02:21:05 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 23 Dec 2021 02:21:05 GMT
Subject: Integrated: 8278125: Some preallocated OOMEs are missing stack trace
In-Reply-To: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
References: <E024KnLOkF7ZtY2TWiHPUjAh8i-ISHlsysNJG7FzSyA=.f98bff80-27a5-423b-bfc1-c79a56688715@github.com>
Message-ID: <y-aYhjHAtVusfsBBf-FZJWjS8NEEZGpAAmjhdaveRwM=.c8faf807-930b-4cbf-b809-194874bd4ed9@github.com>

On Thu, 2 Dec 2021 12:54:31 GMT, Yi Yang <yyang at openjdk.org> wrote:

> Our customer found that the PreallocatedOutOfMemoryErrorCount is 4 by default. It ought to pre-allocate 4 OOMEs with stack trace, but in fact, no matter how many OOMEs are thrown, only 2 OOMEs have proper stack trace. This is because PreallocatedOutOfMemoryErrorCount is consumed multiple times:
> 
> VM tries to allocate a huge object while Java heap is insufficient to accommodate, it goes to:
> 
> https://github.com/openjdk/jdk/blob/b79554bb5cef14590d427543a40efbcc60c66548/src/hotspot/share/gc/shared/memAllocator.cpp#L115-L136
> 
> Line 135(`Universe::out_of_memory_error_java_heap`->`Universe::gen_out_of_memory_error`) and line 136(`THROW_OOP_`->`Exceptions::_throw`->`Exceptions::count_out_of_memory_exceptions`->`Universe::out_of_memory_error_java_heap`->`Universe::gen_out_of_memory_error`) call `Universe::gen_out_of_memory_error` twice in a single OOM event, which leads this unexpected scenario. Proposed fix is to remove such call in `Exceptions::count_out_of_memory_exceptions`.
> 
> Thanks.

This pull request has now been integrated.

Changeset: ad1dc9c2
Author:    Yi Yang <yyang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ad1dc9c2ae5463363aff20072a3f2ca4ea23acd2
Stats:     88 lines in 4 files changed: 85 ins; 1 del; 2 mod

8278125: Some preallocated OOMEs are missing stack trace

Co-authored-by: dongyun.tdy <dongyun.tdy at alibaba-inc.com>
Reviewed-by: dholmes, coleenp

-------------

PR: https://git.openjdk.java.net/jdk/pull/6672

From dholmes at openjdk.java.net  Thu Dec 23 02:49:15 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 23 Dec 2021 02:49:15 GMT
Subject: RFR: 8267517: async logging for stdout and stderr [v5]
In-Reply-To: <-JCBht0sipE70KzadQ-t4BCohscGC76Sz9GwTC0V6sw=.0d76d735-ac3d-4260-8747-763c72793bf9@github.com>
References: <Nv1V5JHKgJh0NtqijGmWmI9Kh2VgDxgDIOAdfCtOavA=.503f41c2-a5d1-4a25-ab90-00252814a9bf@github.com>
 <-JCBht0sipE70KzadQ-t4BCohscGC76Sz9GwTC0V6sw=.0d76d735-ac3d-4260-8747-763c72793bf9@github.com>
Message-ID: <BggxtF2jatS5yB9GRfpF6Wb9_UR8I7gdugRE3y4swzI=.fc01885e-870c-4bc4-869c-fc2731502a8d@github.com>

On Wed, 22 Dec 2021 09:05:55 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch refactors LogFileStreamOutput so stdout/stderr can support support -Xlog:async.
>> 
>> With  `-Xlog:all=trace:stdout`, the helloworld in Java outputs 16520 log entries to stdout.  We are see that the wall time reduces from  84.138ms to 72.914ms, or the throughput increases 15% because of async logging.
>> 
>> 
>> $perf stat -r 300 ./build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -Xlog:async -XX:AsyncLogBufferSize=48M HelloWorld > /dev/null
>> 
>>  Performance counter stats for './build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -Xlog:async -XX:AsyncLogBufferSize=48M HelloWorld' (300 runs):
>> 
>>             107.21 msec task-clock                #    1.470 CPUs utilized            ( +-  0.17% )
>>              2,681      context-switches          #    0.025 M/sec                    ( +-  0.32% )
>>                  1      cpu-migrations            #    0.011 K/sec                    ( +-  4.56% )
>>              4,006      page-faults               #    0.037 M/sec                    ( +-  0.01% )
>> ...
>>           0.072914 +- 0.000126 seconds time elapsed  ( +-  0.17% )
>> 
>>  Performance counter stats for './build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -XX:AsyncLogBufferSize=48M HelloWorld' (300 runs):
>> 
>>              88.04 msec task-clock                #    1.046 CPUs utilized            ( +-  0.10% )
>>                310      context-switches          #    0.004 M/sec                    ( +-  0.31% )
>>                  1      cpu-migrations            #    0.008 K/sec                    ( +-  5.07% )
>>              4,004      page-faults               #    0.045 M/sec                    ( +-  0.01% )
>> ...
>>           0.084138 +- 0.000111 seconds time elapsed  ( +-  0.13% )
>> 
>> 
>> The easiest test of stdout with AsyncLogging is to use tty and XOFF Ctrl^s. Java applications with UL to stdout were blocked by Ctrl-s. The entire java process will be frozen.  -Xlog:async now cover both stdout and stderr. It can circumvent this issue.  
>> 
>> Add a new jtreg to cover a scenario that unified logging with -Xlog:async will not be frozen even when stdout is blocked.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove BlockedLoggingTest.java and add test for stdout/err in test_asynclog.cpp.
>   
>   This patch also adds to flushing semantic to LogFileStreamOutput::write_blocking().
>   It aligns with LogFileOutput::write_blocking().

Latest version looks good to me. I'm running it through our CI testing.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6132

From dholmes at openjdk.java.net  Thu Dec 23 05:21:12 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 23 Dec 2021 05:21:12 GMT
Subject: RFR: 8267517: async logging for stdout and stderr [v5]
In-Reply-To: <-JCBht0sipE70KzadQ-t4BCohscGC76Sz9GwTC0V6sw=.0d76d735-ac3d-4260-8747-763c72793bf9@github.com>
References: <Nv1V5JHKgJh0NtqijGmWmI9Kh2VgDxgDIOAdfCtOavA=.503f41c2-a5d1-4a25-ab90-00252814a9bf@github.com>
 <-JCBht0sipE70KzadQ-t4BCohscGC76Sz9GwTC0V6sw=.0d76d735-ac3d-4260-8747-763c72793bf9@github.com>
Message-ID: <kgn9YKiPdh3V1KFPXftUFtMHtkDdRCOiPK00uZuNqYk=.2a540b41-2f85-4b7b-8ab0-a957a2475795@github.com>

On Wed, 22 Dec 2021 09:05:55 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch refactors LogFileStreamOutput so stdout/stderr can support support -Xlog:async.
>> 
>> With  `-Xlog:all=trace:stdout`, the helloworld in Java outputs 16520 log entries to stdout.  We are see that the wall time reduces from  84.138ms to 72.914ms, or the throughput increases 15% because of async logging.
>> 
>> 
>> $perf stat -r 300 ./build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -Xlog:async -XX:AsyncLogBufferSize=48M HelloWorld > /dev/null
>> 
>>  Performance counter stats for './build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -Xlog:async -XX:AsyncLogBufferSize=48M HelloWorld' (300 runs):
>> 
>>             107.21 msec task-clock                #    1.470 CPUs utilized            ( +-  0.17% )
>>              2,681      context-switches          #    0.025 M/sec                    ( +-  0.32% )
>>                  1      cpu-migrations            #    0.011 K/sec                    ( +-  4.56% )
>>              4,006      page-faults               #    0.037 M/sec                    ( +-  0.01% )
>> ...
>>           0.072914 +- 0.000126 seconds time elapsed  ( +-  0.17% )
>> 
>>  Performance counter stats for './build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -XX:AsyncLogBufferSize=48M HelloWorld' (300 runs):
>> 
>>              88.04 msec task-clock                #    1.046 CPUs utilized            ( +-  0.10% )
>>                310      context-switches          #    0.004 M/sec                    ( +-  0.31% )
>>                  1      cpu-migrations            #    0.008 K/sec                    ( +-  5.07% )
>>              4,004      page-faults               #    0.045 M/sec                    ( +-  0.01% )
>> ...
>>           0.084138 +- 0.000111 seconds time elapsed  ( +-  0.13% )
>> 
>> 
>> The easiest test of stdout with AsyncLogging is to use tty and XOFF Ctrl^s. Java applications with UL to stdout were blocked by Ctrl-s. The entire java process will be frozen.  -Xlog:async now cover both stdout and stderr. It can circumvent this issue.  
>> 
>> Add a new jtreg to cover a scenario that unified logging with -Xlog:async will not be frozen even when stdout is blocked.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove BlockedLoggingTest.java and add test for stdout/err in test_asynclog.cpp.
>   
>   This patch also adds to flushing semantic to LogFileStreamOutput::write_blocking().
>   It aligns with LogFileOutput::write_blocking().

Testing results were fine.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6132

From ysuenaga at openjdk.java.net  Thu Dec 23 06:33:14 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 23 Dec 2021 06:33:14 GMT
Subject: RFR: 8267517: async logging for stdout and stderr [v5]
In-Reply-To: <-JCBht0sipE70KzadQ-t4BCohscGC76Sz9GwTC0V6sw=.0d76d735-ac3d-4260-8747-763c72793bf9@github.com>
References: <Nv1V5JHKgJh0NtqijGmWmI9Kh2VgDxgDIOAdfCtOavA=.503f41c2-a5d1-4a25-ab90-00252814a9bf@github.com>
 <-JCBht0sipE70KzadQ-t4BCohscGC76Sz9GwTC0V6sw=.0d76d735-ac3d-4260-8747-763c72793bf9@github.com>
Message-ID: <1z252MYN6UPdBfbCAqNYU28UF91GmjR93gDKp30qTnQ=.efe9c7b4-f0bc-4c1a-b8b2-0099eb4b1bc2@github.com>

On Wed, 22 Dec 2021 09:05:55 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch refactors LogFileStreamOutput so stdout/stderr can support support -Xlog:async.
>> 
>> With  `-Xlog:all=trace:stdout`, the helloworld in Java outputs 16520 log entries to stdout.  We are see that the wall time reduces from  84.138ms to 72.914ms, or the throughput increases 15% because of async logging.
>> 
>> 
>> $perf stat -r 300 ./build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -Xlog:async -XX:AsyncLogBufferSize=48M HelloWorld > /dev/null
>> 
>>  Performance counter stats for './build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -Xlog:async -XX:AsyncLogBufferSize=48M HelloWorld' (300 runs):
>> 
>>             107.21 msec task-clock                #    1.470 CPUs utilized            ( +-  0.17% )
>>              2,681      context-switches          #    0.025 M/sec                    ( +-  0.32% )
>>                  1      cpu-migrations            #    0.011 K/sec                    ( +-  4.56% )
>>              4,006      page-faults               #    0.037 M/sec                    ( +-  0.01% )
>> ...
>>           0.072914 +- 0.000126 seconds time elapsed  ( +-  0.17% )
>> 
>>  Performance counter stats for './build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -XX:AsyncLogBufferSize=48M HelloWorld' (300 runs):
>> 
>>              88.04 msec task-clock                #    1.046 CPUs utilized            ( +-  0.10% )
>>                310      context-switches          #    0.004 M/sec                    ( +-  0.31% )
>>                  1      cpu-migrations            #    0.008 K/sec                    ( +-  5.07% )
>>              4,004      page-faults               #    0.045 M/sec                    ( +-  0.01% )
>> ...
>>           0.084138 +- 0.000111 seconds time elapsed  ( +-  0.13% )
>> 
>> 
>> The easiest test of stdout with AsyncLogging is to use tty and XOFF Ctrl^s. Java applications with UL to stdout were blocked by Ctrl-s. The entire java process will be frozen.  -Xlog:async now cover both stdout and stderr. It can circumvent this issue.  
>> 
>> Add a new jtreg to cover a scenario that unified logging with -Xlog:async will not be frozen even when stdout is blocked.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove BlockedLoggingTest.java and add test for stdout/err in test_asynclog.cpp.
>   
>   This patch also adds to flushing semantic to LogFileStreamOutput::write_blocking().
>   It aligns with LogFileOutput::write_blocking().

Marked as reviewed by ysuenaga (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6132

From xliu at openjdk.java.net  Thu Dec 23 20:24:16 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 23 Dec 2021 20:24:16 GMT
Subject: RFR: 8267517: async logging for stdout and stderr [v5]
In-Reply-To: <kgn9YKiPdh3V1KFPXftUFtMHtkDdRCOiPK00uZuNqYk=.2a540b41-2f85-4b7b-8ab0-a957a2475795@github.com>
References: <Nv1V5JHKgJh0NtqijGmWmI9Kh2VgDxgDIOAdfCtOavA=.503f41c2-a5d1-4a25-ab90-00252814a9bf@github.com>
 <-JCBht0sipE70KzadQ-t4BCohscGC76Sz9GwTC0V6sw=.0d76d735-ac3d-4260-8747-763c72793bf9@github.com>
 <kgn9YKiPdh3V1KFPXftUFtMHtkDdRCOiPK00uZuNqYk=.2a540b41-2f85-4b7b-8ab0-a957a2475795@github.com>
Message-ID: <gK-XmsgaS5DgqAp7KPsvedw2F1mxxMae7WZnYpTfKpg=.d847fa5b-8d6c-4753-acdd-5f9b34e36225@github.com>

On Thu, 23 Dec 2021 05:18:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove BlockedLoggingTest.java and add test for stdout/err in test_asynclog.cpp.
>>   
>>   This patch also adds to flushing semantic to LogFileStreamOutput::write_blocking().
>>   It aligns with LogFileOutput::write_blocking().
>
> Testing results were fine.

@dholmes-ora @YaSuenag 
Thanks for reviewing!

-------------

PR: https://git.openjdk.java.net/jdk/pull/6132

From xliu at openjdk.java.net  Thu Dec 23 20:24:16 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 23 Dec 2021 20:24:16 GMT
Subject: RFR: 8267517: async logging for stdout and stderr [v3]
In-Reply-To: <vDLjYnXX2GN7mCoiYT6Ebr1jVl_cqQVXH8SrElpF2fc=.a79f95a4-a463-4ff0-afc3-9b3f70d39683@github.com>
References: <Nv1V5JHKgJh0NtqijGmWmI9Kh2VgDxgDIOAdfCtOavA=.503f41c2-a5d1-4a25-ab90-00252814a9bf@github.com>
 <ddwRuorCLqbH2zmw-PktIT9bm13hJ2jvNWJMX_1XQpo=.4f426bfb-b843-44c7-b935-fd748dd25db7@github.com>
 <n4MKggE1CsTP9F4f3vYXt-AyaP_TMmF2px-XuxaB2EI=.3efa60a5-a850-4139-81fe-6be8be576d38@github.com>
 <nNJfsPEuz1jJsvAhtVc_GbC2v7rjsBrybot4nTNHIeU=.9b61e42f-d160-4437-8258-ff9e3e1fdbf5@github.com>
 <vDLjYnXX2GN7mCoiYT6Ebr1jVl_cqQVXH8SrElpF2fc=.a79f95a4-a463-4ff0-afc3-9b3f70d39683@github.com>
Message-ID: <aFRi9JNXkTXsdR9vQvC9Zf4iGr6evMbqKLjcv0sNhuM=.093bd48a-2d61-49d0-a64e-058fe3392b0b@github.com>

On Tue, 21 Dec 2021 22:30:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> because `LogFileStreamOutput::write_blocking()` doesn't call fflush(), therefore, we need to do special treat for STDOUT here.
>
> Okay so why does LFO::write_blocking call fflush but LFSO::write_blocking does not? Shouldn't the two methods have the same general semantics?

done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6132

From xliu at openjdk.java.net  Thu Dec 23 20:28:17 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 23 Dec 2021 20:28:17 GMT
Subject: Integrated: 8267517: async logging for stdout and stderr
In-Reply-To: <Nv1V5JHKgJh0NtqijGmWmI9Kh2VgDxgDIOAdfCtOavA=.503f41c2-a5d1-4a25-ab90-00252814a9bf@github.com>
References: <Nv1V5JHKgJh0NtqijGmWmI9Kh2VgDxgDIOAdfCtOavA=.503f41c2-a5d1-4a25-ab90-00252814a9bf@github.com>
Message-ID: <xCIAxfRc7rhm4ANVY8ye2XtJpNrBOQmEdie4bRz__9Q=.07a478e7-1028-4748-b1c2-7287e8d2e95f@github.com>

On Wed, 27 Oct 2021 08:22:12 GMT, Xin Liu <xliu at openjdk.org> wrote:

> This patch refactors LogFileStreamOutput so stdout/stderr can support support -Xlog:async.
> 
> With  `-Xlog:all=trace:stdout`, the helloworld in Java outputs 16520 log entries to stdout.  We are see that the wall time reduces from  84.138ms to 72.914ms, or the throughput increases 15% because of async logging.
> 
> 
> $perf stat -r 300 ./build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -Xlog:async -XX:AsyncLogBufferSize=48M HelloWorld > /dev/null
> 
>  Performance counter stats for './build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -Xlog:async -XX:AsyncLogBufferSize=48M HelloWorld' (300 runs):
> 
>             107.21 msec task-clock                #    1.470 CPUs utilized            ( +-  0.17% )
>              2,681      context-switches          #    0.025 M/sec                    ( +-  0.32% )
>                  1      cpu-migrations            #    0.011 K/sec                    ( +-  4.56% )
>              4,006      page-faults               #    0.037 M/sec                    ( +-  0.01% )
> ...
>           0.072914 +- 0.000126 seconds time elapsed  ( +-  0.17% )
> 
>  Performance counter stats for './build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:all=trace:stdout -XX:AsyncLogBufferSize=48M HelloWorld' (300 runs):
> 
>              88.04 msec task-clock                #    1.046 CPUs utilized            ( +-  0.10% )
>                310      context-switches          #    0.004 M/sec                    ( +-  0.31% )
>                  1      cpu-migrations            #    0.008 K/sec                    ( +-  5.07% )
>              4,004      page-faults               #    0.045 M/sec                    ( +-  0.01% )
> ...
>           0.084138 +- 0.000111 seconds time elapsed  ( +-  0.13% )
> 
> 
> The easiest test of stdout with AsyncLogging is to use tty and XOFF Ctrl^s. Java applications with UL to stdout were blocked by Ctrl-s. The entire java process will be frozen.  -Xlog:async now cover both stdout and stderr. It can circumvent this issue.  
> 
> Add a new jtreg to cover a scenario that unified logging with -Xlog:async will not be frozen even when stdout is blocked.

This pull request has now been integrated.

Changeset: 7aff03ae
Author:    Xin Liu <xliu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7aff03aee1a5cd70638d8bbafeb7765bc7beea45
Stats:     129 lines in 7 files changed: 92 ins; 11 del; 26 mod

8267517: async logging for stdout and stderr

Reviewed-by: dholmes, ysuenaga

-------------

PR: https://git.openjdk.java.net/jdk/pull/6132

From xliu at openjdk.java.net  Thu Dec 23 21:14:49 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 23 Dec 2021 21:14:49 GMT
Subject: RFR: 8279189: Inaccurate comment about class VMThread [v2]
In-Reply-To: <OXbWm67Og9ooBs8AASjp2hcdT-nSD0IwNPN34rDYEWw=.571e4fd3-05e0-4712-bc00-bab8eded8dab@github.com>
References: <OXbWm67Og9ooBs8AASjp2hcdT-nSD0IwNPN34rDYEWw=.571e4fd3-05e0-4712-bc00-bab8eded8dab@github.com>
Message-ID: <x0mas4bAp01HQ4impOAlDxPbE2cNt91JYLah7FcJIg8=.b0b27b51-0194-43c5-876d-8821f31018ff@github.com>

> The comment is inaccurate now. VMThread is different from the primordial thread. I guess the comment is based on the old codebase.
> Because VMThread is singleton, I put the Constructor and Destructor in "private" section. clients use static member functions create/destroy.

Xin Liu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' into JDK-8279189
 - hide VMThread::loop as well.
 - 8279189: Inaccurate comment about class VMThread

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6922/files
  - new: https://git.openjdk.java.net/jdk/pull/6922/files/8c26760b..45c43219

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6922&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6922&range=00-01

  Stats: 9722 lines in 392 files changed: 5240 ins; 2974 del; 1508 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6922.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6922/head:pull/6922

PR: https://git.openjdk.java.net/jdk/pull/6922

From xliu at openjdk.java.net  Thu Dec 23 21:44:22 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 23 Dec 2021 21:44:22 GMT
Subject: RFR: 8279189: Inaccurate comment about class VMThread [v2]
In-Reply-To: <x0mas4bAp01HQ4impOAlDxPbE2cNt91JYLah7FcJIg8=.b0b27b51-0194-43c5-876d-8821f31018ff@github.com>
References: <OXbWm67Og9ooBs8AASjp2hcdT-nSD0IwNPN34rDYEWw=.571e4fd3-05e0-4712-bc00-bab8eded8dab@github.com>
 <x0mas4bAp01HQ4impOAlDxPbE2cNt91JYLah7FcJIg8=.b0b27b51-0194-43c5-876d-8821f31018ff@github.com>
Message-ID: <l3pQNMRYwyPJXLvsZIH2kyPOc8Y2l_oxwU2ZzR8epnM=.f59f11d5-2093-41ea-8078-2b5eb17c029d@github.com>

On Thu, 23 Dec 2021 21:14:49 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> The comment is inaccurate now. VMThread is different from the primordial thread. I guess the comment is based on the old codebase.
>> Because VMThread is singleton, I put the Constructor and Destructor in "private" section. clients use static member functions create/destroy.
>
> Xin Liu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8279189
>  - hide VMThread::loop as well.
>  - 8279189: Inaccurate comment about class VMThread

Reasonable. Tuck away VMThread::loop() in the private section as well.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6922

From kbarrett at openjdk.java.net  Fri Dec 24 00:37:18 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 24 Dec 2021 00:37:18 GMT
Subject: RFR: 8279189: Inaccurate comment about class VMThread [v2]
In-Reply-To: <x0mas4bAp01HQ4impOAlDxPbE2cNt91JYLah7FcJIg8=.b0b27b51-0194-43c5-876d-8821f31018ff@github.com>
References: <OXbWm67Og9ooBs8AASjp2hcdT-nSD0IwNPN34rDYEWw=.571e4fd3-05e0-4712-bc00-bab8eded8dab@github.com>
 <x0mas4bAp01HQ4impOAlDxPbE2cNt91JYLah7FcJIg8=.b0b27b51-0194-43c5-876d-8821f31018ff@github.com>
Message-ID: <d3W7HAqWqeO7O9KmOXg0U_Ec9onfo0wOPkqV3BMkuuI=.55fb0e21-012c-4963-82bf-96fe0086bb5e@github.com>

On Thu, 23 Dec 2021 21:14:49 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> The comment is inaccurate now. VMThread is different from the primordial thread. I guess the comment is based on the old codebase.
>> Because VMThread is singleton, I put the Constructor and Destructor in "private" section. clients use static member functions create/destroy.
>
> Xin Liu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8279189
>  - hide VMThread::loop as well.
>  - 8279189: Inaccurate comment about class VMThread

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6922

From xliu at openjdk.java.net  Fri Dec 24 01:00:15 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Fri, 24 Dec 2021 01:00:15 GMT
Subject: Integrated: 8279189: Inaccurate comment about class VMThread
In-Reply-To: <OXbWm67Og9ooBs8AASjp2hcdT-nSD0IwNPN34rDYEWw=.571e4fd3-05e0-4712-bc00-bab8eded8dab@github.com>
References: <OXbWm67Og9ooBs8AASjp2hcdT-nSD0IwNPN34rDYEWw=.571e4fd3-05e0-4712-bc00-bab8eded8dab@github.com>
Message-ID: <V3DxvW9HJ1GbrEn0Z_Xl2gBDXj5B-5nOStOXSKlZovo=.96f5750a-4854-4717-9bdc-9058401efb58@github.com>

On Thu, 23 Dec 2021 01:14:50 GMT, Xin Liu <xliu at openjdk.org> wrote:

> The comment is inaccurate now. VMThread is different from the primordial thread. I guess the comment is based on the old codebase.
> Because VMThread is singleton, I put the Constructor and Destructor in "private" section. clients use static member functions create/destroy.

This pull request has now been integrated.

Changeset: 22c15dda
Author:    Xin Liu <xliu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/22c15ddae5ef7431f677edf4df9a403613716def
Stats:     10 lines in 1 file changed: 4 ins; 5 del; 1 mod

8279189: Inaccurate comment about class VMThread

Reviewed-by: dholmes, kbarrett

-------------

PR: https://git.openjdk.java.net/jdk/pull/6922

From iklam at openjdk.java.net  Fri Dec 24 01:56:10 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 24 Dec 2021 01:56:10 GMT
Subject: RFR: 8261455: Automatically generate the CDS archive if necessary
In-Reply-To: <0V7F_B4KQSngtk3LRpCO3cw0nGgUELyY3H6sGqva8J4=.6c61f0be-3bf0-43d1-8a33-899a1cb88161@github.com>
References: <0V7F_B4KQSngtk3LRpCO3cw0nGgUELyY3H6sGqva8J4=.6c61f0be-3bf0-43d1-8a33-899a1cb88161@github.com>
Message-ID: <xcq-5JUx3WEmTh8OAiqB6PQX0Qmap0uXZuoa0X_Vg0E=.4affea37-2b4e-4865-b5c2-2ae0769c705f@github.com>

On Thu, 23 Dec 2021 00:22:54 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> This patch is re-coded after serial fixes related: 8275846, 8276787, 8279018 etc.
> original description(PR 5997):
> `----------------------------------------------------------------------------------`
> When shared archive (dynamic archive) failed to map due to damage of the archive file, dump/run jdk version mismatch or non-existence file etc, the new patch will automatically create a new shared archive if -XX:+AutoCreateSharedArchive specified with the name based on SharedArchiveFile.
> This is a revised patch based on the old PR: 5077 and after bug 8273152 integrated.
> `-----------------------------------------------------------------------------------`
> 
> Tests: tier1,tier2,tier3,tier4
> 
> Thanks
> Yumin

Hi Yumin, looks good. I have some preliminary comments.

src/hotspot/share/cds/dynamicArchive.cpp line 414:

> 412: bool DynamicArchive::should_dump_at_vm_exit() {
> 413:   return (DynamicDumpSharedSpaces && (ArchiveClassesAtExit != nullptr)) ||
> 414:          (AutoCreateSharedArchive && Arguments::GetSharedDynamicArchivePath() != nullptr);

I think it's better to do this: if `AutoCreateSharedArchive` is true, and you decide that the archive needs to be updated, then:


    DynamicDumpSharedSpaces = true;
    ArchiveClassesAtExit = Arguments::GetSharedDynamicArchivePath();


That way we don't need to do the check at line 414 anymore.

src/hotspot/share/cds/filemap.cpp line 207:

> 205:   if (!os::file_exists(_full_path)) {
> 206:     return false;
> 207:   }

Is the above check necessary? If the file doesn't exist, will `check_archive()` below return false?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6920

From dholmes at openjdk.java.net  Fri Dec 24 02:42:27 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 24 Dec 2021 02:42:27 GMT
Subject: [jdk18] RFR: 8272058: 25 Null pointer dereference defect groups in
 4 files
In-Reply-To: <TwIvJ3FE4o5AqZ38OQaZhzhB5Ctdph9LYLcQOEZswPk=.14774a97-d3e1-44e1-8a91-568c9d632334@github.com>
References: <TwIvJ3FE4o5AqZ38OQaZhzhB5Ctdph9LYLcQOEZswPk=.14774a97-d3e1-44e1-8a91-568c9d632334@github.com>
Message-ID: <-Sr3JRlCtjaAaKRF_nM0xYoDAjHGaxsH0QAjMxamWx8=.08ca5ddc-b7b5-4519-aebf-bfcfd56b6409@github.com>

On Mon, 20 Dec 2021 20:50:14 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A small refactoring to resolve a Parfait complaint about the return value from
> `MacroAssembler::target_addr_for_insn(address insn_addr, unsigned insn)`
> on AARCH64. The logic that supports returning `nullptr` as the target addr for
> a particular instruction is moved from
> `MacroAssembler::target_addr_for_insn(address insn_addr, unsigned insn)` to
> `MacroAssembler::target_addr_for_insn_allow_null_ret(address insn_addr, unsigned insn)`.
> A couple of `target_addr_for_insn()` call sites that can tolerate a `nullptr` are
> converted to use `target_addr_for_insn_allow_null_ret()`.
> 
> This fix has been tested with Mach5 Tier[1-3].

Perhaps Boris Ulasevich <boris.ulasevich at bell-sw.com> could review?

-------------

PR: https://git.openjdk.java.net/jdk18/pull/51

From david.holmes at oracle.com  Fri Dec 24 02:54:00 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 24 Dec 2021 12:54:00 +1000
Subject: [jdk18] RFR: 8272058: 25 Null pointer dereference defect groups
 in 4 files
In-Reply-To: <-Sr3JRlCtjaAaKRF_nM0xYoDAjHGaxsH0QAjMxamWx8=.08ca5ddc-b7b5-4519-aebf-bfcfd56b6409@github.com>
References: <TwIvJ3FE4o5AqZ38OQaZhzhB5Ctdph9LYLcQOEZswPk=.14774a97-d3e1-44e1-8a91-568c9d632334@github.com>
 <-Sr3JRlCtjaAaKRF_nM0xYoDAjHGaxsH0QAjMxamWx8=.08ca5ddc-b7b5-4519-aebf-bfcfd56b6409@github.com>
Message-ID: <fb53ebd0-d967-1ade-2e34-ceebcb4b6256@oracle.com>

Adding Boris Ulasevich <boris.ulasevich at bell-sw.com> to cc list :)

On 24/12/2021 12:42 pm, David Holmes wrote:
> On Mon, 20 Dec 2021 20:50:14 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:
> 
>> A small refactoring to resolve a Parfait complaint about the return value from
>> `MacroAssembler::target_addr_for_insn(address insn_addr, unsigned insn)`
>> on AARCH64. The logic that supports returning `nullptr` as the target addr for
>> a particular instruction is moved from
>> `MacroAssembler::target_addr_for_insn(address insn_addr, unsigned insn)` to
>> `MacroAssembler::target_addr_for_insn_allow_null_ret(address insn_addr, unsigned insn)`.
>> A couple of `target_addr_for_insn()` call sites that can tolerate a `nullptr` are
>> converted to use `target_addr_for_insn_allow_null_ret()`.
>>
>> This fix has been tested with Mach5 Tier[1-3].
> 
> Perhaps Boris Ulasevich <boris.ulasevich at bell-sw.com> could review?
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk18/pull/51

From bulasevich at openjdk.java.net  Fri Dec 24 08:02:16 2021
From: bulasevich at openjdk.java.net (Boris Ulasevich)
Date: Fri, 24 Dec 2021 08:02:16 GMT
Subject: [jdk18] RFR: 8272058: 25 Null pointer dereference defect groups in
 4 files
In-Reply-To: <TwIvJ3FE4o5AqZ38OQaZhzhB5Ctdph9LYLcQOEZswPk=.14774a97-d3e1-44e1-8a91-568c9d632334@github.com>
References: <TwIvJ3FE4o5AqZ38OQaZhzhB5Ctdph9LYLcQOEZswPk=.14774a97-d3e1-44e1-8a91-568c9d632334@github.com>
Message-ID: <dVrNlZlsmubOhb5C4ffQ53zPnpkRYhPeyr57IeXYHtc=.37f735e3-b037-4d11-b96e-37df21e148ce@github.com>

On Mon, 20 Dec 2021 20:50:14 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A small refactoring to resolve a Parfait complaint about the return value from
> `MacroAssembler::target_addr_for_insn(address insn_addr, unsigned insn)`
> on AARCH64. The logic that supports returning `nullptr` as the target addr for
> a particular instruction is moved from
> `MacroAssembler::target_addr_for_insn(address insn_addr, unsigned insn)` to
> `MacroAssembler::target_addr_for_insn_allow_null_ret(address insn_addr, unsigned insn)`.
> A couple of `target_addr_for_insn()` call sites that can tolerate a `nullptr` are
> converted to use `target_addr_for_insn_allow_null_ret()`.
> 
> This fix has been tested with Mach5 Tier[1-3].

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 293:

> 291: 
> 292: address MacroAssembler::target_addr_for_insn_allow_null_ret(address insn_addr, unsigned insn) {
> 293:   if (Instruction_aarch64::extract(insn, 31, 22) == 0b1011100101 &&

Consider replacing raw constants check with NativeInstruction::is_ldrw_to_zr function call which performs the same check.

-------------

PR: https://git.openjdk.java.net/jdk18/pull/51

From bulasevich at openjdk.java.net  Fri Dec 24 08:13:16 2021
From: bulasevich at openjdk.java.net (Boris Ulasevich)
Date: Fri, 24 Dec 2021 08:13:16 GMT
Subject: [jdk18] RFR: 8272058: 25 Null pointer dereference defect groups in
 4 files
In-Reply-To: <TwIvJ3FE4o5AqZ38OQaZhzhB5Ctdph9LYLcQOEZswPk=.14774a97-d3e1-44e1-8a91-568c9d632334@github.com>
References: <TwIvJ3FE4o5AqZ38OQaZhzhB5Ctdph9LYLcQOEZswPk=.14774a97-d3e1-44e1-8a91-568c9d632334@github.com>
Message-ID: <z86gxosAnMnZs7a2UVGPibyLHxlrAJ4wrNlLWMii9uE=.50d581d2-fdca-4db1-a0ad-67aa94867386@github.com>

On Mon, 20 Dec 2021 20:50:14 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A small refactoring to resolve a Parfait complaint about the return value from
> `MacroAssembler::target_addr_for_insn(address insn_addr, unsigned insn)`
> on AARCH64. The logic that supports returning `nullptr` as the target addr for
> a particular instruction is moved from
> `MacroAssembler::target_addr_for_insn(address insn_addr, unsigned insn)` to
> `MacroAssembler::target_addr_for_insn_allow_null_ret(address insn_addr, unsigned insn)`.
> A couple of `target_addr_for_insn()` call sites that can tolerate a `nullptr` are
> converted to use `target_addr_for_insn_allow_null_ret()`.
> 
> This fix has been tested with Mach5 Tier[1-3].

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 286:

> 284:                    + (uint64_t(Instruction_aarch64::extract(insns[1], 20, 5)) << 16)
> 285:                    + (uint64_t(Instruction_aarch64::extract(insns[2], 20, 5)) << 32));
> 286:   } else if (Instruction_aarch64::extract(insn, 31, 22) == 0b1011100101 &&

It must be a check for safePoint poll: ldrw zr, polling_page. Technically, the target address for this instruction is zero and the function is correct. I am not sure Parfait is right in his complaints. After all, does this code ever works? That is, if you remove it, will the SholdNotReachHere below fire?

-------------

PR: https://git.openjdk.java.net/jdk18/pull/51

From duke at openjdk.java.net  Mon Dec 27 10:24:59 2021
From: duke at openjdk.java.net (KIRIYAMA Takuya)
Date: Mon, 27 Dec 2021 10:24:59 GMT
Subject: RFR: 8277531: Print actual default stacksize on Windows thread
 logging [v2]
In-Reply-To: <L2wrxWhTIPTC8xeV3zrOnk46JIQrpf1m7iB9m6_sl34=.d7c9f526-85da-43e0-b516-291113f58192@github.com>
References: <L2wrxWhTIPTC8xeV3zrOnk46JIQrpf1m7iB9m6_sl34=.d7c9f526-85da-43e0-b516-291113f58192@github.com>
Message-ID: <uNOseHxaOQQHCieNFU14E2-SAji44PjzuXoYfwy0YsY=.d3c355c5-9765-4f6c-bd7b-54f9cb417555@github.com>

> I modified to log actual stack size on Windows by using `os::win32::default_stack_size()`.
> Could you please review this fix?

KIRIYAMA Takuya has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - 8277531: Print actual default stacksize on Windows thread logging
 - Merge branch 'master' into 8277531
 - 8277531: Print actual default stacksize on Windows thread logging

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6495/files
  - new: https://git.openjdk.java.net/jdk/pull/6495/files/85d114f8..3eb2d5c7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6495&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6495&range=00-01

  Stats: 68230 lines in 1811 files changed: 44791 ins; 13591 del; 9848 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6495.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6495/head:pull/6495

PR: https://git.openjdk.java.net/jdk/pull/6495

From duke at openjdk.java.net  Mon Dec 27 10:25:00 2021
From: duke at openjdk.java.net (KIRIYAMA Takuya)
Date: Mon, 27 Dec 2021 10:25:00 GMT
Subject: RFR: 8277531: Print actual default stacksize on Windows thread
 logging
In-Reply-To: <nPLiKHHVp_wadIaFmXMga93KEqlDOiY2lOxc9_YM_4E=.1f3c8f08-d069-4d70-8901-217972bf2137@github.com>
References: <L2wrxWhTIPTC8xeV3zrOnk46JIQrpf1m7iB9m6_sl34=.d7c9f526-85da-43e0-b516-291113f58192@github.com>
 <75bf40e6-bf11-28b4-16e7-11e21a1d0ca0@oracle.com>
 <T3OAJTDch_ipEVaPCRnH4nwLEnITj0wgty2DFgrkxoA=.2bdac040-f380-4844-835a-3f5b31921e13@github.com>
 <RAZoGS3tta9FVpbkdRSq2dA1BZpVXP9C1HRS-HxlR8M=.13074a86-d9f1-4243-8b00-573186ef9833@github.com>
 <nPLiKHHVp_wadIaFmXMga93KEqlDOiY2lOxc9_YM_4E=.1f3c8f08-d069-4d70-8901-217972bf2137@github.com>
Message-ID: <duxc-IqRy5hGkSslrRcTiouaZ_8rkk48fjs5e_XJIqk=.33a3bc2a-f54a-4f49-b057-ebfc5cacdaa2@github.com>

On Fri, 10 Dec 2021 12:38:34 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hi, @tkiriyama,
>> 
>>> > The problem is that os:;win32::default_stack_size() doesn't necessarily
>>> > report the default stack size - it simply reports the stackSize of the
>>> > initial main JavaThread thread. So if you print it, it should only be
>>> > for JavaThreads that are not CompilerThreads.
>>> 
>>> In either case of JavaThreads or CompilerThreads,the stack_size argument of _beginthreadex() must be 0 when this code is executed. According to MSDN document, If the stack_size argument can be 0, the operating system uses the same value as the stack that's specified for the main thread. default_stack_size is specified in create_vm() which runs in the main thread, so we use default_stack_size() for CompilerThreads.
>> 
>> Nope, unfortunately not. It runs on the thread invoking CreateJavaVM(). That is usually not the OS main thread (aka primordial thread). In the case of the standard java launcher, the primordial thread spawns a second thread to invoke CreateJavaVM() in, mainly to impose -Xss. In the case of a custom launcher, all bets are open which thread invokes CreateJavaVM(), but typically it's not the primordial thread either. In fact, we have platforms that explicitly forbid invoking CreateJavaVM() on the primordial thread.
>
>> Hi, @tstuefe ,
>> 
>> It?s exactly as you said. I tried to change _default_stack_size to be set in the main thread or get the stack size of other thread, but it doesn't work well. I wonder if there might be another way to do this.
> 
> I only have bad ideas:
> 
> Bad idea:
> 1) start a thread on windows with stacksize 0. Measure stack size. Now you know the stack size. Obviously bad since we pay for the startup of one whole thread, pointlessly. Whose only point of existing is to tell us its stack size. 
> 
> Slightly better idea, but still bad:
> 
> 2) set _default_stack_size=0 meaning unknown. The first thread created with stacksize=0 measures its own stack and updates that variable. Obviously bad because: too much complexity (e.g. how does the child know it was created with stacksize=0), and at least the first stacksize=0 thread will still be printed with "stacksize=0" by its parent.
> 
> Also bad, but differently bad :-) :
> 
> 3) Just measure default stack size on a developer machine, assume it is the same as on every runtime machine. Hard-code that into the VM. Obviously also bad.
> 
> So, for now I don't see a good idea. If you come up with something better, feel free. But its not a big problem tbh, so probably not worth many brain cycles.
> 
> Cheers, Thomas

Hi, @tstuefe , 

Thank you for your ideas.  
I thought about some alternatives for fix, but unfortunately it is diffcult to print actual stack size when the thread is created.

It is possible to get the stack size when the thread is alive.
I can print actual stack size by thread->stack_size() in thread_native_entry().

With this fix, additional information is printed when logging "thread is alive".
Log format of Xlog changes, but it may be useful that we can know actual stack size in this log.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6495

From minqi at openjdk.java.net  Mon Dec 27 21:42:14 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Mon, 27 Dec 2021 21:42:14 GMT
Subject: RFR: 8261455: Automatically generate the CDS archive if necessary
In-Reply-To: <xcq-5JUx3WEmTh8OAiqB6PQX0Qmap0uXZuoa0X_Vg0E=.4affea37-2b4e-4865-b5c2-2ae0769c705f@github.com>
References: <0V7F_B4KQSngtk3LRpCO3cw0nGgUELyY3H6sGqva8J4=.6c61f0be-3bf0-43d1-8a33-899a1cb88161@github.com>
 <xcq-5JUx3WEmTh8OAiqB6PQX0Qmap0uXZuoa0X_Vg0E=.4affea37-2b4e-4865-b5c2-2ae0769c705f@github.com>
Message-ID: <8G45Sq6KpixtCZHUshXGTyBRKNG1i6JwptIbZqMGvgY=.ee604e57-6ea7-4702-aa7e-f345a6508cee@github.com>

On Fri, 24 Dec 2021 01:38:06 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This patch is re-coded after serial fixes related: 8275846, 8276787, 8279018 etc.
>> original description(PR 5997):
>> `----------------------------------------------------------------------------------`
>> When shared archive (dynamic archive) failed to map due to damage of the archive file, dump/run jdk version mismatch or non-existence file etc, the new patch will automatically create a new shared archive if -XX:+AutoCreateSharedArchive specified with the name based on SharedArchiveFile.
>> This is a revised patch based on the old PR: 5077 and after bug 8273152 integrated.
>> `-----------------------------------------------------------------------------------`
>> 
>> Tests: tier1,tier2,tier3,tier4
>> 
>> Thanks
>> Yumin
>
> src/hotspot/share/cds/filemap.cpp line 207:
> 
>> 205:   if (!os::file_exists(_full_path)) {
>> 206:     return false;
>> 207:   }
> 
> Is the above check necessary? If the file doesn't exist, will `check_archive()` below return false?

It is needed here --- when open a file of name is NULL, os::open first does is checking:
if (strlen(path) > MAX_PATH - 1) {
    errno = ENAMETOOLONG;
    return -1;
  }
It will crash on NULL. Removing it will cause many tests fail.  os:file_exists will first check if it is NULL. 
I will add comment for it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6920

From minqi at openjdk.java.net  Tue Dec 28 03:44:50 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 28 Dec 2021 03:44:50 GMT
Subject: RFR: 8261455: Automatically generate the CDS archive if necessary
 [v2]
In-Reply-To: <0V7F_B4KQSngtk3LRpCO3cw0nGgUELyY3H6sGqva8J4=.6c61f0be-3bf0-43d1-8a33-899a1cb88161@github.com>
References: <0V7F_B4KQSngtk3LRpCO3cw0nGgUELyY3H6sGqva8J4=.6c61f0be-3bf0-43d1-8a33-899a1cb88161@github.com>
Message-ID: <N6rV0HlOorBEGICRB8cbugMiUKsbgojHdEpfG9Dp93s=.be0489e7-ec67-4f4e-b87a-19887405f956@github.com>

> This patch is re-coded after serial fixes related: 8275846, 8276787, 8279018 etc.
> original description(PR 5997):
> `----------------------------------------------------------------------------------`
> When shared archive (dynamic archive) failed to map due to damage of the archive file, dump/run jdk version mismatch or non-existence file etc, the new patch will automatically create a new shared archive if -XX:+AutoCreateSharedArchive specified with the name based on SharedArchiveFile.
> This is a revised patch based on the old PR: 5077 and after bug 8273152 integrated.
> `-----------------------------------------------------------------------------------`
> 
> Tests: tier1,tier2,tier3,tier4
> 
> Thanks
> Yumin

Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:

  Set ArchiveClassesAtExit when AutoCreateSharedArchive is enabled

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6920/files
  - new: https://git.openjdk.java.net/jdk/pull/6920/files/cc0a3cfa..8bbf190c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6920&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6920&range=00-01

  Stats: 6 lines in 2 files changed: 4 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6920.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6920/head:pull/6920

PR: https://git.openjdk.java.net/jdk/pull/6920

From duke at openjdk.java.net  Wed Dec 29 19:41:55 2021
From: duke at openjdk.java.net (Tyler Steele)
Date: Wed, 29 Dec 2021 19:41:55 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v2]
In-Reply-To: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
Message-ID: <g45JuCIr318VPitnrt3XOBzbhlNK0ozzpTsN4Y7RA0c=.ab437454-8c8f-40bc-8938-cd97f8bfa569@github.com>

> Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ??
> 
> ### Implementation notes and alternatives considered
> 
> After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.
> 
> ### Testing
> 
> Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).
> 
> ### More notes
> 
> I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.

Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - fix unsupported os in TestNativeLibrariesEvent.java
 - Removes unnecessary JFR sanity tests
 - Merge branch 'JDK-8203290' of github.com:backwaterred/jdk into JDK-8203290
 - 8203290: Implements Java Flight Recorder on AIX
   
    - changes build system to allow jfr feature on aix
    - implements NetworkPerformance, CPUPerformance, and SystemProcess
    interfaces from os_perf.hpp
    - implements jfr sanity tests
 - 8203290: Implements Java Flight Recorder on AIX
   
    - changes build system to allow jfr feature on aix
    - implements NetworkPerformance, CPUPerformance, and SystemProcess
    interfaces from os_perf.hpp
    - implements jfr sanity tests

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6885/files
  - new: https://git.openjdk.java.net/jdk/pull/6885/files/a105951a..1fe36f65

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6885&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6885&range=00-01

  Stats: 59306 lines in 1564 files changed: 37906 ins; 12535 del; 8865 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6885.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6885/head:pull/6885

PR: https://git.openjdk.java.net/jdk/pull/6885

From duke at openjdk.java.net  Wed Dec 29 20:50:37 2021
From: duke at openjdk.java.net (Tyler Steele)
Date: Wed, 29 Dec 2021 20:50:37 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v3]
In-Reply-To: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
Message-ID: <MNHfWLDDpaf90uWspzGCCKap56Nn3ZuiEWZTw0_XvaA=.068cb094-2dc7-48cf-9000-670efcc03ada@github.com>

> Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ??
> 
> ### Implementation notes and alternatives considered
> 
> After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.
> 
> ### Testing
> 
> Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).
> 
> ### More notes
> 
> I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.

Tyler Steele has updated the pull request incrementally with one additional commit since the last revision:

  Add misssing lib to jfr gtest

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6885/files
  - new: https://git.openjdk.java.net/jdk/pull/6885/files/1fe36f65..7965898a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6885&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6885&range=01-02

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6885.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6885/head:pull/6885

PR: https://git.openjdk.java.net/jdk/pull/6885

From duke at openjdk.java.net  Wed Dec 29 22:42:50 2021
From: duke at openjdk.java.net (Tyler Steele)
Date: Wed, 29 Dec 2021 22:42:50 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v4]
In-Reply-To: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
Message-ID: <XHfPQldHkfXzD7GJHdkUcZUbIAb5-YuIOSt2HfGmpJI=.3c123d7b-f0fc-468c-a411-b9ece8e5cd2a@github.com>

> Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ??
> 
> ### Implementation notes and alternatives considered
> 
> After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.
> 
> ### Testing
> 
> Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).
> 
> ### More notes
> 
> I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.

Tyler Steele has updated the pull request incrementally with one additional commit since the last revision:

  Addresses possible memory leak in network_utilization Class

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6885/files
  - new: https://git.openjdk.java.net/jdk/pull/6885/files/7965898a..4c0b1877

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6885&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6885&range=02-03

  Stats: 5 lines in 2 files changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6885.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6885/head:pull/6885

PR: https://git.openjdk.java.net/jdk/pull/6885

From duke at openjdk.java.net  Wed Dec 29 23:14:52 2021
From: duke at openjdk.java.net (Tyler Steele)
Date: Wed, 29 Dec 2021 23:14:52 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v5]
In-Reply-To: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
Message-ID: <lAuFaBmN9Mcnni-Hv9E24P9J2JAXqEuVSqt93VNuBZg=.8545060c-1afc-466d-b74b-809396e385b2@github.com>

> Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ??
> 
> ### Implementation notes and alternatives considered
> 
> After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.
> 
> ### Testing
> 
> Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).
> 
> ### More notes
> 
> I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.

Tyler Steele has updated the pull request incrementally with one additional commit since the last revision:

  Fix issue where network_interface pointer is not updated to newly created list

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6885/files
  - new: https://git.openjdk.java.net/jdk/pull/6885/files/4c0b1877..a286c9a4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6885&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6885&range=03-04

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6885.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6885/head:pull/6885

PR: https://git.openjdk.java.net/jdk/pull/6885