From ysuenaga at openjdk.java.net  Mon Mar  1 01:47:53 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Mon, 1 Mar 2021 01:47:53 GMT
Subject: RFR: 8262504: Some CLHSDB command cannot know they run on remote
 debugger
Message-ID: <hYYLenPIpA840x3tcc3ZikUiZKdJB3mSuxDs00dFdQo=.62e3707c-c3f8-48ab-8d1e-d5b7d42661d4@github.com>

`pmap` and `pstack` CLHSDB command do not work on remote debugger, we can see following error message:

hsdb> pmap
not yet implemented (debugger does not support CDebugger)!

However, SA has different message for this purpose:

https://github.com/openjdk/jdk/blob/03d888f463c0a6e3fee70ed8ad606fc0a3082636/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PMap.java#L74-L78

SA should show "remote configuration is not yet implemented" when it works on remote debugger.

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

Commit messages:
 - 8262504: Some CLHSDB command cannot know they run on remote debugger

Changes: https://git.openjdk.java.net/jdk/pull/2766/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2766&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262504
  Stats: 43 lines in 5 files changed: 31 ins; 0 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2766.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2766/head:pull/2766

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

From ysuenaga at openjdk.java.net  Mon Mar  1 04:24:40 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Mon, 1 Mar 2021 04:24:40 GMT
Subject: RFR: 8261710: SA DSO objects have sizes that are too large [v5]
In-Reply-To: <52YX6zmd_t9GFBpis5DdKZ3SsrCVfYfFvjShHBFmiy4=.837101a6-d29c-40c3-a03e-ee7626fb6d80@github.com>
References: <rtxSvuvKLmHKrLtsnxf76vSK41b_HWPR_7Bn3wf9YuM=.cf1b54ae-f01d-48d5-9641-d7d9faa541f5@github.com>
 <C1ZuBo_zuSpQ9EMMFRvm_-NWAuU4MseXMdTgkgV2tUE=.486349a5-8178-498e-952d-ca04ed484a29@github.com>
 <AZ06zVkTOrQvNols2nSkGc5eHV9bGWkGpQ4Ob4HPz7Y=.67f536d2-1073-4a4f-ba34-24ba88a0bf2b@github.com>
 <52YX6zmd_t9GFBpis5DdKZ3SsrCVfYfFvjShHBFmiy4=.837101a6-d29c-40c3-a03e-ee7626fb6d80@github.com>
Message-ID: <ARmeBQAVKun7QAdvotHAO4K-Ud81ftymoSfU7peqdI0=.49db0dc9-404a-4161-9236-08326d44b811@github.com>

On Sat, 20 Feb 2021 12:28:05 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Marked as reviewed by sspitsyn (Reviewer).
>
> @sspitsyn Thanks for the review!
> 
>> > lib->end is declared as unsigned (uintptr_t), so we can't use (lib->end < aligned_end) when lib->end is set to -1.
> 
>> Could we use the 0L instead of -1L? What's wrong with 0L?
> 
> I prefer to use -1 instead of 0 for invalid value because we can't distinguish NULL or invalid value if we use 0.

PING: Can I get second reviewer?

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

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

From cjplummer at openjdk.java.net  Mon Mar  1 06:49:07 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 1 Mar 2021 06:49:07 GMT
Subject: RFR: 8261710: SA DSO objects have sizes that are too large [v5]
In-Reply-To: <C1ZuBo_zuSpQ9EMMFRvm_-NWAuU4MseXMdTgkgV2tUE=.486349a5-8178-498e-952d-ca04ed484a29@github.com>
References: <rtxSvuvKLmHKrLtsnxf76vSK41b_HWPR_7Bn3wf9YuM=.cf1b54ae-f01d-48d5-9641-d7d9faa541f5@github.com>
 <C1ZuBo_zuSpQ9EMMFRvm_-NWAuU4MseXMdTgkgV2tUE=.486349a5-8178-498e-952d-ca04ed484a29@github.com>
Message-ID: <4zkgkF0jB4jMOfBGkPMAnV1R_csz_uHmiSfRxCwE9oU=.1e7341e8-04ef-409c-bb0d-dbf441d9a3f1@github.com>

On Thu, 18 Feb 2021 02:56:55 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> This PR relates to [JDK-8261702](https://bugs.openjdk.java.net/browse/JDK-8261702) ( #2562 )
>> When SA creates a DSO object, which is used to represent a shared object file (.so), it initializes the "size" to be the size of the shared object file. This usually results in the size being too big. This can cause SA to get confused about whether or not an address is in the shared object. SA should instead set the DSO's size to the amount of the file that is actually mapped for executable code.
>
> Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Fix comments
>  - Merge remote-tracking branch 'upstream/master' into JDK-8261710
>  - Use p_filesz instead of p_memsz
>  - Remove unnecessary code
>  - Fix for OS X
>  - Use entire of address range of shared library
>  - 8261710: SA DSO objects have sizes that are too large

Marked as reviewed by cjplummer (Reviewer).

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

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

From cjplummer at openjdk.java.net  Mon Mar  1 06:49:07 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 1 Mar 2021 06:49:07 GMT
Subject: RFR: 8261710: SA DSO objects have sizes that are too large [v5]
In-Reply-To: <ARmeBQAVKun7QAdvotHAO4K-Ud81ftymoSfU7peqdI0=.49db0dc9-404a-4161-9236-08326d44b811@github.com>
References: <rtxSvuvKLmHKrLtsnxf76vSK41b_HWPR_7Bn3wf9YuM=.cf1b54ae-f01d-48d5-9641-d7d9faa541f5@github.com>
 <C1ZuBo_zuSpQ9EMMFRvm_-NWAuU4MseXMdTgkgV2tUE=.486349a5-8178-498e-952d-ca04ed484a29@github.com>
 <AZ06zVkTOrQvNols2nSkGc5eHV9bGWkGpQ4Ob4HPz7Y=.67f536d2-1073-4a4f-ba34-24ba88a0bf2b@github.com>
 <52YX6zmd_t9GFBpis5DdKZ3SsrCVfYfFvjShHBFmiy4=.837101a6-d29c-40c3-a03e-ee7626fb6d80@github.com>
 <ARmeBQAVKun7QAdvotHAO4K-Ud81ftymoSfU7peqdI0=.49db0dc9-404a-4161-9236-08326d44b811@github.com>
Message-ID: <MM_2SIKUZ9n4AG7ZVULz9ygiyw8nS6UdI6b_zH0ESuU=.4b6b95aa-6fa6-4ba8-8f33-fb64b15f7613@github.com>

On Mon, 1 Mar 2021 04:22:15 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> PING: Can I get second reviewer?

Sorry, thought I had already done that but I guess not.

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

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

From lucy at openjdk.java.net  Mon Mar  1 08:14:59 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Mon, 1 Mar 2021 08:14:59 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v8]
In-Reply-To: <VGY2qZPofTF4kvhoh2eb-gEVskrAllfc2qUGniHve9w=.a1bbf3d0-a7d5-4362-8511-13e6ad3f5b6d@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <VGY2qZPofTF4kvhoh2eb-gEVskrAllfc2qUGniHve9w=.a1bbf3d0-a7d5-4362-8511-13e6ad3f5b6d@github.com>
Message-ID: <jvGwZSZGzskGi61AiB1TOSe3RPsu-XcCsOowCr_U8fQ=.a6a8e66c-2251-47fa-adc3-f52cfe19b042@github.com>

On Thu, 11 Feb 2021 08:34:09 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comment changes requested by TheRealMDoerr
>
> Changes requested by thartmann (Reviewer).

@TobiHartmann 
@dholmes-ora 
@veresov 
May I kindly ask you to revisit your comments and potentially approve my changes? I believe I have addressed all you concerns and suggestions (as per my comment from Feb 16). 
Thank you!
Lutz

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

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

From thartmann at openjdk.java.net  Mon Mar  1 08:29:59 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 1 Mar 2021 08:29:59 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v8]
In-Reply-To: <Ul6OJXuqVlRZxy7OxB0SRre44bZaZAg7e757hdZf34A=.37ac8cdd-c438-436b-9f84-6176f329b735@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <Ul6OJXuqVlRZxy7OxB0SRre44bZaZAg7e757hdZf34A=.37ac8cdd-c438-436b-9f84-6176f329b735@github.com>
Message-ID: <QcbLrMYdiIMrl_SYwODciobnpte2ttg27-RAg3cx52E=.c40c4fcc-ce88-4e2b-8d92-2e263f118015@github.com>

On Thu, 25 Feb 2021 09:01:10 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> Dear community,
>> may I please request reviews for this fix, improving the usefulness of method invocation counters.
>> - aggregation counters are retyped as uint64_t, shifting the overflow probability way out (> 500 years in case of a 1 GHz counter update frequency).
>> - counters for individual methods are interpreted as (unsigned int), in contrast to their declaration as int. This gives us a factor of two before the counters overflow.
>> - as a special case, "compiled_invocation_counter" is retyped as long, because it has a higher update frequency than other counters.
>> - before/after sample output is attached to the bug description. 
>> 
>> Thank you!
>> Lutz
>
> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment changes requested by TheRealMDoerr

This looks good to me.

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

Marked as reviewed by thartmann (Reviewer).

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

From lucy at openjdk.java.net  Mon Mar  1 08:34:46 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Mon, 1 Mar 2021 08:34:46 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v8]
In-Reply-To: <QcbLrMYdiIMrl_SYwODciobnpte2ttg27-RAg3cx52E=.c40c4fcc-ce88-4e2b-8d92-2e263f118015@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <Ul6OJXuqVlRZxy7OxB0SRre44bZaZAg7e757hdZf34A=.37ac8cdd-c438-436b-9f84-6176f329b735@github.com>
 <QcbLrMYdiIMrl_SYwODciobnpte2ttg27-RAg3cx52E=.c40c4fcc-ce88-4e2b-8d92-2e263f118015@github.com>
Message-ID: <Z3iZ5HHZ218wy3Wk3U3ibFcZXBrPNR_PbhWOKzY49_Y=.74607f8c-98e4-4d27-92a1-9a79f8d2b418@github.com>

On Mon, 1 Mar 2021 08:26:41 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comment changes requested by TheRealMDoerr
>
> This looks good to me.

Thank you for your review, Tobias!
I'll delay integration for a while to give David and Igor a chance to react.

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

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

From aph at openjdk.java.net  Mon Mar  1 10:33:59 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 1 Mar 2021 10:33:59 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v21]
In-Reply-To: <ZfRwLBDhh3K6u3NaWzLWVyoYqBuZVJbipXCZKzPclBs=.bedc9c24-2178-400a-8868-fbbb61b298cc@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <ZfRwLBDhh3K6u3NaWzLWVyoYqBuZVJbipXCZKzPclBs=.bedc9c24-2178-400a-8868-fbbb61b298cc@github.com>
Message-ID: <yMUjWudRugP8LTAT5fuc25Q7R1M9iTCBFMFvXGjRWlQ=.2a6cf189-5bb6-4f41-9e49-d859b85534b6@github.com>

On Fri, 26 Feb 2021 19:17:12 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>  - Minor fixes

src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp line 62:

> 60: 
> 61: #if defined(__APPLE__) || defined(_WIN64)
> 62: #define R18_RESERVED

#define R18_RESERVED true```

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

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

From aph at openjdk.java.net  Mon Mar  1 11:09:56 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 1 Mar 2021 11:09:56 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
In-Reply-To: <snefTFoz9nOu7pghwG_v5GiOsmMvFSiICF3Hr1UskCs=.e9df3841-8204-41f5-a2b7-d8b07569a646@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
 <snefTFoz9nOu7pghwG_v5GiOsmMvFSiICF3Hr1UskCs=.e9df3841-8204-41f5-a2b7-d8b07569a646@github.com>
Message-ID: <olzq5_KwRPyDE2-CoFcqPX9aR0wix5WogLrCo1bgD2I=.ceb47235-e205-4729-b59f-ec9b7033ebe6@github.com>

On Thu, 4 Feb 2021 23:01:52 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>>  - Add comments to WX transitions
>>    
>>    + minor change of placements
>>  - Use macro conditionals instead of empty functions
>>  - Add W^X to tests
>>  - Do not require known W^X state
>>  - Revert w^x in gtests
>
> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 652:
> 
>> 650: 
>> 651: void os::setup_fpu() {
>> 652: }
> 
> Is there really nothing to do here, or does still need to be implemented? A clarification comment here would help/.

There is really nothing to do here.

> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 198:
> 
>> 196: 
>> 197: NOINLINE frame os::current_frame() {
>> 198:   intptr_t *fp = *(intptr_t **)__builtin_frame_address(0);
> 
> In the bsd_x86 counter part we initialize `fp` to `_get_previous_fp()` - do we need to implement it on aarch64 as well (and using address 0 is just a temp workaround) or is it doing the right thing here?

(0)``` looks right to me.

> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 291:
> 
>> 289:         bool is_unsafe_arraycopy = (thread->doing_unsafe_access() && UnsafeCopyMemory::contains_pc(pc));
>> 290:         if ((nm != NULL && nm->has_unsafe_access()) || is_unsafe_arraycopy) {
>> 291:           address next_pc = pc + NativeCall::instruction_size;
> 
> Replace
> 
> address next_pc = pc + NativeCall::instruction_size;
> 
> with
> 
> address next_pc = Assembler::locate_next_instruction(pc);
> 
> there is at least one other place that needs it.

Why is this change needed? AFAICS ```locate_next_instruction()``` is an x86 thing for variable-length instructions, and no other port uses it.

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

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

From aph at openjdk.java.net  Mon Mar  1 11:09:55 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 1 Mar 2021 11:09:55 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v21]
In-Reply-To: <ZfRwLBDhh3K6u3NaWzLWVyoYqBuZVJbipXCZKzPclBs=.bedc9c24-2178-400a-8868-fbbb61b298cc@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <ZfRwLBDhh3K6u3NaWzLWVyoYqBuZVJbipXCZKzPclBs=.bedc9c24-2178-400a-8868-fbbb61b298cc@github.com>
Message-ID: <5l97Ac1W-JbLiCBJMoWut-c-RZEPN6wBHABym2nHeRE=.6d060249-e315-486b-a0ab-1992de6f54d5@github.com>

On Fri, 26 Feb 2021 19:17:12 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>  - Minor fixes

Thanks. With this, I think we're done.

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

Changes requested by aph (Reviewer).

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

From aph at openjdk.java.net  Mon Mar  1 11:09:57 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 1 Mar 2021 11:09:57 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <x0F1vjGptkr-cbJzQ-3bS5zX7mFSgxIEDAjn6DxTfW4=.732c6cb4-7044-4561-821c-6ca63f9768a7@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <MlC0k95KyLxJCu7ZSluQlSdVrGTPolMjYG_rX3lpebU=.9ccf1fac-6fec-4479-80d7-9ee89d3bbb54@github.com>
 <x0F1vjGptkr-cbJzQ-3bS5zX7mFSgxIEDAjn6DxTfW4=.732c6cb4-7044-4561-821c-6ca63f9768a7@github.com>
Message-ID: <cJ0oJULLMQqSzHz-xHWMiJrivyH59QxUI2UQTN0PrdE=.77b688e8-52f1-4207-be64-3393922ecdb6@github.com>

On Fri, 5 Feb 2021 17:20:55 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/vm_version_aarch64.hpp line 93:
>> 
>>> 91:     CPU_MARVELL   = 'V',
>>> 92:     CPU_INTEL     = 'i',
>>> 93:     CPU_APPLE     = 'a',
>> 
>> The `ARM Architecture Reference Manual ARMv8, for ARMv8-A architecture profile` has 8538 pages, can we be more specific and point to the particular section of the document where the CPU codes are defined?
>
> They are defined in 13.2.95. MIDR_EL1, Main ID Register. Apple's code is not there, but "Arm can assign codes that are not published in this manual. All values not assigned by Arm are reserved and must not be used.". I assume the value was obtained by digging around https://github.com/apple/darwin-xnu/blob/main/osfmk/arm/cpuid.h#L62

Anton, this paragraph looks like an excellent comment.

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

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

From aph at openjdk.java.net  Mon Mar  1 11:09:58 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 1 Mar 2021 11:09:58 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
In-Reply-To: <hwBUUi7NHd91Sc9fpH0hTqLXvp2H8ax9-YGqCo4fC2g=.bb995b11-1795-42e8-8a9a-d95406ed8513@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
 <9Nasu4m7orJoGYjX4EYCuz5-aevYNno3Ru3jPHgwkvc=.168cfdf0-648b-46e4-9cb4-b24956eeba7d@github.com>
 <hwBUUi7NHd91Sc9fpH0hTqLXvp2H8ax9-YGqCo4fC2g=.bb995b11-1795-42e8-8a9a-d95406ed8513@github.com>
Message-ID: <wl_FMfr8IuW0pM6APkV36vyWvmy4bsdaoSgWHA-yMmo=.d4ecb78c-e199-4e1c-9215-d68e2d25bc15@github.com>

On Fri, 12 Feb 2021 11:42:59 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 194:
>> 
>>> 192: // may get turned off by -fomit-frame-pointer.
>>> 193: frame os::get_sender_for_C_frame(frame* fr) {
>>> 194:   return frame(fr->link(), fr->link(), fr->sender_pc());
>> 
>> Why is it
>> 
>> return frame(fr->link(), fr->link(), fr->sender_pc());
>> 
>> and not 
>> 
>> return frame(fr->sender_sp(), fr->link(), fr->sender_pc());
>> 
>> like in the bsd-x86 counter part?
>
> bsd_aarcb64 was based on linux_aarch64, with addition of bsd-specific things from bsd_x86
> You think  the bsd-x86 way is better here ?

There's no point copying x86. We don't have any way to know what the sender's SP was in a C frame without using unwind info. I think this is just used when trying to print the stack in a crash dump.

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

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

From sgehwolf at openjdk.java.net  Mon Mar  1 13:10:49 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 1 Mar 2021 13:10:49 GMT
Subject: RFR: 8262379: Add regression test for JDK-8257746
In-Reply-To: <bePB-zu9tc6Pp6B_wqVakmQ_Ouh5iDJSdKyO4sWLDFQ=.78bdb2de-9d5a-47c6-8679-b1ac9304e3d4@github.com>
References: <bePB-zu9tc6Pp6B_wqVakmQ_Ouh5iDJSdKyO4sWLDFQ=.78bdb2de-9d5a-47c6-8679-b1ac9304e3d4@github.com>
Message-ID: <T7U47gw9i7gi4zcdrEs0oQXOeV_A5QePU-MiPhFrBmg=.783e23ff-8dc7-48ba-87a8-fd0c2c8c732d@github.com>

On Thu, 25 Feb 2021 16:27:20 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Fails prior the patch of JDK-8257746, passes after. As expected.
> 
> Thoughts?

@poonamparhar @hseigel Could you please take a look? It's just a simple regression test for the JDK-8257746 NPE regression.

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

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

From hseigel at openjdk.java.net  Mon Mar  1 14:35:50 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 1 Mar 2021 14:35:50 GMT
Subject: RFR: 8262379: Add regression test for JDK-8257746
In-Reply-To: <bePB-zu9tc6Pp6B_wqVakmQ_Ouh5iDJSdKyO4sWLDFQ=.78bdb2de-9d5a-47c6-8679-b1ac9304e3d4@github.com>
References: <bePB-zu9tc6Pp6B_wqVakmQ_Ouh5iDJSdKyO4sWLDFQ=.78bdb2de-9d5a-47c6-8679-b1ac9304e3d4@github.com>
Message-ID: <13E-0hnjHJ7_Ht5ZQIyKK0sybjCByABA1qM4dVJsj-k=.2f406244-5e05-44b5-8f76-629689e937b7@github.com>

On Thu, 25 Feb 2021 16:27:20 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Fails prior the patch of JDK-8257746, passes after. As expected.
> 
> Thoughts?

The new tests looks good.  Thanks for adding it.

Harold

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

Marked as reviewed by hseigel (Reviewer).

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

From ysuenaga at openjdk.java.net  Mon Mar  1 15:12:15 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Mon, 1 Mar 2021 15:12:15 GMT
Subject: RFR: 8262520: Add CLHSDB command to connect to debug server
Message-ID: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>

`attach` command on CLHSDB supports to attach live process (PID) and coredump, but it cannot connect to debug server. CLHSDB does not have a command to connect to debug server.

Other jhsdb commands (jstack, jmap, etc...) can connect debug server via `--connect` option, so CLHSDB should connect to it.

After this change, you can connect to debug server with 'connect <hostname>'.

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

Commit messages:
 - Skip ClhsdbConnect.java if it runs on OS X and the user is not root
 - 8262520: Add CLHSDB command to connect to debug server

Changes: https://git.openjdk.java.net/jdk/pull/2773/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2773&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262520
  Stats: 138 lines in 4 files changed: 133 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2773.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2773/head:pull/2773

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

From sgehwolf at openjdk.java.net  Mon Mar  1 15:17:41 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 1 Mar 2021 15:17:41 GMT
Subject: Integrated: 8262379: Add regression test for JDK-8257746
In-Reply-To: <bePB-zu9tc6Pp6B_wqVakmQ_Ouh5iDJSdKyO4sWLDFQ=.78bdb2de-9d5a-47c6-8679-b1ac9304e3d4@github.com>
References: <bePB-zu9tc6Pp6B_wqVakmQ_Ouh5iDJSdKyO4sWLDFQ=.78bdb2de-9d5a-47c6-8679-b1ac9304e3d4@github.com>
Message-ID: <eOp38fWBGGldQljcHA9k9IvXok93lgqJ8R3qfYfa1No=.8002ac61-6283-4111-8de4-ca44ea6d20c4@github.com>

On Thu, 25 Feb 2021 16:27:20 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Fails prior the patch of JDK-8257746, passes after. As expected.
> 
> Thoughts?

This pull request has now been integrated.

Changeset: 4c9adce2
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4c9adce2
Stats:     56 lines in 1 file changed: 56 ins; 0 del; 0 mod

8262379: Add regression test for JDK-8257746

Reviewed-by: hseigel

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

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

From sgehwolf at openjdk.java.net  Mon Mar  1 15:17:40 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 1 Mar 2021 15:17:40 GMT
Subject: RFR: 8262379: Add regression test for JDK-8257746
In-Reply-To: <13E-0hnjHJ7_Ht5ZQIyKK0sybjCByABA1qM4dVJsj-k=.2f406244-5e05-44b5-8f76-629689e937b7@github.com>
References: <bePB-zu9tc6Pp6B_wqVakmQ_Ouh5iDJSdKyO4sWLDFQ=.78bdb2de-9d5a-47c6-8679-b1ac9304e3d4@github.com>
 <13E-0hnjHJ7_Ht5ZQIyKK0sybjCByABA1qM4dVJsj-k=.2f406244-5e05-44b5-8f76-629689e937b7@github.com>
Message-ID: <LYZLXzeqIBMqd25j-Ors4Qmqv4XrD_ma4hpj4xzJC2k=.8faf6737-d09a-4acd-bf96-337dec49b594@github.com>

On Mon, 1 Mar 2021 14:33:06 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Fails prior the patch of JDK-8257746, passes after. As expected.
>> 
>> Thoughts?
>
> The new tests looks good.  Thanks for adding it.
> 
> Harold

Thanks for the review @hseigel!

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

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

From cjplummer at openjdk.java.net  Mon Mar  1 21:09:42 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 1 Mar 2021 21:09:42 GMT
Subject: RFR: 8262520: Add CLHSDB command to connect to debug server
In-Reply-To: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
References: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
Message-ID: <z7R8_jRqJ71PDNbgwWKL3wsP2A_NP2VIeUKnH4T12DQ=.fced5fab-d274-404a-b43c-eb7e8a56e3e2@github.com>

On Mon, 1 Mar 2021 07:31:04 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> `attach` command on CLHSDB supports to attach live process (PID) and coredump, but it cannot connect to debug server. CLHSDB does not have a command to connect to debug server.
> 
> Other jhsdb commands (jstack, jmap, etc...) can connect debug server via `--connect` option, so CLHSDB should connect to it.
> 
> After this change, you can connect to debug server with 'connect <hostname>'.

You'll need a CSR for this.

Will `jhsdb clhsdb --connect debugserver` work? If not, it should to be consistent with the other commands.

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

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

From dholmes at openjdk.java.net  Mon Mar  1 22:56:48 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 1 Mar 2021 22:56:48 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v8]
In-Reply-To: <Z3iZ5HHZ218wy3Wk3U3ibFcZXBrPNR_PbhWOKzY49_Y=.74607f8c-98e4-4d27-92a1-9a79f8d2b418@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <Ul6OJXuqVlRZxy7OxB0SRre44bZaZAg7e757hdZf34A=.37ac8cdd-c438-436b-9f84-6176f329b735@github.com>
 <QcbLrMYdiIMrl_SYwODciobnpte2ttg27-RAg3cx52E=.c40c4fcc-ce88-4e2b-8d92-2e263f118015@github.com>
 <Z3iZ5HHZ218wy3Wk3U3ibFcZXBrPNR_PbhWOKzY49_Y=.74607f8c-98e4-4d27-92a1-9a79f8d2b418@github.com>
Message-ID: <fM-hioJiG7lQuRPHLncKT_dtglOp7n1Ve62GCTrD6po=.80d9aaac-0dcd-4a8c-a40c-c22a73ee50f8@github.com>

On Mon, 1 Mar 2021 08:31:40 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> This looks good to me.
>
> Thank you for your review, Tobias!
> I'll delay integration for a while to give David and Igor a chance to react.

Hi @RealLucy , I didn't do an actual review just made a passing comment.

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

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

From ysuenaga at openjdk.java.net  Mon Mar  1 23:57:41 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Mon, 1 Mar 2021 23:57:41 GMT
Subject: RFR: 8262520: Add CLHSDB command to connect to debug server
In-Reply-To: <z7R8_jRqJ71PDNbgwWKL3wsP2A_NP2VIeUKnH4T12DQ=.fced5fab-d274-404a-b43c-eb7e8a56e3e2@github.com>
References: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
 <z7R8_jRqJ71PDNbgwWKL3wsP2A_NP2VIeUKnH4T12DQ=.fced5fab-d274-404a-b43c-eb7e8a56e3e2@github.com>
Message-ID: <Tr-dQVeONnKanSEWzX5MLCK7hVnDvOR4FtsrkbMMLiw=.5f6f7d35-c356-4af2-8a64-6970ab228e1c@github.com>

On Mon, 1 Mar 2021 21:06:34 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> You'll need a CSR for this.

Ok, I will add it after this discussion ( `coonect` or `attach` )

> Will `jhsdb clhsdb --connect debugserver` work? If not, it should to be consistent with the other commands.

It does not work. CLHSDB and HSDB do not accept '--connect'. I plan to add it after this PR.

> Does `detach` undo the `connect`?

Yes.

> It's not very symetric if we do since we already had `attach` + `detach` and now you added `connect` + `detach`. Since you can `attach` to a pid or a core file, maybe instead of adding `connect` you should just put the debugd support in `attach`.

I thought `connect` command is easy to understand because it is similar with `--connect` option in jhsdb, and also the change is smaller than adding to `attach` because `attach` already has 1 string argument (PID).
I'm not familiar of network, but I concern hostname which is configured by numeric chars only - I'm not sure it is allowed, but [RFC 1123](https://tools.ietf.org/html/rfc1123) allows digit character at the first.

      The syntax of a legal Internet host name was specified in RFC-952
      [DNS:4].  One aspect of host name syntax is hereby changed: the
      restriction on the first character is relaxed to allow either a
      letter or a digit.  Host software MUST support this more liberal
      syntax.

If digit hostname (e.g. 1234) is allowed, we cannot add debugd support to `attach` because we cannot distinguish it is PID or hostname. If so, it is reasonable to add `connect` command for this purpose.

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

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

From amenkov at openjdk.java.net  Tue Mar  2 00:46:41 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 2 Mar 2021 00:46:41 GMT
Subject: RFR: 8253940: com/sun/jdi/JdwpAttachTest.java failed with
 "RuntimeException: ERROR: LingeredApp.startApp was able to attach" [v2]
In-Reply-To: <HbKTNw-y04gUU47FKLdMn_EapfXk_pF1ova7pzt4JiY=.c91bd739-3b40-4681-a93b-a2bb15f971da@github.com>
References: <HBuZ978kLXLgllYPgBTv7q9_L9MWcAxkh3oqzw-EC2Y=.03e5f605-978b-472b-a56d-b280c4645242@github.com>
 <hxbQJ5saY9Matb6No5O-nBHXYiLGj6Ius17Yt4fABhc=.92ee0ccd-01b7-4010-82c3-6308cf043b59@github.com>
 <HbKTNw-y04gUU47FKLdMn_EapfXk_pF1ova7pzt4JiY=.c91bd739-3b40-4681-a93b-a2bb15f971da@github.com>
Message-ID: <t-zfL7UjiK3ncuQeCdFkvzLVfUTgtHALYIPL1c8l53s=.af5930b4-8e5b-41ff-afd7-7c82c29fc048@github.com>

On Sat, 20 Feb 2021 03:05:55 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated per Chris feedback
>
> Marked as reviewed by cjplummer (Reviewer).

Ping. need 2nd reviewer.

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

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

From minqi at openjdk.java.net  Tue Mar  2 05:03:38 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 2 Mar 2021 05:03:38 GMT
Subject: RFR: 8259070: Add jcmd option to dump CDS
In-Reply-To: <vYtu_WYJ_s19-jmj6lxvwsS4025cmF6tX-xkS-kQRqc=.afc0066d-84e2-405d-850f-39b349f96921@github.com>
References: <hwrc1zAz8G180ToL-C3EuUIF-5R17F5Gm1zcPMBpOtE=.e002a377-e0e2-485b-a08e-b63675a9746b@github.com>
 <vYtu_WYJ_s19-jmj6lxvwsS4025cmF6tX-xkS-kQRqc=.afc0066d-84e2-405d-850f-39b349f96921@github.com>
Message-ID: <cSKqrhtIT_zLtFqfLXKgEh03aQJsWTMw-_EGUY5nv5E=.9a53d633-544a-4412-b796-416a6eaa5dd3@github.com>

On Fri, 26 Feb 2021 22:05:06 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Hi, Please review
>> 
>>   Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with
>>   `java -XX:DumpLoadedClassList=<classlist> .... `  
>>  to collect shareable class names and saved in file `<classlist>` , then 
>>   `java -Xshare:dump -XX:SharedClassListFile=<classlist> -XX:SharedArchiveFile=<archivefile> ...`
>>   With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime  to dump an archive.
>>    The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved.
>>    New added jcmd option:
>>    `jcmd <pid or AppName> VM.cds static_dump <filename>`
>>    or
>>     `jcmd <pid or AppName> VM.cds dynamic_dump <filename>`
>>   To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. 
>>    The file name is optional, if the file name is not supplied, the file name will take format of `java_pid<number>_static.jsa` or `java_pid<number>_dynamic.jsa` for static and dynamic respectively. The `<number>` is the application process ID.
>> 
>>   Tests: tier1,tier2,tier3,tier4
>> 
>> Thanks
>> Yumin
>
> Below are my comments...

@calvinccheung @iklam @tstuefe Thanks for review! I will use CDS.java to implement the dumping for next update. This way, we deal with CDS related code in a central place. Also using Runtime.exec will clear your concern, plus the code will be more readable though it will add some bridge functions between java/vm.

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

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

From cjplummer at openjdk.java.net  Tue Mar  2 05:21:53 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 2 Mar 2021 05:21:53 GMT
Subject: RFR: 8262520: Add CLHSDB command to connect to debug server
In-Reply-To: <Tr-dQVeONnKanSEWzX5MLCK7hVnDvOR4FtsrkbMMLiw=.5f6f7d35-c356-4af2-8a64-6970ab228e1c@github.com>
References: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
 <z7R8_jRqJ71PDNbgwWKL3wsP2A_NP2VIeUKnH4T12DQ=.fced5fab-d274-404a-b43c-eb7e8a56e3e2@github.com>
 <Tr-dQVeONnKanSEWzX5MLCK7hVnDvOR4FtsrkbMMLiw=.5f6f7d35-c356-4af2-8a64-6970ab228e1c@github.com>
Message-ID: <CSHn46AK1J01TEhFAzgVFd4ocl6bph_sMXB1VqJhUN4=.18231ee9-c257-4a8c-8486-0117a7196b2f@github.com>

On Mon, 1 Mar 2021 23:55:18 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> You'll need a CSR for this.
>> 
>> Will `jhsdb clhsdb --connect debugserver` work? If not, it should to be consistent with the other commands.
>> 
>> Does `detach` undo the `connect`? It's not very symetric if we do since we already had `attach` + `detach` and now you added `connect` + `detach`. Since you can `attach` to a pid or a core file, maybe instead of adding `connect` you should just put the debugd support in `attach`.
>
>> You'll need a CSR for this.
> 
> Ok, I will add it after this discussion ( `coonect` or `attach` )
> 
>> Will `jhsdb clhsdb --connect debugserver` work? If not, it should to be consistent with the other commands.
> 
> It does not work. CLHSDB and HSDB do not accept '--connect'. I plan to add it after this PR.
> 
>> Does `detach` undo the `connect`?
> 
> Yes.
> 
>> It's not very symetric if we do since we already had `attach` + `detach` and now you added `connect` + `detach`. Since you can `attach` to a pid or a core file, maybe instead of adding `connect` you should just put the debugd support in `attach`.
> 
> I thought `connect` command is easy to understand because it is similar with `--connect` option in jhsdb, and also the change is smaller than adding to `attach` because `attach` already has 1 string argument (PID).
> I'm not familiar of network, but I concern hostname which is configured by numeric chars only - I'm not sure it is allowed, but [RFC 1123](https://tools.ietf.org/html/rfc1123) allows digit character at the first.
> 
>       The syntax of a legal Internet host name was specified in RFC-952
>       [DNS:4].  One aspect of host name syntax is hereby changed: the
>       restriction on the first character is relaxed to allow either a
>       letter or a digit.  Host software MUST support this more liberal
>       syntax.
> 
> If digit hostname (e.g. 1234) is allowed, we cannot add debugd support to `attach` because we cannot distinguish it is PID or hostname. If so, it is reasonable to add `connect` command for this purpose.

`jhsdb` has `--pid`, `--core`, and `--connect` as the 3 ways to "attach" for lack of a better word. It would have been nice if the clhsdb command did a better job of copying these three command line arguments. You are suggesting that adding a `connect` command would have similarity to the `--connect` option, but unfortunately the `attach` command has no such similarity with the command line arguments `--pid` and `--core`, so I'm not so sure doing so with `connect` is actually helping in that regard, especially when "connect" and "attach" pretty much mean the same thing.

As for numeric host names, yes, that is possible, but then you could also have a numeric core file name. If we really want to avoid the numeric host name problem, perhaps something like `attachd` would be better than `connect`, but it seems any choice we make will have it's drawbacks due the the baggage of existing commands and options.

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

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

From ysuenaga at openjdk.java.net  Tue Mar  2 06:59:40 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 2 Mar 2021 06:59:40 GMT
Subject: Integrated: 8261710: SA DSO objects have sizes that are too large
In-Reply-To: <rtxSvuvKLmHKrLtsnxf76vSK41b_HWPR_7Bn3wf9YuM=.cf1b54ae-f01d-48d5-9641-d7d9faa541f5@github.com>
References: <rtxSvuvKLmHKrLtsnxf76vSK41b_HWPR_7Bn3wf9YuM=.cf1b54ae-f01d-48d5-9641-d7d9faa541f5@github.com>
Message-ID: <WJHfymgbGLjDBjsDAoX4KxA1rerx-SdPhinjgdcKNrI=.e2621559-65a1-41d7-b587-42c375d416a5@github.com>

On Sun, 14 Feb 2021 07:14:24 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> This PR relates to [JDK-8261702](https://bugs.openjdk.java.net/browse/JDK-8261702) ( #2562 )
> When SA creates a DSO object, which is used to represent a shared object file (.so), it initializes the "size" to be the size of the shared object file. This usually results in the size being too big. This can cause SA to get confused about whether or not an address is in the shared object. SA should instead set the DSO's size to the amount of the file that is actually mapped for executable code.

This pull request has now been integrated.

Changeset: 3b350ad8
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3b350ad8
Stats:     95 lines in 9 files changed: 56 ins; 13 del; 26 mod

8261710: SA DSO objects have sizes that are too large

Reviewed-by: sspitsyn, cjplummer

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

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

From ysuenaga at openjdk.java.net  Tue Mar  2 07:14:58 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 2 Mar 2021 07:14:58 GMT
Subject: RFR: 8262520: Add CLHSDB command to connect to debug server
In-Reply-To: <CSHn46AK1J01TEhFAzgVFd4ocl6bph_sMXB1VqJhUN4=.18231ee9-c257-4a8c-8486-0117a7196b2f@github.com>
References: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
 <z7R8_jRqJ71PDNbgwWKL3wsP2A_NP2VIeUKnH4T12DQ=.fced5fab-d274-404a-b43c-eb7e8a56e3e2@github.com>
 <Tr-dQVeONnKanSEWzX5MLCK7hVnDvOR4FtsrkbMMLiw=.5f6f7d35-c356-4af2-8a64-6970ab228e1c@github.com>
 <CSHn46AK1J01TEhFAzgVFd4ocl6bph_sMXB1VqJhUN4=.18231ee9-c257-4a8c-8486-0117a7196b2f@github.com>
Message-ID: <LIj9n09Uf_xAa7BjFXJnIUSTQ84Q9XeVaWSL5QkS6Tg=.1cbd3cea-c51e-4b23-bf12-43b3a5fd3587@github.com>

On Tue, 2 Mar 2021 05:18:51 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>>> You'll need a CSR for this.
>> 
>> Ok, I will add it after this discussion ( `coonect` or `attach` )
>> 
>>> Will `jhsdb clhsdb --connect debugserver` work? If not, it should to be consistent with the other commands.
>> 
>> It does not work. CLHSDB and HSDB do not accept '--connect'. I plan to add it after this PR.
>> 
>>> Does `detach` undo the `connect`?
>> 
>> Yes.
>> 
>>> It's not very symetric if we do since we already had `attach` + `detach` and now you added `connect` + `detach`. Since you can `attach` to a pid or a core file, maybe instead of adding `connect` you should just put the debugd support in `attach`.
>> 
>> I thought `connect` command is easy to understand because it is similar with `--connect` option in jhsdb, and also the change is smaller than adding to `attach` because `attach` already has 1 string argument (PID).
>> I'm not familiar of network, but I concern hostname which is configured by numeric chars only - I'm not sure it is allowed, but [RFC 1123](https://tools.ietf.org/html/rfc1123) allows digit character at the first.
>> 
>>       The syntax of a legal Internet host name was specified in RFC-952
>>       [DNS:4].  One aspect of host name syntax is hereby changed: the
>>       restriction on the first character is relaxed to allow either a
>>       letter or a digit.  Host software MUST support this more liberal
>>       syntax.
>> 
>> If digit hostname (e.g. 1234) is allowed, we cannot add debugd support to `attach` because we cannot distinguish it is PID or hostname. If so, it is reasonable to add `connect` command for this purpose.
>
> `jhsdb` has `--pid`, `--core`, and `--connect` as the 3 ways to "attach" for lack of a better word. It would have been nice if the clhsdb command did a better job of copying these three command line arguments. You are suggesting that adding a `connect` command would have similarity to the `--connect` option, but unfortunately the `attach` command has no such similarity with the command line arguments `--pid` and `--core`, so I'm not so sure doing so with `connect` is actually helping in that regard, especially when "connect" and "attach" pretty much mean the same thing.
> 
> As for numeric host names, yes, that is possible, but then you could also have a numeric core file name. If we really want to avoid the numeric host name problem, perhaps something like `attachd` would be better than `connect`, but it seems any choice we make will have it's drawbacks due the the baggage of existing commands and options.

@plummercj Ok, I try to add debug server support to `attach` clhsdb command. Then should we still need CSR?

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

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

From akozlov at openjdk.java.net  Tue Mar  2 07:48:33 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 07:48:33 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v22]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <v5pZx2-cL7w14ww7AUj0-aM3H0WLtdE9KQOMcmz3oXM=.de608aec-285e-420c-a0bd-87ff2621366a@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  Update comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/663cb4a1..e42b82db

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=21
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=20-21

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

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

From akozlov at openjdk.java.net  Tue Mar  2 07:48:34 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 07:48:34 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <cJ0oJULLMQqSzHz-xHWMiJrivyH59QxUI2UQTN0PrdE=.77b688e8-52f1-4207-be64-3393922ecdb6@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <MlC0k95KyLxJCu7ZSluQlSdVrGTPolMjYG_rX3lpebU=.9ccf1fac-6fec-4479-80d7-9ee89d3bbb54@github.com>
 <x0F1vjGptkr-cbJzQ-3bS5zX7mFSgxIEDAjn6DxTfW4=.732c6cb4-7044-4561-821c-6ca63f9768a7@github.com>
 <cJ0oJULLMQqSzHz-xHWMiJrivyH59QxUI2UQTN0PrdE=.77b688e8-52f1-4207-be64-3393922ecdb6@github.com>
Message-ID: <M-kUXnyeRkWZF8-CcGTlKqCGerC7BpZ4KUFKbPEm9Dw=.0692eac6-4803-4110-b46b-0658cd0b10cd@github.com>

On Mon, 1 Mar 2021 10:46:34 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> They are defined in 13.2.95. MIDR_EL1, Main ID Register. Apple's code is not there, but "Arm can assign codes that are not published in this manual. All values not assigned by Arm are reserved and must not be used.". I assume the value was obtained by digging around https://github.com/apple/darwin-xnu/blob/main/osfmk/arm/cpuid.h#L62
>
> Anton, this paragraph looks like an excellent comment.

Thanks, I've added the comment.

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

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

From akozlov at openjdk.java.net  Tue Mar  2 07:48:36 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 07:48:36 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <MF1iA9imUPiz__P2Xgl06D6uqX6m3yi5_LkRtVy0yYA=.985a8d8e-d585-4ca1-8c27-3752dc4f297a@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <MF1iA9imUPiz__P2Xgl06D6uqX6m3yi5_LkRtVy0yYA=.985a8d8e-d585-4ca1-8c27-3752dc4f297a@github.com>
Message-ID: <NMDh28nN07b-L4FvOo_lZSVr6WTbMjQtwXB4uOpbRgU=.e025620b-bb0e-4f81-aea4-7c023a268161@github.com>

On Mon, 15 Feb 2021 17:59:54 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 810:
>> 
>>> 808: #ifdef __APPLE__
>>> 809:           // Less-than word types are stored one after another.
>>> 810:           // The code unable to handle this, bailout.
>> 
>> Perhaps:  // The code is unable to handle this so bailout.
>
> Hello, we have updated PR, now this bailout is used only by the code which can handle it (native wrapper generator), for the rest it will cause guarantee failed if this bailout is triggered

I've fixed the spelling. Sorry for it to take so long :(

>> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 195:
>> 
>>> 193: frame os::get_sender_for_C_frame(frame* fr) {
>>> 194:   return frame(fr->link(), fr->link(), fr->sender_pc());
>>> 195: }
>> 
>> Is this file going to be built by GCC or just macOS compilers?
>
> there is no support for compiling java with gcc on macos since about jdk11, only clang.
> considering this and the absence of gcc for macos_m1, the answer is - just macOS compilers.

I've fixed the comment. Now it states `JVM compiled with -fno-omit-frame-pointer, so RFP is saved on the stack.`

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

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

From akozlov at openjdk.java.net  Tue Mar  2 08:06:49 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 08:06:49 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <gYlruHfPt3n_2sFsFzadoB-H9J1sZJQsspB9AjKeO2o=.ca9e5f03-7181-42cb-b2d9-4f3490f05235@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <WI3MFWpvxNdYp4WRkhkagyWSmnIIAfvYWl3nS8AW_Y0=.b09073dd-cec3-4dbd-88c4-974d46b01737@github.com>
 <gYlruHfPt3n_2sFsFzadoB-H9J1sZJQsspB9AjKeO2o=.ca9e5f03-7181-42cb-b2d9-4f3490f05235@github.com>
Message-ID: <UNXam2gyH9Z3bgNClVHc956LquoEu1KkZ-89DQpu4ZE=.5a71445d-0dbd-4ae9-8fe8-0e279cb7fc61@github.com>

On Fri, 12 Feb 2021 12:40:09 GMT, Florian Weimer <fweimer at openjdk.org> wrote:

>> only macos comiplers
>
> The comment is also wrong for glibc: The AArch64 ABI requires a 64 KiB guard region independently of page size, otherwise `-fstack-clash-protection` is not reliable.

Thanks, I deleted the comment. It describes implementation distinguishing initial and regular thread http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/548cb3b7b713#l12.7. I'm not sure why the comment was preserved for the bsd_x86, but I don't think it makes sense here.

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

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

From akozlov at openjdk.java.net  Tue Mar  2 08:14:46 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 08:14:46 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <Ymv3QSLaT5H6CuKXfwuUkep_PKnO3Zj54kSQA0jcc6s=.59dc4d6d-a8d0-4016-8a59-a4d6cb8b57ac@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <Ymv3QSLaT5H6CuKXfwuUkep_PKnO3Zj54kSQA0jcc6s=.59dc4d6d-a8d0-4016-8a59-a4d6cb8b57ac@github.com>
Message-ID: <Ei8n5Xqt_Usrtyz-M4AudO6fuOV30FTSG6BCpNXUa2w=.fe6928be-256e-4448-b094-1f7c869e4b26@github.com>

On Fri, 12 Feb 2021 13:32:52 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 486:
>> 
>>> 484:         }
>>> 485:       }
>>> 486:     }
>> 
>> This appears to be a mix for Mavericks (10.9) and 10.12
>> work arounds. Is this code needed by this project?
>
> I wasn't able to replicate JDK-8020753 and JDK-8186286. So will remove these workaround
> @gerard-ziemski, 8020753 was originally your fix, do you know if it still needed on intel-mac ?

The x86_bsd still carries the workaround https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp#L745. It's worth having macos ports to be aligned by features. I would propose to have this workaround for now, and decide on it later for macos/x86 and macos/aarch64 at once. Sorry for chiming in so late.

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

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

From ysuenaga at openjdk.java.net  Tue Mar  2 08:33:23 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 2 Mar 2021 08:33:23 GMT
Subject: RFR: 8262520: Add CLHSDB command to connect to debug server [v2]
In-Reply-To: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
References: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
Message-ID: <-RzHIDOhgyrkwn28lOfAnPmFpUbKN6OvlEQ71bSCFto=.29a04285-4a84-426a-9ff5-41cc691af2cd@github.com>

> `attach` command on CLHSDB supports to attach live process (PID) and coredump, but it cannot connect to debug server. CLHSDB does not have a command to connect to debug server.
> 
> Other jhsdb commands (jstack, jmap, etc...) can connect debug server via `--connect` option, so CLHSDB should connect to it.
> 
> After this change, you can connect to debug server with 'connect <hostname>'.

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Implement as "attach" instead of "connect"

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2773/files
  - new: https://git.openjdk.java.net/jdk/pull/2773/files/7e86add8..e59bb9c7

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

  Stats: 101 lines in 5 files changed: 35 ins; 25 del; 41 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2773.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2773/head:pull/2773

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

From ysuenaga at openjdk.java.net  Tue Mar  2 08:33:24 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 2 Mar 2021 08:33:24 GMT
Subject: RFR: 8262520: Add CLHSDB command to connect to debug server
In-Reply-To: <CSHn46AK1J01TEhFAzgVFd4ocl6bph_sMXB1VqJhUN4=.18231ee9-c257-4a8c-8486-0117a7196b2f@github.com>
References: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
 <z7R8_jRqJ71PDNbgwWKL3wsP2A_NP2VIeUKnH4T12DQ=.fced5fab-d274-404a-b43c-eb7e8a56e3e2@github.com>
 <Tr-dQVeONnKanSEWzX5MLCK7hVnDvOR4FtsrkbMMLiw=.5f6f7d35-c356-4af2-8a64-6970ab228e1c@github.com>
 <CSHn46AK1J01TEhFAzgVFd4ocl6bph_sMXB1VqJhUN4=.18231ee9-c257-4a8c-8486-0117a7196b2f@github.com>
Message-ID: <SbSowq5qCjDjIoM3Iv0xR2FrsS4oQ-nIVPk45V51WM4=.e9ed878d-c86a-438f-b566-16dc2c3c0d2e@github.com>

On Tue, 2 Mar 2021 05:18:51 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>>> You'll need a CSR for this.
>> 
>> Ok, I will add it after this discussion ( `coonect` or `attach` )
>> 
>>> Will `jhsdb clhsdb --connect debugserver` work? If not, it should to be consistent with the other commands.
>> 
>> It does not work. CLHSDB and HSDB do not accept '--connect'. I plan to add it after this PR.
>> 
>>> Does `detach` undo the `connect`?
>> 
>> Yes.
>> 
>>> It's not very symetric if we do since we already had `attach` + `detach` and now you added `connect` + `detach`. Since you can `attach` to a pid or a core file, maybe instead of adding `connect` you should just put the debugd support in `attach`.
>> 
>> I thought `connect` command is easy to understand because it is similar with `--connect` option in jhsdb, and also the change is smaller than adding to `attach` because `attach` already has 1 string argument (PID).
>> I'm not familiar of network, but I concern hostname which is configured by numeric chars only - I'm not sure it is allowed, but [RFC 1123](https://tools.ietf.org/html/rfc1123) allows digit character at the first.
>> 
>>       The syntax of a legal Internet host name was specified in RFC-952
>>       [DNS:4].  One aspect of host name syntax is hereby changed: the
>>       restriction on the first character is relaxed to allow either a
>>       letter or a digit.  Host software MUST support this more liberal
>>       syntax.
>> 
>> If digit hostname (e.g. 1234) is allowed, we cannot add debugd support to `attach` because we cannot distinguish it is PID or hostname. If so, it is reasonable to add `connect` command for this purpose.
>
> `jhsdb` has `--pid`, `--core`, and `--connect` as the 3 ways to "attach" for lack of a better word. It would have been nice if the clhsdb command did a better job of copying these three command line arguments. You are suggesting that adding a `connect` command would have similarity to the `--connect` option, but unfortunately the `attach` command has no such similarity with the command line arguments `--pid` and `--core`, so I'm not so sure doing so with `connect` is actually helping in that regard, especially when "connect" and "attach" pretty much mean the same thing.
> 
> As for numeric host names, yes, that is possible, but then you could also have a numeric core file name. If we really want to avoid the numeric host name problem, perhaps something like `attachd` would be better than `connect`, but it seems any choice we make will have it's drawbacks due the the baggage of existing commands and options.

> @plummercj Ok, I try to add debug server support to `attach` clhsdb command. Then should we still need CSR?

Pushed new commit to be implemented as `attach`. It works fine with serviceability/sa jtreg tests on my Linux x64.
I will add CSR if you are ok.

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

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

From lucy at openjdk.java.net  Tue Mar  2 08:37:50 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Tue, 2 Mar 2021 08:37:50 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v8]
In-Reply-To: <fM-hioJiG7lQuRPHLncKT_dtglOp7n1Ve62GCTrD6po=.80d9aaac-0dcd-4a8c-a40c-c22a73ee50f8@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <Ul6OJXuqVlRZxy7OxB0SRre44bZaZAg7e757hdZf34A=.37ac8cdd-c438-436b-9f84-6176f329b735@github.com>
 <QcbLrMYdiIMrl_SYwODciobnpte2ttg27-RAg3cx52E=.c40c4fcc-ce88-4e2b-8d92-2e263f118015@github.com>
 <Z3iZ5HHZ218wy3Wk3U3ibFcZXBrPNR_PbhWOKzY49_Y=.74607f8c-98e4-4d27-92a1-9a79f8d2b418@github.com>
 <fM-hioJiG7lQuRPHLncKT_dtglOp7n1Ve62GCTrD6po=.80d9aaac-0dcd-4a8c-a40c-c22a73ee50f8@github.com>
Message-ID: <YNnTcpzHGGXrLkHd_KoctjHUc62dLdAHoeJvDqQFulc=.585f52b3-e931-4c94-a05a-bc2920c772cf@github.com>

On Mon, 1 Mar 2021 22:54:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thank you for your review, Tobias!
>> I'll delay integration for a while to give David and Igor a chance to react.
>
> Hi @RealLucy , I didn't do an actual review just made a passing comment.

@dholmes-ora OK then. I just didn't want to ignore anyone's opinion. 
I plan to integrate the change before my EOB (GMT+1), provided there are no objections.

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

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

From akozlov at openjdk.java.net  Tue Mar  2 09:02:10 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 09:02:10 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
Message-ID: <u7KDYpBsS8hE4DIlr86x1XP2jNk2evuzajQr66XXjYI=.e7caf1a7-c841-43aa-95dc-e8b96df309da@github.com>

On Tue, 2 Feb 2021 22:18:43 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   support macos_aarch64 in hsdis
>
> src/hotspot/os_cpu/bsd_aarch64/thread_bsd_aarch64.cpp line 43:
> 
>> 41:   assert(Thread::current() == this, "caller must be current thread");
>> 42:   return pd_get_top_frame(fr_addr, ucontext, isInJava);
>> 43: }
> 
> Is AsyncGetCallTrace() being supported by this port?

I assume answer to be yes (I have a little experience with AsyncGetCallTrace). This code is identical to one in bsd/x86 and linux/aarch64. After few changes in the build system, I got jtreg/serviceability/AsyncGetCallTrace test compiled and passed. I've filed JDK-8262839 to enable the test.

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

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

From akozlov at openjdk.java.net  Tue Mar  2 09:36:51 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 09:36:51 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
Message-ID: <0dfmwagb4EGbnQnZIzpQ_36c9_fpvvebrgnKDW4E9Ps=.e54e9fb2-7500-40d8-8202-ce4903fd106f@github.com>

On Tue, 2 Feb 2021 22:47:04 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   support macos_aarch64 in hsdis
>
> src/hotspot/share/prims/nativeEntryPoint.cpp line 45:
> 
>> 43:   guarantee(status == JNI_OK && !env->ExceptionOccurred(),
>> 44:             "register jdk.internal.invoke.NativeEntryPoint natives");
>> 45: JNI_END
> 
> I thought that jcheck caught a missing new-line?

It seems it did not https://github.com/openjdk/jdk/commit/0fb31dbf3a2adc0f7fb2f9924083908724dcde5a#diff-f39cd3f794a337734adf30863f702725ee04182fee2345b2669e59ebed17a2ccR44. Anyway I reverted this change as it is the only change in the file, thanks.

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

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

From akozlov at openjdk.java.net  Tue Mar  2 11:07:56 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 11:07:56 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
Message-ID: <WlU-by8oEfoJIVOKjkhNLCPUuW4DdRMAFIO6PWIPzb4=.cbc4742c-d113-4d20-b5f3-9a42655f9b86@github.com>

On Tue, 2 Feb 2021 23:10:17 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> For platform files that were copied from other ports to this port, if the file wasn't
> changed I presume the copyright years are left alone. If the file required changes
> for this port, I expect the year to be updated to 2021. How are you verifying that
> these copyright years are being properly managed on the new files?

There are no exact copies, based on
git -c diff.renameLimit=10000000 diff --find-copies-harder -C75% --name-status upstream/master...

So every file changed in the branch potentially needs the copyright update. All file diffs are not trivial, IMHO.

I'll run the copyright update after we fix a few remaining issues with the PR, to avoid updating copyright and changing/reverting the actual content.

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

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

From kevinw at openjdk.java.net  Tue Mar  2 11:41:39 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Tue, 2 Mar 2021 11:41:39 GMT
Subject: RFR: 8262520: Add CLHSDB command to connect to debug server
In-Reply-To: <SbSowq5qCjDjIoM3Iv0xR2FrsS4oQ-nIVPk45V51WM4=.e9ed878d-c86a-438f-b566-16dc2c3c0d2e@github.com>
References: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
 <z7R8_jRqJ71PDNbgwWKL3wsP2A_NP2VIeUKnH4T12DQ=.fced5fab-d274-404a-b43c-eb7e8a56e3e2@github.com>
 <Tr-dQVeONnKanSEWzX5MLCK7hVnDvOR4FtsrkbMMLiw=.5f6f7d35-c356-4af2-8a64-6970ab228e1c@github.com>
 <CSHn46AK1J01TEhFAzgVFd4ocl6bph_sMXB1VqJhUN4=.18231ee9-c257-4a8c-8486-0117a7196b2f@github.com>
 <SbSowq5qCjDjIoM3Iv0xR2FrsS4oQ-nIVPk45V51WM4=.e9ed878d-c86a-438f-b566-16dc2c3c0d2e@github.com>
Message-ID: <NTKNea-dfY-ejLusM9KHBN3P8NOQ3yni64Oc8px2P6Q=.2efde33c-1c85-45f1-919d-de2344eb7fcd@github.com>

On Tue, 2 Mar 2021 08:30:06 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> `jhsdb` has `--pid`, `--core`, and `--connect` as the 3 ways to "attach" for lack of a better word. It would have been nice if the clhsdb command did a better job of copying these three command line arguments. You are suggesting that adding a `connect` command would have similarity to the `--connect` option, but unfortunately the `attach` command has no such similarity with the command line arguments `--pid` and `--core`, so I'm not so sure doing so with `connect` is actually helping in that regard, especially when "connect" and "attach" pretty much mean the same thing.
>> 
>> As for numeric host names, yes, that is possible, but then you could also have a numeric core file name. If we really want to avoid the numeric host name problem, perhaps something like `attachd` would be better than `connect`, but it seems any choice we make will have it's drawbacks due the the baggage of existing commands and options.
>
>> @plummercj Ok, I try to add debug server support to `attach` clhsdb command. Then should we still need CSR?
> 
> Pushed new commit to be implemented as `attach`. It works fine with serviceability/sa jtreg tests on my Linux x64.
> I will add CSR if you are ok.

Hi,
I ran the first version and agree it works, the connect command worked OK when I ran a local, manual test.  But I do like adding to the attach Command rather than connect, avoiding introducing a new Command name.

Assuming an int is a PID like in Tool.java is reasonable.  
You can have a leading numeral since a certain RFC, but although I can't find clear language to say it's definitely illegal, actualy using a fully numeric hostname seems unwise.

CLHSDB.java line 185
Now that "private void attachDebugger(int pid)" takes an int, we don't want to catch NumberFormatException, that try/catch block is not wanted.

In the testcase, I think it will fail if a command throws an Exception, but that is limiting what problems it can detect:
could we make the test check at least some of the key output to show that we are attached and getting information, not errors or something unexpected?  If at least some key commands we issue are checked that they contain some output indicating success that would be great.

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

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

From mbaesken at openjdk.java.net  Tue Mar  2 12:39:54 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 2 Mar 2021 12:39:54 GMT
Subject: RFR: JDK-8262466: linux libsaproc/DwarfParser.cpp delete DwarfParser
 object in early return
Message-ID: <BiateiitsH2blICs1ZAcVYPjzUhXiChtQVtTac6U4-w=.15bcbfc2-be75-4961-b95f-9198fd08e991@github.com>

There is an early return in Java_sun_jvm_hotspot_debugger_linux_amd64_DwarfParser_createDwarfContext that misses to delete the non-parsable parser object.
see also the Sonar finding :
https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=cpp&open=AXck8Ca-BBG2CXpcnimn&resolved=false&severities=BLOCKER&types=BUG

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

Commit messages:
 - JDK-8262466

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

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

From ysuenaga at openjdk.java.net  Tue Mar  2 12:55:04 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 2 Mar 2021 12:55:04 GMT
Subject: RFR: 8262520: Add CLHSDB command to connect to debug server [v3]
In-Reply-To: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
References: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
Message-ID: <WKq-Wmomp8PNGWUKS_Sp6Aa0wYg9mzdkunPrsQKrMK8=.fbfda9d9-f383-4c48-a0ac-d08a37086c27@github.com>

> `attach` command on CLHSDB supports to attach live process (PID) and coredump, but it cannot connect to debug server. CLHSDB does not have a command to connect to debug server.
> 
> Other jhsdb commands (jstack, jmap, etc...) can connect debug server via `--connect` option, so CLHSDB should connect to it.
> 
> After this change, you can connect to debug server with 'connect <hostname>'.

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Fix comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2773/files
  - new: https://git.openjdk.java.net/jdk/pull/2773/files/e59bb9c7..10feed4d

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

  Stats: 29 lines in 3 files changed: 3 ins; 22 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2773.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2773/head:pull/2773

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

From ysuenaga at openjdk.java.net  Tue Mar  2 12:55:04 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 2 Mar 2021 12:55:04 GMT
Subject: RFR: 8262520: Add CLHSDB command to connect to debug server
In-Reply-To: <NTKNea-dfY-ejLusM9KHBN3P8NOQ3yni64Oc8px2P6Q=.2efde33c-1c85-45f1-919d-de2344eb7fcd@github.com>
References: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
 <z7R8_jRqJ71PDNbgwWKL3wsP2A_NP2VIeUKnH4T12DQ=.fced5fab-d274-404a-b43c-eb7e8a56e3e2@github.com>
 <Tr-dQVeONnKanSEWzX5MLCK7hVnDvOR4FtsrkbMMLiw=.5f6f7d35-c356-4af2-8a64-6970ab228e1c@github.com>
 <CSHn46AK1J01TEhFAzgVFd4ocl6bph_sMXB1VqJhUN4=.18231ee9-c257-4a8c-8486-0117a7196b2f@github.com>
 <SbSowq5qCjDjIoM3Iv0xR2FrsS4oQ-nIVPk45V51WM4=.e9ed878d-c86a-438f-b566-16dc2c3c0d2e@github.com>
 <NTKNea-dfY-ejLusM9KHBN3P8NOQ3yni64Oc8px2P6Q=.2efde33c-1c85-45f1-919d-de2344eb7fcd@github.com>
Message-ID: <6nUOChsMl-sDnmoIYOyC6jdCYhO_0XR2WbDb5ZOqYWU=.6046ac00-f052-40ea-9cb3-1715153b810f@github.com>

On Tue, 2 Mar 2021 11:39:10 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>>> @plummercj Ok, I try to add debug server support to `attach` clhsdb command. Then should we still need CSR?
>> 
>> Pushed new commit to be implemented as `attach`. It works fine with serviceability/sa jtreg tests on my Linux x64.
>> I will add CSR if you are ok.
>
> Hi,
> I ran the first version and agree it works, the connect command worked OK when I ran a local, manual test.  But I do like adding to the attach Command rather than connect, avoiding introducing a new Command name.
> 
> Assuming an int is a PID like in Tool.java is reasonable.  
> You can have a leading numeral since a certain RFC, but although I can't find clear language to say it's definitely illegal, actualy using a fully numeric hostname seems unwise.
> 
> CLHSDB.java line 185
> Now that "private void attachDebugger(int pid)" takes an int, we don't want to catch NumberFormatException, that try/catch block is not wanted.
> 
> In the testcase, I think it will fail if a command throws an Exception, but that is limiting what problems it can detect:
> could we make the test check at least some of the key output to show that we are attached and getting information, not errors or something unexpected?  If at least some key commands we issue are checked that they contain some output indicating success that would be great.

Thanks @kevinjwalls !

> CLHSDB.java line 185
> Now that "private void attachDebugger(int pid)" takes an int, we don't want to catch NumberFormatException, that try/catch block is not wanted.

I fixed it in new commit, and also I fixed HSDB.java.

> In the testcase, I think it will fail if a command throws an Exception, but that is limiting what problems it can detect:
> could we make the test check at least some of the key output to show that we are attached and getting information, not errors or something unexpected? If at least some key commands we issue are checked that they contain some output indicating success that would be great.

I added calling `class java.lang.Object` and `class java.lang.String` in testcase. We can check whether the connection works fine through them.

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

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

From akozlov at openjdk.java.net  Tue Mar  2 14:34:51 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 14:34:51 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
In-Reply-To: <hEaFWHE_iOfvoT79PO1tsOkG0IVniyDakQlyH3_t70s=.a0083425-ef18-413b-be61-bfaa1eea8452@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
 <hEaFWHE_iOfvoT79PO1tsOkG0IVniyDakQlyH3_t70s=.a0083425-ef18-413b-be61-bfaa1eea8452@github.com>
Message-ID: <YYxKFpSFJVHj9FIQNUngREmO7aBwrmRWXrx5XIfeiEE=.b59b60c7-435b-4884-9f06-1c3b7c868d84@github.com>

On Thu, 4 Feb 2021 22:15:47 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>>  - Add comments to WX transitions
>>    
>>    + minor change of placements
>>  - Use macro conditionals instead of empty functions
>>  - Add W^X to tests
>>  - Do not require known W^X state
>>  - Revert w^x in gtests
>
> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 322:
> 
>> 320: #ifdef __APPLE__
>> 321:       } else if (sig == SIGFPE && info->si_code == FPE_NOOP) {
>> 322:         Unimplemented();
> 
> Is there a follow up issue for this?

Thanks, this is a leftover from the development phase, it will be removed. In macos/x86, this looks like a workaround. We've never met with this condition and it looks recent darwin kernel should correctly report the cause in si_code: https://github.com/apple/darwin-xnu/blob/33eb9835cd948dbbcdd8741aa52457cbe507c765/bsd/dev/arm/unix_signal.c#L436.

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

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

From ysuenaga at openjdk.java.net  Tue Mar  2 14:59:48 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 2 Mar 2021 14:59:48 GMT
Subject: RFR: JDK-8262466: linux libsaproc/DwarfParser.cpp delete
 DwarfParser object in early return
In-Reply-To: <BiateiitsH2blICs1ZAcVYPjzUhXiChtQVtTac6U4-w=.15bcbfc2-be75-4961-b95f-9198fd08e991@github.com>
References: <BiateiitsH2blICs1ZAcVYPjzUhXiChtQVtTac6U4-w=.15bcbfc2-be75-4961-b95f-9198fd08e991@github.com>
Message-ID: <t64Fr3m3SwlGYAJ66ij6nLGAgZfrkplxJRq79eicXcg=.3c187e4f-18f7-4d65-b50a-2d08ff9ff584@github.com>

On Tue, 2 Mar 2021 12:34:35 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There is an early return in Java_sun_jvm_hotspot_debugger_linux_amd64_DwarfParser_createDwarfContext that misses to delete the non-parsable parser object.
> see also the Sonar finding :
> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=cpp&open=AXck8Ca-BBG2CXpcnimn&resolved=false&severities=BLOCKER&types=BUG

Looks good. Thank you for take this issue!

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

Marked as reviewed by ysuenaga (Reviewer).

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

From kevinw at openjdk.java.net  Tue Mar  2 16:15:40 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Tue, 2 Mar 2021 16:15:40 GMT
Subject: RFR: JDK-8262466: linux libsaproc/DwarfParser.cpp delete
 DwarfParser object in early return
In-Reply-To: <BiateiitsH2blICs1ZAcVYPjzUhXiChtQVtTac6U4-w=.15bcbfc2-be75-4961-b95f-9198fd08e991@github.com>
References: <BiateiitsH2blICs1ZAcVYPjzUhXiChtQVtTac6U4-w=.15bcbfc2-be75-4961-b95f-9198fd08e991@github.com>
Message-ID: <_v0q7bj_AXVZgtcPDdoAo6L3Z4Fc44rrPRVHu2iIcIE=.ea362094-dbb0-49ac-8035-b910b18609d1@github.com>

On Tue, 2 Mar 2021 12:34:35 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There is an early return in Java_sun_jvm_hotspot_debugger_linux_amd64_DwarfParser_createDwarfContext that misses to delete the non-parsable parser object.
> see also the Sonar finding :
> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=cpp&open=AXck8Ca-BBG2CXpcnimn&resolved=false&severities=BLOCKER&types=BUG

Marked as reviewed by kevinw (Committer).

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

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

From iveresov at openjdk.java.net  Tue Mar  2 17:13:01 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Tue, 2 Mar 2021 17:13:01 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v8]
In-Reply-To: <YNnTcpzHGGXrLkHd_KoctjHUc62dLdAHoeJvDqQFulc=.585f52b3-e931-4c94-a05a-bc2920c772cf@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <Ul6OJXuqVlRZxy7OxB0SRre44bZaZAg7e757hdZf34A=.37ac8cdd-c438-436b-9f84-6176f329b735@github.com>
 <QcbLrMYdiIMrl_SYwODciobnpte2ttg27-RAg3cx52E=.c40c4fcc-ce88-4e2b-8d92-2e263f118015@github.com>
 <Z3iZ5HHZ218wy3Wk3U3ibFcZXBrPNR_PbhWOKzY49_Y=.74607f8c-98e4-4d27-92a1-9a79f8d2b418@github.com>
 <fM-hioJiG7lQuRPHLncKT_dtglOp7n1Ve62GCTrD6po=.80d9aaac-0dcd-4a8c-a40c-c22a73ee50f8@github.com>
 <YNnTcpzHGGXrLkHd_KoctjHUc62dLdAHoeJvDqQFulc=.585f52b3-e931-4c94-a05a-bc2920c772cf@github.com>
Message-ID: <MC20c43GlIyyTm98B3ielv7E79A0_JMn8gMjihKeyKY=.220fcc51-a887-4348-9f82-22ef99a2418a@github.com>

On Tue, 2 Mar 2021 08:34:29 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> Hi @RealLucy , I didn't do an actual review just made a passing comment.
>
> @dholmes-ora OK then. I just didn't want to ignore anyone's opinion. 
> I plan to integrate the change before my EOB (GMT+1), provided there are no objections.

I left a comment a while ago about the unsigned int casts (in ```Method::print_invocation_count()```) that I don't understand the reason for. Could you please comment on that?

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

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

From kvn at openjdk.java.net  Tue Mar  2 17:17:49 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 2 Mar 2021 17:17:49 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v8]
In-Reply-To: <Ul6OJXuqVlRZxy7OxB0SRre44bZaZAg7e757hdZf34A=.37ac8cdd-c438-436b-9f84-6176f329b735@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <Ul6OJXuqVlRZxy7OxB0SRre44bZaZAg7e757hdZf34A=.37ac8cdd-c438-436b-9f84-6176f329b735@github.com>
Message-ID: <3mk54i0LQX0awCjtEnYDpf0C9QiCERjP7pOLI6GAvBU=.53cd8ad8-2237-46c9-afa4-72d5f5bbac06@github.com>

On Thu, 25 Feb 2021 09:01:10 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> Dear community,
>> may I please request reviews for this fix, improving the usefulness of method invocation counters.
>> - aggregation counters are retyped as uint64_t, shifting the overflow probability way out (> 500 years in case of a 1 GHz counter update frequency).
>> - counters for individual methods are interpreted as (unsigned int), in contrast to their declaration as int. This gives us a factor of two before the counters overflow.
>> - as a special case, "compiled_invocation_counter" is retyped as long, because it has a higher update frequency than other counters.
>> - before/after sample output is attached to the bug description. 
>> 
>> Thank you!
>> Lutz
>
> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment changes requested by TheRealMDoerr

I have few comments.

src/hotspot/cpu/x86/vtableStubs_x86_32.cpp line 159:

> 157:     return NULL;
> 158:   }
> 159: 

Why you did not update asm instruction to update `nof_megamorphic_calls` in this file?

src/hotspot/share/oops/method.cpp line 530:

> 528: 
> 529:   if (method_data() != NULL) {
> 530:     unsigned int dcc    = (unsigned int)method_data()->decompile_count();

decompile_count() returns `uint` why do cast and why you check decompile_count for overflow? It is very rare updated and limited by `PerMethodRecompilationCutoff` flag (400 by default):
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/oops/methodData.hpp#L2391

src/hotspot/share/oops/method.cpp line 518:

> 516:   // Print a "overflow" notification to create awareness.
> 517:   const char* addMsg;
> 518:   unsigned int maxInt = (1U<<31) - 1;

Why not use INT_MAX?

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

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

From lucy at openjdk.java.net  Tue Mar  2 17:26:42 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Tue, 2 Mar 2021 17:26:42 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v8]
In-Reply-To: <3mk54i0LQX0awCjtEnYDpf0C9QiCERjP7pOLI6GAvBU=.53cd8ad8-2237-46c9-afa4-72d5f5bbac06@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <Ul6OJXuqVlRZxy7OxB0SRre44bZaZAg7e757hdZf34A=.37ac8cdd-c438-436b-9f84-6176f329b735@github.com>
 <3mk54i0LQX0awCjtEnYDpf0C9QiCERjP7pOLI6GAvBU=.53cd8ad8-2237-46c9-afa4-72d5f5bbac06@github.com>
Message-ID: <OxYb19tQQyAWVVy6yAeX7xnGNMf_VGn7XRcy2kfuf4o=.6bdfc879-32f8-44c5-8b71-67dd9f445dad@github.com>

On Tue, 2 Mar 2021 16:34:26 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comment changes requested by TheRealMDoerr
>
> src/hotspot/cpu/x86/vtableStubs_x86_32.cpp line 159:
> 
>> 157:     return NULL;
>> 158:   }
>> 159: 
> 
> Why you did not update asm instruction to update `nof_megamorphic_calls` in this file?

The reason is plain simple: there is no incrementq() for x86_32. I could emulate that with a few lines like
    address ctrAddr = (address)SharedRuntime::nof_megamorphic_calls_addr();
    __ lea(rscratch1, ExternalAddress(ctrAddr));
    __ addl(Address(rscratch1, 0), 1);
    __ adcl(Address(rscratch1, 4), 0);
Not sure if that would be desirable here. Just let me know. As is, the code just updates the less significant half of the 8-byte counter.

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

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

From lucy at openjdk.java.net  Tue Mar  2 17:33:52 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Tue, 2 Mar 2021 17:33:52 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v8]
In-Reply-To: <3mk54i0LQX0awCjtEnYDpf0C9QiCERjP7pOLI6GAvBU=.53cd8ad8-2237-46c9-afa4-72d5f5bbac06@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <Ul6OJXuqVlRZxy7OxB0SRre44bZaZAg7e757hdZf34A=.37ac8cdd-c438-436b-9f84-6176f329b735@github.com>
 <3mk54i0LQX0awCjtEnYDpf0C9QiCERjP7pOLI6GAvBU=.53cd8ad8-2237-46c9-afa4-72d5f5bbac06@github.com>
Message-ID: <VlLH5Vhyn2ky5ulZmGcv0mc35A1myfBsVEc_9idhjUc=.0adc4205-2441-4f41-8fee-5d8d27fc8681@github.com>

On Tue, 2 Mar 2021 16:44:44 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comment changes requested by TheRealMDoerr
>
> src/hotspot/share/oops/method.cpp line 530:
> 
>> 528: 
>> 529:   if (method_data() != NULL) {
>> 530:     unsigned int dcc    = (unsigned int)method_data()->decompile_count();
> 
> decompile_count() returns `uint` why do cast and why you check decompile_count for overflow? It is very rare updated and limited by `PerMethodRecompilationCutoff` flag (400 by default):
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/oops/methodData.hpp#L2391

That uint slipped my attention. And with the cutoff parameter, overflow is no issue. I can remove the cast and the check.

> src/hotspot/share/oops/method.cpp line 518:
> 
>> 516:   // Print a "overflow" notification to create awareness.
>> 517:   const char* addMsg;
>> 518:   unsigned int maxInt = (1U<<31) - 1;
> 
> Why not use INT_MAX?

Will change.

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

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

From lucy at openjdk.java.net  Tue Mar  2 17:37:43 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Tue, 2 Mar 2021 17:37:43 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v8]
In-Reply-To: <3mk54i0LQX0awCjtEnYDpf0C9QiCERjP7pOLI6GAvBU=.53cd8ad8-2237-46c9-afa4-72d5f5bbac06@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <Ul6OJXuqVlRZxy7OxB0SRre44bZaZAg7e757hdZf34A=.37ac8cdd-c438-436b-9f84-6176f329b735@github.com>
 <3mk54i0LQX0awCjtEnYDpf0C9QiCERjP7pOLI6GAvBU=.53cd8ad8-2237-46c9-afa4-72d5f5bbac06@github.com>
Message-ID: <bj1yHHIJVOAklDxq6uDB0zSVwrlFelayw2fd0Gyswyg=.6add799f-ebc4-4f34-9f0c-d2fddd24a23f@github.com>

On Tue, 2 Mar 2021 17:14:34 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comment changes requested by TheRealMDoerr
>
> I have few comments.

@veresov I can't see your comment re. the casts. The only comment I see is re. the *64 suffixes. 
Anyway, is your question/comment directly related to Vladimir's annotations? Or do you need further reasoning? Please let me know.

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

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

From kvn at openjdk.java.net  Tue Mar  2 17:52:45 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 2 Mar 2021 17:52:45 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v8]
In-Reply-To: <OxYb19tQQyAWVVy6yAeX7xnGNMf_VGn7XRcy2kfuf4o=.6bdfc879-32f8-44c5-8b71-67dd9f445dad@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <Ul6OJXuqVlRZxy7OxB0SRre44bZaZAg7e757hdZf34A=.37ac8cdd-c438-436b-9f84-6176f329b735@github.com>
 <3mk54i0LQX0awCjtEnYDpf0C9QiCERjP7pOLI6GAvBU=.53cd8ad8-2237-46c9-afa4-72d5f5bbac06@github.com>
 <OxYb19tQQyAWVVy6yAeX7xnGNMf_VGn7XRcy2kfuf4o=.6bdfc879-32f8-44c5-8b71-67dd9f445dad@github.com>
Message-ID: <biqlAy-3u0GctcrxSbxo0FI33dVfsmkX28iPyEVdQQQ=.800c7193-85ca-46dc-a6f2-bf517f3ea195@github.com>

On Tue, 2 Mar 2021 17:23:23 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> src/hotspot/cpu/x86/vtableStubs_x86_32.cpp line 159:
>> 
>>> 157:     return NULL;
>>> 158:   }
>>> 159: 
>> 
>> Why you did not update asm instruction to update `nof_megamorphic_calls` in this file?
>
> The reason is plain simple: there is no incrementq() for x86_32. I could emulate that with a few lines like
>     address ctrAddr = (address)SharedRuntime::nof_megamorphic_calls_addr();
>     __ lea(rscratch1, ExternalAddress(ctrAddr));
>     __ addl(Address(rscratch1, 0), 1);
>     __ adcl(Address(rscratch1, 4), 0);
> Not sure if that would be desirable here. Just let me know. As is, the code just updates the less significant half of the 8-byte counter.

Okay, let keep as it is. Then revert this file back - the only change is new empty line.

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

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

From iveresov at openjdk.java.net  Tue Mar  2 18:56:55 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Tue, 2 Mar 2021 18:56:55 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v8]
In-Reply-To: <bj1yHHIJVOAklDxq6uDB0zSVwrlFelayw2fd0Gyswyg=.6add799f-ebc4-4f34-9f0c-d2fddd24a23f@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <Ul6OJXuqVlRZxy7OxB0SRre44bZaZAg7e757hdZf34A=.37ac8cdd-c438-436b-9f84-6176f329b735@github.com>
 <3mk54i0LQX0awCjtEnYDpf0C9QiCERjP7pOLI6GAvBU=.53cd8ad8-2237-46c9-afa4-72d5f5bbac06@github.com>
 <bj1yHHIJVOAklDxq6uDB0zSVwrlFelayw2fd0Gyswyg=.6add799f-ebc4-4f34-9f0c-d2fddd24a23f@github.com>
Message-ID: <FsqGKu8fr7eHDlQxBaJYckzOOKf6bLzTIaA4XKlAKGY=.9134e6cf-03f3-41f8-bb05-3ec5093ae660@github.com>

On Tue, 2 Mar 2021 17:35:18 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> I have few comments.
>
> @veresov I can't see your comment re. the casts. The only comment I see is re. the *64 suffixes. 
> Anyway, is your question/comment directly related to Vladimir's annotations? Or do you need further reasoning? Please let me know.

No it was a different question. I see my comments try clicking on the "Files changed" tab and scrolling down to method.cpp.
I also left a comment about your changes to ```compare_methods()``` I don't think it's correct.

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

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

From lmesnik at openjdk.java.net  Tue Mar  2 19:10:51 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 2 Mar 2021 19:10:51 GMT
Subject: RFR: 8253940: com/sun/jdi/JdwpAttachTest.java failed with
 "RuntimeException: ERROR: LingeredApp.startApp was able to attach" [v2]
In-Reply-To: <hxbQJ5saY9Matb6No5O-nBHXYiLGj6Ius17Yt4fABhc=.92ee0ccd-01b7-4010-82c3-6308cf043b59@github.com>
References: <HBuZ978kLXLgllYPgBTv7q9_L9MWcAxkh3oqzw-EC2Y=.03e5f605-978b-472b-a56d-b280c4645242@github.com>
 <hxbQJ5saY9Matb6No5O-nBHXYiLGj6Ius17Yt4fABhc=.92ee0ccd-01b7-4010-82c3-6308cf043b59@github.com>
Message-ID: <xpnkSAydwnBkjSnEwMmbIW0NLejL5HdRZXzry6FaY2o=.712a482d-51ec-4f95-b26c-bfe4c617cb9e@github.com>

On Fri, 19 Feb 2021 23:04:59 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Failures related to "no route to host" and "cannot bind to address" errors are covered by https://git.openjdk.java.net/jdk/pull/2633
>> 
>> This change fixes failures with listening on IPv6 loopback and attaching to "localhost" (the test connects to some other process which listens on the same port on IPv4 loopback and as a result gets "handshake failed - received >< - expected >JDWP-Handshake<" error)
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated per Chris feedback

Marked as reviewed by lmesnik (Committer).

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

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

From lucy at openjdk.java.net  Tue Mar  2 19:28:41 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Tue, 2 Mar 2021 19:28:41 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v8]
In-Reply-To: <FsqGKu8fr7eHDlQxBaJYckzOOKf6bLzTIaA4XKlAKGY=.9134e6cf-03f3-41f8-bb05-3ec5093ae660@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <Ul6OJXuqVlRZxy7OxB0SRre44bZaZAg7e757hdZf34A=.37ac8cdd-c438-436b-9f84-6176f329b735@github.com>
 <3mk54i0LQX0awCjtEnYDpf0C9QiCERjP7pOLI6GAvBU=.53cd8ad8-2237-46c9-afa4-72d5f5bbac06@github.com>
 <bj1yHHIJVOAklDxq6uDB0zSVwrlFelayw2fd0Gyswyg=.6add799f-ebc4-4f34-9f0c-d2fddd24a23f@github.com>
 <FsqGKu8fr7eHDlQxBaJYckzOOKf6bLzTIaA4XKlAKGY=.9134e6cf-03f3-41f8-bb05-3ec5093ae660@github.com>
Message-ID: <D0S90alIz2xJJJq750XrxnniHDAoDKiWN58mLhW7_x8=.512c6f70-4226-4ac9-9a63-aaa24a835a21@github.com>

On Tue, 2 Mar 2021 18:53:47 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> @veresov I can't see your comment re. the casts. The only comment I see is re. the *64 suffixes. 
>> Anyway, is your question/comment directly related to Vladimir's annotations? Or do you need further reasoning? Please let me know.
>
> No it was a different question. I see my comments try clicking on the "Files changed" tab and scrolling down to method.cpp.
> I also left a comment about your changes to ```compare_methods()``` I don't think it's correct.

Igor, I'm sorry, I can't see your comments. Neither those for method.cpp nor those for java.cpp. I checked the piper mail traffic as well. No mail from you after the *64 suffix comment. For simplicity, could you just paste your comment here, please? Or send them to me via mail (off-list, first.last at sap.com)?

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

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

From iveresov at openjdk.java.net  Tue Mar  2 19:50:42 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Tue, 2 Mar 2021 19:50:42 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v8]
In-Reply-To: <D0S90alIz2xJJJq750XrxnniHDAoDKiWN58mLhW7_x8=.512c6f70-4226-4ac9-9a63-aaa24a835a21@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <Ul6OJXuqVlRZxy7OxB0SRre44bZaZAg7e757hdZf34A=.37ac8cdd-c438-436b-9f84-6176f329b735@github.com>
 <3mk54i0LQX0awCjtEnYDpf0C9QiCERjP7pOLI6GAvBU=.53cd8ad8-2237-46c9-afa4-72d5f5bbac06@github.com>
 <bj1yHHIJVOAklDxq6uDB0zSVwrlFelayw2fd0Gyswyg=.6add799f-ebc4-4f34-9f0c-d2fddd24a23f@github.com>
 <FsqGKu8fr7eHDlQxBaJYckzOOKf6bLzTIaA4XKlAKGY=.9134e6cf-03f3-41f8-bb05-3ec5093ae660@github.com>
 <D0S90alIz2xJJJq750XrxnniHDAoDKiWN58mLhW7_x8=.512c6f70-4226-4ac9-9a63-aaa24a835a21@github.com>
Message-ID: <X5gsdwl1YlalWOVbT4IwMhX-2xSqs3co8sKyDTYgfBY=.17a3a9dd-ceae-4571-882c-b2f0c8fcbb50@github.com>

On Tue, 2 Mar 2021 19:25:26 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> No it was a different question. I see my comments try clicking on the "Files changed" tab and scrolling down to method.cpp.
>> I also left a comment about your changes to ```compare_methods()``` I don't think it's correct.
>
> Igor, I'm sorry, I can't see your comments. Neither those for method.cpp nor those for java.cpp. I checked the piper mail traffic as well. No mail from you after the *64 suffix comment. For simplicity, could you just paste your comment here, please? Or send them to me via mail (off-list, first.last at sap.com)?

Ok, odd. I've sent you an email.

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

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

From iveresov at openjdk.java.net  Tue Mar  2 20:04:04 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Tue, 2 Mar 2021 20:04:04 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v2]
In-Reply-To: <8B4V-lAbFWqYJzdcbVyz69U05GX14vFRx6nY-tKorNU=.4dff6316-f85e-4578-ae59-2dab8d804627@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <ekO55Wt9H4U56-RG0c42FihkWP2gy-JhC-hoTRxjCgU=.c6c77076-11f5-4a30-8934-707c07fd70db@github.com>
 <8B4V-lAbFWqYJzdcbVyz69U05GX14vFRx6nY-tKorNU=.4dff6316-f85e-4578-ae59-2dab8d804627@github.com>
Message-ID: <7wsUXkZzWxQxKZU2obDzcql7ADmt3pFpyaVUe3a0D_o=.d4f62585-cd23-4e58-9ccd-2c6ebe555f43@github.com>

On Thu, 11 Feb 2021 21:14:04 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Lutz Schmidt has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.
>
> src/hotspot/share/oops/method.cpp line 516:
> 
>> 514:   // This is ok because counters are unsigned by nature, and it gives us
>> 515:   // another factor of 2 before the counter values become meaningless.
>> 516:   // Print a "overflow" notification to create awareness.
> 
> What ```invocation_count()``` returns (which is currently equivalent to ```interpreter_invocation_count()``` btw) comes from the ```InvocationCounter::count()``` which cannot grow beyond 2^31, so all these counts are always positive. What exactly do these casts to unsigned do?

So, why do we need the casts to unsigned in this method?

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

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

From iveresov at openjdk.java.net  Tue Mar  2 20:04:03 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Tue, 2 Mar 2021 20:04:03 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v2]
In-Reply-To: <ekO55Wt9H4U56-RG0c42FihkWP2gy-JhC-hoTRxjCgU=.c6c77076-11f5-4a30-8934-707c07fd70db@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <ekO55Wt9H4U56-RG0c42FihkWP2gy-JhC-hoTRxjCgU=.c6c77076-11f5-4a30-8934-707c07fd70db@github.com>
Message-ID: <8B4V-lAbFWqYJzdcbVyz69U05GX14vFRx6nY-tKorNU=.4dff6316-f85e-4578-ae59-2dab8d804627@github.com>

On Thu, 11 Feb 2021 17:47:54 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> Dear community,
>> may I please request reviews for this fix, improving the usefulness of method invocation counters.
>> - aggregation counters are retyped as uint64_t, shifting the overflow probability way out (> 500 years in case of a 1 GHz counter update frequency).
>> - counters for individual methods are interpreted as (unsigned int), in contrast to their declaration as int. This gives us a factor of two before the counters overflow.
>> - as a special case, "compiled_invocation_counter" is retyped as long, because it has a higher update frequency than other counters.
>> - before/after sample output is attached to the bug description. 
>> 
>> Thank you!
>> Lutz
>
> Lutz Schmidt has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

Changes requested by iveresov (Reviewer).

src/hotspot/share/oops/method.cpp line 516:

> 514:   // This is ok because counters are unsigned by nature, and it gives us
> 515:   // another factor of 2 before the counter values become meaningless.
> 516:   // Print a "overflow" notification to create awareness.

What ```invocation_count()``` returns (which is currently equivalent to ```interpreter_invocation_count()``` btw) comes from the ```InvocationCounter::count()``` which cannot grow beyond 2^31, so all these counts are always positive. What exactly do these casts to unsigned do?

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

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

From iveresov at openjdk.java.net  Tue Mar  2 20:04:06 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Tue, 2 Mar 2021 20:04:06 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v8]
In-Reply-To: <VlLH5Vhyn2ky5ulZmGcv0mc35A1myfBsVEc_9idhjUc=.0adc4205-2441-4f41-8fee-5d8d27fc8681@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <Ul6OJXuqVlRZxy7OxB0SRre44bZaZAg7e757hdZf34A=.37ac8cdd-c438-436b-9f84-6176f329b735@github.com>
 <3mk54i0LQX0awCjtEnYDpf0C9QiCERjP7pOLI6GAvBU=.53cd8ad8-2237-46c9-afa4-72d5f5bbac06@github.com>
 <VlLH5Vhyn2ky5ulZmGcv0mc35A1myfBsVEc_9idhjUc=.0adc4205-2441-4f41-8fee-5d8d27fc8681@github.com>
Message-ID: <39PPAynJ6dWRnCwIgxerBB2IiJm0BFwt3TQ2DqcUJLk=.345fcb18-0370-4f86-ad14-787529496fcc@github.com>

On Tue, 2 Mar 2021 17:30:47 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> src/hotspot/share/oops/method.cpp line 518:
>> 
>>> 516:   // Print a "overflow" notification to create awareness.
>>> 517:   const char* addMsg;
>>> 518:   unsigned int maxInt = (1U<<31) - 1;
>> 
>> Why not use INT_MAX?
>
> Will change.

I'd be better to change the logic to check if the counter is ```>= InvocationCounter::count_limit``` then it's in overflow.

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

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

From iveresov at openjdk.java.net  Tue Mar  2 20:04:06 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Tue, 2 Mar 2021 20:04:06 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v8]
In-Reply-To: <Ul6OJXuqVlRZxy7OxB0SRre44bZaZAg7e757hdZf34A=.37ac8cdd-c438-436b-9f84-6176f329b735@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <Ul6OJXuqVlRZxy7OxB0SRre44bZaZAg7e757hdZf34A=.37ac8cdd-c438-436b-9f84-6176f329b735@github.com>
Message-ID: <BK_Hrgo8M4wvyn-KOU71LYk4F3S2a_UUGmVDFg2eZWI=.2884c27f-41e4-4aae-97a5-f00fd932446b@github.com>

On Thu, 25 Feb 2021 09:01:10 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> Dear community,
>> may I please request reviews for this fix, improving the usefulness of method invocation counters.
>> - aggregation counters are retyped as uint64_t, shifting the overflow probability way out (> 500 years in case of a 1 GHz counter update frequency).
>> - counters for individual methods are interpreted as (unsigned int), in contrast to their declaration as int. This gives us a factor of two before the counters overflow.
>> - as a special case, "compiled_invocation_counter" is retyped as long, because it has a higher update frequency than other counters.
>> - before/after sample output is attached to the bug description. 
>> 
>> Thank you!
>> Lutz
>
> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment changes requested by TheRealMDoerr

src/hotspot/share/runtime/java.cpp line 100:

> 98: int compare_methods(Method** a, Method** b) {
> 99:   return (int32_t)(((uint32_t)(*b)->invocation_count() + (*b)->compiled_invocation_count())
> 100:                  - ((uint32_t)(*a)->invocation_count() + (*a)->compiled_invocation_count()));

Is this correct? The arithmetic look to be: (int32_t) (uint64_t - uint64_t). If the 64 values inside don't fit in 32, you'll get a negative number which would break the sorting logic.

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

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

From akozlov at openjdk.java.net  Tue Mar  2 20:32:49 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 20:32:49 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
In-Reply-To: <9bn80xM9g41OytCtH71-krOZtAgy27TbvTFJHmfmKrE=.e9d223d5-2922-4891-8f45-ee039d88ced6@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
 <9bn80xM9g41OytCtH71-krOZtAgy27TbvTFJHmfmKrE=.e9d223d5-2922-4891-8f45-ee039d88ced6@github.com>
Message-ID: <FqG48k4wPLWnjZX7DO2Vi9utptmRaSSLKZvAFkXJVuA=.50cf018d-194a-4149-82b3-bcf6ce6aa8fd@github.com>

On Thu, 4 Feb 2021 22:34:16 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>>  - Add comments to WX transitions
>>    
>>    + minor change of placements
>>  - Use macro conditionals instead of empty functions
>>  - Add W^X to tests
>>  - Do not require known W^X state
>>  - Revert w^x in gtests
>
> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 237:
> 
>> 235:       os::Posix::ucontext_set_pc(uc, StubRoutines::continuation_for_safefetch_fault(pc));
>> 236:       return true;
>> 237:     }
> 
> Isn't this case already handled by `JVM_HANDLE_XXX_SIGNAL()` ? Why do we need it here again?

Good point, thanks. We are missing a few fixes in os_cpu/bsd_aarch64. This was moved out recently. I'm going to align bsd_aarch64 with the rest of platforms.

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

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

From iveresov at openjdk.java.net  Tue Mar  2 20:50:44 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Tue, 2 Mar 2021 20:50:44 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v8]
In-Reply-To: <BK_Hrgo8M4wvyn-KOU71LYk4F3S2a_UUGmVDFg2eZWI=.2884c27f-41e4-4aae-97a5-f00fd932446b@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <Ul6OJXuqVlRZxy7OxB0SRre44bZaZAg7e757hdZf34A=.37ac8cdd-c438-436b-9f84-6176f329b735@github.com>
 <BK_Hrgo8M4wvyn-KOU71LYk4F3S2a_UUGmVDFg2eZWI=.2884c27f-41e4-4aae-97a5-f00fd932446b@github.com>
Message-ID: <BADanxAzCxhsHJdQzYoLUgWpuGRtLN2K-t34iFUcjBk=.e140b7c9-39f1-498d-abde-f98fd6d2b6f1@github.com>

On Thu, 25 Feb 2021 16:36:38 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comment changes requested by TheRealMDoerr
>
> src/hotspot/share/runtime/java.cpp line 100:
> 
>> 98: int compare_methods(Method** a, Method** b) {
>> 99:   return (int32_t)(((uint32_t)(*b)->invocation_count() + (*b)->compiled_invocation_count())
>> 100:                  - ((uint32_t)(*a)->invocation_count() + (*a)->compiled_invocation_count()));
> 
> Is this correct? The arithmetic look to be: (int32_t) (uint64_t - uint64_t). If the 64 values inside don't fit in 32, you'll get a negative number which would break the sorting logic.

I see that you've fixed the types since the last comment, but it think it's still broken (and has been before).
How about:
int64_t diff =  ((*b)->compiled_invocation_count() - (*a)->compiled_invocation_count()) + ((*b)->invocation_count() - (*a)->invocation_count());
if (diff > 0) return 1;
else if (diff < 0) return -1;
else return 0;
It's kind of hacky too, because it assumes that compiled_invocation_count() are positive and didn't overflow. But at least we'd get rid of a possible overflow during summation. What do you think?

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

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

From lucy at openjdk.java.net  Tue Mar  2 20:50:43 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Tue, 2 Mar 2021 20:50:43 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v2]
In-Reply-To: <7wsUXkZzWxQxKZU2obDzcql7ADmt3pFpyaVUe3a0D_o=.d4f62585-cd23-4e58-9ccd-2c6ebe555f43@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <ekO55Wt9H4U56-RG0c42FihkWP2gy-JhC-hoTRxjCgU=.c6c77076-11f5-4a30-8934-707c07fd70db@github.com>
 <8B4V-lAbFWqYJzdcbVyz69U05GX14vFRx6nY-tKorNU=.4dff6316-f85e-4578-ae59-2dab8d804627@github.com>
 <7wsUXkZzWxQxKZU2obDzcql7ADmt3pFpyaVUe3a0D_o=.d4f62585-cd23-4e58-9ccd-2c6ebe555f43@github.com>
Message-ID: <3cDAX-RUCe2SA1O1Mq_Ge152dzwNUSDj3ZQB0ziYJxM=.e594bfe0-4d68-46fc-8d59-16b2dfa3abf1@github.com>

On Thu, 25 Feb 2021 16:31:58 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> src/hotspot/share/oops/method.cpp line 516:
>> 
>>> 514:   // This is ok because counters are unsigned by nature, and it gives us
>>> 515:   // another factor of 2 before the counter values become meaningless.
>>> 516:   // Print a "overflow" notification to create awareness.
>> 
>> What ```invocation_count()``` returns (which is currently equivalent to ```interpreter_invocation_count()``` btw) comes from the ```InvocationCounter::count()``` which cannot grow beyond 2^31, so all these counts are always positive. What exactly do these casts to unsigned do?
>
> So, why do we need the casts to unsigned in this method?

When you increment (2^31-1), you get 2^31 which is 0x80000000. When interpreted as signed int, it is MIN_INT. I don't want that. I want to treat the value as positive number - what it actually is. There is no negative count!

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

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

From lucy at openjdk.java.net  Tue Mar  2 20:50:45 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Tue, 2 Mar 2021 20:50:45 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v8]
In-Reply-To: <39PPAynJ6dWRnCwIgxerBB2IiJm0BFwt3TQ2DqcUJLk=.345fcb18-0370-4f86-ad14-787529496fcc@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <Ul6OJXuqVlRZxy7OxB0SRre44bZaZAg7e757hdZf34A=.37ac8cdd-c438-436b-9f84-6176f329b735@github.com>
 <3mk54i0LQX0awCjtEnYDpf0C9QiCERjP7pOLI6GAvBU=.53cd8ad8-2237-46c9-afa4-72d5f5bbac06@github.com>
 <VlLH5Vhyn2ky5ulZmGcv0mc35A1myfBsVEc_9idhjUc=.0adc4205-2441-4f41-8fee-5d8d27fc8681@github.com>
 <39PPAynJ6dWRnCwIgxerBB2IiJm0BFwt3TQ2DqcUJLk=.345fcb18-0370-4f86-ad14-787529496fcc@github.com>
Message-ID: <WF7yz2by5qPWbievAQ3UTRw5DdpxJayXLQoMh1U1fnA=.0d21ce56-a251-4f48-b0c9-c6a9c8e6886a@github.com>

On Tue, 2 Mar 2021 18:50:24 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Will change.
>
> I'd be better to change the logic to check if the counter is ```>= InvocationCounter::count_limit``` then it's in overflow.

With overflow I do not mean "counter overflow" as it is used to trigger compiler activities but plain simple "range of singed int exceeded". Should I use different wording? E.g. "counter in signed int overflow"?

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

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

From iveresov at openjdk.java.net  Tue Mar  2 20:58:47 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Tue, 2 Mar 2021 20:58:47 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v8]
In-Reply-To: <WF7yz2by5qPWbievAQ3UTRw5DdpxJayXLQoMh1U1fnA=.0d21ce56-a251-4f48-b0c9-c6a9c8e6886a@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <Ul6OJXuqVlRZxy7OxB0SRre44bZaZAg7e757hdZf34A=.37ac8cdd-c438-436b-9f84-6176f329b735@github.com>
 <3mk54i0LQX0awCjtEnYDpf0C9QiCERjP7pOLI6GAvBU=.53cd8ad8-2237-46c9-afa4-72d5f5bbac06@github.com>
 <VlLH5Vhyn2ky5ulZmGcv0mc35A1myfBsVEc_9idhjUc=.0adc4205-2441-4f41-8fee-5d8d27fc8681@github.com>
 <39PPAynJ6dWRnCwIgxerBB2IiJm0BFwt3TQ2DqcUJLk=.345fcb18-0370-4f86-ad14-787529496fcc@github.com>
 <WF7yz2by5qPWbievAQ3UTRw5DdpxJayXLQoMh1U1fnA=.0d21ce56-a251-4f48-b0c9-c6a9c8e6886a@github.com>
Message-ID: <lyInsyQOKTiod-FYtqxmVc1PMct4LXsR-G5x0bJbH8A=.98085e12-a12a-4786-9232-a7c405a0ab11@github.com>

On Tue, 2 Mar 2021 20:47:25 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> I'd be better to change the logic to check if the counter is ```>= InvocationCounter::count_limit``` then it's in overflow.
>
> With overflow I do not mean "counter overflow" as it is used to trigger compiler activities but plain simple "range of singed int exceeded". Should I use different wording? E.g. "counter in signed int overflow"?

Then it will never happen. These values come from ```InvocationCounter::count()```. And it will never return a value > 2^31 - 1.

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

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

From iveresov at openjdk.java.net  Tue Mar  2 21:02:39 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Tue, 2 Mar 2021 21:02:39 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v8]
In-Reply-To: <lyInsyQOKTiod-FYtqxmVc1PMct4LXsR-G5x0bJbH8A=.98085e12-a12a-4786-9232-a7c405a0ab11@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <Ul6OJXuqVlRZxy7OxB0SRre44bZaZAg7e757hdZf34A=.37ac8cdd-c438-436b-9f84-6176f329b735@github.com>
 <3mk54i0LQX0awCjtEnYDpf0C9QiCERjP7pOLI6GAvBU=.53cd8ad8-2237-46c9-afa4-72d5f5bbac06@github.com>
 <VlLH5Vhyn2ky5ulZmGcv0mc35A1myfBsVEc_9idhjUc=.0adc4205-2441-4f41-8fee-5d8d27fc8681@github.com>
 <39PPAynJ6dWRnCwIgxerBB2IiJm0BFwt3TQ2DqcUJLk=.345fcb18-0370-4f86-ad14-787529496fcc@github.com>
 <WF7yz2by5qPWbievAQ3UTRw5DdpxJayXLQoMh1U1fnA=.0d21ce56-a251-4f48-b0c9-c6a9c8e6886a@github.com>
 <lyInsyQOKTiod-FYtqxmVc1PMct4LXsR-G5x0bJbH8A=.98085e12-a12a-4786-9232-a7c405a0ab11@github.com>
Message-ID: <dwZXe8-qNJVDS6wX582b-eVPxg_8b98vBLXQWfkEGds=.0a010486-2e54-43a2-b4f1-78a694f99d35@github.com>

On Tue, 2 Mar 2021 20:55:50 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> With overflow I do not mean "counter overflow" as it is used to trigger compiler activities but plain simple "range of singed int exceeded". Should I use different wording? E.g. "counter in signed int overflow"?
>
> Then it will never happen. These values come from ```InvocationCounter::count()```. And it will never return a value > 2^31 - 1.

Sorry, it can return 2^31. Which would be an indication of a counter overflow (InvocationCounter::count_limit == 2^31). Your code is correct in both senses. It is a counter overflow and a signed int overflow.

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

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

From iveresov at openjdk.java.net  Tue Mar  2 21:11:51 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Tue, 2 Mar 2021 21:11:51 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v8]
In-Reply-To: <dwZXe8-qNJVDS6wX582b-eVPxg_8b98vBLXQWfkEGds=.0a010486-2e54-43a2-b4f1-78a694f99d35@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <Ul6OJXuqVlRZxy7OxB0SRre44bZaZAg7e757hdZf34A=.37ac8cdd-c438-436b-9f84-6176f329b735@github.com>
 <3mk54i0LQX0awCjtEnYDpf0C9QiCERjP7pOLI6GAvBU=.53cd8ad8-2237-46c9-afa4-72d5f5bbac06@github.com>
 <VlLH5Vhyn2ky5ulZmGcv0mc35A1myfBsVEc_9idhjUc=.0adc4205-2441-4f41-8fee-5d8d27fc8681@github.com>
 <39PPAynJ6dWRnCwIgxerBB2IiJm0BFwt3TQ2DqcUJLk=.345fcb18-0370-4f86-ad14-787529496fcc@github.com>
 <WF7yz2by5qPWbievAQ3UTRw5DdpxJayXLQoMh1U1fnA=.0d21ce56-a251-4f48-b0c9-c6a9c8e6886a@github.com>
 <lyInsyQOKTiod-FYtqxmVc1PMct4LXsR-G5x0bJbH8A=.98085e12-a12a-4786-9232-a7c405a0ab11@github.com>
 <dwZXe8-qNJVDS6wX582b-eVPxg_8b98vBLXQWfkEGds=.0a010486-2e54-43a2-b4f1-78a694f99d35@github.com>
Message-ID: <8CM8mqTq7RmwR2sjk0J69O19UQXASFKghQyIy6lKduA=.101780ec-9039-4749-a27b-6dd0997bd398@github.com>

On Tue, 2 Mar 2021 20:59:46 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Then it will never happen. These values come from ```InvocationCounter::count()```. And it will never return a value > 2^31 - 1.
>
> Sorry, it can return 2^31. Which would be an indication of a counter overflow (InvocationCounter::count_limit == 2^31). Your code is correct in both senses. It is a counter overflow and a signed int overflow.

Oops, my arithmetic is bad again. InvocationCounter::count_limit is 2^30. So, I don't think there ever going to be an overflow that you're looking for. The sign bit is always 0. Or am I missing something again? :)

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

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

From lucy at openjdk.java.net  Tue Mar  2 21:11:52 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Tue, 2 Mar 2021 21:11:52 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v8]
In-Reply-To: <BADanxAzCxhsHJdQzYoLUgWpuGRtLN2K-t34iFUcjBk=.e140b7c9-39f1-498d-abde-f98fd6d2b6f1@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <Ul6OJXuqVlRZxy7OxB0SRre44bZaZAg7e757hdZf34A=.37ac8cdd-c438-436b-9f84-6176f329b735@github.com>
 <BK_Hrgo8M4wvyn-KOU71LYk4F3S2a_UUGmVDFg2eZWI=.2884c27f-41e4-4aae-97a5-f00fd932446b@github.com>
 <BADanxAzCxhsHJdQzYoLUgWpuGRtLN2K-t34iFUcjBk=.e140b7c9-39f1-498d-abde-f98fd6d2b6f1@github.com>
Message-ID: <iylzykfLo0f1M6-gUT5hzGpRnnJl9Gc9pGt0JEHJvOQ=.cc45edbd-7b6c-4255-8abd-a7be042248a1@github.com>

On Tue, 2 Mar 2021 20:46:01 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> src/hotspot/share/runtime/java.cpp line 100:
>> 
>>> 98: int compare_methods(Method** a, Method** b) {
>>> 99:   return (int32_t)(((uint32_t)(*b)->invocation_count() + (*b)->compiled_invocation_count())
>>> 100:                  - ((uint32_t)(*a)->invocation_count() + (*a)->compiled_invocation_count()));
>> 
>> Is this correct? The arithmetic look to be: (int32_t) (uint64_t - uint64_t). If the 64 values inside don't fit in 32, you'll get a negative number which would break the sorting logic.
>
> I see that you've fixed the types since the last comment, but it think it's still broken (and has been before).
> How about:
> int64_t diff =  ((*b)->compiled_invocation_count() - (*a)->compiled_invocation_count()) + ((*b)->invocation_count() - (*a)->invocation_count());
> if (diff > 0) return 1;
> else if (diff < 0) return -1;
> else return 0;
> It's kind of hacky too, because it assumes that compiled_invocation_count() are positive and didn't overflow. But at least we'd get rid of a possible overflow during summation. What do you think?

Right. As soon as there is overflow, the original formula doesn't do the trick either.
We can fix it as long as either (unsigned int)invocation_count() does not wrap around from 2^32-1 to 0. The entire expression is calculated as int64_t, protecting us from overflow for the next few years. If we then calculate the return value as you propose, we are good.

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

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

From iveresov at openjdk.java.net  Tue Mar  2 21:18:50 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Tue, 2 Mar 2021 21:18:50 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v2]
In-Reply-To: <3cDAX-RUCe2SA1O1Mq_Ge152dzwNUSDj3ZQB0ziYJxM=.e594bfe0-4d68-46fc-8d59-16b2dfa3abf1@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <ekO55Wt9H4U56-RG0c42FihkWP2gy-JhC-hoTRxjCgU=.c6c77076-11f5-4a30-8934-707c07fd70db@github.com>
 <8B4V-lAbFWqYJzdcbVyz69U05GX14vFRx6nY-tKorNU=.4dff6316-f85e-4578-ae59-2dab8d804627@github.com>
 <7wsUXkZzWxQxKZU2obDzcql7ADmt3pFpyaVUe3a0D_o=.d4f62585-cd23-4e58-9ccd-2c6ebe555f43@github.com>
 <3cDAX-RUCe2SA1O1Mq_Ge152dzwNUSDj3ZQB0ziYJxM=.e594bfe0-4d68-46fc-8d59-16b2dfa3abf1@github.com>
Message-ID: <alIuBfrMfJcQZtt3RzHsOcKZ23fo7XkImn1XItkRLaE=.2afa3965-827c-46d6-b745-405998262e15@github.com>

On Tue, 2 Mar 2021 20:43:53 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> So, why do we need the casts to unsigned in this method?
>
> When you increment (2^31-1), you get 2^31 which is 0x80000000. When interpreted as signed int, it is MIN_INT. I don't want that. I want to treat the value as positive number - what it actually is. There is no negative count!

I was trying to make a point that these counters are always < MAX_INT. ```InvocationCounter::count()``` shifts the counter right by 1, ensuring that the sign bit is 0. ```Method::{invocation, backedge, interpreter_invocation}_count()``` can also return ```InvocationCounter::count_limit```, but this one is 2^30, which is also positive.

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

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

From akozlov at openjdk.java.net  Tue Mar  2 21:19:18 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 21:19:18 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v23]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <ciwAT0uB2sME-WzcDx96ipa1QHDFCeru1pO847cdBrY=.a7f895c7-e7ed-45ce-babd-c9ba2f955dda@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request incrementally with five additional commits since the last revision:

 - Fix after JDK-8259539, partially revert preconditions
 - JDK-8260471: bsd_aarch64 part
 - JDK-8259539: bsd_aarch64 part
 - JDK-8257828: bsd_aarch64 part
 - Cleanup os_bsd_aarch64 signal handling

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/e42b82db..4c37f068

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=22
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=21-22

  Stats: 31 lines in 1 file changed: 15 ins; 11 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

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

From akozlov at openjdk.java.net  Tue Mar  2 21:19:18 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 21:19:18 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
In-Reply-To: <-PhzrEcgREcbXuZ5GrxAfVa6Uwil9YoOkZULt1154rw=.9689a79e-cf61-4f79-9b36-a3295fecab7b@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
 <i9UArB35vpHowW6HbtTkKLQX-wwfSx1dg1NKLHIRdGs=.5e08a151-8ad3-46cc-b006-34d750410c47@github.com>
 <-PhzrEcgREcbXuZ5GrxAfVa6Uwil9YoOkZULt1154rw=.9689a79e-cf61-4f79-9b36-a3295fecab7b@github.com>
Message-ID: <XOowePO_JQ-AQ342Gtf3w3J8nrin2YPdlj0ZP6gwYJM=.2884d345-3eab-4ba6-85f8-fde1d011df49@github.com>

On Fri, 12 Feb 2021 15:21:06 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 302:
>> 
>>> 300:         const uint64_t *detail_msg_ptr
>>> 301:           = (uint64_t*)(pc + NativeInstruction::instruction_size);
>>> 302:         const char *detail_msg = (const char *)*detail_msg_ptr;
>> 
>> Where is `detail_msg` used?
>
> Came from linux_arm64. was used in os_linux_aarch64.cpp on line 246 in report_and_die
> But became unused on bsd_arm64. I agree this needs to be removed

It seems we have merged master branch before JDK-8259539 was integrated. It brings back use of detail_msg. I reverted details_msg as well its following use.

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

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

From lucy at openjdk.java.net  Tue Mar  2 21:29:46 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Tue, 2 Mar 2021 21:29:46 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v2]
In-Reply-To: <alIuBfrMfJcQZtt3RzHsOcKZ23fo7XkImn1XItkRLaE=.2afa3965-827c-46d6-b745-405998262e15@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <ekO55Wt9H4U56-RG0c42FihkWP2gy-JhC-hoTRxjCgU=.c6c77076-11f5-4a30-8934-707c07fd70db@github.com>
 <8B4V-lAbFWqYJzdcbVyz69U05GX14vFRx6nY-tKorNU=.4dff6316-f85e-4578-ae59-2dab8d804627@github.com>
 <7wsUXkZzWxQxKZU2obDzcql7ADmt3pFpyaVUe3a0D_o=.d4f62585-cd23-4e58-9ccd-2c6ebe555f43@github.com>
 <3cDAX-RUCe2SA1O1Mq_Ge152dzwNUSDj3ZQB0ziYJxM=.e594bfe0-4d68-46fc-8d59-16b2dfa3abf1@github.com>
 <alIuBfrMfJcQZtt3RzHsOcKZ23fo7XkImn1XItkRLaE=.2afa3965-827c-46d6-b745-405998262e15@github.com>
Message-ID: <CVQoNQplMz8-7bSuZUYaJKQUf7BrPztTUNAnpJc04nU=.631d8189-b1b9-4f05-8477-47170aba538f@github.com>

On Tue, 2 Mar 2021 21:15:46 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> When you increment (2^31-1), you get 2^31 which is 0x80000000. When interpreted as signed int, it is MIN_INT. I don't want that. I want to treat the value as positive number - what it actually is. There is no negative count!
>
> I was trying to make a point that these counters are always < MAX_INT. ```InvocationCounter::count()``` shifts the counter right by 1, ensuring that the sign bit is 0. ```Method::{invocation, backedge, interpreter_invocation}_count()``` can also return ```InvocationCounter::count_limit```, but this one is 2^30, which is also positive.

Slowly, but surely, we are coming to a common understanding. Thanks for educating me. I hadn't seen the range limitation for the counters. Now that I know, I recognise there is some knowledge in my almost faded memory.
OK, these three counters will never get dangerously close to 2^31-1. I will rework the section, remove some checks and casts. This will only happen tomorrow (Wednesday) which starts in 90 minutes in my time zone (GMT+1).

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

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

From akozlov at openjdk.java.net  Tue Mar  2 21:29:52 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 21:29:52 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
In-Reply-To: <snefTFoz9nOu7pghwG_v5GiOsmMvFSiICF3Hr1UskCs=.e9df3841-8204-41f5-a2b7-d8b07569a646@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
 <snefTFoz9nOu7pghwG_v5GiOsmMvFSiICF3Hr1UskCs=.e9df3841-8204-41f5-a2b7-d8b07569a646@github.com>
Message-ID: <k5nnBgnSMPy-3Zk3rnTAsmrFgMlO08wb_4wpfOYg4SM=.cf972a76-c5c6-4428-9574-66120fa79594@github.com>

On Thu, 4 Feb 2021 22:58:39 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>>  - Add comments to WX transitions
>>    
>>    + minor change of placements
>>  - Use macro conditionals instead of empty functions
>>  - Add W^X to tests
>>  - Do not require known W^X state
>>  - Revert w^x in gtests
>
> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 420:
> 
>> 418: size_t os::Posix::_compiler_thread_min_stack_allowed = 72 * K;
>> 419: size_t os::Posix::_java_thread_min_stack_allowed = 72 * K;
>> 420: size_t os::Posix::_vm_internal_thread_min_stack_allowed = 72 * K;
> 
> Those are slightly larger than their x86_64 counter parts. Are they conservative/aggressive values? How did we arrive at those?

These values were copied from linux_aarch64. The motivation is that clang on macos/aarch64 will likely to produce stack frames for C++ functions similar to frames generates by gcc on linux/aarch64. And sizes of java stack frames should not change.

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

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

From cjplummer at openjdk.java.net  Tue Mar  2 22:33:52 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 2 Mar 2021 22:33:52 GMT
Subject: RFR: 8262520: Add CLHSDB command to connect to debug server [v3]
In-Reply-To: <WKq-Wmomp8PNGWUKS_Sp6Aa0wYg9mzdkunPrsQKrMK8=.fbfda9d9-f383-4c48-a0ac-d08a37086c27@github.com>
References: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
 <WKq-Wmomp8PNGWUKS_Sp6Aa0wYg9mzdkunPrsQKrMK8=.fbfda9d9-f383-4c48-a0ac-d08a37086c27@github.com>
Message-ID: <ucA3-g3HcHbQ5uZ1Mc_hBrFSK17l2iavHr95CEsNJkM=.805874ca-b7cc-4b01-9761-c70b8e795b5a@github.com>

On Tue, 2 Mar 2021 12:55:04 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> `attach` command on CLHSDB supports to attach live process (PID) and coredump, but it cannot connect to debug server. CLHSDB does not have a command to connect to debug server.
>> 
>> Other jhsdb commands (jstack, jmap, etc...) can connect debug server via `--connect` option, so CLHSDB should connect to it.
>> 
>> After this change, you can connect to debug server with 'connect <hostname>'.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comments

This pre-existing code in CLHSDB.java is a little concerning:

127     private void doUsage() {
128         System.out.println("Usage:  java CLHSDB [[pid] | [path-to-java-executable [path-to-corefile]] | help ]");
129         System.out.println("           pid:                     attach to the process whose id is 'pid'");
130         System.out.println("           path-to-java-executable: Debug a core file produced by this program");
131         System.out.println("           path-to-corefile:        Debug this corefile.  The default is 'core'");
132         System.out.println("        If no arguments are specified, you can select what to do from the GUI.\n");
133         HotSpotAgent.showUsage();
134     }

First concern is that you have not added "debug server" support to it.  2nd concern is the "If no arguments are specified, you can select what to do from the GUI" part. It looks like using the GUI you can launch the CLHSDB console, although I can't find in the source where/how that is actually done. In any case, i don't see any way to pass command arguments when you do that.

I'm just wondering how much of this CLHSDB support we want to keep beyond what the clhsdb command needs. Do we still want to support invoking CLHSDB.main() from the java command line?

src/jdk.hotspot.agent/doc/clhsdb.html line 39:

> 37: Available commands:
> 38:   assert true | false <font color="red">turn on/off asserts in SA code</font>
> 39:   attach pid | exec core | remote_server  <font color="red">attach SA to a process, core, or remote debug server</font>

The `jhsdb` help says `jhsdb jstack --connect debugserver`, so maybe `debug_server` would be better than `remote_server`. I think "remote debug server" in the help text is fine.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CLHSDB.java line 53:

> 51:         // and coreFilename is the pathname of a core file we are
> 52:         // supposed to attach to.
> 53:         // Finally, if remoteMachineName != null, we are supposed to connect to remote debug server.

Split this line so its length is more consistent with the previous lines.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CLHSDB.java line 125:

> 123:     private String execPath;
> 124:     private String coreFilename;
> 125:     private String remoteMachineName;

I think `debugServerName` or `remoteDebugServerName` would be better.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CLHSDB.java line 230:

> 228:             System.out.println("Connecting to debug server, please wait...");
> 229:             agent.attach(remoteMachineName);
> 230:             this.remoteMachineName = remoteMachineName;

I'm a little surprised to see that there is already some support for connecting to a debug server in CLHSDB.java. Was it previously used from anywhere?

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HSDB.java line 436:

> 434:     // and coreFilename is the pathname of a core file we are
> 435:     // supposed to attach to.
> 436:     // Finally, if remoteMachineName != null, we are supposed to connect to remote debug server.

Split into 2 lines.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HSDB.java line 84:

> 82:   private String execPath;
> 83:   private String coreFilename;
> 84:   private String remoteMachineName;

`debugServerName` or `remoteDebugServerName`

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HSDB.java line 100:

> 98:     execPath = null;
> 99:     coreFilename = null;
> 100:     remoteMachineName = null;

In general it's not clear to me why HSDB.java needed to be modified in a way similar to CLHSDB.java. If the goal is really just to add debug server support to the `clshdb attach` command, why is HSDB involved in that? Or is this adding debug server support elsewhere also (in which case it's not clear to me where this exposed to the user)?

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

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

From dholmes at openjdk.java.net  Tue Mar  2 23:25:08 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 2 Mar 2021 23:25:08 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v23]
In-Reply-To: <ciwAT0uB2sME-WzcDx96ipa1QHDFCeru1pO847cdBrY=.a7f895c7-e7ed-45ce-babd-c9ba2f955dda@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <ciwAT0uB2sME-WzcDx96ipa1QHDFCeru1pO847cdBrY=.a7f895c7-e7ed-45ce-babd-c9ba2f955dda@github.com>
Message-ID: <sL7Ru9rbNmfzeX-14ZZdvyVzmjIn3R-NCZypqjU5Amk=.7a077954-920c-46f0-bae2-b646e9b1b6ae@github.com>

On Tue, 2 Mar 2021 21:19:18 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Fix after JDK-8259539, partially revert preconditions
>  - JDK-8260471: bsd_aarch64 part
>  - JDK-8259539: bsd_aarch64 part
>  - JDK-8257828: bsd_aarch64 part
>  - Cleanup os_bsd_aarch64 signal handling

src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 207:

> 205:   // Enable WXWrite: this function is called by the signal handler at arbitrary
> 206:   // point of execution.
> 207:   ThreadWXEnable wx(WXWrite, thread);

Note that `thread` can be NULL here if the signal handler is running in a non-attached thread.

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

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

From iveresov at openjdk.java.net  Tue Mar  2 23:45:52 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Tue, 2 Mar 2021 23:45:52 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v8]
In-Reply-To: <iylzykfLo0f1M6-gUT5hzGpRnnJl9Gc9pGt0JEHJvOQ=.cc45edbd-7b6c-4255-8abd-a7be042248a1@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <Ul6OJXuqVlRZxy7OxB0SRre44bZaZAg7e757hdZf34A=.37ac8cdd-c438-436b-9f84-6176f329b735@github.com>
 <BK_Hrgo8M4wvyn-KOU71LYk4F3S2a_UUGmVDFg2eZWI=.2884c27f-41e4-4aae-97a5-f00fd932446b@github.com>
 <BADanxAzCxhsHJdQzYoLUgWpuGRtLN2K-t34iFUcjBk=.e140b7c9-39f1-498d-abde-f98fd6d2b6f1@github.com>
 <iylzykfLo0f1M6-gUT5hzGpRnnJl9Gc9pGt0JEHJvOQ=.cc45edbd-7b6c-4255-8abd-a7be042248a1@github.com>
Message-ID: <1rk73X6FOYTSZ353R5Qb1QytcIwwtZg5341d-vTqvhQ=.9e21e448-b4bb-4ded-9544-ef44b56375c5@github.com>

On Tue, 2 Mar 2021 21:08:38 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> I see that you've fixed the types since the last comment, but it think it's still broken (and has been before).
>> How about:
>> int64_t diff =  ((*b)->compiled_invocation_count() - (*a)->compiled_invocation_count()) + ((*b)->invocation_count() - (*a)->invocation_count());
>> if (diff > 0) return 1;
>> else if (diff < 0) return -1;
>> else return 0;
>> It's kind of hacky too, because it assumes that compiled_invocation_count() are positive and didn't overflow. But at least we'd get rid of a possible overflow during summation. What do you think?
>
> Right. As soon as there is overflow, the original formula doesn't do the trick either.
> We can fix it as long as either (unsigned int)invocation_count() does not wrap around from 2^32-1 to 0. The entire expression is calculated as int64_t, protecting us from overflow for the next few years. If we then calculate the return value as you propose, we are good.

In your new code here casts to uint32_t are probably unnecessary.

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

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

From ysuenaga at openjdk.java.net  Wed Mar  3 02:10:39 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 3 Mar 2021 02:10:39 GMT
Subject: RFR: 8262520: Add CLHSDB command to connect to debug server [v3]
In-Reply-To: <ucA3-g3HcHbQ5uZ1Mc_hBrFSK17l2iavHr95CEsNJkM=.805874ca-b7cc-4b01-9761-c70b8e795b5a@github.com>
References: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
 <WKq-Wmomp8PNGWUKS_Sp6Aa0wYg9mzdkunPrsQKrMK8=.fbfda9d9-f383-4c48-a0ac-d08a37086c27@github.com>
 <ucA3-g3HcHbQ5uZ1Mc_hBrFSK17l2iavHr95CEsNJkM=.805874ca-b7cc-4b01-9761-c70b8e795b5a@github.com>
Message-ID: <jz-gUBiK7JBGarhJoQDcTTzP44aZKMTRC8dInFhtyvA=.d517c6dc-0500-470b-8b2a-7cc0febc9632@github.com>

On Tue, 2 Mar 2021 22:31:22 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This pre-existing code in CLHSDB.java is a little concerning:
> 
> ```
> 127     private void doUsage() {
> 128         System.out.println("Usage:  java CLHSDB [[pid] | [path-to-java-executable [path-to-corefile]] | help ]");
> 129         System.out.println("           pid:                     attach to the process whose id is 'pid'");
> 130         System.out.println("           path-to-java-executable: Debug a core file produced by this program");
> 131         System.out.println("           path-to-corefile:        Debug this corefile.  The default is 'core'");
> 132         System.out.println("        If no arguments are specified, you can select what to do from the GUI.\n");
> 133         HotSpotAgent.showUsage();
> 134     }
> ```
> 
> First concern is that you have not added "debug server" support to it. 2nd concern is the "If no arguments are specified, you can select what to do from the GUI" part. It looks like using the GUI you can launch the CLHSDB console, although I can't find in the source where/how that is actually done. In any case, i don't see any way to pass command arguments when you do that.

I just added the feature to connect to debug server, so I did not change `CLHSDB(String[] args)` and help message.
I think it should be changed when we add `--connect` option to `jhsdb clhsdb`. (I will work for it after this PR)

> 
> I'm just wondering how much of this CLHSDB support we want to keep beyond what the clhsdb command needs. Do we still want to support invoking CLHSDB.main() from the java command line?

I think we should remove `main()` from CLHSDB/HSDB to be honest because they are called from SALauncher, and we cannot call them directly because they are not exported in module-info.

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

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

From ysuenaga at openjdk.java.net  Wed Mar  3 02:29:18 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 3 Mar 2021 02:29:18 GMT
Subject: RFR: 8262520: Add CLHSDB command to connect to debug server [v4]
In-Reply-To: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
References: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
Message-ID: <XSdMZAv25RdKGm5DBouj127sKNVKDEqXjYgQbIr8RHA=.0431c363-350b-4972-b3cd-8012247f2a27@github.com>

> `attach` command on CLHSDB supports to attach live process (PID) and coredump, but it cannot connect to debug server. CLHSDB does not have a command to connect to debug server.
> 
> Other jhsdb commands (jstack, jmap, etc...) can connect debug server via `--connect` option, so CLHSDB should connect to it.
> 
> After this change, you can connect to debug server with 'connect <hostname>'.

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Fix comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2773/files
  - new: https://git.openjdk.java.net/jdk/pull/2773/files/10feed4d..01a30e70

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

  Stats: 31 lines in 4 files changed: 2 ins; 0 del; 29 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2773.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2773/head:pull/2773

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

From ysuenaga at openjdk.java.net  Wed Mar  3 02:29:20 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 3 Mar 2021 02:29:20 GMT
Subject: RFR: 8262520: Add CLHSDB command to connect to debug server [v3]
In-Reply-To: <ucA3-g3HcHbQ5uZ1Mc_hBrFSK17l2iavHr95CEsNJkM=.805874ca-b7cc-4b01-9761-c70b8e795b5a@github.com>
References: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
 <WKq-Wmomp8PNGWUKS_Sp6Aa0wYg9mzdkunPrsQKrMK8=.fbfda9d9-f383-4c48-a0ac-d08a37086c27@github.com>
 <ucA3-g3HcHbQ5uZ1Mc_hBrFSK17l2iavHr95CEsNJkM=.805874ca-b7cc-4b01-9761-c70b8e795b5a@github.com>
Message-ID: <XTR_qXwhHxBBtcOM6ClM7u2KdjyOtVznnX4ktSXnDvI=.a8eda847-8c8e-48a0-981c-e91e0a52a65a@github.com>

On Tue, 2 Mar 2021 21:48:30 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comments
>
> src/jdk.hotspot.agent/doc/clhsdb.html line 39:
> 
>> 37: Available commands:
>> 38:   assert true | false <font color="red">turn on/off asserts in SA code</font>
>> 39:   attach pid | exec core | remote_server  <font color="red">attach SA to a process, core, or remote debug server</font>
> 
> The `jhsdb` help says `jhsdb jstack --connect debugserver`, so maybe `debug_server` would be better than `remote_server`. I think "remote debug server" in the help text is fine.

Fixed it in new commit.

> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CLHSDB.java line 53:
> 
>> 51:         // and coreFilename is the pathname of a core file we are
>> 52:         // supposed to attach to.
>> 53:         // Finally, if remoteMachineName != null, we are supposed to connect to remote debug server.
> 
> Split this line so its length is more consistent with the previous lines.

Fixed it in new commit.

> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CLHSDB.java line 125:
> 
>> 123:     private String execPath;
>> 124:     private String coreFilename;
>> 125:     private String remoteMachineName;
> 
> I think `debugServerName` or `remoteDebugServerName` would be better.

Rename to `debugServerName` in new commit.

> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CLHSDB.java line 230:
> 
>> 228:             System.out.println("Connecting to debug server, please wait...");
>> 229:             agent.attach(remoteMachineName);
>> 230:             this.remoteMachineName = remoteMachineName;
> 
> I'm a little surprised to see that there is already some support for connecting to a debug server in CLHSDB.java. Was it previously used from anywhere?

I cannot find out caller of `CLHSDB::connect`. I guess CLHSDB.java is copied from HSDB.java because they are similar - HSDB uses `connect()` to connect to debug server.

> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HSDB.java line 84:
> 
>> 82:   private String execPath;
>> 83:   private String coreFilename;
>> 84:   private String remoteMachineName;
> 
> `debugServerName` or `remoteDebugServerName`

Rename to `debugServerName` in new commit.

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

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

From ysuenaga at openjdk.java.net  Wed Mar  3 02:34:39 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 3 Mar 2021 02:34:39 GMT
Subject: RFR: 8262520: Add CLHSDB command to connect to debug server [v3]
In-Reply-To: <ucA3-g3HcHbQ5uZ1Mc_hBrFSK17l2iavHr95CEsNJkM=.805874ca-b7cc-4b01-9761-c70b8e795b5a@github.com>
References: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
 <WKq-Wmomp8PNGWUKS_Sp6Aa0wYg9mzdkunPrsQKrMK8=.fbfda9d9-f383-4c48-a0ac-d08a37086c27@github.com>
 <ucA3-g3HcHbQ5uZ1Mc_hBrFSK17l2iavHr95CEsNJkM=.805874ca-b7cc-4b01-9761-c70b8e795b5a@github.com>
Message-ID: <wd6oPSynx2DtdDmRNmCehucTiNtI_TTy8R-YaZfVKrY=.46b37b06-244e-4d73-bb40-075621238e6c@github.com>

On Tue, 2 Mar 2021 22:24:17 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comments
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HSDB.java line 100:
> 
>> 98:     execPath = null;
>> 99:     coreFilename = null;
>> 100:     remoteMachineName = null;
> 
> In general it's not clear to me why HSDB.java needed to be modified in a way similar to CLHSDB.java. If the goal is really just to add debug server support to the `clshdb attach` command, why is HSDB involved in that? Or is this adding debug server support elsewhere also (in which case it's not clear to me where this exposed to the user)?

As I said in above, CLHSDB.java and HSDB.java are similar, and also I added `attach(String debugServerName)` to `CommandProcessor$DebuggerInterface` which is used in HSDB.java, so I changed HSDB.java even though it does not affect to HSDB.

We can implement `attach(String debugServerName)` as empty method, and it might be reasonable. What do you think?

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

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

From lzang at openjdk.java.net  Wed Mar  3 07:23:58 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 3 Mar 2021 07:23:58 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out
Message-ID: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>

8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out

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

Commit messages:
 - code refine
 - 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out

Changes: https://git.openjdk.java.net/jdk/pull/2803/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2803&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262386
  Stats: 86 lines in 2 files changed: 59 ins; 5 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2803.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2803/head:pull/2803

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

From mbaesken at openjdk.java.net  Wed Mar  3 07:44:52 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 3 Mar 2021 07:44:52 GMT
Subject: Integrated: JDK-8262466: linux libsaproc/DwarfParser.cpp delete
 DwarfParser object in early return
In-Reply-To: <BiateiitsH2blICs1ZAcVYPjzUhXiChtQVtTac6U4-w=.15bcbfc2-be75-4961-b95f-9198fd08e991@github.com>
References: <BiateiitsH2blICs1ZAcVYPjzUhXiChtQVtTac6U4-w=.15bcbfc2-be75-4961-b95f-9198fd08e991@github.com>
Message-ID: <ptHJaA-XoPp-_ps-PMTcyZ_RueUS7Sxz_Hwmur5D-7E=.c20d9c50-c754-49bc-ae91-9b6f819029b9@github.com>

On Tue, 2 Mar 2021 12:34:35 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There is an early return in Java_sun_jvm_hotspot_debugger_linux_amd64_DwarfParser_createDwarfContext that misses to delete the non-parsable parser object.
> see also the Sonar finding :
> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=cpp&open=AXck8Ca-BBG2CXpcnimn&resolved=false&severities=BLOCKER&types=BUG

This pull request has now been integrated.

Changeset: 0265ab63
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0265ab63
Stats:     5 lines in 1 file changed: 1 ins; 2 del; 2 mod

8262466: linux libsaproc/DwarfParser.cpp delete DwarfParser object in early return

Reviewed-by: ysuenaga, kevinw

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

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

From dholmes at openjdk.java.net  Wed Mar  3 10:23:06 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 3 Mar 2021 10:23:06 GMT
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code
Message-ID: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>

ObjectMonitors can only be used by JavaThreads (modulo some interactions with hashcodes and deflation) but we use "Thread*" almost everywhere mainly due to use of TRAPS (and TRAPS will itself use JavaThread once JDK-8252685 is done). Also some uses of TRAPS in the API's are wrong as, for example, monitor entry can never throw an exception.

So this cleanup tackles:
- remove incorrect use of TRAPS
- change "Thread*" to "JavaThread*" where applicable
- don't use THREAD for things not related to exception processing
- standardise the naming so that we have "JavaThread* current" rather a mix if Self/THREAD/jt etc.
- remove unnecessary as_Java_thread() conversions
- other misc cleanup I noticed in some functions

The cleanup is predominantly in objectMonitor.* and synchronizer.* but with a fan out to the users of those APIs. No attempt is made to cleanup the callers beyond ensuring we have a suitable JavaThread reference for the calls. 

Thanks,
David

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

Commit messages:
 - Forgot to updated Graal config for JVMCI structs change
 - 8262910: Cleanup THREAD/TRAPS/naming and typing issues in ObjectMonitor and related code

Changes: https://git.openjdk.java.net/jdk/pull/2802/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2802&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262910
  Stats: 515 lines in 18 files changed: 15 ins; 58 del; 442 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2802.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2802/head:pull/2802

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

From lucy at openjdk.java.net  Wed Mar  3 13:22:17 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Wed, 3 Mar 2021 13:22:17 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v9]
In-Reply-To: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
Message-ID: <khnyiyNk7GcQCvEgMJKE90UQ8g02kN9Lkcm0S4-FuVw=.4b18cbfc-818f-431d-a327-4aaf328cba95@github.com>

> Dear community,
> may I please request reviews for this fix, improving the usefulness of method invocation counters.
> - aggregation counters are retyped as uint64_t, shifting the overflow probability way out (> 500 years in case of a 1 GHz counter update frequency).
> - counters for individual methods are interpreted as (unsigned int), in contrast to their declaration as int. This gives us a factor of two before the counters overflow.
> - as a special case, "compiled_invocation_counter" is retyped as long, because it has a higher update frequency than other counters.
> - before/after sample output is attached to the bug description. 
> 
> Thank you!
> Lutz

Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:

  Changes requested by veresov

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2511/files
  - new: https://git.openjdk.java.net/jdk/pull/2511/files/e8af119b..5c27640f

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

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

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

From lucy at openjdk.java.net  Wed Mar  3 13:28:21 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Wed, 3 Mar 2021 13:28:21 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v10]
In-Reply-To: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
Message-ID: <NVcbueC4LdqmzU8seEI2TlWaK7nvEogh0NYxMZ_0MNs=.23ddea4b-e4c7-4d6e-adbb-cc7183c52b81@github.com>

> Dear community,
> may I please request reviews for this fix, improving the usefulness of method invocation counters.
> - aggregation counters are retyped as uint64_t, shifting the overflow probability way out (> 500 years in case of a 1 GHz counter update frequency).
> - counters for individual methods are interpreted as (unsigned int), in contrast to their declaration as int. This gives us a factor of two before the counters overflow.
> - as a special case, "compiled_invocation_counter" is retyped as long, because it has a higher update frequency than other counters.
> - before/after sample output is attached to the bug description. 
> 
> Thank you!
> Lutz

Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:

  revert copyright change to get rid of unchanged file

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2511/files
  - new: https://git.openjdk.java.net/jdk/pull/2511/files/5c27640f..0faea5aa

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

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

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

From lucy at openjdk.java.net  Wed Mar  3 13:28:25 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Wed, 3 Mar 2021 13:28:25 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v2]
In-Reply-To: <8B4V-lAbFWqYJzdcbVyz69U05GX14vFRx6nY-tKorNU=.4dff6316-f85e-4578-ae59-2dab8d804627@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <ekO55Wt9H4U56-RG0c42FihkWP2gy-JhC-hoTRxjCgU=.c6c77076-11f5-4a30-8934-707c07fd70db@github.com>
 <8B4V-lAbFWqYJzdcbVyz69U05GX14vFRx6nY-tKorNU=.4dff6316-f85e-4578-ae59-2dab8d804627@github.com>
Message-ID: <wfuXR_8BU3PAnzHuWiS3hNiQEgrZFEFH1QOHH1CwGWY=.3f97eb11-6735-4d80-9e00-9a8a77715247@github.com>

On Tue, 2 Mar 2021 20:01:22 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8261447: requested changes by TobiHartmann
>
> Changes requested by iveresov (Reviewer).

@veresov 
@vnkozlov 
Thank you again for the discussion yesterday. I have pushed the resulting changes for you to review. Awaiting your comments...

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

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

From iveresov at openjdk.java.net  Wed Mar  3 15:25:41 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Wed, 3 Mar 2021 15:25:41 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v10]
In-Reply-To: <NVcbueC4LdqmzU8seEI2TlWaK7nvEogh0NYxMZ_0MNs=.23ddea4b-e4c7-4d6e-adbb-cc7183c52b81@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <NVcbueC4LdqmzU8seEI2TlWaK7nvEogh0NYxMZ_0MNs=.23ddea4b-e4c7-4d6e-adbb-cc7183c52b81@github.com>
Message-ID: <f3TiJDi2NZwlMfPr-O2ETdD5uLnhwJqqB_iU3jt_ocA=.51a5a31b-4fdb-4554-b8bc-d1aefc1be0c5@github.com>

On Wed, 3 Mar 2021 13:28:21 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> Dear community,
>> may I please request reviews for this fix, improving the usefulness of method invocation counters.
>> - aggregation counters are retyped as uint64_t, shifting the overflow probability way out (> 500 years in case of a 1 GHz counter update frequency).
>> - counters for individual methods are interpreted as (unsigned int), in contrast to their declaration as int. This gives us a factor of two before the counters overflow.
>> - as a special case, "compiled_invocation_counter" is retyped as long, because it has a higher update frequency than other counters.
>> - before/after sample output is attached to the bug description. 
>> 
>> Thank you!
>> Lutz
>
> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert copyright change to get rid of unchanged file

This looks good to me.

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

Marked as reviewed by iveresov (Reviewer).

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

From lucy at openjdk.java.net  Wed Mar  3 15:59:48 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Wed, 3 Mar 2021 15:59:48 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v10]
In-Reply-To: <f3TiJDi2NZwlMfPr-O2ETdD5uLnhwJqqB_iU3jt_ocA=.51a5a31b-4fdb-4554-b8bc-d1aefc1be0c5@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <NVcbueC4LdqmzU8seEI2TlWaK7nvEogh0NYxMZ_0MNs=.23ddea4b-e4c7-4d6e-adbb-cc7183c52b81@github.com>
 <f3TiJDi2NZwlMfPr-O2ETdD5uLnhwJqqB_iU3jt_ocA=.51a5a31b-4fdb-4554-b8bc-d1aefc1be0c5@github.com>
Message-ID: <TGHp4s50_I7DCStTPDF9AmZZhcZPqygpzs9oIHSm6Lw=.ddf4710d-f96f-4100-b139-6a05b1c33aac@github.com>

On Wed, 3 Mar 2021 15:22:58 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert copyright change to get rid of unchanged file
>
> This looks good to me.

Thank you, Igor!

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

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

From gziemski at openjdk.java.net  Wed Mar  3 16:00:00 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Wed, 3 Mar 2021 16:00:00 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v23]
In-Reply-To: <sL7Ru9rbNmfzeX-14ZZdvyVzmjIn3R-NCZypqjU5Amk=.7a077954-920c-46f0-bae2-b646e9b1b6ae@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <ciwAT0uB2sME-WzcDx96ipa1QHDFCeru1pO847cdBrY=.a7f895c7-e7ed-45ce-babd-c9ba2f955dda@github.com>
 <sL7Ru9rbNmfzeX-14ZZdvyVzmjIn3R-NCZypqjU5Amk=.7a077954-920c-46f0-bae2-b646e9b1b6ae@github.com>
Message-ID: <SaFPzYzpXuZFUYhDvGg6PQHM-EUrSqbR02H5SzL6OvI=.77d3186b-74a5-404a-950f-95af6a13dabd@github.com>

On Tue, 2 Mar 2021 23:21:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Note that `thread` can be NULL here if the signal handler is running in a non-attached thread. If we then perform:
> `ThreadWXEnable(WXMode new_mode, Thread* thread = NULL) : _thread(thread ? thread : Thread::current()),`
> we call Thread::current() on a non-attached thread and that will assert/crash if we get NULL. Either avoid using WX when the thread is NULL, or else change to use Thread::current_or_null_safe() and ensure all uses have a NULL check.

https://bugs.openjdk.java.net/browse/JDK-8262903 tracks this issue.

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

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

From coleenp at openjdk.java.net  Wed Mar  3 16:22:40 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 3 Mar 2021 16:22:40 GMT
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code
In-Reply-To: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
Message-ID: <9jH0cOue9iImW1rlDFazv1hldqc03qu6JSHScSWL1wI=.2c340a01-324f-447e-828c-ffa9f41cb853@github.com>

On Wed, 3 Mar 2021 05:15:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

> ObjectMonitors can only be used by JavaThreads (modulo some interactions with hashcodes and deflation) but we use "Thread*" almost everywhere mainly due to use of TRAPS (and TRAPS will itself use JavaThread once JDK-8252685 is done). Also some uses of TRAPS in the API's are wrong as, for example, monitor entry can never throw an exception.
> 
> So this cleanup tackles:
> - remove incorrect use of TRAPS
> - change "Thread*" to "JavaThread*" where applicable
> - don't use THREAD for things not related to exception processing
> - standardise the naming so that we have "JavaThread* current" rather a mix if Self/THREAD/jt etc.
> - remove unnecessary as_Java_thread() conversions
> - other misc cleanup I noticed in some functions
> 
> The cleanup is predominantly in objectMonitor.* and synchronizer.* but with a fan out to the users of those APIs. No attempt is made to cleanup the callers beyond ensuring we have a suitable JavaThread reference for the calls. 
> 
> Thanks,
> David

src/hotspot/share/runtime/objectMonitor.cpp line 1676:

> 1674: // we might just dequeue a thread from the WaitSet and directly unpark() it.
> 1675: 
> 1676: void ObjectMonitor::INotify(JavaThread * current) {

nit: space between JavaThread and star.

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

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

From coleenp at openjdk.java.net  Wed Mar  3 16:28:40 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 3 Mar 2021 16:28:40 GMT
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code
In-Reply-To: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
Message-ID: <AFnChy8qG_DR809bNN3Nyjpd52g7UQOzH0rBZirRll8=.1dfee132-23d4-435a-abf0-5677b4039d8e@github.com>

On Wed, 3 Mar 2021 05:15:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

> ObjectMonitors can only be used by JavaThreads (modulo some interactions with hashcodes and deflation) but we use "Thread*" almost everywhere mainly due to use of TRAPS (and TRAPS will itself use JavaThread once JDK-8252685 is done). Also some uses of TRAPS in the API's are wrong as, for example, monitor entry can never throw an exception.
> 
> So this cleanup tackles:
> - remove incorrect use of TRAPS
> - change "Thread*" to "JavaThread*" where applicable
> - don't use THREAD for things not related to exception processing
> - standardise the naming so that we have "JavaThread* current" rather a mix if Self/THREAD/jt etc.
> - remove unnecessary as_Java_thread() conversions
> - other misc cleanup I noticed in some functions
> 
> The cleanup is predominantly in objectMonitor.* and synchronizer.* but with a fan out to the users of those APIs. No attempt is made to cleanup the callers beyond ensuring we have a suitable JavaThread reference for the calls. 
> 
> Thanks,
> David

I think this change looks good.  I made some general comments on specific lines.

src/hotspot/share/runtime/synchronizer.hpp line 92:

> 90:   // This is the "slow path" version of monitor enter and exit.
> 91:   static void enter(Handle obj, BasicLock* lock, JavaThread* current);
> 92:   static void exit(oop obj, BasicLock* lock, TRAPS);

So are you suggesting that we should have the convention that if a function takes a Thread/JavaThread argument as the last argument, to use "current" rather than "THREAD", since the latter implies it is supposed to be used to pass an argument for the parameter to TRAPS?  I think this is good.  It manages some confusion about trailing THREAD arguments in some callers.  Specializing further to JavaThread from Thread is also a good change.

src/hotspot/share/runtime/synchronizer.hpp line 146:

> 144: 
> 145:   // Deflate idle monitors:
> 146:   static void chk_for_block_req(JavaThread* current, const char* op_name,

I like "current" better than "self" as a convention.

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

Marked as reviewed by coleenp (Reviewer).

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

From gziemski at openjdk.java.net  Wed Mar  3 17:56:15 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Wed, 3 Mar 2021 17:56:15 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <WlU-by8oEfoJIVOKjkhNLCPUuW4DdRMAFIO6PWIPzb4=.cbc4742c-d113-4d20-b5f3-9a42655f9b86@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <WlU-by8oEfoJIVOKjkhNLCPUuW4DdRMAFIO6PWIPzb4=.cbc4742c-d113-4d20-b5f3-9a42655f9b86@github.com>
Message-ID: <DFLFDkNJ30yiF-YpFG6-NtwDi1iYo__6EgymUpCsXiM=.a622ede5-cd91-44a9-9c93-bc81e25872b4@github.com>

On Tue, 2 Mar 2021 11:05:20 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> For platform files that were copied from other ports to this port, if the file wasn't
>> changed I presume the copyright years are left alone. If the file required changes
>> for this port, I expect the year to be updated to 2021. How are you verifying that
>> these copyright years are being properly managed on the new files?
>> 
>> For the new W^X helpers, e.g., WXWriteFromExecSetter, a short comment
>> explaining why one was landed in a particular place would help reviewers.
>> Also see my comment about creating a new ThreadToNativeWithWXExecFromVM
>> helper.
>> 
>> I'm stopping my review with all the src/hotspot files done for now.
>
>> For platform files that were copied from other ports to this port, if the file wasn't
>> changed I presume the copyright years are left alone. If the file required changes
>> for this port, I expect the year to be updated to 2021. How are you verifying that
>> these copyright years are being properly managed on the new files?
> 
> There are no exact copies, based on
> git -c diff.renameLimit=10000000 diff --find-copies-harder -C75% --name-status upstream/master...
> 
> So every file changed in the branch potentially needs the copyright update. All file diffs are not trivial, IMHO.
> 
> I'll run the copyright update after we fix a few remaining issues with the PR, to avoid updating copyright and changing/reverting the actual content.

A list of the bugs that our internal testing revealed so far:

https://bugs.openjdk.java.net/browse/JDK-8262952
https://bugs.openjdk.java.net/browse/JDK-8262894
https://bugs.openjdk.java.net/browse/JDK-8262895
https://bugs.openjdk.java.net/browse/JDK-8262896
https://bugs.openjdk.java.net/browse/JDK-8262897
https://bugs.openjdk.java.net/browse/JDK-8262898
https://bugs.openjdk.java.net/browse/JDK-8262899
https://bugs.openjdk.java.net/browse/JDK-8262900
https://bugs.openjdk.java.net/browse/JDK-8262901
https://bugs.openjdk.java.net/browse/JDK-8262903
https://bugs.openjdk.java.net/browse/JDK-8262904

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

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

From aph at openjdk.java.net  Wed Mar  3 17:56:15 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 3 Mar 2021 17:56:15 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <DFLFDkNJ30yiF-YpFG6-NtwDi1iYo__6EgymUpCsXiM=.a622ede5-cd91-44a9-9c93-bc81e25872b4@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <WlU-by8oEfoJIVOKjkhNLCPUuW4DdRMAFIO6PWIPzb4=.cbc4742c-d113-4d20-b5f3-9a42655f9b86@github.com>
 <DFLFDkNJ30yiF-YpFG6-NtwDi1iYo__6EgymUpCsXiM=.a622ede5-cd91-44a9-9c93-bc81e25872b4@github.com>
Message-ID: <2vF8YcQ9CgnLxMus9tHTd4HmFITeH5wddBKzH-QNNEY=.dbfb2cd5-5997-4b79-88a5-d8292fc56965@github.com>

On Wed, 3 Mar 2021 17:39:28 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> A list of the bugs that our internal testing revealed so far:

Are any of these blockers for integration? Some of them are to do with things like features that aren't yet supported, and we can't fix what we can't see.

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

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

From akozlov at openjdk.java.net  Wed Mar  3 19:13:59 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 3 Mar 2021 19:13:59 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <2vF8YcQ9CgnLxMus9tHTd4HmFITeH5wddBKzH-QNNEY=.dbfb2cd5-5997-4b79-88a5-d8292fc56965@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <WlU-by8oEfoJIVOKjkhNLCPUuW4DdRMAFIO6PWIPzb4=.cbc4742c-d113-4d20-b5f3-9a42655f9b86@github.com>
 <DFLFDkNJ30yiF-YpFG6-NtwDi1iYo__6EgymUpCsXiM=.a622ede5-cd91-44a9-9c93-bc81e25872b4@github.com>
 <2vF8YcQ9CgnLxMus9tHTd4HmFITeH5wddBKzH-QNNEY=.dbfb2cd5-5997-4b79-88a5-d8292fc56965@github.com>
Message-ID: <_eNysRZporueV4wITFZra8ng_O6dvxAIc0moIWOh95U=.bd3e669d-8efc-41e1-8fb2-e9f2f8e4d1f8@github.com>

On Wed, 3 Mar 2021 17:46:41 GMT, Andrew Haley <aph at openjdk.org> wrote:

> A list of the bugs that our internal testing revealed so far ...

Thank you! Some of them look like test issues, but a few need more serious consideration. I want to resolve https://bugs.openjdk.java.net/browse/JDK-8262903 at least, along with a few remaining comments.

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

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

From pchilanomate at openjdk.java.net  Wed Mar  3 19:26:40 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Wed, 3 Mar 2021 19:26:40 GMT
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code
In-Reply-To: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
Message-ID: <1KJvn-X7o7pVACivXUFqMiMICiUf-cUzqBqyN6HCscc=.57f72c5d-1565-4ab2-aa9d-daa424eccb8f@github.com>

On Wed, 3 Mar 2021 05:15:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

> ObjectMonitors can only be used by JavaThreads (modulo some interactions with hashcodes and deflation) but we use "Thread*" almost everywhere mainly due to use of TRAPS (and TRAPS will itself use JavaThread once JDK-8252685 is done). Also some uses of TRAPS in the API's are wrong as, for example, monitor entry can never throw an exception.
> 
> So this cleanup tackles:
> - remove incorrect use of TRAPS
> - change "Thread*" to "JavaThread*" where applicable
> - don't use THREAD for things not related to exception processing
> - standardise the naming so that we have "JavaThread* current" rather a mix if Self/THREAD/jt etc.
> - remove unnecessary as_Java_thread() conversions
> - other misc cleanup I noticed in some functions
> 
> The cleanup is predominantly in objectMonitor.* and synchronizer.* but with a fan out to the users of those APIs. No attempt is made to cleanup the callers beyond ensuring we have a suitable JavaThread reference for the calls. 
> 
> Thanks,
> David

Hi David,

Changes look good to me.

Thanks,
Patricio

src/hotspot/share/runtime/objectMonitor.hpp line 306:

> 304: 
> 305:   bool      enter(JavaThread* current);
> 306:   void      exit(bool not_suspended, TRAPS);

Shouldn't we also remove use of TRAPS for exit()? In case of unbalanced locking we don't throw IMSE, only just assert.

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

Marked as reviewed by pchilanomate (Committer).

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

From kvn at openjdk.java.net  Wed Mar  3 19:39:51 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 3 Mar 2021 19:39:51 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v10]
In-Reply-To: <NVcbueC4LdqmzU8seEI2TlWaK7nvEogh0NYxMZ_0MNs=.23ddea4b-e4c7-4d6e-adbb-cc7183c52b81@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <NVcbueC4LdqmzU8seEI2TlWaK7nvEogh0NYxMZ_0MNs=.23ddea4b-e4c7-4d6e-adbb-cc7183c52b81@github.com>
Message-ID: <wKLUz9Tz-Qr1JYK1-09Tj1hr8nPPXnyD1mwQVdoiJsI=.90a42e0c-6eb8-42d0-b633-62a4b80685e2@github.com>

On Wed, 3 Mar 2021 13:28:21 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> Dear community,
>> may I please request reviews for this fix, improving the usefulness of method invocation counters.
>> - aggregation counters are retyped as uint64_t, shifting the overflow probability way out (> 500 years in case of a 1 GHz counter update frequency).
>> - counters for individual methods are interpreted as (unsigned int), in contrast to their declaration as int. This gives us a factor of two before the counters overflow.
>> - as a special case, "compiled_invocation_counter" is retyped as long, because it has a higher update frequency than other counters.
>> - before/after sample output is attached to the bug description. 
>> 
>> Thank you!
>> Lutz
>
> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert copyright change to get rid of unchanged file

Good.

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

Marked as reviewed by kvn (Reviewer).

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

From lucy at openjdk.java.net  Wed Mar  3 20:07:42 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Wed, 3 Mar 2021 20:07:42 GMT
Subject: Integrated: 8261447: MethodInvocationCounters frequently run into
 overflow
In-Reply-To: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
Message-ID: <14vfJddqmWgxR50iw7eBSCMzNqTdxvHvkbHJm-7Xo4Q=.667af6eb-0a18-4a2a-8bce-b26facf856ca@github.com>

On Wed, 10 Feb 2021 16:28:29 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

> Dear community,
> may I please request reviews for this fix, improving the usefulness of method invocation counters.
> - aggregation counters are retyped as uint64_t, shifting the overflow probability way out (> 500 years in case of a 1 GHz counter update frequency).
> - counters for individual methods are interpreted as (unsigned int), in contrast to their declaration as int. This gives us a factor of two before the counters overflow.
> - as a special case, "compiled_invocation_counter" is retyped as long, because it has a higher update frequency than other counters.
> - before/after sample output is attached to the bug description. 
> 
> Thank you!
> Lutz

This pull request has now been integrated.

Changeset: 268d9b79
Author:    Lutz Schmidt <lucy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/268d9b79
Stats:     164 lines in 11 files changed: 51 ins; 4 del; 109 mod

8261447: MethodInvocationCounters frequently run into overflow

Reviewed-by: thartmann, mdoerr, kvn, iveresov

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

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

From lucy at openjdk.java.net  Wed Mar  3 20:07:42 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Wed, 3 Mar 2021 20:07:42 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v10]
In-Reply-To: <wKLUz9Tz-Qr1JYK1-09Tj1hr8nPPXnyD1mwQVdoiJsI=.90a42e0c-6eb8-42d0-b633-62a4b80685e2@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <NVcbueC4LdqmzU8seEI2TlWaK7nvEogh0NYxMZ_0MNs=.23ddea4b-e4c7-4d6e-adbb-cc7183c52b81@github.com>
 <wKLUz9Tz-Qr1JYK1-09Tj1hr8nPPXnyD1mwQVdoiJsI=.90a42e0c-6eb8-42d0-b633-62a4b80685e2@github.com>
Message-ID: <ufu6bReEUP1tyQobwYxLGJVBqTa_wp-VJXJz6hiW0vQ=.7c78ec59-1da4-41a1-8a0e-e2b1c970dc19@github.com>

On Wed, 3 Mar 2021 19:36:41 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert copyright change to get rid of unchanged file
>
> Good.

Thank you, Vladimir!

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

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

From cjplummer at openjdk.java.net  Wed Mar  3 20:09:56 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 3 Mar 2021 20:09:56 GMT
Subject: RFR: 8243455: Many SA tests can fail due to trying to get the stack
 trace of an active method
Message-ID: <vjDRMVH6jMQsafl_UZTsf0Fglcx89foITgIg4Zhmawo=.f98f3f01-53d3-4613-8c54-67b9f2d34215@github.com>

Many tests run `LingeredApp`, get its stack with `jstack`, and then look for `LingeredApp.main` in the output, which should appear in the stack trace of the main thread. Usually this works fine since the main thread is in a loop, and usually blocked in `Thread.sleep()`. However, during the short period of time it wakes up from sleep, the thread's stack might not be walk-able, in which case the `LingeredApp.main` frame will not appear, and the tests looking for it will fail.

The fix is to introduce a new thread called `SteadyStateThread` that has a method called `steadyState()` that blocks indefinitely trying to synchronize on a locked object. All code that used to look for `LingeredApp.main` in the output now instead looks for `LingeredApp.steadyState`, which should always be there. I'm open to suggestions for a better name than "SteadyState" if you have one.

There are a few special cases with the tests that were modified that are described below:

Regarding the removal of `LingeredAppWithTrivialMain.java`, it was originally added to fix [JDK-8229118](https://bugs.openjdk.java.net/browse/JDK-8229118), which was an issue with the `ClhsdbFindPC` test failing on aarch64 when doing the `-Xcomp` run. It expected `LingeredApp.main()` to be compiled in that case, and for the PC of the frame to be in an `NMethod`. However, on aarch64 an uncommon-trap was causing it to be de-optimized, so the PC was in the interpreter instead, causing the test to fail. The fix was to instead rely on finding a trivial `LingeredAppWithTrivialMain.main()` frame in the stack trace since it would always be compiled. With the changes to instead have (and rely on) the `SteadyStateThread` and the presence of `LingeredApp.steadyState()`, the need for `LingeredAppWithTrivialMain` goes away. `LingeredApp.steadyState()` will always be compiled, even on aarch64.

Regarding `DebugdConnectTest.java`, it is listed in the CR as an affected test but no specified fix has been provided.
 None is needed. The issue was that it looked for `LingeredApp` in the jstack output, and it used to be the only place it would find it was in the main thread's stack trace, which sometimes could not be retrieved. Now it can also be found in the `SteadyStateThread`'s stack trace, which can always be retrieved.

Regarding `HeapDumpTest.java`, it used to check for `LingeredAppWithExtendedChars.main` and now it checks for `LingeredApp.steadyState`. It still is run with `LingeredAppWithExtendedChars`. The only thing special about that class is that it contains an extended unicode character used to reproduce [JDK-8028623](https://bugs.openjdk.java.net/browse/JDK-8028623), so it will still do that, even though it now checks for `LingeredApp.steadyState`.

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

Commit messages:
 - Use full name of SteadStateThread
 - Create and use SteadyStateThread stack for jstack queries.

Changes: https://git.openjdk.java.net/jdk/pull/2700/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2700&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8243455
  Stats: 119 lines in 11 files changed: 43 ins; 36 del; 40 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2700.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2700/head:pull/2700

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

From cjplummer at openjdk.java.net  Wed Mar  3 20:15:50 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 3 Mar 2021 20:15:50 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out
In-Reply-To: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
Message-ID: <Zvf7GN59hJdc7SgVRao3cEbcpU99CbGceULIfJnDJOE=.4bd79c51-6b9b-4ff9-9ada-dc43fd6ca6e8@github.com>

On Wed, 3 Mar 2021 07:01:46 GMT, Lin Zang <lzang at openjdk.org> wrote:

> 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out

The fix is fairly big and could use some explaining. Can you provide a bit more detail on what the bug is? In the CR you mention it is due to the combination of a very large array and the segmented heap dump support, but don't really explain what the actual bug is. You can add this detail to the CR rather than here.  Also can explain your solution, especially this new `writeThrough` mode? Thanks.

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

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

From lmesnik at openjdk.java.net  Wed Mar  3 20:16:37 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Wed, 3 Mar 2021 20:16:37 GMT
Subject: RFR: 8243455: Many SA tests can fail due to trying to get the
 stack trace of an active method
In-Reply-To: <vjDRMVH6jMQsafl_UZTsf0Fglcx89foITgIg4Zhmawo=.f98f3f01-53d3-4613-8c54-67b9f2d34215@github.com>
References: <vjDRMVH6jMQsafl_UZTsf0Fglcx89foITgIg4Zhmawo=.f98f3f01-53d3-4613-8c54-67b9f2d34215@github.com>
Message-ID: <EPr5_a4ucrPIqZwbPFfQFXnBfCVyQJ5-JjIA6ckogQY=.e021c282-9479-4aa6-9f6e-4badc1ae9221@github.com>

On Tue, 23 Feb 2021 23:34:31 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Many tests run `LingeredApp`, get its stack with `jstack`, and then look for `LingeredApp.main` in the output, which should appear in the stack trace of the main thread. Usually this works fine since the main thread is in a loop, and usually blocked in `Thread.sleep()`. However, during the short period of time it wakes up from sleep, the thread's stack might not be walk-able, in which case the `LingeredApp.main` frame will not appear, and the tests looking for it will fail.
> 
> The fix is to introduce a new thread called `SteadyStateThread` that has a method called `steadyState()` that blocks indefinitely trying to synchronize on a locked object. All code that used to look for `LingeredApp.main` in the output now instead looks for `LingeredApp.steadyState`, which should always be there. I'm open to suggestions for a better name than "SteadyState" if you have one.
> 
> There are a few special cases with the tests that were modified that are described below:
> 
> Regarding the removal of `LingeredAppWithTrivialMain.java`, it was originally added to fix [JDK-8229118](https://bugs.openjdk.java.net/browse/JDK-8229118), which was an issue with the `ClhsdbFindPC` test failing on aarch64 when doing the `-Xcomp` run. It expected `LingeredApp.main()` to be compiled in that case, and for the PC of the frame to be in an `NMethod`. However, on aarch64 an uncommon-trap was causing it to be de-optimized, so the PC was in the interpreter instead, causing the test to fail. The fix was to instead rely on finding a trivial `LingeredAppWithTrivialMain.main()` frame in the stack trace since it would always be compiled. With the changes to instead have (and rely on) the `SteadyStateThread` and the presence of `LingeredApp.steadyState()`, the need for `LingeredAppWithTrivialMain` goes away. `LingeredApp.steadyState()` will always be compiled, even on aarch64.
> 
> Regarding `DebugdConnectTest.java`, it is listed in the CR as an affected test but no specified fix has been provided.
>  None is needed. The issue was that it looked for `LingeredApp` in the jstack output, and it used to be the only place it would find it was in the main thread's stack trace, which sometimes could not be retrieved. Now it can also be found in the `SteadyStateThread`'s stack trace, which can always be retrieved.
> 
> Regarding `HeapDumpTest.java`, it used to check for `LingeredAppWithExtendedChars.main` and now it checks for `LingeredApp.steadyState`. It still is run with `LingeredAppWithExtendedChars`. The only thing special about that class is that it contains an extended unicode character used to reproduce [JDK-8028623](https://bugs.openjdk.java.net/browse/JDK-8028623), so it will still do that, even though it now checks for `LingeredApp.steadyState`.

Marked as reviewed by lmesnik (Committer).

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

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

From cjplummer at openjdk.java.net  Wed Mar  3 21:31:02 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 3 Mar 2021 21:31:02 GMT
Subject: RFR: 8262486: Merge trivial JDWP agent changes from the loom repo to
 the jdk repo
Message-ID: <yHmko3VNeYOAz1V_gPdX6-12LRFibJEiOqu5L8frFEs=.7094c811-fc00-4c3c-bc53-788a3c225f74@github.com>

In the loom repo there are a number of trivial changes to the JDWP agent that are not loom specific. Moving them to the jdk repo will make future merges simpler, along with making it easier to get a diff of the important differences between the loom and jdk repos, without the clutter of these trivial changes. The changes I'd like to merge are:

1. Very minor code refactoring.
2. Comment additions, fixes, and improvements.
3. Minor indentation and whitespace changes.
4. Added a trivial assert

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

Commit messages:
 - Minor jdwp agent edits from loom project.

Changes: https://git.openjdk.java.net/jdk/pull/2815/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2815&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262486
  Stats: 79 lines in 7 files changed: 37 ins; 4 del; 38 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2815.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2815/head:pull/2815

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

From david.holmes at oracle.com  Wed Mar  3 22:08:49 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 4 Mar 2021 08:08:49 +1000
Subject: RFR: 8243455: Many SA tests can fail due to trying to get the
 stack trace of an active method
In-Reply-To: <vjDRMVH6jMQsafl_UZTsf0Fglcx89foITgIg4Zhmawo=.f98f3f01-53d3-4613-8c54-67b9f2d34215@github.com>
References: <vjDRMVH6jMQsafl_UZTsf0Fglcx89foITgIg4Zhmawo=.f98f3f01-53d3-4613-8c54-67b9f2d34215@github.com>
Message-ID: <4a06743b-ee1c-69b4-587c-697650283cb2@oracle.com>

Hi Chris,

On 4/03/2021 6:09 am, Chris Plummer wrote:
> Many tests run `LingeredApp`, get its stack with `jstack`, and then look for `LingeredApp.main` in the output, which should appear in the stack trace of the main thread. Usually this works fine since the main thread is in a loop, and usually blocked in `Thread.sleep()`. However, during the short period of time it wakes up from sleep, the thread's stack might not be walk-able, in which case the `LingeredApp.main` frame will not appear, and the tests looking for it will fail.

Doesn't jstack force all threads to be walkable via a safepoint or 
handshake?

David
-----

> The fix is to introduce a new thread called `SteadyStateThread` that has a method called `steadyState()` that blocks indefinitely trying to synchronize on a locked object. All code that used to look for `LingeredApp.main` in the output now instead looks for `LingeredApp.steadyState`, which should always be there. I'm open to suggestions for a better name than "SteadyState" if you have one.
> 
> There are a few special cases with the tests that were modified that are described below:
> 
> Regarding the removal of `LingeredAppWithTrivialMain.java`, it was originally added to fix [JDK-8229118](https://bugs.openjdk.java.net/browse/JDK-8229118), which was an issue with the `ClhsdbFindPC` test failing on aarch64 when doing the `-Xcomp` run. It expected `LingeredApp.main()` to be compiled in that case, and for the PC of the frame to be in an `NMethod`. However, on aarch64 an uncommon-trap was causing it to be de-optimized, so the PC was in the interpreter instead, causing the test to fail. The fix was to instead rely on finding a trivial `LingeredAppWithTrivialMain.main()` frame in the stack trace since it would always be compiled. With the changes to instead have (and rely on) the `SteadyStateThread` and the presence of `LingeredApp.steadyState()`, the need for `LingeredAppWithTrivialMain` goes away. `LingeredApp.steadyState()` will always be compiled, even on aarch64.
> 
> Regarding `DebugdConnectTest.java`, it is listed in the CR as an affected test but no specified fix has been provided.
>   None is needed. The issue was that it looked for `LingeredApp` in the jstack output, and it used to be the only place it would find it was in the main thread's stack trace, which sometimes could not be retrieved. Now it can also be found in the `SteadyStateThread`'s stack trace, which can always be retrieved.
> 
> Regarding `HeapDumpTest.java`, it used to check for `LingeredAppWithExtendedChars.main` and now it checks for `LingeredApp.steadyState`. It still is run with `LingeredAppWithExtendedChars`. The only thing special about that class is that it contains an extended unicode character used to reproduce [JDK-8028623](https://bugs.openjdk.java.net/browse/JDK-8028623), so it will still do that, even though it now checks for `LingeredApp.steadyState`.
> 
> -------------
> 
> Commit messages:
>   - Use full name of SteadStateThread
>   - Create and use SteadyStateThread stack for jstack queries.
> 
> Changes: https://git.openjdk.java.net/jdk/pull/2700/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2700&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8243455
>    Stats: 119 lines in 11 files changed: 43 ins; 36 del; 40 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/2700.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/2700/head:pull/2700
> 
> PR: https://git.openjdk.java.net/jdk/pull/2700
> 

From cjplummer at openjdk.java.net  Wed Mar  3 22:22:57 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 3 Mar 2021 22:22:57 GMT
Subject: RFR: 8262520: Add CLHSDB command to connect to debug server [v3]
In-Reply-To: <wd6oPSynx2DtdDmRNmCehucTiNtI_TTy8R-YaZfVKrY=.46b37b06-244e-4d73-bb40-075621238e6c@github.com>
References: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
 <WKq-Wmomp8PNGWUKS_Sp6Aa0wYg9mzdkunPrsQKrMK8=.fbfda9d9-f383-4c48-a0ac-d08a37086c27@github.com>
 <ucA3-g3HcHbQ5uZ1Mc_hBrFSK17l2iavHr95CEsNJkM=.805874ca-b7cc-4b01-9761-c70b8e795b5a@github.com>
 <wd6oPSynx2DtdDmRNmCehucTiNtI_TTy8R-YaZfVKrY=.46b37b06-244e-4d73-bb40-075621238e6c@github.com>
Message-ID: <lKtrdFS0WFISgVXKujzG-O2eNfOF0KR5Jb0GTfJd_Os=.2455c3fa-9933-4bda-b5e0-fcd1f44cce66@github.com>

On Wed, 3 Mar 2021 02:32:04 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HSDB.java line 100:
>> 
>>> 98:     execPath = null;
>>> 99:     coreFilename = null;
>>> 100:     remoteMachineName = null;
>> 
>> In general it's not clear to me why HSDB.java needed to be modified in a way similar to CLHSDB.java. If the goal is really just to add debug server support to the `clshdb attach` command, why is HSDB involved in that? Or is this adding debug server support elsewhere also (in which case it's not clear to me where this exposed to the user)?
>
> As I said in above, CLHSDB.java and HSDB.java are similar, and also I added `attach(String debugServerName)` to `CommandProcessor$DebuggerInterface` which is used in HSDB.java, so I changed HSDB.java even though it does not affect to HSDB.
> 
> We can implement `attach(String debugServerName)` as empty method, and it might be reasonable. What do you think?

I see now. Both HSDB and CLHSDB implement CommandProcessor$DebuggerInterface, and they pass an instance of this class to the CommandProcessor constructor, and that allows CommandProcessor to do callbacks for the attach (or connect). Given this, it looks like you do want to add support for all 3 attach modes to the HSDB CommandProcessor$DebuggerInterface implementation. Otherwise you won't be able to attach to a debug server when you bring up the command line support using the HSDB gui.

What's been confusing, and I'm finally starting to understand, is that CommandProcessor is the SA command line support, and clhsdb (CLHSDB) and hsdb (HSDB) both use CommandProcessor to provide the command line support to the user. Maybe you should re-purpose this CR/PR as "Add SA CommandProcessor support to connect to debug server", and make sure the CR talks about how this impacts both clhsdb and hsdb.

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

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

From cjplummer at openjdk.java.net  Wed Mar  3 22:35:40 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 3 Mar 2021 22:35:40 GMT
Subject: RFR: 8262520: Add CLHSDB command to connect to debug server [v3]
In-Reply-To: <jz-gUBiK7JBGarhJoQDcTTzP44aZKMTRC8dInFhtyvA=.d517c6dc-0500-470b-8b2a-7cc0febc9632@github.com>
References: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
 <WKq-Wmomp8PNGWUKS_Sp6Aa0wYg9mzdkunPrsQKrMK8=.fbfda9d9-f383-4c48-a0ac-d08a37086c27@github.com>
 <ucA3-g3HcHbQ5uZ1Mc_hBrFSK17l2iavHr95CEsNJkM=.805874ca-b7cc-4b01-9761-c70b8e795b5a@github.com>
 <jz-gUBiK7JBGarhJoQDcTTzP44aZKMTRC8dInFhtyvA=.d517c6dc-0500-470b-8b2a-7cc0febc9632@github.com>
Message-ID: <VQfP5xNEzkwAAGijCdtqZMMX7E1FM--kJ3Uq1u-DhmY=.63c39432-54fc-4e1d-b4dc-88560faa8b35@github.com>

On Wed, 3 Mar 2021 02:08:15 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I think we should remove `main()` from CLHSDB/HSDB to be honest because they are called from SALauncher, and we cannot call them directly because they are not exported in module-info.

Yes, I'm starting to come to the same conclusion. The only code that constructs a `CLHSDB` object, and therefore triggers the potential call to `doUsage()`, is `CLHSDB.main()`, and it is only called from `SALauncher` when using `jhsdb clhsdb`. We could get rid of `main()` and have some other entrypoint that is passed the values of all the possible options, rather than having to parse them in CLHSDB.java.

There is one test invokes java with the `CLHSDB` class. See SABase.java. It's part of ciReplay testing. I think it would be easily modified to just run `jhsdb clhsdb`

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

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

From cjplummer at openjdk.java.net  Wed Mar  3 22:40:39 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 3 Mar 2021 22:40:39 GMT
Subject: RFR: 8243455: Many SA tests can fail due to trying to get the
 stack trace of an active method
In-Reply-To: <EPr5_a4ucrPIqZwbPFfQFXnBfCVyQJ5-JjIA6ckogQY=.e021c282-9479-4aa6-9f6e-4badc1ae9221@github.com>
References: <vjDRMVH6jMQsafl_UZTsf0Fglcx89foITgIg4Zhmawo=.f98f3f01-53d3-4613-8c54-67b9f2d34215@github.com>
 <EPr5_a4ucrPIqZwbPFfQFXnBfCVyQJ5-JjIA6ckogQY=.e021c282-9479-4aa6-9f6e-4badc1ae9221@github.com>
Message-ID: <vk55a1YRzNRvFtjHmu5n0Ag_EPLxp0w4cRsZ7oDa54s=.695f6000-48f9-43c7-9150-193c895ab5a5@github.com>

On Wed, 3 Mar 2021 20:13:56 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Many tests run `LingeredApp`, get its stack with `jstack`, and then look for `LingeredApp.main` in the output, which should appear in the stack trace of the main thread. Usually this works fine since the main thread is in a loop, and usually blocked in `Thread.sleep()`. However, during the short period of time it wakes up from sleep, the thread's stack might not be walk-able, in which case the `LingeredApp.main` frame will not appear, and the tests looking for it will fail.
>> 
>> The fix is to introduce a new thread called `SteadyStateThread` that has a method called `steadyState()` that blocks indefinitely trying to synchronize on a locked object. All code that used to look for `LingeredApp.main` in the output now instead looks for `LingeredApp.steadyState`, which should always be there. I'm open to suggestions for a better name than "SteadyState" if you have one.
>> 
>> There are a few special cases with the tests that were modified that are described below:
>> 
>> Regarding the removal of `LingeredAppWithTrivialMain.java`, it was originally added to fix [JDK-8229118](https://bugs.openjdk.java.net/browse/JDK-8229118), which was an issue with the `ClhsdbFindPC` test failing on aarch64 when doing the `-Xcomp` run. It expected `LingeredApp.main()` to be compiled in that case, and for the PC of the frame to be in an `NMethod`. However, on aarch64 an uncommon-trap was causing it to be de-optimized, so the PC was in the interpreter instead, causing the test to fail. The fix was to instead rely on finding a trivial `LingeredAppWithTrivialMain.main()` frame in the stack trace since it would always be compiled. With the changes to instead have (and rely on) the `SteadyStateThread` and the presence of `LingeredApp.steadyState()`, the need for `LingeredAppWithTrivialMain` goes away. `LingeredApp.steadyState()` will always be compiled, even on aarch64.
>> 
>> Regarding `DebugdConnectTest.java`, it is listed in the CR as an affected test but no specified fix has been provided.
>>  None is needed. The issue was that it looked for `LingeredApp` in the jstack output, and it used to be the only place it would find it was in the main thread's stack trace, which sometimes could not be retrieved. Now it can also be found in the `SteadyStateThread`'s stack trace, which can always be retrieved.
>> 
>> Regarding `HeapDumpTest.java`, it used to check for `LingeredAppWithExtendedChars.main` and now it checks for `LingeredApp.steadyState`. It still is run with `LingeredAppWithExtendedChars`. The only thing special about that class is that it contains an extended unicode character used to reproduce [JDK-8028623](https://bugs.openjdk.java.net/browse/JDK-8028623), so it will still do that, even though it now checks for `LingeredApp.steadyState`.
>
> Marked as reviewed by lmesnik (Committer).

> Doesn't jstack force all threads to be walkable via a safepoint or
> handshake?

Nope. If it did it couldn't debug core files or a hung process. That's why SA has so much code to safe guard against walking off the deep end when doing things like stack walking and heap scanning.

BTW, you might be thinking of the Attach API version of `jstack`, which does safepoint. These tests all involve the SA version of `jstack`.

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

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

From cjplummer at openjdk.java.net  Wed Mar  3 22:44:42 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 3 Mar 2021 22:44:42 GMT
Subject: RFR: 8262520: Add CLHSDB command to connect to debug server [v4]
In-Reply-To: <XSdMZAv25RdKGm5DBouj127sKNVKDEqXjYgQbIr8RHA=.0431c363-350b-4972-b3cd-8012247f2a27@github.com>
References: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
 <XSdMZAv25RdKGm5DBouj127sKNVKDEqXjYgQbIr8RHA=.0431c363-350b-4972-b3cd-8012247f2a27@github.com>
Message-ID: <EfcbklnAv2PP_2FiQHBgo56xfSGnvIlAnJbcJlPxLXw=.670253d6-dd7d-4632-a14f-9fa760ef2c0c@github.com>

On Wed, 3 Mar 2021 02:29:18 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> `attach` command on CLHSDB supports to attach live process (PID) and coredump, but it cannot connect to debug server. CLHSDB does not have a command to connect to debug server.
>> 
>> Other jhsdb commands (jstack, jmap, etc...) can connect debug server via `--connect` option, so CLHSDB should connect to it.
>> 
>> After this change, you can connect to debug server with 'connect <hostname>'.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comments

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CLHSDB.java line 236:

> 234:         catch (DebuggerException e) {
> 235:             final String errMsg = formatMessage(e.getMessage(), 80);
> 236:             System.err.println("Unable to connect to machine \"" + debugServerName + "\":\n\n" + errMsg);

"machine" -> "debug server"

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

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

From david.holmes at oracle.com  Wed Mar  3 22:52:17 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 4 Mar 2021 08:52:17 +1000
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code
In-Reply-To: <9jH0cOue9iImW1rlDFazv1hldqc03qu6JSHScSWL1wI=.2c340a01-324f-447e-828c-ffa9f41cb853@github.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
 <9jH0cOue9iImW1rlDFazv1hldqc03qu6JSHScSWL1wI=.2c340a01-324f-447e-828c-ffa9f41cb853@github.com>
Message-ID: <f6683c74-dabc-5f91-c097-205c10fb1975@oracle.com>

Hi Coleen,

Thanks for looking at this.

On 4/03/2021 2:22 am, Coleen Phillimore wrote:
> 
> src/hotspot/share/runtime/objectMonitor.cpp line 1676:
> 
>> 1674: // we might just dequeue a thread from the WaitSet and directly unpark() it.
>> 1675:
>> 1676: void ObjectMonitor::INotify(JavaThread * current) {
> 
> nit: space between JavaThread and star.

Fixed - and a couple of other cases too.

David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/2802
> 

From david.holmes at oracle.com  Wed Mar  3 22:56:56 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 4 Mar 2021 08:56:56 +1000
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code
In-Reply-To: <AFnChy8qG_DR809bNN3Nyjpd52g7UQOzH0rBZirRll8=.1dfee132-23d4-435a-abf0-5677b4039d8e@github.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
 <AFnChy8qG_DR809bNN3Nyjpd52g7UQOzH0rBZirRll8=.1dfee132-23d4-435a-abf0-5677b4039d8e@github.com>
Message-ID: <060f3820-2400-ad61-195d-5f615422de25@oracle.com>

On 4/03/2021 2:28 am, Coleen Phillimore wrote:
> I think this change looks good.  I made some general comments on specific lines.

Thanks.

> src/hotspot/share/runtime/synchronizer.hpp line 92:
> 
>> 90:   // This is the "slow path" version of monitor enter and exit.
>> 91:   static void enter(Handle obj, BasicLock* lock, JavaThread* current);
>> 92:   static void exit(oop obj, BasicLock* lock, TRAPS);
> 
> So are you suggesting that we should have the convention that if a function takes a Thread/JavaThread argument as the last argument, to use "current" rather than "THREAD", since the latter implies it is supposed to be used to pass an argument for the parameter to TRAPS?  I think this is good.  It manages some confusion about trailing THREAD arguments in some callers.  Specializing further to JavaThread from Thread is also a good change.

Yes. As discussed with Ioi, ideally if you see a call:

foo(..., THREAD);

then you should be able to say "Aha! foo is a TRAPS function that can 
propagate an exception, but the calling code needs to do some special 
handling so isn't using CHECK or CATCH". We are a long way from that due 
to incidental uses of THREAD for convenience in things like ResourceMark 
construction within TRAPS functions.

Thanks,
David
-----

> src/hotspot/share/runtime/synchronizer.hpp line 146:
> 
>> 144:
>> 145:   // Deflate idle monitors:
>> 146:   static void chk_for_block_req(JavaThread* current, const char* op_name,
> 
> I like "current" better than "self" as a convention.
> 
> -------------
> 
> Marked as reviewed by coleenp (Reviewer).
> 
> PR: https://git.openjdk.java.net/jdk/pull/2802
> 

From david.holmes at oracle.com  Wed Mar  3 22:58:20 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 4 Mar 2021 08:58:20 +1000
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code
In-Reply-To: <1KJvn-X7o7pVACivXUFqMiMICiUf-cUzqBqyN6HCscc=.57f72c5d-1565-4ab2-aa9d-daa424eccb8f@github.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
 <1KJvn-X7o7pVACivXUFqMiMICiUf-cUzqBqyN6HCscc=.57f72c5d-1565-4ab2-aa9d-daa424eccb8f@github.com>
Message-ID: <264aebc1-5fe1-f060-3643-6e843c33c08b@oracle.com>

Hi Patricio,

Thanks for looking at this.

On 4/03/2021 5:26 am, Patricio Chilano Mateo wrote:
> Hi David,
> 
> Changes look good to me.
> 
> Thanks,
> Patricio
> 
> src/hotspot/share/runtime/objectMonitor.hpp line 306:
> 
>> 304:
>> 305:   bool      enter(JavaThread* current);
>> 306:   void      exit(bool not_suspended, TRAPS);
> 
> Shouldn't we also remove use of TRAPS for exit()? In case of unbalanced locking we don't throw IMSE, only just assert.

Good catch! (no pun intended). Yes I overlooked that was don't actually 
throw the IMSE in plain exit (in contrast to jni_exit).

Fixed.

Thanks,
David
-----

> -------------
> 
> Marked as reviewed by pchilanomate (Committer).
> 
> PR: https://git.openjdk.java.net/jdk/pull/2802
> 

From coleen.phillimore at oracle.com  Wed Mar  3 23:02:23 2021
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 3 Mar 2021 18:02:23 -0500
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code
In-Reply-To: <060f3820-2400-ad61-195d-5f615422de25@oracle.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
 <AFnChy8qG_DR809bNN3Nyjpd52g7UQOzH0rBZirRll8=.1dfee132-23d4-435a-abf0-5677b4039d8e@github.com>
 <060f3820-2400-ad61-195d-5f615422de25@oracle.com>
Message-ID: <ddaed60b-da47-9a01-adce-6c0670cd8e91@oracle.com>



On 3/3/21 5:56 PM, David Holmes wrote:
> On 4/03/2021 2:28 am, Coleen Phillimore wrote:
>> I think this change looks good.? I made some general comments on 
>> specific lines.
>
> Thanks.
>
>> src/hotspot/share/runtime/synchronizer.hpp line 92:
>>
>>> 90:?? // This is the "slow path" version of monitor enter and exit.
>>> 91:?? static void enter(Handle obj, BasicLock* lock, JavaThread* 
>>> current);
>>> 92:?? static void exit(oop obj, BasicLock* lock, TRAPS);
>>
>> So are you suggesting that we should have the convention that if a 
>> function takes a Thread/JavaThread argument as the last argument, to 
>> use "current" rather than "THREAD", since the latter implies it is 
>> supposed to be used to pass an argument for the parameter to TRAPS?? 
>> I think this is good.? It manages some confusion about trailing 
>> THREAD arguments in some callers. Specializing further to JavaThread 
>> from Thread is also a good change.
>
> Yes. As discussed with Ioi, ideally if you see a call:
>
> foo(..., THREAD);
>
> then you should be able to say "Aha! foo is a TRAPS function that can 
> propagate an exception, but the calling code needs to do some special 
> handling so isn't using CHECK or CATCH". We are a long way from that 
> due to incidental uses of THREAD for convenience in things like 
> ResourceMark construction within TRAPS functions.

Yes, but please don't change ResourceMark rm(THREAD) to something else.? 
It's not worth the churn and nobody is confused by it.
Coleen

>
> Thanks,
> David
> -----
>
>> src/hotspot/share/runtime/synchronizer.hpp line 146:
>>
>>> 144:
>>> 145:?? // Deflate idle monitors:
>>> 146:?? static void chk_for_block_req(JavaThread* current, const 
>>> char* op_name,
>>
>> I like "current" better than "self" as a convention.
>>
>> -------------
>>
>> Marked as reviewed by coleenp (Reviewer).
>>
>> PR: https://git.openjdk.java.net/jdk/pull/2802
>>


From dholmes at openjdk.java.net  Wed Mar  3 23:03:01 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 3 Mar 2021 23:03:01 GMT
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code [v2]
In-Reply-To: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
Message-ID: <RtvrU7X9v7f_Y42Rqq0NWHWX-rxFDgzcfnhX-A6-nBk=.18d602dd-2725-4d97-a7bf-a4f378659df4@github.com>

> ObjectMonitors can only be used by JavaThreads (modulo some interactions with hashcodes and deflation) but we use "Thread*" almost everywhere mainly due to use of TRAPS (and TRAPS will itself use JavaThread once JDK-8252685 is done). Also some uses of TRAPS in the API's are wrong as, for example, monitor entry can never throw an exception.
> 
> So this cleanup tackles:
> - remove incorrect use of TRAPS
> - change "Thread*" to "JavaThread*" where applicable
> - don't use THREAD for things not related to exception processing
> - standardise the naming so that we have "JavaThread* current" rather a mix if Self/THREAD/jt etc.
> - remove unnecessary as_Java_thread() conversions
> - other misc cleanup I noticed in some functions
> 
> The cleanup is predominantly in objectMonitor.* and synchronizer.* but with a fan out to the users of those APIs. No attempt is made to cleanup the callers beyond ensuring we have a suitable JavaThread reference for the calls. 
> 
> Thanks,
> David

David Holmes has updated the pull request incrementally with two additional commits since the last revision:

 - ObjectMonitor::exit can't actually throw IMSE so replaced TRAPS with JavaThread* current
 - Style fix: Thread *  -> Thread* in type declarations

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2802/files
  - new: https://git.openjdk.java.net/jdk/pull/2802/files/6e334d08..c764b038

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

  Stats: 18 lines in 5 files changed: 0 ins; 2 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2802.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2802/head:pull/2802

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

From dholmes at openjdk.java.net  Wed Mar  3 23:08:06 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 3 Mar 2021 23:08:06 GMT
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code [v3]
In-Reply-To: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
Message-ID: <t3mKAu_gO1j2Aslw952xIm5DuiEWGAN1YBPZG2_5ckI=.90023947-cf48-4ffa-bb22-5f7db5887dfd@github.com>

> ObjectMonitors can only be used by JavaThreads (modulo some interactions with hashcodes and deflation) but we use "Thread*" almost everywhere mainly due to use of TRAPS (and TRAPS will itself use JavaThread once JDK-8252685 is done). Also some uses of TRAPS in the API's are wrong as, for example, monitor entry can never throw an exception.
> 
> So this cleanup tackles:
> - remove incorrect use of TRAPS
> - change "Thread*" to "JavaThread*" where applicable
> - don't use THREAD for things not related to exception processing
> - standardise the naming so that we have "JavaThread* current" rather a mix if Self/THREAD/jt etc.
> - remove unnecessary as_Java_thread() conversions
> - other misc cleanup I noticed in some functions
> 
> The cleanup is predominantly in objectMonitor.* and synchronizer.* but with a fan out to the users of those APIs. No attempt is made to cleanup the callers beyond ensuring we have a suitable JavaThread reference for the calls. 
> 
> Thanks,
> David

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  More pointer declaration style fixups

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2802/files
  - new: https://git.openjdk.java.net/jdk/pull/2802/files/c764b038..e8a66366

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

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

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

From amenkov at openjdk.java.net  Wed Mar  3 23:27:40 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 3 Mar 2021 23:27:40 GMT
Subject: RFR: 8262486: Merge trivial JDWP agent changes from the loom repo
 to the jdk repo
In-Reply-To: <yHmko3VNeYOAz1V_gPdX6-12LRFibJEiOqu5L8frFEs=.7094c811-fc00-4c3c-bc53-788a3c225f74@github.com>
References: <yHmko3VNeYOAz1V_gPdX6-12LRFibJEiOqu5L8frFEs=.7094c811-fc00-4c3c-bc53-788a3c225f74@github.com>
Message-ID: <q97rkkUpQ5LjPdlYUYjbx4blMeZkYSjAiqCA1Rdj58U=.c972f7b8-46b6-45ba-92e4-eda1ea4a3184@github.com>

On Wed, 3 Mar 2021 20:17:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> In the loom repo there are a number of trivial changes to the JDWP agent that are not loom specific. Moving them to the jdk repo will make future merges simpler, along with making it easier to get a diff of the important differences between the loom and jdk repos, without the clutter of these trivial changes. The changes I'd like to merge are:
> 
> 1. Very minor code refactoring.
> 2. Comment additions, fixes, and improvements.
> 3. Minor indentation and whitespace changes.
> 4. Added a trivial assert

Marked as reviewed by amenkov (Reviewer).

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

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

From cjplummer at openjdk.java.net  Wed Mar  3 23:45:40 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 3 Mar 2021 23:45:40 GMT
Subject: RFR: 8262504: Some CLHSDB command cannot know they run on remote
 debugger
In-Reply-To: <hYYLenPIpA840x3tcc3ZikUiZKdJB3mSuxDs00dFdQo=.62e3707c-c3f8-48ab-8d1e-d5b7d42661d4@github.com>
References: <hYYLenPIpA840x3tcc3ZikUiZKdJB3mSuxDs00dFdQo=.62e3707c-c3f8-48ab-8d1e-d5b7d42661d4@github.com>
Message-ID: <q07Z4YLPgqOIrzp1XEA3d4LpdlN-vVQDFprZ38AEhyc=.5a5752b7-445a-4427-baa7-0d21fc4e8ba4@github.com>

On Sun, 28 Feb 2021 13:18:21 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> `pmap` and `pstack` CLHSDB command do not work on remote debugger, we can see following error message:
> 
> hsdb> pmap
> not yet implemented (debugger does not support CDebugger)!
> 
> However, SA has different message for this purpose:
> 
> https://github.com/openjdk/jdk/blob/03d888f463c0a6e3fee70ed8ad606fc0a3082636/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PMap.java#L74-L78
> 
> SA should show "remote configuration is not yet implemented" when it works on remote debugger.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/Tool.java line 69:

> 67:       }
> 68:    }
> 69: 

This section seems to be the key to your changes, but I have to admit that I don't follow how it all ties in together. Maybe you can explain the overall structure of the Tool subclasses to help explain. They seem to be overloaded with modes that make it hard to follow all the logic. For example, you've added the `Tool(HotSpotAgent agent)` constructor, and we already have `Tool()` and `Tool(JVMDebugger d)`. It's unclear to me what the use case is for each. Also, we have about 10 subclasses of Tool. Why do only `PMap` an `PStack` need this new constructor.

BTW, looking at Tool and its subclasses has made me realize we have a hole other area of historical tool baggage, similar to what we are discussing with CLHSDB and HSDB. My guess is all these tool subclasses used to be invoked directly from the java command line. Now they are all hidden behind `jhsdb` subcommands, but still carry the old java command line support. In addition, when adding `jhsdb` and it's subcommands, it looks like there was an effort to mimic the existing Attach API commands like jmap and jinfo, so the SA versions of these commands have multiple modes which invoke different Tool subclasses. For example, `jhdsb jmap` alone can invoke the ClassLoaderStats, FinalizerInfo, ObjectHistogram, PMap, and HeapSummary tools, in addition to dumping the heap graph in HProf or GXL format. I think things would have been simpler and cleaner if each of these were made separate `jhsdb` subcommands, but it's probably too late for that. I suppose we could deprecate the existing sub-com
 mands and add all these new  sub-commands, but that will just make things harder for us until the old commands are eventually removed, which might never happen.

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

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

From lmesnik at openjdk.java.net  Wed Mar  3 23:55:55 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Wed, 3 Mar 2021 23:55:55 GMT
Subject: RFR: 8262486: Merge trivial JDWP agent changes from the loom repo
 to the jdk repo
In-Reply-To: <yHmko3VNeYOAz1V_gPdX6-12LRFibJEiOqu5L8frFEs=.7094c811-fc00-4c3c-bc53-788a3c225f74@github.com>
References: <yHmko3VNeYOAz1V_gPdX6-12LRFibJEiOqu5L8frFEs=.7094c811-fc00-4c3c-bc53-788a3c225f74@github.com>
Message-ID: <QHRyHc24pgGs7BcDQr4jSufjsFQs4ITDtmJDSRWWTTc=.2d978d9a-fe3b-4cc6-94f8-85771cc9df31@github.com>

On Wed, 3 Mar 2021 20:17:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> In the loom repo there are a number of trivial changes to the JDWP agent that are not loom specific. Moving them to the jdk repo will make future merges simpler, along with making it easier to get a diff of the important differences between the loom and jdk repos, without the clutter of these trivial changes. The changes I'd like to merge are:
> 
> 1. Very minor code refactoring.
> 2. Comment additions, fixes, and improvements.
> 3. Minor indentation and whitespace changes.
> 4. Added a trivial assert

Marked as reviewed by lmesnik (Committer).

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

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

From ysuenaga at openjdk.java.net  Thu Mar  4 00:02:04 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 4 Mar 2021 00:02:04 GMT
Subject: RFR: 8262520: Add CLHSDB command to connect to debug server [v5]
In-Reply-To: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
References: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
Message-ID: <I5WiKMcEMkjKZi26juD8rXLkeYKuiMAoKpX8vkv7ybk=.33803423-5ffc-4ec5-a022-85ae8196d7a5@github.com>

> `attach` command on CLHSDB supports to attach live process (PID) and coredump, but it cannot connect to debug server. CLHSDB does not have a command to connect to debug server.
> 
> Other jhsdb commands (jstack, jmap, etc...) can connect debug server via `--connect` option, so CLHSDB should connect to it.
> 
> After this change, you can connect to debug server with 'connect <hostname>'.

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Update error message in CLHSDB

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2773/files
  - new: https://git.openjdk.java.net/jdk/pull/2773/files/01a30e70..59d2dd00

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2773&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2773&range=03-04

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

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

From amenkov at openjdk.java.net  Thu Mar  4 00:40:40 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 4 Mar 2021 00:40:40 GMT
Subject: Integrated: 8224775: test/jdk/com/sun/jdi/JdwpListenTest.java failed
 to attach
In-Reply-To: <pRiX1N1rR7NYrKg4y4BmHmB4vtRpCO0fVEZH0NMgkaM=.219d5434-25b9-4d5d-945a-27aaedefb6d2@github.com>
References: <pRiX1N1rR7NYrKg4y4BmHmB4vtRpCO0fVEZH0NMgkaM=.219d5434-25b9-4d5d-945a-27aaedefb6d2@github.com>
Message-ID: <StADlM7cTZ-mQc7RXahrdPzcjzI70r8_K0UrKwmusdQ=.091f08fa-f06b-4867-8b75-4d7196c361b7@github.com>

On Thu, 18 Feb 2021 21:43:00 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix also partially fixes JdwpAttachTest failures (JDK-8253940).
> The failures are caused by network configuration changes during test execution ("global" IPv6 addresses disappears from interface).
> To minimize chances of intermittent failures like this java.net tests use only link-local addresses whenever possible.
> The fix does the same for JDI tests (Utils.getAddressesWithSymbolicAndNumericScopes  is used by JdwpListenTest and JdwpAttachTest)

This pull request has now been integrated.

Changeset: 104a2628
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/104a2628
Stats:     14 lines in 1 file changed: 3 ins; 0 del; 11 mod

8224775: test/jdk/com/sun/jdi/JdwpListenTest.java failed to attach

Reviewed-by: sspitsyn, dfuchs

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

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

From amenkov at openjdk.java.net  Thu Mar  4 00:43:53 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 4 Mar 2021 00:43:53 GMT
Subject: Integrated: 8253940: com/sun/jdi/JdwpAttachTest.java failed with
 "RuntimeException: ERROR: LingeredApp.startApp was able to attach"
In-Reply-To: <HBuZ978kLXLgllYPgBTv7q9_L9MWcAxkh3oqzw-EC2Y=.03e5f605-978b-472b-a56d-b280c4645242@github.com>
References: <HBuZ978kLXLgllYPgBTv7q9_L9MWcAxkh3oqzw-EC2Y=.03e5f605-978b-472b-a56d-b280c4645242@github.com>
Message-ID: <jqsMX6_us4mGkwszKtVC1-bboPUIKRbqxJPY7iF0RTA=.a0d627bf-3c26-48ee-ab70-40cac25bec89@github.com>

On Fri, 19 Feb 2021 20:10:14 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Failures related to "no route to host" and "cannot bind to address" errors are covered by https://git.openjdk.java.net/jdk/pull/2633
> 
> This change fixes failures with listening on IPv6 loopback and attaching to "localhost" (the test connects to some other process which listens on the same port on IPv4 loopback and as a result gets "handshake failed - received >< - expected >JDWP-Handshake<" error)

This pull request has now been integrated.

Changeset: d93fa0d6
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d93fa0d6
Stats:     21 lines in 1 file changed: 16 ins; 0 del; 5 mod

8253940: com/sun/jdi/JdwpAttachTest.java failed with "RuntimeException: ERROR: LingeredApp.startApp was able to attach"

Reviewed-by: cjplummer, lmesnik

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

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

From ysuenaga at openjdk.java.net  Thu Mar  4 01:09:47 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 4 Mar 2021 01:09:47 GMT
Subject: RFR: 8262520: Add SA CommandProcessor support to connect to debug
 server [v3]
In-Reply-To: <lKtrdFS0WFISgVXKujzG-O2eNfOF0KR5Jb0GTfJd_Os=.2455c3fa-9933-4bda-b5e0-fcd1f44cce66@github.com>
References: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
 <WKq-Wmomp8PNGWUKS_Sp6Aa0wYg9mzdkunPrsQKrMK8=.fbfda9d9-f383-4c48-a0ac-d08a37086c27@github.com>
 <ucA3-g3HcHbQ5uZ1Mc_hBrFSK17l2iavHr95CEsNJkM=.805874ca-b7cc-4b01-9761-c70b8e795b5a@github.com>
 <wd6oPSynx2DtdDmRNmCehucTiNtI_TTy8R-YaZfVKrY=.46b37b06-244e-4d73-bb40-075621238e6c@github.com>
 <lKtrdFS0WFISgVXKujzG-O2eNfOF0KR5Jb0GTfJd_Os=.2455c3fa-9933-4bda-b5e0-fcd1f44cce66@github.com>
Message-ID: <lGz87WzLMZe5t4Vl0GF1RfTjhvOKJeF8qRKuKHV0oy4=.9d64d308-0764-4136-bca2-e463e15f91cd@github.com>

On Wed, 3 Mar 2021 22:20:12 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> As I said in above, CLHSDB.java and HSDB.java are similar, and also I added `attach(String debugServerName)` to `CommandProcessor$DebuggerInterface` which is used in HSDB.java, so I changed HSDB.java even though it does not affect to HSDB.
>> 
>> We can implement `attach(String debugServerName)` as empty method, and it might be reasonable. What do you think?
>
> I see now. Both HSDB and CLHSDB implement CommandProcessor$DebuggerInterface, and they pass an instance of this class to the CommandProcessor constructor, and that allows CommandProcessor to do callbacks for the attach (or connect). Given this, it looks like you do want to add support for all 3 attach modes to the HSDB CommandProcessor$DebuggerInterface implementation. Otherwise you won't be able to attach to a debug server when you bring up the command line support using the HSDB gui.
> 
> What's been confusing, and I'm finally starting to understand, is that CommandProcessor is the SA command line support, and clhsdb (CLHSDB) and hsdb (HSDB) both use CommandProcessor to provide the command line support to the user. Maybe you should re-purpose this CR/PR as "Add SA CommandProcessor support to connect to debug server", and make sure the CR talks about how this impacts both clhsdb and hsdb.

I've updated subject both CR and PR, and also I updated description in JBS.

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

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

From ysuenaga at openjdk.java.net  Thu Mar  4 01:09:48 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 4 Mar 2021 01:09:48 GMT
Subject: RFR: 8262520: Add SA CommandProcessor support to connect to debug
 server [v4]
In-Reply-To: <EfcbklnAv2PP_2FiQHBgo56xfSGnvIlAnJbcJlPxLXw=.670253d6-dd7d-4632-a14f-9fa760ef2c0c@github.com>
References: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
 <XSdMZAv25RdKGm5DBouj127sKNVKDEqXjYgQbIr8RHA=.0431c363-350b-4972-b3cd-8012247f2a27@github.com>
 <EfcbklnAv2PP_2FiQHBgo56xfSGnvIlAnJbcJlPxLXw=.670253d6-dd7d-4632-a14f-9fa760ef2c0c@github.com>
Message-ID: <ZJL6QiQJuDqSGsd-ycTp2I0P7d8mcv4EOdWiz1ORi4A=.1d84ff66-de00-4706-b8cf-1fd3efdce7e2@github.com>

On Wed, 3 Mar 2021 22:42:14 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comments
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CLHSDB.java line 236:
> 
>> 234:         catch (DebuggerException e) {
>> 235:             final String errMsg = formatMessage(e.getMessage(), 80);
>> 236:             System.err.println("Unable to connect to machine \"" + debugServerName + "\":\n\n" + errMsg);
> 
> "machine" -> "debug server"

I fixed it in new commit.

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

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

From ysuenaga at openjdk.java.net  Thu Mar  4 01:13:04 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 4 Mar 2021 01:13:04 GMT
Subject: RFR: 8262520: Add SA CommandProcessor support to connect to debug
 server [v3]
In-Reply-To: <VQfP5xNEzkwAAGijCdtqZMMX7E1FM--kJ3Uq1u-DhmY=.63c39432-54fc-4e1d-b4dc-88560faa8b35@github.com>
References: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
 <WKq-Wmomp8PNGWUKS_Sp6Aa0wYg9mzdkunPrsQKrMK8=.fbfda9d9-f383-4c48-a0ac-d08a37086c27@github.com>
 <ucA3-g3HcHbQ5uZ1Mc_hBrFSK17l2iavHr95CEsNJkM=.805874ca-b7cc-4b01-9761-c70b8e795b5a@github.com>
 <jz-gUBiK7JBGarhJoQDcTTzP44aZKMTRC8dInFhtyvA=.d517c6dc-0500-470b-8b2a-7cc0febc9632@github.com>
 <VQfP5xNEzkwAAGijCdtqZMMX7E1FM--kJ3Uq1u-DhmY=.63c39432-54fc-4e1d-b4dc-88560faa8b35@github.com>
Message-ID: <tD2uKX3i6AGpD2hpeiPG4tbMSqdny4hSsTvSNjHp5To=.343731d9-2bd0-444f-920b-059563211e8f@github.com>

On Wed, 3 Mar 2021 22:33:19 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Yes, I'm starting to come to the same conclusion. The only code that constructs a `CLHSDB` object, and therefore triggers the potential call to `doUsage()`, is `CLHSDB.main()`, and it is only called from `SALauncher` when using `jhsdb clhsdb`. We could get rid of `main()` and have some other entrypoint that is passed the values of all the possible options, rather than having to parse them in CLHSDB.java.
> 
> There is one test invokes java with the `CLHSDB` class. See SABase.java. It's part of ciReplay testing. I think it would be easily modified to just run `jhsdb clhsdb`

I think `debugd` and `jinfo` are also remove `main()` if they have because they do not provide commands like `jstack`.
I will file it to JBS, and will fix them later.

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

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

From ysuenaga at openjdk.java.net  Thu Mar  4 02:11:55 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 4 Mar 2021 02:11:55 GMT
Subject: RFR: 8262504: Some CLHSDB command cannot know they run on remote
 debugger
In-Reply-To: <q07Z4YLPgqOIrzp1XEA3d4LpdlN-vVQDFprZ38AEhyc=.5a5752b7-445a-4427-baa7-0d21fc4e8ba4@github.com>
References: <hYYLenPIpA840x3tcc3ZikUiZKdJB3mSuxDs00dFdQo=.62e3707c-c3f8-48ab-8d1e-d5b7d42661d4@github.com>
 <q07Z4YLPgqOIrzp1XEA3d4LpdlN-vVQDFprZ38AEhyc=.5a5752b7-445a-4427-baa7-0d21fc4e8ba4@github.com>
Message-ID: <BS-vUqZg1ZRkbMTy-cETWRc6NDKvNai5IkJEeVD65Cc=.d9aaf849-40d0-45ac-b46c-dc8206e04207@github.com>

On Wed, 3 Mar 2021 23:42:31 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This section seems to be the key to your changes, but I have to admit that I don't follow how it all ties in together. Maybe you can explain the overall structure of the Tool subclasses to help explain. They seem to be overloaded with modes that make it hard to follow all the logic. For example, you've added the `Tool(HotSpotAgent agent)` constructor, and we already have `Tool()` and `Tool(JVMDebugger d)`. It's unclear to me what the use case is for each. Also, we have about 10 subclasses of Tool. Why do only `PMap` an `PStack` need this new constructor.

All of traditional serviceability commands (jstack, jmap, etc...) seem to extend `Tool` because it has a function to parse commandline args and to attach debuggee commonly.
`Tool` supports several attach mechanism: `Tool()` supports attach debuggee manually, `Tool(JVMDebugger)` supports attach debuggee via available `JVMDegbugger`. `HotSpotAgent` communicates to debugee, so `Tool` would create its instance. Thus I added `Tool(HotSpotAgent)` to use available remote debug server.

AFAICS only `PMap` and `PStack` do not support remote debug server, so I changed for them.
(I plan to support `pmap` and `pstack` when we attach remote debug server, so it is important to know debuggee type.)

> BTW, looking at Tool and its subclasses has made me realize we have a whole other area of historical tool baggage, similar to what we are discussing with CLHSDB and HSDB. My guess is all these tool subclasses used to be invoked directly from the java command line. Now they are all hidden behind `jhsdb` subcommands, but still carry the old java command line support. In addition, when adding `jhsdb` and it's subcommands, it looks like there was an effort to mimic the existing Attach API commands like jmap and jinfo, so the SA versions of these commands have multiple modes which invoke different Tool subclasses. For example, `jhdsb jmap` alone can invoke the ClassLoaderStats, FinalizerInfo, ObjectHistogram, PMap, and HeapSummary tools, in addition to dumping the heap graph in HProf or GXL format. I think things would have been simpler and cleaner if each of these were made separate `jhsdb` subcommands, but it's probably too late for that. I suppose we could deprecate the existing sub-
 commands and add all these new sub-commands, but that will just make things harder for us until the old commands are eventually removed, which might never happen.

I agree with you it is too late to happen.
As I commented in https://github.com/openjdk/jdk/pull/2773#issuecomment-790203478 , we can do simplify for them as possible. For example, we can remove `main()` and related methods (e.g. showing usage) from them. If we can remove commandline support from all tool classes, It might help a little to maintain.

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

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

From lzang at openjdk.java.net  Thu Mar  4 03:44:45 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 4 Mar 2021 03:44:45 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out
In-Reply-To: <Zvf7GN59hJdc7SgVRao3cEbcpU99CbGceULIfJnDJOE=.4bd79c51-6b9b-4ff9-9ada-dc43fd6ca6e8@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
 <Zvf7GN59hJdc7SgVRao3cEbcpU99CbGceULIfJnDJOE=.4bd79c51-6b9b-4ff9-9ada-dc43fd6ca6e8@github.com>
Message-ID: <e6bMvI_trIEXu7SAiM98-OpZug3Mwli00owZzLXxJNo=.fa0b5857-28b8-428d-9477-61044e32ad49@github.com>

On Wed, 3 Mar 2021 20:12:55 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out
>
> The fix is fairly big and could use some explaining. Can you provide a bit more detail on what the bug is? In the CR you mention it is due to the combination of a very large array and the segmented heap dump support, but don't really explain what the actual bug is. You can add this detail to the CR rather than here.  Also can explain your solution, especially this new `writeThrough` mode? Thanks.

Hi Chris,

Thanks for your review, I found there is a potential risk for huge object dumping with this PR, I would work out an update and then add the explaination in the CR.
Thanks!

BRs,
Lin

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

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

From cjplummer at openjdk.java.net  Thu Mar  4 07:05:49 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 4 Mar 2021 07:05:49 GMT
Subject: RFR: 8262520: Add SA CommandProcessor support to connect to debug
 server [v3]
In-Reply-To: <tD2uKX3i6AGpD2hpeiPG4tbMSqdny4hSsTvSNjHp5To=.343731d9-2bd0-444f-920b-059563211e8f@github.com>
References: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
 <WKq-Wmomp8PNGWUKS_Sp6Aa0wYg9mzdkunPrsQKrMK8=.fbfda9d9-f383-4c48-a0ac-d08a37086c27@github.com>
 <ucA3-g3HcHbQ5uZ1Mc_hBrFSK17l2iavHr95CEsNJkM=.805874ca-b7cc-4b01-9761-c70b8e795b5a@github.com>
 <jz-gUBiK7JBGarhJoQDcTTzP44aZKMTRC8dInFhtyvA=.d517c6dc-0500-470b-8b2a-7cc0febc9632@github.com>
 <VQfP5xNEzkwAAGijCdtqZMMX7E1FM--kJ3Uq1u-DhmY=.63c39432-54fc-4e1d-b4dc-88560faa8b35@github.com>
 <tD2uKX3i6AGpD2hpeiPG4tbMSqdny4hSsTvSNjHp5To=.343731d9-2bd0-444f-920b-059563211e8f@github.com>
Message-ID: <yg5gDEAxcfmSvqc5J1Etzj5NTDixaUWQnfffTyO_S8A=.875547e5-022f-45ee-8967-96dcacf5239c@github.com>

On Thu, 4 Mar 2021 01:09:40 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>>> I think we should remove `main()` from CLHSDB/HSDB to be honest because they are called from SALauncher, and we cannot call them directly because they are not exported in module-info.
>> 
>> Yes, I'm starting to come to the same conclusion. The only code that constructs a `CLHSDB` object, and therefore triggers the potential call to `doUsage()`, is `CLHSDB.main()`, and it is only called from `SALauncher` when using `jhsdb clhsdb`. We could get rid of `main()` and have some other entrypoint that is passed the values of all the possible options, rather than having to parse them in CLHSDB.java.
>> 
>> There is one test invokes java with the `CLHSDB` class. See SABase.java. It's part of ciReplay testing. I think it would be easily modified to just run `jhsdb clhsdb`
>
>> Yes, I'm starting to come to the same conclusion. The only code that constructs a `CLHSDB` object, and therefore triggers the potential call to `doUsage()`, is `CLHSDB.main()`, and it is only called from `SALauncher` when using `jhsdb clhsdb`. We could get rid of `main()` and have some other entrypoint that is passed the values of all the possible options, rather than having to parse them in CLHSDB.java.
>> 
>> There is one test invokes java with the `CLHSDB` class. See SABase.java. It's part of ciReplay testing. I think it would be easily modified to just run `jhsdb clhsdb`
> 
> I think `debugd` and `jsnap` are also remove `main()` if they have because they do not provide commands like `jstack`.
> I will file it to JBS, and will fix them later.

BTW, referring back to the change to have attach handle pids and debug servernames, and the concern about a host having a numeric name, we already have code that assumes we don't have to deal with this in Tools.java. I just stumbled across this:

           try {
              pid = Integer.parseInt(args[0]);
              debugeeType = DEBUGEE_PID;
           } catch (NumberFormatException e) {
              // try remote server
              remoteServer = args[0];
              debugeeType  = DEBUGEE_REMOTE;
           }

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

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

From cjplummer at openjdk.java.net  Thu Mar  4 07:16:47 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 4 Mar 2021 07:16:47 GMT
Subject: RFR: 8262504: Some CLHSDB command cannot know they run on remote
 debugger
In-Reply-To: <BS-vUqZg1ZRkbMTy-cETWRc6NDKvNai5IkJEeVD65Cc=.d9aaf849-40d0-45ac-b46c-dc8206e04207@github.com>
References: <hYYLenPIpA840x3tcc3ZikUiZKdJB3mSuxDs00dFdQo=.62e3707c-c3f8-48ab-8d1e-d5b7d42661d4@github.com>
 <q07Z4YLPgqOIrzp1XEA3d4LpdlN-vVQDFprZ38AEhyc=.5a5752b7-445a-4427-baa7-0d21fc4e8ba4@github.com>
 <BS-vUqZg1ZRkbMTy-cETWRc6NDKvNai5IkJEeVD65Cc=.d9aaf849-40d0-45ac-b46c-dc8206e04207@github.com>
Message-ID: <9Tr5gQZew4ATFNNHe7o2RC-S26DsYGZRkVlD8h0d5Xo=.d8ad3895-d014-4d2d-b2e7-59969f6b3499@github.com>

On Thu, 4 Mar 2021 02:08:58 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/Tool.java line 69:
>> 
>>> 67:       }
>>> 68:    }
>>> 69: 
>> 
>> This section seems to be the key to your changes, but I have to admit that I don't follow how it all ties in together. Maybe you can explain the overall structure of the Tool subclasses to help explain. They seem to be overloaded with modes that make it hard to follow all the logic. For example, you've added the `Tool(HotSpotAgent agent)` constructor, and we already have `Tool()` and `Tool(JVMDebugger d)`. It's unclear to me what the use case is for each. Also, we have about 10 subclasses of Tool. Why do only `PMap` an `PStack` need this new constructor.
>> 
>> BTW, looking at Tool and its subclasses has made me realize we have a whole other area of historical tool baggage, similar to what we are discussing with CLHSDB and HSDB. My guess is all these tool subclasses used to be invoked directly from the java command line. Now they are all hidden behind `jhsdb` subcommands, but still carry the old java command line support. In addition, when adding `jhsdb` and it's subcommands, it looks like there was an effort to mimic the existing Attach API commands like jmap and jinfo, so the SA versions of these commands have multiple modes which invoke different Tool subclasses. For example, `jhdsb jmap` alone can invoke the ClassLoaderStats, FinalizerInfo, ObjectHistogram, PMap, and HeapSummary tools, in addition to dumping the heap graph in HProf or GXL format. I think things would have been simpler and cleaner if each of these were made separate `jhsdb` subcommands, but it's probably too late for that. I suppose we could deprecate the existing sub
 -commands and add all these new  sub-commands, but that will just make things harder for us until the old commands are eventually removed, which might never happen.
>
>> This section seems to be the key to your changes, but I have to admit that I don't follow how it all ties in together. Maybe you can explain the overall structure of the Tool subclasses to help explain. They seem to be overloaded with modes that make it hard to follow all the logic. For example, you've added the `Tool(HotSpotAgent agent)` constructor, and we already have `Tool()` and `Tool(JVMDebugger d)`. It's unclear to me what the use case is for each. Also, we have about 10 subclasses of Tool. Why do only `PMap` an `PStack` need this new constructor.
> 
> All of traditional serviceability commands (jstack, jmap, etc...) seem to extend `Tool` because it has a function to parse commandline args and to attach debuggee commonly.
> `Tool` supports several attach mechanism: `Tool()` supports attach debuggee manually, `Tool(JVMDebugger)` supports attach debuggee via available `JVMDegbugger`. `HotSpotAgent` communicates to debugee, so `Tool` would create its instance. Thus I added `Tool(HotSpotAgent)` to use available remote debug server.
> 
> AFAICS only `PMap` and `PStack` do not support remote debug server, so I changed for them.
> (I plan to support `pmap` and `pstack` when we attach remote debug server, so it is important to know debuggee type.)
> 
>> BTW, looking at Tool and its subclasses has made me realize we have a whole other area of historical tool baggage, similar to what we are discussing with CLHSDB and HSDB. My guess is all these tool subclasses used to be invoked directly from the java command line. Now they are all hidden behind `jhsdb` subcommands, but still carry the old java command line support. In addition, when adding `jhsdb` and it's subcommands, it looks like there was an effort to mimic the existing Attach API commands like jmap and jinfo, so the SA versions of these commands have multiple modes which invoke different Tool subclasses. For example, `jhdsb jmap` alone can invoke the ClassLoaderStats, FinalizerInfo, ObjectHistogram, PMap, and HeapSummary tools, in addition to dumping the heap graph in HProf or GXL format. I think things would have been simpler and cleaner if each of these were made separate `jhsdb` subcommands, but it's probably too late for that. I suppose we could deprecate the existing sub
 -commands and add all these new sub-commands, but that will just make things harder for us until the old commands are eventually removed, which might never happen.
> 
> I agree with you it is too late to happen.
> As I commented in https://github.com/openjdk/jdk/pull/2773#issuecomment-790203478 , we can do simplify for them as possible. For example, we can remove `main()` and related methods (e.g. showing usage) from them. If we can remove commandline support from all tool classes, It might help a little to maintain.

If I understanding correctly, we have two users of Tools.java. One is `SALauncher` and the other is `CommandProcessor`. When we use `SALauncher`, we determine the `debugeeType` based on the command line arguments used. When using the `CommandProcessor`, we need access to the `HotSpotAgent` to get the `debuggeeType`, since it has stored this in its `startupMode` field . So the only reason for this new constructor is so we can set `debugeeType`, and then as you've pointed out, that makes the following existing code work correctly:

 if (getDebugeeType() == DEBUGEE_REMOTE) { 
     out.println("remote configuration is not yet implemented"); 
 } else { 
     out.println("not yet implemented (debugger does not support CDebugger)!"); 
 }

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

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

From cjplummer at openjdk.java.net  Thu Mar  4 07:28:48 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 4 Mar 2021 07:28:48 GMT
Subject: RFR: 8262504: Some CLHSDB command cannot know they run on remote
 debugger
In-Reply-To: <9Tr5gQZew4ATFNNHe7o2RC-S26DsYGZRkVlD8h0d5Xo=.d8ad3895-d014-4d2d-b2e7-59969f6b3499@github.com>
References: <hYYLenPIpA840x3tcc3ZikUiZKdJB3mSuxDs00dFdQo=.62e3707c-c3f8-48ab-8d1e-d5b7d42661d4@github.com>
 <q07Z4YLPgqOIrzp1XEA3d4LpdlN-vVQDFprZ38AEhyc=.5a5752b7-445a-4427-baa7-0d21fc4e8ba4@github.com>
 <BS-vUqZg1ZRkbMTy-cETWRc6NDKvNai5IkJEeVD65Cc=.d9aaf849-40d0-45ac-b46c-dc8206e04207@github.com>
 <9Tr5gQZew4ATFNNHe7o2RC-S26DsYGZRkVlD8h0d5Xo=.d8ad3895-d014-4d2d-b2e7-59969f6b3499@github.com>
Message-ID: <ospqpX5XWQ5LTdeXCUiV8x08YVF1_7ECOoIcX9jbB6Q=.7da431fd-a99d-4e62-9f5d-f55ec3f294c3@github.com>

On Thu, 4 Mar 2021 07:14:18 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>>> This section seems to be the key to your changes, but I have to admit that I don't follow how it all ties in together. Maybe you can explain the overall structure of the Tool subclasses to help explain. They seem to be overloaded with modes that make it hard to follow all the logic. For example, you've added the `Tool(HotSpotAgent agent)` constructor, and we already have `Tool()` and `Tool(JVMDebugger d)`. It's unclear to me what the use case is for each. Also, we have about 10 subclasses of Tool. Why do only `PMap` an `PStack` need this new constructor.
>> 
>> All of traditional serviceability commands (jstack, jmap, etc...) seem to extend `Tool` because it has a function to parse commandline args and to attach debuggee commonly.
>> `Tool` supports several attach mechanism: `Tool()` supports attach debuggee manually, `Tool(JVMDebugger)` supports attach debuggee via available `JVMDegbugger`. `HotSpotAgent` communicates to debugee, so `Tool` would create its instance. Thus I added `Tool(HotSpotAgent)` to use available remote debug server.
>> 
>> AFAICS only `PMap` and `PStack` do not support remote debug server, so I changed for them.
>> (I plan to support `pmap` and `pstack` when we attach remote debug server, so it is important to know debuggee type.)
>> 
>>> BTW, looking at Tool and its subclasses has made me realize we have a whole other area of historical tool baggage, similar to what we are discussing with CLHSDB and HSDB. My guess is all these tool subclasses used to be invoked directly from the java command line. Now they are all hidden behind `jhsdb` subcommands, but still carry the old java command line support. In addition, when adding `jhsdb` and it's subcommands, it looks like there was an effort to mimic the existing Attach API commands like jmap and jinfo, so the SA versions of these commands have multiple modes which invoke different Tool subclasses. For example, `jhdsb jmap` alone can invoke the ClassLoaderStats, FinalizerInfo, ObjectHistogram, PMap, and HeapSummary tools, in addition to dumping the heap graph in HProf or GXL format. I think things would have been simpler and cleaner if each of these were made separate `jhsdb` subcommands, but it's probably too late for that. I suppose we could deprecate the existing su
 b-commands and add all these new sub-commands, but that will just make things harder for us until the old commands are eventually removed, which might never happen.
>> 
>> I agree with you it is too late to happen.
>> As I commented in https://github.com/openjdk/jdk/pull/2773#issuecomment-790203478 , we can do simplify for them as possible. For example, we can remove `main()` and related methods (e.g. showing usage) from them. If we can remove commandline support from all tool classes, It might help a little to maintain.
>
> If I understanding correctly, we have two users of Tools.java. One is `SALauncher` and the other is `CommandProcessor`. When we use `SALauncher`, we determine the `debugeeType` based on the command line arguments used. When using the `CommandProcessor`, we need access to the `HotSpotAgent` to get the `debuggeeType`, since it has stored this in its `startupMode` field . So the only reason for this new constructor is so we can set `debugeeType`, and then as you've pointed out, that makes the following existing code work correctly:
> 
>  if (getDebugeeType() == DEBUGEE_REMOTE) { 
>      out.println("remote configuration is not yet implemented"); 
>  } else { 
>      out.println("not yet implemented (debugger does not support CDebugger)!"); 
>  }

> I agree with you it is too late to happen.
> As I commented in [#2773 (comment)](https://github.com/openjdk/jdk/pull/2773#issuecomment-790203478) , we can do simplify for them as possible. For example, we can remove `main()` and related methods (e.g. showing usage) from them. If we can remove commandline support from all tool classes, It might help a little to maintain.

Yes, I'd like to see a lot of this excess baggage go away. I also wouldn't mind at least considering re-imagining the command line interface for all these Tool subclasses, but would only do so if we could quickly deprecate what we currently have. We already have enough cases of being able to do the same thing more than one way (I think in some cases 5 ways). We don't need one more, but on the other hand, as an example, having `jhsdb jmap` support dumping the java heap just doesn't make any sense. My guess is the first `jmap` just dumped the memory map of loaded libraries, and then more and more unrelated subcommands kept being added to it, but I'm not sure of the history. The Attach API `jmap` command suffers from the same issue, although oddly is does not support the library mapping output like the SA version does. I'm not sure which version of `jmap` came first and what it initially looked like.

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

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

From cjplummer at openjdk.java.net  Thu Mar  4 07:35:41 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 4 Mar 2021 07:35:41 GMT
Subject: RFR: 8262520: Add SA CommandProcessor support to connect to debug
 server [v3]
In-Reply-To: <yg5gDEAxcfmSvqc5J1Etzj5NTDixaUWQnfffTyO_S8A=.875547e5-022f-45ee-8967-96dcacf5239c@github.com>
References: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
 <WKq-Wmomp8PNGWUKS_Sp6Aa0wYg9mzdkunPrsQKrMK8=.fbfda9d9-f383-4c48-a0ac-d08a37086c27@github.com>
 <ucA3-g3HcHbQ5uZ1Mc_hBrFSK17l2iavHr95CEsNJkM=.805874ca-b7cc-4b01-9761-c70b8e795b5a@github.com>
 <jz-gUBiK7JBGarhJoQDcTTzP44aZKMTRC8dInFhtyvA=.d517c6dc-0500-470b-8b2a-7cc0febc9632@github.com>
 <VQfP5xNEzkwAAGijCdtqZMMX7E1FM--kJ3Uq1u-DhmY=.63c39432-54fc-4e1d-b4dc-88560faa8b35@github.com>
 <tD2uKX3i6AGpD2hpeiPG4tbMSqdny4hSsTvSNjHp5To=.343731d9-2bd0-444f-920b-059563211e8f@github.com>
 <yg5gDEAxcfmSvqc5J1Etzj5NTDixaUWQnfffTyO_S8A=.875547e5-022f-45ee-8967-96dcacf5239c@github.com>
Message-ID: <N9uoCUWB3LCeTgzSk1o89oF2PGyrg7r3_vvVuTFw3Ns=.5ebd8847-f9d1-4b3e-8a66-76ee5e9c7d86@github.com>

On Thu, 4 Mar 2021 07:03:25 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>>> Yes, I'm starting to come to the same conclusion. The only code that constructs a `CLHSDB` object, and therefore triggers the potential call to `doUsage()`, is `CLHSDB.main()`, and it is only called from `SALauncher` when using `jhsdb clhsdb`. We could get rid of `main()` and have some other entrypoint that is passed the values of all the possible options, rather than having to parse them in CLHSDB.java.
>>> 
>>> There is one test invokes java with the `CLHSDB` class. See SABase.java. It's part of ciReplay testing. I think it would be easily modified to just run `jhsdb clhsdb`
>> 
>> I think `debugd` and `jsnap` are also remove `main()` if they have because they do not provide commands like `jstack`.
>> I will file it to JBS, and will fix them later.
>
> BTW, referring back to the change to have attach handle pids and debug servernames, and the concern about a host having a numeric name, we already have code that assumes we don't have to deal with this in Tools.java. I just stumbled across this:
> 
>            try {
>               pid = Integer.parseInt(args[0]);
>               debugeeType = DEBUGEE_PID;
>            } catch (NumberFormatException e) {
>               // try remote server
>               remoteServer = args[0];
>               debugeeType  = DEBUGEE_REMOTE;
>            }

I think the changes look good now. Please create a CSR and then we can finish the review of this PR.

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

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

From cjplummer at openjdk.java.net  Thu Mar  4 07:39:51 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 4 Mar 2021 07:39:51 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out
In-Reply-To: <e6bMvI_trIEXu7SAiM98-OpZug3Mwli00owZzLXxJNo=.fa0b5857-28b8-428d-9477-61044e32ad49@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
 <Zvf7GN59hJdc7SgVRao3cEbcpU99CbGceULIfJnDJOE=.4bd79c51-6b9b-4ff9-9ada-dc43fd6ca6e8@github.com>
 <e6bMvI_trIEXu7SAiM98-OpZug3Mwli00owZzLXxJNo=.fa0b5857-28b8-428d-9477-61044e32ad49@github.com>
Message-ID: <oaMRL-GuwQKYlGByJvPhHH63A4LTvQLsL2W6BOIS6cc=.5ee0e7f9-bdc3-4e51-9fcf-999d607730c1@github.com>

On Thu, 4 Mar 2021 02:48:44 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> The fix is fairly big and could use some explaining. Can you provide a bit more detail on what the bug is? In the CR you mention it is due to the combination of a very large array and the segmented heap dump support, but don't really explain what the actual bug is. You can add this detail to the CR rather than here.  Also can explain your solution, especially this new `writeThrough` mode? Thanks.
>
> Hi Chris,
> 
> Thanks for your review, I found there is a potential risk for huge object dumping with this PR, I would work out an update and then add the explaination in the CR.
> Thanks!
> 
> BRs,
> Lin

Thanks for the explanation in the CR. That helps a lot. I didn't have time to get through the review today, but will do so tomorrow.

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

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

From ysuenaga at openjdk.java.net  Thu Mar  4 08:44:39 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 4 Mar 2021 08:44:39 GMT
Subject: RFR: 8262520: Add SA CommandProcessor support to connect to debug
 server [v3]
In-Reply-To: <N9uoCUWB3LCeTgzSk1o89oF2PGyrg7r3_vvVuTFw3Ns=.5ebd8847-f9d1-4b3e-8a66-76ee5e9c7d86@github.com>
References: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
 <WKq-Wmomp8PNGWUKS_Sp6Aa0wYg9mzdkunPrsQKrMK8=.fbfda9d9-f383-4c48-a0ac-d08a37086c27@github.com>
 <ucA3-g3HcHbQ5uZ1Mc_hBrFSK17l2iavHr95CEsNJkM=.805874ca-b7cc-4b01-9761-c70b8e795b5a@github.com>
 <jz-gUBiK7JBGarhJoQDcTTzP44aZKMTRC8dInFhtyvA=.d517c6dc-0500-470b-8b2a-7cc0febc9632@github.com>
 <VQfP5xNEzkwAAGijCdtqZMMX7E1FM--kJ3Uq1u-DhmY=.63c39432-54fc-4e1d-b4dc-88560faa8b35@github.com>
 <tD2uKX3i6AGpD2hpeiPG4tbMSqdny4hSsTvSNjHp5To=.343731d9-2bd0-444f-920b-059563211e8f@github.com>
 <yg5gDEAxcfmSvqc5J1Etzj5NTDixaUWQnfffTyO_S8A=.875547e5-022f-45ee-8967-96dcacf5239c@github.com>
 <N9uoCUWB3LCeTgzSk1o89oF2PGyrg7r3_vvVuTFw3Ns=.5ebd8847-f9d1-4b3e-8a66-76ee5e9c7d86@github.com>
Message-ID: <D0PKiu1UtUdZwnEEl66UU7G9vn8fm2MEgYD7jdYTb1A=.245c72d4-b2f4-4505-907a-a89416901d2f@github.com>

On Thu, 4 Mar 2021 07:32:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> BTW, referring back to the change to have attach handle pids and debug servernames, and the concern about a host having a numeric name, we already have code that assumes we don't have to deal with this in Tools.java. I just stumbled across this:
>> 
>>            try {
>>               pid = Integer.parseInt(args[0]);
>>               debugeeType = DEBUGEE_PID;
>>            } catch (NumberFormatException e) {
>>               // try remote server
>>               remoteServer = args[0];
>>               debugeeType  = DEBUGEE_REMOTE;
>>            }
>
> I think the changes look good now. Please create a CSR and then we can finish the review of this PR.

I filed CSR and finalized it: https://bugs.openjdk.java.net/browse/JDK-8263005

> BTW, referring back to the change to have attach handle pids and debug servernames, and the concern about a host having a numeric name, we already have code that assumes we don't have to deal with this in Tools.java. I just stumbled across this:

Thanks! I felt confident for current PR :)

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

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

From ysuenaga at openjdk.java.net  Thu Mar  4 09:11:48 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 4 Mar 2021 09:11:48 GMT
Subject: RFR: 8262504: Some CLHSDB command cannot know they run on remote
 debugger
In-Reply-To: <ospqpX5XWQ5LTdeXCUiV8x08YVF1_7ECOoIcX9jbB6Q=.7da431fd-a99d-4e62-9f5d-f55ec3f294c3@github.com>
References: <hYYLenPIpA840x3tcc3ZikUiZKdJB3mSuxDs00dFdQo=.62e3707c-c3f8-48ab-8d1e-d5b7d42661d4@github.com>
 <q07Z4YLPgqOIrzp1XEA3d4LpdlN-vVQDFprZ38AEhyc=.5a5752b7-445a-4427-baa7-0d21fc4e8ba4@github.com>
 <BS-vUqZg1ZRkbMTy-cETWRc6NDKvNai5IkJEeVD65Cc=.d9aaf849-40d0-45ac-b46c-dc8206e04207@github.com>
 <9Tr5gQZew4ATFNNHe7o2RC-S26DsYGZRkVlD8h0d5Xo=.d8ad3895-d014-4d2d-b2e7-59969f6b3499@github.com>
 <ospqpX5XWQ5LTdeXCUiV8x08YVF1_7ECOoIcX9jbB6Q=.7da431fd-a99d-4e62-9f5d-f55ec3f294c3@github.com>
Message-ID: <T6YJH8j7swsqNOAYBPVeWCrxCbQsDhGo4dI_dpmW_LY=.f4eb44dd-d441-40b0-a349-0c01ae5c053e@github.com>

On Thu, 4 Mar 2021 07:26:21 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> If I understanding correctly, we have two users of Tools.java. One is `SALauncher` and the other is `CommandProcessor`. When we use `SALauncher`, we determine the `debugeeType` based on the command line arguments used. When using the `CommandProcessor`, we need access to the `HotSpotAgent` to get the `debuggeeType`, since it has stored this in its `startupMode` field . So the only reason for this new constructor is so we can set `debugeeType`, and then as you've pointed out, that makes the following existing code work correctly:
>> 
>>  if (getDebugeeType() == DEBUGEE_REMOTE) { 
>>      out.println("remote configuration is not yet implemented"); 
>>  } else { 
>>      out.println("not yet implemented (debugger does not support CDebugger)!"); 
>>  }
>
>> I agree with you it is too late to happen.
>> As I commented in [#2773 (comment)](https://github.com/openjdk/jdk/pull/2773#issuecomment-790203478) , we can do simplify for them as possible. For example, we can remove `main()` and related methods (e.g. showing usage) from them. If we can remove commandline support from all tool classes, It might help a little to maintain.
> 
> Yes, I'd like to see a lot of this excess baggage go away. I also wouldn't mind at least considering re-imagining the command line interface for all these Tool subclasses, but would only do so if we could quickly deprecate what we currently have. We already have enough cases of being able to do the same thing more than one way (I think in some cases 5 ways). We don't need one more, but on the other hand, as an example, having `jhsdb jmap` support dumping the java heap just doesn't make any sense. My guess is the first `jmap` just dumped the memory map of loaded libraries, and then more and more unrelated subcommands kept being added to it, but I'm not sure of the history. The Attach API `jmap` command suffers from the same issue, although oddly is does not support the library mapping output like the SA version does. I'm not sure which version of `jmap` came first and what it initially looked like.

I cannot agree with restructuring sub commands and options in jhsdb for compatibility.

Since jhsdb is introduced, SA tools (jstack, jmap, and so on) has been removed the feature to use SA, they are for live process only with Attach API. So I guess we can ignore about SA interface for them. In addition, they are marked as unsupported tool in [the document](https://docs.oracle.com/en/java/javase/15/docs/specs/man/index.html).

Thus I guess we can think about jhsdb and jcmd (dcmd) interface only. If so, I think we can remove some excess baggages from them (e.g. command line support), and it is worth to work for maintenance in future.

But this PR does not aim it, it will be the next step.

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

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

From lzang at openjdk.java.net  Thu Mar  4 13:25:49 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 4 Mar 2021 13:25:49 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out
In-Reply-To: <oaMRL-GuwQKYlGByJvPhHH63A4LTvQLsL2W6BOIS6cc=.5ee0e7f9-bdc3-4e51-9fcf-999d607730c1@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
 <Zvf7GN59hJdc7SgVRao3cEbcpU99CbGceULIfJnDJOE=.4bd79c51-6b9b-4ff9-9ada-dc43fd6ca6e8@github.com>
 <e6bMvI_trIEXu7SAiM98-OpZug3Mwli00owZzLXxJNo=.fa0b5857-28b8-428d-9477-61044e32ad49@github.com>
 <oaMRL-GuwQKYlGByJvPhHH63A4LTvQLsL2W6BOIS6cc=.5ee0e7f9-bdc3-4e51-9fcf-999d607730c1@github.com>
Message-ID: <7p7PD78B0fKuSonRZ44rQWvBKHabsz4n9VT4WbVluFI=.e4248320-f134-4ed0-b073-a3466970932c@github.com>

On Thu, 4 Mar 2021 07:37:01 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Hi Chris,
>> 
>> Thanks for your review, I found there is a potential risk for huge object dumping with this PR, I would work out an update and then add the explaination in the CR.
>> Thanks!
>> 
>> BRs,
>> Lin
>
> Thanks for the explanation in the CR. That helps a lot. I didn't have time to get through the review today, but will do so tomorrow.

Hi Chris,
Thanks a lot, I am still wip to reduce the memory consumption. So I think you could help review after my next update :)

BRs,
Lin

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

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

From pchilanomate at openjdk.java.net  Thu Mar  4 14:22:42 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Thu, 4 Mar 2021 14:22:42 GMT
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code [v3]
In-Reply-To: <1KJvn-X7o7pVACivXUFqMiMICiUf-cUzqBqyN6HCscc=.57f72c5d-1565-4ab2-aa9d-daa424eccb8f@github.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
 <1KJvn-X7o7pVACivXUFqMiMICiUf-cUzqBqyN6HCscc=.57f72c5d-1565-4ab2-aa9d-daa424eccb8f@github.com>
Message-ID: <rmKUC9bnv10ZYc28KYgw8GabvrOW7OanllgD3SMDH1o=.3cb98a44-3d72-47ee-b23f-11fb0499ff49@github.com>

On Wed, 3 Mar 2021 19:24:17 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More pointer declaration style fixups
>
> Hi David,
> 
> Changes look good to me.
> 
> Thanks,
> Patricio

> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-compiler-dev](mailto:hotspot-compiler-dev at openjdk.java.net):_
> 
> Hi Patricio,
> 
> Thanks for looking at this.
> 
> On 4/03/2021 5:26 am, Patricio Chilano Mateo wrote:
> 
> > Hi David,
> > Changes look good to me.
> > Thanks,
> > Patricio
> > src/hotspot/share/runtime/objectMonitor.hpp line 306:
> > > 304:
> > > 305:   bool      enter(JavaThread* current);
> > > 306:   void      exit(bool not_suspended, TRAPS);
> > 
> > 
> > Shouldn't we also remove use of TRAPS for exit()? In case of unbalanced locking we don't throw IMSE, only just assert.
> 
> Good catch! (no pun intended). Yes I overlooked that was don't actually
> throw the IMSE in plain exit (in contrast to jni_exit).
> 
> Fixed.
Looks good!

Thanks,
Patricio

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

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

From gziemski at openjdk.java.net  Thu Mar  4 15:29:59 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Thu, 4 Mar 2021 15:29:59 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <2vF8YcQ9CgnLxMus9tHTd4HmFITeH5wddBKzH-QNNEY=.dbfb2cd5-5997-4b79-88a5-d8292fc56965@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <WlU-by8oEfoJIVOKjkhNLCPUuW4DdRMAFIO6PWIPzb4=.cbc4742c-d113-4d20-b5f3-9a42655f9b86@github.com>
 <DFLFDkNJ30yiF-YpFG6-NtwDi1iYo__6EgymUpCsXiM=.a622ede5-cd91-44a9-9c93-bc81e25872b4@github.com>
 <2vF8YcQ9CgnLxMus9tHTd4HmFITeH5wddBKzH-QNNEY=.dbfb2cd5-5997-4b79-88a5-d8292fc56965@github.com>
Message-ID: <tBipBlvx8GoWStqMaVuNMNwr9KpINTecikQczUCv_wI=.18cc127c-8450-430c-a5a3-7dbcd2075ef1@github.com>

On Wed, 3 Mar 2021 17:46:41 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > A list of the bugs that our internal testing revealed so far:
> 
> Are any of these blockers for integration? Some of them are to do with things like features that aren't yet supported, and we can't fix what we can't see.

I don't personally think any of these issues are blockers. It's a great effort as it is and very much appreciated. Anything else can be fixed as a followup.

There might be some legal requirements (i.e. JCK) that I'm not in position to comment on, however, so someone else might need to chime in here.

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

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

From github.com+4146708+a74nh at openjdk.java.net  Thu Mar  4 17:39:01 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Thu, 4 Mar 2021 17:39:01 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <tBipBlvx8GoWStqMaVuNMNwr9KpINTecikQczUCv_wI=.18cc127c-8450-430c-a5a3-7dbcd2075ef1@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <WlU-by8oEfoJIVOKjkhNLCPUuW4DdRMAFIO6PWIPzb4=.cbc4742c-d113-4d20-b5f3-9a42655f9b86@github.com>
 <DFLFDkNJ30yiF-YpFG6-NtwDi1iYo__6EgymUpCsXiM=.a622ede5-cd91-44a9-9c93-bc81e25872b4@github.com>
 <2vF8YcQ9CgnLxMus9tHTd4HmFITeH5wddBKzH-QNNEY=.dbfb2cd5-5997-4b79-88a5-d8292fc56965@github.com>
 <tBipBlvx8GoWStqMaVuNMNwr9KpINTecikQczUCv_wI=.18cc127c-8450-430c-a5a3-7dbcd2075ef1@github.com>
Message-ID: <nPJsUts1-fZDvRZPsROWtSLOP7slGCUYUcjXcSu4d-E=.2b8a7229-13b4-4f07-82bc-fc762c55c526@github.com>

On Thu, 4 Mar 2021 15:27:25 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>>> A list of the bugs that our internal testing revealed so far:
>> 
>> Are any of these blockers for integration? Some of them are to do with things like features that aren't yet supported, and we can't fix what we can't see.
>
>> > A list of the bugs that our internal testing revealed so far:
>> 
>> Are any of these blockers for integration? Some of them are to do with things like features that aren't yet supported, and we can't fix what we can't see.
> 
> I don't personally think any of these issues are blockers. It's a great effort as it is and very much appreciated. Anything else can be fixed as a followup.
> 
> There might be some legal requirements (i.e. JCK) that I'm not in position to comment on, however, so someone else might need to chime in here.

I was building this PR on a new machine, and I now get the following error:

> /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:258:31: error: cast to smaller integer type 'MIDIClientRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
> static MIDIClientRef client = (MIDIClientRef) NULL;
>                               ^~~~~~~~~~~~~~~~~~~~
> /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:259:29: error: cast to smaller integer type 'MIDIPortRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
> static MIDIPortRef inPort = (MIDIPortRef) NULL;
>                             ^~~~~~~~~~~~~~~~~~
> /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:260:30: error: cast to smaller integer type 'MIDIPortRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
> static MIDIPortRef outPort = (MIDIPortRef) NULL;
>                              ^~~~~~~~~~~~~~~~~~
> /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:466:32: error: cast to smaller integer type 'MIDIEndpointRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
>     MIDIEndpointRef endpoint = (MIDIEndpointRef) NULL;
>                                ^~~~~~~~~~~~~~~~~~~~~~
> 4 errors generated.

As far as I can tell the only difference between the two systems is the xcode version:

New system (failing)
% xcodebuild -version
Xcode 12.5
Build version 12E5244e

Old system (working)
% xcodebuild -version
Xcode 12.4
Build version 12D4e

Looks like the newer version of Xcode is being a little stricter with casting?
Replacing the NULL with 0 seems to fix the issue.

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

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

From vkempik at openjdk.java.net  Thu Mar  4 18:22:51 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Thu, 4 Mar 2021 18:22:51 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <nPJsUts1-fZDvRZPsROWtSLOP7slGCUYUcjXcSu4d-E=.2b8a7229-13b4-4f07-82bc-fc762c55c526@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <WlU-by8oEfoJIVOKjkhNLCPUuW4DdRMAFIO6PWIPzb4=.cbc4742c-d113-4d20-b5f3-9a42655f9b86@github.com>
 <DFLFDkNJ30yiF-YpFG6-NtwDi1iYo__6EgymUpCsXiM=.a622ede5-cd91-44a9-9c93-bc81e25872b4@github.com>
 <2vF8YcQ9CgnLxMus9tHTd4HmFITeH5wddBKzH-QNNEY=.dbfb2cd5-5997-4b79-88a5-d8292fc56965@github.com>
 <tBipBlvx8GoWStqMaVuNMNwr9KpINTecikQczUCv_wI=.18cc127c-8450-430c-a5a3-7dbcd2075ef1@github.com>
 <nPJsUts1-fZDvRZPsROWtSLOP7slGCUYUcjXcSu4d-E=.2b8a7229-13b4-4f07-82bc-fc762c55c526@github.com>
Message-ID: <yPuti6hI-2ryTux1GdrZHAcP0n0esc5E1PCPXvm389o=.70b78b9a-365e-4a80-8903-e9a0b822492f@github.com>

On Thu, 4 Mar 2021 17:36:22 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

> I was building this PR on a new machine, and I now get the following error:
> 
> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:258:31: error: cast to smaller integer type 'MIDIClientRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
> > static MIDIClientRef client = (MIDIClientRef) NULL;
> > ^~~~~~~~~~~~~~~~~~~~
> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:259:29: error: cast to smaller integer type 'MIDIPortRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
> > static MIDIPortRef inPort = (MIDIPortRef) NULL;
> > ^~~~~~~~~~~~~~~~~~
> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:260:30: error: cast to smaller integer type 'MIDIPortRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
> > static MIDIPortRef outPort = (MIDIPortRef) NULL;
> > ^~~~~~~~~~~~~~~~~~
> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:466:32: error: cast to smaller integer type 'MIDIEndpointRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
> > MIDIEndpointRef endpoint = (MIDIEndpointRef) NULL;
> > ^~~~~~~~~~~~~~~~~~~~~~
> > 4 errors generated.
> 
> As far as I can tell the only difference between the two systems is the xcode version:
> 
> New system (failing)
> % xcodebuild -version
> Xcode 12.5
> Build version 12E5244e
> 
> Old system (working)
> % xcodebuild -version
> Xcode 12.4
> Build version 12D4e
> 
> Looks like the newer version of Xcode is being a little stricter with casting?
> Replacing the NULL with 0 seems to fix the issue.

Hello
there is one issue with the info you provided, it's from Xcode12.5 beta.
And beta license agreement forbids sharing output of beta version of compiler&co
So we can't say we have issue with newer xcode beta until that beta went public & released.
Fixing issues you found now will mean someone have violated xcode beta license agreement and made these issues public.

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

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

From kevinw at openjdk.java.net  Thu Mar  4 18:32:55 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 4 Mar 2021 18:32:55 GMT
Subject: RFR: 8259577: Dangling reference to temp_path in
 Java_sun_tools_attach_VirtualMachineImpl_getTempDir
Message-ID: <LCKP8juPYXI7kC3l90ci1Y9ifZd1yK70jG6WUQM2TUA=.946e70d1-2233-4564-84d5-12be965ed803@github.com>

Hi,
This is a pull request for 8259577, which points out that Java_sun_tools_attach_VirtualMachineImpl_getTempDir
caches a local variable from a previous call, so could return garbage.
However as noted in the bug, we have been safe so far because this method is only called once, so the caching is not required.
Thanks.

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

Commit messages:
 - 8259577: Dangling reference to temp_path in Java_sun_tools_attach_VirtualMachineImpl_getTempDir

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

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

From iklam at openjdk.java.net  Thu Mar  4 19:10:40 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 4 Mar 2021 19:10:40 GMT
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code [v3]
In-Reply-To: <AFnChy8qG_DR809bNN3Nyjpd52g7UQOzH0rBZirRll8=.1dfee132-23d4-435a-abf0-5677b4039d8e@github.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
 <AFnChy8qG_DR809bNN3Nyjpd52g7UQOzH0rBZirRll8=.1dfee132-23d4-435a-abf0-5677b4039d8e@github.com>
Message-ID: <5BCJBgQqTUiNQXzh7i3dEVGlkiZBU5NYQIQp5Ke55L0=.e92797b3-3384-407b-8797-91d171735b30@github.com>

On Wed, 3 Mar 2021 16:24:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More pointer declaration style fixups
>
> src/hotspot/share/runtime/synchronizer.hpp line 92:
> 
>> 90:   // This is the "slow path" version of monitor enter and exit.
>> 91:   static void enter(Handle obj, BasicLock* lock, JavaThread* current);
>> 92:   static void exit(oop obj, BasicLock* lock, TRAPS);
> 
> So are you suggesting that we should have the convention that if a function takes a Thread/JavaThread argument as the last argument, to use "current" rather than "THREAD", since the latter implies it is supposed to be used to pass an argument for the parameter to TRAPS?  I think this is good.  It manages some confusion about trailing THREAD arguments in some callers.  Specializing further to JavaThread from Thread is also a good change.

A suggestion (perhaps as a future RFE), if a function never throws:

void foo(Class* c, Method*m, Thread* current);

maybe we should move the last `thread` argument to first:

void foo(Thread* current, Class* c, Method*m);

This will make it absolutely sure that `foo` will never throw an exception -- when you are reading a caller of `foo`, you don't need to refer to the declaration of `foo` to know that.

Also, this will be consistent with our usual convention of passing "bigger" arguments first (Process > Thread -> Class -> method -> bci, etc).

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

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

From cjplummer at openjdk.java.net  Thu Mar  4 19:18:55 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 4 Mar 2021 19:18:55 GMT
Subject: RFR: 8259577: Dangling reference to temp_path in
 Java_sun_tools_attach_VirtualMachineImpl_getTempDir
In-Reply-To: <LCKP8juPYXI7kC3l90ci1Y9ifZd1yK70jG6WUQM2TUA=.946e70d1-2233-4564-84d5-12be965ed803@github.com>
References: <LCKP8juPYXI7kC3l90ci1Y9ifZd1yK70jG6WUQM2TUA=.946e70d1-2233-4564-84d5-12be965ed803@github.com>
Message-ID: <IAU8saU07kBlMXsFvbeLzTUQVtPYhZ2VZ9ltd0T1Udo=.041146dc-ff8b-4232-8086-ca486119cf34@github.com>

On Thu, 4 Mar 2021 18:27:48 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Hi,
> This is a pull request for 8259577, which points out that Java_sun_tools_attach_VirtualMachineImpl_getTempDir
> caches a local variable from a previous call, so could return garbage.
> However as noted in the bug, we have been safe so far because this method is only called once, so the caching is not required.
> Thanks.

Looks good, except you need to update the copyright.

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

Marked as reviewed by cjplummer (Reviewer).

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

From kevinw at openjdk.java.net  Thu Mar  4 19:47:00 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 4 Mar 2021 19:47:00 GMT
Subject: RFR: 8259577: Dangling reference to temp_path in
 Java_sun_tools_attach_VirtualMachineImpl_getTempDir [v2]
In-Reply-To: <LCKP8juPYXI7kC3l90ci1Y9ifZd1yK70jG6WUQM2TUA=.946e70d1-2233-4564-84d5-12be965ed803@github.com>
References: <LCKP8juPYXI7kC3l90ci1Y9ifZd1yK70jG6WUQM2TUA=.946e70d1-2233-4564-84d5-12be965ed803@github.com>
Message-ID: <k0jpvpElU29GG0CespRP5xSdXV-4k8OJSm8OpWunsuI=.a70e28f3-1065-4676-bcda-faad7a4ffd89@github.com>

> Hi,
> This is a pull request for 8259577, which points out that Java_sun_tools_attach_VirtualMachineImpl_getTempDir
> caches a local variable from a previous call, so could return garbage.
> However as noted in the bug, we have been safe so far because this method is only called once, so the caching is not required.
> Thanks.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  Copyright update.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2832/files
  - new: https://git.openjdk.java.net/jdk/pull/2832/files/7eb29e4d..c660082f

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

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

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

From kevinw at openjdk.java.net  Thu Mar  4 19:47:00 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 4 Mar 2021 19:47:00 GMT
Subject: RFR: 8259577: Dangling reference to temp_path in
 Java_sun_tools_attach_VirtualMachineImpl_getTempDir [v2]
In-Reply-To: <IAU8saU07kBlMXsFvbeLzTUQVtPYhZ2VZ9ltd0T1Udo=.041146dc-ff8b-4232-8086-ca486119cf34@github.com>
References: <LCKP8juPYXI7kC3l90ci1Y9ifZd1yK70jG6WUQM2TUA=.946e70d1-2233-4564-84d5-12be965ed803@github.com>
 <IAU8saU07kBlMXsFvbeLzTUQVtPYhZ2VZ9ltd0T1Udo=.041146dc-ff8b-4232-8086-ca486119cf34@github.com>
Message-ID: <_DQILl_Hkhoew8aRga0cenhuzvxQwaMmPb1TwZZX0pc=.6d43fd5e-2a2b-428b-9e8d-2fdc2f1d9b7f@github.com>

On Thu, 4 Mar 2021 19:15:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyright update.
>
> Looks good, except you need to update the copyright.

Oops, updated copyright... Thanks.

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

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

From lmesnik at openjdk.java.net  Thu Mar  4 20:59:41 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 4 Mar 2021 20:59:41 GMT
Subject: RFR: 8259577: Dangling reference to temp_path in
 Java_sun_tools_attach_VirtualMachineImpl_getTempDir [v2]
In-Reply-To: <k0jpvpElU29GG0CespRP5xSdXV-4k8OJSm8OpWunsuI=.a70e28f3-1065-4676-bcda-faad7a4ffd89@github.com>
References: <LCKP8juPYXI7kC3l90ci1Y9ifZd1yK70jG6WUQM2TUA=.946e70d1-2233-4564-84d5-12be965ed803@github.com>
 <k0jpvpElU29GG0CespRP5xSdXV-4k8OJSm8OpWunsuI=.a70e28f3-1065-4676-bcda-faad7a4ffd89@github.com>
Message-ID: <QLhg0pH2nwMEFniR-F2-6oOgdp9DAkzO22d99d_3g_0=.12e4344d-f7c9-4aca-b7bf-649e8daf0e27@github.com>

On Thu, 4 Mar 2021 19:47:00 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Hi,
>> This is a pull request for 8259577, which points out that Java_sun_tools_attach_VirtualMachineImpl_getTempDir
>> caches a local variable from a previous call, so could return garbage.
>> However as noted in the bug, we have been safe so far because this method is only called once, so the caching is not required.
>> Thanks.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright update.

Marked as reviewed by lmesnik (Committer).

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

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

From coleenp at openjdk.java.net  Thu Mar  4 22:28:39 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 4 Mar 2021 22:28:39 GMT
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code [v3]
In-Reply-To: <5BCJBgQqTUiNQXzh7i3dEVGlkiZBU5NYQIQp5Ke55L0=.e92797b3-3384-407b-8797-91d171735b30@github.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
 <AFnChy8qG_DR809bNN3Nyjpd52g7UQOzH0rBZirRll8=.1dfee132-23d4-435a-abf0-5677b4039d8e@github.com>
 <5BCJBgQqTUiNQXzh7i3dEVGlkiZBU5NYQIQp5Ke55L0=.e92797b3-3384-407b-8797-91d171735b30@github.com>
Message-ID: <gvqceGdC5L1uaxUrETRXQxweqxHI6N2BnoSlVQhBkkY=.fda575b8-5065-44e3-ad29-844c776ca50e@github.com>

On Thu, 4 Mar 2021 19:07:29 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/runtime/synchronizer.hpp line 92:
>> 
>>> 90:   // This is the "slow path" version of monitor enter and exit.
>>> 91:   static void enter(Handle obj, BasicLock* lock, JavaThread* current);
>>> 92:   static void exit(oop obj, BasicLock* lock, TRAPS);
>> 
>> So are you suggesting that we should have the convention that if a function takes a Thread/JavaThread argument as the last argument, to use "current" rather than "THREAD", since the latter implies it is supposed to be used to pass an argument for the parameter to TRAPS?  I think this is good.  It manages some confusion about trailing THREAD arguments in some callers.  Specializing further to JavaThread from Thread is also a good change.
>
> A suggestion (perhaps as a future RFE), if a function never throws:
> 
> void foo(Class* c, Method*m, Thread* current);
> 
> maybe we should move the last `thread` argument to first:
> 
> void foo(Thread* current, Class* c, Method*m);
> 
> This will make it absolutely sure that `foo` will never throw an exception -- when you are reading a caller of `foo`, you don't need to refer to the declaration of `foo` to know that.
> 
> Also, this will be consistent with our usual convention of passing "bigger" arguments first (Process > Thread -> Class -> method -> bci, etc).

I agree, but I've been and think we should change these as we modified the code, and not wholesale.

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

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

From iklam at openjdk.java.net  Thu Mar  4 22:54:07 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 4 Mar 2021 22:54:07 GMT
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code [v3]
In-Reply-To: <gvqceGdC5L1uaxUrETRXQxweqxHI6N2BnoSlVQhBkkY=.fda575b8-5065-44e3-ad29-844c776ca50e@github.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
 <AFnChy8qG_DR809bNN3Nyjpd52g7UQOzH0rBZirRll8=.1dfee132-23d4-435a-abf0-5677b4039d8e@github.com>
 <5BCJBgQqTUiNQXzh7i3dEVGlkiZBU5NYQIQp5Ke55L0=.e92797b3-3384-407b-8797-91d171735b30@github.com>
 <gvqceGdC5L1uaxUrETRXQxweqxHI6N2BnoSlVQhBkkY=.fda575b8-5065-44e3-ad29-844c776ca50e@github.com>
Message-ID: <5Zgk--NJzA3oG-I-hcZOKm6YYpq6mM-LBiTmQYIjvyc=.18e4b81e-6392-4607-956b-922d578f6d93@github.com>

On Thu, 4 Mar 2021 22:25:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> A suggestion (perhaps as a future RFE), if a function never throws:
>> 
>> void foo(Class* c, Method*m, Thread* current);
>> 
>> maybe we should move the last `thread` argument to first:
>> 
>> void foo(Thread* current, Class* c, Method*m);
>> 
>> This will make it absolutely sure that `foo` will never throw an exception -- when you are reading a caller of `foo`, you don't need to refer to the declaration of `foo` to know that.
>> 
>> Also, this will be consistent with our usual convention of passing "bigger" arguments first (Process > Thread -> Class -> method -> bci, etc).
>
> I agree, but I've been and think we should change these as we modified the code, and not wholesale.

Then maybe we should do the reordering in this PR, since we are changing the parameters anyway.

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

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

From dcubed at openjdk.java.net  Thu Mar  4 23:46:52 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 4 Mar 2021 23:46:52 GMT
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code [v2]
In-Reply-To: <RtvrU7X9v7f_Y42Rqq0NWHWX-rxFDgzcfnhX-A6-nBk=.18d602dd-2725-4d97-a7bf-a4f378659df4@github.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
 <RtvrU7X9v7f_Y42Rqq0NWHWX-rxFDgzcfnhX-A6-nBk=.18d602dd-2725-4d97-a7bf-a4f378659df4@github.com>
Message-ID: <q2sqNS6WlXm_6H-TUorF2lQtgalMqzVMSm6FK4wrfOQ=.5b3faad0-a8d3-4986-b879-653c998ab6a4@github.com>

On Wed, 3 Mar 2021 23:03:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> ObjectMonitors can only be used by JavaThreads (modulo some interactions with hashcodes and deflation) but we use "Thread*" almost everywhere mainly due to use of TRAPS (and TRAPS will itself use JavaThread once JDK-8252685 is done). Also some uses of TRAPS in the API's are wrong as, for example, monitor entry can never throw an exception.
>> 
>> So this cleanup tackles:
>> - remove incorrect use of TRAPS
>> - change "Thread*" to "JavaThread*" where applicable
>> - don't use THREAD for things not related to exception processing
>> - standardise the naming so that we have "JavaThread* current" rather a mix if Self/THREAD/jt etc.
>> - remove unnecessary as_Java_thread() conversions
>> - other misc cleanup I noticed in some functions
>> 
>> The cleanup is predominantly in objectMonitor.* and synchronizer.* but with a fan out to the users of those APIs. No attempt is made to cleanup the callers beyond ensuring we have a suitable JavaThread reference for the calls. 
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - ObjectMonitor::exit can't actually throw IMSE so replaced TRAPS with JavaThread* current
>  - Style fix: Thread *  -> Thread* in type declarations

src/hotspot/share/runtime/objectMonitor.cpp line 1355:

> 1353: //
> 1354: // complete_exit exits a lock returning recursion count
> 1355: // complete_exit/reenter operate as a wait without waiting

Thanks for detecting this stale comment and deleting it.
Also thanks for retiring ExitSuspendEquivalent().

src/hotspot/share/runtime/objectMonitor.cpp line 1402:

> 1400:   do {                                                                 \
> 1401:     if (!check_owner(THREAD)) {                                        \
> 1402:        assert(HAS_PENDING_EXCEPTION, "expected a pending IMSE here."); \

Wow! 3 different ways to refer to the same thread in one function: THREAD, Self and jt.
Thanks for cleaning that up.

src/hotspot/share/runtime/synchronizer.cpp line 316:

> 314:                                      BasicLock * lock) {
> 315:   assert(current->thread_state() == _thread_in_Java, "invariant");
> 316:   NoSafepointVerifier nsv;

Did you mean to delete this assert()? If so, why?
Update: because the next assert rules out being at a safepoint because you
can't have a thread in _thread_in_Java at a safepoint. Okay...

src/hotspot/share/runtime/synchronizer.hpp line 110:

> 108:   // that needs to wait() on a java-level object but must not respond
> 109:   // to interrupt requests and doesn't timeout.
> 110:   static void wait_uninterruptibly(Handle obj, JavaThread* current);

Ahhh - I see now. You got rid of the 'Millis' parameter.

src/hotspot/share/runtime/synchronizer.hpp line 200:

> 198:   BasicLock   _lock;
> 199:  public:
> 200:   ObjectLocker(Handle obj, JavaThread* current);

So no more non-JavaThread uses of ObjectLocker?

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

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

From dcubed at openjdk.java.net  Thu Mar  4 23:46:50 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 4 Mar 2021 23:46:50 GMT
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code [v3]
In-Reply-To: <t3mKAu_gO1j2Aslw952xIm5DuiEWGAN1YBPZG2_5ckI=.90023947-cf48-4ffa-bb22-5f7db5887dfd@github.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
 <t3mKAu_gO1j2Aslw952xIm5DuiEWGAN1YBPZG2_5ckI=.90023947-cf48-4ffa-bb22-5f7db5887dfd@github.com>
Message-ID: <4vZKr9NSgnXKcRYkokO_dGUbP_vaXNR0wqvHDiPo36c=.7b24e8fb-32ed-4d22-8ac4-9d781b4190be@github.com>

On Wed, 3 Mar 2021 23:08:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> ObjectMonitors can only be used by JavaThreads (modulo some interactions with hashcodes and deflation) but we use "Thread*" almost everywhere mainly due to use of TRAPS (and TRAPS will itself use JavaThread once JDK-8252685 is done). Also some uses of TRAPS in the API's are wrong as, for example, monitor entry can never throw an exception.
>> 
>> So this cleanup tackles:
>> - remove incorrect use of TRAPS
>> - change "Thread*" to "JavaThread*" where applicable
>> - don't use THREAD for things not related to exception processing
>> - standardise the naming so that we have "JavaThread* current" rather a mix if Self/THREAD/jt etc.
>> - remove unnecessary as_Java_thread() conversions
>> - other misc cleanup I noticed in some functions
>> 
>> The cleanup is predominantly in objectMonitor.* and synchronizer.* but with a fan out to the users of those APIs. No attempt is made to cleanup the callers beyond ensuring we have a suitable JavaThread reference for the calls. 
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More pointer declaration style fixups

I think I only have nits and typos.
Thanks for doing this massive cleanup!

src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 261:

> 259:   volatile_nonstatic_field(ObjectMonitor,      _cxq,                                          ObjectWaiter*)                         \
> 260:   volatile_nonstatic_field(ObjectMonitor,      _EntryList,                                    ObjectWaiter*)                         \
> 261:   volatile_nonstatic_field(ObjectMonitor,      _succ,                                         JavaThread*)                               \

nit - please fix the indent before the backslash...

src/hotspot/share/oops/instanceKlass.cpp line 946:

> 944:     HandleMark hm(THREAD);
> 945:     Handle h_init_lock(THREAD, init_lock());
> 946:     ObjectLocker ol(h_init_lock, jt);

I was going to mumble about adding a new 'jt' here, but this isn't an
ObjectMonitor related file so you probably held off here.

src/hotspot/share/runtime/objectMonitor.hpp line 49:

> 47:   ObjectWaiter* volatile _next;
> 48:   ObjectWaiter* volatile _prev;
> 49:   JavaThread*   _thread;

So no more uses of ObjectWaiter by non-JavaThreads?

src/hotspot/share/runtime/synchronizer.cpp line 437:

> 435:       BiasedLocking::revoke(obj, current);
> 436:     } else {
> 437:       guarantee(false, "VMThread should not be involved with ObjectMonitor");

Interesting change. Seems out of context for this change.
Since you have "guarantee(false," you can use "fatal(" instead...

src/hotspot/share/runtime/synchronizer.cpp line 612:

> 610:   ObjectMonitor* monitor = inflate(current, obj, inflate_cause_jni_exit);
> 611:   // If this thread has locked the object, exit the monitor. We
> 612:   // intentionally do not use CHECK on check_owner because we must exit the

s/CHECK on check_owner/check_owner/

src/hotspot/share/runtime/synchronizer.cpp line 678:

> 676:   // after ownership is regained.
> 677:   ObjectMonitor* monitor = inflate(current, obj(), inflate_cause_wait);
> 678:   monitor->wait(0 /* wait-forever */, false /* not interruptible */, current);

Didn't expect to see this change from "millis" to "0" either.
Seems out of context for this change.

Update: I see that you deleted the 'millis' param now. I missed that before.

src/hotspot/share/runtime/synchronizer.cpp line 1071:

> 1069:       // monitors_iterate() is only called at a safepoint or when the
> 1070:       // target thread is suspended or when the target thread is
> 1071:       // operating on itcurrent. The current closures in use today are

typo - s/itcurrent/itself/

src/hotspot/share/runtime/synchronizer.hpp line 206:

> 204:   void wait(TRAPS)  { ObjectSynchronizer::wait(_obj, 0, CHECK); } // wait forever
> 205:   void notify_all(TRAPS)  { ObjectSynchronizer::notifyall(_obj, CHECK); }
> 206:   void wait_uninterruptibly(JavaThread* current) { ObjectSynchronizer::wait_uninterruptibly(_obj, current); }

Any reason for not use 'current_thread' here?

src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java line 516:

> 514:     public final int objectMonitorCxq = getFieldOffset("ObjectMonitor::_cxq", Integer.class, "ObjectWaiter*", -1, jdk13Backport);
> 515:     public final int objectMonitorEntryList = getFieldOffset("ObjectMonitor::_EntryList", Integer.class, "ObjectWaiter*", -1, jdk13Backport);
> 516:     public final int objectMonitorSucc = getFieldOffset("ObjectMonitor::_succ", Integer.class, JDK < 17 ? "Thread*" : "JavaThread*", -1, jdk13Backport);

That makes my brain hurt...

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

Marked as reviewed by dcubed (Reviewer).

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

From dcubed at openjdk.java.net  Thu Mar  4 23:46:53 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 4 Mar 2021 23:46:53 GMT
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code [v3]
In-Reply-To: <AFnChy8qG_DR809bNN3Nyjpd52g7UQOzH0rBZirRll8=.1dfee132-23d4-435a-abf0-5677b4039d8e@github.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
 <AFnChy8qG_DR809bNN3Nyjpd52g7UQOzH0rBZirRll8=.1dfee132-23d4-435a-abf0-5677b4039d8e@github.com>
Message-ID: <Dwg6DDTzYvoNUz_P4XpfnypEkfYvhB7kJ4OgqPN2Re0=.78e4e7de-ce59-4ce2-aa35-ede3c32a469b@github.com>

On Wed, 3 Mar 2021 16:25:37 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More pointer declaration style fixups
>
> src/hotspot/share/runtime/synchronizer.hpp line 146:
> 
>> 144: 
>> 145:   // Deflate idle monitors:
>> 146:   static void chk_for_block_req(JavaThread* current, const char* op_name,
> 
> I like "current" better than "self" as a convention.

Out of all the changes from "self" -> "current"... how did you decide to land
a comment on this one... :-)

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

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

From david.holmes at oracle.com  Fri Mar  5 04:03:58 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 5 Mar 2021 14:03:58 +1000
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code [v3]
In-Reply-To: <5Zgk--NJzA3oG-I-hcZOKm6YYpq6mM-LBiTmQYIjvyc=.18e4b81e-6392-4607-956b-922d578f6d93@github.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
 <AFnChy8qG_DR809bNN3Nyjpd52g7UQOzH0rBZirRll8=.1dfee132-23d4-435a-abf0-5677b4039d8e@github.com>
 <5BCJBgQqTUiNQXzh7i3dEVGlkiZBU5NYQIQp5Ke55L0=.e92797b3-3384-407b-8797-91d171735b30@github.com>
 <gvqceGdC5L1uaxUrETRXQxweqxHI6N2BnoSlVQhBkkY=.fda575b8-5065-44e3-ad29-844c776ca50e@github.com>
 <5Zgk--NJzA3oG-I-hcZOKm6YYpq6mM-LBiTmQYIjvyc=.18e4b81e-6392-4607-956b-922d578f6d93@github.com>
Message-ID: <f43bbaf0-6367-d6f6-ae69-eeb49e9f5a03@oracle.com>

On 5/03/2021 8:54 am, Ioi Lam wrote:
> On Thu, 4 Mar 2021 22:25:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
> 
>>> A suggestion (perhaps as a future RFE), if a function never throws:
>>>
>>> void foo(Class* c, Method*m, Thread* current);
>>>
>>> maybe we should move the last `thread` argument to first:
>>>
>>> void foo(Thread* current, Class* c, Method*m);
>>>
>>> This will make it absolutely sure that `foo` will never throw an exception -- when you are reading a caller of `foo`, you don't need to refer to the declaration of `foo` to know that.
>>>
>>> Also, this will be consistent with our usual convention of passing "bigger" arguments first (Process > Thread -> Class -> method -> bci, etc).
>>
>> I agree, but I've been and think we should change these as we modified the code, and not wholesale.
> 
> Then maybe we should do the reordering in this PR, since we are changing the parameters anyway.

I don't agree with this general "rule". Most of the time the Thread* is 
not truly a part of the API, just "tramp data" that needs to get passed 
through so that we minimise the need to manifest Thread::current. So to 
me it is appropriate that this goes at the end.

Cheers,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/2802
> 

From david.holmes at oracle.com  Fri Mar  5 04:12:03 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 5 Mar 2021 14:12:03 +1000
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code [v2]
In-Reply-To: <q2sqNS6WlXm_6H-TUorF2lQtgalMqzVMSm6FK4wrfOQ=.5b3faad0-a8d3-4986-b879-653c998ab6a4@github.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
 <RtvrU7X9v7f_Y42Rqq0NWHWX-rxFDgzcfnhX-A6-nBk=.18d602dd-2725-4d97-a7bf-a4f378659df4@github.com>
 <q2sqNS6WlXm_6H-TUorF2lQtgalMqzVMSm6FK4wrfOQ=.5b3faad0-a8d3-4986-b879-653c998ab6a4@github.com>
Message-ID: <bdc37803-d86e-6bbe-1144-b089585fb64b@oracle.com>

Hi Dan,

Thanks for taking a look at this.

Trimming ...

On 5/03/2021 9:46 am, Daniel D.Daugherty wrote:
> src/hotspot/share/runtime/synchronizer.hpp line 200:
> 
>> 198:   BasicLock   _lock;
>> 199:  public:
>> 200:   ObjectLocker(Handle obj, JavaThread* current);
> 
> So no more non-JavaThread uses of ObjectLocker?

Are you aware of any? ObjectLocker (and ObjectWaiter) pertain to 
ObjectMonitors, and ObjectMonitors can only be acquired by JavaThreads. 
Otherwise this whole change needs to be undone. :)

Thanks,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/2802
> 

From david.holmes at oracle.com  Fri Mar  5 04:55:04 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 5 Mar 2021 14:55:04 +1000
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code [v3]
In-Reply-To: <4vZKr9NSgnXKcRYkokO_dGUbP_vaXNR0wqvHDiPo36c=.7b24e8fb-32ed-4d22-8ac4-9d781b4190be@github.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
 <t3mKAu_gO1j2Aslw952xIm5DuiEWGAN1YBPZG2_5ckI=.90023947-cf48-4ffa-bb22-5f7db5887dfd@github.com>
 <4vZKr9NSgnXKcRYkokO_dGUbP_vaXNR0wqvHDiPo36c=.7b24e8fb-32ed-4d22-8ac4-9d781b4190be@github.com>
Message-ID: <bb3749bf-77cc-2aa8-d5e9-229bd532274f@oracle.com>

Hi again Dan,

(I've given up trying to figure out how PR review emails get split up. :) )

Trimming ...

On 5/03/2021 9:46 am, Daniel D.Daugherty wrote:
> src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 261:
> 
>> 259:   volatile_nonstatic_field(ObjectMonitor,      _cxq,                                          ObjectWaiter*)                         \
>> 260:   volatile_nonstatic_field(ObjectMonitor,      _EntryList,                                    ObjectWaiter*)                         \
>> 261:   volatile_nonstatic_field(ObjectMonitor,      _succ,                                         JavaThread*)                               \
> 
> nit - please fix the indent before the backslash...

Fixed.

> src/hotspot/share/oops/instanceKlass.cpp line 946:
> 
>> 944:     HandleMark hm(THREAD);
>> 945:     Handle h_init_lock(THREAD, init_lock());
>> 946:     ObjectLocker ol(h_init_lock, jt);
> 
> I was going to mumble about adding a new 'jt' here, but this isn't an
> ObjectMonitor related file so you probably held off here.

Yes, and "jt" already exists as the JavaThread manifestation of Thread.

> src/hotspot/share/runtime/objectMonitor.hpp line 49:
> 
>> 47:   ObjectWaiter* volatile _next;
>> 48:   ObjectWaiter* volatile _prev;
>> 49:   JavaThread*   _thread;
> 
> So no more uses of ObjectWaiter by non-JavaThreads?

See other email. AFAIA non-JavaThreads can wait on ObjectMonitors.

> src/hotspot/share/runtime/synchronizer.cpp line 437:
> 
>> 435:       BiasedLocking::revoke(obj, current);
>> 436:     } else {
>> 437:       guarantee(false, "VMThread should not be involved with ObjectMonitor");
> 
> Interesting change. Seems out of context for this change.
> Since you have "guarantee(false," you can use "fatal(" instead...

This is an incomplete change. Earlier I still had TRAPS on enter() even 
though it must be a JavaThread so I changed the BL code fragment to the 
above. But then when I realized enter() never produces an exception, the 
TRAPS became JavaThread* and so it is impossible to be at a safepoint 
(or in the VMThread.). So I've reformulated that block. Thanks for noticing!

> src/hotspot/share/runtime/synchronizer.cpp line 612:
> 
>> 610:   ObjectMonitor* monitor = inflate(current, obj, inflate_cause_jni_exit);
>> 611:   // If this thread has locked the object, exit the monitor. We
>> 612:   // intentionally do not use CHECK on check_owner because we must exit the
> 
> s/CHECK on check_owner/check_owner/

No, the comment is explaining why we do not have this:

   bool owned = monitor->check_owner(CHECK);
   if (owned) {
     monitor->exit(true, current);
   }

the exception we are concerned about is not the one that might be posted 
by check_owner, but any pre-existing pending exception that might be 
present. We must release the monitor regardless.


> src/hotspot/share/runtime/synchronizer.cpp line 678:
> 
>> 676:   // after ownership is regained.
>> 677:   ObjectMonitor* monitor = inflate(current, obj(), inflate_cause_wait);
>> 678:   monitor->wait(0 /* wait-forever */, false /* not interruptible */, current);
> 
> Didn't expect to see this change from "millis" to "0" either.
> Seems out of context for this change.
> 
> Update: I see that you deleted the 'millis' param now. I missed that before.

Yes a "target of opportunity" given the other changes to this method.

> src/hotspot/share/runtime/synchronizer.cpp line 1071:
> 
>> 1069:       // monitors_iterate() is only called at a safepoint or when the
>> 1070:       // target thread is suspended or when the target thread is
>> 1071:       // operating on itcurrent. The current closures in use today are
> 
> typo - s/itcurrent/itself/

Well spotted! (Did that on purpose just to see who was paying attention 
- NOT! :) )

> src/hotspot/share/runtime/synchronizer.hpp line 206:
> 
>> 204:   void wait(TRAPS)  { ObjectSynchronizer::wait(_obj, 0, CHECK); } // wait forever
>> 205:   void notify_all(TRAPS)  { ObjectSynchronizer::notifyall(_obj, CHECK); }
>> 206:   void wait_uninterruptibly(JavaThread* current) { ObjectSynchronizer::wait_uninterruptibly(_obj, current); }
> 
> Any reason for not use 'current_thread' here?

?? I'm using "current" everywhere.

> src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java line 516:
> 
>> 514:     public final int objectMonitorCxq = getFieldOffset("ObjectMonitor::_cxq", Integer.class, "ObjectWaiter*", -1, jdk13Backport);
>> 515:     public final int objectMonitorEntryList = getFieldOffset("ObjectMonitor::_EntryList", Integer.class, "ObjectWaiter*", -1, jdk13Backport);
>> 516:     public final int objectMonitorSucc = getFieldOffset("ObjectMonitor::_succ", Integer.class, JDK < 17 ? "Thread*" : "JavaThread*", -1, jdk13Backport);
> 
> That makes my brain hurt...

Yeah it needs to maintain backward compatibility.

Thanks for the review!

David
-----

> -------------
> 
> Marked as reviewed by dcubed (Reviewer).
> 
> PR: https://git.openjdk.java.net/jdk/pull/2802
> 

From dholmes at openjdk.java.net  Fri Mar  5 04:59:02 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 5 Mar 2021 04:59:02 GMT
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code [v4]
In-Reply-To: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
Message-ID: <nU8Uca0ilRC5fhJjF7439Q2_WNRQ21pYK3jgJP0YT_8=.fb37074c-234a-493b-b05c-f7319a458c5b@github.com>

> ObjectMonitors can only be used by JavaThreads (modulo some interactions with hashcodes and deflation) but we use "Thread*" almost everywhere mainly due to use of TRAPS (and TRAPS will itself use JavaThread once JDK-8252685 is done). Also some uses of TRAPS in the API's are wrong as, for example, monitor entry can never throw an exception.
> 
> So this cleanup tackles:
> - remove incorrect use of TRAPS
> - change "Thread*" to "JavaThread*" where applicable
> - don't use THREAD for things not related to exception processing
> - standardise the naming so that we have "JavaThread* current" rather a mix if Self/THREAD/jt etc.
> - remove unnecessary as_Java_thread() conversions
> - other misc cleanup I noticed in some functions
> 
> The cleanup is predominantly in objectMonitor.* and synchronizer.* but with a fan out to the users of those APIs. No attempt is made to cleanup the callers beyond ensuring we have a suitable JavaThread reference for the calls. 
> 
> Thanks,
> David

David Holmes has updated the pull request incrementally with three additional commits since the last revision:

 - Fix typo
 - Fixed up BiasedLocking code in ObjectSynchronizer::enter
 - iFixed alignment in macro

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2802/files
  - new: https://git.openjdk.java.net/jdk/pull/2802/files/e8a66366..e8e7674b

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

  Stats: 6 lines in 2 files changed: 0 ins; 4 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2802.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2802/head:pull/2802

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

From david.holmes at oracle.com  Fri Mar  5 05:01:22 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 5 Mar 2021 15:01:22 +1000
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code [v4]
In-Reply-To: <nU8Uca0ilRC5fhJjF7439Q2_WNRQ21pYK3jgJP0YT_8=.fb37074c-234a-493b-b05c-f7319a458c5b@github.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
 <nU8Uca0ilRC5fhJjF7439Q2_WNRQ21pYK3jgJP0YT_8=.fb37074c-234a-493b-b05c-f7319a458c5b@github.com>
Message-ID: <6ccd9d20-0f4e-ac0c-cef5-d044f118c76a@oracle.com>

Could I please get a Thumbs up from serviceability on the two JVMTI 
changes, and from compiler folk on the JVMCI and Graal change.

Thanks,
David

On 5/03/2021 2:59 pm, David Holmes wrote:
>> ObjectMonitors can only be used by JavaThreads (modulo some interactions with hashcodes and deflation) but we use "Thread*" almost everywhere mainly due to use of TRAPS (and TRAPS will itself use JavaThread once JDK-8252685 is done). Also some uses of TRAPS in the API's are wrong as, for example, monitor entry can never throw an exception.
>>
>> So this cleanup tackles:
>> - remove incorrect use of TRAPS
>> - change "Thread*" to "JavaThread*" where applicable
>> - don't use THREAD for things not related to exception processing
>> - standardise the naming so that we have "JavaThread* current" rather a mix if Self/THREAD/jt etc.
>> - remove unnecessary as_Java_thread() conversions
>> - other misc cleanup I noticed in some functions
>>
>> The cleanup is predominantly in objectMonitor.* and synchronizer.* but with a fan out to the users of those APIs. No attempt is made to cleanup the callers beyond ensuring we have a suitable JavaThread reference for the calls.
>>
>> Thanks,
>> David
> 
> David Holmes has updated the pull request incrementally with three additional commits since the last revision:
> 
>   - Fix typo
>   - Fixed up BiasedLocking code in ObjectSynchronizer::enter
>   - iFixed alignment in macro
> 
> -------------
> 
> Changes:
>    - all: https://git.openjdk.java.net/jdk/pull/2802/files
>    - new: https://git.openjdk.java.net/jdk/pull/2802/files/e8a66366..e8e7674b
> 
> Webrevs:
>   - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2802&range=03
>   - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2802&range=02-03
> 
>    Stats: 6 lines in 2 files changed: 0 ins; 4 del; 2 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/2802.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/2802/head:pull/2802
> 
> PR: https://git.openjdk.java.net/jdk/pull/2802
> 

From cjplummer at openjdk.java.net  Fri Mar  5 06:46:38 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 5 Mar 2021 06:46:38 GMT
Subject: RFR: 8262504: Some CLHSDB command cannot know they run on remote
 debugger
In-Reply-To: <hYYLenPIpA840x3tcc3ZikUiZKdJB3mSuxDs00dFdQo=.62e3707c-c3f8-48ab-8d1e-d5b7d42661d4@github.com>
References: <hYYLenPIpA840x3tcc3ZikUiZKdJB3mSuxDs00dFdQo=.62e3707c-c3f8-48ab-8d1e-d5b7d42661d4@github.com>
Message-ID: <QzsqiO3gB4AU3Sq5hdQkRfv0W5NAAv7t7rZh0STOtJs=.c969bcfc-7ea3-43f6-8f88-9e17c98c9bb9@github.com>

On Sun, 28 Feb 2021 13:18:21 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> `pmap` and `pstack` CLHSDB command do not work on remote debugger, we can see following error message:
> 
> hsdb> pmap
> not yet implemented (debugger does not support CDebugger)!
> 
> However, SA has different message for this purpose:
> 
> https://github.com/openjdk/jdk/blob/03d888f463c0a6e3fee70ed8ad606fc0a3082636/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PMap.java#L74-L78
> 
> SA should show "remote configuration is not yet implemented" when it works on remote debugger.

Marked as reviewed by cjplummer (Reviewer).

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

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

From cjplummer at openjdk.java.net  Fri Mar  5 07:07:03 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 5 Mar 2021 07:07:03 GMT
Subject: RFR: 8262520: Add SA Command Line Debugger support to connect to
 debug server [v5]
In-Reply-To: <I5WiKMcEMkjKZi26juD8rXLkeYKuiMAoKpX8vkv7ybk=.33803423-5ffc-4ec5-a022-85ae8196d7a5@github.com>
References: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
 <I5WiKMcEMkjKZi26juD8rXLkeYKuiMAoKpX8vkv7ybk=.33803423-5ffc-4ec5-a022-85ae8196d7a5@github.com>
Message-ID: <vZ_LCBfrFjxQBu2j_egJWQW-iHltM1pWeosqvfXGa6U=.91f7dc04-82ab-470c-be3f-37577ceb0ef2@github.com>

On Thu, 4 Mar 2021 00:02:04 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> `attach` command on CLHSDB supports to attach live process (PID) and coredump, but it cannot connect to debug server. CLHSDB does not have a command to connect to debug server.
>> 
>> Other jhsdb commands (jstack, jmap, etc...) can connect debug server via `--connect` option, so CLHSDB should connect to it.
>> 
>> After this change, you can connect to debug server with 'connect <hostname>'.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update error message in CLHSDB

test/hotspot/jtreg/serviceability/sa/sadebugd/ClhsdbAttachToDebugServer.java line 95:

> 93:             out.shouldMatch("^java/lang/Object @0x[0-9a-f]+$"); // for "class java.lang.Object"
> 94:             out.shouldMatch("^java/lang/String @0x[0-9a-f]+$"); // for "class java.lang.String"
> 95:             out.shouldHaveExitValue(0);

I think you should do more error checking here. If you look at ClhsdbLauncher you will see:
        // This will detect most SA failures, including during the attach.
        oa.shouldNotMatch("^sun.jvm.hotspot.debugger.DebuggerException:.*$");
        // This will detect unexpected exceptions, like NPEs and asserts, that are caught
        // by sun.jvm.hotspot.CommandProcessor.
        oa.shouldNotMatch("^Error: .*$");
I think you could use something similar here.

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

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

From ysuenaga at openjdk.java.net  Fri Mar  5 07:33:06 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Fri, 5 Mar 2021 07:33:06 GMT
Subject: RFR: 8262520: Add SA Command Line Debugger support to connect to
 debug server [v6]
In-Reply-To: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
References: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
Message-ID: <IMzvJPwPM29clXUBuQx8QO15Bt4dRWeXSIaISbvG3Vs=.2f5f50c7-3a6a-477a-b4b5-9139a2823472@github.com>

> `attach` command on CLHSDB supports to attach live process (PID) and coredump, but it cannot connect to debug server. CLHSDB does not have a command to connect to debug server.
> 
> Other jhsdb commands (jstack, jmap, etc...) can connect debug server via `--connect` option, so CLHSDB should connect to it.
> 
> After this change, you can connect to debug server with 'connect <hostname>'.

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Add assertion to check unexpected exceptions are happened in command line debugger

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2773/files
  - new: https://git.openjdk.java.net/jdk/pull/2773/files/59d2dd00..4f1cd7e9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2773&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2773&range=04-05

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

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

From ysuenaga at openjdk.java.net  Fri Mar  5 07:39:41 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Fri, 5 Mar 2021 07:39:41 GMT
Subject: RFR: 8262520: Add SA Command Line Debugger support to connect to
 debug server [v5]
In-Reply-To: <vZ_LCBfrFjxQBu2j_egJWQW-iHltM1pWeosqvfXGa6U=.91f7dc04-82ab-470c-be3f-37577ceb0ef2@github.com>
References: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
 <I5WiKMcEMkjKZi26juD8rXLkeYKuiMAoKpX8vkv7ybk=.33803423-5ffc-4ec5-a022-85ae8196d7a5@github.com>
 <vZ_LCBfrFjxQBu2j_egJWQW-iHltM1pWeosqvfXGa6U=.91f7dc04-82ab-470c-be3f-37577ceb0ef2@github.com>
Message-ID: <Lv-l9k_jvJMkLVfybT1j9B_bixBqxz_2ICQqAcOe358=.dadc1f05-b1ab-47eb-afc9-5259f75fcdcd@github.com>

On Fri, 5 Mar 2021 07:03:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update error message in CLHSDB
>
> test/hotspot/jtreg/serviceability/sa/sadebugd/ClhsdbAttachToDebugServer.java line 95:
> 
>> 93:             out.shouldMatch("^java/lang/Object @0x[0-9a-f]+$"); // for "class java.lang.Object"
>> 94:             out.shouldMatch("^java/lang/String @0x[0-9a-f]+$"); // for "class java.lang.String"
>> 95:             out.shouldHaveExitValue(0);
> 
> I think you should do more error checking here. If you look at ClhsdbLauncher you will see:
>         // This will detect most SA failures, including during the attach.
>         oa.shouldNotMatch("^sun.jvm.hotspot.debugger.DebuggerException:.*$");
>         // This will detect unexpected exceptions, like NPEs and asserts, that are caught
>         // by sun.jvm.hotspot.CommandProcessor.
>         oa.shouldNotMatch("^Error: .*$");
> I think you could use something similar here.

I added them in new commit.
BTW I found out to check warnings which relate to `-Xcheck:jni` at ClhsdbLauncher. I did not add them to ClhsdbAttachToDebugServer because they are not the issue which relates to debug server. Is it ok?

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

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

From cjplummer at openjdk.java.net  Fri Mar  5 08:08:49 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 5 Mar 2021 08:08:49 GMT
Subject: RFR: 8262520: Add SA Command Line Debugger support to connect to
 debug server [v6]
In-Reply-To: <IMzvJPwPM29clXUBuQx8QO15Bt4dRWeXSIaISbvG3Vs=.2f5f50c7-3a6a-477a-b4b5-9139a2823472@github.com>
References: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
 <IMzvJPwPM29clXUBuQx8QO15Bt4dRWeXSIaISbvG3Vs=.2f5f50c7-3a6a-477a-b4b5-9139a2823472@github.com>
Message-ID: <qPLZ_dNZZWzhRCQ3Syxhlww8Fi-TQdLD1dKFFlIbYLU=.7937b239-ed16-4f06-8b59-9f23678fdffc@github.com>

On Fri, 5 Mar 2021 07:33:06 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> `attach` command on CLHSDB supports to attach live process (PID) and coredump, but it cannot connect to debug server. CLHSDB does not have a command to connect to debug server.
>> 
>> Other jhsdb commands (jstack, jmap, etc...) can connect debug server via `--connect` option, so CLHSDB should connect to it.
>> 
>> After this change, you can connect to debug server with 'connect <hostname>'.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add assertion to check unexpected exceptions are happened in command line debugger

Marked as reviewed by cjplummer (Reviewer).

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

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

From cjplummer at openjdk.java.net  Fri Mar  5 08:08:49 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 5 Mar 2021 08:08:49 GMT
Subject: RFR: 8262520: Add SA Command Line Debugger support to connect to
 debug server [v5]
In-Reply-To: <Lv-l9k_jvJMkLVfybT1j9B_bixBqxz_2ICQqAcOe358=.dadc1f05-b1ab-47eb-afc9-5259f75fcdcd@github.com>
References: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
 <I5WiKMcEMkjKZi26juD8rXLkeYKuiMAoKpX8vkv7ybk=.33803423-5ffc-4ec5-a022-85ae8196d7a5@github.com>
 <vZ_LCBfrFjxQBu2j_egJWQW-iHltM1pWeosqvfXGa6U=.91f7dc04-82ab-470c-be3f-37577ceb0ef2@github.com>
 <Lv-l9k_jvJMkLVfybT1j9B_bixBqxz_2ICQqAcOe358=.dadc1f05-b1ab-47eb-afc9-5259f75fcdcd@github.com>
Message-ID: <XH36HMqJRxTLl0SWNg7Y7QVonvKnsbfjEVdBW_LtG0M=.8c11ae49-6451-4635-81d5-d9edc55d30dd@github.com>

On Fri, 5 Mar 2021 07:36:26 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/sa/sadebugd/ClhsdbAttachToDebugServer.java line 95:
>> 
>>> 93:             out.shouldMatch("^java/lang/Object @0x[0-9a-f]+$"); // for "class java.lang.Object"
>>> 94:             out.shouldMatch("^java/lang/String @0x[0-9a-f]+$"); // for "class java.lang.String"
>>> 95:             out.shouldHaveExitValue(0);
>> 
>> I think you should do more error checking here. If you look at ClhsdbLauncher you will see:
>>         // This will detect most SA failures, including during the attach.
>>         oa.shouldNotMatch("^sun.jvm.hotspot.debugger.DebuggerException:.*$");
>>         // This will detect unexpected exceptions, like NPEs and asserts, that are caught
>>         // by sun.jvm.hotspot.CommandProcessor.
>>         oa.shouldNotMatch("^Error: .*$");
>> I think you could use something similar here.
>
> I added them in new commit.
> BTW I found out to check warnings which relate to `-Xcheck:jni` at ClhsdbLauncher. I did not add them to ClhsdbAttachToDebugServer because they are not the issue which relates to debug server. Is it ok?

No need for the `-Xcheck:jni` checks. I added that recently because we did have a bug, but I think we get more than enough testing with it already when running the ClhsdbLauncher tests.

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

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

From lzang at openjdk.java.net  Fri Mar  5 10:55:59 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 5 Mar 2021 10:55:59 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v2]
In-Reply-To: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
Message-ID: <o8MsUTlNpU0z5he9RP2ZOt2JLMCUHnTjw8GCpw3uXWY=.e3556b2d-1e65-43f5-952c-6bc1f0e98e3d@github.com>

> 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out

Lin Zang has updated the pull request incrementally with one additional commit since the last revision:

  reduce memory consumption

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2803/files
  - new: https://git.openjdk.java.net/jdk/pull/2803/files/1fe8c0c7..70e43ddd

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

  Stats: 98 lines in 1 file changed: 50 ins; 3 del; 45 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2803.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2803/head:pull/2803

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

From lzang at openjdk.java.net  Fri Mar  5 11:08:39 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 5 Mar 2021 11:08:39 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out
In-Reply-To: <7p7PD78B0fKuSonRZ44rQWvBKHabsz4n9VT4WbVluFI=.e4248320-f134-4ed0-b073-a3466970932c@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
 <Zvf7GN59hJdc7SgVRao3cEbcpU99CbGceULIfJnDJOE=.4bd79c51-6b9b-4ff9-9ada-dc43fd6ca6e8@github.com>
 <e6bMvI_trIEXu7SAiM98-OpZug3Mwli00owZzLXxJNo=.fa0b5857-28b8-428d-9477-61044e32ad49@github.com>
 <oaMRL-GuwQKYlGByJvPhHH63A4LTvQLsL2W6BOIS6cc=.5ee0e7f9-bdc3-4e51-9fcf-999d607730c1@github.com>
 <7p7PD78B0fKuSonRZ44rQWvBKHabsz4n9VT4WbVluFI=.e4248320-f134-4ed0-b073-a3466970932c@github.com>
Message-ID: <cedPjc6Gumib0S_yqDLAm8up9lPEGguw5w5LJblpKHM=.cad805fe-ab47-4eb4-8c78-e2a17109a2ce@github.com>

On Thu, 4 Mar 2021 13:22:47 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> Thanks for the explanation in the CR. That helps a lot. I didn't have time to get through the review today, but will do so tomorrow.
>
> Hi Chris,
> Thanks a lot, I am still wip to reduce the memory consumption. So I think you could help review after my next update :)
> 
> BRs,
> Lin

Update a new patch that reduce the memory consumption issue.
As mentioned in the CR,  there is internal buffer used for segmented heap dump.  The dumped object data firstly write into this buffer and then flush() when the size is known. when the internal buffer is full, the current implementation do:

- new a larger buffer,  copy data from old buffer into the new one, and then use it as the internal buffer.

This could cause large memory consumption because the old buffer data are copied, and also the old buffer can not be "free" until next GC. 

For example, if the internel buffer's length is 1MB, when it is full, a new 2MB buffer is allocated so there is actually 3MB memory taken (old buffer + new buffer). And in this case, for the ~4GB large array, it keeps generating new buffers and do copying, which takes both CPU and memory intensively and cause the timeout issue.

This patch optimize it by creating a array list of byte[]. when old buffer is full, it saved into the list and the new one is created and used as the internal buffer. In this case, the above example takes 2MB?1MB for old? saved in the list; and 1MB for the new buffer)

Together with the "write through" mode introduced in this PR, by which all arrays are write through to underlying stream and hence no extra buffer requried. The PR could help fix the LargeArray issue and also save memory.

Thanks!
Lin

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

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

From github.com+4146708+a74nh at openjdk.java.net  Fri Mar  5 11:14:49 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Fri, 5 Mar 2021 11:14:49 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <yPuti6hI-2ryTux1GdrZHAcP0n0esc5E1PCPXvm389o=.70b78b9a-365e-4a80-8903-e9a0b822492f@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <WlU-by8oEfoJIVOKjkhNLCPUuW4DdRMAFIO6PWIPzb4=.cbc4742c-d113-4d20-b5f3-9a42655f9b86@github.com>
 <DFLFDkNJ30yiF-YpFG6-NtwDi1iYo__6EgymUpCsXiM=.a622ede5-cd91-44a9-9c93-bc81e25872b4@github.com>
 <2vF8YcQ9CgnLxMus9tHTd4HmFITeH5wddBKzH-QNNEY=.dbfb2cd5-5997-4b79-88a5-d8292fc56965@github.com>
 <tBipBlvx8GoWStqMaVuNMNwr9KpINTecikQczUCv_wI=.18cc127c-8450-430c-a5a3-7dbcd2075ef1@github.com>
 <nPJsUts1-fZDvRZPsROWtSLOP7slGCUYUcjXcSu4d-E=.2b8a7229-13b4-4f07-82bc-fc762c55c526@github.com>
 <yPuti6hI-2ryTux1GdrZHAcP0n0esc5E1PCPXvm389o=.70b78b9a-365e-4a80-8903-e9a0b822492f@github.com>
Message-ID: <ALwCIkHXaVHDCuuko2Vku6HZhRqcVV26sF52Jxl7VvI=.0ba86f48-03fd-46d1-93c3-f2a12effe999@github.com>

On Thu, 4 Mar 2021 18:19:33 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

> Hello
> there is one issue with the info you provided, it's from Xcode12.5 beta.
> And beta license agreement forbids sharing output of beta version of compiler&co
> So we can't say we have issue with newer xcode beta until that beta went public & released.
> Fixing issues you found now will mean someone have violated xcode beta license agreement and made these issues public.

Ok, I wasn't aware of that. I'll downgrade back to the non-beta version.

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

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

From dcubed at openjdk.java.net  Fri Mar  5 16:03:40 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 5 Mar 2021 16:03:40 GMT
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code [v4]
In-Reply-To: <nU8Uca0ilRC5fhJjF7439Q2_WNRQ21pYK3jgJP0YT_8=.fb37074c-234a-493b-b05c-f7319a458c5b@github.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
 <nU8Uca0ilRC5fhJjF7439Q2_WNRQ21pYK3jgJP0YT_8=.fb37074c-234a-493b-b05c-f7319a458c5b@github.com>
Message-ID: <CzcZh2lXCTqIBu3plUtWhhTuur6omHo_GmR_cjQCRn4=.2099700b-89f9-4dd5-ae1f-25cbc90a9924@github.com>

On Fri, 5 Mar 2021 04:59:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> ObjectMonitors can only be used by JavaThreads (modulo some interactions with hashcodes and deflation) but we use "Thread*" almost everywhere mainly due to use of TRAPS (and TRAPS will itself use JavaThread once JDK-8252685 is done). Also some uses of TRAPS in the API's are wrong as, for example, monitor entry can never throw an exception.
>> 
>> So this cleanup tackles:
>> - remove incorrect use of TRAPS
>> - change "Thread*" to "JavaThread*" where applicable
>> - don't use THREAD for things not related to exception processing
>> - standardise the naming so that we have "JavaThread* current" rather a mix if Self/THREAD/jt etc.
>> - remove unnecessary as_Java_thread() conversions
>> - other misc cleanup I noticed in some functions
>> 
>> The cleanup is predominantly in objectMonitor.* and synchronizer.* but with a fan out to the users of those APIs. No attempt is made to cleanup the callers beyond ensuring we have a suitable JavaThread reference for the calls. 
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fix typo
>  - Fixed up BiasedLocking code in ObjectSynchronizer::enter
>  - iFixed alignment in macro

Thumbs up.

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

Marked as reviewed by dcubed (Reviewer).

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

From rrich at openjdk.java.net  Fri Mar  5 17:28:24 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Fri, 5 Mar 2021 17:28:24 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <ALwCIkHXaVHDCuuko2Vku6HZhRqcVV26sF52Jxl7VvI=.0ba86f48-03fd-46d1-93c3-f2a12effe999@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <WlU-by8oEfoJIVOKjkhNLCPUuW4DdRMAFIO6PWIPzb4=.cbc4742c-d113-4d20-b5f3-9a42655f9b86@github.com>
 <DFLFDkNJ30yiF-YpFG6-NtwDi1iYo__6EgymUpCsXiM=.a622ede5-cd91-44a9-9c93-bc81e25872b4@github.com>
 <2vF8YcQ9CgnLxMus9tHTd4HmFITeH5wddBKzH-QNNEY=.dbfb2cd5-5997-4b79-88a5-d8292fc56965@github.com>
 <tBipBlvx8GoWStqMaVuNMNwr9KpINTecikQczUCv_wI=.18cc127c-8450-430c-a5a3-7dbcd2075ef1@github.com>
 <nPJsUts1-fZDvRZPsROWtSLOP7slGCUYUcjXcSu4d-E=.2b8a7229-13b4-4f07-82bc-fc762c55c526@github.com>
 <yPuti6hI-2ryTux1GdrZHAcP0n0esc5E1PCPXvm389o=.70b78b9a-365e-4a80-8903-e9a0b822492f@github.com>
 <ALwCIkHXaVHDCuuko2Vku6HZhRqcVV26sF52Jxl7VvI=.0ba86f48-03fd-46d1-93c3-f2a12effe999@github.com>
Message-ID: <lQbCTtxrMGtcQ9annTOJa_zUPL3db1ETRwVp2sBJ5qA=.611f9f30-fcfa-4f3d-b9b3-11a03b012fb3@github.com>

On Fri, 5 Mar 2021 11:11:44 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

>>> I was building this PR on a new machine, and I now get the following error:
>>> 
>>> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:258:31: error: cast to smaller integer type 'MIDIClientRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
>>> > static MIDIClientRef client = (MIDIClientRef) NULL;
>>> > ^~~~~~~~~~~~~~~~~~~~
>>> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:259:29: error: cast to smaller integer type 'MIDIPortRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
>>> > static MIDIPortRef inPort = (MIDIPortRef) NULL;
>>> > ^~~~~~~~~~~~~~~~~~
>>> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:260:30: error: cast to smaller integer type 'MIDIPortRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
>>> > static MIDIPortRef outPort = (MIDIPortRef) NULL;
>>> > ^~~~~~~~~~~~~~~~~~
>>> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:466:32: error: cast to smaller integer type 'MIDIEndpointRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
>>> > MIDIEndpointRef endpoint = (MIDIEndpointRef) NULL;
>>> > ^~~~~~~~~~~~~~~~~~~~~~
>>> > 4 errors generated.
>>> 
>>> As far as I can tell the only difference between the two systems is the xcode version:
>>> 
>>> New system (failing)
>>> % xcodebuild -version
>>> Xcode 12.5
>>> Build version 12E5244e
>>> 
>>> Old system (working)
>>> % xcodebuild -version
>>> Xcode 12.4
>>> Build version 12D4e
>>> 
>>> Looks like the newer version of Xcode is being a little stricter with casting?
>>> Replacing the NULL with 0 seems to fix the issue.
>> 
>> Hello
>> there is one issue with the info you provided, it's from Xcode12.5 beta.
>> And beta license agreement forbids sharing output of beta version of compiler&co
>> So we can't say we have issue with newer xcode beta until that beta went public & released.
>> Fixing issues you found now will mean someone have violated xcode beta license agreement and made these issues public.
>
>> Hello
>> there is one issue with the info you provided, it's from Xcode12.5 beta.
>> And beta license agreement forbids sharing output of beta version of compiler&co
>> So we can't say we have issue with newer xcode beta until that beta went public & released.
>> Fixing issues you found now will mean someone have violated xcode beta license agreement and made these issues public.
> 
> Ok, I wasn't aware of that. I'll downgrade back to the non-beta version.

Hi,

@VladimirKempik reported failure of CompressedClassPointers.largeHeapAbove32GTest() with [JDK-8262895](https://bugs.openjdk.java.net/browse/JDK-8262895) on macos_aarch64.

He also helped analyzing the issue (thanks!).

Apparently the vm has difficulties mapping the heap of 31GB at one of the preferred addresses given in
[`get_attach_addresses_for_disjoint_mode()`](https://github.com/openjdk/jdk/blob/8d3de4b1bdb5dc13bb7724596dc2123ba05bbb81/src/hotspot/share/memory/virtualspace.cpp#L477). This causes the test failure indirectly.

IMO it could be worth the effort to find out why the heap cannot be mapped at the preferred addresses. Reviewers should decide on it. I wouldn't be able to do it myself though as I don't have access to a macos_aarch64 system.

Alternatively I'd suggest to exlude macos_aarch64 from the subtest largeHeapAbove32GTest.

Best regards,
Richard.

--

#### Details of the analysis

In the following trace we see the vm trying to allocate the heap at addresses given in [`get_attach_addresses_for_disjoint_mode()`](https://github.com/openjdk/jdk/blob/8d3de4b1bdb5dc13bb7724596dc2123ba05bbb81/src/hotspot/share/memory/virtualspace.cpp#L477) without success:

images/jdk/bin/java  -XX:+UnlockDiagnosticVMOptions -XX:+UnlockExperimentalVMOptions -Xmx31g -XX:-UseAOT -Xlog:gc+metaspace=trace,cds=trace,heap+gc+exit=info,gc+heap+coops=trace -Xshare:off -XX:+VerifyBeforeGC -XX:HeapSearchSteps=40 -version
OpenJDK 64-Bit Server VM warning: Shared spaces are not supported in this VM
[0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0000001000000000 heap of size 0x7c1000000
[0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0000001800000000 heap of size 0x7c1000000
[0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0000002000000000 heap of size 0x7c1000000
[0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0000004000000000 heap of size 0x7c1000000
[0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0000005000000000 heap of size 0x7c1000000
[0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0008000000000000 heap of size 0x7c1000000
[0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0010000000000000 heap of size 0x7c1000000
[0.006s][trace][gc,heap,coops] Trying to allocate at address 0x0018000000000000 heap of size 0x7c1000000
[0.006s][trace][gc,heap,coops] Trying to allocate at address 0x0020000000000000 heap of size 0x7c1000000
[0.006s][trace][gc,heap,coops] Trying to allocate at address 0x0080000000000000 heap of size 0x7c1000000
[0.006s][trace][gc,heap,coops] Trying to allocate at address 0x0100000000000000 heap of size 0x7c1000000
[0.006s][trace][gc,heap,coops] Trying to allocate at address 0x0110000000000000 heap of size 0x7c1000000

Finally it gives up and lets the os chose the address:

[0.006s][trace][gc,heap,coops] Trying to allocate at address NULL heap of size 0x7c1000000
[0.006s][debug][gc,heap,coops] Protected page at the reserved heap base: 0x0000000280000000 / 16777216 bytes
[0.006s][debug][gc,heap,coops] Heap address: 0x0000000281000000, size: 31744 MB, Compressed Oops mode: Non-zero based: 0x0000000280000000, Oop shift amount: 3

The os chooses to map the heap at 0x0000000281000000 that is at 10GB. This leaves not much room for a 4GB (*) aligned compressed class space below 32G for a zero based encoding. And indeed we get a compressed class space with an encoding base that is not zero and largeHeapAbove32GTest fails then

[0.007s][info ][gc,metaspace ] Compressed class space mapped at: 0x0000007000000000-0x0000007040000000, reserved size: 1073741824
[0.007s][info ][gc,metaspace ] Narrow klass base: 0x0000007000000000, Narrow klass shift: 0, Narrow klass range: 0x40000000
On macos 10.15 (x86_64) the vm succeeds first try mapping the heap at address 0x0000001000000000.

(*) On aarch64 the encoding base has to be 4GB aligned. Unfortunately the 4GB alignment is enforced to strictly on the start address of the compressed class space instead of enforcing it on the encoding base. See [JDK-8258756](https://bugs.openjdk.java.net/browse/JDK-8258756)

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

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

From cjplummer at openjdk.java.net  Fri Mar  5 19:05:21 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 5 Mar 2021 19:05:21 GMT
Subject: RFR: 8262486: Merge trivial JDWP agent changes from the loom repo
 to the jdk repo [v2]
In-Reply-To: <yHmko3VNeYOAz1V_gPdX6-12LRFibJEiOqu5L8frFEs=.7094c811-fc00-4c3c-bc53-788a3c225f74@github.com>
References: <yHmko3VNeYOAz1V_gPdX6-12LRFibJEiOqu5L8frFEs=.7094c811-fc00-4c3c-bc53-788a3c225f74@github.com>
Message-ID: <n-5naohT74qVTYY0GKrXPK8gZ2Ez0kv6FksHallc8Ks=.70009adb-778b-4915-8900-3cd5ff37dc02@github.com>

> In the loom repo there are a number of trivial changes to the JDWP agent that are not loom specific. Moving them to the jdk repo will make future merges simpler, along with making it easier to get a diff of the important differences between the loom and jdk repos, without the clutter of these trivial changes. The changes I'd like to merge are:
> 
> 1. Very minor code refactoring.
> 2. Comment additions, fixes, and improvements.
> 3. Minor indentation and whitespace changes.
> 4. Added a trivial assert

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  Minor jdwp agent edits from loom project.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2815/files
  - new: https://git.openjdk.java.net/jdk/pull/2815/files/e2c9a451..6a34ada1

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

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

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

From cjplummer at openjdk.java.net  Fri Mar  5 19:05:21 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 5 Mar 2021 19:05:21 GMT
Subject: RFR: 8262486: Merge trivial JDWP agent changes from the loom repo
 to the jdk repo [v2]
In-Reply-To: <q97rkkUpQ5LjPdlYUYjbx4blMeZkYSjAiqCA1Rdj58U=.c972f7b8-46b6-45ba-92e4-eda1ea4a3184@github.com>
References: <yHmko3VNeYOAz1V_gPdX6-12LRFibJEiOqu5L8frFEs=.7094c811-fc00-4c3c-bc53-788a3c225f74@github.com>
 <q97rkkUpQ5LjPdlYUYjbx4blMeZkYSjAiqCA1Rdj58U=.c972f7b8-46b6-45ba-92e4-eda1ea4a3184@github.com>
Message-ID: <Ki1oRy1UCDrM53u938RNbWwhcIWvN5y5GX62vWSuy5k=.5fb2fd27-9924-485a-9d53-281fa57a37ee@github.com>

On Wed, 3 Mar 2021 23:24:52 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor jdwp agent edits from loom project.
>
> Marked as reviewed by amenkov (Reviewer).

@alexmenkov @lmesnik I made a couple of very minor edits. Can you please approve them. Thanks!

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

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

From amenkov at openjdk.java.net  Fri Mar  5 20:48:06 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Fri, 5 Mar 2021 20:48:06 GMT
Subject: RFR: 8262486: Merge trivial JDWP agent changes from the loom repo
 to the jdk repo [v2]
In-Reply-To: <Ki1oRy1UCDrM53u938RNbWwhcIWvN5y5GX62vWSuy5k=.5fb2fd27-9924-485a-9d53-281fa57a37ee@github.com>
References: <yHmko3VNeYOAz1V_gPdX6-12LRFibJEiOqu5L8frFEs=.7094c811-fc00-4c3c-bc53-788a3c225f74@github.com>
 <q97rkkUpQ5LjPdlYUYjbx4blMeZkYSjAiqCA1Rdj58U=.c972f7b8-46b6-45ba-92e4-eda1ea4a3184@github.com>
 <Ki1oRy1UCDrM53u938RNbWwhcIWvN5y5GX62vWSuy5k=.5fb2fd27-9924-485a-9d53-281fa57a37ee@github.com>
Message-ID: <uVvhp9qnrhCCQ6sITzUVsF-eN_fOPRtfoKKa88SXw1Q=.bfcf309b-affb-4e42-b2ed-9c5abcf2c476@github.com>

On Fri, 5 Mar 2021 19:02:57 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> 
> 
> @alexmenkov @lmesnik I made a couple of very minor edits. Can you please approve them. Thanks!

Still LGTM

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

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

From lmesnik at openjdk.java.net  Fri Mar  5 20:55:06 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Fri, 5 Mar 2021 20:55:06 GMT
Subject: RFR: 8262486: Merge trivial JDWP agent changes from the loom repo
 to the jdk repo [v2]
In-Reply-To: <n-5naohT74qVTYY0GKrXPK8gZ2Ez0kv6FksHallc8Ks=.70009adb-778b-4915-8900-3cd5ff37dc02@github.com>
References: <yHmko3VNeYOAz1V_gPdX6-12LRFibJEiOqu5L8frFEs=.7094c811-fc00-4c3c-bc53-788a3c225f74@github.com>
 <n-5naohT74qVTYY0GKrXPK8gZ2Ez0kv6FksHallc8Ks=.70009adb-778b-4915-8900-3cd5ff37dc02@github.com>
Message-ID: <JQpu3RIbkGBYS_JrUgyPA_sJ1N1mVRQYJoya6iqpVLA=.e7187578-68ea-49ca-8ae1-68fab4b78944@github.com>

On Fri, 5 Mar 2021 19:05:21 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> In the loom repo there are a number of trivial changes to the JDWP agent that are not loom specific. Moving them to the jdk repo will make future merges simpler, along with making it easier to get a diff of the important differences between the loom and jdk repos, without the clutter of these trivial changes. The changes I'd like to merge are:
>> 
>> 1. Very minor code refactoring.
>> 2. Comment additions, fixes, and improvements.
>> 3. Minor indentation and whitespace changes.
>> 4. Added a trivial assert
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor jdwp agent edits from loom project.

Marked as reviewed by lmesnik (Committer).

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

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

From alanb at openjdk.java.net  Sat Mar  6 09:38:08 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 6 Mar 2021 09:38:08 GMT
Subject: RFR: JDK-8263104: fix warnings for empty paragraphs
In-Reply-To: <pOVO9eKG44kNe-9b2khf_RCzjzu5mD0H2AeTM7thjog=.fecf709c-28c4-4321-9161-dc3c7892defa@github.com>
References: <pOVO9eKG44kNe-9b2khf_RCzjzu5mD0H2AeTM7thjog=.fecf709c-28c4-4321-9161-dc3c7892defa@github.com>
Message-ID: <6pQuxdYXIeFdsAmjJLMiZgy5pKDxynzkTBjnYSr4SJw=.ff8af313-9adb-426a-89ce-65c16a8317c9@github.com>

On Fri, 5 Mar 2021 19:36:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some simple cleanup for empty `<p>` tags.
> 
> Two of the tags are completely redundant, and simply deleted.
> 
> The other three, in _package.html_ files are generally undesirable. Although the presumed intent of the `id` declaration is to label the `@see` info, proximity in the source code does not ensure proximity in the generated code. The actual result is an empty paragraph at the end of the enclosing generated `<div>`, and before the generated output for the `@since` tag.
> 
> The better solution is to move the `id` declaration into the `@see <a href...` and then delete the empty `<p>`.

Marked as reviewed by alanb (Reviewer).

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

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

From lancea at openjdk.java.net  Sat Mar  6 11:26:06 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Sat, 6 Mar 2021 11:26:06 GMT
Subject: RFR: JDK-8263104: fix warnings for empty paragraphs
In-Reply-To: <pOVO9eKG44kNe-9b2khf_RCzjzu5mD0H2AeTM7thjog=.fecf709c-28c4-4321-9161-dc3c7892defa@github.com>
References: <pOVO9eKG44kNe-9b2khf_RCzjzu5mD0H2AeTM7thjog=.fecf709c-28c4-4321-9161-dc3c7892defa@github.com>
Message-ID: <qZn3caSYyLrLjpLRTGW5J9u2-w88k_d_Wq-qQqHUaG0=.58aa5ed5-f1bc-4006-b5eb-5015d1e162d2@github.com>

On Fri, 5 Mar 2021 19:36:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some simple cleanup for empty `<p>` tags.
> 
> Two of the tags are completely redundant, and simply deleted.
> 
> The other three, in _package.html_ files are generally undesirable. Although the presumed intent of the `id` declaration is to label the `@see` info, proximity in the source code does not ensure proximity in the generated code. The actual result is an empty paragraph at the end of the enclosing generated `<div>`, and before the generated output for the `@since` tag.
> 
> The better solution is to move the `id` declaration into the `@see <a href...` and then delete the empty `<p>`.

Marked as reviewed by lancea (Reviewer).

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

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

From jjg at openjdk.java.net  Sat Mar  6 15:10:07 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Sat, 6 Mar 2021 15:10:07 GMT
Subject: Integrated: JDK-8263104: fix warnings for empty paragraphs
In-Reply-To: <pOVO9eKG44kNe-9b2khf_RCzjzu5mD0H2AeTM7thjog=.fecf709c-28c4-4321-9161-dc3c7892defa@github.com>
References: <pOVO9eKG44kNe-9b2khf_RCzjzu5mD0H2AeTM7thjog=.fecf709c-28c4-4321-9161-dc3c7892defa@github.com>
Message-ID: <6FoMt0zfqvGcDldeeG44yeunGbakXCHgPLIjgzIfvZM=.4f9824c3-4576-4fe8-b816-b5f4ce4534f6@github.com>

On Fri, 5 Mar 2021 19:36:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some simple cleanup for empty `<p>` tags.
> 
> Two of the tags are completely redundant, and simply deleted.
> 
> The other three, in _package.html_ files are generally undesirable. Although the presumed intent of the `id` declaration is to label the `@see` info, proximity in the source code does not ensure proximity in the generated code. The actual result is an empty paragraph at the end of the enclosing generated `<div>`, and before the generated output for the `@since` tag.
> 
> The better solution is to move the `id` declaration into the `@see <a href...` and then delete the empty `<p>`.

This pull request has now been integrated.

Changeset: 71829850
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/71829850
Stats:     8 lines in 5 files changed: 0 ins; 4 del; 4 mod

8263104: fix warnings for empty paragraphs

Reviewed-by: alanb, lancea

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

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

From ysuenaga at openjdk.java.net  Sun Mar  7 10:15:15 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sun, 7 Mar 2021 10:15:15 GMT
Subject: RFR: 8263140: Japanese chars garble in console window in HSDB
Message-ID: <KYApMyFcX3_HUOUotqdR3gw1BALvA7oEqjfFZLecFjw=.3b5a6b82-0cd5-404e-af9f-ceb65ebf14f5@github.com>

We can command line debugger via "Windows" -> "Console" menu on HSDB. If the command shows error message in localized string (e.g. Japanese), it might garble as following:

![garbled](https://user-images.githubusercontent.com/7421132/110232635-39e89b00-7f62-11eb-95c9-1a5238072814.png)

Command line debugger and Debugger Console (WinDbg on Windows) will use Courier font on their console, but it does not show Japanese chars. I guess it would happen on CJK chars because monospaced font for Chinese, Japanese, Korean are different from Courier.

After this change on Windows which set to Japanese locale, it uses MS Gothic and we can see localized message as following:

![fixed](https://user-images.githubusercontent.com/7421132/110232699-a4014000-7f62-11eb-9185-6eff39394541.png)

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

Commit messages:
 - 8263140: Japanese chars garble in console window in HSDB

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

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

From vsharma at openjdk.java.net  Sun Mar  7 10:50:20 2021
From: vsharma at openjdk.java.net (Vipin Sharma)
Date: Sun, 7 Mar 2021 10:50:20 GMT
Subject: RFR: JDK-8261095: Add test for clhsdb symbol command
Message-ID: <vvBz34jYNl1w-989imPpF7K5U-3GYAzTTXGLqV2-2BU=.71fc7da5-36a3-48ba-ba2e-2100f90d1941@github.com>

JDK-8261095: Add test for clhsdb symbol command

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

Commit messages:
 - JDK-8261095: Add test for clhsdb symbol command

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

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

From iklam at openjdk.java.net  Sun Mar  7 19:52:05 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Sun, 7 Mar 2021 19:52:05 GMT
Subject: RFR: 8263140: Japanese chars garble in console window in HSDB
In-Reply-To: <KYApMyFcX3_HUOUotqdR3gw1BALvA7oEqjfFZLecFjw=.3b5a6b82-0cd5-404e-af9f-ceb65ebf14f5@github.com>
References: <KYApMyFcX3_HUOUotqdR3gw1BALvA7oEqjfFZLecFjw=.3b5a6b82-0cd5-404e-af9f-ceb65ebf14f5@github.com>
Message-ID: <pnjMS-QRoV02o8urmDb0QLHoIi4QzYH2dQLuROYiqJ8=.9abeaf7c-ba74-46b9-b80d-4a3faa0b54bb@github.com>

On Sun, 7 Mar 2021 07:32:17 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> We can command line debugger via "Windows" -> "Console" menu on HSDB. If the command shows error message in localized string (e.g. Japanese), it might garble as following:
> 
> ![garbled](https://user-images.githubusercontent.com/7421132/110232635-39e89b00-7f62-11eb-95c9-1a5238072814.png)
> 
> Command line debugger and Debugger Console (WinDbg on Windows) will use Courier font on their console, but it does not show Japanese chars. I guess it would happen on CJK chars because monospaced font for Chinese, Japanese, Korean are different from Courier.
> 
> After this change on Windows which set to Japanese locale, it uses MS Gothic and we can see localized message as following:
> 
> ![fixed](https://user-images.githubusercontent.com/7421132/110232699-a4014000-7f62-11eb-9185-6eff39394541.png)

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/CommandProcessorPanel.java line 63:

> 61:         editor = new JTextArea();
> 62:         editor.setDocument(new EditableAtEndDocument());
> 63:         editor.setFont(new Font(Font.MONOSPACED, Font.PLAIN, GraphicsUtilities.FONT_SIZE));

Maybe this can be changed to `GraphicsUtilities.getMonospacedFont()` so there's no need to export FONT_SIZE?

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

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

From github.com+741251+turbanoff at openjdk.java.net  Sun Mar  7 20:31:08 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 7 Mar 2021 20:31:08 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v11]
In-Reply-To: <fPIf2TG2r9A2gJKfY2q8ifG4fHP7Ed1lHJ1KyExwI-U=.59c5f061-4e65-4db1-8a86-64a97a323b24@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <djPl7TL8j0qwyuLjwnZI96g7UPmw3XamdbVltf8fbos=.36a5bbe7-1fd0-496b-999f-7c49d06fc0a8@github.com>
 <6zhT8ySP8rFE4wV5vva0oKRDSxDnSYYZ-sXAQJ6F_DM=.b83a0f88-7231-4796-a0b5-d51b5950d316@github.com>
 <KKuuOtcyAwZLESU78ZnNaF5LmeoQeWzxj-yO-xCj5ZM=.ea9ff05f-ffea-477f-b7eb-b94df1f186f3@github.com>
 <fPIf2TG2r9A2gJKfY2q8ifG4fHP7Ed1lHJ1KyExwI-U=.59c5f061-4e65-4db1-8a86-64a97a323b24@github.com>
Message-ID: <FtDgzqkxbiUrEEutqoTjnbPiDE5VmJFH4pYDN97jbqA=.92524dca-6010-4d6b-8b29-6801297e1a34@github.com>

On Fri, 19 Feb 2021 15:03:11 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> As I can see only ByteArrayInputStream is actually passed in `InputStream` in current JDK code:
>> 
>>     PKCS7 pkcs7 = new PKCS7(is.readAllBytes());
>>         private static List<X509Certificate> parsePKCS7(InputStream is)
>>             certs = parsePKCS7(is);
>>                 public X509CertPath(InputStream is, String encoding)
>>                     return new X509CertPath(new ByteArrayInputStream(data), encoding);
>> 
>>     PKCS7 pkcs7 = new PKCS7(is.readAllBytes());
>>         private static List<X509Certificate> parsePKCS7(InputStream is)
>>             certs = parsePKCS7(is);
>>                 public X509CertPath(InputStream is, String encoding)
>>                     this(is, PKIPATH_ENCODING);
>>                         public X509CertPath(InputStream is) throws CertificateException {
>>                             return new X509CertPath(new ByteArrayInputStream(encoding));
>> 
>> ![???????????](https://user-images.githubusercontent.com/741251/108475587-f4f61080-72a1-11eb-91e0-ac2b98c7c490.png)
>> 
>> Perhaps original marking approach was lost during refactoring?
>
> You are right, the code was refactored (way back in 2010) [1] to read one block at a time, so this check on mark can be removed. So, in this case, I think it is probably safe to just pass the InputStream as-is to PKCS7(InputStream), but maybe you can add a comment that says this should always be a ByteArrayInputStream. We can look at refactoring this code and clean it up a bit more later.
> 
> [1] https://hg.openjdk.java.net/jdk/jdk/rev/337ae296b6d6

I find implementation of `sun.security.pkcs.PKCS7#PKCS7(java.io.InputStream)` a bit confusing (or even buggy). It uses only `InputStream.available()` to parse block.
So I would prefer to not use it.

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

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

From ysuenaga at openjdk.java.net  Sun Mar  7 23:52:21 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sun, 7 Mar 2021 23:52:21 GMT
Subject: RFR: 8263140: Japanese chars garble in console window in HSDB [v2]
In-Reply-To: <KYApMyFcX3_HUOUotqdR3gw1BALvA7oEqjfFZLecFjw=.3b5a6b82-0cd5-404e-af9f-ceb65ebf14f5@github.com>
References: <KYApMyFcX3_HUOUotqdR3gw1BALvA7oEqjfFZLecFjw=.3b5a6b82-0cd5-404e-af9f-ceb65ebf14f5@github.com>
Message-ID: <aGKpXx_W1YuGiZbvTfe1Kh-wAwiaBtYgZ0HGdzpefVk=.f0b759b2-5bf1-4a73-8bdc-3d9cdc2ec288@github.com>

> We can command line debugger via "Windows" -> "Console" menu on HSDB. If the command shows error message in localized string (e.g. Japanese), it might garble as following:
> 
> ![garbled](https://user-images.githubusercontent.com/7421132/110232635-39e89b00-7f62-11eb-95c9-1a5238072814.png)
> 
> Command line debugger and Debugger Console (WinDbg on Windows) will use Courier font on their console, but it does not show Japanese chars. I guess it would happen on CJK chars because monospaced font for Chinese, Japanese, Korean are different from Courier.
> 
> After this change on Windows which set to Japanese locale, it uses MS Gothic and we can see localized message as following:
> 
> ![fixed](https://user-images.githubusercontent.com/7421132/110232699-a4014000-7f62-11eb-9185-6eff39394541.png)

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Add GraphicsUtilities.getMonospacedFont()

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2862/files
  - new: https://git.openjdk.java.net/jdk/pull/2862/files/a5f6647f..c0a5844a

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

  Stats: 7 lines in 3 files changed: 4 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2862.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2862/head:pull/2862

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

From ysuenaga at openjdk.java.net  Sun Mar  7 23:57:07 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sun, 7 Mar 2021 23:57:07 GMT
Subject: RFR: 8263140: Japanese chars garble in console window in HSDB [v2]
In-Reply-To: <pnjMS-QRoV02o8urmDb0QLHoIi4QzYH2dQLuROYiqJ8=.9abeaf7c-ba74-46b9-b80d-4a3faa0b54bb@github.com>
References: <KYApMyFcX3_HUOUotqdR3gw1BALvA7oEqjfFZLecFjw=.3b5a6b82-0cd5-404e-af9f-ceb65ebf14f5@github.com>
 <pnjMS-QRoV02o8urmDb0QLHoIi4QzYH2dQLuROYiqJ8=.9abeaf7c-ba74-46b9-b80d-4a3faa0b54bb@github.com>
Message-ID: <J76QHGNU1vh5U9hJ1aKJe7KtNIaoz98Jb7drlY3tU3w=.c36d39bb-1643-424e-9286-8ea32d4425a6@github.com>

On Sun, 7 Mar 2021 19:49:12 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Maybe this can be changed to `GraphicsUtilities.getMonospacedFont()` so there's no need to export FONT_SIZE?

Yeah, it is the point what I thought too, but I didn't do so because it is one liner.
However I re-think about it from your comment, so I pushed new commit to add `GraphicsUtilities.getMonospacedFont()`.

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

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

From iklam at openjdk.java.net  Mon Mar  8 00:26:06 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 8 Mar 2021 00:26:06 GMT
Subject: RFR: 8263140: Japanese chars garble in console window in HSDB [v2]
In-Reply-To: <aGKpXx_W1YuGiZbvTfe1Kh-wAwiaBtYgZ0HGdzpefVk=.f0b759b2-5bf1-4a73-8bdc-3d9cdc2ec288@github.com>
References: <KYApMyFcX3_HUOUotqdR3gw1BALvA7oEqjfFZLecFjw=.3b5a6b82-0cd5-404e-af9f-ceb65ebf14f5@github.com>
 <aGKpXx_W1YuGiZbvTfe1Kh-wAwiaBtYgZ0HGdzpefVk=.f0b759b2-5bf1-4a73-8bdc-3d9cdc2ec288@github.com>
Message-ID: <9EJHm1SQNQHDjeMqJxdVUvtFf2zSwq37Ia2whGLH25Y=.2d17b78e-65ff-42c9-9a11-28dfe4480be0@github.com>

On Sun, 7 Mar 2021 23:52:21 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We can command line debugger via "Windows" -> "Console" menu on HSDB. If the command shows error message in localized string (e.g. Japanese), it might garble as following:
>> 
>> ![garbled](https://user-images.githubusercontent.com/7421132/110232635-39e89b00-7f62-11eb-95c9-1a5238072814.png)
>> 
>> Command line debugger and Debugger Console (WinDbg on Windows) will use Courier font on their console, but it does not show Japanese chars. I guess it would happen on CJK chars because monospaced font for Chinese, Japanese, Korean are different from Courier.
>> 
>> After this change on Windows which set to Japanese locale, it uses MS Gothic and we can see localized message as following:
>> 
>> ![fixed](https://user-images.githubusercontent.com/7421132/110232699-a4014000-7f62-11eb-9185-6eff39394541.png)
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add GraphicsUtilities.getMonospacedFont()

LGTM

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

Marked as reviewed by iklam (Reviewer).

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

From kiriyama.takuya at fujitsu.com  Mon Mar  8 00:47:57 2021
From: kiriyama.takuya at fujitsu.com (kiriyama.takuya at fujitsu.com)
Date: Mon, 8 Mar 2021 00:47:57 +0000
Subject: Online user guide for jconsole is wrong
Message-ID: <TYAPR01MB25111FB923C5305EB1E59A25E7939@TYAPR01MB2511.jpnprd01.prod.outlook.com>

Hello.

The URL to the online user guide on the help menu in JConsole is wrong in Java 15.

Now this URL is:
http://docs.oracle.com/javase/15/docs/technotes/guides/management/jconsole.html
However, the the online user guide page pointed by this URL doesn't exists.
It should be:
https://docs.oracle.com/en/java/javase/{java version}/docs/specs/man/jconsole.html
The page pointed by this URL exists for Java 12, 13, 14 and 15.

Please consider the following code:

diff --git a/src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages.properties b/src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages.properties
index 24c2209ad0d..8af36f5d148 100644
--- a/src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages.properties
+++ b/src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages.properties
@@ -129,7 +129,7 @@ HELP_ABOUT_DIALOG_JAVA_VERSION=Java VM version:<br>{0}
 HELP_ABOUT_DIALOG_MASTHEAD_ACCESSIBLE_NAME=Masthead Graphic
 HELP_ABOUT_DIALOG_MASTHEAD_TITLE=About JConsole
 HELP_ABOUT_DIALOG_TITLE=JConsole: About
-HELP_ABOUT_DIALOG_USER_GUIDE_LINK_URL=http://docs.oracle.com/javase/{0}/docs/technotes/guides/management/jconsole.html
+HELP_ABOUT_DIALOG_USER_GUIDE_LINK_URL=https://docs.oracle.com/en/java/javase/{0}/docs/specs/man/jconsole.html
 HELP_MENU_ABOUT_TITLE=&About JConsole
 HELP_MENU_USER_GUIDE_TITLE=Online &User Guide
 HELP_MENU_TITLE=&Help
diff --git a/src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_ja.properties b/src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_ja.properties
index 2847da2e0a2..1ec346a36a5 100644
--- a/src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_ja.properties
+++ b/src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_ja.properties
@@ -130,6 +130,7 @@ HELP_ABOUT_DIALOG_MASTHEAD_ACCESSIBLE_NAME=\u30DE\u30B9\u30C8\u30D8\u30C3\u30C9\
 HELP_ABOUT_DIALOG_MASTHEAD_TITLE=JConsole\u306B\u3064\u3044\u3066
 HELP_ABOUT_DIALOG_TITLE=JConsole: \u8A73\u7D30
 HELP_ABOUT_DIALOG_USER_GUIDE_LINK_URL=http://docs.oracle.com/javase/{0}/docs/technotes/guides/management/jconsole.html
+HELP_ABOUT_DIALOG_USER_GUIDE_LINK_URL=https://docs.oracle.com/en/java/javase/{0}/docs/specs/man/jconsole.html
 HELP_MENU_ABOUT_TITLE=JConsole\u306B\u3064\u3044\u3066(&A)
 HELP_MENU_USER_GUIDE_TITLE=\u30AA\u30F3\u30E9\u30A4\u30F3\u30FB\u30E6\u30FC\u30B6\u30FC\u30FB\u30AC\u30A4\u30C9(&U)
 HELP_MENU_TITLE=\u30D8\u30EB\u30D7(&H)
diff --git a/src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties b/src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties
index 1541bf99968..57943d5f007 100644
--- a/src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties
+++ b/src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties
@@ -129,7 +129,7 @@ HELP_ABOUT_DIALOG_JAVA_VERSION=Java VM \u7248\u672C:<br>{0}
 HELP_ABOUT_DIALOG_MASTHEAD_ACCESSIBLE_NAME=\u62A5\u5934\u56FE
 HELP_ABOUT_DIALOG_MASTHEAD_TITLE=\u5173\u4E8E JConsole
 HELP_ABOUT_DIALOG_TITLE=JConsole: \u5173\u4E8E
-HELP_ABOUT_DIALOG_USER_GUIDE_LINK_URL=http://docs.oracle.com/javase/{0}/docs/technotes/guides/management/jconsole.html
+HELP_ABOUT_DIALOG_USER_GUIDE_LINK_URL=https://docs.oracle.com/en/java/javase/{0}/docs/specs/man/jconsole.html
 HELP_MENU_ABOUT_TITLE=\u5173\u4E8E JConsole(&A)
 HELP_MENU_USER_GUIDE_TITLE=\u8054\u673A\u7528\u6237\u6307\u5357(&U)
 HELP_MENU_TITLE=\u5E2E\u52A9(&H)

Regards,
Takuya Kiriyama

<????>---------------------------------------------------------------------
??????????????????
????????MW?????????
?????(Kiriyama Takuya)(kiriyama.takuya at jp.fujitsu.com)
TEL?044-863-9653????6028-0132?


From kevinw at openjdk.java.net  Mon Mar  8 11:44:06 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Mon, 8 Mar 2021 11:44:06 GMT
Subject: Integrated: 8259577: Dangling reference to temp_path in
 Java_sun_tools_attach_VirtualMachineImpl_getTempDir
In-Reply-To: <LCKP8juPYXI7kC3l90ci1Y9ifZd1yK70jG6WUQM2TUA=.946e70d1-2233-4564-84d5-12be965ed803@github.com>
References: <LCKP8juPYXI7kC3l90ci1Y9ifZd1yK70jG6WUQM2TUA=.946e70d1-2233-4564-84d5-12be965ed803@github.com>
Message-ID: <fvF7VKl7H3b1GzAM9Pb305ohc3TqiySPJWxjhMLb5NQ=.cf619998-9fce-4534-abf4-ceead7579a74@github.com>

On Thu, 4 Mar 2021 18:27:48 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Hi,
> This is a pull request for 8259577, which points out that Java_sun_tools_attach_VirtualMachineImpl_getTempDir
> caches a local variable from a previous call, so could return garbage.
> However as noted in the bug, we have been safe so far because this method is only called once, so the caching is not required.
> Thanks.

This pull request has now been integrated.

Changeset: 51cca57c
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/51cca57c
Stats:     11 lines in 1 file changed: 0 ins; 3 del; 8 mod

8259577: Dangling reference to temp_path in Java_sun_tools_attach_VirtualMachineImpl_getTempDir

Reviewed-by: cjplummer, lmesnik

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

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

From chris.plummer at oracle.com  Mon Mar  8 18:34:37 2021
From: chris.plummer at oracle.com (Chris Plummer)
Date: Mon, 8 Mar 2021 10:34:37 -0800
Subject: Online user guide for jconsole is wrong
In-Reply-To: <TYAPR01MB25111FB923C5305EB1E59A25E7939@TYAPR01MB2511.jpnprd01.prod.outlook.com>
References: <TYAPR01MB25111FB923C5305EB1E59A25E7939@TYAPR01MB2511.jpnprd01.prod.outlook.com>
Message-ID: <1e17ab17-6705-b608-1efb-b9f6df0f7595@oracle.com>

Hi Takuya,

I filed https://bugs.openjdk.java.net/browse/JDK-8263203 for this issue. 
Normally bugs are fixed in the current source first (JDK 17), and then 
backported to older releases. However, given that the docss for JDK 17 
don't exist yet, you still end up with an invalid URL, and there's no 
guarantee the URL will be correct when the JDK 17 docs appear. I will 
need to get some guidance how proceed with this fix.

thanks,

Chris

On 3/7/21 4:47 PM, kiriyama.takuya at fujitsu.com wrote:
> diff --git a/src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages.properties b/src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages.properties
> index 24c2209ad0d..8af36f5d148 100644
> --- a/src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages.properties
> +++ b/src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages.properties
> @@ -129,7 +129,7 @@ HELP_ABOUT_DIALOG_JAVA_VERSION=Java VM version:<br>{0}
>   HELP_ABOUT_DIALOG_MASTHEAD_ACCESSIBLE_NAME=Masthead Graphic
>   HELP_ABOUT_DIALOG_MASTHEAD_TITLE=About JConsole
>   HELP_ABOUT_DIALOG_TITLE=JConsole: About
> -HELP_ABOUT_DIALOG_USER_GUIDE_LINK_URL=http://docs.oracle.com/javase/{0}/docs/technotes/guides/management/jconsole.html
> +HELP_ABOUT_DIALOG_USER_GUIDE_LINK_URL=https://docs.oracle.com/en/java/javase/{0}/docs/specs/man/jconsole.html
>   HELP_MENU_ABOUT_TITLE=&About JConsole
>   HELP_MENU_USER_GUIDE_TITLE=Online &User Guide
>   HELP_MENU_TITLE=&Help
> diff --git a/src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_ja.properties b/src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_ja.properties
> index 2847da2e0a2..1ec346a36a5 100644
> --- a/src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_ja.properties
> +++ b/src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_ja.properties
> @@ -130,6 +130,7 @@ HELP_ABOUT_DIALOG_MASTHEAD_ACCESSIBLE_NAME=\u30DE\u30B9\u30C8\u30D8\u30C3\u30C9\
>   HELP_ABOUT_DIALOG_MASTHEAD_TITLE=JConsole\u306B\u3064\u3044\u3066
>   HELP_ABOUT_DIALOG_TITLE=JConsole: \u8A73\u7D30
>   HELP_ABOUT_DIALOG_USER_GUIDE_LINK_URL=http://docs.oracle.com/javase/{0}/docs/technotes/guides/management/jconsole.html
> +HELP_ABOUT_DIALOG_USER_GUIDE_LINK_URL=https://docs.oracle.com/en/java/javase/{0}/docs/specs/man/jconsole.html
>   HELP_MENU_ABOUT_TITLE=JConsole\u306B\u3064\u3044\u3066(&A)
>   HELP_MENU_USER_GUIDE_TITLE=\u30AA\u30F3\u30E9\u30A4\u30F3\u30FB\u30E6\u30FC\u30B6\u30FC\u30FB\u30AC\u30A4\u30C9(&U)
>   HELP_MENU_TITLE=\u30D8\u30EB\u30D7(&H)
> diff --git a/src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties b/src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties
> index 1541bf99968..57943d5f007 100644
> --- a/src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties
> +++ b/src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties
> @@ -129,7 +129,7 @@ HELP_ABOUT_DIALOG_JAVA_VERSION=Java VM \u7248\u672C:<br>{0}
>   HELP_ABOUT_DIALOG_MASTHEAD_ACCESSIBLE_NAME=\u62A5\u5934\u56FE
>   HELP_ABOUT_DIALOG_MASTHEAD_TITLE=\u5173\u4E8E JConsole
>   HELP_ABOUT_DIALOG_TITLE=JConsole: \u5173\u4E8E
> -HELP_ABOUT_DIALOG_USER_GUIDE_LINK_URL=http://docs.oracle.com/javase/{0}/docs/technotes/guides/management/jconsole.html
> +HELP_ABOUT_DIALOG_USER_GUIDE_LINK_URL=https://docs.oracle.com/en/java/javase/{0}/docs/specs/man/jconsole.html
>   HELP_MENU_ABOUT_TITLE=\u5173\u4E8E JConsole(&A)
>   HELP_MENU_USER_GUIDE_TITLE=\u8054\u673A\u7528\u6237\u6307\u5357(&U)
>   HELP_MENU_TITLE=\u5E2E\u52A9(&H)


From cjplummer at openjdk.java.net  Mon Mar  8 19:54:06 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 8 Mar 2021 19:54:06 GMT
Subject: RFR: 8263140: Japanese chars garble in console window in HSDB [v2]
In-Reply-To: <9EJHm1SQNQHDjeMqJxdVUvtFf2zSwq37Ia2whGLH25Y=.2d17b78e-65ff-42c9-9a11-28dfe4480be0@github.com>
References: <KYApMyFcX3_HUOUotqdR3gw1BALvA7oEqjfFZLecFjw=.3b5a6b82-0cd5-404e-af9f-ceb65ebf14f5@github.com>
 <aGKpXx_W1YuGiZbvTfe1Kh-wAwiaBtYgZ0HGdzpefVk=.f0b759b2-5bf1-4a73-8bdc-3d9cdc2ec288@github.com>
 <9EJHm1SQNQHDjeMqJxdVUvtFf2zSwq37Ia2whGLH25Y=.2d17b78e-65ff-42c9-9a11-28dfe4480be0@github.com>
Message-ID: <2pvVxM8qKzxIHUwSuSqcKTzBWZX-2aaozYMhkQPHT9Y=.3787b78f-40b0-4b21-b834-020d675a9172@github.com>

On Mon, 8 Mar 2021 00:23:16 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add GraphicsUtilities.getMonospacedFont()
>
> LGTM

There are two additional locations that use `lookupFont("Courier")`. Any reason not to replace them also? If you do replace them, then I think you can get rid of `lookupFont`.

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

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

From prr at openjdk.java.net  Mon Mar  8 20:03:10 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 8 Mar 2021 20:03:10 GMT
Subject: RFR: 8263140: Japanese chars garble in console window in HSDB [v2]
In-Reply-To: <2pvVxM8qKzxIHUwSuSqcKTzBWZX-2aaozYMhkQPHT9Y=.3787b78f-40b0-4b21-b834-020d675a9172@github.com>
References: <KYApMyFcX3_HUOUotqdR3gw1BALvA7oEqjfFZLecFjw=.3b5a6b82-0cd5-404e-af9f-ceb65ebf14f5@github.com>
 <aGKpXx_W1YuGiZbvTfe1Kh-wAwiaBtYgZ0HGdzpefVk=.f0b759b2-5bf1-4a73-8bdc-3d9cdc2ec288@github.com>
 <9EJHm1SQNQHDjeMqJxdVUvtFf2zSwq37Ia2whGLH25Y=.2d17b78e-65ff-42c9-9a11-28dfe4480be0@github.com>
 <2pvVxM8qKzxIHUwSuSqcKTzBWZX-2aaozYMhkQPHT9Y=.3787b78f-40b0-4b21-b834-020d675a9172@github.com>
Message-ID: <gfQeXVXrOXI1QLFN1Y1w8xIOYl-nLRFim9SO24jVXiI=.679a1103-b18b-4d83-989e-46942449b8bb@github.com>

On Mon, 8 Mar 2021 19:51:40 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> There are two additional locations that use `lookupFont("Courier")`. Any reason not to replace them also? If you do replace them, then I think you can get rid of `lookupFont`.

I think you really, really should get rid that ! Courier is a Postscript font that you will be hard pressed to find on modern systems. On Windows we might still have the "special case" code that remaps it to Courier New. Linux probably doesn't have it because it is a proprietary name which is why JDK used it only in 1.0 and stopped in 1.1 some 25 (!) years ago. And using a logical font you will get much better code point support

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

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

From cjplummer at openjdk.java.net  Mon Mar  8 20:24:12 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 8 Mar 2021 20:24:12 GMT
Subject: RFR: 8263140: Japanese chars garble in console window in HSDB [v2]
In-Reply-To: <gfQeXVXrOXI1QLFN1Y1w8xIOYl-nLRFim9SO24jVXiI=.679a1103-b18b-4d83-989e-46942449b8bb@github.com>
References: <KYApMyFcX3_HUOUotqdR3gw1BALvA7oEqjfFZLecFjw=.3b5a6b82-0cd5-404e-af9f-ceb65ebf14f5@github.com>
 <aGKpXx_W1YuGiZbvTfe1Kh-wAwiaBtYgZ0HGdzpefVk=.f0b759b2-5bf1-4a73-8bdc-3d9cdc2ec288@github.com>
 <9EJHm1SQNQHDjeMqJxdVUvtFf2zSwq37Ia2whGLH25Y=.2d17b78e-65ff-42c9-9a11-28dfe4480be0@github.com>
 <2pvVxM8qKzxIHUwSuSqcKTzBWZX-2aaozYMhkQPHT9Y=.3787b78f-40b0-4b21-b834-020d675a9172@github.com>
 <gfQeXVXrOXI1QLFN1Y1w8xIOYl-nLRFim9SO24jVXiI=.679a1103-b18b-4d83-989e-46942449b8bb@github.com>
Message-ID: <N8BiHxzLfroyEXpcV-KppOvaHEBZ_vveH6SFnUrUTCQ=.8a2c5b8f-aab8-4fef-96e7-dc07e33d4a5d@github.com>

On Mon, 8 Mar 2021 20:00:26 GMT, Phil Race <prr at openjdk.org> wrote:

>> There are two additional locations that use `lookupFont("Courier")`. Any reason not to replace them also? If you do replace them, then I think you can get rid of `lookupFont`.
>
>> There are two additional locations that use `lookupFont("Courier")`. Any reason not to replace them also? If you do replace them, then I think you can get rid of `lookupFont`.
> 
> I think you really, really should get rid that ! Courier is a Postscript font that you will be hard pressed to find on modern systems. On Windows we might still have the "special case" code that remaps it to Courier New. Linux probably doesn't have it because it is a proprietary name which is why JDK used it only in 1.0 and stopped in 1.1 some 25 (!) years ago. And using a logical font you will get much better code point support
> 
> And if we don't have special logic then Courier will map to "Dialog" which is quite a different beast - and so probably not at all  what the coder wanted.

BTW, on linux this does slightly adjust the appearance of text in the console. Not saying it's better or worse, just different.

Before:
![image](https://user-images.githubusercontent.com/53915825/110376897-9acaae80-8008-11eb-9788-3603b60798eb.png)

After:
![image](https://user-images.githubusercontent.com/53915825/110377000-b8981380-8008-11eb-9e3b-700506b11a18.png)

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

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

From cjplummer at openjdk.java.net  Mon Mar  8 23:52:09 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 8 Mar 2021 23:52:09 GMT
Subject: RFR: JDK-8261095: Add test for clhsdb "symbol" command
In-Reply-To: <vvBz34jYNl1w-989imPpF7K5U-3GYAzTTXGLqV2-2BU=.71fc7da5-36a3-48ba-ba2e-2100f90d1941@github.com>
References: <vvBz34jYNl1w-989imPpF7K5U-3GYAzTTXGLqV2-2BU=.71fc7da5-36a3-48ba-ba2e-2100f90d1941@github.com>
Message-ID: <gx76U715trdpqSzVuSKXZFO3Fy2-UyzHtCmUX4kimq0=.17d276ec-007a-4ac2-9b1e-ca6366bca892@github.com>

On Sun, 7 Mar 2021 10:43:34 GMT, Vipin Sharma <vsharma at openjdk.org> wrote:

> JDK-8261095: Add test for clhsdb "symbol" command

Overall it looks good. I have some suggestions for improved comments and formatting, and also please use the line.separator property.

test/hotspot/jtreg/serviceability/sa/ClhsdbSymbol.java line 54:

> 52:             System.out.println("Started LingeredApp with pid " + theApp.getPid());
> 53: 
> 54:             //Use command "class java.lang.Thread" to get the address of the InstanceKlass for java.lang.Thread

Put a space after the `//`. Same goes for all the comments below.

test/hotspot/jtreg/serviceability/sa/ClhsdbSymbol.java line 85:

> 83: 
> 84:             //extract address comes along with Symbol instance, following is corresponding sample output line
> 85:             //Symbol* Klass::_name: Symbol @ 0x0000000800471120

// The inspect command output will have one line of output that looks like the following.
//   Symbol* Klass::_name: Symbol @ 0x0000000800471120
// Extract the Symbol address from it.

test/hotspot/jtreg/serviceability/sa/ClhsdbSymbol.java line 97:

> 95:             }
> 96: 
> 97:             //Running "symbol" command on the Symbol instance address extracted in previous step

// Run "symbol" command on the Symbol instance address extracted in previous step.
// It should produce the symbol for java/lang/Thread.

test/hotspot/jtreg/serviceability/sa/ClhsdbSymbol.java line 103:

> 101:             expStrMap.put(cmdStr, List.of("#java/lang/Thread"));
> 102:             test.run(theApp.getPid(), cmds, expStrMap, null);
> 103: 

No need for newline here.

test/hotspot/jtreg/serviceability/sa/ClhsdbSymbol.java line 63:

> 61:             String[] parts = classOutput.split("\n");
> 62: 
> 63:             //extract thread address from the output line similar to "java/lang/Thread @0x000000080001d940"

I'd prefer:
// Extract the thread InstanceKlass address from the output, which looks similar to the following:
//   java/lang/Thread @0x000000080001d940

test/hotspot/jtreg/serviceability/sa/ClhsdbSymbol.java line 61:

> 59:             String classOutput = test.run(theApp.getPid(), cmds, expStrMap, null);
> 60:             String threadAddress = null;
> 61:             String[] parts = classOutput.split("\n");

I think you should be using the line.separator properly instead of "\n".
`            String linesep = System.getProperty("line.separator");`

test/hotspot/jtreg/serviceability/sa/ClhsdbSymbol.java line 82:

> 80:             String inspectOutput = test.run(theApp.getPid(), cmds, expStrMap, null);
> 81:             String symbolAddress = null;
> 82:             parts = inspectOutput.split("\n");

And here also use line.separator.

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

Changes requested by cjplummer (Reviewer).

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

From ysuenaga at openjdk.java.net  Tue Mar  9 00:54:25 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 9 Mar 2021 00:54:25 GMT
Subject: RFR: 8263140: Japanese chars garble in console window in HSDB [v3]
In-Reply-To: <KYApMyFcX3_HUOUotqdR3gw1BALvA7oEqjfFZLecFjw=.3b5a6b82-0cd5-404e-af9f-ceb65ebf14f5@github.com>
References: <KYApMyFcX3_HUOUotqdR3gw1BALvA7oEqjfFZLecFjw=.3b5a6b82-0cd5-404e-af9f-ceb65ebf14f5@github.com>
Message-ID: <LeCT7kosfVYkwlsONMdmt1Re3tEUKoJB38TXlkdtY7o=.1d4442f8-938f-4fcc-8d61-94092d1de334@github.com>

> We can command line debugger via "Windows" -> "Console" menu on HSDB. If the command shows error message in localized string (e.g. Japanese), it might garble as following:
> 
> ![garbled](https://user-images.githubusercontent.com/7421132/110232635-39e89b00-7f62-11eb-95c9-1a5238072814.png)
> 
> Command line debugger and Debugger Console (WinDbg on Windows) will use Courier font on their console, but it does not show Japanese chars. I guess it would happen on CJK chars because monospaced font for Chinese, Japanese, Korean are different from Courier.
> 
> After this change on Windows which set to Japanese locale, it uses MS Gothic and we can see localized message as following:
> 
> ![fixed](https://user-images.githubusercontent.com/7421132/110232699-a4014000-7f62-11eb-9185-6eff39394541.png)

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Get rid of using Courier font

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2862/files
  - new: https://git.openjdk.java.net/jdk/pull/2862/files/c0a5844a..ef9be0d7

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

  Stats: 21 lines in 3 files changed: 0 ins; 17 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2862.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2862/head:pull/2862

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

From ysuenaga at openjdk.java.net  Tue Mar  9 00:58:07 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 9 Mar 2021 00:58:07 GMT
Subject: RFR: 8263140: Japanese chars garble in console window in HSDB [v2]
In-Reply-To: <N8BiHxzLfroyEXpcV-KppOvaHEBZ_vveH6SFnUrUTCQ=.8a2c5b8f-aab8-4fef-96e7-dc07e33d4a5d@github.com>
References: <KYApMyFcX3_HUOUotqdR3gw1BALvA7oEqjfFZLecFjw=.3b5a6b82-0cd5-404e-af9f-ceb65ebf14f5@github.com>
 <aGKpXx_W1YuGiZbvTfe1Kh-wAwiaBtYgZ0HGdzpefVk=.f0b759b2-5bf1-4a73-8bdc-3d9cdc2ec288@github.com>
 <9EJHm1SQNQHDjeMqJxdVUvtFf2zSwq37Ia2whGLH25Y=.2d17b78e-65ff-42c9-9a11-28dfe4480be0@github.com>
 <2pvVxM8qKzxIHUwSuSqcKTzBWZX-2aaozYMhkQPHT9Y=.3787b78f-40b0-4b21-b834-020d675a9172@github.com>
 <gfQeXVXrOXI1QLFN1Y1w8xIOYl-nLRFim9SO24jVXiI=.679a1103-b18b-4d83-989e-46942449b8bb@github.com>
 <N8BiHxzLfroyEXpcV-KppOvaHEBZ_vveH6SFnUrUTCQ=.8a2c5b8f-aab8-4fef-96e7-dc07e33d4a5d@github.com>
Message-ID: <U-dbO5cnM1gTC7M2ZYzfYknBBhWDUNovdDdTE-9NI4U=.be040287-fc96-4adf-b9ad-ef926a7ee7a7@github.com>

On Mon, 8 Mar 2021 20:21:06 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>>> There are two additional locations that use `lookupFont("Courier")`. Any reason not to replace them also? If you do replace them, then I think you can get rid of `lookupFont`.
>> 
>> I think you really, really should get rid that ! Courier is a Postscript font that you will be hard pressed to find on modern systems. On Windows we might still have the "special case" code that remaps it to Courier New. Linux probably doesn't have it because it is a proprietary name which is why JDK used it only in 1.0 and stopped in 1.1 some 25 (!) years ago. And using a logical font you will get much better code point support
>> 
>> And if we don't have special logic then Courier will map to "Dialog" which is quite a different beast - and so probably not at all  what the coder wanted.
>
> BTW, on linux this does slightly adjust the appearance of text in the console. Not saying it's better or worse, just different.
> 
> Before:
> ![image](https://user-images.githubusercontent.com/53915825/110376897-9acaae80-8008-11eb-9788-3603b60798eb.png)
> 
> After:
> ![image](https://user-images.githubusercontent.com/53915825/110377000-b8981380-8008-11eb-9e3b-700506b11a18.png)

Thank you for the comments!

>  Any reason not to replace them also?

AnnotateMemoryPanel and MemoryPanel will not be non-ascii chars because they will show the address and kind of memory, so I didn't change them.
But I understood that we should not use Courier font, so I pushed new commit to get rid of it. Could you review again?

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

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

From amenkov at openjdk.java.net  Tue Mar  9 01:36:21 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 9 Mar 2021 01:36:21 GMT
Subject: RFR: 8262001:
 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java failed with
 "RuntimeException: Current Peak = 14 Expected to be == previous peak = 7 + 8"
Message-ID: <TZBFsiqKOxxbp-tN07-glyx947_eN6jTUEJlFWZcpik=.043c257d-d7ec-4df2-8504-1914e55e3975@github.com>

The fix updates ResetPeakThreadCount.java test - increases number of threads, but relaxes conditions so start/termination of system threads don't cause failures.
Additional changes:
- store threads in a list instead of array (we need only to start/terminate some number of threads, so linked list works better);
- flags for thread termination are moved to thread class;
- store values from ThreadMXBean.getPeakThreadCount() and getThreadCount() in int instead of long (the methods return int values)

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

Commit messages:
 - Update ResetPeakThreadCount.java

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

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

From ysuenaga at openjdk.java.net  Tue Mar  9 02:19:07 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 9 Mar 2021 02:19:07 GMT
Subject: RFR: JDK-8261095: Add test for clhsdb "symbol" command
In-Reply-To: <gx76U715trdpqSzVuSKXZFO3Fy2-UyzHtCmUX4kimq0=.17d276ec-007a-4ac2-9b1e-ca6366bca892@github.com>
References: <vvBz34jYNl1w-989imPpF7K5U-3GYAzTTXGLqV2-2BU=.71fc7da5-36a3-48ba-ba2e-2100f90d1941@github.com>
 <gx76U715trdpqSzVuSKXZFO3Fy2-UyzHtCmUX4kimq0=.17d276ec-007a-4ac2-9b1e-ca6366bca892@github.com>
Message-ID: <FAQJtlQU7hoP14yGE7zxfogG5ixUaCznxdG6e8Lhzj4=.fa43832a-67a0-4903-b683-b6c7e6e03b94@github.com>

On Mon, 8 Mar 2021 23:47:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> JDK-8261095: Add test for clhsdb "symbol" command
>
> test/hotspot/jtreg/serviceability/sa/ClhsdbSymbol.java line 61:
> 
>> 59:             String classOutput = test.run(theApp.getPid(), cmds, expStrMap, null);
>> 60:             String threadAddress = null;
>> 61:             String[] parts = classOutput.split("\n");
> 
> I think you should be using the line.separator properly instead of "\n".
> `            String linesep = System.getProperty("line.separator");`

It might be more simple if you use [String::lines](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/String.html#lines()) and stream API.

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

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

From cjplummer at openjdk.java.net  Tue Mar  9 02:39:07 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 9 Mar 2021 02:39:07 GMT
Subject: RFR: JDK-8261095: Add test for clhsdb "symbol" command
In-Reply-To: <FAQJtlQU7hoP14yGE7zxfogG5ixUaCznxdG6e8Lhzj4=.fa43832a-67a0-4903-b683-b6c7e6e03b94@github.com>
References: <vvBz34jYNl1w-989imPpF7K5U-3GYAzTTXGLqV2-2BU=.71fc7da5-36a3-48ba-ba2e-2100f90d1941@github.com>
 <gx76U715trdpqSzVuSKXZFO3Fy2-UyzHtCmUX4kimq0=.17d276ec-007a-4ac2-9b1e-ca6366bca892@github.com>
 <FAQJtlQU7hoP14yGE7zxfogG5ixUaCznxdG6e8Lhzj4=.fa43832a-67a0-4903-b683-b6c7e6e03b94@github.com>
Message-ID: <6-yPlOU7pzIGQ-qEj7EbNYaT3xhXJ_MTz86yZ_RbVd0=.83e9f616-7671-4799-931f-5da9fbd6ed60@github.com>

On Tue, 9 Mar 2021 02:16:30 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/sa/ClhsdbSymbol.java line 61:
>> 
>>> 59:             String classOutput = test.run(theApp.getPid(), cmds, expStrMap, null);
>>> 60:             String threadAddress = null;
>>> 61:             String[] parts = classOutput.split("\n");
>> 
>> I think you should be using the line.separator properly instead of "\n".
>> `            String linesep = System.getProperty("line.separator");`
>
> It might be more simple if you use [String::lines](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/String.html#lines()) and stream API.

Yes. Coincidentally I was just having an internal chat about `split(linesep)`, and `String.lines()` was mentioned. We have a lot of existing code that uses `split(linesep)` because `String.lines()` has only been around since JDK 11, and even some newer test code we have uses `split(linsep)` because it was copied from older tests.

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

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

From cjplummer at openjdk.java.net  Tue Mar  9 04:57:14 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 9 Mar 2021 04:57:14 GMT
Subject: RFR: 8263055: hsdb Command Line Debugger does not properly direct
 output for some commands
Message-ID: <pGwJVLHvj0BILLgV5TFOZoqdhx1JXVVda0fNVS4GZg4=.4f79539f-ee86-4b05-a1b3-bcdeddfaf32a@github.com>

I ran the hsdb Command Line Debugger (Windows -> Console menu item) and tried the class and classes commands, and neither appeared to produce any output. Other commands seemed to work as expected. I then went back to the terminal window I used to launch hsdb, and notice all the output from class and classes commands went there instead. The reason is because these commands are using System.out.println instead of out.println. "out" is a PrintStream field of the CommandProcessor instance, and should be used for all output other than error output, which can use "err".

We have no test for this, but I did run the hsdb GUI, brought up the Command Line Debugger, and confirmed that `class` and `classes` now properly show the output there. We do have clhsdb tests that also exercise this CommandProcessor code, but clhsdb directs all the output to System.out, so `out.println` and `System.out.println` end up being the same, thus the issue was not noticed.

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

Commit messages:
 - Use out.println instead of System.out.println so output ends up in the right place when the two are not the same.

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

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

From cjplummer at openjdk.java.net  Tue Mar  9 05:01:08 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 9 Mar 2021 05:01:08 GMT
Subject: RFR: 8243455: Many SA tests can fail due to trying to get the
 stack trace of an active method
In-Reply-To: <vk55a1YRzNRvFtjHmu5n0Ag_EPLxp0w4cRsZ7oDa54s=.695f6000-48f9-43c7-9150-193c895ab5a5@github.com>
References: <vjDRMVH6jMQsafl_UZTsf0Fglcx89foITgIg4Zhmawo=.f98f3f01-53d3-4613-8c54-67b9f2d34215@github.com>
 <EPr5_a4ucrPIqZwbPFfQFXnBfCVyQJ5-JjIA6ckogQY=.e021c282-9479-4aa6-9f6e-4badc1ae9221@github.com>
 <vk55a1YRzNRvFtjHmu5n0Ag_EPLxp0w4cRsZ7oDa54s=.695f6000-48f9-43c7-9150-193c895ab5a5@github.com>
Message-ID: <8oYrNmyKRUN6UEOAUtE91ApphlvUuLSVoNsXVCMAkUE=.6c5e9841-4338-4cd2-b209-bf76df4f8d17@github.com>

On Wed, 3 Mar 2021 22:37:32 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Marked as reviewed by lmesnik (Committer).
>
>> Doesn't jstack force all threads to be walkable via a safepoint or
>> handshake?
> 
> Nope. If it did it couldn't debug core files or a hung process. That's why SA has so much code to safe guard against walking off the deep end when doing things like stack walking and heap scanning.
> 
> BTW, you might be thinking of the Attach API version of `jstack`, which does safepoint. These tests all involve the SA version of `jstack`.

Ping! I could use one more reviewer. Thanks!

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

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

From cjplummer at openjdk.java.net  Tue Mar  9 05:02:10 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 9 Mar 2021 05:02:10 GMT
Subject: RFR: 8262271: SA: Add new stress test that tests getting the
 stack trace of an active thread
In-Reply-To: <_K-vQe2ii1xQ6eUI1tlrMr1Jzln35Enmb_wO_XIFc4w=.9e23582a-2fcf-4044-bd97-d6c653b200d3@github.com>
References: <59yxshwLvp5MVCYf2F2THU0T-SJjWbQfQTRLpJ3o2K4=.0e2e73cb-71dd-41b1-a86c-3460631c544c@github.com>
 <_K-vQe2ii1xQ6eUI1tlrMr1Jzln35Enmb_wO_XIFc4w=.9e23582a-2fcf-4044-bd97-d6c653b200d3@github.com>
Message-ID: <7mqSxtBy0DoRh6O5Owhc-bHxVv3f254Vetqv9HEiKO0=.2b7efb5c-26bb-45be-bbc3-f7bb4971d276@github.com>

On Thu, 25 Feb 2021 07:00:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This a new test that runs jstack on a process that is busy doing things. It runs jstack 4 times as the process is starting up.
>
>> Sorry but I don't see how this ensures it runs jstack as the jshell is
>> starting up, the startup could be complete before even one jstack gets
>> issued.
> 
> My observation is that at least the main thread has a different stack trace on each iteration. Also, each iteration takes progressively longer as jshell starts up. Although I don't fully understand the reason why, I think it's related to [JDK-8262098](https://bugs.openjdk.java.net/browse/JDK-8262098). Possibly the larger the program gets, the more SA needs to page in, even though you would think jstack would not need to touch that many pages. In any case, this is an indication that the program is changing its state.

Ping! Still need 2 reviewers. Thanks!

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

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

From vsharma at openjdk.java.net  Tue Mar  9 05:34:23 2021
From: vsharma at openjdk.java.net (Vipin Sharma)
Date: Tue, 9 Mar 2021 05:34:23 GMT
Subject: RFR: JDK-8261095: Add test for clhsdb "symbol" command [v2]
In-Reply-To: <vvBz34jYNl1w-989imPpF7K5U-3GYAzTTXGLqV2-2BU=.71fc7da5-36a3-48ba-ba2e-2100f90d1941@github.com>
References: <vvBz34jYNl1w-989imPpF7K5U-3GYAzTTXGLqV2-2BU=.71fc7da5-36a3-48ba-ba2e-2100f90d1941@github.com>
Message-ID: <OwyxxIvlK5rYfKbfqqxxcixKkmkd2lefA7KSLzDHJaw=.1d21c211-2b82-485e-9d54-7af692693a53@github.com>

> JDK-8261095: Add test for clhsdb "symbol" command

Vipin Sharma has updated the pull request incrementally with one additional commit since the last revision:

  Updated comments as per review and started using String.lines

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2863/files
  - new: https://git.openjdk.java.net/jdk/pull/2863/files/2ee7bd78..9d914d35

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

  Stats: 26 lines in 1 file changed: 1 ins; 7 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2863.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2863/head:pull/2863

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

From ysuenaga at openjdk.java.net  Tue Mar  9 05:35:08 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 9 Mar 2021 05:35:08 GMT
Subject: RFR: 8262271: SA: Add new stress test that tests getting the
 stack trace of an active thread
In-Reply-To: <59yxshwLvp5MVCYf2F2THU0T-SJjWbQfQTRLpJ3o2K4=.0e2e73cb-71dd-41b1-a86c-3460631c544c@github.com>
References: <59yxshwLvp5MVCYf2F2THU0T-SJjWbQfQTRLpJ3o2K4=.0e2e73cb-71dd-41b1-a86c-3460631c544c@github.com>
Message-ID: <46kh9dbevecJe7oOYR0SOvSi9MKB8cZ_d_PC_AS8ksU=.98e8b9aa-6137-4d00-bc42-89c9811e257d@github.com>

On Thu, 25 Feb 2021 03:54:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This a new test that runs jstack on a process that is busy doing things. It runs jstack 4 times as the process is starting up.

test/jdk/sun/tools/jhsdb/JStackStressTest.java line 91:

> 89:             } else {
> 90:                 System.out.println("Jshell not alive");
> 91:             }

Shouldn't we use `Process::waitFor` at this point to ensure the jshell is terminated? This test might not have enough time to shutdown since issuing `/exit`.
`destroy()` should be called when timeout is happened at `waitFor()`.

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

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

From ysuenaga at openjdk.java.net  Tue Mar  9 05:45:07 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 9 Mar 2021 05:45:07 GMT
Subject: RFR: 8243455: Many SA tests can fail due to trying to get the
 stack trace of an active method
In-Reply-To: <vjDRMVH6jMQsafl_UZTsf0Fglcx89foITgIg4Zhmawo=.f98f3f01-53d3-4613-8c54-67b9f2d34215@github.com>
References: <vjDRMVH6jMQsafl_UZTsf0Fglcx89foITgIg4Zhmawo=.f98f3f01-53d3-4613-8c54-67b9f2d34215@github.com>
Message-ID: <7XhX8JSGPd-dybaSBxW26qO4eLS30aa9bbvP1PkgOCQ=.d31304ac-c988-41a5-bea7-e848ebc2d37e@github.com>

On Tue, 23 Feb 2021 23:34:31 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Many tests run `LingeredApp`, get its stack with `jstack`, and then look for `LingeredApp.main` in the output, which should appear in the stack trace of the main thread. Usually this works fine since the main thread is in a loop, and usually blocked in `Thread.sleep()`. However, during the short period of time it wakes up from sleep, the thread's stack might not be walk-able, in which case the `LingeredApp.main` frame will not appear, and the tests looking for it will fail.
> 
> The fix is to introduce a new thread called `SteadyStateThread` that has a method called `steadyState()` that blocks indefinitely trying to synchronize on a locked object. All code that used to look for `LingeredApp.main` in the output now instead looks for `LingeredApp.steadyState`, which should always be there. I'm open to suggestions for a better name than "SteadyState" if you have one.
> 
> There are a few special cases with the tests that were modified that are described below:
> 
> Regarding the removal of `LingeredAppWithTrivialMain.java`, it was originally added to fix [JDK-8229118](https://bugs.openjdk.java.net/browse/JDK-8229118), which was an issue with the `ClhsdbFindPC` test failing on aarch64 when doing the `-Xcomp` run. It expected `LingeredApp.main()` to be compiled in that case, and for the PC of the frame to be in an `NMethod`. However, on aarch64 an uncommon-trap was causing it to be de-optimized, so the PC was in the interpreter instead, causing the test to fail. The fix was to instead rely on finding a trivial `LingeredAppWithTrivialMain.main()` frame in the stack trace since it would always be compiled. With the changes to instead have (and rely on) the `SteadyStateThread` and the presence of `LingeredApp.steadyState()`, the need for `LingeredAppWithTrivialMain` goes away. `LingeredApp.steadyState()` will always be compiled, even on aarch64.
> 
> Regarding `DebugdConnectTest.java`, it is listed in the CR as an affected test but no specified fix has been provided.
>  None is needed. The issue was that it looked for `LingeredApp` in the jstack output, and it used to be the only place it would find it was in the main thread's stack trace, which sometimes could not be retrieved. Now it can also be found in the `SteadyStateThread`'s stack trace, which can always be retrieved.
> 
> Regarding `HeapDumpTest.java`, it used to check for `LingeredAppWithExtendedChars.main` and now it checks for `LingeredApp.steadyState`. It still is run with `LingeredAppWithExtendedChars`. The only thing special about that class is that it contains an extended unicode character used to reproduce [JDK-8028623](https://bugs.openjdk.java.net/browse/JDK-8028623), so it will still do that, even though it now checks for `LingeredApp.steadyState`.

test/lib/jdk/test/lib/apps/LingeredApp.java line 531:

> 529:             // although this probably is not necessary to guarantee that the
> 530:             // stack trace is readable.
> 531:             Thread.sleep(100);

Can we wait to change the state of `steadyStateThread` to `BLOCKED`? It is more robustness than `Thread.sleep(100)`.

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

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

From ysuenaga at openjdk.java.net  Tue Mar  9 05:54:08 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 9 Mar 2021 05:54:08 GMT
Subject: RFR: JDK-8261095: Add test for clhsdb "symbol" command [v2]
In-Reply-To: <OwyxxIvlK5rYfKbfqqxxcixKkmkd2lefA7KSLzDHJaw=.1d21c211-2b82-485e-9d54-7af692693a53@github.com>
References: <vvBz34jYNl1w-989imPpF7K5U-3GYAzTTXGLqV2-2BU=.71fc7da5-36a3-48ba-ba2e-2100f90d1941@github.com>
 <OwyxxIvlK5rYfKbfqqxxcixKkmkd2lefA7KSLzDHJaw=.1d21c211-2b82-485e-9d54-7af692693a53@github.com>
Message-ID: <XSOyg6Ivjsm7SYGmS7iWDpQgK3ftjcY4jVBQjN5mv5Q=.67f81083-b0de-4529-99fe-41453f80958c@github.com>

On Tue, 9 Mar 2021 05:34:23 GMT, Vipin Sharma <vsharma at openjdk.org> wrote:

>> JDK-8261095: Add test for clhsdb "symbol" command
>
> Vipin Sharma has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated comments as per review and started using String.lines

test/hotspot/jtreg/serviceability/sa/ClhsdbSymbol.java line 67:

> 65:                                                       .findFirst()
> 66:                                                       .map(addresses -> addresses[1])
> 67:                                                       .orElse(null);

It should just call `get()` because `NoSuchElementException` would be called when we cannot find out Thread class from stdout.
If you want to throw `RuntimeException` like next step, you should use `orElseThrow()`.

test/hotspot/jtreg/serviceability/sa/ClhsdbSymbol.java line 86:

> 84:                                                         .map(part -> part.split("@ "))
> 85:                                                         .findFirst().map(symbolParts -> symbolParts[1])
> 86:                                                         .orElse(null);

Same comment in above.

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

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

From cjplummer at openjdk.java.net  Tue Mar  9 06:09:06 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 9 Mar 2021 06:09:06 GMT
Subject: RFR: 8243455: Many SA tests can fail due to trying to get the
 stack trace of an active method
In-Reply-To: <7XhX8JSGPd-dybaSBxW26qO4eLS30aa9bbvP1PkgOCQ=.d31304ac-c988-41a5-bea7-e848ebc2d37e@github.com>
References: <vjDRMVH6jMQsafl_UZTsf0Fglcx89foITgIg4Zhmawo=.f98f3f01-53d3-4613-8c54-67b9f2d34215@github.com>
 <7XhX8JSGPd-dybaSBxW26qO4eLS30aa9bbvP1PkgOCQ=.d31304ac-c988-41a5-bea7-e848ebc2d37e@github.com>
Message-ID: <7QM-0egfnzDC-3LQiQ3Vg4R8nAiwseR010VhRSZqpds=.0ee3a712-472a-4fb4-bbef-137d3149bf58@github.com>

On Tue, 9 Mar 2021 05:42:05 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Many tests run `LingeredApp`, get its stack with `jstack`, and then look for `LingeredApp.main` in the output, which should appear in the stack trace of the main thread. Usually this works fine since the main thread is in a loop, and usually blocked in `Thread.sleep()`. However, during the short period of time it wakes up from sleep, the thread's stack might not be walk-able, in which case the `LingeredApp.main` frame will not appear, and the tests looking for it will fail.
>> 
>> The fix is to introduce a new thread called `SteadyStateThread` that has a method called `steadyState()` that blocks indefinitely trying to synchronize on a locked object. All code that used to look for `LingeredApp.main` in the output now instead looks for `LingeredApp.steadyState`, which should always be there. I'm open to suggestions for a better name than "SteadyState" if you have one.
>> 
>> There are a few special cases with the tests that were modified that are described below:
>> 
>> Regarding the removal of `LingeredAppWithTrivialMain.java`, it was originally added to fix [JDK-8229118](https://bugs.openjdk.java.net/browse/JDK-8229118), which was an issue with the `ClhsdbFindPC` test failing on aarch64 when doing the `-Xcomp` run. It expected `LingeredApp.main()` to be compiled in that case, and for the PC of the frame to be in an `NMethod`. However, on aarch64 an uncommon-trap was causing it to be de-optimized, so the PC was in the interpreter instead, causing the test to fail. The fix was to instead rely on finding a trivial `LingeredAppWithTrivialMain.main()` frame in the stack trace since it would always be compiled. With the changes to instead have (and rely on) the `SteadyStateThread` and the presence of `LingeredApp.steadyState()`, the need for `LingeredAppWithTrivialMain` goes away. `LingeredApp.steadyState()` will always be compiled, even on aarch64.
>> 
>> Regarding `DebugdConnectTest.java`, it is listed in the CR as an affected test but no specified fix has been provided.
>>  None is needed. The issue was that it looked for `LingeredApp` in the jstack output, and it used to be the only place it would find it was in the main thread's stack trace, which sometimes could not be retrieved. Now it can also be found in the `SteadyStateThread`'s stack trace, which can always be retrieved.
>> 
>> Regarding `HeapDumpTest.java`, it used to check for `LingeredAppWithExtendedChars.main` and now it checks for `LingeredApp.steadyState`. It still is run with `LingeredAppWithExtendedChars`. The only thing special about that class is that it contains an extended unicode character used to reproduce [JDK-8028623](https://bugs.openjdk.java.net/browse/JDK-8028623), so it will still do that, even though it now checks for `LingeredApp.steadyState`.
>
> test/lib/jdk/test/lib/apps/LingeredApp.java line 531:
> 
>> 529:             // although this probably is not necessary to guarantee that the
>> 530:             // stack trace is readable.
>> 531:             Thread.sleep(100);
> 
> Can we wait to change the state of `steadyStateThread` to `BLOCKED`? It is more robustness than `Thread.sleep(100)`.

How do you do that?

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

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

From ysuenaga at openjdk.java.net  Tue Mar  9 06:15:11 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 9 Mar 2021 06:15:11 GMT
Subject: RFR: 8243455: Many SA tests can fail due to trying to get the
 stack trace of an active method
In-Reply-To: <7QM-0egfnzDC-3LQiQ3Vg4R8nAiwseR010VhRSZqpds=.0ee3a712-472a-4fb4-bbef-137d3149bf58@github.com>
References: <vjDRMVH6jMQsafl_UZTsf0Fglcx89foITgIg4Zhmawo=.f98f3f01-53d3-4613-8c54-67b9f2d34215@github.com>
 <7XhX8JSGPd-dybaSBxW26qO4eLS30aa9bbvP1PkgOCQ=.d31304ac-c988-41a5-bea7-e848ebc2d37e@github.com>
 <7QM-0egfnzDC-3LQiQ3Vg4R8nAiwseR010VhRSZqpds=.0ee3a712-472a-4fb4-bbef-137d3149bf58@github.com>
Message-ID: <26L6p0ytA2nd87VmulzMrJ_LABHrAxdSn5Llg50Nye4=.4e9b21df-2bc2-4e25-800e-3d08f28733d8@github.com>

On Tue, 9 Mar 2021 06:06:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> test/lib/jdk/test/lib/apps/LingeredApp.java line 531:
>> 
>>> 529:             // although this probably is not necessary to guarantee that the
>>> 530:             // stack trace is readable.
>>> 531:             Thread.sleep(100);
>> 
>> Can we wait to change the state of `steadyStateThread` to `BLOCKED`? It is more robustness than `Thread.sleep(100)`.
>
> How do you do that?

For example, can we write following code?

while (steadyStateThread.getState() != Thread.State.BLOCKED) {
    Thread.onSpinWait();
}

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

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

From cjplummer at openjdk.java.net  Tue Mar  9 06:24:07 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 9 Mar 2021 06:24:07 GMT
Subject: RFR: 8262271: SA: Add new stress test that tests getting the
 stack trace of an active thread
In-Reply-To: <46kh9dbevecJe7oOYR0SOvSi9MKB8cZ_d_PC_AS8ksU=.98e8b9aa-6137-4d00-bc42-89c9811e257d@github.com>
References: <59yxshwLvp5MVCYf2F2THU0T-SJjWbQfQTRLpJ3o2K4=.0e2e73cb-71dd-41b1-a86c-3460631c544c@github.com>
 <46kh9dbevecJe7oOYR0SOvSi9MKB8cZ_d_PC_AS8ksU=.98e8b9aa-6137-4d00-bc42-89c9811e257d@github.com>
Message-ID: <soYsewsJ1DczVQfZXuUhOiBuaBK_RZQSbgigMMvJs_o=.2fc6fbc1-a7ac-4c2b-a70b-13adfa7ff915@github.com>

On Tue, 9 Mar 2021 05:32:28 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> This a new test that runs jstack on a process that is busy doing things. It runs jstack 4 times as the process is starting up.
>
> test/jdk/sun/tools/jhsdb/JStackStressTest.java line 91:
> 
>> 89:             } else {
>> 90:                 System.out.println("Jshell not alive");
>> 91:             }
> 
> Shouldn't we use `Process::waitFor` at this point to ensure the jshell is terminated? This test might not have enough time to shutdown since issuing `/exit`.
> `destroy()` should be called when timeout is happened at `waitFor()`.

Yeah, I'll do that. Not sure why I didn't do it that way in the first place. I think I copied this from somewhere, but now I can't find where.

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

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

From cjplummer at openjdk.java.net  Tue Mar  9 06:31:05 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 9 Mar 2021 06:31:05 GMT
Subject: RFR: 8262271: SA: Add new stress test that tests getting the
 stack trace of an active thread
In-Reply-To: <soYsewsJ1DczVQfZXuUhOiBuaBK_RZQSbgigMMvJs_o=.2fc6fbc1-a7ac-4c2b-a70b-13adfa7ff915@github.com>
References: <59yxshwLvp5MVCYf2F2THU0T-SJjWbQfQTRLpJ3o2K4=.0e2e73cb-71dd-41b1-a86c-3460631c544c@github.com>
 <46kh9dbevecJe7oOYR0SOvSi9MKB8cZ_d_PC_AS8ksU=.98e8b9aa-6137-4d00-bc42-89c9811e257d@github.com>
 <soYsewsJ1DczVQfZXuUhOiBuaBK_RZQSbgigMMvJs_o=.2fc6fbc1-a7ac-4c2b-a70b-13adfa7ff915@github.com>
Message-ID: <9mYQLsG3nMriIJGQE2bz2OhRG7kBK5M4QHoUzmnOgn8=.29048f92-f889-403a-af59-2bab6a6bb372@github.com>

On Tue, 9 Mar 2021 06:21:22 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> test/jdk/sun/tools/jhsdb/JStackStressTest.java line 91:
>> 
>>> 89:             } else {
>>> 90:                 System.out.println("Jshell not alive");
>>> 91:             }
>> 
>> Shouldn't we use `Process::waitFor` at this point to ensure the jshell is terminated? This test might not have enough time to shutdown since issuing `/exit`.
>> `destroy()` should be called when timeout is happened at `waitFor()`.
>
> Yeah, I'll do that. Not sure why I didn't do it that way in the first place. I think I copied this from somewhere, but now I can't find where.

Ah, it was JShellHeapDumpTest.java, which does the same thing (it's in a different test directory, so my grep missed it). There really is no reason not to just forcibly kill it, since its job is done and we don't really need its output or a graceful exit. However, for some reason I partially decided to try to get it to exit gracefully by adding the /exit command, and then get the output. So I'll still add the waitfor.

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

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

From cjplummer at openjdk.java.net  Tue Mar  9 06:38:07 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 9 Mar 2021 06:38:07 GMT
Subject: RFR: 8243455: Many SA tests can fail due to trying to get the
 stack trace of an active method
In-Reply-To: <26L6p0ytA2nd87VmulzMrJ_LABHrAxdSn5Llg50Nye4=.4e9b21df-2bc2-4e25-800e-3d08f28733d8@github.com>
References: <vjDRMVH6jMQsafl_UZTsf0Fglcx89foITgIg4Zhmawo=.f98f3f01-53d3-4613-8c54-67b9f2d34215@github.com>
 <7XhX8JSGPd-dybaSBxW26qO4eLS30aa9bbvP1PkgOCQ=.d31304ac-c988-41a5-bea7-e848ebc2d37e@github.com>
 <7QM-0egfnzDC-3LQiQ3Vg4R8nAiwseR010VhRSZqpds=.0ee3a712-472a-4fb4-bbef-137d3149bf58@github.com>
 <26L6p0ytA2nd87VmulzMrJ_LABHrAxdSn5Llg50Nye4=.4e9b21df-2bc2-4e25-800e-3d08f28733d8@github.com>
Message-ID: <T6gavOaSn7Zivvb950lY5gQl6uwvvMM5ftA1YQUjWeM=.d7d20900-620e-4635-bef1-2dfa3b2cc89e@github.com>

On Tue, 9 Mar 2021 06:12:09 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> How do you do that?
>
> For example, can we write following code?
> 
> while (steadyStateThread.getState() != Thread.State.BLOCKED) {
>     Thread.onSpinWait();
> }

Ok, that's easy enough. What about the loop before it. Do you prefer 100ms sleeps or onSpinWait() for it also.

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

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

From ysuenaga at openjdk.java.net  Tue Mar  9 06:46:09 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 9 Mar 2021 06:46:09 GMT
Subject: RFR: 8243455: Many SA tests can fail due to trying to get the
 stack trace of an active method
In-Reply-To: <T6gavOaSn7Zivvb950lY5gQl6uwvvMM5ftA1YQUjWeM=.d7d20900-620e-4635-bef1-2dfa3b2cc89e@github.com>
References: <vjDRMVH6jMQsafl_UZTsf0Fglcx89foITgIg4Zhmawo=.f98f3f01-53d3-4613-8c54-67b9f2d34215@github.com>
 <7XhX8JSGPd-dybaSBxW26qO4eLS30aa9bbvP1PkgOCQ=.d31304ac-c988-41a5-bea7-e848ebc2d37e@github.com>
 <7QM-0egfnzDC-3LQiQ3Vg4R8nAiwseR010VhRSZqpds=.0ee3a712-472a-4fb4-bbef-137d3149bf58@github.com>
 <26L6p0ytA2nd87VmulzMrJ_LABHrAxdSn5Llg50Nye4=.4e9b21df-2bc2-4e25-800e-3d08f28733d8@github.com>
 <T6gavOaSn7Zivvb950lY5gQl6uwvvMM5ftA1YQUjWeM=.d7d20900-620e-4635-bef1-2dfa3b2cc89e@github.com>
Message-ID: <JyipCld3g5_qC4Tecp6lskU_x8v6Pao-A1BzQseNGUs=.84e18d6c-396b-4045-aee3-f674ea0c97b9@github.com>

On Tue, 9 Mar 2021 06:34:58 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> For example, can we write following code?
>> 
>> while (steadyStateThread.getState() != Thread.State.BLOCKED) {
>>     Thread.onSpinWait();
>> }
>
> Ok, that's easy enough. What about the loop before it. Do you prefer 100ms sleeps or onSpinWait() for it also.

I prefer `onSpinWait()` if anything because it expects short suspend, and we can expect CPU friendly code.

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

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

From ysuenaga at openjdk.java.net  Tue Mar  9 07:06:05 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 9 Mar 2021 07:06:05 GMT
Subject: RFR: 8243455: Many SA tests can fail due to trying to get the
 stack trace of an active method
In-Reply-To: <JyipCld3g5_qC4Tecp6lskU_x8v6Pao-A1BzQseNGUs=.84e18d6c-396b-4045-aee3-f674ea0c97b9@github.com>
References: <vjDRMVH6jMQsafl_UZTsf0Fglcx89foITgIg4Zhmawo=.f98f3f01-53d3-4613-8c54-67b9f2d34215@github.com>
 <7XhX8JSGPd-dybaSBxW26qO4eLS30aa9bbvP1PkgOCQ=.d31304ac-c988-41a5-bea7-e848ebc2d37e@github.com>
 <7QM-0egfnzDC-3LQiQ3Vg4R8nAiwseR010VhRSZqpds=.0ee3a712-472a-4fb4-bbef-137d3149bf58@github.com>
 <26L6p0ytA2nd87VmulzMrJ_LABHrAxdSn5Llg50Nye4=.4e9b21df-2bc2-4e25-800e-3d08f28733d8@github.com>
 <T6gavOaSn7Zivvb950lY5gQl6uwvvMM5ftA1YQUjWeM=.d7d20900-620e-4635-bef1-2dfa3b2cc89e@github.com>
 <JyipCld3g5_qC4Tecp6lskU_x8v6Pao-A1BzQseNGUs=.84e18d6c-396b-4045-aee3-f674ea0c97b9@github.com>
Message-ID: <nuquPfgl4sH2evQUYaDpYihBAF4RhSM5UjZo8wg7EOc=.c9c85915-226c-4584-b309-5f57765ed956@github.com>

On Tue, 9 Mar 2021 06:42:51 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Ok, that's easy enough. What about the loop before it. Do you prefer 100ms sleeps or onSpinWait() for it also.
>
> I prefer `onSpinWait()` if anything because it expects short suspend, and we can expect CPU friendly code.

As an option, we can remove `steadyStateReached` and rewrite the code as following:

        steadyStateThread.setName("SteadyStateThread");
        steadyStateThread.start();

        while (steadyStateThread.getState() != Thread.State.BLOCKED) {
            Thread.onSpinWait();
        }

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

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

From cjplummer at openjdk.java.net  Tue Mar  9 07:17:28 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 9 Mar 2021 07:17:28 GMT
Subject: RFR: 8262271: SA: Add new stress test that tests getting the
 stack trace of an active thread [v2]
In-Reply-To: <59yxshwLvp5MVCYf2F2THU0T-SJjWbQfQTRLpJ3o2K4=.0e2e73cb-71dd-41b1-a86c-3460631c544c@github.com>
References: <59yxshwLvp5MVCYf2F2THU0T-SJjWbQfQTRLpJ3o2K4=.0e2e73cb-71dd-41b1-a86c-3460631c544c@github.com>
Message-ID: <xmMUx-npHPS9Y5S19PhQ1qFCBECWZGSb_drcjicVRaw=.d6f9c5b7-ed5f-4af2-812b-e133d6c8d8a4@github.com>

> This a new test that runs jstack on a process that is busy doing things. It runs jstack 4 times as the process is starting up.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  Use waitFor() instead of destroyForcibly().

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2720/files
  - new: https://git.openjdk.java.net/jdk/pull/2720/files/e9bfe2be..6689e8ac

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

  Stats: 8 lines in 1 file changed: 1 ins; 4 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2720.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2720/head:pull/2720

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

From cjplummer at openjdk.java.net  Tue Mar  9 07:27:26 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 9 Mar 2021 07:27:26 GMT
Subject: RFR: 8243455: Many SA tests can fail due to trying to get the
 stack trace of an active method [v2]
In-Reply-To: <vjDRMVH6jMQsafl_UZTsf0Fglcx89foITgIg4Zhmawo=.f98f3f01-53d3-4613-8c54-67b9f2d34215@github.com>
References: <vjDRMVH6jMQsafl_UZTsf0Fglcx89foITgIg4Zhmawo=.f98f3f01-53d3-4613-8c54-67b9f2d34215@github.com>
Message-ID: <fGSNDp2jgJFSt-dctuX4IMYv9txYr3wrS2LwHC4rNWk=.b994fce9-37ff-46f9-8c29-ed47deda062e@github.com>

> Many tests run `LingeredApp`, get its stack with `jstack`, and then look for `LingeredApp.main` in the output, which should appear in the stack trace of the main thread. Usually this works fine since the main thread is in a loop, and usually blocked in `Thread.sleep()`. However, during the short period of time it wakes up from sleep, the thread's stack might not be walk-able, in which case the `LingeredApp.main` frame will not appear, and the tests looking for it will fail.
> 
> The fix is to introduce a new thread called `SteadyStateThread` that has a method called `steadyState()` that blocks indefinitely trying to synchronize on a locked object. All code that used to look for `LingeredApp.main` in the output now instead looks for `LingeredApp.steadyState`, which should always be there. I'm open to suggestions for a better name than "SteadyState" if you have one.
> 
> There are a few special cases with the tests that were modified that are described below:
> 
> Regarding the removal of `LingeredAppWithTrivialMain.java`, it was originally added to fix [JDK-8229118](https://bugs.openjdk.java.net/browse/JDK-8229118), which was an issue with the `ClhsdbFindPC` test failing on aarch64 when doing the `-Xcomp` run. It expected `LingeredApp.main()` to be compiled in that case, and for the PC of the frame to be in an `NMethod`. However, on aarch64 an uncommon-trap was causing it to be de-optimized, so the PC was in the interpreter instead, causing the test to fail. The fix was to instead rely on finding a trivial `LingeredAppWithTrivialMain.main()` frame in the stack trace since it would always be compiled. With the changes to instead have (and rely on) the `SteadyStateThread` and the presence of `LingeredApp.steadyState()`, the need for `LingeredAppWithTrivialMain` goes away. `LingeredApp.steadyState()` will always be compiled, even on aarch64.
> 
> Regarding `DebugdConnectTest.java`, it is listed in the CR as an affected test but no specified fix has been provided.
>  None is needed. The issue was that it looked for `LingeredApp` in the jstack output, and it used to be the only place it would find it was in the main thread's stack trace, which sometimes could not be retrieved. Now it can also be found in the `SteadyStateThread`'s stack trace, which can always be retrieved.
> 
> Regarding `HeapDumpTest.java`, it used to check for `LingeredAppWithExtendedChars.main` and now it checks for `LingeredApp.steadyState`. It still is run with `LingeredAppWithExtendedChars`. The only thing special about that class is that it contains an extended unicode character used to reproduce [JDK-8028623](https://bugs.openjdk.java.net/browse/JDK-8028623), so it will still do that, even though it now checks for `LingeredApp.steadyState`.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  Use onSpinWait() instead of sleep(), and check for BLOCKED thread state.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2700/files
  - new: https://git.openjdk.java.net/jdk/pull/2700/files/4ab24304..f2d964cb

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

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

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

From cjplummer at openjdk.java.net  Tue Mar  9 07:32:06 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 9 Mar 2021 07:32:06 GMT
Subject: RFR: 8243455: Many SA tests can fail due to trying to get the
 stack trace of an active method [v2]
In-Reply-To: <nuquPfgl4sH2evQUYaDpYihBAF4RhSM5UjZo8wg7EOc=.c9c85915-226c-4584-b309-5f57765ed956@github.com>
References: <vjDRMVH6jMQsafl_UZTsf0Fglcx89foITgIg4Zhmawo=.f98f3f01-53d3-4613-8c54-67b9f2d34215@github.com>
 <7XhX8JSGPd-dybaSBxW26qO4eLS30aa9bbvP1PkgOCQ=.d31304ac-c988-41a5-bea7-e848ebc2d37e@github.com>
 <7QM-0egfnzDC-3LQiQ3Vg4R8nAiwseR010VhRSZqpds=.0ee3a712-472a-4fb4-bbef-137d3149bf58@github.com>
 <26L6p0ytA2nd87VmulzMrJ_LABHrAxdSn5Llg50Nye4=.4e9b21df-2bc2-4e25-800e-3d08f28733d8@github.com>
 <T6gavOaSn7Zivvb950lY5gQl6uwvvMM5ftA1YQUjWeM=.d7d20900-620e-4635-bef1-2dfa3b2cc89e@github.com>
 <JyipCld3g5_qC4Tecp6lskU_x8v6Pao-A1BzQseNGUs=.84e18d6c-396b-4045-aee3-f674ea0c97b9@github.com>
 <nuquPfgl4sH2evQUYaDpYihBAF4RhSM5UjZo8wg7EOc=.c9c85915-226c-4584-b309-5f57765ed956@github.com>
Message-ID: <KJBruPQiG10JfYl__wupYc8gsAkCu4wSWuLwM2qErs0=.b2d1f3e0-d3d7-464f-a02f-f6178539b386@github.com>

On Tue, 9 Mar 2021 07:03:36 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I prefer `onSpinWait()` if anything because it expects short suspend, and we can expect CPU friendly code.
>
> As an option, we can remove `steadyStateReached` and rewrite the code as following:
> 
>         steadyStateThread.setName("SteadyStateThread");
>         steadyStateThread.start();
> 
>         while (steadyStateThread.getState() != Thread.State.BLOCKED) {
>             Thread.onSpinWait();
>         }

I thought of that, but was worried that during thread startup maybe there might be a spurious short lived period where the thread was BLOCKED. Probably not possible, but I didn't want to have to go about proving as much.

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

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

From dnsimon at openjdk.java.net  Tue Mar  9 09:58:12 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Tue, 9 Mar 2021 09:58:12 GMT
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code [v3]
In-Reply-To: <4vZKr9NSgnXKcRYkokO_dGUbP_vaXNR0wqvHDiPo36c=.7b24e8fb-32ed-4d22-8ac4-9d781b4190be@github.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
 <t3mKAu_gO1j2Aslw952xIm5DuiEWGAN1YBPZG2_5ckI=.90023947-cf48-4ffa-bb22-5f7db5887dfd@github.com>
 <4vZKr9NSgnXKcRYkokO_dGUbP_vaXNR0wqvHDiPo36c=.7b24e8fb-32ed-4d22-8ac4-9d781b4190be@github.com>
Message-ID: <5Z2tkhiP0idMlHF-uazCkNxK7gd1CzdnaRhOsNost74=.6a7e8c6c-df40-40ce-b38f-7484e875dbb9@github.com>

On Thu, 4 Mar 2021 23:37:27 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More pointer declaration style fixups
>
> src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java line 516:
> 
>> 514:     public final int objectMonitorCxq = getFieldOffset("ObjectMonitor::_cxq", Integer.class, "ObjectWaiter*", -1, jdk13Backport);
>> 515:     public final int objectMonitorEntryList = getFieldOffset("ObjectMonitor::_EntryList", Integer.class, "ObjectWaiter*", -1, jdk13Backport);
>> 516:     public final int objectMonitorSucc = getFieldOffset("ObjectMonitor::_succ", Integer.class, JDK < 17 ? "Thread*" : "JavaThread*", -1, jdk13Backport);
> 
> That makes my brain hurt...

That's the price of maintaining Graal to work across 10 (and counting...) JDK versions.
This change looks good to me. Thanks for the heads up @dholmes-ora - I'll port this change to Graal upstream.

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

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

From david.holmes at oracle.com  Tue Mar  9 10:05:28 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 9 Mar 2021 20:05:28 +1000
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code [v3]
In-Reply-To: <5Z2tkhiP0idMlHF-uazCkNxK7gd1CzdnaRhOsNost74=.6a7e8c6c-df40-40ce-b38f-7484e875dbb9@github.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
 <t3mKAu_gO1j2Aslw952xIm5DuiEWGAN1YBPZG2_5ckI=.90023947-cf48-4ffa-bb22-5f7db5887dfd@github.com>
 <4vZKr9NSgnXKcRYkokO_dGUbP_vaXNR0wqvHDiPo36c=.7b24e8fb-32ed-4d22-8ac4-9d781b4190be@github.com>
 <5Z2tkhiP0idMlHF-uazCkNxK7gd1CzdnaRhOsNost74=.6a7e8c6c-df40-40ce-b38f-7484e875dbb9@github.com>
Message-ID: <b05f925f-f840-f6a0-6896-9284415fb128@oracle.com>

On 9/03/2021 7:58 pm, Doug Simon wrote:
> On Thu, 4 Mar 2021 23:37:27 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:
> 
>>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>>>
>>>    More pointer declaration style fixups
>>
>> src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java line 516:
>>
>>> 514:     public final int objectMonitorCxq = getFieldOffset("ObjectMonitor::_cxq", Integer.class, "ObjectWaiter*", -1, jdk13Backport);
>>> 515:     public final int objectMonitorEntryList = getFieldOffset("ObjectMonitor::_EntryList", Integer.class, "ObjectWaiter*", -1, jdk13Backport);
>>> 516:     public final int objectMonitorSucc = getFieldOffset("ObjectMonitor::_succ", Integer.class, JDK < 17 ? "Thread*" : "JavaThread*", -1, jdk13Backport);
>>
>> That makes my brain hurt...
> 
> That's the price of maintaining Graal to work across 10 (and counting...) JDK versions.
> This change looks good to me. Thanks for the heads up @dholmes-ora - I'll port this change to Graal upstream.

Many thanks Doug!

David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/2802
> 

From dfuchs at openjdk.java.net  Tue Mar  9 10:27:06 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 9 Mar 2021 10:27:06 GMT
Subject: RFR: 8262001:
 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java failed with
 "RuntimeException: Current Peak = 14 Expected to be == previous peak = 7 + 8"
In-Reply-To: <TZBFsiqKOxxbp-tN07-glyx947_eN6jTUEJlFWZcpik=.043c257d-d7ec-4df2-8504-1914e55e3975@github.com>
References: <TZBFsiqKOxxbp-tN07-glyx947_eN6jTUEJlFWZcpik=.043c257d-d7ec-4df2-8504-1914e55e3975@github.com>
Message-ID: <EidWXliJloxTrsDmmYj7IrKvWrwbQCe9pIMZ3k4A6T8=.d8887895-5ed5-48cd-9417-1b411f8e9657@github.com>

On Tue, 9 Mar 2021 01:31:33 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates ResetPeakThreadCount.java test - increases number of threads, but relaxes conditions so start/termination of system threads don't cause failures.
> Additional changes:
> - store threads in a list instead of array (we need only to start/terminate some number of threads, so linked list works better);
> - flags for thread termination are moved to thread class;
> - store values from ThreadMXBean.getPeakThreadCount() and getThreadCount() in int instead of long (the methods return int values)

This looks like a good cleanup to me. Please wait for a review from someone from serviceability-dev before pushing.

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

Marked as reviewed by dfuchs (Reviewer).

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

From ysuenaga at openjdk.java.net  Tue Mar  9 10:46:07 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 9 Mar 2021 10:46:07 GMT
Subject: RFR: 8262271: SA: Add new stress test that tests getting the
 stack trace of an active thread [v2]
In-Reply-To: <xmMUx-npHPS9Y5S19PhQ1qFCBECWZGSb_drcjicVRaw=.d6f9c5b7-ed5f-4af2-812b-e133d6c8d8a4@github.com>
References: <59yxshwLvp5MVCYf2F2THU0T-SJjWbQfQTRLpJ3o2K4=.0e2e73cb-71dd-41b1-a86c-3460631c544c@github.com>
 <xmMUx-npHPS9Y5S19PhQ1qFCBECWZGSb_drcjicVRaw=.d6f9c5b7-ed5f-4af2-812b-e133d6c8d8a4@github.com>
Message-ID: <MIDs78Q1LCqUByiADokyaJ4WPUC_oU4095WU0IDKbVc=.174fb312-cac1-4762-af76-a8890a3c4da2@github.com>

On Tue, 9 Mar 2021 07:17:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This a new test that runs jstack on a process that is busy doing things. It runs jstack 4 times as the process is starting up.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use waitFor() instead of destroyForcibly().

Marked as reviewed by ysuenaga (Reviewer).

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

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

From ysuenaga at openjdk.java.net  Tue Mar  9 10:47:07 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 9 Mar 2021 10:47:07 GMT
Subject: RFR: 8243455: Many SA tests can fail due to trying to get the
 stack trace of an active method [v2]
In-Reply-To: <fGSNDp2jgJFSt-dctuX4IMYv9txYr3wrS2LwHC4rNWk=.b994fce9-37ff-46f9-8c29-ed47deda062e@github.com>
References: <vjDRMVH6jMQsafl_UZTsf0Fglcx89foITgIg4Zhmawo=.f98f3f01-53d3-4613-8c54-67b9f2d34215@github.com>
 <fGSNDp2jgJFSt-dctuX4IMYv9txYr3wrS2LwHC4rNWk=.b994fce9-37ff-46f9-8c29-ed47deda062e@github.com>
Message-ID: <hS9PJt11K6jDvrPn_1lZ-83J-fIUXKUvcsJ7Z19fksQ=.7206fdbc-8910-4ab2-93bb-aed8aa4c07f0@github.com>

On Tue, 9 Mar 2021 07:27:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Many tests run `LingeredApp`, get its stack with `jstack`, and then look for `LingeredApp.main` in the output, which should appear in the stack trace of the main thread. Usually this works fine since the main thread is in a loop, and usually blocked in `Thread.sleep()`. However, during the short period of time it wakes up from sleep, the thread's stack might not be walk-able, in which case the `LingeredApp.main` frame will not appear, and the tests looking for it will fail.
>> 
>> The fix is to introduce a new thread called `SteadyStateThread` that has a method called `steadyState()` that blocks indefinitely trying to synchronize on a locked object. All code that used to look for `LingeredApp.main` in the output now instead looks for `LingeredApp.steadyState`, which should always be there. I'm open to suggestions for a better name than "SteadyState" if you have one.
>> 
>> There are a few special cases with the tests that were modified that are described below:
>> 
>> Regarding the removal of `LingeredAppWithTrivialMain.java`, it was originally added to fix [JDK-8229118](https://bugs.openjdk.java.net/browse/JDK-8229118), which was an issue with the `ClhsdbFindPC` test failing on aarch64 when doing the `-Xcomp` run. It expected `LingeredApp.main()` to be compiled in that case, and for the PC of the frame to be in an `NMethod`. However, on aarch64 an uncommon-trap was causing it to be de-optimized, so the PC was in the interpreter instead, causing the test to fail. The fix was to instead rely on finding a trivial `LingeredAppWithTrivialMain.main()` frame in the stack trace since it would always be compiled. With the changes to instead have (and rely on) the `SteadyStateThread` and the presence of `LingeredApp.steadyState()`, the need for `LingeredAppWithTrivialMain` goes away. `LingeredApp.steadyState()` will always be compiled, even on aarch64.
>> 
>> Regarding `DebugdConnectTest.java`, it is listed in the CR as an affected test but no specified fix has been provided.
>>  None is needed. The issue was that it looked for `LingeredApp` in the jstack output, and it used to be the only place it would find it was in the main thread's stack trace, which sometimes could not be retrieved. Now it can also be found in the `SteadyStateThread`'s stack trace, which can always be retrieved.
>> 
>> Regarding `HeapDumpTest.java`, it used to check for `LingeredAppWithExtendedChars.main` and now it checks for `LingeredApp.steadyState`. It still is run with `LingeredAppWithExtendedChars`. The only thing special about that class is that it contains an extended unicode character used to reproduce [JDK-8028623](https://bugs.openjdk.java.net/browse/JDK-8028623), so it will still do that, even though it now checks for `LingeredApp.steadyState`.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use onSpinWait() instead of sleep(), and check for BLOCKED thread state.

Marked as reviewed by ysuenaga (Reviewer).

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

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

From lzang at openjdk.java.net  Tue Mar  9 14:00:27 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Tue, 9 Mar 2021 14:00:27 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v3]
In-Reply-To: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
Message-ID: <Y8JmpRiD2VjqmFo3iJNcA2cdxfpIL46XEDOED3PqO4M=.a425bbf3-5c7e-4a12-8449-1f8326393bac@github.com>

> 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out

Lin Zang has updated the pull request incrementally with one additional commit since the last revision:

  Revert "reduce memory consumption"
  
  This reverts commit 70e43ddd453724ce36bf729fa6489c0027957b8e.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2803/files
  - new: https://git.openjdk.java.net/jdk/pull/2803/files/70e43ddd..8dde2fdd

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

  Stats: 98 lines in 1 file changed: 3 ins; 50 del; 45 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2803.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2803/head:pull/2803

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

From lzang at openjdk.java.net  Tue Mar  9 14:00:27 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Tue, 9 Mar 2021 14:00:27 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out
In-Reply-To: <cedPjc6Gumib0S_yqDLAm8up9lPEGguw5w5LJblpKHM=.cad805fe-ab47-4eb4-8c78-e2a17109a2ce@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
 <Zvf7GN59hJdc7SgVRao3cEbcpU99CbGceULIfJnDJOE=.4bd79c51-6b9b-4ff9-9ada-dc43fd6ca6e8@github.com>
 <e6bMvI_trIEXu7SAiM98-OpZug3Mwli00owZzLXxJNo=.fa0b5857-28b8-428d-9477-61044e32ad49@github.com>
 <oaMRL-GuwQKYlGByJvPhHH63A4LTvQLsL2W6BOIS6cc=.5ee0e7f9-bdc3-4e51-9fcf-999d607730c1@github.com>
 <7p7PD78B0fKuSonRZ44rQWvBKHabsz4n9VT4WbVluFI=.e4248320-f134-4ed0-b073-a3466970932c@github.com>
 <cedPjc6Gumib0S_yqDLAm8up9lPEGguw5w5LJblpKHM=.cad805fe-ab47-4eb4-8c78-e2a17109a2ce@github.com>
Message-ID: <69h5uaXSdgc4Fkhla6QdtoezGPyVcFMNasVI8iNxYWI=.3a7c3e6a-8dfa-4ff1-a7cf-db71d3ea7bbf@github.com>

On Fri, 5 Mar 2021 11:05:57 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> Hi Chris,
>> Thanks a lot, I am still wip to reduce the memory consumption. So I think you could help review after my next update :)
>> 
>> BRs,
>> Lin
>
> Update a new patch that reduce the memory consumption issue.
> As mentioned in the CR,  there is internal buffer used for segmented heap dump.  The dumped object data firstly write into this buffer and then flush() when the size is known. when the internal buffer is full, the current implementation do:
> 
> - new a larger buffer,  copy data from old buffer into the new one, and then use it as the internal buffer.
> 
> This could cause large memory consumption because the old buffer data are copied, and also the old buffer can not be "free" until next GC. 
> 
> For example, if the internel buffer's length is 1MB, when it is full, a new 2MB buffer is allocated so there is actually 3MB memory taken (old buffer + new buffer). And in this case, for the ~4GB large array, it keeps generating new buffers and do copying, which takes both CPU and memory intensively and cause the timeout issue.
> 
> This patch optimize it by creating a array list of byte[]. when old buffer is full, it saved into the list and the new one is created and used as the internal buffer. In this case, the above example takes 2MB?1MB for old? saved in the list; and 1MB for the new buffer)
> 
> Together with the "write through" mode introduced in this PR, by which all arrays are write through to underlying stream and hence no extra buffer requried. The PR could help fix the LargeArray issue and also save memory.
> 
> Thanks!
> Lin

As discussed in CR https://bugs.openjdk.java.net/browse/JDK-8262386, the byte[] list is much more like an optimization. Revert it in the PR and I will create a separate CR and PR for it. 

Thanks,
Lin

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

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

From akozlov at openjdk.java.net  Tue Mar  9 16:12:36 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 9 Mar 2021 16:12:36 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v24]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <LMAOpd9DlD4esG9l4lwxtOe5_j1Cpi6aU33tVWCz3bE=.b4ab8215-55c0-43b4-a222-03e5aa0862e3@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 105 commits:

 - Merge commit 'refs/pull/11/head' of https://github.com/AntonKozlov/jdk into jdk-macos
 - workaround JDK-8262895 by disabling subtest
 - Fix typo
 - Rename threadWXSetters.hpp -> threadWXSetters.inline.hpp
 - JDK-8259937: bsd_aarch64 part
 - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
 - Fix after JDK-8259539, partially revert preconditions
 - JDK-8260471: bsd_aarch64 part
 - JDK-8259539: bsd_aarch64 part
 - JDK-8257828: bsd_aarch64 part
 - ... and 95 more: https://git.openjdk.java.net/jdk/compare/a6e34b3d...a72f6834

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

Changes: https://git.openjdk.java.net/jdk/pull/2200/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=23
  Stats: 2873 lines in 73 files changed: 2787 ins; 27 del; 59 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

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

From akozlov at openjdk.java.net  Tue Mar  9 16:12:37 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 9 Mar 2021 16:12:37 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12]
In-Reply-To: <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <Vg27jHtpjAQ36mYoE5MyolUJUi8K9lSb_c3grH_DLvM=.df18633b-2124-44b0-ac51-e5405a3f745d@github.com>
 <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com>
Message-ID: <yi2biGsqSXqJPSCRZcsTxv1vVOnSZiGvtBK96gl6u14=.80dd4aa2-e6d1-49aa-a95a-020203b6fce5@github.com>

On Tue, 9 Feb 2021 09:06:26 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update signal handler part for debugger
>
> src/hotspot/share/runtime/threadWXSetters.hpp line 28:
> 
>> 26: #define SHARE_RUNTIME_THREADWXSETTERS_HPP
>> 27: 
>> 28: #include "runtime/thread.inline.hpp"
> 
> This breaks against our convention to forbid inline.hpp files from being included from being included from .hpp files. You need to rework this by either moving the implementation to a .cpp file, or convert this file into an .inline.hpp
> 
> See the Source Files section in:
> https://htmlpreview.github.io/?https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.html

Thanks, I renamed the file to threadWXSetters.inline.hpp

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

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

From akozlov at openjdk.java.net  Tue Mar  9 16:58:19 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 9 Mar 2021 16:58:19 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12]
In-Reply-To: <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <Vg27jHtpjAQ36mYoE5MyolUJUi8K9lSb_c3grH_DLvM=.df18633b-2124-44b0-ac51-e5405a3f745d@github.com>
 <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com>
Message-ID: <z9mnfpAEpe9fRFn8A_rmjYx3nU1mzbRsCiMPWsLEKkU=.b7a08d2b-fc4b-42a6-aabb-2b008427ba2c@github.com>

On Tue, 9 Feb 2021 09:12:13 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update signal handler part for debugger
>
> src/hotspot/share/runtime/thread.hpp line 848:
> 
>> 846:   void init_wx();
>> 847:   WXMode enable_wx(WXMode new_state);
>> 848: #endif // __APPLE__ && AARCH64
> 
> Now that this is only compiled into macOS/AArch64, could this be moved over to thread_bsd_aarch64.hpp? The same goes for the associated functions.

The thread_bsd_aarch64.hpp describes a part of JavaThread, while this block belongs to Thread for now. Since W^X is an attribute of any operating system thread, I assumed Thread to be the right place for W^X bookkeeping. 

In most cases, we manage W^X state of JavaThread. But sometimes a GC thread needs the WXWrite state, or safefetch is called from non-JavaThread. Probably this can be dealt with (e.g. GCThread to always have the WXWrite state). But such change would be much more than a simple refactoring and it would require a significant amount of testing. Ideally, I would like to investigate this as a follow-up change, or at least after other fixes to this PR.

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

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

From kevinw at openjdk.java.net  Tue Mar  9 17:38:09 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Tue, 9 Mar 2021 17:38:09 GMT
Subject: RFR: 8262520: Add SA Command Line Debugger support to connect to
 debug server [v6]
In-Reply-To: <IMzvJPwPM29clXUBuQx8QO15Bt4dRWeXSIaISbvG3Vs=.2f5f50c7-3a6a-477a-b4b5-9139a2823472@github.com>
References: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
 <IMzvJPwPM29clXUBuQx8QO15Bt4dRWeXSIaISbvG3Vs=.2f5f50c7-3a6a-477a-b4b5-9139a2823472@github.com>
Message-ID: <nQLW0b1pfAD8S_JLJp5N1upyXBRzCRURjLJxiACHHrE=.a3f096e5-c5e9-42b9-97b0-a8c18e5f0de6@github.com>

On Fri, 5 Mar 2021 07:33:06 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> `attach` command on CLHSDB supports to attach live process (PID) and coredump, but it cannot connect to debug server. CLHSDB does not have a command to connect to debug server.
>> 
>> Other jhsdb commands (jstack, jmap, etc...) can connect debug server via `--connect` option, so CLHSDB should connect to it.
>> 
>> After this change, you can connect to debug server with 'connect <hostname>'.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add assertion to check unexpected exceptions are happened in command line debugger

Marked as reviewed by kevinw (Committer).

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

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

From akozlov at openjdk.java.net  Tue Mar  9 17:58:21 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 9 Mar 2021 17:58:21 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12]
In-Reply-To: <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <Vg27jHtpjAQ36mYoE5MyolUJUi8K9lSb_c3grH_DLvM=.df18633b-2124-44b0-ac51-e5405a3f745d@github.com>
 <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com>
Message-ID: <Dze4ZtrPI_OLkuExMIN1fl5u6eCryLmgNRgAHzN2kXE=.eee71cb4-1c81-46f8-b6ae-063659a28fc2@github.com>

On Tue, 9 Feb 2021 09:23:50 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update signal handler part for debugger
>
> src/hotspot/share/runtime/thread.cpp line 2515:
> 
>> 2513: void JavaThread::check_special_condition_for_native_trans(JavaThread *thread) {
>> 2514:   // Enable WXWrite: called directly from interpreter native wrapper.
>> 2515:   MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXWrite, thread));
> 
> FWIW, I personally think that adding these MACOS_AARCH64_ONLY usages at the call sites increase the line-noise in the affected functions. I think I would have preferred a version:
> ThreadWXEnable(WXMode new_mode, Thread* thread = NULL) {
>   MACOS_AARCH64_ONLY(initialize(new_mode, thread);) {}
> void initialize(...); // Implementation in thread_bsd_aarch64.cpp (alt. inline.hpp)
> With that said, I'm fine with taking this discussion as a follow-up.

The former version used no such macros. I like that now it's clear the W^X management is relevant to macos/aarch64 only. I see the point to move the pre-processor condition into the class implementation. But I think it will bring a bit of inconsistency, as the rest of W^X implementation is explicitly guarded by preprocessor conditionals. I've also tried to push macro conditionals as far as possible down to implementation, providing a kind of generalized W^X interface. That required a few artificial decisions, e.g. how would we call the mode we execute on the rest of platforms with write and execute allowed, WXWriteExec?.. I abandoned that attempt.

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

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

From akozlov at openjdk.java.net  Tue Mar  9 18:04:19 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 9 Mar 2021 18:04:19 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v21]
In-Reply-To: <yMUjWudRugP8LTAT5fuc25Q7R1M9iTCBFMFvXGjRWlQ=.2a6cf189-5bb6-4f41-9e49-d859b85534b6@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <ZfRwLBDhh3K6u3NaWzLWVyoYqBuZVJbipXCZKzPclBs=.bedc9c24-2178-400a-8868-fbbb61b298cc@github.com>
 <yMUjWudRugP8LTAT5fuc25Q7R1M9iTCBFMFvXGjRWlQ=.2a6cf189-5bb6-4f41-9e49-d859b85534b6@github.com>
Message-ID: <v33sSQcIVsvidIkYzaOsIhkjNhojCVastBXuUJJ67IM=.9123e430-657f-4c24-a201-4f457232c983@github.com>

On Mon, 1 Mar 2021 10:31:19 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>>  - Minor fixes
>
> src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp line 62:
> 
>> 60: 
>> 61: #if defined(__APPLE__) || defined(_WIN64)
>> 62: #define R18_RESERVED
> 
> #define R18_RESERVED true```

We always check for `R18_RESERVED` with `#if(n)def`, is there any reason to define the value for the macro?

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

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

From lmesnik at openjdk.java.net  Tue Mar  9 18:16:18 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 9 Mar 2021 18:16:18 GMT
Subject: RFR: 8243455: Many SA tests can fail due to trying to get the
 stack trace of an active method [v2]
In-Reply-To: <fGSNDp2jgJFSt-dctuX4IMYv9txYr3wrS2LwHC4rNWk=.b994fce9-37ff-46f9-8c29-ed47deda062e@github.com>
References: <vjDRMVH6jMQsafl_UZTsf0Fglcx89foITgIg4Zhmawo=.f98f3f01-53d3-4613-8c54-67b9f2d34215@github.com>
 <fGSNDp2jgJFSt-dctuX4IMYv9txYr3wrS2LwHC4rNWk=.b994fce9-37ff-46f9-8c29-ed47deda062e@github.com>
Message-ID: <mnW3wgQ68DPj5kqQqYrNp1RmnWCwxoGcIbxqC3o1YXE=.97a5e9a1-1e30-4c4f-9a85-9b7334b65d22@github.com>

On Tue, 9 Mar 2021 07:27:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Many tests run `LingeredApp`, get its stack with `jstack`, and then look for `LingeredApp.main` in the output, which should appear in the stack trace of the main thread. Usually this works fine since the main thread is in a loop, and usually blocked in `Thread.sleep()`. However, during the short period of time it wakes up from sleep, the thread's stack might not be walk-able, in which case the `LingeredApp.main` frame will not appear, and the tests looking for it will fail.
>> 
>> The fix is to introduce a new thread called `SteadyStateThread` that has a method called `steadyState()` that blocks indefinitely trying to synchronize on a locked object. All code that used to look for `LingeredApp.main` in the output now instead looks for `LingeredApp.steadyState`, which should always be there. I'm open to suggestions for a better name than "SteadyState" if you have one.
>> 
>> There are a few special cases with the tests that were modified that are described below:
>> 
>> Regarding the removal of `LingeredAppWithTrivialMain.java`, it was originally added to fix [JDK-8229118](https://bugs.openjdk.java.net/browse/JDK-8229118), which was an issue with the `ClhsdbFindPC` test failing on aarch64 when doing the `-Xcomp` run. It expected `LingeredApp.main()` to be compiled in that case, and for the PC of the frame to be in an `NMethod`. However, on aarch64 an uncommon-trap was causing it to be de-optimized, so the PC was in the interpreter instead, causing the test to fail. The fix was to instead rely on finding a trivial `LingeredAppWithTrivialMain.main()` frame in the stack trace since it would always be compiled. With the changes to instead have (and rely on) the `SteadyStateThread` and the presence of `LingeredApp.steadyState()`, the need for `LingeredAppWithTrivialMain` goes away. `LingeredApp.steadyState()` will always be compiled, even on aarch64.
>> 
>> Regarding `DebugdConnectTest.java`, it is listed in the CR as an affected test but no specified fix has been provided.
>>  None is needed. The issue was that it looked for `LingeredApp` in the jstack output, and it used to be the only place it would find it was in the main thread's stack trace, which sometimes could not be retrieved. Now it can also be found in the `SteadyStateThread`'s stack trace, which can always be retrieved.
>> 
>> Regarding `HeapDumpTest.java`, it used to check for `LingeredAppWithExtendedChars.main` and now it checks for `LingeredApp.steadyState`. It still is run with `LingeredAppWithExtendedChars`. The only thing special about that class is that it contains an extended unicode character used to reproduce [JDK-8028623](https://bugs.openjdk.java.net/browse/JDK-8028623), so it will still do that, even though it now checks for `LingeredApp.steadyState`.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use onSpinWait() instead of sleep(), and check for BLOCKED thread state.

Marked as reviewed by lmesnik (Committer).

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

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

From prr at openjdk.java.net  Tue Mar  9 18:49:11 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 9 Mar 2021 18:49:11 GMT
Subject: RFR: 8263140: Japanese chars garble in console window in HSDB [v3]
In-Reply-To: <LeCT7kosfVYkwlsONMdmt1Re3tEUKoJB38TXlkdtY7o=.1d4442f8-938f-4fcc-8d61-94092d1de334@github.com>
References: <KYApMyFcX3_HUOUotqdR3gw1BALvA7oEqjfFZLecFjw=.3b5a6b82-0cd5-404e-af9f-ceb65ebf14f5@github.com>
 <LeCT7kosfVYkwlsONMdmt1Re3tEUKoJB38TXlkdtY7o=.1d4442f8-938f-4fcc-8d61-94092d1de334@github.com>
Message-ID: <DV3NKMTarpckq4r-ERcUaDcvQP2XufuO00iGC5qsAZg=.0dd99aa5-0029-41da-8474-4639cc869044@github.com>

On Tue, 9 Mar 2021 00:54:25 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We can command line debugger via "Windows" -> "Console" menu on HSDB. If the command shows error message in localized string (e.g. Japanese), it might garble as following:
>> 
>> ![garbled](https://user-images.githubusercontent.com/7421132/110232635-39e89b00-7f62-11eb-95c9-1a5238072814.png)
>> 
>> Command line debugger and Debugger Console (WinDbg on Windows) will use Courier font on their console, but it does not show Japanese chars. I guess it would happen on CJK chars because monospaced font for Chinese, Japanese, Korean are different from Courier.
>> 
>> After this change on Windows which set to Japanese locale, it uses MS Gothic and we can see localized message as following:
>> 
>> ![fixed](https://user-images.githubusercontent.com/7421132/110232699-a4014000-7f62-11eb-9185-6eff39394541.png)
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Get rid of using Courier font

Marked as reviewed by prr (Reviewer).

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

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

From cjplummer at openjdk.java.net  Tue Mar  9 18:55:09 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 9 Mar 2021 18:55:09 GMT
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code [v4]
In-Reply-To: <nU8Uca0ilRC5fhJjF7439Q2_WNRQ21pYK3jgJP0YT_8=.fb37074c-234a-493b-b05c-f7319a458c5b@github.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
 <nU8Uca0ilRC5fhJjF7439Q2_WNRQ21pYK3jgJP0YT_8=.fb37074c-234a-493b-b05c-f7319a458c5b@github.com>
Message-ID: <Ekzw6f-_m58CwUUziN-WUsGd5Kn8NXyimxbFe5hZSmo=.6f9d082b-2059-41b5-8ccb-6be77c6ac106@github.com>

On Fri, 5 Mar 2021 04:59:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> ObjectMonitors can only be used by JavaThreads (modulo some interactions with hashcodes and deflation) but we use "Thread*" almost everywhere mainly due to use of TRAPS (and TRAPS will itself use JavaThread once JDK-8252685 is done). Also some uses of TRAPS in the API's are wrong as, for example, monitor entry can never throw an exception.
>> 
>> So this cleanup tackles:
>> - remove incorrect use of TRAPS
>> - change "Thread*" to "JavaThread*" where applicable
>> - don't use THREAD for things not related to exception processing
>> - standardise the naming so that we have "JavaThread* current" rather a mix if Self/THREAD/jt etc.
>> - remove unnecessary as_Java_thread() conversions
>> - other misc cleanup I noticed in some functions
>> 
>> The cleanup is predominantly in objectMonitor.* and synchronizer.* but with a fan out to the users of those APIs. No attempt is made to cleanup the callers beyond ensuring we have a suitable JavaThread reference for the calls. 
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fix typo
>  - Fixed up BiasedLocking code in ObjectSynchronizer::enter
>  - iFixed alignment in macro

JVMTI changes look good.

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

Marked as reviewed by cjplummer (Reviewer).

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

From minqi at openjdk.java.net  Tue Mar  9 19:12:28 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 9 Mar 2021 19:12:28 GMT
Subject: RFR: 8259070: Add jcmd option to dump CDS [v2]
In-Reply-To: <hwrc1zAz8G180ToL-C3EuUIF-5R17F5Gm1zcPMBpOtE=.e002a377-e0e2-485b-a08e-b63675a9746b@github.com>
References: <hwrc1zAz8G180ToL-C3EuUIF-5R17F5Gm1zcPMBpOtE=.e002a377-e0e2-485b-a08e-b63675a9746b@github.com>
Message-ID: <Rjd_G-BdxHcm_iqB0s4pJdwvo52ZVDB_sJGwzccATrc=.75212572-8713-4489-85b3-c62756b4ea22@github.com>

> Hi, Please review
> 
>   Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with
>   `java -XX:DumpLoadedClassList=<classlist> .... `  
>  to collect shareable class names and saved in file `<classlist>` , then 
>   `java -Xshare:dump -XX:SharedClassListFile=<classlist> -XX:SharedArchiveFile=<archivefile> ...`
>   With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime  to dump an archive.
>    The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved.
>    New added jcmd option:
>    `jcmd <pid or AppName> VM.cds static_dump <filename>`
>    or
>     `jcmd <pid or AppName> VM.cds dynamic_dump <filename>`
>   To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. 
>    The file name is optional, if the file name is not supplied, the file name will take format of `java_pid<number>_static.jsa` or `java_pid<number>_dynamic.jsa` for static and dynamic respectively. The `<number>` is the application process ID.
> 
>   Tests: tier1,tier2,tier3,tier4
> 
> Thanks
> Yumin

Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:

  Add function CDS.dumpSharedArchive in java to dump shared archive

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2737/files
  - new: https://git.openjdk.java.net/jdk/pull/2737/files/e371456c..d486c06e

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

  Stats: 450 lines in 13 files changed: 258 ins; 156 del; 36 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2737.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2737/head:pull/2737

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

From cjplummer at openjdk.java.net  Tue Mar  9 19:13:11 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 9 Mar 2021 19:13:11 GMT
Subject: RFR: 8263140: Japanese chars garble in console window in HSDB [v3]
In-Reply-To: <LeCT7kosfVYkwlsONMdmt1Re3tEUKoJB38TXlkdtY7o=.1d4442f8-938f-4fcc-8d61-94092d1de334@github.com>
References: <KYApMyFcX3_HUOUotqdR3gw1BALvA7oEqjfFZLecFjw=.3b5a6b82-0cd5-404e-af9f-ceb65ebf14f5@github.com>
 <LeCT7kosfVYkwlsONMdmt1Re3tEUKoJB38TXlkdtY7o=.1d4442f8-938f-4fcc-8d61-94092d1de334@github.com>
Message-ID: <P8weJCBd0S0eDiL9uzlW2E-QnNbOi9Sm4tUAgwAcfHI=.c826289b-e837-472d-aec1-1ddbe4c31434@github.com>

On Tue, 9 Mar 2021 00:54:25 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We can command line debugger via "Windows" -> "Console" menu on HSDB. If the command shows error message in localized string (e.g. Japanese), it might garble as following:
>> 
>> ![garbled](https://user-images.githubusercontent.com/7421132/110232635-39e89b00-7f62-11eb-95c9-1a5238072814.png)
>> 
>> Command line debugger and Debugger Console (WinDbg on Windows) will use Courier font on their console, but it does not show Japanese chars. I guess it would happen on CJK chars because monospaced font for Chinese, Japanese, Korean are different from Courier.
>> 
>> After this change on Windows which set to Japanese locale, it uses MS Gothic and we can see localized message as following:
>> 
>> ![fixed](https://user-images.githubusercontent.com/7421132/110232699-a4014000-7f62-11eb-9185-6eff39394541.png)
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Get rid of using Courier font

Marked as reviewed by cjplummer (Reviewer).

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

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

From iklam at openjdk.java.net  Tue Mar  9 19:17:06 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 9 Mar 2021 19:17:06 GMT
Subject: RFR: 8263140: Japanese chars garble in console window in HSDB [v3]
In-Reply-To: <LeCT7kosfVYkwlsONMdmt1Re3tEUKoJB38TXlkdtY7o=.1d4442f8-938f-4fcc-8d61-94092d1de334@github.com>
References: <KYApMyFcX3_HUOUotqdR3gw1BALvA7oEqjfFZLecFjw=.3b5a6b82-0cd5-404e-af9f-ceb65ebf14f5@github.com>
 <LeCT7kosfVYkwlsONMdmt1Re3tEUKoJB38TXlkdtY7o=.1d4442f8-938f-4fcc-8d61-94092d1de334@github.com>
Message-ID: <UH7ueT2-FbQnLnSySXmKmc64cvp0g_EQ7D4qmKR0vpg=.1d5254cc-0bc4-4cf9-ac0f-667569aa415e@github.com>

On Tue, 9 Mar 2021 00:54:25 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We can command line debugger via "Windows" -> "Console" menu on HSDB. If the command shows error message in localized string (e.g. Japanese), it might garble as following:
>> 
>> ![garbled](https://user-images.githubusercontent.com/7421132/110232635-39e89b00-7f62-11eb-95c9-1a5238072814.png)
>> 
>> Command line debugger and Debugger Console (WinDbg on Windows) will use Courier font on their console, but it does not show Japanese chars. I guess it would happen on CJK chars because monospaced font for Chinese, Japanese, Korean are different from Courier.
>> 
>> After this change on Windows which set to Japanese locale, it uses MS Gothic and we can see localized message as following:
>> 
>> ![fixed](https://user-images.githubusercontent.com/7421132/110232699-a4014000-7f62-11eb-9185-6eff39394541.png)
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Get rid of using Courier font

Latest changes LGTM

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

Marked as reviewed by iklam (Reviewer).

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

From cjplummer at openjdk.java.net  Tue Mar  9 21:37:09 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 9 Mar 2021 21:37:09 GMT
Subject: Integrated: 8262486: Merge trivial JDWP agent changes from the loom
 repo to the jdk repo
In-Reply-To: <yHmko3VNeYOAz1V_gPdX6-12LRFibJEiOqu5L8frFEs=.7094c811-fc00-4c3c-bc53-788a3c225f74@github.com>
References: <yHmko3VNeYOAz1V_gPdX6-12LRFibJEiOqu5L8frFEs=.7094c811-fc00-4c3c-bc53-788a3c225f74@github.com>
Message-ID: <woAXG1a2yQD4eX2nY3E4hpK80zDnAi1K68KW6po4f6g=.d52791fd-dc0b-410b-a143-171774a712b6@github.com>

On Wed, 3 Mar 2021 20:17:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> In the loom repo there are a number of trivial changes to the JDWP agent that are not loom specific. Moving them to the jdk repo will make future merges simpler, along with making it easier to get a diff of the important differences between the loom and jdk repos, without the clutter of these trivial changes. The changes I'd like to merge are:
> 
> 1. Very minor code refactoring.
> 2. Comment additions, fixes, and improvements.
> 3. Minor indentation and whitespace changes.
> 4. Added a trivial assert

This pull request has now been integrated.

Changeset: 2218e726
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2218e726
Stats:     82 lines in 7 files changed: 38 ins; 5 del; 39 mod

8262486: Merge trivial JDWP agent changes from the loom repo to the jdk repo

Reviewed-by: amenkov, lmesnik

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

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

From minqi at openjdk.java.net  Tue Mar  9 21:50:25 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 9 Mar 2021 21:50:25 GMT
Subject: RFR: 8259070: Add jcmd option to dump CDS [v3]
In-Reply-To: <hwrc1zAz8G180ToL-C3EuUIF-5R17F5Gm1zcPMBpOtE=.e002a377-e0e2-485b-a08e-b63675a9746b@github.com>
References: <hwrc1zAz8G180ToL-C3EuUIF-5R17F5Gm1zcPMBpOtE=.e002a377-e0e2-485b-a08e-b63675a9746b@github.com>
Message-ID: <UQ6gbZhxZ-5W1HkjA_XO2RnuEI1U-scC_iJRPD2Mrb4=.99793b9d-3cd6-4fbe-ad98-f418ccbc6f3a@github.com>

> Hi, Please review
> 
>   Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with
>   `java -XX:DumpLoadedClassList=<classlist> .... `  
>  to collect shareable class names and saved in file `<classlist>` , then 
>   `java -Xshare:dump -XX:SharedClassListFile=<classlist> -XX:SharedArchiveFile=<archivefile> ...`
>   With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime  to dump an archive.
>    The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved.
>    New added jcmd option:
>    `jcmd <pid or AppName> VM.cds static_dump <filename>`
>    or
>     `jcmd <pid or AppName> VM.cds dynamic_dump <filename>`
>   To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. 
>    The file name is optional, if the file name is not supplied, the file name will take format of `java_pid<number>_static.jsa` or `java_pid<number>_dynamic.jsa` for static and dynamic respectively. The `<number>` is the application process ID.
> 
>   Tests: tier1,tier2,tier3,tier4
> 
> Thanks
> Yumin

Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:

  Fix white space in CDS.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2737/files
  - new: https://git.openjdk.java.net/jdk/pull/2737/files/d486c06e..bfa71577

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

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

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

From david.holmes at oracle.com  Tue Mar  9 21:57:50 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 10 Mar 2021 07:57:50 +1000
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code [v4]
In-Reply-To: <Ekzw6f-_m58CwUUziN-WUsGd5Kn8NXyimxbFe5hZSmo=.6f9d082b-2059-41b5-8ccb-6be77c6ac106@github.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
 <nU8Uca0ilRC5fhJjF7439Q2_WNRQ21pYK3jgJP0YT_8=.fb37074c-234a-493b-b05c-f7319a458c5b@github.com>
 <Ekzw6f-_m58CwUUziN-WUsGd5Kn8NXyimxbFe5hZSmo=.6f9d082b-2059-41b5-8ccb-6be77c6ac106@github.com>
Message-ID: <2d3d2ee8-0323-8e0b-a8a5-5d14c0113bbb@oracle.com>

On 10/03/2021 4:55 am, Chris Plummer wrote:
> On Fri, 5 Mar 2021 04:59:02 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> ObjectMonitors can only be used by JavaThreads (modulo some interactions with hashcodes and deflation) but we use "Thread*" almost everywhere mainly due to use of TRAPS (and TRAPS will itself use JavaThread once JDK-8252685 is done). Also some uses of TRAPS in the API's are wrong as, for example, monitor entry can never throw an exception.
>>>
>>> So this cleanup tackles:
>>> - remove incorrect use of TRAPS
>>> - change "Thread*" to "JavaThread*" where applicable
>>> - don't use THREAD for things not related to exception processing
>>> - standardise the naming so that we have "JavaThread* current" rather a mix if Self/THREAD/jt etc.
>>> - remove unnecessary as_Java_thread() conversions
>>> - other misc cleanup I noticed in some functions
>>>
>>> The cleanup is predominantly in objectMonitor.* and synchronizer.* but with a fan out to the users of those APIs. No attempt is made to cleanup the callers beyond ensuring we have a suitable JavaThread reference for the calls.
>>>
>>> Thanks,
>>> David
>>
>> David Holmes has updated the pull request incrementally with three additional commits since the last revision:
>>
>>   - Fix typo
>>   - Fixed up BiasedLocking code in ObjectSynchronizer::enter
>>   - iFixed alignment in macro
> 
> JVMTI changes look good.

Thanks Chris!

David

> -------------
> 
> Marked as reviewed by cjplummer (Reviewer).
> 
> PR: https://git.openjdk.java.net/jdk/pull/2802
> 

From igor.ignatyev at oracle.com  Tue Mar  9 22:41:24 2021
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 9 Mar 2021 22:41:24 +0000
Subject: RFR(S) : 8246494 : introduce vm.flagless at-requires property
In-Reply-To: <A153375D-2932-418F-A534-F7D9B18ACB02@oracle.com>
References: <F3998ECB-C19E-4F50-A7CA-A2D0A390ED70@oracle.com>
 <5b1cac8c-7e9b-195a-edfa-6ab972e32bf0@oracle.com>
 <A153375D-2932-418F-A534-F7D9B18ACB02@oracle.com>
Message-ID: <DFFAF124-7964-4A8A-BBF0-8FA0CE11FD77@oracle.com>

RFR got migrated to github as https://github.com/openjdk/jdk/pull/2800

-- Igor

On Jun 5, 2020, at 9:10 AM, Igor Ignatyev <igor.ignatyev at oracle.com<mailto:igor.ignatyev at oracle.com>> wrote:

Hi Per,

you are reading this correctly, make TEST=test/hotspot/jtreg/gc/z/TestSmallHeap.java JTREG="VM_OPTIONS=-XX:+UseZGC" won't execute gc/z/TestSmallHeap.java; and I don't see it to be incorrect. Let me try to explain why using gc/z/TestSmallHeap.java as a running example.

A hotspot test is expected not to be just runnable in an out-of-box configuration, but also to serve its purpose as much as possible (which is not always 100% given some tests require special build flavor, environment setup, etc); in other words, a test is to at least have all necessary VM flags within it and not to hope that someone will provide them. gc/z/TestSmallHeap.java does that, it explicitly selects zGC, so there is no need for -XX:+UseZGC to achieve that. Given this test can be run only when zGC can be selected, it @requires vm.gc.Z, which is set to true if zGC is already explicitly selected or if zGC is available and no other GC is specified, and the latter holds for an out-of-box configuration (assuming that zGC is available in the JVM under test); thus, again, you don't have to specify -XX:+UseZGC to run this test. So there are no "technical" reasons to run gc/z/TestSmallHeap.java (or any other gc/z/ tests) with -XX:+UseZGC. The proposed patches don't change that fact in any way.

The patches exclude the tests that ignore external VM flags from execution if any significant VM flags are specified. gc/z/TestSmallHeap.java ignores all externally provided VM flags, including -XX:+UseZGC. And although in the case of -XX:+UseZGC, it's harmless, in almost all other cases it's not. Just to give you a few examples:
Let's say you are fixing a bug in zGC which could be reproduced by gc/z/TestSmallHeap.java. You came up with two alternative solutions, one of which is guarded by `if (UseNewCode)`. To test these solutions, you ran gc/z tests twice: with -XX:+UseZGC -XX:+UseNewCode, and all tests passed; with XX:+UseZGC, and many tests (but not gc/z/TestSmallHeap.java) failed. So based on these results, you decided that the guarded solution is perfect, cleaned up the code, sent it out for review, got it pushed, and minutes later found out that gc/z/TestSmallHeap.java and some other tests which ignore VM flags failed. It would take you some time, to realize that you hadn't tested your UseNewCode solution by these tests. Yet were these tests excluded from your testing, it would be much easier for you to spot that and react accordingly.
Here is another scenario, you decided to change the default value of ZUncommit, so you ran different tests with `XX:+UseZGC -XX:-ZUncommit`, all green, you pushed a trivial change s/true/false in z_globals.hpp, next thing you knew a bunch of zGC specific tests failed in CI. And again, these were the tests that silently ignored `XX:+UseZGC -XX:-ZUncommit`.
Or a slight variation, zGC-supported was added to a future JIT, gc/z tests were run with the flag combination which enabled the future JIT, all passed, the victory was declared; N releases later; default JIT got changed to the future JIT; the next CI build is a disaster, with lots of tests failing from the bugs which had not been found N/2 years ago.

Although I understand that it might take some getting used to from you and others who used to run gc/x tests with -XX:+Use${X}GC, I am certain that this will improve the overall quality of hotspot, save not only machine time (from running these tests with other flags) but engineers time from analyzing surprising failures, and increase confidence and trust in the hotspot test suite.

In a word, I can see how this can be a bit surprising, yet still less surprising than the current behavior, but I don't see it as incorrect, it just surfaces limitations of certain tests. From my (slightly biased) point of view, it's the right thing to do.

Thanks.
-- Igor

On Jun 5, 2020, at 1:20 AM, Per Liden <per.liden at oracle.com<mailto:per.liden at oracle.com>> wrote:

Hi Igor,

When looking at the follow-up sub-tasks for this, I see for example this:

http://cr.openjdk.java.net/~iignatyev/8246499/webrev.00/test/hotspot/jtreg/gc/z/TestSmallHeap.java.udiff.html

Maybe I'm misunderstanding how this is supposed to work, but it looks like this test would now _not_ be executed if I do:

make TEST=test/hotspot/jtreg/gc/z/TestSmallHeap.java JTREG="VM_OPTIONS=-XX:+UseZGC"

Is that so? In that case, that seems incorrect.

cheers,
Per

On 6/3/20 11:30 PM, Igor Ignatyev wrote:
http://cr.openjdk.java.net/~iignatyev//8246494/webrev.00
70 lines changed: 66 ins; 0 del; 4 mod
Hi all,
could you please review the patch which introduces a new @requires property to filter out the tests which ignore externally provided JVM flags?
the idea behind this patch is to have a way to clearly mark tests which ignore flags, so
a) it's obvious that they don't execute a flag-guarded code/feature, and extra care should be taken to use them to verify any flag-guarded changed;
b) they can be easily excluded from runs w/ flags.
@requires and VMProps allows us to achieve both, so it's been decided to add a new property `vm.flagless`. `vm.flagless` is set to false if there are any XX flags other than `-XX:MaxRAMPercentage` and `-XX:CreateCoredumpOnCrash` (which are known to be set almost always) or any X flags other `-Xmixed`; in other words any tests w/ `@requires vm.flagless` will be excluded from runs w/ any other X / XX flags passed via `-vmoption` / `-javaoption`. in rare cases, when one still wants to run the tests marked by `vm.flagless`  w/ external flags, `vm.flagless` can be forcefully set to true by setting any value to `TEST_VM_FLAGLESS` env. variable.
this patch adds necessary common changes and marks common tests, namely Scimark, GTestWrapper and TestNativeProcessBuilder. Component-specific tests will be marked separately by the corresponding subtasks of 8151707[1].
please note, the patch depends on CODETOOLS-7902336[2], which will be included in the next jtreg version, so this patch is to be integrated only after jtreg5.1 is promoted and we switch to use it by 8246387[3].
JBS: https://bugs.openjdk.java.net/browse/JDK-8246494
webrev: http://cr.openjdk.java.net/~iignatyev//8246494/webrev.00
testing: marked tests w/ different XX and X flags w/ and w/o TEST_VM_FLAGLESS env. var, and w/o any flags
[1] https://bugs.openjdk.java.net/browse/JDK-8151707
[2] https://bugs.openjdk.java.net/browse/CODETOOLS-7902336
[3] https://bugs.openjdk.java.net/browse/JDK-8246387
Thanks,
-- Igor


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20210309/0374fdab/attachment-0001.htm>

From ysuenaga at openjdk.java.net  Tue Mar  9 23:45:11 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 9 Mar 2021 23:45:11 GMT
Subject: Integrated: 8262520: Add SA Command Line Debugger support to connect
 to debug server
In-Reply-To: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
References: <z09htzJY5-v4qx2tvdyORmaZBTvdZvehGxNbE3SxE9I=.4ddb82fd-bbe7-47b1-82f2-8595ffd18d0d@github.com>
Message-ID: <NUIOI6L8ZawmOX9xikE9Uy54MiUeRo5Jsm-ppUeoWgs=.acbf905d-fb62-4395-b6c8-ccea8d5bd0ca@github.com>

On Mon, 1 Mar 2021 07:31:04 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> `attach` command on CLHSDB supports to attach live process (PID) and coredump, but it cannot connect to debug server. CLHSDB does not have a command to connect to debug server.
> 
> Other jhsdb commands (jstack, jmap, etc...) can connect debug server via `--connect` option, so CLHSDB should connect to it.
> 
> After this change, you can connect to debug server with 'connect <hostname>'.

This pull request has now been integrated.

Changeset: 70342e85
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/70342e85
Stats:     225 lines in 5 files changed: 161 ins; 29 del; 35 mod

8262520: Add SA Command Line Debugger support to connect to debug server

Reviewed-by: cjplummer, kevinw

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

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

From ysuenaga at openjdk.java.net  Tue Mar  9 23:47:10 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 9 Mar 2021 23:47:10 GMT
Subject: Integrated: 8263140: Japanese chars garble in console window in HSDB
In-Reply-To: <KYApMyFcX3_HUOUotqdR3gw1BALvA7oEqjfFZLecFjw=.3b5a6b82-0cd5-404e-af9f-ceb65ebf14f5@github.com>
References: <KYApMyFcX3_HUOUotqdR3gw1BALvA7oEqjfFZLecFjw=.3b5a6b82-0cd5-404e-af9f-ceb65ebf14f5@github.com>
Message-ID: <ZAqfxZjhAPL1XtMzpc_GGL3ayCSefU76gu-Z8Dsx6Do=.6261a46e-d5ee-46ef-af9d-7dda44d55290@github.com>

On Sun, 7 Mar 2021 07:32:17 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> We can command line debugger via "Windows" -> "Console" menu on HSDB. If the command shows error message in localized string (e.g. Japanese), it might garble as following:
> 
> ![garbled](https://user-images.githubusercontent.com/7421132/110232635-39e89b00-7f62-11eb-95c9-1a5238072814.png)
> 
> Command line debugger and Debugger Console (WinDbg on Windows) will use Courier font on their console, but it does not show Japanese chars. I guess it would happen on CJK chars because monospaced font for Chinese, Japanese, Korean are different from Courier.
> 
> After this change on Windows which set to Japanese locale, it uses MS Gothic and we can see localized message as following:
> 
> ![fixed](https://user-images.githubusercontent.com/7421132/110232699-a4014000-7f62-11eb-9185-6eff39394541.png)

This pull request has now been integrated.

Changeset: d0c1aec2
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d0c1aec2
Stats:     24 lines in 5 files changed: 0 ins; 11 del; 13 mod

8263140: Japanese chars garble in console window in HSDB

Reviewed-by: iklam, prr, cjplummer

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

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

From sspitsyn at openjdk.java.net  Tue Mar  9 23:53:09 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 9 Mar 2021 23:53:09 GMT
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code [v4]
In-Reply-To: <nU8Uca0ilRC5fhJjF7439Q2_WNRQ21pYK3jgJP0YT_8=.fb37074c-234a-493b-b05c-f7319a458c5b@github.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
 <nU8Uca0ilRC5fhJjF7439Q2_WNRQ21pYK3jgJP0YT_8=.fb37074c-234a-493b-b05c-f7319a458c5b@github.com>
Message-ID: <bvkoDwsJXoV7ZGxSpXGq_iz1XyGMavlzSKc6BppvXrg=.fb6af4a6-3c75-4a77-beb9-7850e51dbd73@github.com>

On Fri, 5 Mar 2021 04:59:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> ObjectMonitors can only be used by JavaThreads (modulo some interactions with hashcodes and deflation) but we use "Thread*" almost everywhere mainly due to use of TRAPS (and TRAPS will itself use JavaThread once JDK-8252685 is done). Also some uses of TRAPS in the API's are wrong as, for example, monitor entry can never throw an exception.
>> 
>> So this cleanup tackles:
>> - remove incorrect use of TRAPS
>> - change "Thread*" to "JavaThread*" where applicable
>> - don't use THREAD for things not related to exception processing
>> - standardise the naming so that we have "JavaThread* current" rather a mix if Self/THREAD/jt etc.
>> - remove unnecessary as_Java_thread() conversions
>> - other misc cleanup I noticed in some functions
>> 
>> The cleanup is predominantly in objectMonitor.* and synchronizer.* but with a fan out to the users of those APIs. No attempt is made to cleanup the callers beyond ensuring we have a suitable JavaThread reference for the calls. 
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fix typo
>  - Fixed up BiasedLocking code in ObjectSynchronizer::enter
>  - iFixed alignment in macro

Marked as reviewed by sspitsyn (Reviewer).

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

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

From sspitsyn at openjdk.java.net  Tue Mar  9 23:53:09 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 9 Mar 2021 23:53:09 GMT
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code [v4]
In-Reply-To: <Ekzw6f-_m58CwUUziN-WUsGd5Kn8NXyimxbFe5hZSmo=.6f9d082b-2059-41b5-8ccb-6be77c6ac106@github.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
 <nU8Uca0ilRC5fhJjF7439Q2_WNRQ21pYK3jgJP0YT_8=.fb37074c-234a-493b-b05c-f7319a458c5b@github.com>
 <Ekzw6f-_m58CwUUziN-WUsGd5Kn8NXyimxbFe5hZSmo=.6f9d082b-2059-41b5-8ccb-6be77c6ac106@github.com>
Message-ID: <vwlcvk6TWrn-hJETlKGr99Vlh54MabzPlkRwd8NnwY8=.684eb486-75c8-47df-824a-6db4e41a77c9@github.com>

On Tue, 9 Mar 2021 18:52:27 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Fix typo
>>  - Fixed up BiasedLocking code in ObjectSynchronizer::enter
>>  - iFixed alignment in macro
>
> JVMTI changes look good.

Hi David,

Nice unification, looks great.
A couple of comments.

src/hotspot/share/runtime/synchronizer.cpp

 638 int ObjectSynchronizer::wait(Handle obj, jlong millis, TRAPS) {
 639   JavaThread* current = THREAD->as_Java_thread();
 . . .
 652   DTRACE_MONITOR_WAIT_PROBE(monitor, obj(), current, millis);
 653   monitor->wait(millis, true, THREAD); // Not CHECK as we need following code

Is it intentional to use `THREAD` instead of `current` at line 653?

1141 bool ObjectSynchronizer::request_deflate_idle_monitors() {
1142   Thread* current = Thread::current();
 . . .
1158     if (current->is_Java_thread()) {
1159       // JavaThread has to honor the blocking protocol.
1160       ThreadBlockInVM tbivm(current->as_Java_thread());
 . . .
 
 Would it better to define `current` as at the line 639?
 There can be similar cases, e.g. the `deflate_idle_monitors()`.
 
 -Serguei

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

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

From david.holmes at oracle.com  Wed Mar 10 00:37:02 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 10 Mar 2021 10:37:02 +1000
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code [v4]
In-Reply-To: <vwlcvk6TWrn-hJETlKGr99Vlh54MabzPlkRwd8NnwY8=.684eb486-75c8-47df-824a-6db4e41a77c9@github.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
 <nU8Uca0ilRC5fhJjF7439Q2_WNRQ21pYK3jgJP0YT_8=.fb37074c-234a-493b-b05c-f7319a458c5b@github.com>
 <Ekzw6f-_m58CwUUziN-WUsGd5Kn8NXyimxbFe5hZSmo=.6f9d082b-2059-41b5-8ccb-6be77c6ac106@github.com>
 <vwlcvk6TWrn-hJETlKGr99Vlh54MabzPlkRwd8NnwY8=.684eb486-75c8-47df-824a-6db4e41a77c9@github.com>
Message-ID: <26dc9d38-26ad-3587-0c1c-f3794318f9ab@oracle.com>

Hi Serguei,

Thanks for taking a look.

On 10/03/2021 9:53 am, Serguei Spitsyn wrote:
> On Tue, 9 Mar 2021 18:52:27 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:
> 
>>> David Holmes has updated the pull request incrementally with three additional commits since the last revision:
>>>
>>>   - Fix typo
>>>   - Fixed up BiasedLocking code in ObjectSynchronizer::enter
>>>   - iFixed alignment in macro
>>
>> JVMTI changes look good.
> 
> Hi David,
> 
> Nice unification, looks great.
> A couple of comments.
> 
> src/hotspot/share/runtime/synchronizer.cpp
> 
>   638 int ObjectSynchronizer::wait(Handle obj, jlong millis, TRAPS) {
>   639   JavaThread* current = THREAD->as_Java_thread();
>   . . .
>   652   DTRACE_MONITOR_WAIT_PROBE(monitor, obj(), current, millis);
>   653   monitor->wait(millis, true, THREAD); // Not CHECK as we need following code
> 
> Is it intentional to use `THREAD` instead of `current` at line 653?

Yes, purely as a documentation aid - the "THREAD" usage indicates the 
wait() can lead to an exception. (Once TRAPS is defined using JavaThread 
the "current" variable won't be needed.)

> 1141 bool ObjectSynchronizer::request_deflate_idle_monitors() {
> 1142   Thread* current = Thread::current();
>   . . .
> 1158     if (current->is_Java_thread()) {
> 1159       // JavaThread has to honor the blocking protocol.
> 1160       ThreadBlockInVM tbivm(current->as_Java_thread());
>   . . .
>   
>   Would it better to define `current` as at the line 639?
>   There can be similar cases, e.g. the `deflate_idle_monitors()`.

I'm not sure what you mean - the current thread in these calls need not 
be a JavaThread ... hmmm actually ... since  JDK-8254029 
request_deflate_idle_monitors is only used by WhiteBox for testing, so 
the current thread must be a JavaThread (previously it could be VMThread 
during VM shutdown). But not so for deflate_idle_monitors

// This function is called by the MonitorDeflationThread to deflate
// ObjectMonitors. It is also called via do_final_audit_and_print_stats()
// by the VMThread.
size_t ObjectSynchronizer::deflate_idle_monitors() {

I'll make an adjustment to request_deflate and re-test.

Thanks,
David

>   
>   -Serguei
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/2802
> 

From dholmes at openjdk.java.net  Wed Mar 10 00:57:40 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 10 Mar 2021 00:57:40 GMT
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code [v5]
In-Reply-To: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
Message-ID: <fb8DPH8A0ER-B3MiEZZJOJnGB2DMqVUiuuLQX9_MsR4=.6a19c75d-c908-4a24-bf90-da28c16177d2@github.com>

> ObjectMonitors can only be used by JavaThreads (modulo some interactions with hashcodes and deflation) but we use "Thread*" almost everywhere mainly due to use of TRAPS (and TRAPS will itself use JavaThread once JDK-8252685 is done). Also some uses of TRAPS in the API's are wrong as, for example, monitor entry can never throw an exception.
> 
> So this cleanup tackles:
> - remove incorrect use of TRAPS
> - change "Thread*" to "JavaThread*" where applicable
> - don't use THREAD for things not related to exception processing
> - standardise the naming so that we have "JavaThread* current" rather a mix if Self/THREAD/jt etc.
> - remove unnecessary as_Java_thread() conversions
> - other misc cleanup I noticed in some functions
> 
> The cleanup is predominantly in objectMonitor.* and synchronizer.* but with a fan out to the users of those APIs. No attempt is made to cleanup the callers beyond ensuring we have a suitable JavaThread reference for the calls. 
> 
> Thanks,
> David

David Holmes 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 10 additional commits since the last revision:

 - Merge branch 'master' into 8262910-sync-traps
 - Updated request_deflate_idle_monitors as it can only be called by a JavaThread via WhiteBox API
 - Fix typo
 - Fixed up BiasedLocking code in ObjectSynchronizer::enter
 - iFixed alignment in macro
 - More pointer declaration style fixups
 - ObjectMonitor::exit can't actually throw IMSE so replaced TRAPS with JavaThread* current
 - Style fix: Thread *  -> Thread* in type declarations
 - Forgot to updated Graal config for JVMCI structs change
 - 8262910: Cleanup THREAD/TRAPS/naming and typing issues in ObjectMonitor and related code

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2802/files
  - new: https://git.openjdk.java.net/jdk/pull/2802/files/e8e7674b..b493c2e9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2802&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2802&range=03-04

  Stats: 8483 lines in 272 files changed: 4864 ins; 2218 del; 1401 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2802.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2802/head:pull/2802

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

From sspitsyn at openjdk.java.net  Wed Mar 10 01:07:10 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 10 Mar 2021 01:07:10 GMT
Subject: RFR: 8243455: Many SA tests can fail due to trying to get the
 stack trace of an active method [v2]
In-Reply-To: <fGSNDp2jgJFSt-dctuX4IMYv9txYr3wrS2LwHC4rNWk=.b994fce9-37ff-46f9-8c29-ed47deda062e@github.com>
References: <vjDRMVH6jMQsafl_UZTsf0Fglcx89foITgIg4Zhmawo=.f98f3f01-53d3-4613-8c54-67b9f2d34215@github.com>
 <fGSNDp2jgJFSt-dctuX4IMYv9txYr3wrS2LwHC4rNWk=.b994fce9-37ff-46f9-8c29-ed47deda062e@github.com>
Message-ID: <ljxB3fxTF3pQShWdfBWhcZDsR7adqceeoSntVTjzBns=.572711b1-0179-4704-81f3-2f6dcf10c9fe@github.com>

On Tue, 9 Mar 2021 07:27:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Many tests run `LingeredApp`, get its stack with `jstack`, and then look for `LingeredApp.main` in the output, which should appear in the stack trace of the main thread. Usually this works fine since the main thread is in a loop, and usually blocked in `Thread.sleep()`. However, during the short period of time it wakes up from sleep, the thread's stack might not be walk-able, in which case the `LingeredApp.main` frame will not appear, and the tests looking for it will fail.
>> 
>> The fix is to introduce a new thread called `SteadyStateThread` that has a method called `steadyState()` that blocks indefinitely trying to synchronize on a locked object. All code that used to look for `LingeredApp.main` in the output now instead looks for `LingeredApp.steadyState`, which should always be there. I'm open to suggestions for a better name than "SteadyState" if you have one.
>> 
>> There are a few special cases with the tests that were modified that are described below:
>> 
>> Regarding the removal of `LingeredAppWithTrivialMain.java`, it was originally added to fix [JDK-8229118](https://bugs.openjdk.java.net/browse/JDK-8229118), which was an issue with the `ClhsdbFindPC` test failing on aarch64 when doing the `-Xcomp` run. It expected `LingeredApp.main()` to be compiled in that case, and for the PC of the frame to be in an `NMethod`. However, on aarch64 an uncommon-trap was causing it to be de-optimized, so the PC was in the interpreter instead, causing the test to fail. The fix was to instead rely on finding a trivial `LingeredAppWithTrivialMain.main()` frame in the stack trace since it would always be compiled. With the changes to instead have (and rely on) the `SteadyStateThread` and the presence of `LingeredApp.steadyState()`, the need for `LingeredAppWithTrivialMain` goes away. `LingeredApp.steadyState()` will always be compiled, even on aarch64.
>> 
>> Regarding `DebugdConnectTest.java`, it is listed in the CR as an affected test but no specified fix has been provided.
>>  None is needed. The issue was that it looked for `LingeredApp` in the jstack output, and it used to be the only place it would find it was in the main thread's stack trace, which sometimes could not be retrieved. Now it can also be found in the `SteadyStateThread`'s stack trace, which can always be retrieved.
>> 
>> Regarding `HeapDumpTest.java`, it used to check for `LingeredAppWithExtendedChars.main` and now it checks for `LingeredApp.steadyState`. It still is run with `LingeredAppWithExtendedChars`. The only thing special about that class is that it contains an extended unicode character used to reproduce [JDK-8028623](https://bugs.openjdk.java.net/browse/JDK-8028623), so it will still do that, even though it now checks for `LingeredApp.steadyState`.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use onSpinWait() instead of sleep(), and check for BLOCKED thread state.

Marked as reviewed by sspitsyn (Reviewer).

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

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

From sspitsyn at openjdk.java.net  Wed Mar 10 01:07:12 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 10 Mar 2021 01:07:12 GMT
Subject: RFR: 8243455: Many SA tests can fail due to trying to get the
 stack trace of an active method [v2]
In-Reply-To: <mnW3wgQ68DPj5kqQqYrNp1RmnWCwxoGcIbxqC3o1YXE=.97a5e9a1-1e30-4c4f-9a85-9b7334b65d22@github.com>
References: <vjDRMVH6jMQsafl_UZTsf0Fglcx89foITgIg4Zhmawo=.f98f3f01-53d3-4613-8c54-67b9f2d34215@github.com>
 <fGSNDp2jgJFSt-dctuX4IMYv9txYr3wrS2LwHC4rNWk=.b994fce9-37ff-46f9-8c29-ed47deda062e@github.com>
 <mnW3wgQ68DPj5kqQqYrNp1RmnWCwxoGcIbxqC3o1YXE=.97a5e9a1-1e30-4c4f-9a85-9b7334b65d22@github.com>
Message-ID: <9x_Z0W-8nCCR113XgUgtIp0LGb1C1-46x40K79EGjVQ=.92043908-63a8-4ec6-98b2-4ff02edecd33@github.com>

On Tue, 9 Mar 2021 18:13:09 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use onSpinWait() instead of sleep(), and check for BLOCKED thread state.
>
> Marked as reviewed by lmesnik (Committer).

Chris,

test/lib/jdk/test/lib/apps/LingeredApp.java

It is better to rename `startSteadStateThread` to `startSteadyStateThread`, otherwise it seems to be a typo.

+        try {
+            // Sleep until the thread has started running.
+            while (!steadyStateReached) {
+                Thread.sleep(100);
+            }
+            // Do another short sleep so we can get into the synchronized block,
+            // although this probably is not necessary to guarantee that the
+            // stack trace is readable.
+            Thread.sleep(100);
+        } catch (InterruptedException e) {
+        }

It is better to remove the second sleep as it is not really needed.

Another concern is that the stack trace of this thread is going to be trivial, not sure if it is useful.
But it can be okay though if it serves trivial purposes. :)
It feels like something better is needed in general.

-Serguei

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

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

From cjplummer at openjdk.java.net  Wed Mar 10 01:56:07 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 10 Mar 2021 01:56:07 GMT
Subject: RFR: 8243455: Many SA tests can fail due to trying to get the
 stack trace of an active method [v2]
In-Reply-To: <ljxB3fxTF3pQShWdfBWhcZDsR7adqceeoSntVTjzBns=.572711b1-0179-4704-81f3-2f6dcf10c9fe@github.com>
References: <vjDRMVH6jMQsafl_UZTsf0Fglcx89foITgIg4Zhmawo=.f98f3f01-53d3-4613-8c54-67b9f2d34215@github.com>
 <fGSNDp2jgJFSt-dctuX4IMYv9txYr3wrS2LwHC4rNWk=.b994fce9-37ff-46f9-8c29-ed47deda062e@github.com>
 <ljxB3fxTF3pQShWdfBWhcZDsR7adqceeoSntVTjzBns=.572711b1-0179-4704-81f3-2f6dcf10c9fe@github.com>
Message-ID: <PSmtXMf10hyU5GE8VuhC6QWsCdp19e-z4ScLsKY1HFo=.a82dfdf9-4796-43d3-9e75-dbda82a5d58c@github.com>

On Wed, 10 Mar 2021 01:04:31 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use onSpinWait() instead of sleep(), and check for BLOCKED thread state.
>
> Marked as reviewed by sspitsyn (Reviewer).

@sspitsyn 

> It is better to rename `startSteadStateThread` to `startSteadyStateThread`, otherwise it seems to be a typo.

I'll fix that.

> It is better to remove the second sleep as it is not really needed.

You were looking at the first version. It was updated last night.

> Another concern is that the stack trace of this thread is going to be trivial, not sure if it is useful.
> But it can be okay though if it serves trivial purposes. :)
> It feels like something better is needed in general.

It's no less trivial than the main thread that tests used to look for, except that previously once in a great while the thread woke up from sleep (and that usually resulted in a test failure because the stack trace could not be produced). However, I also have a PR [2720](https://github.com/openjdk/jdk/pull/2720) to add a stack trace stress test.

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

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

From cjplummer at openjdk.java.net  Wed Mar 10 02:01:22 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 10 Mar 2021 02:01:22 GMT
Subject: RFR: 8243455: Many SA tests can fail due to trying to get the
 stack trace of an active method [v3]
In-Reply-To: <vjDRMVH6jMQsafl_UZTsf0Fglcx89foITgIg4Zhmawo=.f98f3f01-53d3-4613-8c54-67b9f2d34215@github.com>
References: <vjDRMVH6jMQsafl_UZTsf0Fglcx89foITgIg4Zhmawo=.f98f3f01-53d3-4613-8c54-67b9f2d34215@github.com>
Message-ID: <iGPDSfUDLlzwW9VlnFZp7EhGYJZAbAWs_EeW7tarRcg=.3e31dcd9-df9d-4ec8-b5f2-128766a234f0@github.com>

> Many tests run `LingeredApp`, get its stack with `jstack`, and then look for `LingeredApp.main` in the output, which should appear in the stack trace of the main thread. Usually this works fine since the main thread is in a loop, and usually blocked in `Thread.sleep()`. However, during the short period of time it wakes up from sleep, the thread's stack might not be walk-able, in which case the `LingeredApp.main` frame will not appear, and the tests looking for it will fail.
> 
> The fix is to introduce a new thread called `SteadyStateThread` that has a method called `steadyState()` that blocks indefinitely trying to synchronize on a locked object. All code that used to look for `LingeredApp.main` in the output now instead looks for `LingeredApp.steadyState`, which should always be there. I'm open to suggestions for a better name than "SteadyState" if you have one.
> 
> There are a few special cases with the tests that were modified that are described below:
> 
> Regarding the removal of `LingeredAppWithTrivialMain.java`, it was originally added to fix [JDK-8229118](https://bugs.openjdk.java.net/browse/JDK-8229118), which was an issue with the `ClhsdbFindPC` test failing on aarch64 when doing the `-Xcomp` run. It expected `LingeredApp.main()` to be compiled in that case, and for the PC of the frame to be in an `NMethod`. However, on aarch64 an uncommon-trap was causing it to be de-optimized, so the PC was in the interpreter instead, causing the test to fail. The fix was to instead rely on finding a trivial `LingeredAppWithTrivialMain.main()` frame in the stack trace since it would always be compiled. With the changes to instead have (and rely on) the `SteadyStateThread` and the presence of `LingeredApp.steadyState()`, the need for `LingeredAppWithTrivialMain` goes away. `LingeredApp.steadyState()` will always be compiled, even on aarch64.
> 
> Regarding `DebugdConnectTest.java`, it is listed in the CR as an affected test but no specified fix has been provided.
>  None is needed. The issue was that it looked for `LingeredApp` in the jstack output, and it used to be the only place it would find it was in the main thread's stack trace, which sometimes could not be retrieved. Now it can also be found in the `SteadyStateThread`'s stack trace, which can always be retrieved.
> 
> Regarding `HeapDumpTest.java`, it used to check for `LingeredAppWithExtendedChars.main` and now it checks for `LingeredApp.steadyState`. It still is run with `LingeredAppWithExtendedChars`. The only thing special about that class is that it contains an extended unicode character used to reproduce [JDK-8028623](https://bugs.openjdk.java.net/browse/JDK-8028623), so it will still do that, even though it now checks for `LingeredApp.steadyState`.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  rename startSteadStateThread to startSteadyStateThread

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2700/files
  - new: https://git.openjdk.java.net/jdk/pull/2700/files/f2d964cb..2be98ddf

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

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

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

From dcubed at openjdk.java.net  Wed Mar 10 02:19:16 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 10 Mar 2021 02:19:16 GMT
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code [v5]
In-Reply-To: <fb8DPH8A0ER-B3MiEZZJOJnGB2DMqVUiuuLQX9_MsR4=.6a19c75d-c908-4a24-bf90-da28c16177d2@github.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
 <fb8DPH8A0ER-B3MiEZZJOJnGB2DMqVUiuuLQX9_MsR4=.6a19c75d-c908-4a24-bf90-da28c16177d2@github.com>
Message-ID: <Taah45GFM0LUp_Oi8SJfWvFsQk8tASZT2O8xaVJQiT4=.0eb5f1a3-d8ae-4167-b43e-eeafbcdb9375@github.com>

On Wed, 10 Mar 2021 00:57:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> ObjectMonitors can only be used by JavaThreads (modulo some interactions with hashcodes and deflation) but we use "Thread*" almost everywhere mainly due to use of TRAPS (and TRAPS will itself use JavaThread once JDK-8252685 is done). Also some uses of TRAPS in the API's are wrong as, for example, monitor entry can never throw an exception.
>> 
>> So this cleanup tackles:
>> - remove incorrect use of TRAPS
>> - change "Thread*" to "JavaThread*" where applicable
>> - don't use THREAD for things not related to exception processing
>> - standardise the naming so that we have "JavaThread* current" rather a mix if Self/THREAD/jt etc.
>> - remove unnecessary as_Java_thread() conversions
>> - other misc cleanup I noticed in some functions
>> 
>> The cleanup is predominantly in objectMonitor.* and synchronizer.* but with a fan out to the users of those APIs. No attempt is made to cleanup the callers beyond ensuring we have a suitable JavaThread reference for the calls. 
>> 
>> Thanks,
>> David
>
> David Holmes 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 10 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8262910-sync-traps
>  - Updated request_deflate_idle_monitors as it can only be called by a JavaThread via WhiteBox API
>  - Fix typo
>  - Fixed up BiasedLocking code in ObjectSynchronizer::enter
>  - iFixed alignment in macro
>  - More pointer declaration style fixups
>  - ObjectMonitor::exit can't actually throw IMSE so replaced TRAPS with JavaThread* current
>  - Style fix: Thread *  -> Thread* in type declarations
>  - Forgot to updated Graal config for JVMCI structs change
>  - 8262910: Cleanup THREAD/TRAPS/naming and typing issues in ObjectMonitor and related code

Marked as reviewed by dcubed (Reviewer).

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

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

From david.holmes at oracle.com  Wed Mar 10 02:41:25 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 10 Mar 2021 12:41:25 +1000
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code [v5]
In-Reply-To: <Taah45GFM0LUp_Oi8SJfWvFsQk8tASZT2O8xaVJQiT4=.0eb5f1a3-d8ae-4167-b43e-eeafbcdb9375@github.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
 <fb8DPH8A0ER-B3MiEZZJOJnGB2DMqVUiuuLQX9_MsR4=.6a19c75d-c908-4a24-bf90-da28c16177d2@github.com>
 <Taah45GFM0LUp_Oi8SJfWvFsQk8tASZT2O8xaVJQiT4=.0eb5f1a3-d8ae-4167-b43e-eeafbcdb9375@github.com>
Message-ID: <e9eacb14-1bf5-d235-57a7-6b2039a60fab@oracle.com>

On 10/03/2021 12:19 pm, Daniel D.Daugherty wrote:
> On Wed, 10 Mar 2021 00:57:40 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> ObjectMonitors can only be used by JavaThreads (modulo some interactions with hashcodes and deflation) but we use "Thread*" almost everywhere mainly due to use of TRAPS (and TRAPS will itself use JavaThread once JDK-8252685 is done). Also some uses of TRAPS in the API's are wrong as, for example, monitor entry can never throw an exception.
>>>
>>> So this cleanup tackles:
>>> - remove incorrect use of TRAPS
>>> - change "Thread*" to "JavaThread*" where applicable
>>> - don't use THREAD for things not related to exception processing
>>> - standardise the naming so that we have "JavaThread* current" rather a mix if Self/THREAD/jt etc.
>>> - remove unnecessary as_Java_thread() conversions
>>> - other misc cleanup I noticed in some functions
>>>
>>> The cleanup is predominantly in objectMonitor.* and synchronizer.* but with a fan out to the users of those APIs. No attempt is made to cleanup the callers beyond ensuring we have a suitable JavaThread reference for the calls.
>>>
>>> Thanks,
>>> David
>>
>> David Holmes 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 10 additional commits since the last revision:
>>
>>   - Merge branch 'master' into 8262910-sync-traps
>>   - Updated request_deflate_idle_monitors as it can only be called by a JavaThread via WhiteBox API
>>   - Fix typo
>>   - Fixed up BiasedLocking code in ObjectSynchronizer::enter
>>   - iFixed alignment in macro
>>   - More pointer declaration style fixups
>>   - ObjectMonitor::exit can't actually throw IMSE so replaced TRAPS with JavaThread* current
>>   - Style fix: Thread *  -> Thread* in type declarations
>>   - Forgot to updated Graal config for JVMCI structs change
>>   - 8262910: Cleanup THREAD/TRAPS/naming and typing issues in ObjectMonitor and related code
> 
> Marked as reviewed by dcubed (Reviewer).

Thanks for the final re-review Dan. I'll push once testing is complete.

David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/2802
> 

From sspitsyn at openjdk.java.net  Wed Mar 10 02:52:12 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 10 Mar 2021 02:52:12 GMT
Subject: RFR: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code [v5]
In-Reply-To: <Taah45GFM0LUp_Oi8SJfWvFsQk8tASZT2O8xaVJQiT4=.0eb5f1a3-d8ae-4167-b43e-eeafbcdb9375@github.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
 <fb8DPH8A0ER-B3MiEZZJOJnGB2DMqVUiuuLQX9_MsR4=.6a19c75d-c908-4a24-bf90-da28c16177d2@github.com>
 <Taah45GFM0LUp_Oi8SJfWvFsQk8tASZT2O8xaVJQiT4=.0eb5f1a3-d8ae-4167-b43e-eeafbcdb9375@github.com>
Message-ID: <U8z4Nefmv6teR7N89qS0FAzvW2PG3NpQbXsZnSuicsY=.11025c50-0217-4920-8cca-bad785d26aa6@github.com>

On Wed, 10 Mar 2021 02:16:17 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> David Holmes 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 10 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8262910-sync-traps
>>  - Updated request_deflate_idle_monitors as it can only be called by a JavaThread via WhiteBox API
>>  - Fix typo
>>  - Fixed up BiasedLocking code in ObjectSynchronizer::enter
>>  - iFixed alignment in macro
>>  - More pointer declaration style fixups
>>  - ObjectMonitor::exit can't actually throw IMSE so replaced TRAPS with JavaThread* current
>>  - Style fix: Thread *  -> Thread* in type declarations
>>  - Forgot to updated Graal config for JVMCI structs change
>>  - 8262910: Cleanup THREAD/TRAPS/naming and typing issues in ObjectMonitor and related code
>
> Marked as reviewed by dcubed (Reviewer).

Thank you for explanations, David.
I did not insist the `deflate_idle_monitors` has to be changed just wanted to double-check if there is any need.

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

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

From vsharma at openjdk.java.net  Wed Mar 10 03:48:29 2021
From: vsharma at openjdk.java.net (Vipin Sharma)
Date: Wed, 10 Mar 2021 03:48:29 GMT
Subject: RFR: JDK-8261095: Add test for clhsdb "symbol" command [v3]
In-Reply-To: <vvBz34jYNl1w-989imPpF7K5U-3GYAzTTXGLqV2-2BU=.71fc7da5-36a3-48ba-ba2e-2100f90d1941@github.com>
References: <vvBz34jYNl1w-989imPpF7K5U-3GYAzTTXGLqV2-2BU=.71fc7da5-36a3-48ba-ba2e-2100f90d1941@github.com>
Message-ID: <eF84MMg_yCaCUOHePKUs5wrHKw227BJRBc_PSODnirw=.254e69f7-aef8-489f-b92b-052d4a5689a4@github.com>

> JDK-8261095: Add test for clhsdb "symbol" command

Vipin Sharma has updated the pull request incrementally with one additional commit since the last revision:

  Started using orElseThrow and removed null check following this

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2863/files
  - new: https://git.openjdk.java.net/jdk/pull/2863/files/9d914d35..f7d50bd4

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

  Stats: 9 lines in 1 file changed: 1 ins; 5 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2863.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2863/head:pull/2863

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

From cjplummer at openjdk.java.net  Wed Mar 10 04:36:14 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 10 Mar 2021 04:36:14 GMT
Subject: RFR: JDK-8261095: Add test for clhsdb "symbol" command [v3]
In-Reply-To: <eF84MMg_yCaCUOHePKUs5wrHKw227BJRBc_PSODnirw=.254e69f7-aef8-489f-b92b-052d4a5689a4@github.com>
References: <vvBz34jYNl1w-989imPpF7K5U-3GYAzTTXGLqV2-2BU=.71fc7da5-36a3-48ba-ba2e-2100f90d1941@github.com>
 <eF84MMg_yCaCUOHePKUs5wrHKw227BJRBc_PSODnirw=.254e69f7-aef8-489f-b92b-052d4a5689a4@github.com>
Message-ID: <fCt4DwQs1Gv8VNzMx6x7K1q8FACILQlBSdLy3yCmGtU=.26870cb2-b76c-46c6-8e96-59864f5aba55@github.com>

On Wed, 10 Mar 2021 03:48:29 GMT, Vipin Sharma <vsharma at openjdk.org> wrote:

>> JDK-8261095: Add test for clhsdb "symbol" command
>
> Vipin Sharma has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Started using orElseThrow and removed null check following this

I didn't realize that `lines()` returns a `Stream`. TBH I find the original code a lot easier to read than the `Stream` code, but that's pretty much always my opinion when I see `Stream` code. Others will probably feel your new version is more elegant, so I won't protest.

Having said that, I also just learned that `String.split("\R")` will properly split the lines with any newline character sequence. See [Pattern](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/regex/Pattern.html):
`\R    Any Unicode linebreak sequence \u000D\u000A|[\u000A\u000B\u000C\u000D\u0085\u2028\u2029] `

test/hotspot/jtreg/serviceability/sa/ClhsdbSymbol.java line 68:

> 66:                                                       .map(addresses -> addresses[1])
> 67:                                                       .orElseThrow(() -> new RuntimeException("Cannot find address of " +
> 68:                                                               "the InstanceKlass for java.lang.Thread in output"));

These lines really don't format well, a reason why the previous `orElse()` version is probably better. Maybe you can make this work by moving the `.filter()` call to a new line that is indented 8 more than the previous line

test/hotspot/jtreg/serviceability/sa/ClhsdbSymbol.java line 71:

> 69: 
> 70: 
> 71:             // Use "inspect" on the thread address we extracted in previous step

"in `the` previous step"

test/hotspot/jtreg/serviceability/sa/ClhsdbSymbol.java line 79:

> 77: 
> 78:             // The inspect command output will have one line of output that looks like the following.
> 79:             // Symbol* Klass::_name: Symbol @ 0x0000000800471120

Indent this line of the comment

test/hotspot/jtreg/serviceability/sa/ClhsdbSymbol.java line 87:

> 85:                                                                 "Cannot find address with Symbol instance"));
> 86: 
> 87:             // Run "symbol" command on the Symbol instance address extracted in previous step.

"in `the` previous step"

test/hotspot/jtreg/serviceability/sa/ClhsdbSymbol.java line 85:

> 83:                                                         .findFirst().map(symbolParts -> symbolParts[1])
> 84:                                                         .orElseThrow(() -> new RuntimeException(
> 85:                                                                 "Cannot find address with Symbol instance"));

Same issue with formatting as above.

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

Changes requested by cjplummer (Reviewer).

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

From iklam at openjdk.java.net  Wed Mar 10 04:42:09 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 10 Mar 2021 04:42:09 GMT
Subject: RFR: 8259070: Add jcmd option to dump CDS [v3]
In-Reply-To: <UQ6gbZhxZ-5W1HkjA_XO2RnuEI1U-scC_iJRPD2Mrb4=.99793b9d-3cd6-4fbe-ad98-f418ccbc6f3a@github.com>
References: <hwrc1zAz8G180ToL-C3EuUIF-5R17F5Gm1zcPMBpOtE=.e002a377-e0e2-485b-a08e-b63675a9746b@github.com>
 <UQ6gbZhxZ-5W1HkjA_XO2RnuEI1U-scC_iJRPD2Mrb4=.99793b9d-3cd6-4fbe-ad98-f418ccbc6f3a@github.com>
Message-ID: <B-g8YZqbJMfAFPZvGpllxvOfoohFeI6MzeNdpEhOCvk=.dbdc6f3e-db3f-419b-8dc1-1ecc155b43a8@github.com>

On Tue, 9 Mar 2021 21:50:25 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Hi, Please review
>> 
>>   Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with
>>   `java -XX:DumpLoadedClassList=<classlist> .... `  
>>  to collect shareable class names and saved in file `<classlist>` , then 
>>   `java -Xshare:dump -XX:SharedClassListFile=<classlist> -XX:SharedArchiveFile=<archivefile> ...`
>>   With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime  to dump an archive.
>>    The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved.
>>    New added jcmd option:
>>    `jcmd <pid or AppName> VM.cds static_dump <filename>`
>>    or
>>     `jcmd <pid or AppName> VM.cds dynamic_dump <filename>`
>>   To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. 
>>    The file name is optional, if the file name is not supplied, the file name will take format of `java_pid<number>_static.jsa` or `java_pid<number>_dynamic.jsa` for static and dynamic respectively. The `<number>` is the application process ID.
>> 
>>   Tests: tier1,tier2,tier3,tier4
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix white space in CDS.java

Changes requested by iklam (Reviewer).

src/hotspot/share/services/diagnosticCommand.cpp line 1124:

> 1122:   }
> 1123:   Symbol* cds_name  = vmSymbols::jdk_internal_misc_CDS();
> 1124:   Klass*  cds_klass = SystemDictionary::resolve_or_null(cds_name, THREAD);

Should be `cds_klass = SystemDictionary::resolve_or_fail(cds_name, CHECK);`

src/java.base/share/classes/jdk/internal/misc/CDS.java line 278:

> 276:             dumpDynamicArchive(archiveFile);
> 277:         }
> 278:     }

I think we should have some error checks and clean up:

- Remove the classlist file
- Check if if the process exit status is 0
- Remove the JSA file first, then try to dump it, and check if the file exists afterwards. If not, report the error. (For both dynamic and static dumps)

src/java.base/share/classes/jdk/internal/misc/CDS.java line 256:

> 254: 
> 255:             // Do not take parent env which will cause dumping fail.
> 256:             Process proc = Runtime.getRuntime().exec(cmds.toArray(new String[0]),

Could you explain why the parent's env variables will cause dumping to fail?

src/java.base/share/classes/jdk/internal/misc/CDS.java line 213:

> 211:               testStr.contains("-XX:+DynamicDumpSharedSpaces") ||
> 212:               testStr.contains("-XX:+RecordDynamicDumpInfo");
> 213:     }

The following flags should also be excluded:

- -XX:-DumpSharedSpaces
- -Xshare:
- -XX:SharedClassListFile=
- -XX:SharedArchiveFile=
- -XX:ArchiveClassesAtExit=
- -XX:+UseSharedSpaces
- -XX:+RequireSharedSpaces

We also need to have a few test cases when the LingeredApp is started with these flags.

src/java.base/share/classes/jdk/internal/misc/CDS.java line 262:

> 260:                 String line;
> 261:                 InputStreamReader isr = new InputStreamReader(proc.getInputStream());
> 262:                 BufferedReader rdr = new BufferedReader(isr);

Also, I think the output should always be logged. Otherwise if an error happens, it's very difficult for the user to diagnose (and they won't know about the "CDS.Debug" property).

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

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

From vsharma at openjdk.java.net  Wed Mar 10 04:52:08 2021
From: vsharma at openjdk.java.net (Vipin Sharma)
Date: Wed, 10 Mar 2021 04:52:08 GMT
Subject: RFR: JDK-8261095: Add test for clhsdb "symbol" command [v3]
In-Reply-To: <fCt4DwQs1Gv8VNzMx6x7K1q8FACILQlBSdLy3yCmGtU=.26870cb2-b76c-46c6-8e96-59864f5aba55@github.com>
References: <vvBz34jYNl1w-989imPpF7K5U-3GYAzTTXGLqV2-2BU=.71fc7da5-36a3-48ba-ba2e-2100f90d1941@github.com>
 <eF84MMg_yCaCUOHePKUs5wrHKw227BJRBc_PSODnirw=.254e69f7-aef8-489f-b92b-052d4a5689a4@github.com>
 <fCt4DwQs1Gv8VNzMx6x7K1q8FACILQlBSdLy3yCmGtU=.26870cb2-b76c-46c6-8e96-59864f5aba55@github.com>
Message-ID: <2bLTXeGWIZsZgniGAlCvKskXZoMhNZEjud1-gbXU9Hc=.0cf986b4-1b1e-40a6-b4a4-7d4ffec3fb93@github.com>

On Wed, 10 Mar 2021 04:30:57 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Vipin Sharma has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Started using orElseThrow and removed null check following this
>
> test/hotspot/jtreg/serviceability/sa/ClhsdbSymbol.java line 68:
> 
>> 66:                                                       .map(addresses -> addresses[1])
>> 67:                                                       .orElseThrow(() -> new RuntimeException("Cannot find address of " +
>> 68:                                                               "the InstanceKlass for java.lang.Thread in output"));
> 
> These lines really don't format well, a reason why the previous `orElse()` version is probably better. Maybe you can make this work by moving the `.filter()` call to a new line that is indented 8 more than the previous line

After moving the filter to the next line also can not fit this in one line.
In addition to the filter, moving all characters starting from "new RuntimeException(...." also goes till 126 char.
Following is one suggestion, does it look good?

String threadAddress = classOutput.lines()
        .filter(part -> part.startsWith("java/lang/Thread"))
        .map(part -> part.split(" @"))
        .findFirst()
        .map(addresses -> addresses[1])
        .orElseThrow(() -> new RuntimeException(
                "Cannot find address of the InstanceKlass for java.lang.Thread in output"));

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

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

From vsharma at openjdk.java.net  Wed Mar 10 04:57:30 2021
From: vsharma at openjdk.java.net (Vipin Sharma)
Date: Wed, 10 Mar 2021 04:57:30 GMT
Subject: RFR: JDK-8261095: Add test for clhsdb "symbol" command [v4]
In-Reply-To: <vvBz34jYNl1w-989imPpF7K5U-3GYAzTTXGLqV2-2BU=.71fc7da5-36a3-48ba-ba2e-2100f90d1941@github.com>
References: <vvBz34jYNl1w-989imPpF7K5U-3GYAzTTXGLqV2-2BU=.71fc7da5-36a3-48ba-ba2e-2100f90d1941@github.com>
Message-ID: <7VIwh6yddLuXHnizourNZL9SV1LGqbW673atXHo43S4=.49d73aee-61b5-4e6a-a4e7-4a201211212f@github.com>

> JDK-8261095: Add test for clhsdb "symbol" command

Vipin Sharma has updated the pull request incrementally with one additional commit since the last revision:

  Moving filter call to next line for better formatting

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2863/files
  - new: https://git.openjdk.java.net/jdk/pull/2863/files/f7d50bd4..2a516c2b

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

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

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

From vsharma at openjdk.java.net  Wed Mar 10 04:57:31 2021
From: vsharma at openjdk.java.net (Vipin Sharma)
Date: Wed, 10 Mar 2021 04:57:31 GMT
Subject: RFR: JDK-8261095: Add test for clhsdb "symbol" command [v3]
In-Reply-To: <2bLTXeGWIZsZgniGAlCvKskXZoMhNZEjud1-gbXU9Hc=.0cf986b4-1b1e-40a6-b4a4-7d4ffec3fb93@github.com>
References: <vvBz34jYNl1w-989imPpF7K5U-3GYAzTTXGLqV2-2BU=.71fc7da5-36a3-48ba-ba2e-2100f90d1941@github.com>
 <eF84MMg_yCaCUOHePKUs5wrHKw227BJRBc_PSODnirw=.254e69f7-aef8-489f-b92b-052d4a5689a4@github.com>
 <fCt4DwQs1Gv8VNzMx6x7K1q8FACILQlBSdLy3yCmGtU=.26870cb2-b76c-46c6-8e96-59864f5aba55@github.com>
 <2bLTXeGWIZsZgniGAlCvKskXZoMhNZEjud1-gbXU9Hc=.0cf986b4-1b1e-40a6-b4a4-7d4ffec3fb93@github.com>
Message-ID: <niy9z9MmRjmMIzIAFmKYA5H7Dz4vdpmaUt6Nu3Rs3Rk=.fb859d1f-7648-4b8e-a79c-baa2dbd17a6b@github.com>

On Wed, 10 Mar 2021 04:49:27 GMT, Vipin Sharma <vsharma at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/sa/ClhsdbSymbol.java line 68:
>> 
>>> 66:                                                       .map(addresses -> addresses[1])
>>> 67:                                                       .orElseThrow(() -> new RuntimeException("Cannot find address of " +
>>> 68:                                                               "the InstanceKlass for java.lang.Thread in output"));
>> 
>> These lines really don't format well, a reason why the previous `orElse()` version is probably better. Maybe you can make this work by moving the `.filter()` call to a new line that is indented 8 more than the previous line
>
> After moving the filter to the next line also can not fit this in one line.
> In addition to the filter, moving all characters starting from "new RuntimeException(...." also goes till 126 char.
> Following is one suggestion, does it look good?
> 
> String threadAddress = classOutput.lines()
>         .filter(part -> part.startsWith("java/lang/Thread"))
>         .map(part -> part.split(" @"))
>         .findFirst()
>         .map(addresses -> addresses[1])
>         .orElseThrow(() -> new RuntimeException(
>                 "Cannot find address of the InstanceKlass for java.lang.Thread in output"));

Formatting in my comment is not clear, so I have added one new commit for this.

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

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

From vsharma at openjdk.java.net  Wed Mar 10 05:11:30 2021
From: vsharma at openjdk.java.net (Vipin Sharma)
Date: Wed, 10 Mar 2021 05:11:30 GMT
Subject: RFR: JDK-8261095: Add test for clhsdb "symbol" command [v5]
In-Reply-To: <vvBz34jYNl1w-989imPpF7K5U-3GYAzTTXGLqV2-2BU=.71fc7da5-36a3-48ba-ba2e-2100f90d1941@github.com>
References: <vvBz34jYNl1w-989imPpF7K5U-3GYAzTTXGLqV2-2BU=.71fc7da5-36a3-48ba-ba2e-2100f90d1941@github.com>
Message-ID: <k7f4nhGID78v-mM0t-B4T9jm5TfzWqGti6syAFcIuYY=.4017d209-f363-48e3-a45b-e3c090f3e4ec@github.com>

> JDK-8261095: Add test for clhsdb "symbol" command

Vipin Sharma has updated the pull request incrementally with one additional commit since the last revision:

  Updated formatting and grammer changes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2863/files
  - new: https://git.openjdk.java.net/jdk/pull/2863/files/2a516c2b..c977ed1d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2863&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2863&range=03-04

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

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

From cjplummer at openjdk.java.net  Wed Mar 10 05:20:07 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 10 Mar 2021 05:20:07 GMT
Subject: RFR: JDK-8261095: Add test for clhsdb "symbol" command [v5]
In-Reply-To: <k7f4nhGID78v-mM0t-B4T9jm5TfzWqGti6syAFcIuYY=.4017d209-f363-48e3-a45b-e3c090f3e4ec@github.com>
References: <vvBz34jYNl1w-989imPpF7K5U-3GYAzTTXGLqV2-2BU=.71fc7da5-36a3-48ba-ba2e-2100f90d1941@github.com>
 <k7f4nhGID78v-mM0t-B4T9jm5TfzWqGti6syAFcIuYY=.4017d209-f363-48e3-a45b-e3c090f3e4ec@github.com>
Message-ID: <usrq8vCCX7fcPSzPMUSdIdewCPn1WSraNBo2Bg8nxak=.8103ccfa-925b-4965-939c-8b7f59b9e686@github.com>

On Wed, 10 Mar 2021 05:11:30 GMT, Vipin Sharma <vsharma at openjdk.org> wrote:

>> JDK-8261095: Add test for clhsdb "symbol" command
>
> Vipin Sharma has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated formatting and grammer changes

Marked as reviewed by cjplummer (Reviewer).

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

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

From cjplummer at openjdk.java.net  Wed Mar 10 05:20:08 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 10 Mar 2021 05:20:08 GMT
Subject: RFR: JDK-8261095: Add test for clhsdb "symbol" command [v3]
In-Reply-To: <niy9z9MmRjmMIzIAFmKYA5H7Dz4vdpmaUt6Nu3Rs3Rk=.fb859d1f-7648-4b8e-a79c-baa2dbd17a6b@github.com>
References: <vvBz34jYNl1w-989imPpF7K5U-3GYAzTTXGLqV2-2BU=.71fc7da5-36a3-48ba-ba2e-2100f90d1941@github.com>
 <eF84MMg_yCaCUOHePKUs5wrHKw227BJRBc_PSODnirw=.254e69f7-aef8-489f-b92b-052d4a5689a4@github.com>
 <fCt4DwQs1Gv8VNzMx6x7K1q8FACILQlBSdLy3yCmGtU=.26870cb2-b76c-46c6-8e96-59864f5aba55@github.com>
 <2bLTXeGWIZsZgniGAlCvKskXZoMhNZEjud1-gbXU9Hc=.0cf986b4-1b1e-40a6-b4a4-7d4ffec3fb93@github.com>
 <niy9z9MmRjmMIzIAFmKYA5H7Dz4vdpmaUt6Nu3Rs3Rk=.fb859d1f-7648-4b8e-a79c-baa2dbd17a6b@github.com>
Message-ID: <IXW4MUOQLpy4oOLFrMRwBmOpdvFnepx7dB_J-zff9as=.00cf7540-8c7f-469a-adfc-be24b5652997@github.com>

On Wed, 10 Mar 2021 04:54:03 GMT, Vipin Sharma <vsharma at openjdk.org> wrote:

>> After moving the filter to the next line also can not fit this in one line.
>> In addition to the filter, moving all characters starting from "new RuntimeException(...." also goes till 126 char.
>> Following is one suggestion, does it look good?
>> 
>> String threadAddress = classOutput.lines()
>>         .filter(part -> part.startsWith("java/lang/Thread"))
>>         .map(part -> part.split(" @"))
>>         .findFirst()
>>         .map(addresses -> addresses[1])
>>         .orElseThrow(() -> new RuntimeException(
>>                 "Cannot find address of the InstanceKlass for java.lang.Thread in output"));
>
> Formatting in my comment is not clear, so I have added one new commit for this.

Formatting looked fine in the email. Try putting it in a code block to prevent the auto formatting being done on it.

Latest webrev looks good.

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

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

From cjplummer at openjdk.java.net  Wed Mar 10 05:25:19 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 10 Mar 2021 05:25:19 GMT
Subject: RFR: 8263326: Remove ReceiverTypeData check from
 serviceability/sa/TestPrintMdo.java
Message-ID: <nxs5_MwI8XEYOLNqPN-EUCRs94Nwo6K4dHgn0TM-sMo=.baf3b490-3d8f-4796-9468-6ef49299adef@github.com>

See CR for a description of why this change is needed.

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

Commit messages:
 - Don't check for ReceiverTypeData in the printmdo output.

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

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

From ysuenaga at openjdk.java.net  Wed Mar 10 06:07:08 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 10 Mar 2021 06:07:08 GMT
Subject: RFR: JDK-8261095: Add test for clhsdb "symbol" command [v5]
In-Reply-To: <k7f4nhGID78v-mM0t-B4T9jm5TfzWqGti6syAFcIuYY=.4017d209-f363-48e3-a45b-e3c090f3e4ec@github.com>
References: <vvBz34jYNl1w-989imPpF7K5U-3GYAzTTXGLqV2-2BU=.71fc7da5-36a3-48ba-ba2e-2100f90d1941@github.com>
 <k7f4nhGID78v-mM0t-B4T9jm5TfzWqGti6syAFcIuYY=.4017d209-f363-48e3-a45b-e3c090f3e4ec@github.com>
Message-ID: <Pyw3-OnIZfHT6c2eXxsbPOar4KFY_X93WaIW1cKZgz0=.e58e4ecc-feea-495b-9755-3dab6537fc6f@github.com>

On Wed, 10 Mar 2021 05:11:30 GMT, Vipin Sharma <vsharma at openjdk.org> wrote:

>> JDK-8261095: Add test for clhsdb "symbol" command
>
> Vipin Sharma has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated formatting and grammer changes

Marked as reviewed by ysuenaga (Reviewer).

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

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

From lzang at openjdk.java.net  Wed Mar 10 09:41:21 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 10 Mar 2021 09:41:21 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v13]
In-Reply-To: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
Message-ID: <5P7_HEiPQT5u9elB2S-xWzsFn-InsPPAWsb2-re38jg=.c725a88c-b4c6-4802-b9a6-65bdf62791ca@github.com>

> 8252842: Extend jmap to support parallel heap dump

Lin Zang has updated the pull request incrementally with one additional commit since the last revision:

  reduce memory consumption and fix memory leak issue

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2261/files
  - new: https://git.openjdk.java.net/jdk/pull/2261/files/6789ba29..d636a140

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=11-12

  Stats: 200 lines in 2 files changed: 159 ins; 14 del; 27 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2261.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2261/head:pull/2261

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

From lzang at openjdk.java.net  Wed Mar 10 09:58:29 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 10 Mar 2021 09:58:29 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v14]
In-Reply-To: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
Message-ID: <0nlry3eA6RqWE-w1L_TQVLntJXJKMn7rCYPpLvx5aHI=.15073046-45ac-4ae0-b8ea-348730636c40@github.com>

> 8252842: Extend jmap to support parallel heap dump

Lin Zang has updated the pull request incrementally with one additional commit since the last revision:

  fix trailing white space issue

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2261/files
  - new: https://git.openjdk.java.net/jdk/pull/2261/files/d636a140..1e583904

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=12-13

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

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

From ysuenaga at openjdk.java.net  Wed Mar 10 11:18:26 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 10 Mar 2021 11:18:26 GMT
Subject: RFR: 8263342: Add --connect option to jhsdb hsdb/clhsdb
Message-ID: <8P9wnEz8u2vWe__AzCvHn5WA12MV-psaP-2y7ZDbr0Q=.21b05c15-b33a-4577-8bb3-4b6b6498e456@github.com>

Most of subcommands in jhsdb supports to connect to debug server via `--connect` command line option, however `hsdb` and `clhsdb` do not accept it.

Both HSDB and CLHSDB support to connect to debug server, so they should have capability to do it via command line option.

I also filed [CSR for this issue](https://bugs.openjdk.java.net/browse/JDK-8263345). Please review it as well.

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

Commit messages:
 - 8263342: Add --connect option to jhsdb hsdb/clhsdb

Changes: https://git.openjdk.java.net/jdk/pull/2908/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2908&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263342
  Stats: 130 lines in 5 files changed: 114 ins; 4 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2908.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2908/head:pull/2908

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

From lzang at openjdk.java.net  Wed Mar 10 11:36:11 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 10 Mar 2021 11:36:11 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v10]
In-Reply-To: <MExJEiIs3e_zBbegggS5C4LSZBcPwDplOchJaztsWeg=.60fc0ca0-3958-4a89-af53-65c896b0c573@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <6l7TqqEmupdBa2J8b_NlWif5oVY2SGpu7iKeJMM97ic=.bf63c6e2-878d-4c2a-9a1e-336419c88b58@github.com>
 <CvuSjdeAKN93mwFqzHEya8ho-ONmC_TYAokqDeat3RQ=.ab576df3-1635-45d6-a72f-7aac0a55c34e@github.com>
 <ebrfA2bFIIPhcpZkO75uUvbJ3aMJFoHq_JR46AAEdfQ=.e3dee042-dff0-4b80-8cb0-5c9dae722be7@github.com>
 <HrPwAUu3BrXj3C5fPIjZD3xEO0n2fKoQywKfOiebc7o=.193f9f06-0025-4251-baef-4288aea793b1@github.com>
 <89stqatP7KevfaFqJiTJyoi1q9PdIjR9VpYrK4KzVLE=.120ae881-06b8-4f75-9d51-ff8ea05cac63@github.com>
 <W2I3fgh9yhgn7dm7PM491TkzQ-wbhe_hvqNdZqfW8wU=.7e2e1b13-9138-4c00-94e7-f500e9432c33@github.com>
 <MExJEiIs3e_zBbegggS5C4LSZBcPwDplOchJaztsWeg=.60fc0ca0-3958-4a89-af53-65c896b0c573@github.com>
Message-ID: <yQM1ngC5wGvP2xr5TvcbZo4JtlF6QttL9owYSUQHEy4=.e14e3464-fa3e-4448-978c-721cf85875d3@github.com>

On Tue, 23 Feb 2021 08:51:15 GMT, Ralf Schmelter <rschmelter at openjdk.org> wrote:

>> Dear @plummercj, 
>> 
>> I have reconsidered the solution of ?dumpheapext?, IMHO maybe the name is too specific, for example, if in future there is more arguments for `-histo`, we have to made another command called "inspectheapext".
>>  
>> How about create a new command named (e.g.) "jmapext", and make the "dumpheapext" work as the subcommand and be passed to JVM as the 1st argument of "jmapext".  Then in future we don't bothering adding new command, just subcommand (or argument) like "inspectheapext". And hence there may be more easier to extend other commands? 
>> 
>> What do you think? 
>> 
>> BRs,
>> Lin
>
> Hi @linzang
> 
> 
>> This data are really interest to me, it seems using gzipped dump is faster than unzipped dump, is the because of disk writing or something else? I would investigate more about it~
> 
> I would guess that is the case. In the compressed case we write about 800 MB per second, that is as fast as my SSD goes.
> 
> Here are some actual results I've gotten (uncompressed):
> 
>     jmap.exe -dump:file=ser.hprof,all 30600 
>     Dumping heap to ser.hprof ...
>     Heap dump file created [32009882362 bytes in 59.303 secs]
> 
>     jmap.exe -dump:file=par1.hprof,parallel=1,all 30600
>     Dumping heap to par1.hprof ...
>     Heap dump file created [32009885809 bytes in 72.719 secs]
> 
>     jmap.exe -dump:file=par2.hprof,parallel=2,all 30600
>     Dumping heap to par2.hprof ...
>     Heap dump file created [32009881876 bytes in 57.546 secs]
> 
>     jmap.exe -dump:file=par4.hprof,parallel=4,all 30600
>     Dumping heap to par4.hprof ...
>     Heap dump file created [32009882956 bytes in 44.301 secs]
> 
>     jmap.exe -dump:file=par5.hprof,parallel=5,all 30600
>     Dumping heap to par5.hprof ...
>     Heap dump file created [32009882164 bytes in 40.282 secs]
> 
>     jmap.exe -dump:file=par6.hprof,parallel=6,all 30600
>     Dumping heap to par6.hprof ...
>     Heap dump file created [32009881156 bytes in 45.988 secs]
> 
> And here for the compressed case:
> 
>     jmap.exe -dump:file=par1.hprof.gz,parallel=1,all,gz=1 52372
>     Dumping heap to par1.hprof.gz ...
>     Heap dump file created [8076994216 bytes in 54.057 secs]
> 
>     jmap.exe -dump:file=par2.hprof.gz,parallel=2,all,gz=1 52372
>     Dumping heap to par2.hprof.gz ...
>     Heap dump file created [8075859421 bytes in 43.442 secs]
> 
>     jmap.exe -dump:file=par4.hprof.gz,parallel=4,all,gz=1 52372
>     Dumping heap to par4.hprof.gz ...
>     Heap dump file created [8075886152 bytes in 28.710 secs]
> 
>     jmap.exe -dump:file=par6.hprof.gz,parallel=6,all,gz=1 52372
>     Dumping heap to par6.hprof.gz ...
>     Heap dump file created [8075758374 bytes in 25.730 secs]
> 
>     jmap.exe -dump:file=par8.hprof.gz,parallel=8,all,gz=1 52372
>     Dumping heap to par8.hprof.gz ...
>     Heap dump file created [8075652558 bytes in 26.039 secs]
> 
>     jmap.exe -dump:file=par16.hprof.gz,parallel=16,all,gz=1 52372
>     Dumping heap to par16.hprof.gz ...
>     Heap dump file created [8075644423 bytes in 31.977 secs]
> 
>     jmap.exe -dump:file=par24.hprof.gz,parallel=24,all,gz=1 52372
>     Dumping heap to par24.hprof.gz ...
>     Heap dump file created [8075579546 bytes in 41.094 secs]
> 
> Best regards,
> Ralf

Dear Ralf @schmelter-sap, 
Sorry for late response, I got stuck in other work recently.
I have uploaded a new update that could help reduce memory consumption and also fix the assertion issue. 
I have verified it on my machine, May I ask your help to double check it on your side? 
Thanks!
Lin

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

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

From dcubed at openjdk.java.net  Wed Mar 10 16:12:34 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 10 Mar 2021 16:12:34 GMT
Subject: RFR: 8262881: port JVM/DI tests from JDK-4413752 to JVM/TI
In-Reply-To: <XOECrKnBcmSRjfY2cM-GqFs3jMr0fTy7KJUCUHZ0HGw=.54872a68-97e9-481a-871e-eade80a51604@github.com>
References: <XOECrKnBcmSRjfY2cM-GqFs3jMr0fTy7KJUCUHZ0HGw=.54872a68-97e9-481a-871e-eade80a51604@github.com>
Message-ID: <wxDl6BMQdQ7kxYPkWRwynFzdP18XZfXjUQsvrQ3XK5c=.bf08d32d-2bdc-440c-9bf6-6bd64fbf2411@github.com>

On Tue, 9 Mar 2021 21:08:54 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Add three tests from JDK-4413752 ported to JVM/TI:
> 
> - RawMonitorEnter() with SuspendThread()
>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithRawMonitorEnter/SuspendWithRawMonitorEnter.java
>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithRawMonitorEnter/libSuspendWithRawMonitorEnter.cpp
> 
> - ObjectMonitor enter() with SuspendThread()
>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorEnter/SuspendWithObjectMonitorEnter.java
>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorEnter/libSuspendWithObjectMonitorEnter.cpp
> 
> - ObjectMonitor wait() with SuspendThread
>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java
>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/libSuspendWithObjectMonitorWait.cpp
> 
> The Java files have a transaction diagram to show what each of the
> threads in the test is doing.

These new tests were exercised with Mach5 Tier[134567] testing.
They have also been tested on macOSX and Linux-X64 with the three
build configs running in parallel: fastdebug, release, slowdebug for
each of the three new tests for 6 hours. The results for macOS and
Linux-X64 are in the bug report.

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

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

From dcubed at openjdk.java.net  Wed Mar 10 16:12:34 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 10 Mar 2021 16:12:34 GMT
Subject: RFR: 8262881: port JVM/DI tests from JDK-4413752 to JVM/TI
Message-ID: <XOECrKnBcmSRjfY2cM-GqFs3jMr0fTy7KJUCUHZ0HGw=.54872a68-97e9-481a-871e-eade80a51604@github.com>

Add three tests from JDK-4413752 ported to JVM/TI:

- RawMonitorEnter() with SuspendThread()
  - test/hotspot/jtreg/serviceability/jvmti/SuspendWithRawMonitorEnter/SuspendWithRawMonitorEnter.java
  - test/hotspot/jtreg/serviceability/jvmti/SuspendWithRawMonitorEnter/libSuspendWithRawMonitorEnter.cpp

- ObjectMonitor enter() with SuspendThread()
  - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorEnter/SuspendWithObjectMonitorEnter.java
  - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorEnter/libSuspendWithObjectMonitorEnter.cpp

- ObjectMonitor wait() with SuspendThread
  - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java
  - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/libSuspendWithObjectMonitorWait.cpp

The Java files have a transaction diagram to show what each of the
threads in the test is doing.

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

Commit messages:
 - 8262881: port JVM/DI tests from JDK-4413752 to JVM/TI

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

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

From cjplummer at openjdk.java.net  Wed Mar 10 21:35:09 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 10 Mar 2021 21:35:09 GMT
Subject: RFR: 8263342: Add --connect option to jhsdb hsdb/clhsdb
In-Reply-To: <8P9wnEz8u2vWe__AzCvHn5WA12MV-psaP-2y7ZDbr0Q=.21b05c15-b33a-4577-8bb3-4b6b6498e456@github.com>
References: <8P9wnEz8u2vWe__AzCvHn5WA12MV-psaP-2y7ZDbr0Q=.21b05c15-b33a-4577-8bb3-4b6b6498e456@github.com>
Message-ID: <Rqea_tbDGSxrkwdiST6KV9JgR9D5CuwsfTTpXUPKVNg=.01fe23e2-4751-4a9e-bac0-33f1e86978d4@github.com>

On Wed, 10 Mar 2021 08:29:37 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> Most of subcommands in jhsdb supports to connect to debug server via `--connect` command line option, however `hsdb` and `clhsdb` do not accept it.
> 
> Both HSDB and CLHSDB support to connect to debug server, so they should have capability to do it via command line option.
> 
> I also filed [CSR for this issue](https://bugs.openjdk.java.net/browse/JDK-8263345). Please review it as well.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CLHSDB.java line 157:

> 155:             } catch (NumberFormatException e) {
> 156:                 // Attempt to connect to remote debug server
> 157:                 debugServerName = args[0];

I assume this change to no longer support just specifying an execPath is not exposed to the user, unless they are invoking the CLHSDB class directly from the command line.

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

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

From cjplummer at openjdk.java.net  Wed Mar 10 21:50:07 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 10 Mar 2021 21:50:07 GMT
Subject: RFR: 8263342: Add --connect option to jhsdb hsdb/clhsdb
In-Reply-To: <8P9wnEz8u2vWe__AzCvHn5WA12MV-psaP-2y7ZDbr0Q=.21b05c15-b33a-4577-8bb3-4b6b6498e456@github.com>
References: <8P9wnEz8u2vWe__AzCvHn5WA12MV-psaP-2y7ZDbr0Q=.21b05c15-b33a-4577-8bb3-4b6b6498e456@github.com>
Message-ID: <4qh-8tQoMmmS7lKi5DnxrMB0N0c1KM_HdrocMcfuzxs=.5a397ed1-c621-4c4a-9624-2bcb2bf89d87@github.com>

On Wed, 10 Mar 2021 08:29:37 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> Most of subcommands in jhsdb supports to connect to debug server via `--connect` command line option, however `hsdb` and `clhsdb` do not accept it.
> 
> Both HSDB and CLHSDB support to connect to debug server, so they should have capability to do it via command line option.
> 
> I also filed [CSR for this issue](https://bugs.openjdk.java.net/browse/JDK-8263345). Please review it as well.

test/hotspot/jtreg/serviceability/sa/sadebugd/ClhsdbAttachToDebugServerWithCommandLine.java line 43:

> 41:  */
> 42: 
> 43: public class ClhsdbAttachToDebugServerWithCommandLine {

The test name is rather long. Since this test is already in the sadebugd directory, you could shorten it to ClhsdbAttachWithCommandLine, although I'm not so sure I like it either. How about ClhsdbAttachWithConnect or ClhsdbAttachWithConnectArgument, or ClhsdbTestConnectArgument (I think I like the last one best)?

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

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

From dholmes at openjdk.java.net  Wed Mar 10 22:37:09 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 10 Mar 2021 22:37:09 GMT
Subject: Integrated: 8262910: Cleanup THREAD/TRAPS/naming and typing issues in
 ObjectMonitor and related code
In-Reply-To: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
References: <CNwXADekyVZV4gGwQ6DWRngHIPlepl8weFPLRAliuV4=.d59b6e79-683c-47ea-a75d-77d940f74327@github.com>
Message-ID: <ZQhSZ2I51fCb4iILep20nTC3F41z1hc-zfc6DB-Gj2g=.d7b330ed-22fc-48cb-b4cc-f5636f924480@github.com>

On Wed, 3 Mar 2021 05:15:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

> ObjectMonitors can only be used by JavaThreads (modulo some interactions with hashcodes and deflation) but we use "Thread*" almost everywhere mainly due to use of TRAPS (and TRAPS will itself use JavaThread once JDK-8252685 is done). Also some uses of TRAPS in the API's are wrong as, for example, monitor entry can never throw an exception.
> 
> So this cleanup tackles:
> - remove incorrect use of TRAPS
> - change "Thread*" to "JavaThread*" where applicable
> - don't use THREAD for things not related to exception processing
> - standardise the naming so that we have "JavaThread* current" rather a mix if Self/THREAD/jt etc.
> - remove unnecessary as_Java_thread() conversions
> - other misc cleanup I noticed in some functions
> 
> The cleanup is predominantly in objectMonitor.* and synchronizer.* but with a fan out to the users of those APIs. No attempt is made to cleanup the callers beyond ensuring we have a suitable JavaThread reference for the calls. 
> 
> Thanks,
> David

This pull request has now been integrated.

Changeset: c6d74bd9
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c6d74bd9
Stats:     535 lines in 18 files changed: 14 ins; 65 del; 456 mod

8262910: Cleanup THREAD/TRAPS/naming and typing issues in ObjectMonitor and related code

Reviewed-by: coleenp, pchilanomate, dcubed, cjplummer, sspitsyn

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

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

From amenkov at openjdk.java.net  Wed Mar 10 23:17:20 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 10 Mar 2021 23:17:20 GMT
Subject: RFR: 8262080:
 vmTestbase/nsk/jdi/Event/request/request001/TestDescription.java failed with
 "ERROR: new event is not ThreadStartEvent"
Message-ID: <JzsafYgSso5aYsPImTLCz52dN96s-BJbY3eMrHwxLRw=.9e781f40-5e59-425e-ab83-03872256cb9d@github.com>

The fix updates the test to skip ThreadStartEvent/ThreadDeathEvent from other threads

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

Commit messages:
 - skip system thread start/death

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

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

From cjplummer at openjdk.java.net  Wed Mar 10 23:41:08 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 10 Mar 2021 23:41:08 GMT
Subject: RFR: 8262080:
 vmTestbase/nsk/jdi/Event/request/request001/TestDescription.java failed with
 "ERROR: new event is not ThreadStartEvent"
In-Reply-To: <JzsafYgSso5aYsPImTLCz52dN96s-BJbY3eMrHwxLRw=.9e781f40-5e59-425e-ab83-03872256cb9d@github.com>
References: <JzsafYgSso5aYsPImTLCz52dN96s-BJbY3eMrHwxLRw=.9e781f40-5e59-425e-ab83-03872256cb9d@github.com>
Message-ID: <uC2WfufMgljGwIcx_wd7-pRABZMFYA-mSZVUtaC9tio=.878475fe-10fe-4328-a609-fa558d770f60@github.com>

On Wed, 10 Mar 2021 23:12:47 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates the test to skip ThreadStartEvent/ThreadDeathEvent from other threads

test/hotspot/jtreg/vmTestbase/nsk/share/jdi/JDIBase.java line 171:

> 169:     // Waiting for ThreadStart and ThreadDeath event we can get events from system threads,
> 170:     // so need to ensure we get the event from the desired thread.
> 171:     protected void waitThreadStart(String threadName) throws JDITestRuntimeException {

I think this API is misnamed. It's not just waiting for a ThreadStart for the specified thread. It's waiting for any event other than ThreadStart for some other thread or ThreadDeath for any thread. That's a bit of an odd combination, and certainly not obvious based on the method name and description.

test/hotspot/jtreg/vmTestbase/nsk/share/jdi/JDIBase.java line 185:

> 183:             }
> 184:             // log the event and wait for next one
> 185:             log2("Waiting for ThreadStartEvent, got " + event);

This message is misleading. It could in fact be a ThreadStart, but for some other thread other than the named thread. I think the code would be clearer if there was no fall-through case. Put this code in an else, but also include a different message as part of the else for the `if (evt.thread().name().equals(threadName))` section. Maybe say something like "...got ThreadStartEvent for wrong thread".

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

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

From ysuenaga at openjdk.java.net  Thu Mar 11 00:12:07 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 11 Mar 2021 00:12:07 GMT
Subject: RFR: 8263342: Add --connect option to jhsdb hsdb/clhsdb
In-Reply-To: <Rqea_tbDGSxrkwdiST6KV9JgR9D5CuwsfTTpXUPKVNg=.01fe23e2-4751-4a9e-bac0-33f1e86978d4@github.com>
References: <8P9wnEz8u2vWe__AzCvHn5WA12MV-psaP-2y7ZDbr0Q=.21b05c15-b33a-4577-8bb3-4b6b6498e456@github.com>
 <Rqea_tbDGSxrkwdiST6KV9JgR9D5CuwsfTTpXUPKVNg=.01fe23e2-4751-4a9e-bac0-33f1e86978d4@github.com>
Message-ID: <g_uJWGgTiP4T1oiF93P6YskG_3PwMW7wqiwohWuRUYE=.a413f508-0f2d-4c71-9ba1-029436714d22@github.com>

On Wed, 10 Mar 2021 21:32:44 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Most of subcommands in jhsdb supports to connect to debug server via `--connect` command line option, however `hsdb` and `clhsdb` do not accept it.
>> 
>> Both HSDB and CLHSDB support to connect to debug server, so they should have capability to do it via command line option.
>> 
>> I also filed [CSR for this issue](https://bugs.openjdk.java.net/browse/JDK-8263345). Please review it as well.
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CLHSDB.java line 157:
> 
>> 155:             } catch (NumberFormatException e) {
>> 156:                 // Attempt to connect to remote debug server
>> 157:                 debugServerName = args[0];
> 
> I assume this change to no longer support just specifying an execPath is not exposed to the user, unless they are invoking the CLHSDB class directly from the command line.

Yes, but this code would be run from `SALauncher::runCLHSDB`, so we need to change.
https://github.com/YaSuenag/jdk/blob/JDK-8263342/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/SALauncher.java#L282

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

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

From ysuenaga at openjdk.java.net  Thu Mar 11 00:20:35 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 11 Mar 2021 00:20:35 GMT
Subject: RFR: 8263342: Add --connect option to jhsdb hsdb/clhsdb [v2]
In-Reply-To: <8P9wnEz8u2vWe__AzCvHn5WA12MV-psaP-2y7ZDbr0Q=.21b05c15-b33a-4577-8bb3-4b6b6498e456@github.com>
References: <8P9wnEz8u2vWe__AzCvHn5WA12MV-psaP-2y7ZDbr0Q=.21b05c15-b33a-4577-8bb3-4b6b6498e456@github.com>
Message-ID: <QZ1vc_jKjLAdm9d-FuP43SwUC27uzy32ugiwnpphNgU=.b0f3a1bb-3b49-4621-aadf-ab5dfe75b654@github.com>

> Most of subcommands in jhsdb supports to connect to debug server via `--connect` command line option, however `hsdb` and `clhsdb` do not accept it.
> 
> Both HSDB and CLHSDB support to connect to debug server, so they should have capability to do it via command line option.
> 
> I also filed [CSR for this issue](https://bugs.openjdk.java.net/browse/JDK-8263345). Please review it as well.

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Update testcase name

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2908/files
  - new: https://git.openjdk.java.net/jdk/pull/2908/files/2afba98f..0a0c7895

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

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

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

From ysuenaga at openjdk.java.net  Thu Mar 11 00:20:36 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 11 Mar 2021 00:20:36 GMT
Subject: RFR: 8263342: Add --connect option to jhsdb hsdb/clhsdb [v2]
In-Reply-To: <4qh-8tQoMmmS7lKi5DnxrMB0N0c1KM_HdrocMcfuzxs=.5a397ed1-c621-4c4a-9624-2bcb2bf89d87@github.com>
References: <8P9wnEz8u2vWe__AzCvHn5WA12MV-psaP-2y7ZDbr0Q=.21b05c15-b33a-4577-8bb3-4b6b6498e456@github.com>
 <4qh-8tQoMmmS7lKi5DnxrMB0N0c1KM_HdrocMcfuzxs=.5a397ed1-c621-4c4a-9624-2bcb2bf89d87@github.com>
Message-ID: <DhfXhDpQScdMgy20ZcOrbpaP6-049-2jx-ZrKtlfvNk=.d3fac835-fad1-4bfc-9c6f-ead88d82406b@github.com>

On Wed, 10 Mar 2021 21:46:50 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update testcase name
>
> test/hotspot/jtreg/serviceability/sa/sadebugd/ClhsdbAttachToDebugServerWithCommandLine.java line 43:
> 
>> 41:  */
>> 42: 
>> 43: public class ClhsdbAttachToDebugServerWithCommandLine {
> 
> The test name is rather long. Since this test is already in the sadebugd directory, you could shorten it to ClhsdbAttachWithCommandLine, although I'm not so sure I like it either. How about ClhsdbAttachWithConnect or ClhsdbAttachWithConnectArgument, or ClhsdbTestConnectArgument (I think I like the last one best)?

I renamed to `ClhsdbTestConnectArgument` in new commit.

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

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

From cjplummer at openjdk.java.net  Thu Mar 11 00:36:07 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 11 Mar 2021 00:36:07 GMT
Subject: RFR: 8263342: Add --connect option to jhsdb hsdb/clhsdb [v2]
In-Reply-To: <g_uJWGgTiP4T1oiF93P6YskG_3PwMW7wqiwohWuRUYE=.a413f508-0f2d-4c71-9ba1-029436714d22@github.com>
References: <8P9wnEz8u2vWe__AzCvHn5WA12MV-psaP-2y7ZDbr0Q=.21b05c15-b33a-4577-8bb3-4b6b6498e456@github.com>
 <Rqea_tbDGSxrkwdiST6KV9JgR9D5CuwsfTTpXUPKVNg=.01fe23e2-4751-4a9e-bac0-33f1e86978d4@github.com>
 <g_uJWGgTiP4T1oiF93P6YskG_3PwMW7wqiwohWuRUYE=.a413f508-0f2d-4c71-9ba1-029436714d22@github.com>
Message-ID: <N7B_cymikCfomGLtuz9PV4jVyzIZ1aE5PAsKKTBMgi8=.114d58da-c387-40ae-aa67-5df1a519c5cf@github.com>

On Thu, 11 Mar 2021 00:08:55 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CLHSDB.java line 157:
>> 
>>> 155:             } catch (NumberFormatException e) {
>>> 156:                 // Attempt to connect to remote debug server
>>> 157:                 debugServerName = args[0];
>> 
>> I assume this change to no longer support just specifying an execPath is not exposed to the user, unless they are invoking the CLHSDB class directly from the command line.
>
> Yes, but this code would be run from `SALauncher::runCLHSDB`, so we need to change.
> https://github.com/YaSuenag/jdk/blob/JDK-8263342/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/SALauncher.java#L282

Yes, I understood that part. I just wanted to make sure, for example, that we weren't previously supporting something like `attach <exe_path>` in clhsdb, and that would be impacted by this, but I'm pretty sure clhsdb already prevents doing that. However, what if you used `jshdb <cmd> --exe` and don't specify a core file. Did that ever work, and if so will it still work?

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

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

From ysuenaga at openjdk.java.net  Thu Mar 11 01:22:08 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 11 Mar 2021 01:22:08 GMT
Subject: RFR: 8263342: Add --connect option to jhsdb hsdb/clhsdb [v2]
In-Reply-To: <N7B_cymikCfomGLtuz9PV4jVyzIZ1aE5PAsKKTBMgi8=.114d58da-c387-40ae-aa67-5df1a519c5cf@github.com>
References: <8P9wnEz8u2vWe__AzCvHn5WA12MV-psaP-2y7ZDbr0Q=.21b05c15-b33a-4577-8bb3-4b6b6498e456@github.com>
 <Rqea_tbDGSxrkwdiST6KV9JgR9D5CuwsfTTpXUPKVNg=.01fe23e2-4751-4a9e-bac0-33f1e86978d4@github.com>
 <g_uJWGgTiP4T1oiF93P6YskG_3PwMW7wqiwohWuRUYE=.a413f508-0f2d-4c71-9ba1-029436714d22@github.com>
 <N7B_cymikCfomGLtuz9PV4jVyzIZ1aE5PAsKKTBMgi8=.114d58da-c387-40ae-aa67-5df1a519c5cf@github.com>
Message-ID: <YsOskYBcT5HWdWnCaFC1-2Yz5d-4i0tMxQoXWAFm3vg=.836df800-dbe2-44b9-9502-f10f304b4cef@github.com>

On Thu, 11 Mar 2021 00:33:46 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Yes, I understood that part. I just wanted to make sure, for example, that we weren't previously supporting something like attach <exe_path> in clhsdb, and that would be impacted by this, but I'm pretty sure clhsdb already prevents doing that.

It would check at `SALauncher::buildAttachArgs` https://github.com/openjdk/jdk/blob/32cbd193d9655825d10e07be50ab3b7550ecb401/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/SALauncher.java#L202-L213

> However, what if you used jshdb <cmd> --exe and don't specify a core file. Did that ever work, and if so will it still work?

Due to above code snippets, we can see the usage on the console in JDK 15 as following, and it is same behavior after this change.

$ jhsdb clhsdb --exe /java
You have to set --core.
    --pid <pid>             To attach to and operate on the given live process.
    --core <corefile>       To operate on the given core file.
    --exe <executable for corefile>

    The --core and --exe options must be set together to give the core
    file, and associated executable, to operate on. They can use
    absolute or relative paths.
    The --pid option can be set to operate on a live process.
    --core and --pid are mutually exclusive.

    Examples: jhsdb clhsdb --pid 1234
          or  jhsdb clhsdb --core ./core.1234 --exe ./myexe

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

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

From cjplummer at openjdk.java.net  Thu Mar 11 03:14:07 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 11 Mar 2021 03:14:07 GMT
Subject: RFR: 8263342: Add --connect option to jhsdb hsdb/clhsdb [v2]
In-Reply-To: <QZ1vc_jKjLAdm9d-FuP43SwUC27uzy32ugiwnpphNgU=.b0f3a1bb-3b49-4621-aadf-ab5dfe75b654@github.com>
References: <8P9wnEz8u2vWe__AzCvHn5WA12MV-psaP-2y7ZDbr0Q=.21b05c15-b33a-4577-8bb3-4b6b6498e456@github.com>
 <QZ1vc_jKjLAdm9d-FuP43SwUC27uzy32ugiwnpphNgU=.b0f3a1bb-3b49-4621-aadf-ab5dfe75b654@github.com>
Message-ID: <QdBCJWVSgvrvLdXM17Qdes9ZLd-kJZkKx4AOVo5hTUE=.3abec670-10d2-44ab-9977-ceb78d856895@github.com>

On Thu, 11 Mar 2021 00:20:35 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Most of subcommands in jhsdb supports to connect to debug server via `--connect` command line option, however `hsdb` and `clhsdb` do not accept it.
>> 
>> Both HSDB and CLHSDB support to connect to debug server, so they should have capability to do it via command line option.
>> 
>> I also filed [CSR for this issue](https://bugs.openjdk.java.net/browse/JDK-8263345). Please review it as well.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update testcase name

Marked as reviewed by cjplummer (Reviewer).

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

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

From minqi at openjdk.java.net  Thu Mar 11 04:03:29 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 11 Mar 2021 04:03:29 GMT
Subject: RFR: 8259070: Add jcmd option to dump CDS [v4]
In-Reply-To: <hwrc1zAz8G180ToL-C3EuUIF-5R17F5Gm1zcPMBpOtE=.e002a377-e0e2-485b-a08e-b63675a9746b@github.com>
References: <hwrc1zAz8G180ToL-C3EuUIF-5R17F5Gm1zcPMBpOtE=.e002a377-e0e2-485b-a08e-b63675a9746b@github.com>
Message-ID: <9EU_DwWh3XcyBxJkxgPH1qzvbaa2hvWQYuccdRXWKj0=.c6816df0-6e73-45bc-9e52-caa70b0611fd@github.com>

> Hi, Please review
> 
>   Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with
>   `java -XX:DumpLoadedClassList=<classlist> .... `  
>  to collect shareable class names and saved in file `<classlist>` , then 
>   `java -Xshare:dump -XX:SharedClassListFile=<classlist> -XX:SharedArchiveFile=<archivefile> ...`
>   With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime  to dump an archive.
>    The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved.
>    New added jcmd option:
>    `jcmd <pid or AppName> VM.cds static_dump <filename>`
>    or
>     `jcmd <pid or AppName> VM.cds dynamic_dump <filename>`
>   To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. 
>    The file name is optional, if the file name is not supplied, the file name will take format of `java_pid<number>_static.jsa` or `java_pid<number>_dynamic.jsa` for static and dynamic respectively. The `<number>` is the application process ID.
> 
>   Tests: tier1,tier2,tier3,tier4
> 
> Thanks
> Yumin

Yumin Qi 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 filter more flags to exclude in static dump, add more test cases
 - Merge branch 'master' into jdk-8259070
 - Fix white space in CDS.java
 - Add function CDS.dumpSharedArchive in java to dump shared archive
 - 8259070: Add jcmd option to dump CDS

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2737/files
  - new: https://git.openjdk.java.net/jdk/pull/2737/files/bfa71577..a9010f8f

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

  Stats: 13690 lines in 458 files changed: 7913 ins; 3760 del; 2017 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2737.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2737/head:pull/2737

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

From minqi at openjdk.java.net  Thu Mar 11 04:16:11 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 11 Mar 2021 04:16:11 GMT
Subject: RFR: 8259070: Add jcmd option to dump CDS [v3]
In-Reply-To: <B-g8YZqbJMfAFPZvGpllxvOfoohFeI6MzeNdpEhOCvk=.dbdc6f3e-db3f-419b-8dc1-1ecc155b43a8@github.com>
References: <hwrc1zAz8G180ToL-C3EuUIF-5R17F5Gm1zcPMBpOtE=.e002a377-e0e2-485b-a08e-b63675a9746b@github.com>
 <UQ6gbZhxZ-5W1HkjA_XO2RnuEI1U-scC_iJRPD2Mrb4=.99793b9d-3cd6-4fbe-ad98-f418ccbc6f3a@github.com>
 <B-g8YZqbJMfAFPZvGpllxvOfoohFeI6MzeNdpEhOCvk=.dbdc6f3e-db3f-419b-8dc1-1ecc155b43a8@github.com>
Message-ID: <Q-srtC9xi8xEUkwYNY16p4LMOBzt09GLnIBJI5Z1xP0=.9a310895-94f5-4d77-99f1-a8003e01c38e@github.com>

On Wed, 10 Mar 2021 04:18:29 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix white space in CDS.java
>
> src/hotspot/share/services/diagnosticCommand.cpp line 1124:
> 
>> 1122:   }
>> 1123:   Symbol* cds_name  = vmSymbols::jdk_internal_misc_CDS();
>> 1124:   Klass*  cds_klass = SystemDictionary::resolve_or_null(cds_name, THREAD);
> 
> Should be `cds_klass = SystemDictionary::resolve_or_fail(cds_name, CHECK);`

Changed to use resolve_or_fail.

> src/java.base/share/classes/jdk/internal/misc/CDS.java line 213:
> 
>> 211:               testStr.contains("-XX:+DynamicDumpSharedSpaces") ||
>> 212:               testStr.contains("-XX:+RecordDynamicDumpInfo");
>> 213:     }
> 
> The following flags should also be excluded:
> 
> - -XX:-DumpSharedSpaces
> - -Xshare:
> - -XX:SharedClassListFile=
> - -XX:SharedArchiveFile=
> - -XX:ArchiveClassesAtExit=
> - -XX:+UseSharedSpaces
> - -XX:+RequireSharedSpaces
> 
> We also need to have a few test cases when the LingeredApp is started with these flags.

Added String[] for those flags to check.

> src/java.base/share/classes/jdk/internal/misc/CDS.java line 262:
> 
>> 260:                 String line;
>> 261:                 InputStreamReader isr = new InputStreamReader(proc.getInputStream());
>> 262:                 BufferedReader rdr = new BufferedReader(isr);
> 
> Also, I think the output should always be logged. Otherwise if an error happens, it's very difficult for the user to diagnose (and they won't know about the "CDS.Debug" property).

Yes, done with separate thread.

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

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

From lzang at openjdk.java.net  Thu Mar 11 06:34:19 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 11 Mar 2021 06:34:19 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v15]
In-Reply-To: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
Message-ID: <EcdYWj5KCJQzn25fVlrWspjUQlyvabDbD5jWVi5A4bs=.e0ef469f-9ea1-4e7a-a8b3-be94faca0818@github.com>

> 8252842: Extend jmap to support parallel heap dump

Lin Zang has updated the pull request incrementally with one additional commit since the last revision:

  code clean

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2261/files
  - new: https://git.openjdk.java.net/jdk/pull/2261/files/1e583904..370e4413

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=14
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=13-14

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

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

From coleenp at openjdk.java.net  Thu Mar 11 13:38:07 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 11 Mar 2021 13:38:07 GMT
Subject: RFR: 8263434: Dangling references after
 MethodComparator::methods_EMCP
In-Reply-To: <asxiOdUujvGXb5SvzrRSkAuVcrHz9xTFpwFZ90uJQaM=.f7576bd6-d4ba-4b7a-960f-f8e79ce6c54c@github.com>
References: <asxiOdUujvGXb5SvzrRSkAuVcrHz9xTFpwFZ90uJQaM=.f7576bd6-d4ba-4b7a-960f-f8e79ce6c54c@github.com>
Message-ID: <redUGUUMk9ONtuALYLJLq4vLjLvFzMJEj9ZRTbyTXxE=.b6700116-7175-41e5-a349-4c3abb97f3d0@github.com>

On Thu, 11 Mar 2021 11:02:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports the following problem in MethodComparator::methods_EMCP:
>  "Address of stack memory associated with local variable 's_new' is still referred to by the global variable '_s_new' upon returning to the caller. This will be a dangling reference"
> 
> Code inspection reveals the assignment to static variables is only needed to pass them to helper methods. So, while this is not a detectable bug (yet), it is still cleaner not to expose stack variables in globals.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `tier1`
>  - [x] Linux x86_64 fastdebug, `vmTestbase_nsk_jvmti`

This is much cleaner! Thank you, and thank you SonarCloud.

src/hotspot/share/prims/methodComparator.cpp line 262:

> 260: }
> 261: 
> 262: bool MethodComparator::pool_constants_same(int cpi_old, int cpi_new, ConstantPool* old_cp, ConstantPool* new_cp) {

Can these be const?

src/hotspot/share/prims/methodComparator.cpp line 67:

> 65: bool MethodComparator::args_same(Bytecodes::Code c_old, Bytecodes::Code c_new,
> 66:                                  BytecodeStream* s_old, BytecodeStream* s_new,
> 67:                                  ConstantPool* old_cp,  ConstantPool* new_cp) {

Can these be const pointers too?

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

Marked as reviewed by coleenp (Reviewer).

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

From shade at openjdk.java.net  Thu Mar 11 13:50:24 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 11 Mar 2021 13:50:24 GMT
Subject: RFR: 8263434: Dangling references after
 MethodComparator::methods_EMCP [v2]
In-Reply-To: <asxiOdUujvGXb5SvzrRSkAuVcrHz9xTFpwFZ90uJQaM=.f7576bd6-d4ba-4b7a-960f-f8e79ce6c54c@github.com>
References: <asxiOdUujvGXb5SvzrRSkAuVcrHz9xTFpwFZ90uJQaM=.f7576bd6-d4ba-4b7a-960f-f8e79ce6c54c@github.com>
Message-ID: <I9RUUM_wFM3jWorc7zw0OwllHhfuqVabLVdjnKyyZZo=.5cb9bded-ca33-4bf2-ae55-92cf006966b9@github.com>

> SonarCloud reports the following problem in MethodComparator::methods_EMCP:
>  "Address of stack memory associated with local variable 's_new' is still referred to by the global variable '_s_new' upon returning to the caller. This will be a dangling reference"
> 
> Code inspection reveals the assignment to static variables is only needed to pass them to helper methods. So, while this is not a detectable bug (yet), it is still cleaner not to expose stack variables in globals.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `tier1`
>  - [x] Linux x86_64 fastdebug, `vmTestbase_nsk_jvmti`

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Sprinkling consts

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2937/files
  - new: https://git.openjdk.java.net/jdk/pull/2937/files/9a43dca1..5acc4807

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

  Stats: 13 lines in 2 files changed: 3 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2937.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2937/head:pull/2937

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

From shade at openjdk.java.net  Thu Mar 11 13:50:25 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 11 Mar 2021 13:50:25 GMT
Subject: RFR: 8263434: Dangling references after
 MethodComparator::methods_EMCP [v2]
In-Reply-To: <redUGUUMk9ONtuALYLJLq4vLjLvFzMJEj9ZRTbyTXxE=.b6700116-7175-41e5-a349-4c3abb97f3d0@github.com>
References: <asxiOdUujvGXb5SvzrRSkAuVcrHz9xTFpwFZ90uJQaM=.f7576bd6-d4ba-4b7a-960f-f8e79ce6c54c@github.com>
 <redUGUUMk9ONtuALYLJLq4vLjLvFzMJEj9ZRTbyTXxE=.b6700116-7175-41e5-a349-4c3abb97f3d0@github.com>
Message-ID: <So0c8m7ivPubuvPOVPnB1irhk6KXoVS16K-HigpeMOs=.adb9367a-5e88-482a-acda-a448e02f9031@github.com>

On Thu, 11 Mar 2021 13:33:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Sprinkling consts
>
> src/hotspot/share/prims/methodComparator.cpp line 67:
> 
>> 65: bool MethodComparator::args_same(Bytecodes::Code c_old, Bytecodes::Code c_new,
>> 66:                                  BytecodeStream* s_old, BytecodeStream* s_new,
>> 67:                                  ConstantPool* old_cp,  ConstantPool* new_cp) {
> 
> Can these be const pointers too?

Yes, they can. Sprinkled.

> src/hotspot/share/prims/methodComparator.cpp line 262:
> 
>> 260: }
>> 261: 
>> 262: bool MethodComparator::pool_constants_same(int cpi_old, int cpi_new, ConstantPool* old_cp, ConstantPool* new_cp) {
> 
> Can these be const?

Yes, they can. Sprinkled.

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

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

From akozlov at openjdk.java.net  Thu Mar 11 14:07:44 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 11 Mar 2021 14:07:44 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v23]
In-Reply-To: <SaFPzYzpXuZFUYhDvGg6PQHM-EUrSqbR02H5SzL6OvI=.77d3186b-74a5-404a-950f-95af6a13dabd@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <ciwAT0uB2sME-WzcDx96ipa1QHDFCeru1pO847cdBrY=.a7f895c7-e7ed-45ce-babd-c9ba2f955dda@github.com>
 <sL7Ru9rbNmfzeX-14ZZdvyVzmjIn3R-NCZypqjU5Amk=.7a077954-920c-46f0-bae2-b646e9b1b6ae@github.com>
 <SaFPzYzpXuZFUYhDvGg6PQHM-EUrSqbR02H5SzL6OvI=.77d3186b-74a5-404a-950f-95af6a13dabd@github.com>
Message-ID: <5oHOwsaj5Jpg7ukRTFk7MG--w0_bq2qSwH6FN0WOZNY=.e519c482-ba19-4e24-955d-07743ab92359@github.com>

On Wed, 3 Mar 2021 15:57:13 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 207:
>> 
>>> 205:   // Enable WXWrite: this function is called by the signal handler at arbitrary
>>> 206:   // point of execution.
>>> 207:   ThreadWXEnable wx(WXWrite, thread);
>> 
>> Note that `thread` can be NULL here if the signal handler is running in a non-attached thread. If we then perform:
>> `ThreadWXEnable(WXMode new_mode, Thread* thread = NULL) :
>>     _thread(thread ? thread : Thread::current()),`
>> we call Thread::current() on a non-attached thread and that will assert/crash if we get NULL. Either avoid using WX when the thread is NULL, or else change to use Thread::current_or_null_safe() and ensure all uses have a NULL check.
>
>> Note that `thread` can be NULL here if the signal handler is running in a non-attached thread. If we then perform:
>> `ThreadWXEnable(WXMode new_mode, Thread* thread = NULL) : _thread(thread ? thread : Thread::current()),`
>> we call Thread::current() on a non-attached thread and that will assert/crash if we get NULL. Either avoid using WX when the thread is NULL, or else change to use Thread::current_or_null_safe() and ensure all uses have a NULL check.
> 
> https://bugs.openjdk.java.net/browse/JDK-8262903 tracks this issue.

Thanks for report and analysis! I fixed this in https://github.com/openjdk/jdk/pull/2200/commits/f6fb01b24f525e578692a1c6f2ff0a55b8233576

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

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

From akozlov at openjdk.java.net  Thu Mar 11 14:07:43 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 11 Mar 2021 14:07:43 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v25]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <f8RkGXsdhtld9TcoCNLInUUxZpFYleWuR5VIl3CqVs0=.1776f22d-a62b-4f8d-8fc6-0a43b8353e1c@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  8262903: [macos_aarch64] Thread::current() called on detached thread

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/a72f6834..f6fb01b2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=24
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=23-24

  Stats: 13 lines in 5 files changed: 3 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

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

From dcubed at openjdk.java.net  Thu Mar 11 15:24:08 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 11 Mar 2021 15:24:08 GMT
Subject: RFR: 8263434: Dangling references after
 MethodComparator::methods_EMCP [v2]
In-Reply-To: <redUGUUMk9ONtuALYLJLq4vLjLvFzMJEj9ZRTbyTXxE=.b6700116-7175-41e5-a349-4c3abb97f3d0@github.com>
References: <asxiOdUujvGXb5SvzrRSkAuVcrHz9xTFpwFZ90uJQaM=.f7576bd6-d4ba-4b7a-960f-f8e79ce6c54c@github.com>
 <redUGUUMk9ONtuALYLJLq4vLjLvFzMJEj9ZRTbyTXxE=.b6700116-7175-41e5-a349-4c3abb97f3d0@github.com>
Message-ID: <dfNpKMrdy5aFtr5mS6_BtIRQp6xSSOsVhqZPiCFjgRw=.5e0f6bf1-3d01-46d0-a745-32c3d57accd4@github.com>

On Thu, 11 Mar 2021 13:35:20 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Sprinkling consts
>
> This is much cleaner! Thank you, and thank you SonarCloud.

Please make sure that you get a review from someone on the Serviceability team.

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

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

From iignatyev at openjdk.java.net  Thu Mar 11 20:22:28 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 11 Mar 2021 20:22:28 GMT
Subject: RFR: 8263412: ClassFileInstaller can't be used by classes outside of
 default package
Message-ID: <UHCEvPvTuTw75Lwzs763iCkp0I-2YnwOCt3V7yZxvPk=.a15d9bf6-1385-46d8-889f-a227e0d2f9e2@github.com>

Hi all,

could you please review the patch which moves `ClassFileInstaller` class to `jdk.test.lib.helpers` package? 
to reduce changes in the tests, `ClassFileInstaller` in the default package is kept w/ just `main` method that calls  `jdk.test.lib.helpers. ClassFileInstaller::main`. 

from JBS:
> ClassFileInstaller is in the default package hence it's impossible to use it directly by classes in any other package. although ClassFileInstaller is mainly used directly from jtreg test description, there are cases when one needs to use it in another "driver" class (e.g. to reduce boilerplate), yet to do. that these driver classes have to either be in a default package or use reflection, both approaches have drawbacks. 
> 
> to solve that, we can move ClassFileInstaller implementation to a package, and to avoid unneeded churn, keep package-less ClassFileInstaller class which will call package-full impl.
>
> the need for this patch has raised as part of [JDK-8254129](https://bugs.openjdk.java.net/browse/JDK-8263412).

testing:
- [x] `:jdk_core` against `{macos,windows,linux}-x64`
- [x] `:jdk_svc` against `{macos,windows,linux}-x64`
- [x] `test/hotspot/jtreg` w/o `applications` and `vmTestbase` directories against `{macos,windows,linux}-x64`

Thanks,
-- Igor

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

Commit messages:
 - make ClassFileInstaller.Manifest::from* public
 - updated copyright years
 - import j.t.l.helpers.ClassFileInstaller
 - added jdk/test/lib/helpers/ClassFileInstaller

Changes: https://git.openjdk.java.net/jdk/pull/2932/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2932&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263412
  Stats: 473 lines in 114 files changed: 145 ins; 229 del; 99 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2932.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2932/head:pull/2932

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

From amenkov at openjdk.java.net  Thu Mar 11 20:25:27 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 11 Mar 2021 20:25:27 GMT
Subject: RFR: 8262080:
 vmTestbase/nsk/jdi/Event/request/request001/TestDescription.java failed with
 "ERROR: new event is not ThreadStartEvent" [v2]
In-Reply-To: <JzsafYgSso5aYsPImTLCz52dN96s-BJbY3eMrHwxLRw=.9e781f40-5e59-425e-ab83-03872256cb9d@github.com>
References: <JzsafYgSso5aYsPImTLCz52dN96s-BJbY3eMrHwxLRw=.9e781f40-5e59-425e-ab83-03872256cb9d@github.com>
Message-ID: <9eM4SqwQ4EJUspwE0yrGtYTE9Ed9cJVN6rpqgN0VZvE=.1745435e-b6a7-41ed-baa5-4d6f5f938f28@github.com>

> The fix updates the test to skip ThreadStartEvent/ThreadDeathEvent from other threads

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  Reworked the fix accordingly feedback

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2927/files
  - new: https://git.openjdk.java.net/jdk/pull/2927/files/7d665c88..ff05f525

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

  Stats: 62 lines in 2 files changed: 18 ins; 28 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2927.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2927/head:pull/2927

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

From amenkov at openjdk.java.net  Thu Mar 11 20:25:28 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 11 Mar 2021 20:25:28 GMT
Subject: RFR: 8262080:
 vmTestbase/nsk/jdi/Event/request/request001/TestDescription.java failed with
 "ERROR: new event is not ThreadStartEvent" [v2]
In-Reply-To: <uC2WfufMgljGwIcx_wd7-pRABZMFYA-mSZVUtaC9tio=.878475fe-10fe-4328-a609-fa558d770f60@github.com>
References: <JzsafYgSso5aYsPImTLCz52dN96s-BJbY3eMrHwxLRw=.9e781f40-5e59-425e-ab83-03872256cb9d@github.com>
 <uC2WfufMgljGwIcx_wd7-pRABZMFYA-mSZVUtaC9tio=.878475fe-10fe-4328-a609-fa558d770f60@github.com>
Message-ID: <cDTQABIYQIYi4NaQyFk7QWpDBnXu5i2zI28u0pbnIAI=.301b0e72-05ef-4bde-bbf7-083a4d38bec7@github.com>

On Wed, 10 Mar 2021 23:31:08 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reworked the fix accordingly feedback
>
> test/hotspot/jtreg/vmTestbase/nsk/share/jdi/JDIBase.java line 171:
> 
>> 169:     // Waiting for ThreadStart and ThreadDeath event we can get events from system threads,
>> 170:     // so need to ensure we get the event from the desired thread.
>> 171:     protected void waitThreadStart(String threadName) throws JDITestRuntimeException {
> 
> I think this API is misnamed. It's not just waiting for a ThreadStart for the specified thread. It's waiting for any event other than ThreadStart for some other thread or ThreadDeath for any thread. That's a bit of an odd combination, and certainly not obvious based on the method name and description.

I reworked the fix. Hope now it's clearer.

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

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

From stefank at openjdk.java.net  Thu Mar 11 20:31:16 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Thu, 11 Mar 2021 20:31:16 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v25]
In-Reply-To: <f8RkGXsdhtld9TcoCNLInUUxZpFYleWuR5VIl3CqVs0=.1776f22d-a62b-4f8d-8fc6-0a43b8353e1c@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <f8RkGXsdhtld9TcoCNLInUUxZpFYleWuR5VIl3CqVs0=.1776f22d-a62b-4f8d-8fc6-0a43b8353e1c@github.com>
Message-ID: <gKoH7dS4tYmoRme7Wzbg1mH0ygHFKlaTQgS_JiIE_8A=.96b62223-ef50-43f5-9db1-d150e449e1b9@github.com>

On Thu, 11 Mar 2021 14:07:43 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8262903: [macos_aarch64] Thread::current() called on detached thread

Marked as reviewed by stefank (Reviewer).

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

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

From stefank at openjdk.java.net  Thu Mar 11 20:31:17 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Thu, 11 Mar 2021 20:31:17 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12]
In-Reply-To: <Dze4ZtrPI_OLkuExMIN1fl5u6eCryLmgNRgAHzN2kXE=.eee71cb4-1c81-46f8-b6ae-063659a28fc2@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <Vg27jHtpjAQ36mYoE5MyolUJUi8K9lSb_c3grH_DLvM=.df18633b-2124-44b0-ac51-e5405a3f745d@github.com>
 <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com>
 <Dze4ZtrPI_OLkuExMIN1fl5u6eCryLmgNRgAHzN2kXE=.eee71cb4-1c81-46f8-b6ae-063659a28fc2@github.com>
Message-ID: <3NYUmXmjyZFhGJwrHfEjSRX1VRaPjt5cCp9HRBxODbM=.4880b6d1-f6dd-45db-95f4-9064e9204d87@github.com>

On Tue, 9 Mar 2021 17:55:12 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> src/hotspot/share/runtime/thread.cpp line 2515:
>> 
>>> 2513: void JavaThread::check_special_condition_for_native_trans(JavaThread *thread) {
>>> 2514:   // Enable WXWrite: called directly from interpreter native wrapper.
>>> 2515:   MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXWrite, thread));
>> 
>> FWIW, I personally think that adding these MACOS_AARCH64_ONLY usages at the call sites increase the line-noise in the affected functions. I think I would have preferred a version:
>> ThreadWXEnable(WXMode new_mode, Thread* thread = NULL) {
>>   MACOS_AARCH64_ONLY(initialize(new_mode, thread);) {}
>> void initialize(...); // Implementation in thread_bsd_aarch64.cpp (alt. inline.hpp)
>> With that said, I'm fine with taking this discussion as a follow-up.
>
> The former version used no such macros. I like that now it's clear the W^X management is relevant to macos/aarch64 only. I see the point to move the pre-processor condition into the class implementation. But I think it will bring a bit of inconsistency, as the rest of W^X implementation is explicitly guarded by preprocessor conditionals. I've also tried to push macro conditionals as far as possible down to implementation, providing a kind of generalized W^X interface. That required a few artificial decisions, e.g. how would we call the mode we execute on the rest of platforms with write and execute allowed, WXWriteExec?.. I abandoned that attempt.

I think we would use the same names, but I haven't given it more thought. I might take a look at this after this has been integrated.

>> src/hotspot/share/runtime/thread.hpp line 848:
>> 
>>> 846:   void init_wx();
>>> 847:   WXMode enable_wx(WXMode new_state);
>>> 848: #endif // __APPLE__ && AARCH64
>> 
>> Now that this is only compiled into macOS/AArch64, could this be moved over to thread_bsd_aarch64.hpp? The same goes for the associated functions.
>
> The thread_bsd_aarch64.hpp describes a part of JavaThread, while this block belongs to Thread for now. Since W^X is an attribute of any operating system thread, I assumed Thread to be the right place for W^X bookkeeping. 
> 
> In most cases, we manage W^X state of JavaThread. But sometimes a GC thread needs the WXWrite state, or safefetch is called from non-JavaThread. Probably this can be dealt with (e.g. GCThread to always have the WXWrite state). But such change would be much more than a simple refactoring and it would require a significant amount of testing. Ideally, I would like to investigate this as a follow-up change, or at least after other fixes to this PR.

Good point about Thread vs JavaThread. Yes, this can be looked into as follow-up cleanups.

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

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

From iklam at openjdk.java.net  Thu Mar 11 20:58:07 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 11 Mar 2021 20:58:07 GMT
Subject: RFR: 8263412: ClassFileInstaller can't be used by classes outside
 of default package
In-Reply-To: <UHCEvPvTuTw75Lwzs763iCkp0I-2YnwOCt3V7yZxvPk=.a15d9bf6-1385-46d8-889f-a227e0d2f9e2@github.com>
References: <UHCEvPvTuTw75Lwzs763iCkp0I-2YnwOCt3V7yZxvPk=.a15d9bf6-1385-46d8-889f-a227e0d2f9e2@github.com>
Message-ID: <7P0MS1asoKJMsIEgliuJvza7mcz1z7aBeeF9RKccIK4=.d1dbefa1-3b4b-4adf-bf2e-24f7c61161cb@github.com>

On Thu, 11 Mar 2021 05:47:00 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review the patch which moves `ClassFileInstaller` class to `jdk.test.lib.helpers` package? 
> to reduce changes in the tests, `ClassFileInstaller` in the default package is kept w/ just `main` method that calls  `jdk.test.lib.helpers. ClassFileInstaller::main`. 
> 
> from JBS:
>> ClassFileInstaller is in the default package hence it's impossible to use it directly by classes in any other package. although ClassFileInstaller is mainly used directly from jtreg test description, there are cases when one needs to use it in another "driver" class (e.g. to reduce boilerplate), yet to do. that these driver classes have to either be in a default package or use reflection, both approaches have drawbacks. 
>> 
>> to solve that, we can move ClassFileInstaller implementation to a package, and to avoid unneeded churn, keep package-less ClassFileInstaller class which will call package-full impl.
>>
>> the need for this patch has raised as part of [JDK-8254129](https://bugs.openjdk.java.net/browse/JDK-8254129).
> 
> testing:
> - [x] `:jdk_core` against `{macos,windows,linux}-x64`
> - [x] `:jdk_svc` against `{macos,windows,linux}-x64`
> - [x] `test/hotspot/jtreg` w/o `applications` and `vmTestbase` directories against `{macos,windows,linux}-x64`
> 
> Thanks,
> -- Igor

The CDS test changes look good to me. It seems they are just adding a single line of import.

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

Marked as reviewed by iklam (Reviewer).

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

From coleenp at openjdk.java.net  Thu Mar 11 21:18:11 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 11 Mar 2021 21:18:11 GMT
Subject: RFR: 8263412: ClassFileInstaller can't be used by classes outside
 of default package
In-Reply-To: <UHCEvPvTuTw75Lwzs763iCkp0I-2YnwOCt3V7yZxvPk=.a15d9bf6-1385-46d8-889f-a227e0d2f9e2@github.com>
References: <UHCEvPvTuTw75Lwzs763iCkp0I-2YnwOCt3V7yZxvPk=.a15d9bf6-1385-46d8-889f-a227e0d2f9e2@github.com>
Message-ID: <D6kPlFFpjPlIKs2GeLZp2s6TSRitoXbzJvIfPuuyQb0=.c19ad48f-5613-46d6-ad29-59c8f55957ea@github.com>

On Thu, 11 Mar 2021 05:47:00 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review the patch which moves `ClassFileInstaller` class to `jdk.test.lib.helpers` package? 
> to reduce changes in the tests, `ClassFileInstaller` in the default package is kept w/ just `main` method that calls  `jdk.test.lib.helpers. ClassFileInstaller::main`. 
> 
> from JBS:
>> ClassFileInstaller is in the default package hence it's impossible to use it directly by classes in any other package. although ClassFileInstaller is mainly used directly from jtreg test description, there are cases when one needs to use it in another "driver" class (e.g. to reduce boilerplate), yet to do. that these driver classes have to either be in a default package or use reflection, both approaches have drawbacks. 
>> 
>> to solve that, we can move ClassFileInstaller implementation to a package, and to avoid unneeded churn, keep package-less ClassFileInstaller class which will call package-full impl.
>>
>> the need for this patch has raised as part of [JDK-8254129](https://bugs.openjdk.java.net/browse/JDK-8254129).
> 
> testing:
> - [x] `:jdk_core` against `{macos,windows,linux}-x64`
> - [x] `:jdk_svc` against `{macos,windows,linux}-x64`
> - [x] `test/hotspot/jtreg` w/o `applications` and `vmTestbase` directories against `{macos,windows,linux}-x64`
> 
> Thanks,
> -- Igor

Looks good.  I looked at the RedefineClasses tests also.

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

Marked as reviewed by coleenp (Reviewer).

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

From amenkov at openjdk.java.net  Thu Mar 11 21:20:31 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 11 Mar 2021 21:20:31 GMT
Subject: RFR: 8262080:
 vmTestbase/nsk/jdi/Event/request/request001/TestDescription.java failed with
 "ERROR: new event is not ThreadStartEvent" [v3]
In-Reply-To: <JzsafYgSso5aYsPImTLCz52dN96s-BJbY3eMrHwxLRw=.9e781f40-5e59-425e-ab83-03872256cb9d@github.com>
References: <JzsafYgSso5aYsPImTLCz52dN96s-BJbY3eMrHwxLRw=.9e781f40-5e59-425e-ab83-03872256cb9d@github.com>
Message-ID: <kR4sfF3krjjl6nSo-H4Z3agy199OoxPO_jKYMr49fco=.a5865625-0870-495b-a533-06b5e2c87aad@github.com>

> The fix updates the test to skip ThreadStartEvent/ThreadDeathEvent from other threads

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  used pattern matching for instanceof to simplify the code

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2927/files
  - new: https://git.openjdk.java.net/jdk/pull/2927/files/ff05f525..76808342

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

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

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

From amenkov at openjdk.java.net  Thu Mar 11 22:22:05 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 11 Mar 2021 22:22:05 GMT
Subject: RFR: 8263055: hsdb Command Line Debugger does not properly direct
 output for some commands
In-Reply-To: <pGwJVLHvj0BILLgV5TFOZoqdhx1JXVVda0fNVS4GZg4=.4f79539f-ee86-4b05-a1b3-bcdeddfaf32a@github.com>
References: <pGwJVLHvj0BILLgV5TFOZoqdhx1JXVVda0fNVS4GZg4=.4f79539f-ee86-4b05-a1b3-bcdeddfaf32a@github.com>
Message-ID: <btbPzjKvWl_zAsRQZ2GnTkXsEmaCHEhCqXFAR9wFVKw=.60e2fc37-7ffd-4e89-96d6-57aefb7f7101@github.com>

On Tue, 9 Mar 2021 04:52:57 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I ran the hsdb Command Line Debugger (Windows -> Console menu item) and tried the class and classes commands, and neither appeared to produce any output. Other commands seemed to work as expected. I then went back to the terminal window I used to launch hsdb, and notice all the output from class and classes commands went there instead. The reason is because these commands are using System.out.println instead of out.println. "out" is a PrintStream field of the CommandProcessor instance, and should be used for all output other than error output, which can use "err".
> 
> We have no test for this, but I did run the hsdb GUI, brought up the Command Line Debugger, and confirmed that `class` and `classes` now properly show the output there. We do have clhsdb tests that also exercise this CommandProcessor code, but clhsdb directs all the output to System.out, so `out.println` and `System.out.println` end up being the same, thus the issue was not noticed.

Marked as reviewed by amenkov (Reviewer).

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

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

From cjplummer at openjdk.java.net  Thu Mar 11 22:55:10 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 11 Mar 2021 22:55:10 GMT
Subject: RFR: 8262080:
 vmTestbase/nsk/jdi/Event/request/request001/TestDescription.java failed with
 "ERROR: new event is not ThreadStartEvent" [v3]
In-Reply-To: <kR4sfF3krjjl6nSo-H4Z3agy199OoxPO_jKYMr49fco=.a5865625-0870-495b-a533-06b5e2c87aad@github.com>
References: <JzsafYgSso5aYsPImTLCz52dN96s-BJbY3eMrHwxLRw=.9e781f40-5e59-425e-ab83-03872256cb9d@github.com>
 <kR4sfF3krjjl6nSo-H4Z3agy199OoxPO_jKYMr49fco=.a5865625-0870-495b-a533-06b5e2c87aad@github.com>
Message-ID: <yQxYZbuK0Btl8G4cAcJ5hajdAqPsvL2P_vQ1go98tNg=.e75ebdfa-b2ed-47b6-95e4-d8f36c6942a9@github.com>

On Thu, 11 Mar 2021 21:20:31 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates the test to skip ThreadStartEvent/ThreadDeathEvent from other threads
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   used pattern matching for instanceof to simplify the code

test/hotspot/jtreg/vmTestbase/nsk/share/jdi/JDIBase.java line 178:

> 176:             } else {
> 177:                 // not ThreadStartEvent nor ThreadDeathEvent
> 178:                 gotDesiredEvent = true;

Do you think it would be better if you only set `gotDesiredEvent = true` if the event came in on the named thread? If the event came in on another thread, it seems it should be ignored. If it came in on the named thread, then it is probably an error since the test is expecting ThreadStart or ThreadDeath, so in that case return and let the caller complain.

test/hotspot/jtreg/vmTestbase/nsk/share/jdi/JDIBase.java line 158:

> 156:     // When ThreadStartRequest and/or ThreadDeathRequest are enabled, we can get the events from system threads
> 157:     // unexpected for tests.
> 158:     // The method skips ThreadStartEvent/ThreadDeathEvent events for all threads except the expected one.

Can you clean up the line lengths so they are close to being even.

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

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

From amenkov at openjdk.java.net  Thu Mar 11 23:17:24 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 11 Mar 2021 23:17:24 GMT
Subject: RFR: 8262080:
 vmTestbase/nsk/jdi/Event/request/request001/TestDescription.java failed with
 "ERROR: new event is not ThreadStartEvent" [v4]
In-Reply-To: <JzsafYgSso5aYsPImTLCz52dN96s-BJbY3eMrHwxLRw=.9e781f40-5e59-425e-ab83-03872256cb9d@github.com>
References: <JzsafYgSso5aYsPImTLCz52dN96s-BJbY3eMrHwxLRw=.9e781f40-5e59-425e-ab83-03872256cb9d@github.com>
Message-ID: <sr-R0M5HETEwHsjowzDcTsQ3yeZIlwVyi0ew33tlPMc=.5d022524-1bc1-45f5-87d6-5a50cfbfd168@github.com>

> The fix updates the test to skip ThreadStartEvent/ThreadDeathEvent from other threads

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  reformatted comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2927/files
  - new: https://git.openjdk.java.net/jdk/pull/2927/files/76808342..e08321f1

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

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

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

From amenkov at openjdk.java.net  Thu Mar 11 23:17:25 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 11 Mar 2021 23:17:25 GMT
Subject: RFR: 8262080:
 vmTestbase/nsk/jdi/Event/request/request001/TestDescription.java failed with
 "ERROR: new event is not ThreadStartEvent" [v3]
In-Reply-To: <yQxYZbuK0Btl8G4cAcJ5hajdAqPsvL2P_vQ1go98tNg=.e75ebdfa-b2ed-47b6-95e4-d8f36c6942a9@github.com>
References: <JzsafYgSso5aYsPImTLCz52dN96s-BJbY3eMrHwxLRw=.9e781f40-5e59-425e-ab83-03872256cb9d@github.com>
 <kR4sfF3krjjl6nSo-H4Z3agy199OoxPO_jKYMr49fco=.a5865625-0870-495b-a533-06b5e2c87aad@github.com>
 <yQxYZbuK0Btl8G4cAcJ5hajdAqPsvL2P_vQ1go98tNg=.e75ebdfa-b2ed-47b6-95e4-d8f36c6942a9@github.com>
Message-ID: <nzspA2RM5iZogGsQ_auYW6HiFOE2kpbwJZQI0ew_XMo=.5ad24027-a19e-4ce9-917a-e67dc6ff2462@github.com>

On Thu, 11 Mar 2021 22:48:55 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   used pattern matching for instanceof to simplify the code
>
> test/hotspot/jtreg/vmTestbase/nsk/share/jdi/JDIBase.java line 178:
> 
>> 176:             } else {
>> 177:                 // not ThreadStartEvent nor ThreadDeathEvent
>> 178:                 gotDesiredEvent = true;
> 
> Do you think it would be better if you only set `gotDesiredEvent = true` if the event came in on the named thread? If the event came in on another thread, it seems it should be ignored. If it came in on the named thread, then it is probably an error since the test is expecting ThreadStart or ThreadDeath, so in that case return and let the caller complain.

Not sure I got the idea.
gotDesiredEvent is a flag to exit the cycle, so if the event is not ThreadStart/Death event, we set the flag, leave the cycle and return the event to the caller. In case of request001 test it's an error and the test will fail, but this is desired behaviour

> test/hotspot/jtreg/vmTestbase/nsk/share/jdi/JDIBase.java line 158:
> 
>> 156:     // When ThreadStartRequest and/or ThreadDeathRequest are enabled, we can get the events from system threads
>> 157:     // unexpected for tests.
>> 158:     // The method skips ThreadStartEvent/ThreadDeathEvent events for all threads except the expected one.
> 
> Can you clean up the line lengths so they are close to being even.

done

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

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

From ysuenaga at openjdk.java.net  Fri Mar 12 00:43:13 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Fri, 12 Mar 2021 00:43:13 GMT
Subject: RFR: 8263055: hsdb Command Line Debugger does not properly direct
 output for some commands
In-Reply-To: <pGwJVLHvj0BILLgV5TFOZoqdhx1JXVVda0fNVS4GZg4=.4f79539f-ee86-4b05-a1b3-bcdeddfaf32a@github.com>
References: <pGwJVLHvj0BILLgV5TFOZoqdhx1JXVVda0fNVS4GZg4=.4f79539f-ee86-4b05-a1b3-bcdeddfaf32a@github.com>
Message-ID: <k8XCW7xU1D5OJK6Ri2NDdIL3vXk4KRvV5nTpfSsTHMQ=.d4754003-d867-48f7-8788-a98827d90f99@github.com>

On Tue, 9 Mar 2021 04:52:57 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I ran the hsdb Command Line Debugger (Windows -> Console menu item) and tried the class and classes commands, and neither appeared to produce any output. Other commands seemed to work as expected. I then went back to the terminal window I used to launch hsdb, and notice all the output from class and classes commands went there instead. The reason is because these commands are using System.out.println instead of out.println. "out" is a PrintStream field of the CommandProcessor instance, and should be used for all output other than error output, which can use "err".
> 
> We have no test for this, but I did run the hsdb GUI, brought up the Command Line Debugger, and confirmed that `class` and `classes` now properly show the output there. We do have clhsdb tests that also exercise this CommandProcessor code, but clhsdb directs all the output to System.out, so `out.println` and `System.out.println` end up being the same, thus the issue was not noticed.

Marked as reviewed by ysuenaga (Reviewer).

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

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

From cjplummer at openjdk.java.net  Fri Mar 12 01:28:07 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 12 Mar 2021 01:28:07 GMT
Subject: RFR: 8262080:
 vmTestbase/nsk/jdi/Event/request/request001/TestDescription.java failed with
 "ERROR: new event is not ThreadStartEvent" [v4]
In-Reply-To: <sr-R0M5HETEwHsjowzDcTsQ3yeZIlwVyi0ew33tlPMc=.5d022524-1bc1-45f5-87d6-5a50cfbfd168@github.com>
References: <JzsafYgSso5aYsPImTLCz52dN96s-BJbY3eMrHwxLRw=.9e781f40-5e59-425e-ab83-03872256cb9d@github.com>
 <sr-R0M5HETEwHsjowzDcTsQ3yeZIlwVyi0ew33tlPMc=.5d022524-1bc1-45f5-87d6-5a50cfbfd168@github.com>
Message-ID: <cwi1v1CVebKi1yA2nQf2Hvjh4pfgZdKFn1AT7rPZeyY=.1108e240-d395-49a1-91c9-e76da2a3f2d2@github.com>

On Thu, 11 Mar 2021 23:17:24 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates the test to skip ThreadStartEvent/ThreadDeathEvent from other threads
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reformatted comment

Marked as reviewed by cjplummer (Reviewer).

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

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

From cjplummer at openjdk.java.net  Fri Mar 12 01:28:08 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 12 Mar 2021 01:28:08 GMT
Subject: RFR: 8262080:
 vmTestbase/nsk/jdi/Event/request/request001/TestDescription.java failed with
 "ERROR: new event is not ThreadStartEvent" [v3]
In-Reply-To: <nzspA2RM5iZogGsQ_auYW6HiFOE2kpbwJZQI0ew_XMo=.5ad24027-a19e-4ce9-917a-e67dc6ff2462@github.com>
References: <JzsafYgSso5aYsPImTLCz52dN96s-BJbY3eMrHwxLRw=.9e781f40-5e59-425e-ab83-03872256cb9d@github.com>
 <kR4sfF3krjjl6nSo-H4Z3agy199OoxPO_jKYMr49fco=.a5865625-0870-495b-a533-06b5e2c87aad@github.com>
 <yQxYZbuK0Btl8G4cAcJ5hajdAqPsvL2P_vQ1go98tNg=.e75ebdfa-b2ed-47b6-95e4-d8f36c6942a9@github.com>
 <nzspA2RM5iZogGsQ_auYW6HiFOE2kpbwJZQI0ew_XMo=.5ad24027-a19e-4ce9-917a-e67dc6ff2462@github.com>
Message-ID: <oWamHTWglDDcjH9NW_LrpCpV_uCpAGMvZLLFAYrc86E=.960f43a6-e12d-4146-b999-5f28feb785d7@github.com>

On Thu, 11 Mar 2021 23:07:49 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> test/hotspot/jtreg/vmTestbase/nsk/share/jdi/JDIBase.java line 178:
>> 
>>> 176:             } else {
>>> 177:                 // not ThreadStartEvent nor ThreadDeathEvent
>>> 178:                 gotDesiredEvent = true;
>> 
>> Do you think it would be better if you only set `gotDesiredEvent = true` if the event came in on the named thread? If the event came in on another thread, it seems it should be ignored. If it came in on the named thread, then it is probably an error since the test is expecting ThreadStart or ThreadDeath, so in that case return and let the caller complain.
>
> Not sure I got the idea.
> gotDesiredEvent is a flag to exit the cycle, so if the event is not ThreadStart/Death event, we set the flag, leave the cycle and return the event to the caller. In case of request001 test it's an error and the test will fail, but this is desired behaviour

The purpose is to ignore all events on other threads (not just ThreadStart and ThreadDeath) rather than let result in the test failing. However, I can see now that determining the thread of the event is not easy (lots of instanceOf checks of the event type and casts to the proper type), so probably this is not worth doing unless it proves necessary at some point.

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

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

From mseledtsov at openjdk.java.net  Fri Mar 12 02:11:07 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Fri, 12 Mar 2021 02:11:07 GMT
Subject: RFR: 8263412: ClassFileInstaller can't be used by classes outside
 of default package
In-Reply-To: <UHCEvPvTuTw75Lwzs763iCkp0I-2YnwOCt3V7yZxvPk=.a15d9bf6-1385-46d8-889f-a227e0d2f9e2@github.com>
References: <UHCEvPvTuTw75Lwzs763iCkp0I-2YnwOCt3V7yZxvPk=.a15d9bf6-1385-46d8-889f-a227e0d2f9e2@github.com>
Message-ID: <QhECb_U8iKcmnrdo8XuOpA1vGxpnusjuMVBo5X78Tq0=.53dc142a-f365-43dd-92b9-4ab22df68499@github.com>

On Thu, 11 Mar 2021 05:47:00 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review the patch which moves `ClassFileInstaller` class to `jdk.test.lib.helpers` package? 
> to reduce changes in the tests, `ClassFileInstaller` in the default package is kept w/ just `main` method that calls  `jdk.test.lib.helpers. ClassFileInstaller::main`. 
> 
> from JBS:
>> ClassFileInstaller is in the default package hence it's impossible to use it directly by classes in any other package. although ClassFileInstaller is mainly used directly from jtreg test description, there are cases when one needs to use it in another "driver" class (e.g. to reduce boilerplate), yet to do. that these driver classes have to either be in a default package or use reflection, both approaches have drawbacks. 
>> 
>> to solve that, we can move ClassFileInstaller implementation to a package, and to avoid unneeded churn, keep package-less ClassFileInstaller class which will call package-full impl.
>>
>> the need for this patch has raised as part of [JDK-8254129](https://bugs.openjdk.java.net/browse/JDK-8254129).
> 
> testing:
> - [x] `:jdk_core` against `{macos,windows,linux}-x64`
> - [x] `:jdk_svc` against `{macos,windows,linux}-x64`
> - [x] `test/hotspot/jtreg` w/o `applications` and `vmTestbase` directories against `{macos,windows,linux}-x64`
> 
> Thanks,
> -- Igor

Marked as reviewed by mseledtsov (Committer).

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

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

From cjplummer at openjdk.java.net  Fri Mar 12 02:58:06 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 12 Mar 2021 02:58:06 GMT
Subject: RFR: 8263326: Remove ReceiverTypeData check from
 serviceability/sa/TestPrintMdo.java
In-Reply-To: <nxs5_MwI8XEYOLNqPN-EUCRs94Nwo6K4dHgn0TM-sMo=.baf3b490-3d8f-4796-9468-6ef49299adef@github.com>
References: <nxs5_MwI8XEYOLNqPN-EUCRs94Nwo6K4dHgn0TM-sMo=.baf3b490-3d8f-4796-9468-6ef49299adef@github.com>
Message-ID: <qH19-PG69TBC5Feh5SA4RhqnN3fk43BzOx-Xqq3nMBE=.0f87ab81-4a4d-4f95-b504-191a24f16363@github.com>

On Wed, 10 Mar 2021 05:20:19 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> See CR for a description of why this change is needed.

Ping! Still need 2 reviews. This one is really trivial.

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

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

From ysuenaga at openjdk.java.net  Fri Mar 12 04:23:11 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Fri, 12 Mar 2021 04:23:11 GMT
Subject: RFR: 8262504: Some CLHSDB command cannot know they run on remote
 debugger
In-Reply-To: <QzsqiO3gB4AU3Sq5hdQkRfv0W5NAAv7t7rZh0STOtJs=.c969bcfc-7ea3-43f6-8f88-9e17c98c9bb9@github.com>
References: <hYYLenPIpA840x3tcc3ZikUiZKdJB3mSuxDs00dFdQo=.62e3707c-c3f8-48ab-8d1e-d5b7d42661d4@github.com>
 <QzsqiO3gB4AU3Sq5hdQkRfv0W5NAAv7t7rZh0STOtJs=.c969bcfc-7ea3-43f6-8f88-9e17c98c9bb9@github.com>
Message-ID: <m8IFwElp02D5LMIkaYKf-e87VLX8lzuxMIwGzt8CvzE=.3b1db374-b0b6-49b4-95f0-917c23fdfd3a@github.com>

On Fri, 5 Mar 2021 06:44:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> `pmap` and `pstack` CLHSDB command do not work on remote debugger, we can see following error message:
>> 
>> hsdb> pmap
>> not yet implemented (debugger does not support CDebugger)!
>> 
>> However, SA has different message for this purpose:
>> 
>> https://github.com/openjdk/jdk/blob/03d888f463c0a6e3fee70ed8ad606fc0a3082636/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PMap.java#L74-L78
>> 
>> SA should show "remote configuration is not yet implemented" when it works on remote debugger.
>
> Marked as reviewed by cjplummer (Reviewer).

PING: could you review it? I need one more reviewer, thanks!

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

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

From dholmes at openjdk.java.net  Fri Mar 12 05:27:17 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 12 Mar 2021 05:27:17 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v25]
In-Reply-To: <f8RkGXsdhtld9TcoCNLInUUxZpFYleWuR5VIl3CqVs0=.1776f22d-a62b-4f8d-8fc6-0a43b8353e1c@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <f8RkGXsdhtld9TcoCNLInUUxZpFYleWuR5VIl3CqVs0=.1776f22d-a62b-4f8d-8fc6-0a43b8353e1c@github.com>
Message-ID: <AXibtmRbVH_zQFoRBh8gkCTWU8bbLQ-0LGkhj1pnm-0=.bb57e91b-7738-499b-ac05-a93f4024e163@github.com>

On Thu, 11 Mar 2021 14:07:43 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8262903: [macos_aarch64] Thread::current() called on detached thread

src/hotspot/share/runtime/safefetch.inline.hpp line 35:

> 33: inline int SafeFetch32(int* adr, int errValue) {
> 34:   assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated");
> 35:   MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXExec, Thread::current()));

I think you may have to use `Thread::current_or_null_safe()` here in case this gets called from a signal handling context - see vmError.cpp testing for TestSafeFetchInErrorHandler. Same possibly for SafeFetchN.

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

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

From dholmes at openjdk.java.net  Fri Mar 12 05:52:08 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 12 Mar 2021 05:52:08 GMT
Subject: RFR: 8263326: Remove ReceiverTypeData check from
 serviceability/sa/TestPrintMdo.java
In-Reply-To: <nxs5_MwI8XEYOLNqPN-EUCRs94Nwo6K4dHgn0TM-sMo=.baf3b490-3d8f-4796-9468-6ef49299adef@github.com>
References: <nxs5_MwI8XEYOLNqPN-EUCRs94Nwo6K4dHgn0TM-sMo=.baf3b490-3d8f-4796-9468-6ef49299adef@github.com>
Message-ID: <95DGAMk5biPl8YhmWSES0oxZPe_VhvAQik8m8sDicqQ=.c9e2b0fb-4de5-4e40-a9c5-76893b981afd@github.com>

On Wed, 10 Mar 2021 05:20:19 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> See CR for a description of why this change is needed.

Looks good and trivial.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

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

From akozlov at openjdk.java.net  Fri Mar 12 07:12:17 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 12 Mar 2021 07:12:17 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v25]
In-Reply-To: <AXibtmRbVH_zQFoRBh8gkCTWU8bbLQ-0LGkhj1pnm-0=.bb57e91b-7738-499b-ac05-a93f4024e163@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <f8RkGXsdhtld9TcoCNLInUUxZpFYleWuR5VIl3CqVs0=.1776f22d-a62b-4f8d-8fc6-0a43b8353e1c@github.com>
 <AXibtmRbVH_zQFoRBh8gkCTWU8bbLQ-0LGkhj1pnm-0=.bb57e91b-7738-499b-ac05-a93f4024e163@github.com>
Message-ID: <lPoCNtc83YmZudBHHRDi_pc4xqoTTIzA0b-TzxQXV9o=.1754abd9-5747-4528-a040-0abf5ff6af35@github.com>

On Fri, 12 Mar 2021 05:24:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8262903: [macos_aarch64] Thread::current() called on detached thread
>
> src/hotspot/share/runtime/safefetch.inline.hpp line 35:
> 
>> 33: inline int SafeFetch32(int* adr, int errValue) {
>> 34:   assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated");
>> 35:   MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXExec, Thread::current()));
> 
> I think you may have to use `Thread::current_or_null_safe()` here in case this gets called from a signal handling context - see vmError.cpp testing for TestSafeFetchInErrorHandler. Same possibly for SafeFetchN.

I'm not sure about expected behavior then. We may crash trying to execute the generated code, since we may have no WXExec. If we switch to WXExec, we would need to go back to a previous W^X state, but we don't know which one without the thread.

BTW, the test passes, probably that's why it didn't get attention. All non-trivial actions in the current implementation of `pd_hotspot_signal_handler` (hhttps://github.com/openjdk/jdk/pull/2200/files#diff-9dcc5bcf908e2f8eb00b2c2837d667687a7540936d8f538ee1ea14e31ad50b40R215-R324) assume non-NULL thread. So AFAICS, we should always have a thread when the SafeFetch is called. 

Probably a fix to the https://bugs.openjdk.java.net/browse/JDK-8262903 could just move ThreadWXEnable under the `if`. But now after https://github.com/openjdk/jdk/pull/2200/commits/f6fb01b24f525e578692a1c6f2ff0a55b8233576is ThreadWXEnable allows optional W^X state change, like `MutexLocker` allows optional locking.

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

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

From david.holmes at oracle.com  Fri Mar 12 07:58:56 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 12 Mar 2021 17:58:56 +1000
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v25]
In-Reply-To: <lPoCNtc83YmZudBHHRDi_pc4xqoTTIzA0b-TzxQXV9o=.1754abd9-5747-4528-a040-0abf5ff6af35@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <f8RkGXsdhtld9TcoCNLInUUxZpFYleWuR5VIl3CqVs0=.1776f22d-a62b-4f8d-8fc6-0a43b8353e1c@github.com>
 <AXibtmRbVH_zQFoRBh8gkCTWU8bbLQ-0LGkhj1pnm-0=.bb57e91b-7738-499b-ac05-a93f4024e163@github.com>
 <lPoCNtc83YmZudBHHRDi_pc4xqoTTIzA0b-TzxQXV9o=.1754abd9-5747-4528-a040-0abf5ff6af35@github.com>
Message-ID: <59c46a13-91d9-bd60-70dd-ff8fde81c0c7@oracle.com>

On 12/03/2021 5:12 pm, Anton Kozlov wrote:
> On Fri, 12 Mar 2021 05:24:10 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>>>
>>>    8262903: [macos_aarch64] Thread::current() called on detached thread
>>
>> src/hotspot/share/runtime/safefetch.inline.hpp line 35:
>>
>>> 33: inline int SafeFetch32(int* adr, int errValue) {
>>> 34:   assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated");
>>> 35:   MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXExec, Thread::current()));
>>
>> I think you may have to use `Thread::current_or_null_safe()` here in case this gets called from a signal handling context - see vmError.cpp testing for TestSafeFetchInErrorHandler. Same possibly for SafeFetchN.
> 
> I'm not sure about expected behavior then. We may crash trying to execute the generated code, since we may have no WXExec. If we switch to WXExec, we would need to go back to a previous W^X state, but we don't know which one without the thread.

The NULL check is only part of it. In a signal handling context 
Thread::current() is not safe to call, you have to use 
Thread::current_or_null_safe().

> BTW, the test passes, probably that's why it didn't get attention. All non-trivial actions in the current implementation of `pd_hotspot_signal_handler` (hhttps://github.com/openjdk/jdk/pull/2200/files#diff-9dcc5bcf908e2f8eb00b2c2837d667687a7540936d8f538ee1ea14e31ad50b40R215-R324) assume non-NULL thread. So AFAICS, we should always have a thread when the SafeFetch is called.

Okay but you still need to use Thread::current_or_null_safe().

Cheers,
David

> Probably a fix to the https://bugs.openjdk.java.net/browse/JDK-8262903 could just move ThreadWXEnable under the `if`. But now after https://github.com/openjdk/jdk/pull/2200/commits/f6fb01b24f525e578692a1c6f2ff0a55b8233576is ThreadWXEnable allows optional W^X state change, like `MutexLocker` allows optional locking.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/2200
> 

From akozlov at openjdk.java.net  Fri Mar 12 12:17:39 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 12 Mar 2021 12:17:39 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v26]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <ioUfr36PoGR8ir-TiecioR9y0BI2GfmVq_aWST1b5Uc=.f69452f0-4289-4a29-9857-1b833070b80f@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request incrementally with three additional commits since the last revision:

 - Add Azul copyright
 - Update Oracle copyright years
 - Use Thread::current_or_null_safe in SafeFetch

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/f6fb01b2..29991c92

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=25
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=24-25

  Stats: 83 lines in 53 files changed: 41 ins; 0 del; 42 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

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

From vkempik at openjdk.java.net  Fri Mar 12 13:38:17 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Fri, 12 Mar 2021 13:38:17 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <Ei8n5Xqt_Usrtyz-M4AudO6fuOV30FTSG6BCpNXUa2w=.fe6928be-256e-4448-b094-1f7c869e4b26@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <Ymv3QSLaT5H6CuKXfwuUkep_PKnO3Zj54kSQA0jcc6s=.59dc4d6d-a8d0-4016-8a59-a4d6cb8b57ac@github.com>
 <Ei8n5Xqt_Usrtyz-M4AudO6fuOV30FTSG6BCpNXUa2w=.fe6928be-256e-4448-b094-1f7c869e4b26@github.com>
Message-ID: <YzgtINrzUk1D0dPpOvX2IZyIMhIMC4HqY3FoKtGO6TU=.377dfcb8-98d0-4fc5-ab40-11974e8266d0@github.com>

On Tue, 2 Mar 2021 08:12:10 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> I wasn't able to replicate JDK-8020753 and JDK-8186286. So will remove these workaround
>> @gerard-ziemski, 8020753 was originally your fix, do you know if it still needed on intel-mac ?
>
> The x86_bsd still carries the workaround https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp#L745. It's worth having macos ports to be aligned by features. I would propose to have this workaround for now, and decide on it later for macos/x86 and macos/aarch64 at once. Sorry for chiming in so late.

Hello Anton.
Please keep JDK-8020753 away from this port, as JDK-8020753 was very intel-specific workaround and macos11.0 on aarch64 doesn't show any signs of original bug.

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

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

From akozlov at openjdk.java.net  Fri Mar 12 14:10:18 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 12 Mar 2021 14:10:18 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v25]
In-Reply-To: <gKoH7dS4tYmoRme7Wzbg1mH0ygHFKlaTQgS_JiIE_8A=.96b62223-ef50-43f5-9db1-d150e449e1b9@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <f8RkGXsdhtld9TcoCNLInUUxZpFYleWuR5VIl3CqVs0=.1776f22d-a62b-4f8d-8fc6-0a43b8353e1c@github.com>
 <gKoH7dS4tYmoRme7Wzbg1mH0ygHFKlaTQgS_JiIE_8A=.96b62223-ef50-43f5-9db1-d150e449e1b9@github.com>
Message-ID: <ZSTPk6hVzz7glzH2jZYiRfbEJ0IYKpjWJFpPJ1evnJg=.09ce1d0a-a175-40e7-9005-c1b701f73154@github.com>

On Thu, 11 Mar 2021 20:28:46 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8262903: [macos_aarch64] Thread::current() called on detached thread
>
> Marked as reviewed by stefank (Reviewer).

> you still need to use Thread::current_or_null_safe() [for SafeFetch].

OK :) I fixed this in https://github.com/openjdk/jdk/pull/2200/commits/fd4812e585e0528010a8863df50956a3b64a6744

@dcubed-ojdk, I also updated copyrights, this concludes fixes for the review https://github.com/openjdk/jdk/pull/2200#pullrequestreview-581784107.

@theRealAph, could you elaborate on what is need to be done for https://github.com/openjdk/jdk/pull/2200#pullrequestreview-600597066.

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

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

From aph at openjdk.java.net  Fri Mar 12 16:35:23 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 12 Mar 2021 16:35:23 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v24]
In-Reply-To: <LMAOpd9DlD4esG9l4lwxtOe5_j1Cpi6aU33tVWCz3bE=.b4ab8215-55c0-43b4-a222-03e5aa0862e3@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <LMAOpd9DlD4esG9l4lwxtOe5_j1Cpi6aU33tVWCz3bE=.b4ab8215-55c0-43b4-a222-03e5aa0862e3@github.com>
Message-ID: <Lw_ar-Qr7JWxNWFgRc4qBWYsL12i8-eRmarTyB3gGto=.f3c76e3e-626d-468b-9c03-e4ce9f7ecf33@github.com>

On Tue, 9 Mar 2021 16:12:36 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 105 commits:
> 
>  - Merge commit 'refs/pull/11/head' of https://github.com/AntonKozlov/jdk into jdk-macos
>  - workaround JDK-8262895 by disabling subtest
>  - Fix typo
>  - Rename threadWXSetters.hpp -> threadWXSetters.inline.hpp
>  - JDK-8259937: bsd_aarch64 part
>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>  - Fix after JDK-8259539, partially revert preconditions
>  - JDK-8260471: bsd_aarch64 part
>  - JDK-8259539: bsd_aarch64 part
>  - JDK-8257828: bsd_aarch64 part
>  - ... and 95 more: https://git.openjdk.java.net/jdk/compare/a6e34b3d...a72f6834

> @theRealAph, could you elaborate on what is need to be done for [#2200 (review)](https://github.com/openjdk/jdk/pull/2200#pullrequestreview-600597066).

I think that what you've got now is fine.

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

Marked as reviewed by aph (Reviewer).

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

From aph at openjdk.java.net  Fri Mar 12 16:35:24 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 12 Mar 2021 16:35:24 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v21]
In-Reply-To: <v33sSQcIVsvidIkYzaOsIhkjNhojCVastBXuUJJ67IM=.9123e430-657f-4c24-a201-4f457232c983@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <ZfRwLBDhh3K6u3NaWzLWVyoYqBuZVJbipXCZKzPclBs=.bedc9c24-2178-400a-8868-fbbb61b298cc@github.com>
 <yMUjWudRugP8LTAT5fuc25Q7R1M9iTCBFMFvXGjRWlQ=.2a6cf189-5bb6-4f41-9e49-d859b85534b6@github.com>
 <v33sSQcIVsvidIkYzaOsIhkjNhojCVastBXuUJJ67IM=.9123e430-657f-4c24-a201-4f457232c983@github.com>
Message-ID: <SXXcMmMTXbltmXqeaDgF6g8EJvECwqtlNokXpNJ0CNI=.f358e952-3186-4503-a632-834ec4343c6d@github.com>

On Tue, 9 Mar 2021 18:01:11 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp line 62:
>> 
>>> 60: 
>>> 61: #if defined(__APPLE__) || defined(_WIN64)
>>> 62: #define R18_RESERVED
>> 
>> #define R18_RESERVED true```
>
> We always check for `R18_RESERVED` with `#if(n)def`, is there any reason to define the value for the macro?

Robustness, clarity, maintainability, convention. Why not?

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

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

From akozlov at openjdk.java.net  Fri Mar 12 16:44:38 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 12 Mar 2021 16:44:38 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v27]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <TRklBppvcFXK3TUe1dkT2FCn2b9m57pRFAGHR-Vt-8U=.13d4dcc9-deb4-4227-95ec-d9c7a8fc279d@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  Fix most of issues in java/foreign/ tests
  
  Failures related to va_args are tracked in JDK-8263512.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/29991c92..5bfe0f08

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=26
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=25-26

  Stats: 5 lines in 2 files changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

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

From cjplummer at openjdk.java.net  Fri Mar 12 21:08:08 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 12 Mar 2021 21:08:08 GMT
Subject: RFR: 8263326: Remove ReceiverTypeData check from
 serviceability/sa/TestPrintMdo.java
In-Reply-To: <95DGAMk5biPl8YhmWSES0oxZPe_VhvAQik8m8sDicqQ=.c9e2b0fb-4de5-4e40-a9c5-76893b981afd@github.com>
References: <nxs5_MwI8XEYOLNqPN-EUCRs94Nwo6K4dHgn0TM-sMo=.baf3b490-3d8f-4796-9468-6ef49299adef@github.com>
 <95DGAMk5biPl8YhmWSES0oxZPe_VhvAQik8m8sDicqQ=.c9e2b0fb-4de5-4e40-a9c5-76893b981afd@github.com>
Message-ID: <q9m8XS0_sker_83vJyCRxlECZXq7XwioKECfutaw8ZA=.439b319d-7c23-4e45-beb5-d682fef6ab2e@github.com>

On Fri, 12 Mar 2021 05:49:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> See CR for a description of why this change is needed.
>
> Looks good and trivial.
> 
> Thanks,
> David

Thanks, David!

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

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

From cjplummer at openjdk.java.net  Fri Mar 12 21:10:10 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 12 Mar 2021 21:10:10 GMT
Subject: Integrated: 8263055: hsdb Command Line Debugger does not properly
 direct output for some commands
In-Reply-To: <pGwJVLHvj0BILLgV5TFOZoqdhx1JXVVda0fNVS4GZg4=.4f79539f-ee86-4b05-a1b3-bcdeddfaf32a@github.com>
References: <pGwJVLHvj0BILLgV5TFOZoqdhx1JXVVda0fNVS4GZg4=.4f79539f-ee86-4b05-a1b3-bcdeddfaf32a@github.com>
Message-ID: <xp2SpbTVXtZ37HYweBwhpBS1uMerTM6cHHOMyb_0eXA=.0c5c735f-2ee7-4478-be28-76973dec6913@github.com>

On Tue, 9 Mar 2021 04:52:57 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I ran the hsdb Command Line Debugger (Windows -> Console menu item) and tried the class and classes commands, and neither appeared to produce any output. Other commands seemed to work as expected. I then went back to the terminal window I used to launch hsdb, and notice all the output from class and classes commands went there instead. The reason is because these commands are using System.out.println instead of out.println. "out" is a PrintStream field of the CommandProcessor instance, and should be used for all output other than error output, which can use "err".
> 
> We have no test for this, but I did run the hsdb GUI, brought up the Command Line Debugger, and confirmed that `class` and `classes` now properly show the output there. We do have clhsdb tests that also exercise this CommandProcessor code, but clhsdb directs all the output to System.out, so `out.println` and `System.out.println` end up being the same, thus the issue was not noticed.

This pull request has now been integrated.

Changeset: b2f7c58d
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b2f7c58d
Stats:     5 lines in 1 file changed: 0 ins; 0 del; 5 mod

8263055: hsdb Command Line Debugger does not properly direct output for some commands

Reviewed-by: amenkov, ysuenaga

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

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

From cjplummer at openjdk.java.net  Fri Mar 12 21:10:09 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 12 Mar 2021 21:10:09 GMT
Subject: RFR: 8263055: hsdb Command Line Debugger does not properly direct
 output for some commands
In-Reply-To: <k8XCW7xU1D5OJK6Ri2NDdIL3vXk4KRvV5nTpfSsTHMQ=.d4754003-d867-48f7-8788-a98827d90f99@github.com>
References: <pGwJVLHvj0BILLgV5TFOZoqdhx1JXVVda0fNVS4GZg4=.4f79539f-ee86-4b05-a1b3-bcdeddfaf32a@github.com>
 <k8XCW7xU1D5OJK6Ri2NDdIL3vXk4KRvV5nTpfSsTHMQ=.d4754003-d867-48f7-8788-a98827d90f99@github.com>
Message-ID: <8Dj2_bAA3rlkJ-HGL4LLjzWRuqv8xVtsqN8AnffR_mk=.3a4aa8b0-91e1-47f2-ae42-7a6417e557fb@github.com>

On Fri, 12 Mar 2021 00:40:41 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I ran the hsdb Command Line Debugger (Windows -> Console menu item) and tried the class and classes commands, and neither appeared to produce any output. Other commands seemed to work as expected. I then went back to the terminal window I used to launch hsdb, and notice all the output from class and classes commands went there instead. The reason is because these commands are using System.out.println instead of out.println. "out" is a PrintStream field of the CommandProcessor instance, and should be used for all output other than error output, which can use "err".
>> 
>> We have no test for this, but I did run the hsdb GUI, brought up the Command Line Debugger, and confirmed that `class` and `classes` now properly show the output there. We do have clhsdb tests that also exercise this CommandProcessor code, but clhsdb directs all the output to System.out, so `out.println` and `System.out.println` end up being the same, thus the issue was not noticed.
>
> Marked as reviewed by ysuenaga (Reviewer).

Thanks, Yasumasa and Alex!

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

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

From cjplummer at openjdk.java.net  Fri Mar 12 21:08:09 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 12 Mar 2021 21:08:09 GMT
Subject: Integrated: 8263326: Remove ReceiverTypeData check from
 serviceability/sa/TestPrintMdo.java
In-Reply-To: <nxs5_MwI8XEYOLNqPN-EUCRs94Nwo6K4dHgn0TM-sMo=.baf3b490-3d8f-4796-9468-6ef49299adef@github.com>
References: <nxs5_MwI8XEYOLNqPN-EUCRs94Nwo6K4dHgn0TM-sMo=.baf3b490-3d8f-4796-9468-6ef49299adef@github.com>
Message-ID: <kkCwJ643uM5u6ghKqlAxnt1eVHjhgE00v2nAOQH-QvY=.c22c1b47-5223-4b58-8f02-fa1d81226cdc@github.com>

On Wed, 10 Mar 2021 05:20:19 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> See CR for a description of why this change is needed.

This pull request has now been integrated.

Changeset: ecfa712c
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ecfa712c
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

8263326: Remove ReceiverTypeData check from serviceability/sa/TestPrintMdo.java

Reviewed-by: dholmes

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

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

From iignatyev at openjdk.java.net  Fri Mar 12 23:16:08 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 12 Mar 2021 23:16:08 GMT
Subject: Integrated: 8263412: ClassFileInstaller can't be used by classes
 outside of default package
In-Reply-To: <UHCEvPvTuTw75Lwzs763iCkp0I-2YnwOCt3V7yZxvPk=.a15d9bf6-1385-46d8-889f-a227e0d2f9e2@github.com>
References: <UHCEvPvTuTw75Lwzs763iCkp0I-2YnwOCt3V7yZxvPk=.a15d9bf6-1385-46d8-889f-a227e0d2f9e2@github.com>
Message-ID: <l15ZNjVg8ZFzigmDWVK5uFbQxf7H66k-tU1pgYTM6zE=.a64bc9c0-f2d3-4db6-ab8c-9a42a804e050@github.com>

On Thu, 11 Mar 2021 05:47:00 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review the patch which moves `ClassFileInstaller` class to `jdk.test.lib.helpers` package? 
> to reduce changes in the tests, `ClassFileInstaller` in the default package is kept w/ just `main` method that calls  `jdk.test.lib.helpers. ClassFileInstaller::main`. 
> 
> from JBS:
>> ClassFileInstaller is in the default package hence it's impossible to use it directly by classes in any other package. although ClassFileInstaller is mainly used directly from jtreg test description, there are cases when one needs to use it in another "driver" class (e.g. to reduce boilerplate), yet to do. that these driver classes have to either be in a default package or use reflection, both approaches have drawbacks. 
>> 
>> to solve that, we can move ClassFileInstaller implementation to a package, and to avoid unneeded churn, keep package-less ClassFileInstaller class which will call package-full impl.
>>
>> the need for this patch has raised as part of [JDK-8254129](https://bugs.openjdk.java.net/browse/JDK-8254129).
> 
> testing:
> - [x] `:jdk_core` against `{macos,windows,linux}-x64`
> - [x] `:jdk_svc` against `{macos,windows,linux}-x64`
> - [x] `test/hotspot/jtreg` w/o `applications` and `vmTestbase` directories against `{macos,windows,linux}-x64`
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: e834f99d
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e834f99d
Stats:     472 lines in 114 files changed: 145 ins; 229 del; 98 mod

8263412: ClassFileInstaller can't be used by classes outside of default package

Reviewed-by: iklam, coleenp, mseledtsov

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

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

From iignatyev at openjdk.java.net  Fri Mar 12 23:16:06 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 12 Mar 2021 23:16:06 GMT
Subject: RFR: 8263412: ClassFileInstaller can't be used by classes outside
 of default package
In-Reply-To: <QhECb_U8iKcmnrdo8XuOpA1vGxpnusjuMVBo5X78Tq0=.53dc142a-f365-43dd-92b9-4ab22df68499@github.com>
References: <UHCEvPvTuTw75Lwzs763iCkp0I-2YnwOCt3V7yZxvPk=.a15d9bf6-1385-46d8-889f-a227e0d2f9e2@github.com>
 <QhECb_U8iKcmnrdo8XuOpA1vGxpnusjuMVBo5X78Tq0=.53dc142a-f365-43dd-92b9-4ab22df68499@github.com>
Message-ID: <fiFhFmTFqI0VwtDvIlfzFd-yvzzZNmYGO4T7y16tsMk=.36069165-be2a-4fe9-9518-36a0d5dd0507@github.com>

On Fri, 12 Mar 2021 02:08:09 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review the patch which moves `ClassFileInstaller` class to `jdk.test.lib.helpers` package? 
>> to reduce changes in the tests, `ClassFileInstaller` in the default package is kept w/ just `main` method that calls  `jdk.test.lib.helpers. ClassFileInstaller::main`. 
>> 
>> from JBS:
>>> ClassFileInstaller is in the default package hence it's impossible to use it directly by classes in any other package. although ClassFileInstaller is mainly used directly from jtreg test description, there are cases when one needs to use it in another "driver" class (e.g. to reduce boilerplate), yet to do. that these driver classes have to either be in a default package or use reflection, both approaches have drawbacks. 
>>> 
>>> to solve that, we can move ClassFileInstaller implementation to a package, and to avoid unneeded churn, keep package-less ClassFileInstaller class which will call package-full impl.
>>>
>>> the need for this patch has raised as part of [JDK-8254129](https://bugs.openjdk.java.net/browse/JDK-8254129).
>> 
>> testing:
>> - [x] `:jdk_core` against `{macos,windows,linux}-x64`
>> - [x] `:jdk_svc` against `{macos,windows,linux}-x64`
>> - [x] `test/hotspot/jtreg` w/o `applications` and `vmTestbase` directories against `{macos,windows,linux}-x64`
>> 
>> Thanks,
>> -- Igor
>
> Marked as reviewed by mseledtsov (Committer).

Ioi, Coleen, Misha, thanks for your reviews.

-- Igor

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

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

From iignatyev at openjdk.java.net  Fri Mar 12 23:25:14 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 12 Mar 2021 23:25:14 GMT
Subject: RFR: 8246494: introduce vm.flagless at-requires property
In-Reply-To: <fC51vNiDPG7UUjFvMEJnbbKV0ejluFe023gEgyFq1eI=.f55fd064-9aba-4f05-a3ea-ad6959e1c9bc@github.com>
References: <fC51vNiDPG7UUjFvMEJnbbKV0ejluFe023gEgyFq1eI=.f55fd064-9aba-4f05-a3ea-ad6959e1c9bc@github.com>
Message-ID: <ZBkMQrIHh1a6KfPP28BRkbcn9gMBLVo5gNAy2mcx_IM=.40f59272-fe5b-4199-80fc-92c1eb0b7de8@github.com>

On Tue, 2 Mar 2021 23:27:21 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> resurrecting old [RFR](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-June/041981.html):
> 
>> Hi all,
>> 
>> could you please review the patch which introduces a new @requires property to filter out the tests which ignore externally provided JVM flags?
>> 
>> the idea behind this patch is to have a way to clearly mark tests which ignore flags, so 
>> a) it's obvious that they don't execute a flag-guarded code/feature, and extra care should be taken to use them to verify any flag-guarded changed;
>> b) they can be easily excluded from runs w/ flags.
>> 
>> @requires and VMProps allows us to achieve both, so it's been decided to add a new property `vm.flagless`. `vm.flagless` is set to false if there are any XX flags other than `-XX:MaxRAMPercentage` and `-XX:CreateCoredumpOnCrash` (which are known to be set almost always) or any X flags other `-Xmixed`; in other words any tests w/ `@requires vm.flagless` will be excluded from runs w/ any other X / XX flags passed via `-vmoption` / `-javaoption`. in rare cases, when one still wants to run the tests marked by `vm.flagless`  w/ external flags, `vm.flagless` can be forcefully set to true by setting any value to `TEST_VM_FLAGLESS` env. variable.
>> 
>> this patch adds necessary common changes and marks common tests, namely Scimark, GTestWrapper and TestNativeProcessBuilder. Component-specific tests will be marked separately by the corresponding subtasks of 8151707[1].
>> 
>> please note, the patch depends on CODETOOLS-7902336[2], which will be included in the next jtreg version, so this patch is to be integrated only after jtreg5.1 is promoted and we switch to use it by 8246387[3].
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8246494
>> webrev: http://cr.openjdk.java.net/~iignatyev//8246494/webrev.00
>> testing: marked tests w/ different XX and X flags w/ and w/o TEST_VM_FLAGLESS env. var, and w/o any flags
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8151707
>> [2] https://bugs.openjdk.java.net/browse/CODETOOLS-7902336
>> [3] https://bugs.openjdk.java.net/browse/JDK-8246387
>> 
> 
> after offline discussion with @pliden, it has been decided to reduce the scope of [8246499](https://bugs.openjdk.java.net/browse/JDK-8246499) and not mark the tests that use `UseXGC` flags for selection, e.g. `test/hotspot/jtreg/gc/z/TestSmallHeap.java`.
> 
> Thanks,
> -- Igor

ping?

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

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

From cjplummer at openjdk.java.net  Fri Mar 12 23:39:09 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 12 Mar 2021 23:39:09 GMT
Subject: Integrated: 8243455: Many SA tests can fail due to trying to get the
 stack trace of an active method
In-Reply-To: <vjDRMVH6jMQsafl_UZTsf0Fglcx89foITgIg4Zhmawo=.f98f3f01-53d3-4613-8c54-67b9f2d34215@github.com>
References: <vjDRMVH6jMQsafl_UZTsf0Fglcx89foITgIg4Zhmawo=.f98f3f01-53d3-4613-8c54-67b9f2d34215@github.com>
Message-ID: <vCYj609TfqDFxTtfhkIyoQ4RRmirCt_2423OOwwiwuk=.fd10847f-2a57-4453-bd1e-2641f422af2e@github.com>

On Tue, 23 Feb 2021 23:34:31 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Many tests run `LingeredApp`, get its stack with `jstack`, and then look for `LingeredApp.main` in the output, which should appear in the stack trace of the main thread. Usually this works fine since the main thread is in a loop, and usually blocked in `Thread.sleep()`. However, during the short period of time it wakes up from sleep, the thread's stack might not be walk-able, in which case the `LingeredApp.main` frame will not appear, and the tests looking for it will fail.
> 
> The fix is to introduce a new thread called `SteadyStateThread` that has a method called `steadyState()` that blocks indefinitely trying to synchronize on a locked object. All code that used to look for `LingeredApp.main` in the output now instead looks for `LingeredApp.steadyState`, which should always be there. I'm open to suggestions for a better name than "SteadyState" if you have one.
> 
> There are a few special cases with the tests that were modified that are described below:
> 
> Regarding the removal of `LingeredAppWithTrivialMain.java`, it was originally added to fix [JDK-8229118](https://bugs.openjdk.java.net/browse/JDK-8229118), which was an issue with the `ClhsdbFindPC` test failing on aarch64 when doing the `-Xcomp` run. It expected `LingeredApp.main()` to be compiled in that case, and for the PC of the frame to be in an `NMethod`. However, on aarch64 an uncommon-trap was causing it to be de-optimized, so the PC was in the interpreter instead, causing the test to fail. The fix was to instead rely on finding a trivial `LingeredAppWithTrivialMain.main()` frame in the stack trace since it would always be compiled. With the changes to instead have (and rely on) the `SteadyStateThread` and the presence of `LingeredApp.steadyState()`, the need for `LingeredAppWithTrivialMain` goes away. `LingeredApp.steadyState()` will always be compiled, even on aarch64.
> 
> Regarding `DebugdConnectTest.java`, it is listed in the CR as an affected test but no specified fix has been provided.
>  None is needed. The issue was that it looked for `LingeredApp` in the jstack output, and it used to be the only place it would find it was in the main thread's stack trace, which sometimes could not be retrieved. Now it can also be found in the `SteadyStateThread`'s stack trace, which can always be retrieved.
> 
> Regarding `HeapDumpTest.java`, it used to check for `LingeredAppWithExtendedChars.main` and now it checks for `LingeredApp.steadyState`. It still is run with `LingeredAppWithExtendedChars`. The only thing special about that class is that it contains an extended unicode character used to reproduce [JDK-8028623](https://bugs.openjdk.java.net/browse/JDK-8028623), so it will still do that, even though it now checks for `LingeredApp.steadyState`.

This pull request has now been integrated.

Changeset: 43524cc4
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/43524cc4
Stats:     114 lines in 11 files changed: 41 ins; 36 del; 37 mod

8243455: Many SA tests can fail due to trying to get the stack trace of an active method

Reviewed-by: lmesnik, ysuenaga, sspitsyn

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

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

From cjplummer at openjdk.java.net  Fri Mar 12 23:49:19 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 12 Mar 2021 23:49:19 GMT
Subject: RFR: 8263477: serviceability/sa/ClhsdbDumpheap.java timed out
Message-ID: <vkzHCK8TweXBo2qyYIum1wqBAZ_t_hJ5RCIiPmh7OJ4=.3e780eba-800e-4a65-a72b-fc1ed2c8cb1f@github.com>

[JDK-8257234](https://bugs.openjdk.java.net/browse/JDK-8257234) added a lot more subtests to this test, so now it sometimes times out. I've double the amount of time given to 240. I'd like to push this as a trivial change.

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

Commit messages:
 - Give ClhsdbDumpheap.java a longer timeout since it run a lot more subtests now and sometimes times out.

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

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

From lmesnik at openjdk.java.net  Sat Mar 13 00:08:08 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Sat, 13 Mar 2021 00:08:08 GMT
Subject: RFR: 8263477: serviceability/sa/ClhsdbDumpheap.java timed out
In-Reply-To: <vkzHCK8TweXBo2qyYIum1wqBAZ_t_hJ5RCIiPmh7OJ4=.3e780eba-800e-4a65-a72b-fc1ed2c8cb1f@github.com>
References: <vkzHCK8TweXBo2qyYIum1wqBAZ_t_hJ5RCIiPmh7OJ4=.3e780eba-800e-4a65-a72b-fc1ed2c8cb1f@github.com>
Message-ID: <IdBrD3VhrpZv1eM94kdvE5D_IKJdrJJZt5DiKBqV7Uo=.06edb95a-3ac8-4728-b65c-26603e979daa@github.com>

On Fri, 12 Mar 2021 23:44:22 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> [JDK-8257234](https://bugs.openjdk.java.net/browse/JDK-8257234) added a lot more subtests to this test, so now it sometimes times out. I've double the amount of time given to 240. I'd like to push this as a trivial change.

Marked as reviewed by lmesnik (Committer).

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

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

From dcubed at openjdk.java.net  Sat Mar 13 00:08:08 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 13 Mar 2021 00:08:08 GMT
Subject: RFR: 8263477: serviceability/sa/ClhsdbDumpheap.java timed out
In-Reply-To: <vkzHCK8TweXBo2qyYIum1wqBAZ_t_hJ5RCIiPmh7OJ4=.3e780eba-800e-4a65-a72b-fc1ed2c8cb1f@github.com>
References: <vkzHCK8TweXBo2qyYIum1wqBAZ_t_hJ5RCIiPmh7OJ4=.3e780eba-800e-4a65-a72b-fc1ed2c8cb1f@github.com>
Message-ID: <Qy44iMIRKOKrOiao1rB_hdswZG7pTWiwJRF384eD09s=.1491fb13-e3d7-4d25-b8b2-b21ca04e3a3c@github.com>

On Fri, 12 Mar 2021 23:44:22 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> [JDK-8257234](https://bugs.openjdk.java.net/browse/JDK-8257234) added a lot more subtests to this test, so now it sometimes times out. I've double the amount of time given to 240. I'd like to push this as a trivial change.

Thumbs up!

I agree that this is a trivial change.

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

Marked as reviewed by dcubed (Reviewer).

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

From cjplummer at openjdk.java.net  Sat Mar 13 00:34:07 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Sat, 13 Mar 2021 00:34:07 GMT
Subject: RFR: 8263477: serviceability/sa/ClhsdbDumpheap.java timed out
In-Reply-To: <Qy44iMIRKOKrOiao1rB_hdswZG7pTWiwJRF384eD09s=.1491fb13-e3d7-4d25-b8b2-b21ca04e3a3c@github.com>
References: <vkzHCK8TweXBo2qyYIum1wqBAZ_t_hJ5RCIiPmh7OJ4=.3e780eba-800e-4a65-a72b-fc1ed2c8cb1f@github.com>
 <Qy44iMIRKOKrOiao1rB_hdswZG7pTWiwJRF384eD09s=.1491fb13-e3d7-4d25-b8b2-b21ca04e3a3c@github.com>
Message-ID: <QCqnRfKDPx6SgnCbZMIc6CvosonDKB7NAKsmtjP6TfM=.af3ba4db-5092-4c47-a24b-d13fe9efb431@github.com>

On Sat, 13 Mar 2021 00:05:49 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> [JDK-8257234](https://bugs.openjdk.java.net/browse/JDK-8257234) added a lot more subtests to this test, so now it sometimes times out. I've double the amount of time given to 240. I'd like to push this as a trivial change.
>
> Thumbs up!
> 
> I agree that this is a trivial change.

Thanks, Dan and Leonid!

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

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

From cjplummer at openjdk.java.net  Sat Mar 13 00:34:17 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Sat, 13 Mar 2021 00:34:17 GMT
Subject: RFR: 8263546: Add "findsym" command to clhsdb.html help file
Message-ID: <-u_1bRA3RlHlR4Dh9NkqqlUG3ax86emRoKs5UeGvJXs=.066f58c0-40f7-46d4-bc1b-00f01d2c825e@github.com>

Added clhsdb help for findsym, which was missed when the findsym command was recently added. Also fixed a very minor typo in the findpc help.

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

Commit messages:
 - Add clhsdb help for findsym command.

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

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

From ysuenaga at openjdk.java.net  Sat Mar 13 01:20:05 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sat, 13 Mar 2021 01:20:05 GMT
Subject: RFR: 8263546: Add "findsym" command to clhsdb.html help file
In-Reply-To: <-u_1bRA3RlHlR4Dh9NkqqlUG3ax86emRoKs5UeGvJXs=.066f58c0-40f7-46d4-bc1b-00f01d2c825e@github.com>
References: <-u_1bRA3RlHlR4Dh9NkqqlUG3ax86emRoKs5UeGvJXs=.066f58c0-40f7-46d4-bc1b-00f01d2c825e@github.com>
Message-ID: <6_R3cNYIG76RA_72ejNGVNnQ738vRLu9ApewQtVXv6M=.50799689-5eb8-4dc3-aa0b-5a99c3ab44b3@github.com>

On Sat, 13 Mar 2021 00:28:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Added clhsdb help for findsym, which was missed when the findsym command was recently added. Also fixed a very minor typo in the findpc help.

Marked as reviewed by ysuenaga (Reviewer).

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

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

From iignatyev at openjdk.java.net  Sat Mar 13 04:38:48 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Sat, 13 Mar 2021 04:38:48 GMT
Subject: RFR: 8263549:  8263412 can cause jtreg testlibrary split
Message-ID: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com>

Hi all,

could you please review this dull patch that replaces `ClassFileInstaller` w/ `jdk.test.lib.helpers.ClassFileInstaller` in all jtreg test descriptions to ensure we won't get split testlibrary, and removes `jdk/test/lib/ClassFileInstaller.java` (so it won't be accidentally used).

from JBS:
> after JDK-8263412, we might (again) encounter NCDFE b/c parts of testlibraries aren't on the classpath. this happens when jtreg builds `jdk.test.lib.helpers.ClassFileInstaller` as a part of test-specific code, but `ClassFileInstaller` as part of shared testibrary directory in one test, when in the following test, jtreg sees `ClassFileInstaller` in the shared directory, hence javac won't recompile it/its dependencies, but in runtime `jdk.test.lib.helpers.ClassFileInstaller` is nowhere to be found, hence we get NCDFE. 

testing:
- [x]  `grep ' ClassFileInstaller[^.]`
- [ ] tier1-3

Thanks,
-- Igor

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

Commit messages:
 - fixup
 - update copyright year
 - rm test/lib/ClassFileInstaller.java
 - 's/ ClassFileInstaller / jdk.test.lib.helpers.ClassFileInstaller /g'

Changes: https://git.openjdk.java.net/jdk/pull/2985/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2985&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263549
  Stats: 1736 lines in 867 files changed: 0 ins; 67 del; 1669 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2985.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2985/head:pull/2985

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

From iignatyev at openjdk.java.net  Sat Mar 13 04:42:08 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Sat, 13 Mar 2021 04:42:08 GMT
Subject: RFR: 8263549:  8263412 can cause jtreg testlibrary split
In-Reply-To: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com>
References: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com>
Message-ID: <dEaJYzwXo6IiFslhETMamL51NDQcfBQ7BCfiE_ccsvk=.f5062de3-b0bb-459b-9391-e3bb44a73b33@github.com>

On Sat, 13 Mar 2021 04:31:31 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this dull patch that replaces `ClassFileInstaller` w/ `jdk.test.lib.helpers.ClassFileInstaller` in all jtreg test descriptions to ensure we won't get split testlibrary, and removes `jdk/test/lib/ClassFileInstaller.java` (so it won't be accidentally used).
> 
> from JBS:
>> after JDK-8263412, we might (again) encounter NCDFE b/c parts of testlibraries aren't on the classpath. this happens when jtreg builds `jdk.test.lib.helpers.ClassFileInstaller` as a part of test-specific code, but `ClassFileInstaller` as part of shared testibrary directory in one test, when in the following test, jtreg sees `ClassFileInstaller` in the shared directory, hence javac won't recompile it/its dependencies, but in runtime `jdk.test.lib.helpers.ClassFileInstaller` is nowhere to be found, hence we get NCDFE. 
> 
> testing:
> - [x]  `grep ' ClassFileInstaller[^.]`
> - [ ] tier1-3
> 
> Thanks,
> -- Igor

note for reviewers: the big part of the patch is just `sed -i  's/ ClassFileInstaller / jdk.test.lib.helpers.ClassFileInstaller /g'`

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

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

From dholmes at openjdk.java.net  Sat Mar 13 05:52:22 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 13 Mar 2021 05:52:22 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v27]
In-Reply-To: <TRklBppvcFXK3TUe1dkT2FCn2b9m57pRFAGHR-Vt-8U=.13d4dcc9-deb4-4227-95ec-d9c7a8fc279d@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <TRklBppvcFXK3TUe1dkT2FCn2b9m57pRFAGHR-Vt-8U=.13d4dcc9-deb4-4227-95ec-d9c7a8fc279d@github.com>
Message-ID: <FB2pev3OL8y-AYtFw1i8n3Np5ny9bYb8wdduqVtiXhA=.84f450cc-6891-4a0b-a84d-1abb8a2eaf00@github.com>

On Fri, 12 Mar 2021 16:44:38 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix most of issues in java/foreign/ tests
>   
>   Failures related to va_args are tracked in JDK-8263512.

src/hotspot/share/runtime/safefetch.inline.hpp line 35:

> 33: inline int SafeFetch32(int* adr, int errValue) {
> 34:   assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated");
> 35:   Thread* thread = Thread::current_or_null_safe();

Sorry but this should be MACOS_AARCH64 only. All three lines need to be ifdef'd if you are going to include the assertion.

Thanks,
David

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

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

From iklam at openjdk.java.net  Sat Mar 13 06:19:06 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Sat, 13 Mar 2021 06:19:06 GMT
Subject: RFR: 8263549:  8263412 can cause jtreg testlibrary split
In-Reply-To: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com>
References: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com>
Message-ID: <2ydx9TUT868fiCQNxF6IaEsq9toXBiDJjJK3GqWRREE=.77fc9c8d-efed-47e8-8f53-02255da6e97e@github.com>

On Sat, 13 Mar 2021 04:31:31 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this dull patch that replaces `ClassFileInstaller` w/ `jdk.test.lib.helpers.ClassFileInstaller` in all jtreg test descriptions to ensure we won't get split testlibrary, and removes `jdk/test/lib/ClassFileInstaller.java` (so it won't be accidentally used).
> 
> from JBS:
>> after JDK-8263412, we might (again) encounter NCDFE b/c parts of testlibraries aren't on the classpath. this happens when jtreg builds `jdk.test.lib.helpers.ClassFileInstaller` as a part of test-specific code, but `ClassFileInstaller` as part of shared testibrary directory in one test, when in the following test, jtreg sees `ClassFileInstaller` in the shared directory, hence javac won't recompile it/its dependencies, but in runtime `jdk.test.lib.helpers.ClassFileInstaller` is nowhere to be found, hence we get NCDFE. 
> 
> testing:
> - [x]  `grep ' ClassFileInstaller[^.]`
> - [ ] tier1-3
> 
> Thanks,
> -- Igor

I did this and scanned the differences (with the diff file from the webrev) and it looks reasonable to me.

grep '^[+-]' diff.txt | grep -v Copyright | grep -v '^.[+-]' | less

It looks like most of the changes are mechanical. There were only a few cases where manual changes were made. I trusted that you have tested those cases individually.

But I don't understand why this error can happen. It seems like jtreg would allow two test cases to interfere with each other.

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

Marked as reviewed by iklam (Reviewer).

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

From iignatyev at openjdk.java.net  Sat Mar 13 06:30:00 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Sat, 13 Mar 2021 06:30:00 GMT
Subject: RFR: 8263549:  8263412 can cause jtreg testlibrary split [v2]
In-Reply-To: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com>
References: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com>
Message-ID: <At8rU6AnwStuhNrALmVmVvxaqOvNe-PqnnddIqLkOB4=.66b0d17b-6f4f-4cf8-b6bf-a5592f9a46e3@github.com>

> Hi all,
> 
> could you please review this dull patch that replaces `ClassFileInstaller` w/ `jdk.test.lib.helpers.ClassFileInstaller` in all jtreg test descriptions to ensure we won't get split testlibrary, and removes `jdk/test/lib/ClassFileInstaller.java` (so it won't be accidentally used).
> 
> from JBS:
>> after JDK-8263412, we might (again) encounter NCDFE b/c parts of testlibraries aren't on the classpath. this happens when jtreg builds `jdk.test.lib.helpers.ClassFileInstaller` as a part of test-specific code, but `ClassFileInstaller` as part of shared testibrary directory in one test, when in the following test, jtreg sees `ClassFileInstaller` in the shared directory, hence javac won't recompile it/its dependencies, but in runtime `jdk.test.lib.helpers.ClassFileInstaller` is nowhere to be found, hence we get NCDFE. 
> 
> testing:
> - [x]  `grep ' ClassFileInstaller[^.]`
> - [ ] tier1-3
> 
> Thanks,
> -- Igor

Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision:

  fix compilation error in IncorrectAOTLibraryTest test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2985/files
  - new: https://git.openjdk.java.net/jdk/pull/2985/files/6e53ad97..ff6d4f91

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

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

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

From iignatyev at openjdk.java.net  Sat Mar 13 06:44:12 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Sat, 13 Mar 2021 06:44:12 GMT
Subject: RFR: 8263549:  8263412 can cause jtreg testlibrary split [v3]
In-Reply-To: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com>
References: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com>
Message-ID: <c3UIWUcXOnH5Hd_Th0_YIiKCTklnxTtWFyPOC6QfCpQ=.dae1c7f3-0f63-4047-9df9-79ab0e2306f8@github.com>

> Hi all,
> 
> could you please review this dull patch that replaces `ClassFileInstaller` w/ `jdk.test.lib.helpers.ClassFileInstaller` in all jtreg test descriptions to ensure we won't get split testlibrary, and removes `jdk/test/lib/ClassFileInstaller.java` (so it won't be accidentally used).
> 
> from JBS:
>> after JDK-8263412, we might (again) encounter NCDFE b/c parts of testlibraries aren't on the classpath. this happens when jtreg builds `jdk.test.lib.helpers.ClassFileInstaller` as a part of test-specific code, but `ClassFileInstaller` as part of shared testibrary directory in one test, when in the following test, jtreg sees `ClassFileInstaller` in the shared directory, hence javac won't recompile it/its dependencies, but in runtime `jdk.test.lib.helpers.ClassFileInstaller` is nowhere to be found, hence we get NCDFE. 
> 
> testing:
> - [x]  `grep ' ClassFileInstaller[^.]`
> - [ ] tier1-3
> 
> Thanks,
> -- Igor

Igor Ignatyev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  fix compilation error in IncorrectAOTLibraryTest test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2985/files
  - new: https://git.openjdk.java.net/jdk/pull/2985/files/ff6d4f91..3a3b7a84

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

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

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

From iignatyev at openjdk.java.net  Sat Mar 13 06:44:13 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Sat, 13 Mar 2021 06:44:13 GMT
Subject: RFR: 8263549:  8263412 can cause jtreg testlibrary split [v3]
In-Reply-To: <2ydx9TUT868fiCQNxF6IaEsq9toXBiDJjJK3GqWRREE=.77fc9c8d-efed-47e8-8f53-02255da6e97e@github.com>
References: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com>
 <2ydx9TUT868fiCQNxF6IaEsq9toXBiDJjJK3GqWRREE=.77fc9c8d-efed-47e8-8f53-02255da6e97e@github.com>
Message-ID: <FmxUanOC2tsK13CBu-bdeJ6gziFttKoyMFipgjTdAEM=.c1bc20fa-7173-44ae-8ea6-60bbc2ac5b6d@github.com>

On Sat, 13 Mar 2021 06:16:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Igor Ignatyev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   fix compilation error in IncorrectAOTLibraryTest test
>
> I did this and scanned the differences (with the diff file from the webrev) and it looks reasonable to me.
> 
> grep '^[+-]' diff.txt | grep -v Copyright | grep -v '^.[+-]' | less
> 
> It looks like most of the changes are mechanical. There were only a few cases where manual changes were made. I trusted that you have tested those cases individually.
> 
> But I don't understand why this error can happen. It seems like jtreg would allow two test cases to interfere with each other.

Hi Ioi,

thanks for review this, I ran the whole tier1-3 jobs which should provide enough coverage. as oracle builds don't have AOT feature enabled, I missed a compilation error in `IncorrectAOTLibraryTest` test. the test failed in GitHub action and should be fixed by [3a3b7a8](https://github.com/openjdk/jdk/pull/2985/commits/3a3b7a846289181b466b3c1eb478a0a571d9468b).

-- Igor

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

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

From iklam at openjdk.java.net  Sat Mar 13 07:14:09 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Sat, 13 Mar 2021 07:14:09 GMT
Subject: RFR: 8263549:  8263412 can cause jtreg testlibrary split [v3]
In-Reply-To: <2ydx9TUT868fiCQNxF6IaEsq9toXBiDJjJK3GqWRREE=.77fc9c8d-efed-47e8-8f53-02255da6e97e@github.com>
References: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com>
 <2ydx9TUT868fiCQNxF6IaEsq9toXBiDJjJK3GqWRREE=.77fc9c8d-efed-47e8-8f53-02255da6e97e@github.com>
Message-ID: <uz8GwSfLLDJa8FwDhUBymXo4YkgbnT59TEjSYdHv15Y=.7cc79134-b687-477b-8e72-7dc65cfa8ef7@github.com>

On Sat, 13 Mar 2021 06:16:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> But I don't understand why this error can happen. It seems like jtreg would allow two test cases to interfere with each other.

The root cause seems to be https://bugs.openjdk.java.net/browse/CODETOOLS-7902847

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

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

From dcubed at openjdk.java.net  Sat Mar 13 14:23:08 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 13 Mar 2021 14:23:08 GMT
Subject: RFR: 8263549:  8263412 can cause jtreg testlibrary split [v3]
In-Reply-To: <c3UIWUcXOnH5Hd_Th0_YIiKCTklnxTtWFyPOC6QfCpQ=.dae1c7f3-0f63-4047-9df9-79ab0e2306f8@github.com>
References: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com>
 <c3UIWUcXOnH5Hd_Th0_YIiKCTklnxTtWFyPOC6QfCpQ=.dae1c7f3-0f63-4047-9df9-79ab0e2306f8@github.com>
Message-ID: <HflI5BUCqXAwVWrhyNcQFIwzvsdBUcUX7AB6Xp5RxQU=.5439c807-612d-4c01-b502-6e075ca70ab2@github.com>

On Sat, 13 Mar 2021 06:44:12 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this dull patch that replaces `ClassFileInstaller` w/ `jdk.test.lib.helpers.ClassFileInstaller` in all jtreg test descriptions to ensure we won't get split testlibrary, and removes `jdk/test/lib/ClassFileInstaller.java` (so it won't be accidentally used).
>> 
>> from JBS:
>>> after JDK-8263412, we might (again) encounter NCDFE b/c parts of testlibraries aren't on the classpath. this happens when jtreg builds `jdk.test.lib.helpers.ClassFileInstaller` as a part of test-specific code, but `ClassFileInstaller` as part of shared testibrary directory in one test, when in the following test, jtreg sees `ClassFileInstaller` in the shared directory, hence javac won't recompile it/its dependencies, but in runtime `jdk.test.lib.helpers.ClassFileInstaller` is nowhere to be found, hence we get NCDFE. 
>> 
>> testing:
>> - [x]  `grep ' ClassFileInstaller[^.]`
>> - [ ] tier1-3
>> 
>> Thanks,
>> -- Igor
>
> Igor Ignatyev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

I downloaded the patch and used Ioi's cmd pattern to scroll through
the changes. I can't honestly say that I looked at every line since 867
changed files would overwhelm anyone's brain...

I did notice a couple of `@run main` instead of `@run driver` calls
to the ClassFileInstaller, but those are pre-existing.

Thumbs up.

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

Marked as reviewed by dcubed (Reviewer).

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

From iignatyev at openjdk.java.net  Sat Mar 13 14:56:07 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Sat, 13 Mar 2021 14:56:07 GMT
Subject: Integrated: 8263549:  8263412 can cause jtreg testlibrary split
In-Reply-To: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com>
References: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com>
Message-ID: <_mpUEh9QVZbxsshQP1hNQlstVSmOwqImgOwhZV4lvIQ=.f49472ae-9d8e-4058-beb8-77e0f7b4fd3a@github.com>

On Sat, 13 Mar 2021 04:31:31 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this dull patch that replaces `ClassFileInstaller` w/ `jdk.test.lib.helpers.ClassFileInstaller` in all jtreg test descriptions to ensure we won't get split testlibrary, and removes `jdk/test/lib/ClassFileInstaller.java` (so it won't be accidentally used).
> 
> from JBS:
>> after JDK-8263412, we might (again) encounter NCDFE b/c parts of testlibraries aren't on the classpath. this happens when jtreg builds `jdk.test.lib.helpers.ClassFileInstaller` as a part of test-specific code, but `ClassFileInstaller` as part of shared testibrary directory in one test, when in the following test, jtreg sees `ClassFileInstaller` in the shared directory, hence javac won't recompile it/its dependencies, but in runtime `jdk.test.lib.helpers.ClassFileInstaller` is nowhere to be found, hence we get NCDFE. 
> 
> testing:
> - [x]  `grep ' ClassFileInstaller[^.]`
> - [ ] tier1-3
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: a7aba2b6
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a7aba2b6
Stats:     1738 lines in 867 files changed: 2 ins; 67 del; 1669 mod

8263549: 8263412 can cause jtreg testlibrary split

Reviewed-by: iklam, dcubed

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

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

From iignatyev at openjdk.java.net  Sat Mar 13 14:56:06 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Sat, 13 Mar 2021 14:56:06 GMT
Subject: RFR: 8263549:  8263412 can cause jtreg testlibrary split [v3]
In-Reply-To: <HflI5BUCqXAwVWrhyNcQFIwzvsdBUcUX7AB6Xp5RxQU=.5439c807-612d-4c01-b502-6e075ca70ab2@github.com>
References: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com>
 <c3UIWUcXOnH5Hd_Th0_YIiKCTklnxTtWFyPOC6QfCpQ=.dae1c7f3-0f63-4047-9df9-79ab0e2306f8@github.com>
 <HflI5BUCqXAwVWrhyNcQFIwzvsdBUcUX7AB6Xp5RxQU=.5439c807-612d-4c01-b502-6e075ca70ab2@github.com>
Message-ID: <cWG4uOCEDr5X77Jm1uCxyw-Z1jjgtU4JUsieDCX1py0=.c6cea055-3a06-4a73-aa82-53fe44e0fd77@github.com>

On Sat, 13 Mar 2021 14:20:20 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Igor Ignatyev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.
>
> I downloaded the patch and used Ioi's cmd pattern to scroll through
> the changes. I can't honestly say that I looked at every line since 867
> changed files would overwhelm anyone's brain...
> 
> I did notice a couple of `@run main` instead of `@run driver` calls
> to the ClassFileInstaller, but those are pre-existing.
> 
> Thumbs up.

Hi Dan,

Thanks for your review!

> I did notice a couple of @run main instead of @run driver calls to the ClassFileInstaller, but those are pre-existing.

I noticed this too, planning to fix that with a separate RFE.

-- Igor

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

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

From cjplummer at openjdk.java.net  Sat Mar 13 22:55:06 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Sat, 13 Mar 2021 22:55:06 GMT
Subject: Integrated: 8263477: serviceability/sa/ClhsdbDumpheap.java timed out
In-Reply-To: <vkzHCK8TweXBo2qyYIum1wqBAZ_t_hJ5RCIiPmh7OJ4=.3e780eba-800e-4a65-a72b-fc1ed2c8cb1f@github.com>
References: <vkzHCK8TweXBo2qyYIum1wqBAZ_t_hJ5RCIiPmh7OJ4=.3e780eba-800e-4a65-a72b-fc1ed2c8cb1f@github.com>
Message-ID: <Wldhwo9xaazpV8ukalMnvADroF7-Xuk1YByxfiBg6wc=.9e7e431c-0436-4f65-a0dc-ed144c58a80d@github.com>

On Fri, 12 Mar 2021 23:44:22 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> [JDK-8257234](https://bugs.openjdk.java.net/browse/JDK-8257234) added a lot more subtests to this test, so now it sometimes times out. I've double the amount of time given to 240. I'd like to push this as a trivial change.

This pull request has now been integrated.

Changeset: 8e562d26
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8e562d26
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8263477: serviceability/sa/ClhsdbDumpheap.java timed out

Reviewed-by: lmesnik, dcubed

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

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

From ysuenaga at openjdk.java.net  Mon Mar 15 05:29:12 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Mon, 15 Mar 2021 05:29:12 GMT
Subject: RFR: 8263565: NPE was thrown when
 sun.jvm.hotspot.rmi.serverNamePrefix was set
Message-ID: <h7RuyZ_VM6x6IdDGSictAFUFZJ8C87UuUJIbjpJ_yWs=.94f55574-c7df-4af8-96c5-0c0ac7ced239@github.com>

NPE was thrown when I set server name prefix for debugd as following:

$ jhsdb -J-Dsun.jvm.hotspot.rmi.serverNamePrefix=test debugd --pid 781
Attaching to process ID 781 and starting RMI services, please wait...
Error attaching to process or starting server: sun.jvm.hotspot.debugger.DebuggerException: java.lang.NullPointerException: Cannot invoke "String.length()" because "this.input" is null
        at jdk.hotspot.agent/sun.jvm.hotspot.RMIHelper.rebind(RMIHelper.java:78)
        at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.setupDebugger(HotSpotAgent.java:379)
        at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:329)
        at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.startServer(HotSpotAgent.java:215)
        at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runDEBUGD(SALauncher.java:431)
        at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:493)
Caused by: java.lang.NullPointerException: Cannot invoke "String.length()" because "this.input" is null
        at java.base/java.net.URI$Parser.parse(URI.java:3166)
        at java.base/java.net.URI.<init>(URI.java:623)
        at java.rmi/java.rmi.Naming.intParseURL(Naming.java:273)
        at java.rmi/java.rmi.Naming.parseURL(Naming.java:237)
        at java.rmi/java.rmi.Naming.rebind(Naming.java:171)
        at jdk.hotspot.agent/sun.jvm.hotspot.RMIHelper.rebind(RMIHelper.java:64)
        ... 5 more

`serverNamePrefix` would not affect due to trivial bug.

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

Commit messages:
 - 8263565: NPE was thrown when sun.jvm.hotspot.rmi.serverNamePrefix was set

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

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

From ksakata at openjdk.java.net  Mon Mar 15 07:34:18 2021
From: ksakata at openjdk.java.net (Koichi Sakata)
Date: Mon, 15 Mar 2021 07:34:18 GMT
Subject: RFR: 8263572: Output from jstack mixed mode is misaligned
Message-ID: <LiAjqiWikfy0llyWM79wX1pZQO4JkNsO8WwjWqcAAKg=.e177e030-08cf-42cd-aaee-27d530b5ed02@github.com>

When running jstack with mixed option, the output of the lines that doesn't have an address are misaligned as followings. 

$ sudo jhsdb jstack --mixed --pid 5905
----------------- 5955 -----------------
"event-handler" #20 daemon prio=5 tid=0x00007f133079a970 nid=0x1743 in Object.wait() [0x00007f1308bfe000]
   java.lang.Thread.State: WAITING (on object monitor)
   JavaThread state: _thread_blocked
0x00007f133a85b9f3 __pthread_cond_wait + 0x243
0x00007f133940b75b os::PlatformEvent::park() + 0x8b
0x00007f13393b7b2d ObjectMonitor::wait(long, bool, Thread*) + 0xf4d
0x00007f13397f0b95 ObjectSynchronizer::wait(Handle, long, Thread*) + 0x85
0x00007f1338e85961 JVM_MonitorWait + 0x241
0x00007f1328b264b7 java.lang.Object.wait(long) + 0xd7 (Native method)
0x00007f132177b3c4 * java.lang.Object.wait() bci:2 line:338 (Compiled frame)
* com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(long) bci:64 line:190 (Compiled frame)
* com.sun.tools.jdi.EventQueueImpl.remove(long) bci:18 line:97 (Interpreted frame)
0x00007f1321009543 * com.sun.tools.jdi.EventQueueImpl.remove() bci:2 line:83 (Interpreted frame)

This pull request aligns the indentation. So It will be able to improve readability.

In this pull request the address part is filled with white spaces. The amount of space is calculated from VM's logarithmic address size and lastly 2, which is the length of "0x", is added.

I checked the output on 64-bit and 32-bit OS.

0x00007f596cb2a6b7      java.lang.Object.wait(long) + 0xd7 (Native method)
0x00007f5965791ec4      * java.lang.Object.wait() bci:2 line:338 (Compiled frame)
                        * com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(long) bci:64 line:190 (Compiled frame)
                        * com.sun.tools.jdi.EventQueueImpl.remove(long) bci:18 line:97 (Interpreted frame)
0x00007f5965009543      * com.sun.tools.jdi.EventQueueImpl.remove() bci:2 line:83 (Interpreted frame)
0x00007f59650099b3      * jdk.jshell.execution.JdiEventHandler.run() bci:18 line:79 (Interpreted frame)
0x00007f596500985a      * java.lang.Thread.run() bci:11 line:831 (Interpreted frame)

0x035002d4      java.lang.Object.wait(long) + 0x94 (Native method)
0x034fcd3c      * java.lang.Object.wait() bci:2 line:338 (Compiled frame)
                * com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(long) bci:64 line:190 (Compiled frame)
                * com.sun.tools.jdi.EventQueueImpl.remove(long) bci:18 line:97 (Interpreted frame)
0x03296839      * com.sun.tools.jdi.EventQueueImpl.remove() bci:2 line:83 (Interpreted frame)

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

Commit messages:
 - Format the output from JStack mixed mode

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

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

From lzang at openjdk.java.net  Mon Mar 15 08:50:35 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 15 Mar 2021 08:50:35 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v4]
In-Reply-To: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
Message-ID: <hCno7IM_Y_wbTbStzZ2ByLxeUghZm5g2t0AgqsHGDHE=.04431085-2671-43d4-86e4-7c40911846e2@github.com>

> 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out

Lin Zang 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:

 - Merge branch 'master' into sf
 - Revert "reduce memory consumption"
   
   This reverts commit 70e43ddd453724ce36bf729fa6489c0027957b8e.
 - reduce memory consumption
 - code refine
 - 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2803/files
  - new: https://git.openjdk.java.net/jdk/pull/2803/files/8dde2fdd..6019b1fa

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

  Stats: 37140 lines in 1521 files changed: 27477 ins; 5213 del; 4450 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2803.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2803/head:pull/2803

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

From lzang at openjdk.java.net  Mon Mar 15 08:52:26 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 15 Mar 2021 08:52:26 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v16]
In-Reply-To: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
Message-ID: <elLr3Rwbe0LAO9pGJvxViTVJ4Ug9cANURDYZ1iTay_k=.9cf39543-734d-4d40-a82a-33d813603c41@github.com>

> 8252842: Extend jmap to support parallel heap dump

Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Merge branch 'master' into par-dump
 - code clean
 - fix trailing white space issue
 - reduce memory consumption and fix memory leak issue
 - Revise jmap help info
 - Merge master
 - fix build fail issue on windows
 - hide the dumpheapext error message
 - Merge branch 'master' into pd
 - use parallel= option instead of noparallel
 - ... and 8 more: https://git.openjdk.java.net/jdk/compare/8afec70c...de051006

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

Changes: https://git.openjdk.java.net/jdk/pull/2261/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=15
  Stats: 997 lines in 6 files changed: 797 ins; 58 del; 142 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2261.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2261/head:pull/2261

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

From rehn at openjdk.java.net  Mon Mar 15 11:53:20 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Mon, 15 Mar 2021 11:53:20 GMT
Subject: RFR: 8261262: Kitchensink24HStress.java crashed with
 EXCEPTION_ACCESS_VIOLATION
Message-ID: <N8sz_MwKWT2BdcrSQcU0_-2dUm30_AED4dtfUwLkGd0=.e11ba713-3da7-4fe0-ae03-062ec989e1f6@github.com>

When returning from the last Java frame back to vm and hitting a safepoint poll on that last return we sometimes have a last java frame but no vframe.
This seem to be a bug in itself, handled in: 8263576

Other places which uses vframe NULL checks it before, so let's do that in GetCurrentLocationClosure also.

Testing: nsk jdi/jvmti, jdk jdi, jck vm and t1-3.

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

Commit messages:
 - Check vframe non-null

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

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

From stefank at openjdk.java.net  Mon Mar 15 12:43:26 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 15 Mar 2021 12:43:26 GMT
Subject: RFR: 8263589: Introduce JavaValue::get_oop/set_oop
Message-ID: <cHg8Tu9u24ge_ElzmF1cKNaR-83zPPlX6y1ZXFvJz7Q=.5c529a35-707c-4b17-be9f-badd523111f3@github.com>

JavaValue is a small wrapper class that wraps values used to pass arguments and results between native and Java.

When JavaCalls::call returns an object, the value stored in the JavaValue is not a handliezed jobject. Instead it's a raw oop. So, most of the code handling the `result`, fetches the result as a jobject, and then immediately casts it to an oop. For example:
  oop res = (oop)result.get_jobject();

I'd like to change this code to be:
  oop res = result.get_oop();

The motivations for this patch is:

1) Minimize the places where we pass around oops in jobject variables. Maybe at some point we'll have converted the JVM to only use the jobject type when passing around JNI handle. We need to be stricter with the types when we continue develop our GCs and their barriers.

2) Limit the number of places in the code where we perform raw oop casts. We have a helper cast function for that, cast_to_oop, but not all code use it. I have future patches where the compiler will completely forbid raw cast to oops (in fastdebug builds). With that in place, I can then add more stricter oop verification code when oops are created. This helps catching bugs earlier.

---

When reviewing this patch, take an extra look at the change  to oopsHierarchy.hpp. This was done to support jvmciEnv.cpp code:
  JVMCIObject wrap(oop obj)...
  JVMCIObjectArray wrap(objArrayOop obj)...
  JVMCIPrimitiveArray wrap(typeArrayOop obj) ...
Previously, `wrap((oop)result.get_jobject())` called the first function. When the code was changed to `wrap(result.get_oop())`, where `get_oop()` returns a `oopDesc*`, the compiler didn't know what conversion in oopsHierarchy.hpp to use. Therefore, I replaced the overly permissive `void*` constructor with a constructor that only takes the corresponding `type##OopDesc*`.

An alternative would be to let get_oop() return an oop, but then that would add an unwanted a dependency between globalDefinitions.hpp and  oopsHierarchy.hpp. An earlier version of this patch did return an oop instead of oopDesc*, but it also moved entire JavaValue class out of globalDefinitions.hpp into a new javaValue.hpp file, and had a corresponding javaValue.inline.hpp file.

Even if we end up using the proposed `oopDesc* get_oop()` version, maybe moving the class to javaValues.hpp would still makes sense?

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

Commit messages:
 - Commit unstaged changes
 - 8263589: Introduce JavaValue::get_oop/set_oop

Changes: https://git.openjdk.java.net/jdk/pull/3013/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3013&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263589
  Stats: 72 lines in 26 files changed: 5 ins; 0 del; 67 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3013.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3013/head:pull/3013

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

From jboes at openjdk.java.net  Mon Mar 15 12:55:11 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Mon, 15 Mar 2021 12:55:11 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy
In-Reply-To: <klPrlAvPsVYcAtWjox3cWGgbEIjbHXoaFtYu7iBPCxc=.22a22c0a-7d04-4abf-b9ff-0e2a423a6b18@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <5s4i5725zJd8QrefwYyc8sn2fQXad3hAGLVflkFttmY=.abe55236-e258-482b-b8be-be75e1eb086c@github.com>
 <klPrlAvPsVYcAtWjox3cWGgbEIjbHXoaFtYu7iBPCxc=.22a22c0a-7d04-4abf-b9ff-0e2a423a6b18@github.com>
Message-ID: <yTKkQHWG8Qd3WtteVvA2tqZz4hH1c_qA1jOhtHl9NjM=.6d67bde5-0fa3-4973-857b-f539cab13a32@github.com>

On Thu, 18 Feb 2021 07:12:34 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> Hi @turbanoff, I'm happy to sponsor but I see two comments by @marschall - have they been addressed?
>> https://github.com/openjdk/jdk/pull/1853#discussion_r572815422
>> https://github.com/openjdk/jdk/pull/1853#discussion_r572380746
>
> @FrauBoes fixed in the last commit. Is there any way to de-_integrate_ PR (to include last commit)?

@turbanoff Given that this PR has been lingering for a while, you could drop the change in `X509CertPath.java` for now and integrate the remaining changes. I'm happy to sponsor in that case.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Mar 15 14:50:24 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 15 Mar 2021 14:50:24 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v13]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <IuYcSqYk7zxG7hAU605DouLqEQ7zCfLH1VsulI-Zk0A=.aeb9dcfd-d720-4fd2-9577-8bc454dd77a1@github.com>

> 8080272  Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy
  drop changes in X509CertPath

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/1b30471d..96920ee6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=11-12

  Stats: 25 lines in 1 file changed: 22 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

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

From akozlov at openjdk.java.net  Mon Mar 15 18:23:35 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 15 Mar 2021 18:23:35 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v28]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <hz2vrgXQiBRvuTHp7eiZpkHoAcoMYXlEk-X-hfoJsYo=.a43951e9-c93b-4659-b2b1-ecfdedffad20@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 114 commits:

 - JDK-8262491: bsd_aarch64 part
 - JDK-8263002: bsd_aarch64 part
 - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
 - Wider #ifdef block
 - Fix most of issues in java/foreign/ tests
   
   Failures related to va_args are tracked in JDK-8263512.
 - Add Azul copyright
 - Update Oracle copyright years
 - Use Thread::current_or_null_safe in SafeFetch
 - 8262903: [macos_aarch64] Thread::current() called on detached thread
 - Merge commit 'refs/pull/11/head' of https://github.com/AntonKozlov/jdk into jdk-macos
 - ... and 104 more: https://git.openjdk.java.net/jdk/compare/d825198e...806fc618

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

Changes: https://git.openjdk.java.net/jdk/pull/2200/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=27
  Stats: 2949 lines in 75 files changed: 2839 ins; 27 del; 83 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

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

From cjplummer at openjdk.java.net  Mon Mar 15 18:50:10 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 15 Mar 2021 18:50:10 GMT
Subject: RFR: 8263565: NPE was thrown when
 sun.jvm.hotspot.rmi.serverNamePrefix was set
In-Reply-To: <h7RuyZ_VM6x6IdDGSictAFUFZJ8C87UuUJIbjpJ_yWs=.94f55574-c7df-4af8-96c5-0c0ac7ced239@github.com>
References: <h7RuyZ_VM6x6IdDGSictAFUFZJ8C87UuUJIbjpJ_yWs=.94f55574-c7df-4af8-96c5-0c0ac7ced239@github.com>
Message-ID: <-T97PgdhcBLuWZjkxqtWvE0M-XQKxqC0CJBY88mViKg=.e0a6ba57-7b1e-41ad-961b-0e465710eba6@github.com>

On Mon, 15 Mar 2021 02:01:12 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> NPE was thrown when I set server name prefix for debugd as following:
> 
> $ jhsdb -J-Dsun.jvm.hotspot.rmi.serverNamePrefix=test debugd --pid 781
> Attaching to process ID 781 and starting RMI services, please wait...
> Error attaching to process or starting server: sun.jvm.hotspot.debugger.DebuggerException: java.lang.NullPointerException: Cannot invoke "String.length()" because "this.input" is null
>         at jdk.hotspot.agent/sun.jvm.hotspot.RMIHelper.rebind(RMIHelper.java:78)
>         at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.setupDebugger(HotSpotAgent.java:379)
>         at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:329)
>         at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.startServer(HotSpotAgent.java:215)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runDEBUGD(SALauncher.java:431)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:493)
> Caused by: java.lang.NullPointerException: Cannot invoke "String.length()" because "this.input" is null
>         at java.base/java.net.URI$Parser.parse(URI.java:3166)
>         at java.base/java.net.URI.<init>(URI.java:623)
>         at java.rmi/java.rmi.Naming.intParseURL(Naming.java:273)
>         at java.rmi/java.rmi.Naming.parseURL(Naming.java:237)
>         at java.rmi/java.rmi.Naming.rebind(Naming.java:171)
>         at jdk.hotspot.agent/sun.jvm.hotspot.RMIHelper.rebind(RMIHelper.java:64)
>         ... 5 more
> 
> `serverNamePrefix` would not affect due to trivial bug.

The fix looks fine. It would be nice if this was documented somewhere (and even tested). Also, while looking into this I noticed the following comment:

        // debugServerID follows the pattern [unique_id@]host[:port]
        // we have to transform this as //host[:port]/<serverNamePrefix>['_'<unique_id>]

The `[:port]` part is also not document, not even in the command line syntax for `sadebugd`

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

Marked as reviewed by cjplummer (Reviewer).

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

From jboes at openjdk.java.net  Mon Mar 15 18:52:17 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Mon, 15 Mar 2021 18:52:17 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy
In-Reply-To: <klPrlAvPsVYcAtWjox3cWGgbEIjbHXoaFtYu7iBPCxc=.22a22c0a-7d04-4abf-b9ff-0e2a423a6b18@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <5s4i5725zJd8QrefwYyc8sn2fQXad3hAGLVflkFttmY=.abe55236-e258-482b-b8be-be75e1eb086c@github.com>
 <klPrlAvPsVYcAtWjox3cWGgbEIjbHXoaFtYu7iBPCxc=.22a22c0a-7d04-4abf-b9ff-0e2a423a6b18@github.com>
Message-ID: <4Bae_Uh8Zakn4cnmbXkUcV9xRTus1hgHCEPVthHuEyc=.fb959963-ff7a-4067-b888-e178d9f70e91@github.com>

On Thu, 18 Feb 2021 07:12:34 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> Hi @turbanoff, I'm happy to sponsor but I see two comments by @marschall - have they been addressed?
>> https://github.com/openjdk/jdk/pull/1853#discussion_r572815422
>> https://github.com/openjdk/jdk/pull/1853#discussion_r572380746
>
> @FrauBoes fixed in the last commit. Is there any way to de-_integrate_ PR (to include last commit)?

@turbanoff  Tier 1-3 still all clear. If you /integrate, I will sponsor this tomorrow.

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

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

From akozlov at openjdk.java.net  Mon Mar 15 18:56:18 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 15 Mar 2021 18:56:18 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12]
In-Reply-To: <3NYUmXmjyZFhGJwrHfEjSRX1VRaPjt5cCp9HRBxODbM=.4880b6d1-f6dd-45db-95f4-9064e9204d87@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <Vg27jHtpjAQ36mYoE5MyolUJUi8K9lSb_c3grH_DLvM=.df18633b-2124-44b0-ac51-e5405a3f745d@github.com>
 <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com>
 <Dze4ZtrPI_OLkuExMIN1fl5u6eCryLmgNRgAHzN2kXE=.eee71cb4-1c81-46f8-b6ae-063659a28fc2@github.com>
 <3NYUmXmjyZFhGJwrHfEjSRX1VRaPjt5cCp9HRBxODbM=.4880b6d1-f6dd-45db-95f4-9064e9204d87@github.com>
Message-ID: <v4LN5mBL_UaL1YxXlwj4CLuvo9lQU5yHY_3e5MQQ1g8=.0783fcae-d399-4a76-94e7-73ef68133941@github.com>

On Thu, 11 Mar 2021 20:27:51 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The thread_bsd_aarch64.hpp describes a part of JavaThread, while this block belongs to Thread for now. Since W^X is an attribute of any operating system thread, I assumed Thread to be the right place for W^X bookkeeping. 
>> 
>> In most cases, we manage W^X state of JavaThread. But sometimes a GC thread needs the WXWrite state, or safefetch is called from non-JavaThread. Probably this can be dealt with (e.g. GCThread to always have the WXWrite state). But such change would be much more than a simple refactoring and it would require a significant amount of testing. Ideally, I would like to investigate this as a follow-up change, or at least after other fixes to this PR.
>
> Good point about Thread vs JavaThread. Yes, this can be looked into as follow-up cleanups.

The enhancement is tracked in https://bugs.openjdk.java.net/browse/JDK-8263492

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

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

From akozlov at openjdk.java.net  Mon Mar 15 18:56:17 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 15 Mar 2021 18:56:17 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v21]
In-Reply-To: <SXXcMmMTXbltmXqeaDgF6g8EJvECwqtlNokXpNJ0CNI=.f358e952-3186-4503-a632-834ec4343c6d@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <ZfRwLBDhh3K6u3NaWzLWVyoYqBuZVJbipXCZKzPclBs=.bedc9c24-2178-400a-8868-fbbb61b298cc@github.com>
 <yMUjWudRugP8LTAT5fuc25Q7R1M9iTCBFMFvXGjRWlQ=.2a6cf189-5bb6-4f41-9e49-d859b85534b6@github.com>
 <v33sSQcIVsvidIkYzaOsIhkjNhojCVastBXuUJJ67IM=.9123e430-657f-4c24-a201-4f457232c983@github.com>
 <SXXcMmMTXbltmXqeaDgF6g8EJvECwqtlNokXpNJ0CNI=.f358e952-3186-4503-a632-834ec4343c6d@github.com>
Message-ID: <4EryfweVy9Q97cbm7rAcsSIXuK2XImbIfuPeloJuXEA=.90a1f396-299c-43d2-922b-9af36ca43467@github.com>

On Wed, 10 Mar 2021 11:21:44 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> We always check for `R18_RESERVED` with `#if(n)def`, is there any reason to define the value for the macro?
>
> Robustness, clarity, maintainability, convention. Why not?

I've tried to implement the suggestion, but it pulled more unnecessary changes. It makes the intended way to check the condition less clear (`#ifdef` and not `#if`). The rest of the defines in this file follows the pattern: a define without a value to be checked with `#ifdef` and define with a value to be checked with `#if`. To be consistent, I would need to add `#define R18_RESERVED false` to the `#else` clause and change every `#ifdef R18_RESERVED`/`#ifndef R18_RESERVED` to `#if R18_RESERVED`/`#if !R18_RESERVED`. I think we'll win in clarity in the long term if I will not implement the suggestion without related changes. (And related changes would introduce additional noise, which we are fighting with).

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

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

From akozlov at openjdk.java.net  Mon Mar 15 18:56:23 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 15 Mar 2021 18:56:23 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v28]
In-Reply-To: <FB2pev3OL8y-AYtFw1i8n3Np5ny9bYb8wdduqVtiXhA=.84f450cc-6891-4a0b-a84d-1abb8a2eaf00@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <TRklBppvcFXK3TUe1dkT2FCn2b9m57pRFAGHR-Vt-8U=.13d4dcc9-deb4-4227-95ec-d9c7a8fc279d@github.com>
 <FB2pev3OL8y-AYtFw1i8n3Np5ny9bYb8wdduqVtiXhA=.84f450cc-6891-4a0b-a84d-1abb8a2eaf00@github.com>
Message-ID: <0dFnMCcGeahDTezdMqNQ2ZtipjeEaCpNezow6Kqy5xE=.ec72c0d8-8252-4abf-ab7a-8ce4b89ca527@github.com>

On Sat, 13 Mar 2021 05:49:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 114 commits:
>> 
>>  - JDK-8262491: bsd_aarch64 part
>>  - JDK-8263002: bsd_aarch64 part
>>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>>  - Wider #ifdef block
>>  - Fix most of issues in java/foreign/ tests
>>    
>>    Failures related to va_args are tracked in JDK-8263512.
>>  - Add Azul copyright
>>  - Update Oracle copyright years
>>  - Use Thread::current_or_null_safe in SafeFetch
>>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>>  - Merge commit 'refs/pull/11/head' of https://github.com/AntonKozlov/jdk into jdk-macos
>>  - ... and 104 more: https://git.openjdk.java.net/jdk/compare/d825198e...806fc618
>
> src/hotspot/share/runtime/safefetch.inline.hpp line 35:
> 
>> 33: inline int SafeFetch32(int* adr, int errValue) {
>> 34:   assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated");
>> 35:   Thread* thread = Thread::current_or_null_safe();
> 
> Sorry but this should be MACOS_AARCH64 only. All three lines need to be ifdef'd if you are going to include the assertion.
> 
> Thanks,
> David

Right, thanks! Fixed in https://github.com/openjdk/jdk/pull/2200/commits/3d0f4d2342adc867eaf762fa83a9c3035d6439bd

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

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

From cjplummer at openjdk.java.net  Mon Mar 15 19:25:08 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 15 Mar 2021 19:25:08 GMT
Subject: RFR: 8263572: Output from jstack mixed mode is misaligned
In-Reply-To: <LiAjqiWikfy0llyWM79wX1pZQO4JkNsO8WwjWqcAAKg=.e177e030-08cf-42cd-aaee-27d530b5ed02@github.com>
References: <LiAjqiWikfy0llyWM79wX1pZQO4JkNsO8WwjWqcAAKg=.e177e030-08cf-42cd-aaee-27d530b5ed02@github.com>
Message-ID: <zzzXtXaBXSToz6gz_wS5wRTkr_up1vwa7_vywLbYUMY=.5d9441b0-f92c-448c-818c-8eed4a73ed89@github.com>

On Mon, 15 Mar 2021 07:29:16 GMT, Koichi Sakata <ksakata at openjdk.org> wrote:

> When running jstack with mixed option, the output of the lines that doesn't have an address are misaligned as followings. 
> 
> $ sudo jhsdb jstack --mixed --pid 5905
> ----------------- 5955 -----------------
> "event-handler" #20 daemon prio=5 tid=0x00007f133079a970 nid=0x1743 in Object.wait() [0x00007f1308bfe000]
>    java.lang.Thread.State: WAITING (on object monitor)
>    JavaThread state: _thread_blocked
> 0x00007f133a85b9f3 __pthread_cond_wait + 0x243
> 0x00007f133940b75b os::PlatformEvent::park() + 0x8b
> 0x00007f13393b7b2d ObjectMonitor::wait(long, bool, Thread*) + 0xf4d
> 0x00007f13397f0b95 ObjectSynchronizer::wait(Handle, long, Thread*) + 0x85
> 0x00007f1338e85961 JVM_MonitorWait + 0x241
> 0x00007f1328b264b7 java.lang.Object.wait(long) + 0xd7 (Native method)
> 0x00007f132177b3c4 * java.lang.Object.wait() bci:2 line:338 (Compiled frame)
> * com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(long) bci:64 line:190 (Compiled frame)
> * com.sun.tools.jdi.EventQueueImpl.remove(long) bci:18 line:97 (Interpreted frame)
> 0x00007f1321009543 * com.sun.tools.jdi.EventQueueImpl.remove() bci:2 line:83 (Interpreted frame)
> 
> This pull request aligns the indentation. So It will be able to improve readability.
> 
> In this pull request the address part is filled with white spaces. The amount of space is calculated from VM's logarithmic address size and lastly 2, which is the length of "0x", is added.
> 
> I checked the output on 64-bit and 32-bit OS.
> 
> 0x00007f596cb2a6b7      java.lang.Object.wait(long) + 0xd7 (Native method)
> 0x00007f5965791ec4      * java.lang.Object.wait() bci:2 line:338 (Compiled frame)
>                         * com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(long) bci:64 line:190 (Compiled frame)
>                         * com.sun.tools.jdi.EventQueueImpl.remove(long) bci:18 line:97 (Interpreted frame)
> 0x00007f5965009543      * com.sun.tools.jdi.EventQueueImpl.remove() bci:2 line:83 (Interpreted frame)
> 0x00007f59650099b3      * jdk.jshell.execution.JdiEventHandler.run() bci:18 line:79 (Interpreted frame)
> 0x00007f596500985a      * java.lang.Thread.run() bci:11 line:831 (Interpreted frame)
> 
> 0x035002d4      java.lang.Object.wait(long) + 0x94 (Native method)
> 0x034fcd3c      * java.lang.Object.wait() bci:2 line:338 (Compiled frame)
>                 * com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(long) bci:64 line:190 (Compiled frame)
>                 * com.sun.tools.jdi.EventQueueImpl.remove(long) bci:18 line:97 (Interpreted frame)
> 0x03296839      * com.sun.tools.jdi.EventQueueImpl.remove() bci:2 line:83 (Interpreted frame)

What testing have you done?

Please update the copyright to 2021.

I noticed that in you original jstack output there is only 1 space after the address, and now there appears to be multiple spaces. However, when I produce the jstack out there's already multiple spaces. Was there some formatting issue with your original output?

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PStack.java line 172:

> 170:                          // print java frame(s)
> 171:                          for (int i = 0; i < names.length; i++) {
> 172:                              if (0 < i) {

Please use `i > 0`

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PStack.java line 85:

> 83:         }
> 84:          final boolean cdbgCanDemangle = cdbg.canDemangle();
> 85:          String fillerForAddress = " ".repeat(2 + (2 << VM.getVM().getLogAddressSize())) + "\t";

Why not use `2 * VM.getVM().getAddressSize()` rather than `(2 << VM.getVM().getLogAddressSize()`?

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

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

From coleenp at openjdk.java.net  Mon Mar 15 21:31:08 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 15 Mar 2021 21:31:08 GMT
Subject: RFR: 8263589: Introduce JavaValue::get_oop/set_oop
In-Reply-To: <cHg8Tu9u24ge_ElzmF1cKNaR-83zPPlX6y1ZXFvJz7Q=.5c529a35-707c-4b17-be9f-badd523111f3@github.com>
References: <cHg8Tu9u24ge_ElzmF1cKNaR-83zPPlX6y1ZXFvJz7Q=.5c529a35-707c-4b17-be9f-badd523111f3@github.com>
Message-ID: <73KvQ-wIvi6mX-538ngdN0mHKFs30QI7Y57TFHsfRLM=.89d76b9a-1b3d-401c-a942-86776321c1f9@github.com>

On Mon, 15 Mar 2021 12:35:47 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> JavaValue is a small wrapper class that wraps values used to pass arguments and results between native and Java.
> 
> When JavaCalls::call returns an object, the value stored in the JavaValue is not a handliezed jobject. Instead it's a raw oop. So, most of the code handling the `result`, fetches the result as a jobject, and then immediately casts it to an oop. For example:
>   oop res = (oop)result.get_jobject();
> 
> I'd like to change this code to be:
>   oop res = result.get_oop();
> 
> The motivations for this patch is:
> 
> 1) Minimize the places where we pass around oops in jobject variables. Maybe at some point we'll have converted the JVM to only use the jobject type when passing around JNI handle. We need to be stricter with the types when we continue develop our GCs and their barriers.
> 
> 2) Limit the number of places in the code where we perform raw oop casts. We have a helper cast function for that, cast_to_oop, but not all code use it. I have future patches where the compiler will completely forbid raw cast to oops (in fastdebug builds). With that in place, I can then add more stricter oop verification code when oops are created. This helps catching bugs earlier.
> 
> ---
> 
> When reviewing this patch, take an extra look at the change  to oopsHierarchy.hpp. This was done to support jvmciEnv.cpp code:
>   JVMCIObject wrap(oop obj)...
>   JVMCIObjectArray wrap(objArrayOop obj)...
>   JVMCIPrimitiveArray wrap(typeArrayOop obj) ...
> Previously, `wrap((oop)result.get_jobject())` called the first function. When the code was changed to `wrap(result.get_oop())`, where `get_oop()` returns a `oopDesc*`, the compiler didn't know what conversion in oopsHierarchy.hpp to use. Therefore, I replaced the overly permissive `void*` constructor with a constructor that only takes the corresponding `type##OopDesc*`.
> 
> An alternative would be to let get_oop() return an oop, but then that would add an unwanted a dependency between globalDefinitions.hpp and  oopsHierarchy.hpp. An earlier version of this patch did return an oop instead of oopDesc*, but it also moved entire JavaValue class out of globalDefinitions.hpp into a new javaValue.hpp file, and had a corresponding javaValue.inline.hpp file.
> 
> Even if we end up using the proposed `oopDesc* get_oop()` version, maybe moving the class to javaValues.hpp would still makes sense?

This change looks really good to me.  I have no objection to oopDesc* in JavaCallValue.  We use oopDesc* in all places where the class oop would interfere with values passed between Java and the vm.

src/hotspot/share/utilities/globalDefinitions.hpp line 809:

> 807:     jint     i;
> 808:     jlong    l;
> 809:     jobject  h;

Do we still need jobject after this change?

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

Marked as reviewed by coleenp (Reviewer).

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

From coleenp at openjdk.java.net  Mon Mar 15 21:36:10 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 15 Mar 2021 21:36:10 GMT
Subject: RFR: 8263589: Introduce JavaValue::get_oop/set_oop
In-Reply-To: <73KvQ-wIvi6mX-538ngdN0mHKFs30QI7Y57TFHsfRLM=.89d76b9a-1b3d-401c-a942-86776321c1f9@github.com>
References: <cHg8Tu9u24ge_ElzmF1cKNaR-83zPPlX6y1ZXFvJz7Q=.5c529a35-707c-4b17-be9f-badd523111f3@github.com>
 <73KvQ-wIvi6mX-538ngdN0mHKFs30QI7Y57TFHsfRLM=.89d76b9a-1b3d-401c-a942-86776321c1f9@github.com>
Message-ID: <JfTHVBDjXmDfHV2GB2ejeBbS8ALvx4FQXu_wBaEe9Eg=.2a7ef0d1-433e-4277-b9b5-11f900a6301e@github.com>

On Mon, 15 Mar 2021 21:27:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> JavaValue is a small wrapper class that wraps values used to pass arguments and results between native and Java.
>> 
>> When JavaCalls::call returns an object, the value stored in the JavaValue is not a handliezed jobject. Instead it's a raw oop. So, most of the code handling the `result`, fetches the result as a jobject, and then immediately casts it to an oop. For example:
>>   oop res = (oop)result.get_jobject();
>> 
>> I'd like to change this code to be:
>>   oop res = result.get_oop();
>> 
>> The motivations for this patch is:
>> 
>> 1) Minimize the places where we pass around oops in jobject variables. Maybe at some point we'll have converted the JVM to only use the jobject type when passing around JNI handle. We need to be stricter with the types when we continue develop our GCs and their barriers.
>> 
>> 2) Limit the number of places in the code where we perform raw oop casts. We have a helper cast function for that, cast_to_oop, but not all code use it. I have future patches where the compiler will completely forbid raw cast to oops (in fastdebug builds). With that in place, I can then add more stricter oop verification code when oops are created. This helps catching bugs earlier.
>> 
>> ---
>> 
>> When reviewing this patch, take an extra look at the change  to oopsHierarchy.hpp. This was done to support jvmciEnv.cpp code:
>>   JVMCIObject wrap(oop obj)...
>>   JVMCIObjectArray wrap(objArrayOop obj)...
>>   JVMCIPrimitiveArray wrap(typeArrayOop obj) ...
>> Previously, `wrap((oop)result.get_jobject())` called the first function. When the code was changed to `wrap(result.get_oop())`, where `get_oop()` returns a `oopDesc*`, the compiler didn't know what conversion in oopsHierarchy.hpp to use. Therefore, I replaced the overly permissive `void*` constructor with a constructor that only takes the corresponding `type##OopDesc*`.
>> 
>> An alternative would be to let get_oop() return an oop, but then that would add an unwanted a dependency between globalDefinitions.hpp and  oopsHierarchy.hpp. An earlier version of this patch did return an oop instead of oopDesc*, but it also moved entire JavaValue class out of globalDefinitions.hpp into a new javaValue.hpp file, and had a corresponding javaValue.inline.hpp file.
>> 
>> Even if we end up using the proposed `oopDesc* get_oop()` version, maybe moving the class to javaValues.hpp would still makes sense?
>
> This change looks really good to me.  I have no objection to oopDesc* in JavaCallValue.  We use oopDesc* in all places where the class oop would interfere with values passed between Java and the vm.

Replacing the overly permissive void* oop conversion operator seems like a good effect of this change.  I don't see the necessity of adding a new javaValues.hpp file for this change.

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

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

From dcubed at openjdk.java.net  Mon Mar 15 22:08:08 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 15 Mar 2021 22:08:08 GMT
Subject: RFR: 8261262: Kitchensink24HStress.java crashed with
 EXCEPTION_ACCESS_VIOLATION
In-Reply-To: <N8sz_MwKWT2BdcrSQcU0_-2dUm30_AED4dtfUwLkGd0=.e11ba713-3da7-4fe0-ae03-062ec989e1f6@github.com>
References: <N8sz_MwKWT2BdcrSQcU0_-2dUm30_AED4dtfUwLkGd0=.e11ba713-3da7-4fe0-ae03-062ec989e1f6@github.com>
Message-ID: <Z_Q8PiVhouhY35m88kBr6CiBzh_UDxo0Bmxk45j6d84=.27e1797d-7a2a-4677-a4ce-9022aa072953@github.com>

On Mon, 15 Mar 2021 11:48:38 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> When returning from the last Java frame back to vm and hitting a safepoint poll on that last return we sometimes have a last java frame but no vframe.
> This seem to be a bug in itself, handled in: 8263576
> 
> Other places which uses vframe NULL checks it before, so let's do that in GetCurrentLocationClosure also.
> 
> Testing: nsk jdi/jvmti, jdk jdi, jck vm and t1-3.

Thumbs up!

I agree that the code should have checked for "if (vf != NULL) {"
instead of asserting that "(vf != NULL)".

src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 263:

> 261:     // There can be a race condition between a handshake
> 262:     // and the target thread exiting from Java execution.
> 263:     // We must recheck the last Java frame still exists.

Typo: s/recheck the last/recheck that the last/
(not your typo, but since you're in there...)

src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 266:

> 264:     if (!jt->is_exiting() && jt->has_last_Java_frame()) {
> 265:       javaVFrame* vf = jt->last_java_vframe(&rm);
> 266:       assert(vf != NULL, "must have last java frame");

The code before we converted to handshakes also had this assert.

The pre-handshake code did the work in the doit() function for the
VM_GetCurrentLocation VM-op. This makes me wonder if we always
had frames here when this was previously done via VM-op? And that
makes me wonder whether handshakes is doing something different
so we don't always have a frame here?

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

Marked as reviewed by dcubed (Reviewer).

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

From sspitsyn at openjdk.java.net  Mon Mar 15 22:23:08 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Mon, 15 Mar 2021 22:23:08 GMT
Subject: RFR: 8261262: Kitchensink24HStress.java crashed with
 EXCEPTION_ACCESS_VIOLATION
In-Reply-To: <N8sz_MwKWT2BdcrSQcU0_-2dUm30_AED4dtfUwLkGd0=.e11ba713-3da7-4fe0-ae03-062ec989e1f6@github.com>
References: <N8sz_MwKWT2BdcrSQcU0_-2dUm30_AED4dtfUwLkGd0=.e11ba713-3da7-4fe0-ae03-062ec989e1f6@github.com>
Message-ID: <hL3HjrFeE5u2nEz6psD_KP-K9qY8EuLZm516to38e8Y=.58899c23-1803-4bb0-a853-949aebb9c6b7@github.com>

On Mon, 15 Mar 2021 11:48:38 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> When returning from the last Java frame back to vm and hitting a safepoint poll on that last return we sometimes have a last java frame but no vframe.
> This seem to be a bug in itself, handled in: 8263576
> 
> Other places which uses vframe NULL checks it before, so let's do that in GetCurrentLocationClosure also.
> 
> Testing: nsk jdi/jvmti, jdk jdi, jck vm and t1-3.

Robbin,
The fix looks good to me. Thank you for taking care about this issue!
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From stefank at openjdk.java.net  Mon Mar 15 22:24:14 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 15 Mar 2021 22:24:14 GMT
Subject: RFR: 8263589: Introduce JavaValue::get_oop/set_oop
In-Reply-To: <73KvQ-wIvi6mX-538ngdN0mHKFs30QI7Y57TFHsfRLM=.89d76b9a-1b3d-401c-a942-86776321c1f9@github.com>
References: <cHg8Tu9u24ge_ElzmF1cKNaR-83zPPlX6y1ZXFvJz7Q=.5c529a35-707c-4b17-be9f-badd523111f3@github.com>
 <73KvQ-wIvi6mX-538ngdN0mHKFs30QI7Y57TFHsfRLM=.89d76b9a-1b3d-401c-a942-86776321c1f9@github.com>
Message-ID: <Yu8DZMe6p3TCjgL2LMchAf48i7xHIDJTRtB1TijfIGQ=.3498da13-0d40-4c65-b90d-7b1cc34d63aa@github.com>

On Mon, 15 Mar 2021 21:25:30 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> JavaValue is a small wrapper class that wraps values used to pass arguments and results between native and Java.
>> 
>> When JavaCalls::call returns an object, the value stored in the JavaValue is not a handliezed jobject. Instead it's a raw oop. So, most of the code handling the `result`, fetches the result as a jobject, and then immediately casts it to an oop. For example:
>>   oop res = (oop)result.get_jobject();
>> 
>> I'd like to change this code to be:
>>   oop res = result.get_oop();
>> 
>> The motivations for this patch is:
>> 
>> 1) Minimize the places where we pass around oops in jobject variables. Maybe at some point we'll have converted the JVM to only use the jobject type when passing around JNI handle. We need to be stricter with the types when we continue develop our GCs and their barriers.
>> 
>> 2) Limit the number of places in the code where we perform raw oop casts. We have a helper cast function for that, cast_to_oop, but not all code use it. I have future patches where the compiler will completely forbid raw cast to oops (in fastdebug builds). With that in place, I can then add more stricter oop verification code when oops are created. This helps catching bugs earlier.
>> 
>> ---
>> 
>> When reviewing this patch, take an extra look at the change  to oopsHierarchy.hpp. This was done to support jvmciEnv.cpp code:
>>   JVMCIObject wrap(oop obj)...
>>   JVMCIObjectArray wrap(objArrayOop obj)...
>>   JVMCIPrimitiveArray wrap(typeArrayOop obj) ...
>> Previously, `wrap((oop)result.get_jobject())` called the first function. When the code was changed to `wrap(result.get_oop())`, where `get_oop()` returns a `oopDesc*`, the compiler didn't know what conversion in oopsHierarchy.hpp to use. Therefore, I replaced the overly permissive `void*` constructor with a constructor that only takes the corresponding `type##OopDesc*`.
>> 
>> An alternative would be to let get_oop() return an oop, but then that would add an unwanted a dependency between globalDefinitions.hpp and  oopsHierarchy.hpp. An earlier version of this patch did return an oop instead of oopDesc*, but it also moved entire JavaValue class out of globalDefinitions.hpp into a new javaValue.hpp file, and had a corresponding javaValue.inline.hpp file.
>> 
>> Even if we end up using the proposed `oopDesc* get_oop()` version, maybe moving the class to javaValues.hpp would still makes sense?
>
> src/hotspot/share/utilities/globalDefinitions.hpp line 809:
> 
>> 807:     jint     i;
>> 808:     jlong    l;
>> 809:     jobject  h;
> 
> Do we still need jobject after this change?

We still use jobject for the arguments. We also converted the result to a jobject when it is passed back to Java.

We have a few places in JFR where the code seems to take a detour and fetch the oop from the result JavaValue, create a JNI handle, puts it back with set_jobject, and then reads it out with get_jobject. I have a patch where the code simply returns the created JNI handle without installing it into the result JavaValue. I've left that as a separate patch for the JFR team to review. 

There are some usages in C1, but I haven't tried to figure that out.

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

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

From sspitsyn at openjdk.java.net  Mon Mar 15 22:41:08 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Mon, 15 Mar 2021 22:41:08 GMT
Subject: RFR: 8263589: Introduce JavaValue::get_oop/set_oop
In-Reply-To: <cHg8Tu9u24ge_ElzmF1cKNaR-83zPPlX6y1ZXFvJz7Q=.5c529a35-707c-4b17-be9f-badd523111f3@github.com>
References: <cHg8Tu9u24ge_ElzmF1cKNaR-83zPPlX6y1ZXFvJz7Q=.5c529a35-707c-4b17-be9f-badd523111f3@github.com>
Message-ID: <QmFwYu8c0fAk8BotSXK-bGW9dKf6EVoiSHkgYPsvg8g=.260316a3-75e0-4fdf-a86c-8692a3dd09f8@github.com>

On Mon, 15 Mar 2021 12:35:47 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> JavaValue is a small wrapper class that wraps values used to pass arguments and results between native and Java.
> 
> When JavaCalls::call returns an object, the value stored in the JavaValue is not a handliezed jobject. Instead it's a raw oop. So, most of the code handling the `result`, fetches the result as a jobject, and then immediately casts it to an oop. For example:
>   oop res = (oop)result.get_jobject();
> 
> I'd like to change this code to be:
>   oop res = result.get_oop();
> 
> The motivations for this patch is:
> 
> 1) Minimize the places where we pass around oops in jobject variables. Maybe at some point we'll have converted the JVM to only use the jobject type when passing around JNI handle. We need to be stricter with the types when we continue develop our GCs and their barriers.
> 
> 2) Limit the number of places in the code where we perform raw oop casts. We have a helper cast function for that, cast_to_oop, but not all code use it. I have future patches where the compiler will completely forbid raw cast to oops (in fastdebug builds). With that in place, I can then add more stricter oop verification code when oops are created. This helps catching bugs earlier.
> 
> ---
> 
> When reviewing this patch, take an extra look at the change  to oopsHierarchy.hpp. This was done to support jvmciEnv.cpp code:
>   JVMCIObject wrap(oop obj)...
>   JVMCIObjectArray wrap(objArrayOop obj)...
>   JVMCIPrimitiveArray wrap(typeArrayOop obj) ...
> Previously, `wrap((oop)result.get_jobject())` called the first function. When the code was changed to `wrap(result.get_oop())`, where `get_oop()` returns a `oopDesc*`, the compiler didn't know what conversion in oopsHierarchy.hpp to use. Therefore, I replaced the overly permissive `void*` constructor with a constructor that only takes the corresponding `type##OopDesc*`.
> 
> An alternative would be to let get_oop() return an oop, but then that would add an unwanted a dependency between globalDefinitions.hpp and  oopsHierarchy.hpp. An earlier version of this patch did return an oop instead of oopDesc*, but it also moved entire JavaValue class out of globalDefinitions.hpp into a new javaValue.hpp file, and had a corresponding javaValue.inline.hpp file.
> 
> Even if we end up using the proposed `oopDesc* get_oop()` version, maybe moving the class to javaValues.hpp would still makes sense?

Stefan,
It is a good move in general and tt looks good to me.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From sspitsyn at openjdk.java.net  Mon Mar 15 23:38:08 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Mon, 15 Mar 2021 23:38:08 GMT
Subject: RFR: 8262504: Some CLHSDB command cannot know they run on remote
 debugger
In-Reply-To: <hYYLenPIpA840x3tcc3ZikUiZKdJB3mSuxDs00dFdQo=.62e3707c-c3f8-48ab-8d1e-d5b7d42661d4@github.com>
References: <hYYLenPIpA840x3tcc3ZikUiZKdJB3mSuxDs00dFdQo=.62e3707c-c3f8-48ab-8d1e-d5b7d42661d4@github.com>
Message-ID: <9yHCEhlMi9vCtjGCZvqLL1XtXQBf1oNHXoaPGXZ6M1k=.073f0335-2865-4f6c-b94e-c481179795b5@github.com>

On Sun, 28 Feb 2021 13:18:21 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> `pmap` and `pstack` CLHSDB command do not work on remote debugger, we can see following error message:
> 
> hsdb> pmap
> not yet implemented (debugger does not support CDebugger)!
> 
> However, SA has different message for this purpose:
> 
> https://github.com/openjdk/jdk/blob/03d888f463c0a6e3fee70ed8ad606fc0a3082636/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PMap.java#L74-L78
> 
> SA should show "remote configuration is not yet implemented" when it works on remote debugger.

Hi Yasumasa,
The fix looks good to me.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From cjplummer at openjdk.java.net  Tue Mar 16 00:23:16 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 16 Mar 2021 00:23:16 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v4]
In-Reply-To: <hCno7IM_Y_wbTbStzZ2ByLxeUghZm5g2t0AgqsHGDHE=.04431085-2671-43d4-86e4-7c40911846e2@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
 <hCno7IM_Y_wbTbStzZ2ByLxeUghZm5g2t0AgqsHGDHE=.04431085-2671-43d4-86e4-7c40911846e2@github.com>
Message-ID: <Bk19u5W_DyFDmbVf7m_oGD2FxvmLXdSZXWhTY2wOFuU=.dacc068d-bc7a-4996-8972-a323550fef3c@github.com>

On Mon, 15 Mar 2021 08:50:35 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out
>
> Lin Zang 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:
> 
>  - Merge branch 'master' into sf
>  - Revert "reduce memory consumption"
>    
>    This reverts commit 70e43ddd453724ce36bf729fa6489c0027957b8e.
>  - reduce memory consumption
>  - code refine
>  - 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java line 587:

> 585:         long currentRecordLength = 0;
> 586: 
> 587:         // There is an U4 slot contains the data size written in the dump file.

"a U4 slot that contains..."

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java line 588:

> 586: 
> 587:         // There is an U4 slot contains the data size written in the dump file.
> 588:         // Need to trunicate the array length if the size exceed the MAX_U4_VALUE.

Should be "truncate" and "exceeds"

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java line 618:

> 616:             int bytesToWrite = (int) (longBytes);
> 617:             hprofBufferedOut.fillSegmentSizeAndEnableWriteThrough(bytesToWrite);
> 618:         }

It seems to me this is the key part of the fix, and all other changes and driven by this change. What I don't understand is why enabling `writeThrough` is done here in `calculateArrayMaxLength()`, especially since this same code might be execute more than once for the same segment (thus "enabling" `writeThrough` when it is already enabled). What is the actual trigger for wanting `writeThrough` mode? Is it really just seeing an array for the first time in a segment?

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

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

From ysuenaga at openjdk.java.net  Tue Mar 16 00:20:07 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 16 Mar 2021 00:20:07 GMT
Subject: RFR: 8263565: NPE was thrown when
 sun.jvm.hotspot.rmi.serverNamePrefix was set
In-Reply-To: <-T97PgdhcBLuWZjkxqtWvE0M-XQKxqC0CJBY88mViKg=.e0a6ba57-7b1e-41ad-961b-0e465710eba6@github.com>
References: <h7RuyZ_VM6x6IdDGSictAFUFZJ8C87UuUJIbjpJ_yWs=.94f55574-c7df-4af8-96c5-0c0ac7ced239@github.com>
 <-T97PgdhcBLuWZjkxqtWvE0M-XQKxqC0CJBY88mViKg=.e0a6ba57-7b1e-41ad-961b-0e465710eba6@github.com>
Message-ID: <F0Kt8lyJ_iMtupUqxAnjLwGD4S-aTd52ZkJ83yAl6_U=.76bbd6e7-53ae-4c05-a3aa-7a3a6df9d736@github.com>

On Mon, 15 Mar 2021 18:47:15 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> NPE was thrown when I set server name prefix for debugd as following:
>> 
>> $ jhsdb -J-Dsun.jvm.hotspot.rmi.serverNamePrefix=test debugd --pid 781
>> Attaching to process ID 781 and starting RMI services, please wait...
>> Error attaching to process or starting server: sun.jvm.hotspot.debugger.DebuggerException: java.lang.NullPointerException: Cannot invoke "String.length()" because "this.input" is null
>>         at jdk.hotspot.agent/sun.jvm.hotspot.RMIHelper.rebind(RMIHelper.java:78)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.setupDebugger(HotSpotAgent.java:379)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:329)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.startServer(HotSpotAgent.java:215)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runDEBUGD(SALauncher.java:431)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:493)
>> Caused by: java.lang.NullPointerException: Cannot invoke "String.length()" because "this.input" is null
>>         at java.base/java.net.URI$Parser.parse(URI.java:3166)
>>         at java.base/java.net.URI.<init>(URI.java:623)
>>         at java.rmi/java.rmi.Naming.intParseURL(Naming.java:273)
>>         at java.rmi/java.rmi.Naming.parseURL(Naming.java:237)
>>         at java.rmi/java.rmi.Naming.rebind(Naming.java:171)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.RMIHelper.rebind(RMIHelper.java:64)
>>         ... 5 more
>> 
>> `serverNamePrefix` would not affect due to trivial bug.
>
> The fix looks fine. It would be nice if this was documented somewhere (and even tested). Also, while looking into this I noticed the following comment:
> 
>         // debugServerID follows the pattern [unique_id@]host[:port]
>         // we have to transform this as //host[:port]/<serverNamePrefix>['_'<unique_id>]
> 
> The `[:port]` part is also not document, not even in the command line syntax for `sadebugd`

Thanks @plummercj for your review!

> The fix looks fine. It would be nice if this was documented somewhere (and even tested). Also, while looking into this I noticed the following comment:
> 
> ```
>     // debugServerID follows the pattern [unique_id@]host[:port]
>     // we have to transform this as //host[:port]/<serverNamePrefix>['_'<unique_id>]
> ```
> 
> The `[:port]` part is also not document, not even in the command line syntax for `sadebugd`

In addition `sun.jvm.hotspot.rmi.startRegistry` is also undocumented even though it works well.
Both `serverNamePrefix` and `startRegistry` are not exposed as command line options of jhsdb, I think documentation. implementing testcases, and exposing as command line options should be done simultaneously. We need to change both command line help and manpage in that work (CSR is needed of course.)

For example, I think we can expose them as following:

$ jhsdb debugd --help
    :
    --disableregistry             Do not start RMI registry (to use RMI registry that exists)
    --servernameprefix         Specify RMI server name prefix

$ jhsdb jinfo --help
    :
    --connect [<id>@]<host>[:registryport][/servernameprefix] To connect to a remote debug server (debugd).
    :
    Examples: jhsdb jinfo --pid 1234
          or  jhsdb jinfo --core ./core.1234 --exe ./myexe
          or  jhsdb jinfo --connect debugserver
          or  jhsdb jinfo --connect id at debugserver:1234/prefix

I will work for it if you are ok.

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

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

From cjplummer at openjdk.java.net  Tue Mar 16 00:44:17 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 16 Mar 2021 00:44:17 GMT
Subject: RFR: 8263565: NPE was thrown when
 sun.jvm.hotspot.rmi.serverNamePrefix was set
In-Reply-To: <F0Kt8lyJ_iMtupUqxAnjLwGD4S-aTd52ZkJ83yAl6_U=.76bbd6e7-53ae-4c05-a3aa-7a3a6df9d736@github.com>
References: <h7RuyZ_VM6x6IdDGSictAFUFZJ8C87UuUJIbjpJ_yWs=.94f55574-c7df-4af8-96c5-0c0ac7ced239@github.com>
 <-T97PgdhcBLuWZjkxqtWvE0M-XQKxqC0CJBY88mViKg=.e0a6ba57-7b1e-41ad-961b-0e465710eba6@github.com>
 <F0Kt8lyJ_iMtupUqxAnjLwGD4S-aTd52ZkJ83yAl6_U=.76bbd6e7-53ae-4c05-a3aa-7a3a6df9d736@github.com>
Message-ID: <6LQOt0nW3vbivpTsKAwxd2Pz5OtcAWo3qZtnlKRk6vE=.3b814361-085a-4298-a73e-eeecaa2815f7@github.com>

On Tue, 16 Mar 2021 00:17:09 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> The fix looks fine. It would be nice if this was documented somewhere (and even tested). Also, while looking into this I noticed the following comment:
>> 
>>         // debugServerID follows the pattern [unique_id@]host[:port]
>>         // we have to transform this as //host[:port]/<serverNamePrefix>['_'<unique_id>]
>> 
>> The `[:port]` part is also not document, not even in the command line syntax for `sadebugd`
>
> Thanks @plummercj for your review!
> 
>> The fix looks fine. It would be nice if this was documented somewhere (and even tested). Also, while looking into this I noticed the following comment:
>> 
>> ```
>>     // debugServerID follows the pattern [unique_id@]host[:port]
>>     // we have to transform this as //host[:port]/<serverNamePrefix>['_'<unique_id>]
>> ```
>> 
>> The `[:port]` part is also not document, not even in the command line syntax for `sadebugd`
> 
> In addition `sun.jvm.hotspot.rmi.startRegistry` is also undocumented even though it works well.
> Both `serverNamePrefix` and `startRegistry` are not exposed as command line options of jhsdb, I think documentation. implementing testcases, and exposing as command line options should be done simultaneously. We need to change both command line help and manpage in that work (CSR is needed of course.)
> 
> For example, I think we can expose them as following:
> 
> $ jhsdb debugd --help
>     :
>     --disableregistry             Do not start RMI registry (to use RMI registry that exists)
>     --servernameprefix         Specify RMI server name prefix
> 
> $ jhsdb jinfo --help
>     :
>     --connect [<id>@]<host>[:registryport][/servernameprefix] To connect to a remote debug server (debugd).
>     :
>     Examples: jhsdb jinfo --pid 1234
>           or  jhsdb jinfo --core ./core.1234 --exe ./myexe
>           or  jhsdb jinfo --connect debugserver
>           or  jhsdb jinfo --connect id at debugserver:1234/prefix
> 
> I will work for it if you are ok.

That looks fine, although I'm a little unclear about the need for `--disableregistry`, and how that applies to existing code. 

Also, I think a bit of explanation of `[:registryport]` is needed since it is not also specified by the `jhsdb debugd` command. That's just the port that it chooses to communicate over, and can be any available port, right? If one is not specified, what port is chosen, and what would be a reason that you would want to specify a port?

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

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

From ysuenaga at openjdk.java.net  Tue Mar 16 01:00:07 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 16 Mar 2021 01:00:07 GMT
Subject: RFR: 8263565: NPE was thrown when
 sun.jvm.hotspot.rmi.serverNamePrefix was set
In-Reply-To: <6LQOt0nW3vbivpTsKAwxd2Pz5OtcAWo3qZtnlKRk6vE=.3b814361-085a-4298-a73e-eeecaa2815f7@github.com>
References: <h7RuyZ_VM6x6IdDGSictAFUFZJ8C87UuUJIbjpJ_yWs=.94f55574-c7df-4af8-96c5-0c0ac7ced239@github.com>
 <-T97PgdhcBLuWZjkxqtWvE0M-XQKxqC0CJBY88mViKg=.e0a6ba57-7b1e-41ad-961b-0e465710eba6@github.com>
 <F0Kt8lyJ_iMtupUqxAnjLwGD4S-aTd52ZkJ83yAl6_U=.76bbd6e7-53ae-4c05-a3aa-7a3a6df9d736@github.com>
 <6LQOt0nW3vbivpTsKAwxd2Pz5OtcAWo3qZtnlKRk6vE=.3b814361-085a-4298-a73e-eeecaa2815f7@github.com>
Message-ID: <PI-TJh7srlhNOH20gQl7jz5pSv0X-xQVgoZB8LDyBf0=.fa5aa28a-03fe-4e03-846a-76ec52122352@github.com>

On Tue, 16 Mar 2021 00:41:25 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> That looks fine, although I'm a little unclear about the need for `--disableregistry`, and how that applies to existing code.

We can use it when we want to register SA endpoint to RMI registry that exists (e.g. rmid). I think it is simple to proxy to `sun.jvm.hotspot.rmi.startRegistry` like `--registryport` option in jhsdb.

https://github.com/openjdk/jdk/blob/master/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/SALauncher.java#L392-L400

> Also, I think a bit of explanation of `[:registryport]` is needed since it is not also specified by the `jhsdb debugd` command. That's just the port that it chooses to communicate over, and can be any available port, right? If one is not specified, what port is chosen, and what would be a reason that you would want to specify a port?

We can specify any available port as you said.
For example, if we run multiple debugd instances on same OS, we need to use different port. We can use `--registryport` and `[:registryport]` in that case.
However we will not have many opportunities to use this.

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

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

From cjplummer at openjdk.java.net  Tue Mar 16 01:22:08 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 16 Mar 2021 01:22:08 GMT
Subject: RFR: 8263565: NPE was thrown when
 sun.jvm.hotspot.rmi.serverNamePrefix was set
In-Reply-To: <PI-TJh7srlhNOH20gQl7jz5pSv0X-xQVgoZB8LDyBf0=.fa5aa28a-03fe-4e03-846a-76ec52122352@github.com>
References: <h7RuyZ_VM6x6IdDGSictAFUFZJ8C87UuUJIbjpJ_yWs=.94f55574-c7df-4af8-96c5-0c0ac7ced239@github.com>
 <-T97PgdhcBLuWZjkxqtWvE0M-XQKxqC0CJBY88mViKg=.e0a6ba57-7b1e-41ad-961b-0e465710eba6@github.com>
 <F0Kt8lyJ_iMtupUqxAnjLwGD4S-aTd52ZkJ83yAl6_U=.76bbd6e7-53ae-4c05-a3aa-7a3a6df9d736@github.com>
 <6LQOt0nW3vbivpTsKAwxd2Pz5OtcAWo3qZtnlKRk6vE=.3b814361-085a-4298-a73e-eeecaa2815f7@github.com>
 <PI-TJh7srlhNOH20gQl7jz5pSv0X-xQVgoZB8LDyBf0=.fa5aa28a-03fe-4e03-846a-76ec52122352@github.com>
Message-ID: <EL2_24odQcZwvRkaCK6Yt7ApbL9YVke5VU8OCaKggyg=.0b56f5c1-ac04-48e7-a323-7bf8fb82006d@github.com>

On Tue, 16 Mar 2021 00:57:48 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> That looks fine, although I'm a little unclear about the need for `--disableregistry`, and how that applies to existing code. 
>> 
>> Also, I think a bit of explanation of `[:registryport]` is needed since it is not also specified by the `jhsdb debugd` command. That's just the port that it chooses to communicate over, and can be any available port, right? If one is not specified, what port is chosen, and what would be a reason that you would want to specify a port?
>
>> That looks fine, although I'm a little unclear about the need for `--disableregistry`, and how that applies to existing code.
> 
> We can use it when we want to register SA endpoint to RMI registry that exists (e.g. rmid). I think it is simple to proxy to `sun.jvm.hotspot.rmi.startRegistry` like `--registryport` option in jhsdb.
> 
> https://github.com/openjdk/jdk/blob/master/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/SALauncher.java#L392-L400
> 
>> Also, I think a bit of explanation of `[:registryport]` is needed since it is not also specified by the `jhsdb debugd` command. That's just the port that it chooses to communicate over, and can be any available port, right? If one is not specified, what port is chosen, and what would be a reason that you would want to specify a port?
> 
> We can specify any available port as you said.
> For example, if we run multiple debugd instances on same OS, we need to use different port. We can use `--registryport` and `[:registryport]` in that case.
> However we will not have many opportunities to use this.

I think the default rmi registry port is 1099. However, do we need to also support something like [JDK-8196729](https://bugs.openjdk.java.net/browse/JDK-8196729) for the rmi communications port?

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

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

From ysuenaga at openjdk.java.net  Tue Mar 16 01:28:10 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 16 Mar 2021 01:28:10 GMT
Subject: RFR: 8263565: NPE was thrown when
 sun.jvm.hotspot.rmi.serverNamePrefix was set
In-Reply-To: <EL2_24odQcZwvRkaCK6Yt7ApbL9YVke5VU8OCaKggyg=.0b56f5c1-ac04-48e7-a323-7bf8fb82006d@github.com>
References: <h7RuyZ_VM6x6IdDGSictAFUFZJ8C87UuUJIbjpJ_yWs=.94f55574-c7df-4af8-96c5-0c0ac7ced239@github.com>
 <-T97PgdhcBLuWZjkxqtWvE0M-XQKxqC0CJBY88mViKg=.e0a6ba57-7b1e-41ad-961b-0e465710eba6@github.com>
 <F0Kt8lyJ_iMtupUqxAnjLwGD4S-aTd52ZkJ83yAl6_U=.76bbd6e7-53ae-4c05-a3aa-7a3a6df9d736@github.com>
 <6LQOt0nW3vbivpTsKAwxd2Pz5OtcAWo3qZtnlKRk6vE=.3b814361-085a-4298-a73e-eeecaa2815f7@github.com>
 <PI-TJh7srlhNOH20gQl7jz5pSv0X-xQVgoZB8LDyBf0=.fa5aa28a-03fe-4e03-846a-76ec52122352@github.com>
 <EL2_24odQcZwvRkaCK6Yt7ApbL9YVke5VU8OCaKggyg=.0b56f5c1-ac04-48e7-a323-7bf8fb82006d@github.com>
Message-ID: <A8MFIMdh8S0c7S_C60aT3wCogdSKomW4_65tyZN-i9U=.8e9e9ace-b95d-4717-85c3-231ad76e5bd7@github.com>

On Tue, 16 Mar 2021 01:19:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I think the default rmi registry port is 1099. However, do we need to also support something like [JDK-8196729](https://bugs.openjdk.java.net/browse/JDK-8196729) for the rmi communications port?

We can specify RMI communication port with `--rmiport` in `jhsdb debugd`. It has been introduced in [JDK-8196751](https://bugs.openjdk.java.net/browse/JDK-8196751).

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

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

From ysuenaga at openjdk.java.net  Tue Mar 16 01:31:08 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 16 Mar 2021 01:31:08 GMT
Subject: RFR: 8263565: NPE was thrown when
 sun.jvm.hotspot.rmi.serverNamePrefix was set
In-Reply-To: <A8MFIMdh8S0c7S_C60aT3wCogdSKomW4_65tyZN-i9U=.8e9e9ace-b95d-4717-85c3-231ad76e5bd7@github.com>
References: <h7RuyZ_VM6x6IdDGSictAFUFZJ8C87UuUJIbjpJ_yWs=.94f55574-c7df-4af8-96c5-0c0ac7ced239@github.com>
 <-T97PgdhcBLuWZjkxqtWvE0M-XQKxqC0CJBY88mViKg=.e0a6ba57-7b1e-41ad-961b-0e465710eba6@github.com>
 <F0Kt8lyJ_iMtupUqxAnjLwGD4S-aTd52ZkJ83yAl6_U=.76bbd6e7-53ae-4c05-a3aa-7a3a6df9d736@github.com>
 <6LQOt0nW3vbivpTsKAwxd2Pz5OtcAWo3qZtnlKRk6vE=.3b814361-085a-4298-a73e-eeecaa2815f7@github.com>
 <PI-TJh7srlhNOH20gQl7jz5pSv0X-xQVgoZB8LDyBf0=.fa5aa28a-03fe-4e03-846a-76ec52122352@github.com>
 <EL2_24odQcZwvRkaCK6Yt7ApbL9YVke5VU8OCaKggyg=.0b56f5c1-ac04-48e7-a323-7bf8fb82006d@github.com>
 <A8MFIMdh8S0c7S_C60aT3wCogdSKomW4_65tyZN-i9U=.8e9e9ace-b95d-4717-85c3-231ad76e5bd7@github.com>
Message-ID: <HOOdXVJdMNOXotrDjCGs_2gtmjAuoOoRE5YE0Ny46jM=.5f1432b0-e42f-4266-b7f3-5afa940a2f7f@github.com>

On Tue, 16 Mar 2021 01:25:26 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I think the default rmi registry port is 1099. However, do we need to also support something like [JDK-8196729](https://bugs.openjdk.java.net/browse/JDK-8196729) for the rmi communications port?
>
>> I think the default rmi registry port is 1099. However, do we need to also support something like [JDK-8196729](https://bugs.openjdk.java.net/browse/JDK-8196729) for the rmi communications port?
> 
> We can specify RMI communication port with `--rmiport` in `jhsdb debugd`. It has been introduced in [JDK-8196751](https://bugs.openjdk.java.net/browse/JDK-8196751).

For example, if we want to fix RMI registry and communication port, we can start debugd instance as following:

$ jhsdb debugd --pid 1234 --registryport 2000 --rmiport 3000

Then, we can connect to it as following:

$ jhsdb jinfo --connect localhost:2000

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

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

From cjplummer at openjdk.java.net  Tue Mar 16 02:02:09 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 16 Mar 2021 02:02:09 GMT
Subject: RFR: 8263565: NPE was thrown when
 sun.jvm.hotspot.rmi.serverNamePrefix was set
In-Reply-To: <HOOdXVJdMNOXotrDjCGs_2gtmjAuoOoRE5YE0Ny46jM=.5f1432b0-e42f-4266-b7f3-5afa940a2f7f@github.com>
References: <h7RuyZ_VM6x6IdDGSictAFUFZJ8C87UuUJIbjpJ_yWs=.94f55574-c7df-4af8-96c5-0c0ac7ced239@github.com>
 <-T97PgdhcBLuWZjkxqtWvE0M-XQKxqC0CJBY88mViKg=.e0a6ba57-7b1e-41ad-961b-0e465710eba6@github.com>
 <F0Kt8lyJ_iMtupUqxAnjLwGD4S-aTd52ZkJ83yAl6_U=.76bbd6e7-53ae-4c05-a3aa-7a3a6df9d736@github.com>
 <6LQOt0nW3vbivpTsKAwxd2Pz5OtcAWo3qZtnlKRk6vE=.3b814361-085a-4298-a73e-eeecaa2815f7@github.com>
 <PI-TJh7srlhNOH20gQl7jz5pSv0X-xQVgoZB8LDyBf0=.fa5aa28a-03fe-4e03-846a-76ec52122352@github.com>
 <EL2_24odQcZwvRkaCK6Yt7ApbL9YVke5VU8OCaKggyg=.0b56f5c1-ac04-48e7-a323-7bf8fb82006d@github.com>
 <A8MFIMdh8S0c7S_C60aT3wCogdSKomW4_65tyZN-i9U=.8e9e9ace-b95d-4717-85c3-231ad76e5bd7@github.com>
 <HOOdXVJdMNOXotrDjCGs_2gtmjAuoOoRE5YE0Ny46jM=.5f1432b0-e42f-4266-b7f3-5afa940a2f7f@github.com>
Message-ID: <G6mrFXaWNzvC0d-41PbYLTUwSvSl2sTTdeZ9Xdcx4Q0=.7bca3389-4492-4bea-9e8a-f5bb6dd30b81@github.com>

On Tue, 16 Mar 2021 01:28:49 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>>> I think the default rmi registry port is 1099. However, do we need to also support something like [JDK-8196729](https://bugs.openjdk.java.net/browse/JDK-8196729) for the rmi communications port?
>> 
>> We can specify RMI communication port with `--rmiport` in `jhsdb debugd`. It has been introduced in [JDK-8196751](https://bugs.openjdk.java.net/browse/JDK-8196751).
>
> For example, if we want to fix RMI registry and communication port, we can start debugd instance as following:
> 
> $ jhsdb debugd --pid 1234 --registryport 2000 --rmiport 3000
> 
> Then, we can connect to it as following:
> 
> $ jhsdb jinfo --connect localhost:2000

Sorry. I was running an old jhsdb. So we already have --registryport 2000 --rmiport, and you can already specify [:<registryport>] as part of the debugserver. So what needs to be added is just --servernameprefix, and better help for explaining all the parts of the debugserver that are specified with --connect. You also want to add --disableregistry, but I think that's kind of separate from the above and probably needs its own CR and CSR.

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

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

From ysuenaga at openjdk.java.net  Tue Mar 16 02:42:10 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 16 Mar 2021 02:42:10 GMT
Subject: RFR: 8263565: NPE was thrown when
 sun.jvm.hotspot.rmi.serverNamePrefix was set
In-Reply-To: <G6mrFXaWNzvC0d-41PbYLTUwSvSl2sTTdeZ9Xdcx4Q0=.7bca3389-4492-4bea-9e8a-f5bb6dd30b81@github.com>
References: <h7RuyZ_VM6x6IdDGSictAFUFZJ8C87UuUJIbjpJ_yWs=.94f55574-c7df-4af8-96c5-0c0ac7ced239@github.com>
 <-T97PgdhcBLuWZjkxqtWvE0M-XQKxqC0CJBY88mViKg=.e0a6ba57-7b1e-41ad-961b-0e465710eba6@github.com>
 <F0Kt8lyJ_iMtupUqxAnjLwGD4S-aTd52ZkJ83yAl6_U=.76bbd6e7-53ae-4c05-a3aa-7a3a6df9d736@github.com>
 <6LQOt0nW3vbivpTsKAwxd2Pz5OtcAWo3qZtnlKRk6vE=.3b814361-085a-4298-a73e-eeecaa2815f7@github.com>
 <PI-TJh7srlhNOH20gQl7jz5pSv0X-xQVgoZB8LDyBf0=.fa5aa28a-03fe-4e03-846a-76ec52122352@github.com>
 <EL2_24odQcZwvRkaCK6Yt7ApbL9YVke5VU8OCaKggyg=.0b56f5c1-ac04-48e7-a323-7bf8fb82006d@github.com>
 <A8MFIMdh8S0c7S_C60aT3wCogdSKomW4_65tyZN-i9U=.8e9e9ace-b95d-4717-85c3-231ad76e5bd7@github.com>
 <HOOdXVJdMNOXotrDjCGs_2gtmjAuoOoRE5YE0Ny46jM=.5f1432b0-e42f-4266-b7f3-5afa940a2f7f@github.com>
 <G6mrFXaWNzvC0d-41PbYLTUwSvSl2sTTdeZ9Xdcx4Q0=.7bca3389-4492-4bea-9e8a-f5bb6dd30b81@github.com>
Message-ID: <Gh6Y3JRuCVE4uYIRKRS6Y8JS3R9EHcOBwRRcJQIfVMk=.66883f2d-d108-4c7e-a5f2-380a386b709e@github.com>

On Tue, 16 Mar 2021 01:59:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> So what needs to be added is just --servernameprefix, and better help for explaining all the parts of the debugserver that are specified with --connect. You also want to add --disableregistry, but I think that's kind of separate from the above and probably needs its own CR and CSR.

I filed them to JBS. I will work for them later.

* --servernameprefix: https://bugs.openjdk.java.net/browse/JDK-8263635
* --disableregistry: https://bugs.openjdk.java.net/browse/JDK-8263636

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

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

From ysuenaga at openjdk.java.net  Tue Mar 16 05:49:07 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 16 Mar 2021 05:49:07 GMT
Subject: Integrated: 8262504: Some CLHSDB command cannot know they run on
 remote debugger
In-Reply-To: <hYYLenPIpA840x3tcc3ZikUiZKdJB3mSuxDs00dFdQo=.62e3707c-c3f8-48ab-8d1e-d5b7d42661d4@github.com>
References: <hYYLenPIpA840x3tcc3ZikUiZKdJB3mSuxDs00dFdQo=.62e3707c-c3f8-48ab-8d1e-d5b7d42661d4@github.com>
Message-ID: <rkcROnng2zfnS14mAhWOsyWRnBYmK-Hmp--ye9l16-w=.985e956e-3411-4e19-b064-9c722e173180@github.com>

On Sun, 28 Feb 2021 13:18:21 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> `pmap` and `pstack` CLHSDB command do not work on remote debugger, we can see following error message:
> 
> hsdb> pmap
> not yet implemented (debugger does not support CDebugger)!
> 
> However, SA has different message for this purpose:
> 
> https://github.com/openjdk/jdk/blob/03d888f463c0a6e3fee70ed8ad606fc0a3082636/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PMap.java#L74-L78
> 
> SA should show "remote configuration is not yet implemented" when it works on remote debugger.

This pull request has now been integrated.

Changeset: e03a5948
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e03a5948
Stats:     43 lines in 5 files changed: 31 ins; 0 del; 12 mod

8262504: Some CLHSDB command cannot know they run on remote debugger

Reviewed-by: cjplummer, sspitsyn

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

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

From ksakata at openjdk.java.net  Tue Mar 16 06:09:25 2021
From: ksakata at openjdk.java.net (Koichi Sakata)
Date: Tue, 16 Mar 2021 06:09:25 GMT
Subject: RFR: 8263572: Output from jstack mixed mode is misaligned [v2]
In-Reply-To: <LiAjqiWikfy0llyWM79wX1pZQO4JkNsO8WwjWqcAAKg=.e177e030-08cf-42cd-aaee-27d530b5ed02@github.com>
References: <LiAjqiWikfy0llyWM79wX1pZQO4JkNsO8WwjWqcAAKg=.e177e030-08cf-42cd-aaee-27d530b5ed02@github.com>
Message-ID: <Tk1-poV1F49pg7TH4c9636JUsJvTk0Q9cK-AZX3uPQM=.b5d134e9-f4bd-48d2-97c4-c8f7776077ad@github.com>

> When running jstack with mixed option, the output of the lines that doesn't have an address are misaligned as followings. 
> 
> $ sudo jhsdb jstack --mixed --pid 5905
> ----------------- 5955 -----------------
> "event-handler" #20 daemon prio=5 tid=0x00007f133079a970 nid=0x1743 in Object.wait() [0x00007f1308bfe000]
>    java.lang.Thread.State: WAITING (on object monitor)
>    JavaThread state: _thread_blocked
> 0x00007f133a85b9f3 __pthread_cond_wait + 0x243
> 0x00007f133940b75b os::PlatformEvent::park() + 0x8b
> 0x00007f13393b7b2d ObjectMonitor::wait(long, bool, Thread*) + 0xf4d
> 0x00007f13397f0b95 ObjectSynchronizer::wait(Handle, long, Thread*) + 0x85
> 0x00007f1338e85961 JVM_MonitorWait + 0x241
> 0x00007f1328b264b7 java.lang.Object.wait(long) + 0xd7 (Native method)
> 0x00007f132177b3c4 * java.lang.Object.wait() bci:2 line:338 (Compiled frame)
> * com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(long) bci:64 line:190 (Compiled frame)
> * com.sun.tools.jdi.EventQueueImpl.remove(long) bci:18 line:97 (Interpreted frame)
> 0x00007f1321009543 * com.sun.tools.jdi.EventQueueImpl.remove() bci:2 line:83 (Interpreted frame)
> 
> This pull request aligns the indentation. So It will be able to improve readability.
> 
> In this pull request the address part is filled with white spaces. The amount of space is calculated from VM's logarithmic address size and lastly 2, which is the length of "0x", is added.
> 
> I checked the output on 64-bit and 32-bit OS.
> 
> 0x00007f596cb2a6b7      java.lang.Object.wait(long) + 0xd7 (Native method)
> 0x00007f5965791ec4      * java.lang.Object.wait() bci:2 line:338 (Compiled frame)
>                         * com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(long) bci:64 line:190 (Compiled frame)
>                         * com.sun.tools.jdi.EventQueueImpl.remove(long) bci:18 line:97 (Interpreted frame)
> 0x00007f5965009543      * com.sun.tools.jdi.EventQueueImpl.remove() bci:2 line:83 (Interpreted frame)
> 0x00007f59650099b3      * jdk.jshell.execution.JdiEventHandler.run() bci:18 line:79 (Interpreted frame)
> 0x00007f596500985a      * java.lang.Thread.run() bci:11 line:831 (Interpreted frame)
> 
> 0x035002d4      java.lang.Object.wait(long) + 0x94 (Native method)
> 0x034fcd3c      * java.lang.Object.wait() bci:2 line:338 (Compiled frame)
>                 * com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(long) bci:64 line:190 (Compiled frame)
>                 * com.sun.tools.jdi.EventQueueImpl.remove(long) bci:18 line:97 (Interpreted frame)
> 0x03296839      * com.sun.tools.jdi.EventQueueImpl.remove() bci:2 line:83 (Interpreted frame)

Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision:

  Fix calculation for the length of white space

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3004/files
  - new: https://git.openjdk.java.net/jdk/pull/3004/files/a7f58090..5a83d608

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

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

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

From ksakata at openjdk.java.net  Tue Mar 16 06:25:07 2021
From: ksakata at openjdk.java.net (Koichi Sakata)
Date: Tue, 16 Mar 2021 06:25:07 GMT
Subject: RFR: 8263572: Output from jstack mixed mode is misaligned [v2]
In-Reply-To: <zzzXtXaBXSToz6gz_wS5wRTkr_up1vwa7_vywLbYUMY=.5d9441b0-f92c-448c-818c-8eed4a73ed89@github.com>
References: <LiAjqiWikfy0llyWM79wX1pZQO4JkNsO8WwjWqcAAKg=.e177e030-08cf-42cd-aaee-27d530b5ed02@github.com>
 <zzzXtXaBXSToz6gz_wS5wRTkr_up1vwa7_vywLbYUMY=.5d9441b0-f92c-448c-818c-8eed4a73ed89@github.com>
Message-ID: <uNd5qyZCW0RlA9mdrq4-eqrc8-FazCjbbb5Zkxd5HnA=.bb886de4-900e-439c-bbc8-f583a7737a73@github.com>

On Mon, 15 Mar 2021 19:15:09 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix calculation for the length of white space
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PStack.java line 172:
> 
>> 170:                          // print java frame(s)
>> 171:                          for (int i = 0; i < names.length; i++) {
>> 172:                              if (0 < i) {
> 
> Please use `i > 0`

Sure!

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

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

From ksakata at openjdk.java.net  Tue Mar 16 06:28:09 2021
From: ksakata at openjdk.java.net (Koichi Sakata)
Date: Tue, 16 Mar 2021 06:28:09 GMT
Subject: RFR: 8263572: Output from jstack mixed mode is misaligned [v2]
In-Reply-To: <zzzXtXaBXSToz6gz_wS5wRTkr_up1vwa7_vywLbYUMY=.5d9441b0-f92c-448c-818c-8eed4a73ed89@github.com>
References: <LiAjqiWikfy0llyWM79wX1pZQO4JkNsO8WwjWqcAAKg=.e177e030-08cf-42cd-aaee-27d530b5ed02@github.com>
 <zzzXtXaBXSToz6gz_wS5wRTkr_up1vwa7_vywLbYUMY=.5d9441b0-f92c-448c-818c-8eed4a73ed89@github.com>
Message-ID: <b1hk99skKYpAJpYwLtd3zZ0SLGfQDKXSMLJlXo1NGPY=.97259e35-29a1-46e4-8042-3e4b769908e5@github.com>

On Mon, 15 Mar 2021 19:20:27 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix calculation for the length of white space
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PStack.java line 85:
> 
>> 83:         }
>> 84:          final boolean cdbgCanDemangle = cdbg.canDemangle();
>> 85:          String fillerForAddress = " ".repeat(2 + (2 << VM.getVM().getLogAddressSize())) + "\t";
> 
> Why not use `2 * VM.getVM().getAddressSize()` rather than `(2 << VM.getVM().getLogAddressSize()`?

Thank you. I missed that method. I've changed the code.

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

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

From ksakata at openjdk.java.net  Tue Mar 16 06:55:12 2021
From: ksakata at openjdk.java.net (Koichi Sakata)
Date: Tue, 16 Mar 2021 06:55:12 GMT
Subject: RFR: 8263572: Output from jstack mixed mode is misaligned [v2]
In-Reply-To: <zzzXtXaBXSToz6gz_wS5wRTkr_up1vwa7_vywLbYUMY=.5d9441b0-f92c-448c-818c-8eed4a73ed89@github.com>
References: <LiAjqiWikfy0llyWM79wX1pZQO4JkNsO8WwjWqcAAKg=.e177e030-08cf-42cd-aaee-27d530b5ed02@github.com>
 <zzzXtXaBXSToz6gz_wS5wRTkr_up1vwa7_vywLbYUMY=.5d9441b0-f92c-448c-818c-8eed4a73ed89@github.com>
Message-ID: <FkWKGIb6fjNq8lClZzMl-rO5q2-TAAYRGyKT6v_XS6U=.ef40f45e-286f-410d-b1e6-5d670291743a@github.com>

On Mon, 15 Mar 2021 19:22:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix calculation for the length of white space
>
> What testing have you done?
> 
> Please update the copyright to 2021.
> 
> I noticed that in you original jstack output there is only 1 space after the address, and now there appears to be multiple spaces. However, when I produce the jstack out there's already multiple spaces. Was there some formatting issue with your original output?

Thank you for your comment, @plummercj.

> What testing have you done?

I added the content of the test that I've done in the body text.

> Please update the copyright to 2021.

Sure!

> I noticed that in you original jstack output there is only 1 space after the address, and now there appears to be multiple spaces. However, when I produce the jstack out there's already multiple spaces. Was there some formatting issue with your original output?

I'm sorry. It seemed that a tab after the address was lost on pasting. I pasted proper one once again. So there is no format issue after the address.

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

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

From sspitsyn at openjdk.java.net  Tue Mar 16 07:10:08 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 16 Mar 2021 07:10:08 GMT
Subject: RFR: 8262271: SA: Add new stress test that tests getting the
 stack trace of an active thread [v2]
In-Reply-To: <xmMUx-npHPS9Y5S19PhQ1qFCBECWZGSb_drcjicVRaw=.d6f9c5b7-ed5f-4af2-812b-e133d6c8d8a4@github.com>
References: <59yxshwLvp5MVCYf2F2THU0T-SJjWbQfQTRLpJ3o2K4=.0e2e73cb-71dd-41b1-a86c-3460631c544c@github.com>
 <xmMUx-npHPS9Y5S19PhQ1qFCBECWZGSb_drcjicVRaw=.d6f9c5b7-ed5f-4af2-812b-e133d6c8d8a4@github.com>
Message-ID: <O6KfpioA7I1thHHw-5fxUQpRpMq50LIVNKtm2tfTt_A=.3195ef3c-1413-432a-9f33-9ce1c6a56145@github.com>

On Tue, 9 Mar 2021 07:17:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This a new test that runs jstack on a process that is busy doing things. It runs jstack 4 times as the process is starting up.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use waitFor() instead of destroyForcibly().

Chris,
New test looks okay to me.
How did you verify it is stable on all platforms?
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From lzang at openjdk.java.net  Tue Mar 16 07:36:13 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Tue, 16 Mar 2021 07:36:13 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v4]
In-Reply-To: <Bk19u5W_DyFDmbVf7m_oGD2FxvmLXdSZXWhTY2wOFuU=.dacc068d-bc7a-4996-8972-a323550fef3c@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
 <hCno7IM_Y_wbTbStzZ2ByLxeUghZm5g2t0AgqsHGDHE=.04431085-2671-43d4-86e4-7c40911846e2@github.com>
 <Bk19u5W_DyFDmbVf7m_oGD2FxvmLXdSZXWhTY2wOFuU=.dacc068d-bc7a-4996-8972-a323550fef3c@github.com>
Message-ID: <0z8n3vAl_Uc5wQAD12aixrSXWRmrHtqjbZpSRekOI0o=.d4967e04-6a92-4237-afab-acc15fe6175d@github.com>

On Tue, 16 Mar 2021 00:20:34 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Lin Zang 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:
>> 
>>  - Merge branch 'master' into sf
>>  - Revert "reduce memory consumption"
>>    
>>    This reverts commit 70e43ddd453724ce36bf729fa6489c0027957b8e.
>>  - reduce memory consumption
>>  - code refine
>>  - 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java line 618:
> 
>> 616:             int bytesToWrite = (int) (longBytes);
>> 617:             hprofBufferedOut.fillSegmentSizeAndEnableWriteThrough(bytesToWrite);
>> 618:         }
> 
> It seems to me this is the key part of the fix, and all other changes and driven by this change. What I don't understand is why enabling `writeThrough` is done here in `calculateArrayMaxLength()`, especially since this same code might be execute more than once for the same segment (thus "enabling" `writeThrough` when it is already enabled). What is the actual trigger for wanting `writeThrough` mode? Is it really just seeing an array for the first time in a segment?

Dear Chris, 

> What I don't understand is why enabling `writeThrough` is done here in `calculateArrayMaxLength()`

This is the place where the array size could be calculated by the writer before the array element data are written. So there is no need to cache the array in the internal buffer of segmentedOutputStream.

> especially since this same code might be execute more than once for the same segment (thus "enabling" `writeThrough` when it is already enabled). 

IMO, it is not possible to execute write-through multiple times. in `fillSegmentSizeAndEnableWriteThrough()` there is a flush that will write all buffered data in to underlying output stream first and then start write-through mode. 
And from the implementation in https://github.com/openjdk/jdk/blob/c484d8904285652246c3af212a4211b9a8955149/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/AbstractHeapGraphWriter.java#L62
the method ` writeHeapRecordEpilogue()` would be called for every object iterated. And in this method, the `exitSegmentMode()` will be called which will disable write-through mode. 

Briefly, the segment could contain multiple objects. But the array object would be treated as a new standalone segment, which is written to the underlying output stream directly by write-through mode.  

> What is the actual trigger for wanting writeThrough mode? Is it really just seeing an array for the first time in a segment?

The root cause for requiring writeThrough mode is to avoid caching data in the internal buffer of `SegmentedOutputStream`, which would cause memory consumption and also performance issues, which is the also the root cause of this bug.

Moreover, the reason that need to "cache data" in internal buffer before data written to file is that current implementation of SA heap dumper need to fill the size slot in segment header only after the segment data are written.  Which is hard to do after introducing gzipped heap dump because the header and the data are compressed when written to file and not easy to be modified.

However, the current implementation of dumping array object first calculates the array size, so the size of segment data is known when creating segment header. And this fix uses that info to avoid cache array data.

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

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

From stefank at openjdk.java.net  Tue Mar 16 07:47:08 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Tue, 16 Mar 2021 07:47:08 GMT
Subject: RFR: 8263589: Introduce JavaValue::get_oop/set_oop
In-Reply-To: <73KvQ-wIvi6mX-538ngdN0mHKFs30QI7Y57TFHsfRLM=.89d76b9a-1b3d-401c-a942-86776321c1f9@github.com>
References: <cHg8Tu9u24ge_ElzmF1cKNaR-83zPPlX6y1ZXFvJz7Q=.5c529a35-707c-4b17-be9f-badd523111f3@github.com>
 <73KvQ-wIvi6mX-538ngdN0mHKFs30QI7Y57TFHsfRLM=.89d76b9a-1b3d-401c-a942-86776321c1f9@github.com>
Message-ID: <w2Um44Ewyj2J67IgHn8Udu2CGzjv2z-zIpJoEXQVI5g=.6c52f336-cff2-406a-b862-9d1eeb6419c8@github.com>

On Mon, 15 Mar 2021 21:27:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> JavaValue is a small wrapper class that wraps values used to pass arguments and results between native and Java.
>> 
>> When JavaCalls::call returns an object, the value stored in the JavaValue is not a handliezed jobject. Instead it's a raw oop. So, most of the code handling the `result`, fetches the result as a jobject, and then immediately casts it to an oop. For example:
>>   oop res = (oop)result.get_jobject();
>> 
>> I'd like to change this code to be:
>>   oop res = result.get_oop();
>> 
>> The motivations for this patch is:
>> 
>> 1) Minimize the places where we pass around oops in jobject variables. Maybe at some point we'll have converted the JVM to only use the jobject type when passing around JNI handle. We need to be stricter with the types when we continue develop our GCs and their barriers.
>> 
>> 2) Limit the number of places in the code where we perform raw oop casts. We have a helper cast function for that, cast_to_oop, but not all code use it. I have future patches where the compiler will completely forbid raw cast to oops (in fastdebug builds). With that in place, I can then add more stricter oop verification code when oops are created. This helps catching bugs earlier.
>> 
>> ---
>> 
>> When reviewing this patch, take an extra look at the change  to oopsHierarchy.hpp. This was done to support jvmciEnv.cpp code:
>>   JVMCIObject wrap(oop obj)...
>>   JVMCIObjectArray wrap(objArrayOop obj)...
>>   JVMCIPrimitiveArray wrap(typeArrayOop obj) ...
>> Previously, `wrap((oop)result.get_jobject())` called the first function. When the code was changed to `wrap(result.get_oop())`, where `get_oop()` returns a `oopDesc*`, the compiler didn't know what conversion in oopsHierarchy.hpp to use. Therefore, I replaced the overly permissive `void*` constructor with a constructor that only takes the corresponding `type##OopDesc*`.
>> 
>> An alternative would be to let get_oop() return an oop, but then that would add an unwanted a dependency between globalDefinitions.hpp and  oopsHierarchy.hpp. An earlier version of this patch did return an oop instead of oopDesc*, but it also moved entire JavaValue class out of globalDefinitions.hpp into a new javaValue.hpp file, and had a corresponding javaValue.inline.hpp file.
>> 
>> Even if we end up using the proposed `oopDesc* get_oop()` version, maybe moving the class to javaValues.hpp would still makes sense?
>
> This change looks really good to me.  I have no objection to oopDesc* in JavaCallValue.  We use oopDesc* in all places where the class oop would interfere with values passed between Java and the vm.

Thanks @coleenp @sspitsyn for reviewing!

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

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

From lzang at openjdk.java.net  Tue Mar 16 07:44:35 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Tue, 16 Mar 2021 07:44:35 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v5]
In-Reply-To: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
Message-ID: <sK1OL0VSui0iICLbwz-kdY0t9Fj9T0R3Lk4-ZdgcPQQ=.7f4cd913-b0bf-4821-a912-b71d2a7681c2@github.com>

> 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out

Lin Zang has updated the pull request incrementally with one additional commit since the last revision:

  fix typo in comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2803/files
  - new: https://git.openjdk.java.net/jdk/pull/2803/files/6019b1fa..7eb475e7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2803&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2803&range=03-04

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

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

From rehn at openjdk.java.net  Tue Mar 16 07:57:08 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Tue, 16 Mar 2021 07:57:08 GMT
Subject: RFR: 8261262: Kitchensink24HStress.java crashed with
 EXCEPTION_ACCESS_VIOLATION
In-Reply-To: <Z_Q8PiVhouhY35m88kBr6CiBzh_UDxo0Bmxk45j6d84=.27e1797d-7a2a-4677-a4ce-9022aa072953@github.com>
References: <N8sz_MwKWT2BdcrSQcU0_-2dUm30_AED4dtfUwLkGd0=.e11ba713-3da7-4fe0-ae03-062ec989e1f6@github.com>
 <Z_Q8PiVhouhY35m88kBr6CiBzh_UDxo0Bmxk45j6d84=.27e1797d-7a2a-4677-a4ce-9022aa072953@github.com>
Message-ID: <EggIGgFU0bN8Y7BY4VTqGECf7SsU4gdB3HMa98aAxko=.4a5654c9-518b-4280-b702-b41f382a811e@github.com>

On Mon, 15 Mar 2021 21:45:34 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> When returning from the last Java frame back to vm and hitting a safepoint poll on that last return we sometimes have a last java frame but no vframe.
>> This seem to be a bug in itself, handled in: 8263576
>> 
>> Other places which uses vframe NULL checks it before, so let's do that in GetCurrentLocationClosure also.
>> 
>> Testing: nsk jdi/jvmti, jdk jdi, jck vm and t1-3.
>
> src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 263:
> 
>> 261:     // There can be a race condition between a handshake
>> 262:     // and the target thread exiting from Java execution.
>> 263:     // We must recheck the last Java frame still exists.
> 
> Typo: s/recheck the last/recheck that the last/
> (not your typo, but since you're in there...)

Fixed

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

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

From rehn at openjdk.java.net  Tue Mar 16 08:07:40 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Tue, 16 Mar 2021 08:07:40 GMT
Subject: RFR: 8261262: Kitchensink24HStress.java crashed with
 EXCEPTION_ACCESS_VIOLATION [v2]
In-Reply-To: <Z_Q8PiVhouhY35m88kBr6CiBzh_UDxo0Bmxk45j6d84=.27e1797d-7a2a-4677-a4ce-9022aa072953@github.com>
References: <N8sz_MwKWT2BdcrSQcU0_-2dUm30_AED4dtfUwLkGd0=.e11ba713-3da7-4fe0-ae03-062ec989e1f6@github.com>
 <Z_Q8PiVhouhY35m88kBr6CiBzh_UDxo0Bmxk45j6d84=.27e1797d-7a2a-4677-a4ce-9022aa072953@github.com>
Message-ID: <dI1zEuOsTK1EONtdDdneBkmc6n5ZoP3X-O3zf9xojlc=.1d459626-e904-48f8-ac81-6062dcde1969@github.com>

On Mon, 15 Mar 2021 22:05:32 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Thumbs up!
> 
> I agree that the code should have checked for "if (vf != NULL) {"
> instead of asserting that "(vf != NULL)".

Thanks Dan!

> src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 266:
> 
>> 264:     if (!jt->is_exiting() && jt->has_last_Java_frame()) {
>> 265:       javaVFrame* vf = jt->last_java_vframe(&rm);
>> 266:       assert(vf != NULL, "must have last java frame");
> 
> The code before we converted to handshakes also had this assert.
> 
> The pre-handshake code did the work in the doit() function for the
> VM_GetCurrentLocation VM-op. This makes me wonder if we always
> had frames here when this was previously done via VM-op? And that
> makes me wonder whether handshakes is doing something different
> so we don't always have a frame here?

The differences is 8253180 (JDK 16), which turns return polls into branches to SafepointBlob instead of going via signal handler.
When setting up the last java frame in the SafepointBlob we get different result than before.
To look at that potential bug I opened 8263576.

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

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

From rehn at openjdk.java.net  Tue Mar 16 08:07:39 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Tue, 16 Mar 2021 08:07:39 GMT
Subject: RFR: 8261262: Kitchensink24HStress.java crashed with
 EXCEPTION_ACCESS_VIOLATION [v2]
In-Reply-To: <N8sz_MwKWT2BdcrSQcU0_-2dUm30_AED4dtfUwLkGd0=.e11ba713-3da7-4fe0-ae03-062ec989e1f6@github.com>
References: <N8sz_MwKWT2BdcrSQcU0_-2dUm30_AED4dtfUwLkGd0=.e11ba713-3da7-4fe0-ae03-062ec989e1f6@github.com>
Message-ID: <kz2WEkHRTWF6lmASszUudk-Dkf9xEmWOBJnjXszrmHg=.14a677b7-d7f2-4d1d-b411-f4628a3c812d@github.com>

> When returning from the last Java frame back to vm and hitting a safepoint poll on that last return we sometimes have a last java frame but no vframe.
> This seem to be a bug in itself, handled in: 8263576
> 
> Other places which uses vframe NULL checks it before, so let's do that in GetCurrentLocationClosure also.
> 
> Testing: nsk jdi/jvmti, jdk jdi, jck vm and t1-3.

Robbin Ehn 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:

 - Typo
 - Merge branch 'master' into 8261262
 - Check vframe non-null

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3010/files
  - new: https://git.openjdk.java.net/jdk/pull/3010/files/50348e80..068364b6

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

  Stats: 937 lines in 72 files changed: 385 ins; 370 del; 182 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3010.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3010/head:pull/3010

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

From rehn at openjdk.java.net  Tue Mar 16 08:07:41 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Tue, 16 Mar 2021 08:07:41 GMT
Subject: RFR: 8261262: Kitchensink24HStress.java crashed with
 EXCEPTION_ACCESS_VIOLATION [v2]
In-Reply-To: <hL3HjrFeE5u2nEz6psD_KP-K9qY8EuLZm516to38e8Y=.58899c23-1803-4bb0-a853-949aebb9c6b7@github.com>
References: <N8sz_MwKWT2BdcrSQcU0_-2dUm30_AED4dtfUwLkGd0=.e11ba713-3da7-4fe0-ae03-062ec989e1f6@github.com>
 <hL3HjrFeE5u2nEz6psD_KP-K9qY8EuLZm516to38e8Y=.58899c23-1803-4bb0-a853-949aebb9c6b7@github.com>
Message-ID: <dWHj0uzTfd-gEuf2Yy6czQE760dkoUYkbMipRnjNX2M=.79b7c4fc-0039-45e6-a706-f3f866c56747@github.com>

On Mon, 15 Mar 2021 22:20:38 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Robbin,
> The fix looks good to me. Thank you for taking care about this issue!
> Thanks,
> Serguei

Thanks Serguei!

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

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

From stefank at openjdk.java.net  Tue Mar 16 08:32:06 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Tue, 16 Mar 2021 08:32:06 GMT
Subject: Integrated: 8263589: Introduce JavaValue::get_oop/set_oop
In-Reply-To: <cHg8Tu9u24ge_ElzmF1cKNaR-83zPPlX6y1ZXFvJz7Q=.5c529a35-707c-4b17-be9f-badd523111f3@github.com>
References: <cHg8Tu9u24ge_ElzmF1cKNaR-83zPPlX6y1ZXFvJz7Q=.5c529a35-707c-4b17-be9f-badd523111f3@github.com>
Message-ID: <_-Q848_viOn6nedZYPXtEncvHRurcKq2AGOLL4jdddI=.c87c7dff-98fa-41e7-a910-a016e7c5deda@github.com>

On Mon, 15 Mar 2021 12:35:47 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> JavaValue is a small wrapper class that wraps values used to pass arguments and results between native and Java.
> 
> When JavaCalls::call returns an object, the value stored in the JavaValue is not a handliezed jobject. Instead it's a raw oop. So, most of the code handling the `result`, fetches the result as a jobject, and then immediately casts it to an oop. For example:
>   oop res = (oop)result.get_jobject();
> 
> I'd like to change this code to be:
>   oop res = result.get_oop();
> 
> The motivations for this patch is:
> 
> 1) Minimize the places where we pass around oops in jobject variables. Maybe at some point we'll have converted the JVM to only use the jobject type when passing around JNI handle. We need to be stricter with the types when we continue develop our GCs and their barriers.
> 
> 2) Limit the number of places in the code where we perform raw oop casts. We have a helper cast function for that, cast_to_oop, but not all code use it. I have future patches where the compiler will completely forbid raw cast to oops (in fastdebug builds). With that in place, I can then add more stricter oop verification code when oops are created. This helps catching bugs earlier.
> 
> ---
> 
> When reviewing this patch, take an extra look at the change  to oopsHierarchy.hpp. This was done to support jvmciEnv.cpp code:
>   JVMCIObject wrap(oop obj)...
>   JVMCIObjectArray wrap(objArrayOop obj)...
>   JVMCIPrimitiveArray wrap(typeArrayOop obj) ...
> Previously, `wrap((oop)result.get_jobject())` called the first function. When the code was changed to `wrap(result.get_oop())`, where `get_oop()` returns a `oopDesc*`, the compiler didn't know what conversion in oopsHierarchy.hpp to use. Therefore, I replaced the overly permissive `void*` constructor with a constructor that only takes the corresponding `type##OopDesc*`.
> 
> An alternative would be to let get_oop() return an oop, but then that would add an unwanted a dependency between globalDefinitions.hpp and  oopsHierarchy.hpp. An earlier version of this patch did return an oop instead of oopDesc*, but it also moved entire JavaValue class out of globalDefinitions.hpp into a new javaValue.hpp file, and had a corresponding javaValue.inline.hpp file.
> 
> Even if we end up using the proposed `oopDesc* get_oop()` version, maybe moving the class to javaValues.hpp would still makes sense?

This pull request has now been integrated.

Changeset: a1f6591f
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a1f6591f
Stats:     72 lines in 26 files changed: 5 ins; 0 del; 67 mod

8263589: Introduce JavaValue::get_oop/set_oop

Reviewed-by: coleenp, sspitsyn

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

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

From github.com+741251+turbanoff at openjdk.java.net  Tue Mar 16 10:13:11 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 16 Mar 2021 10:13:11 GMT
Subject: Integrated: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <Gm7s8Wp6sP7u0kYiTeTblJgRC5aCdi2LSB3zUiWWhKc=.a19637ca-c449-4176-96af-ae7dc0e09b26@github.com>

On Sun, 20 Dec 2020 17:05:21 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> 8080272  Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy

This pull request has now been integrated.

Changeset: 68deb24b
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Julia Boes <jboes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/68deb24b
Stats:     105 lines in 7 files changed: 3 ins; 78 del; 24 mod

8080272: Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy

Reviewed-by: mcimadamore, alanb

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

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

From cjplummer at openjdk.java.net  Tue Mar 16 23:14:14 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 16 Mar 2021 23:14:14 GMT
Subject: RFR: 8262271: SA: Add new stress test that tests getting the
 stack trace of an active thread [v2]
In-Reply-To: <O6KfpioA7I1thHHw-5fxUQpRpMq50LIVNKtm2tfTt_A=.3195ef3c-1413-432a-9f33-9ce1c6a56145@github.com>
References: <59yxshwLvp5MVCYf2F2THU0T-SJjWbQfQTRLpJ3o2K4=.0e2e73cb-71dd-41b1-a86c-3460631c544c@github.com>
 <xmMUx-npHPS9Y5S19PhQ1qFCBECWZGSb_drcjicVRaw=.d6f9c5b7-ed5f-4af2-812b-e133d6c8d8a4@github.com>
 <O6KfpioA7I1thHHw-5fxUQpRpMq50LIVNKtm2tfTt_A=.3195ef3c-1413-432a-9f33-9ce1c6a56145@github.com>
Message-ID: <On0kBXAE8Vt_Nc10SdnjaIIK2Q6vdhA5Wv9Ms7B1R2E=.eaf4631d-7bac-435d-950e-5d60282ef6f5@github.com>

On Tue, 16 Mar 2021 07:07:19 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>  How did you verify it is stable on all platforms?

I did 100s of runs on all our platforms with both product and debug builds, and also with -Xcomp.

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

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

From ysuenaga at openjdk.java.net  Tue Mar 16 23:18:19 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 16 Mar 2021 23:18:19 GMT
Subject: RFR: 8263670: pmap and pstack in jhsdb do not work on debug server
Message-ID: <OzFp9WFONUqIUYqdZ78D04bfnhgOSaeB1WqmPtyUdA0=.7dcf74d3-6819-4c9c-b878-a26cfcd0cbc6@github.com>

jhsdb supports pmap (jhsdb jmap) and pstack (jhsdb jstack --mixed), and they work fine if they attach to live process or to coredump, however they do not work on debug server as following:

$ jhsdb jmap --connect localhost
Attaching to remote server localhost, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 11.0.10+9
remote configuration is not yet implemented

pmap and pstack depend on CDebugger in SA, however it would not be set in case of remote debugger client. We can avoid it if we can delegate the process to debug server.

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

Commit messages:
 - 8263670: pmap and pstack in jhsdb do not work on debug server

Changes: https://git.openjdk.java.net/jdk/pull/3027/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3027&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263670
  Stats: 159 lines in 7 files changed: 141 ins; 4 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3027.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3027/head:pull/3027

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

From cjplummer at openjdk.java.net  Tue Mar 16 23:32:06 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 16 Mar 2021 23:32:06 GMT
Subject: RFR: 8263572: Output from jstack mixed mode is misaligned [v2]
In-Reply-To: <FkWKGIb6fjNq8lClZzMl-rO5q2-TAAYRGyKT6v_XS6U=.ef40f45e-286f-410d-b1e6-5d670291743a@github.com>
References: <LiAjqiWikfy0llyWM79wX1pZQO4JkNsO8WwjWqcAAKg=.e177e030-08cf-42cd-aaee-27d530b5ed02@github.com>
 <zzzXtXaBXSToz6gz_wS5wRTkr_up1vwa7_vywLbYUMY=.5d9441b0-f92c-448c-818c-8eed4a73ed89@github.com>
 <FkWKGIb6fjNq8lClZzMl-rO5q2-TAAYRGyKT6v_XS6U=.ef40f45e-286f-410d-b1e6-5d670291743a@github.com>
Message-ID: <gYeX6zc2LJyZREfGeH_Aip3pp48ygBHyWWP_E31hQ_g=.9476f576-66e4-46ed-bcb9-c715b859208d@github.com>

On Tue, 16 Mar 2021 06:51:59 GMT, Koichi Sakata <ksakata at openjdk.org> wrote:

> > What testing have you done?
> 
> I added the content of the test that I've done in the body text.

I was referring to the running of existing tests. I just want to make sure the format changes don't cause any tests to fail. It looks like the only test we have that uses `--mixed` is `test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixed.java`. This test is normally run as part of the git automated testing, but it is only run on linux, and I'm seeing the following in the test results:

`TEST RESULT: Passed. Skipped: jtreg.SkippedException: SA Attach not expected to work. Ptrace attach not supported.`

So it was skipped since the machine does not support Ptrace attach, and this was the only attempt to run the test.

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

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

From cjplummer at openjdk.java.net  Wed Mar 17 00:28:14 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 17 Mar 2021 00:28:14 GMT
Subject: RFR: 8263670: pmap and pstack in jhsdb do not work on debug server
In-Reply-To: <OzFp9WFONUqIUYqdZ78D04bfnhgOSaeB1WqmPtyUdA0=.7dcf74d3-6819-4c9c-b878-a26cfcd0cbc6@github.com>
References: <OzFp9WFONUqIUYqdZ78D04bfnhgOSaeB1WqmPtyUdA0=.7dcf74d3-6819-4c9c-b878-a26cfcd0cbc6@github.com>
Message-ID: <mFfeltfVRsGye7-4X9XJ1czWg022dMyk9mm38R-852U=.653f92cb-e119-49c8-84d0-6c273ef8077b@github.com>

On Tue, 16 Mar 2021 12:01:30 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> jhsdb supports pmap (jhsdb jmap) and pstack (jhsdb jstack --mixed), and they work fine if they attach to live process or to coredump, however they do not work on debug server as following:
> 
> $ jhsdb jmap --connect localhost
> Attaching to remote server localhost, please wait...
> Debugger attached successfully.
> Server compiler detected.
> JVM version is 11.0.10+9
> remote configuration is not yet implemented
> 
> pmap and pstack depend on CDebugger in SA, however it would not be set in case of remote debugger client. We can avoid it if we can delegate the process to debug server.

If I understand correctly, this is very different than the way we normally implement remote debugging support. Normally pages are read in from the remote VM process and into the local SA client, where it can then implement SA support in much the same way as it normally does. For PStack and PMap, you've chosen to instead just execute the commands in the remote debugd server, and return the (text) result to the client. It's not clear to me why the normal model (of reading in the remote pages and leveraging existing PStack and PMAp  supprt) can't instead be used so we can keep the remote debugging support consistent. How are PStack and PMap different from other SA support that does not require remote execution of commands.

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

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

From mseledtsov at openjdk.java.net  Wed Mar 17 00:48:07 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Wed, 17 Mar 2021 00:48:07 GMT
Subject: RFR: 8246494: introduce vm.flagless at-requires property
In-Reply-To: <fC51vNiDPG7UUjFvMEJnbbKV0ejluFe023gEgyFq1eI=.f55fd064-9aba-4f05-a3ea-ad6959e1c9bc@github.com>
References: <fC51vNiDPG7UUjFvMEJnbbKV0ejluFe023gEgyFq1eI=.f55fd064-9aba-4f05-a3ea-ad6959e1c9bc@github.com>
Message-ID: <dWqIuKUXFQxxUVP8qAGYwuaPYd4wWkMkiX3o4YbHjjk=.ca753fc6-1413-4581-ae9c-836b73850810@github.com>

On Tue, 2 Mar 2021 23:27:21 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> resurrecting old [RFR](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-June/041981.html):
> 
>> Hi all,
>> 
>> could you please review the patch which introduces a new @requires property to filter out the tests which ignore externally provided JVM flags?
>> 
>> the idea behind this patch is to have a way to clearly mark tests which ignore flags, so 
>> a) it's obvious that they don't execute a flag-guarded code/feature, and extra care should be taken to use them to verify any flag-guarded changed;
>> b) they can be easily excluded from runs w/ flags.
>> 
>> @requires and VMProps allows us to achieve both, so it's been decided to add a new property `vm.flagless`. `vm.flagless` is set to false if there are any XX flags other than `-XX:MaxRAMPercentage` and `-XX:CreateCoredumpOnCrash` (which are known to be set almost always) or any X flags other `-Xmixed`; in other words any tests w/ `@requires vm.flagless` will be excluded from runs w/ any other X / XX flags passed via `-vmoption` / `-javaoption`. in rare cases, when one still wants to run the tests marked by `vm.flagless`  w/ external flags, `vm.flagless` can be forcefully set to true by setting any value to `TEST_VM_FLAGLESS` env. variable.
>> 
>> this patch adds necessary common changes and marks common tests, namely Scimark, GTestWrapper and TestNativeProcessBuilder. Component-specific tests will be marked separately by the corresponding subtasks of 8151707[1].
>> 
>> please note, the patch depends on CODETOOLS-7902336[2], which will be included in the next jtreg version, so this patch is to be integrated only after jtreg5.1 is promoted and we switch to use it by 8246387[3].
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8246494
>> webrev: http://cr.openjdk.java.net/~iignatyev//8246494/webrev.00
>> testing: marked tests w/ different XX and X flags w/ and w/o TEST_VM_FLAGLESS env. var, and w/o any flags
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8151707
>> [2] https://bugs.openjdk.java.net/browse/CODETOOLS-7902336
>> [3] https://bugs.openjdk.java.net/browse/JDK-8246387
>> 
> 
> after offline discussion with @pliden, it has been decided to reduce the scope of [8246499](https://bugs.openjdk.java.net/browse/JDK-8246499) and not mark the tests that use `UseXGC` flags for selection, e.g. `test/hotspot/jtreg/gc/z/TestSmallHeap.java`.
> 
> Thanks,
> -- Igor

These changes look good to me.

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

Marked as reviewed by mseledtsov (Committer).

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

From iignatyev at openjdk.java.net  Wed Mar 17 00:58:08 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 17 Mar 2021 00:58:08 GMT
Subject: RFR: 8246494: introduce vm.flagless at-requires property
In-Reply-To: <dWqIuKUXFQxxUVP8qAGYwuaPYd4wWkMkiX3o4YbHjjk=.ca753fc6-1413-4581-ae9c-836b73850810@github.com>
References: <fC51vNiDPG7UUjFvMEJnbbKV0ejluFe023gEgyFq1eI=.f55fd064-9aba-4f05-a3ea-ad6959e1c9bc@github.com>
 <dWqIuKUXFQxxUVP8qAGYwuaPYd4wWkMkiX3o4YbHjjk=.ca753fc6-1413-4581-ae9c-836b73850810@github.com>
Message-ID: <YZw6BrN6ACwiG7G7bXzIl4iilxhLKaIkpRMxj6OAxyQ=.6cce7d51-c2e0-4eb1-bb48-e75fa5aa21ce@github.com>

On Wed, 17 Mar 2021 00:45:00 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

>> resurrecting old [RFR](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-June/041981.html):
>> 
>>> Hi all,
>>> 
>>> could you please review the patch which introduces a new @requires property to filter out the tests which ignore externally provided JVM flags?
>>> 
>>> the idea behind this patch is to have a way to clearly mark tests which ignore flags, so 
>>> a) it's obvious that they don't execute a flag-guarded code/feature, and extra care should be taken to use them to verify any flag-guarded changed;
>>> b) they can be easily excluded from runs w/ flags.
>>> 
>>> @requires and VMProps allows us to achieve both, so it's been decided to add a new property `vm.flagless`. `vm.flagless` is set to false if there are any XX flags other than `-XX:MaxRAMPercentage` and `-XX:CreateCoredumpOnCrash` (which are known to be set almost always) or any X flags other `-Xmixed`; in other words any tests w/ `@requires vm.flagless` will be excluded from runs w/ any other X / XX flags passed via `-vmoption` / `-javaoption`. in rare cases, when one still wants to run the tests marked by `vm.flagless`  w/ external flags, `vm.flagless` can be forcefully set to true by setting any value to `TEST_VM_FLAGLESS` env. variable.
>>> 
>>> this patch adds necessary common changes and marks common tests, namely Scimark, GTestWrapper and TestNativeProcessBuilder. Component-specific tests will be marked separately by the corresponding subtasks of 8151707[1].
>>> 
>>> please note, the patch depends on CODETOOLS-7902336[2], which will be included in the next jtreg version, so this patch is to be integrated only after jtreg5.1 is promoted and we switch to use it by 8246387[3].
>>> 
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8246494
>>> webrev: http://cr.openjdk.java.net/~iignatyev//8246494/webrev.00
>>> testing: marked tests w/ different XX and X flags w/ and w/o TEST_VM_FLAGLESS env. var, and w/o any flags
>>> 
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8151707
>>> [2] https://bugs.openjdk.java.net/browse/CODETOOLS-7902336
>>> [3] https://bugs.openjdk.java.net/browse/JDK-8246387
>>> 
>> 
>> after offline discussion with @pliden, it has been decided to reduce the scope of [8246499](https://bugs.openjdk.java.net/browse/JDK-8246499) and not mark the tests that use `UseXGC` flags for selection, e.g. `test/hotspot/jtreg/gc/z/TestSmallHeap.java`.
>> 
>> Thanks,
>> -- Igor
>
> These changes look good to me.

Thanks, Misha!

-- Igor

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

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

From sspitsyn at openjdk.java.net  Wed Mar 17 01:14:07 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 17 Mar 2021 01:14:07 GMT
Subject: RFR: 8262080:
 vmTestbase/nsk/jdi/Event/request/request001/TestDescription.java failed with
 "ERROR: new event is not ThreadStartEvent" [v4]
In-Reply-To: <sr-R0M5HETEwHsjowzDcTsQ3yeZIlwVyi0ew33tlPMc=.5d022524-1bc1-45f5-87d6-5a50cfbfd168@github.com>
References: <JzsafYgSso5aYsPImTLCz52dN96s-BJbY3eMrHwxLRw=.9e781f40-5e59-425e-ab83-03872256cb9d@github.com>
 <sr-R0M5HETEwHsjowzDcTsQ3yeZIlwVyi0ew33tlPMc=.5d022524-1bc1-45f5-87d6-5a50cfbfd168@github.com>
Message-ID: <YhtdCxNJjupie5CLt9zVrk_7v0KkzgAANlFtfZoVmqU=.2c1a3a90-0cee-407e-85a5-2aa7dbd702f9@github.com>

On Thu, 11 Mar 2021 23:17:24 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates the test to skip ThreadStartEvent/ThreadDeathEvent from other threads
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reformatted comment

Alex,

The fix looks good.
One minor suggestion about the messages:
+                    log2("Got ThreadStartEvent for wrong thread: " + event);
+                    log2("Got ThreadDeathEvent for wrong thread: " + event);

More clear message would be something like:
  "Thread is not expected, skipping XXX event: " + ...

Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2927

From sspitsyn at openjdk.java.net  Wed Mar 17 01:20:07 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 17 Mar 2021 01:20:07 GMT
Subject: RFR: 8262001:
 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java failed with
 "RuntimeException: Current Peak = 14 Expected to be == previous peak = 7 + 8"
In-Reply-To: <TZBFsiqKOxxbp-tN07-glyx947_eN6jTUEJlFWZcpik=.043c257d-d7ec-4df2-8504-1914e55e3975@github.com>
References: <TZBFsiqKOxxbp-tN07-glyx947_eN6jTUEJlFWZcpik=.043c257d-d7ec-4df2-8504-1914e55e3975@github.com>
Message-ID: <7_Sl6l0wFAYwjAAxNdzJkqzhk2InB0IUgaPe3zmvXoA=.f3b6bf4b-3244-4a63-80ba-045e91acbf47@github.com>

On Tue, 9 Mar 2021 01:31:33 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates ResetPeakThreadCount.java test - increases number of threads, but relaxes conditions so start/termination of system threads don't cause failures.
> Additional changes:
> - store threads in a list instead of array (we need only to start/terminate some number of threads, so linked list works better);
> - flags for thread termination are moved to thread class;
> - store values from ThreadMXBean.getPeakThreadCount() and getThreadCount() in int instead of long (the methods return int values)

Alex,
This looks good to me.
Nit:
The line needs a dot (was missed in the original code):
`+    // The MyThread thread lives as long as correspondent its live value is true`

Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2885

From ysuenaga at openjdk.java.net  Wed Mar 17 01:25:07 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 17 Mar 2021 01:25:07 GMT
Subject: RFR: 8263670: pmap and pstack in jhsdb do not work on debug server
In-Reply-To: <mFfeltfVRsGye7-4X9XJ1czWg022dMyk9mm38R-852U=.653f92cb-e119-49c8-84d0-6c273ef8077b@github.com>
References: <OzFp9WFONUqIUYqdZ78D04bfnhgOSaeB1WqmPtyUdA0=.7dcf74d3-6819-4c9c-b878-a26cfcd0cbc6@github.com>
 <mFfeltfVRsGye7-4X9XJ1czWg022dMyk9mm38R-852U=.653f92cb-e119-49c8-84d0-6c273ef8077b@github.com>
Message-ID: <q_jnJYTkJ2QYQh5K1AWHbw5Kt3cHt7__F77ru2lQKII=.732206cc-0825-4c0a-b315-f05237dffa57@github.com>

On Wed, 17 Mar 2021 00:25:19 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> If I understand correctly, this is very different than the way we normally implement remote debugging support. Normally pages are read in from the remote VM process and into the local SA client, where it can then implement SA support in much the same way as it normally does. For PStack and PMap, you've chosen to instead just execute the commands in the remote debugd server, and return the (text) result to the client.

Yes.

> It's not clear to me why the normal model (of reading in the remote pages and leveraging existing PStack and PMAp supprt) can't instead be used so we can keep the remote debugging support consistent. How are PStack and PMap different from other SA support that does not require remote execution of commands.

SA would set various information when it attaches to debuggee, so it is difficult to catch up them when remote debugger attached because only debugd can attach to debuggee directly.
As I said in the description of this PR, both PMap and PStack depend on CDebugger. CDebugger holds low-level information such as library list and native thread list. They would be initialized when it attached - it is startup of debugd, and we cannot get them when we connect to debugd.

I thought to export CDebugger as RMI object, but it seems to complex. So I decided to run both pmap and pstack on debugd.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3027

From sspitsyn at openjdk.java.net  Wed Mar 17 01:44:07 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 17 Mar 2021 01:44:07 GMT
Subject: RFR: 8263434: Dangling references after
 MethodComparator::methods_EMCP [v2]
In-Reply-To: <I9RUUM_wFM3jWorc7zw0OwllHhfuqVabLVdjnKyyZZo=.5cb9bded-ca33-4bf2-ae55-92cf006966b9@github.com>
References: <asxiOdUujvGXb5SvzrRSkAuVcrHz9xTFpwFZ90uJQaM=.f7576bd6-d4ba-4b7a-960f-f8e79ce6c54c@github.com>
 <I9RUUM_wFM3jWorc7zw0OwllHhfuqVabLVdjnKyyZZo=.5cb9bded-ca33-4bf2-ae55-92cf006966b9@github.com>
Message-ID: <N4UeTUQSxHjG0CsRyq-5tZgH2cgmHVV12FYVwObfdGU=.c80cf5ae-a9e3-4b6b-a18c-e6cc5b59e37f@github.com>

On Thu, 11 Mar 2021 13:50:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> SonarCloud reports the following problem in MethodComparator::methods_EMCP:
>>  "Address of stack memory associated with local variable 's_new' is still referred to by the global variable '_s_new' upon returning to the caller. This will be a dangling reference"
>> 
>> Code inspection reveals the assignment to static variables is only needed to pass them to helper methods. So, while this is not a detectable bug (yet), it is still cleaner not to expose stack variables in globals.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug `tier1`
>>  - [x] Linux x86_64 fastdebug, `vmTestbase_nsk_jvmti`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sprinkling consts

Aleksey,
Sorry for being late to the party.
This looks good to me.
One nit: unneeded extra '()' what came from the original code:
`     if ((old_cp->klass_at_noresolve(cpi_old) != new_cp->klass_at_noresolve(cpi_new)))`

Thanks,
Serguei

-------------

Changes requested by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2937

From cjplummer at openjdk.java.net  Wed Mar 17 05:00:10 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 17 Mar 2021 05:00:10 GMT
Subject: RFR: 8263670: pmap and pstack in jhsdb do not work on debug server
In-Reply-To: <q_jnJYTkJ2QYQh5K1AWHbw5Kt3cHt7__F77ru2lQKII=.732206cc-0825-4c0a-b315-f05237dffa57@github.com>
References: <OzFp9WFONUqIUYqdZ78D04bfnhgOSaeB1WqmPtyUdA0=.7dcf74d3-6819-4c9c-b878-a26cfcd0cbc6@github.com>
 <mFfeltfVRsGye7-4X9XJ1czWg022dMyk9mm38R-852U=.653f92cb-e119-49c8-84d0-6c273ef8077b@github.com>
 <q_jnJYTkJ2QYQh5K1AWHbw5Kt3cHt7__F77ru2lQKII=.732206cc-0825-4c0a-b315-f05237dffa57@github.com>
Message-ID: <6ShRMqQdyZulms0svEnGT2TT4an_ulqoVovPABis9fE=.b523a7e7-1bf8-41e9-aca2-af6f1a0aa556@github.com>

On Wed, 17 Mar 2021 01:22:39 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> If I understand correctly, this is very different than the way we normally implement remote debugging support. Normally pages are read in from the remote VM process and into the local SA client, where it can then implement SA support in much the same way as it normally does. For PStack and PMap, you've chosen to instead just execute the commands in the remote debugd server, and return the (text) result to the client. It's not clear to me why the normal model (of reading in the remote pages and leveraging existing PStack and PMAp  supprt) can't instead be used so we can keep the remote debugging support consistent. How are PStack and PMap different from other SA support that does not require remote execution of commands.
>
>> If I understand correctly, this is very different than the way we normally implement remote debugging support. Normally pages are read in from the remote VM process and into the local SA client, where it can then implement SA support in much the same way as it normally does. For PStack and PMap, you've chosen to instead just execute the commands in the remote debugd server, and return the (text) result to the client.
> 
> Yes.
> 
>> It's not clear to me why the normal model (of reading in the remote pages and leveraging existing PStack and PMAp supprt) can't instead be used so we can keep the remote debugging support consistent. How are PStack and PMap different from other SA support that does not require remote execution of commands.
> 
> SA would set various information when it attaches to debuggee, so it is difficult to catch up them when remote debugger attached because only debugd can attach to debuggee directly.
> As I said in the description of this PR, both PMap and PStack depend on CDebugger. CDebugger holds low-level information such as library list and native thread list. They would be initialized when it attached - it is startup of debugd, and we cannot get them when we connect to debugd.
> 
> I thought to export CDebugger as RMI object, but it seems to complex. So I decided to run both pmap and pstack on debugd.

Do we have any issues with any other clhsdb commands that rely CDebugger. I haven't looked into the implementation, but I'm suspicious of `thread`, `threads`, `findpc` of an address in the executable, and `findsym`.

And speaking of CDebugger, the SA "debugger" hierarchy is too heavily abstracted. I counted about 18 classes and interfaces that have "Debugger" in their name, and some of the interfaces get inherited more than once. I really wonder if it has to be that complex. My first adventure into this mess was for [JDK-8239062](https://bugs.openjdk.java.net/browse/JDK-8239062), a time when I knew close to nothing about SA. Was not fun and I eventually gave up. You might want to have a look at the CR, if not just to add some comments and maybe enlighten me on some things.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3027

From cjplummer at openjdk.java.net  Wed Mar 17 05:00:11 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 17 Mar 2021 05:00:11 GMT
Subject: RFR: 8263670: pmap and pstack in jhsdb do not work on debug server
In-Reply-To: <OzFp9WFONUqIUYqdZ78D04bfnhgOSaeB1WqmPtyUdA0=.7dcf74d3-6819-4c9c-b878-a26cfcd0cbc6@github.com>
References: <OzFp9WFONUqIUYqdZ78D04bfnhgOSaeB1WqmPtyUdA0=.7dcf74d3-6819-4c9c-b878-a26cfcd0cbc6@github.com>
Message-ID: <4FfOb6SCd4KEfcRA2jcj0zCcEtzN7B9GU_9mPmZnuwk=.de9d0929-3b27-478d-8306-478bcfed0f10@github.com>

On Tue, 16 Mar 2021 12:01:30 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> jhsdb supports pmap (jhsdb jmap) and pstack (jhsdb jstack --mixed), and they work fine if they attach to live process or to coredump, however they do not work on debug server as following:
> 
> $ jhsdb jmap --connect localhost
> Attaching to remote server localhost, please wait...
> Debugger attached successfully.
> Server compiler detected.
> JVM version is 11.0.10+9
> remote configuration is not yet implemented
> 
> pmap and pstack depend on CDebugger in SA, however it would not be set in case of remote debugger client. We can avoid it if we can delegate the process to debug server.

test/hotspot/jtreg/serviceability/sa/sadebugd/PmapOnDebugdTest.java line 36:

> 34:  * @bug 8263670
> 35:  * @requires vm.hasSA
> 36:  * @requires os.family != "windows"

You exclude windows but you check for "dylib" below.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3027

From cjplummer at openjdk.java.net  Wed Mar 17 05:06:08 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 17 Mar 2021 05:06:08 GMT
Subject: RFR: 8263670: pmap and pstack in jhsdb do not work on debug server
In-Reply-To: <OzFp9WFONUqIUYqdZ78D04bfnhgOSaeB1WqmPtyUdA0=.7dcf74d3-6819-4c9c-b878-a26cfcd0cbc6@github.com>
References: <OzFp9WFONUqIUYqdZ78D04bfnhgOSaeB1WqmPtyUdA0=.7dcf74d3-6819-4c9c-b878-a26cfcd0cbc6@github.com>
Message-ID: <69VN5ibIY4d_dT4M-OxUSMRhwN2jSEkIrBSIEzbDFKc=.a529f8e9-94f3-4f4b-96f7-20633f771106@github.com>

On Tue, 16 Mar 2021 12:01:30 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> jhsdb supports pmap (jhsdb jmap) and pstack (jhsdb jstack --mixed), and they work fine if they attach to live process or to coredump, however they do not work on debug server as following:
> 
> $ jhsdb jmap --connect localhost
> Attaching to remote server localhost, please wait...
> Debugger attached successfully.
> Server compiler detected.
> JVM version is 11.0.10+9
> remote configuration is not yet implemented
> 
> pmap and pstack depend on CDebugger in SA, however it would not be set in case of remote debugger client. We can avoid it if we can delegate the process to debug server.

test/hotspot/jtreg/serviceability/sa/sadebugd/PmapOnDebugdTest.java line 56:

> 54:             // are not required.
> 55:             throw new SkippedException("Cannot run this test on OSX if adding privileges is required.");
> 56:         }

pmap and pstack are not even supported on OSX with a live process. The automated github testing did not catch this because it passed due to the above check:

TEST RESULT: Passed. Skipped: jtreg.SkippedException: Cannot run this test on OSX if adding privileges is required.

If it passed the check, it would have failed below to find a .dylib. You could change the code below to something like what is in ClhsdbPmap.java:

            if (!withCore && Platform.isOSX()) {
                expStrMap.put("pmap", List.of("Not available for Mac OS X processes"));
            } else {
                expStrMap.put("pmap", List.of("jvm", "java", "jli", "jimage"));
            }

-------------

PR: https://git.openjdk.java.net/jdk/pull/3027

From ysuenaga at openjdk.java.net  Wed Mar 17 05:55:09 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 17 Mar 2021 05:55:09 GMT
Subject: RFR: 8263670: pmap and pstack in jhsdb do not work on debug server
In-Reply-To: <6ShRMqQdyZulms0svEnGT2TT4an_ulqoVovPABis9fE=.b523a7e7-1bf8-41e9-aca2-af6f1a0aa556@github.com>
References: <OzFp9WFONUqIUYqdZ78D04bfnhgOSaeB1WqmPtyUdA0=.7dcf74d3-6819-4c9c-b878-a26cfcd0cbc6@github.com>
 <mFfeltfVRsGye7-4X9XJ1czWg022dMyk9mm38R-852U=.653f92cb-e119-49c8-84d0-6c273ef8077b@github.com>
 <q_jnJYTkJ2QYQh5K1AWHbw5Kt3cHt7__F77ru2lQKII=.732206cc-0825-4c0a-b315-f05237dffa57@github.com>
 <6ShRMqQdyZulms0svEnGT2TT4an_ulqoVovPABis9fE=.b523a7e7-1bf8-41e9-aca2-af6f1a0aa556@github.com>
Message-ID: <2QodC_HP4E5x7ifnGJGNVVxfMWjtmLU6X4qa-Qg5zBg=.bf2732f7-ff70-4dfe-9682-f6e722176e46@github.com>

On Wed, 17 Mar 2021 04:55:27 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Do we have any issues with any other clhsdb commands that rely CDebugger. I haven't looked into the implementation, but I'm suspicious of `thread`, `threads`, `findpc` of an address in the executable, and `findsym`.

Yes, I confirmed `findsim` has same issue on remote debugger. It will be fixed if `findsym` use `execCommandOnServer()` in this PR, but it is not in this scope now.

> And speaking of CDebugger, the SA "debugger" hierarchy is too heavily abstracted. I counted about 18 classes and interfaces that have "Debugger" in their name, and some of the interfaces get inherited more than once. I really wonder if it has to be that complex. My first adventure into this mess was for [JDK-8239062](https://bugs.openjdk.java.net/browse/JDK-8239062), a time when I knew close to nothing about SA. Was not fun and I eventually gave up. You might want to have a look at the CR, if not just to add some comments and maybe enlighten me on some things.

I agree with you that Debugger (includes Debugger) and their inheritances are very complex, but it is very difficult to refactor IMHO - it could be the same as creating SA from scratch. It would be better if all commands run on client side of course, but it seems to be difficult, thus I decided to run some primitive commands (e.g. pmap, pstack) are run on server side (debugd).
 If this PR is integrated, [JDK-8239062](https://bugs.openjdk.java.net/browse/JDK-8239062) also can be fixed because it may be able to run on debugd.

OTOH this PR could be more complex to SA implementation for remote debugger, but I have no idea to fix this problem without refactoring (C)Debugger interfaces.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3027

From shade at openjdk.java.net  Wed Mar 17 06:35:34 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 17 Mar 2021 06:35:34 GMT
Subject: RFR: 8263434: Dangling references after
 MethodComparator::methods_EMCP [v3]
In-Reply-To: <asxiOdUujvGXb5SvzrRSkAuVcrHz9xTFpwFZ90uJQaM=.f7576bd6-d4ba-4b7a-960f-f8e79ce6c54c@github.com>
References: <asxiOdUujvGXb5SvzrRSkAuVcrHz9xTFpwFZ90uJQaM=.f7576bd6-d4ba-4b7a-960f-f8e79ce6c54c@github.com>
Message-ID: <ZlLuPPL3A3B_vg6-2rWPwBjJfY6b8tqQeuDxAYl1EMc=.06497fe9-6e57-4ca4-adb8-29f5a7dcf6ad@github.com>

> SonarCloud reports the following problem in MethodComparator::methods_EMCP:
>  "Address of stack memory associated with local variable 's_new' is still referred to by the global variable '_s_new' upon returning to the caller. This will be a dangling reference"
> 
> Code inspection reveals the assignment to static variables is only needed to pass them to helper methods. So, while this is not a detectable bug (yet), it is still cleaner not to expose stack variables in globals.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `tier1`
>  - [x] Linux x86_64 fastdebug, `vmTestbase_nsk_jvmti`

Aleksey Shipilev 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:

 - Update copyrights
 - Drop excess parentheses
 - Merge branch 'master' into JDK-8263434-dangling-methodcomparator-ecmp
 - Sprinkling consts
 - 8263434: Dangling references after MethodComparator::methods_EMCP

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2937/files
  - new: https://git.openjdk.java.net/jdk/pull/2937/files/5acc4807..82bf43e0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2937&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2937&range=01-02

  Stats: 33632 lines in 1544 files changed: 24507 ins; 4957 del; 4168 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2937.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2937/head:pull/2937

PR: https://git.openjdk.java.net/jdk/pull/2937

From shade at openjdk.java.net  Wed Mar 17 06:35:35 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 17 Mar 2021 06:35:35 GMT
Subject: RFR: 8263434: Dangling references after
 MethodComparator::methods_EMCP [v2]
In-Reply-To: <N4UeTUQSxHjG0CsRyq-5tZgH2cgmHVV12FYVwObfdGU=.c80cf5ae-a9e3-4b6b-a18c-e6cc5b59e37f@github.com>
References: <asxiOdUujvGXb5SvzrRSkAuVcrHz9xTFpwFZ90uJQaM=.f7576bd6-d4ba-4b7a-960f-f8e79ce6c54c@github.com>
 <I9RUUM_wFM3jWorc7zw0OwllHhfuqVabLVdjnKyyZZo=.5cb9bded-ca33-4bf2-ae55-92cf006966b9@github.com>
 <N4UeTUQSxHjG0CsRyq-5tZgH2cgmHVV12FYVwObfdGU=.c80cf5ae-a9e3-4b6b-a18c-e6cc5b59e37f@github.com>
Message-ID: <_1ZolMabvo2HNY7oQvMH9I_Ncg8Vjwm343YPlyyux8A=.051230b8-206e-42c2-9be4-c495111bf7d8@github.com>

On Wed, 17 Mar 2021 01:40:56 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> One nit: unneeded extra '()' what came from the original code:
> ` if ((old_cp->klass_at_noresolve(cpi_old) != new_cp->klass_at_noresolve(cpi_new)))`

Sure, updated. Also updated copyrights.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2937

From sspitsyn at openjdk.java.net  Wed Mar 17 06:36:06 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 17 Mar 2021 06:36:06 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out
In-Reply-To: <69h5uaXSdgc4Fkhla6QdtoezGPyVcFMNasVI8iNxYWI=.3a7c3e6a-8dfa-4ff1-a7cf-db71d3ea7bbf@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
 <Zvf7GN59hJdc7SgVRao3cEbcpU99CbGceULIfJnDJOE=.4bd79c51-6b9b-4ff9-9ada-dc43fd6ca6e8@github.com>
 <e6bMvI_trIEXu7SAiM98-OpZug3Mwli00owZzLXxJNo=.fa0b5857-28b8-428d-9477-61044e32ad49@github.com>
 <oaMRL-GuwQKYlGByJvPhHH63A4LTvQLsL2W6BOIS6cc=.5ee0e7f9-bdc3-4e51-9fcf-999d607730c1@github.com>
 <7p7PD78B0fKuSonRZ44rQWvBKHabsz4n9VT4WbVluFI=.e4248320-f134-4ed0-b073-a3466970932c@github.com>
 <cedPjc6Gumib0S_yqDLAm8up9lPEGguw5w5LJblpKHM=.cad805fe-ab47-4eb4-8c78-e2a17109a2ce@github.com>
 <69h5uaXSdgc4Fkhla6QdtoezGPyVcFMNasVI8iNxYWI=.3a7c3e6a-8dfa-4ff1-a7cf-db71d3ea7bbf@github.com>
Message-ID: <2J1CEmVaXJuvU3fseIBYDcJCihqoeAf07bt0hgvJWWE=.259496ed-1883-4035-a4e5-e6c45f511707@github.com>

On Tue, 9 Mar 2021 13:57:24 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> Update a new patch that reduce the memory consumption issue.
>> As mentioned in the CR,  there is internal buffer used for segmented heap dump.  The dumped object data firstly write into this buffer and then flush() when the size is known. when the internal buffer is full, the current implementation do:
>> 
>> - new a larger buffer,  copy data from old buffer into the new one, and then use it as the internal buffer.
>> 
>> This could cause large memory consumption because the old buffer data are copied, and also the old buffer can not be "free" until next GC. 
>> 
>> For example, if the internel buffer's length is 1MB, when it is full, a new 2MB buffer is allocated so there is actually 3MB memory taken (old buffer + new buffer). And in this case, for the ~4GB large array, it keeps generating new buffers and do copying, which takes both CPU and memory intensively and cause the timeout issue.
>> 
>> This patch optimize it by creating a array list of byte[]. when old buffer is full, it saved into the list and the new one is created and used as the internal buffer. In this case, the above example takes 2MB?1MB for old? saved in the list; and 1MB for the new buffer)
>> 
>> Together with the "write through" mode introduced in this PR, by which all arrays are write through to underlying stream and hence no extra buffer requried. The PR could help fix the LargeArray issue and also save memory.
>> 
>> Thanks!
>> Lin
>
> As discussed in CR https://bugs.openjdk.java.net/browse/JDK-8262386, the byte[] list is much more like an optimization. Revert it in the PR and I will create a separate CR and PR for it. 
> 
> Thanks,
> Lin

Hi Lin,

One concern I have is the naming used in the fix.
First, the term write-through you use is unusual and confusing.
Would it better to say 'direct or unbuffered output' instead?

 612         // Now the total size of data to dump is known and can be filled to segment header.
 613         // Enable write-through mode to avoid internal buffer copies.
 614         if (useSegmentedHeapDump) {
 615             long longBytes = length * typeSize + headerSize;
 616             int bytesToWrite = (int) (longBytes);
 617             hprofBufferedOut.fillSegmentSizeAndEnableWriteThrough(bytesToWrite);
 618         }

Why 'longBytes' ? The scope of this local variable is very short, and it is clear that its type is long.
Why not something like 'size' or 'totalSize' ?
There is no need in parentheses around the 'longBytes' at L616.
Also, there is no need to for one more local variable 'bytesToWrite'.
Something like below is more clear:
  int size = (int)(length * typeSize + headerSize);
I agree with Chris, it is confusing why the decision about write-trough mode is made in this method.
The method fillSegmentSizeAndEnableWriteThrough() is called for any array if useSegmentedHeapDump == true,
so any segmented output for arrays is direct (in write-through mode).
Is this new dimension really needs to be introduced?

Thanks,
Serguei

-------------

PR: https://git.openjdk.java.net/jdk/pull/2803

From sspitsyn at openjdk.java.net  Wed Mar 17 06:43:05 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 17 Mar 2021 06:43:05 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out
In-Reply-To: <2J1CEmVaXJuvU3fseIBYDcJCihqoeAf07bt0hgvJWWE=.259496ed-1883-4035-a4e5-e6c45f511707@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
 <Zvf7GN59hJdc7SgVRao3cEbcpU99CbGceULIfJnDJOE=.4bd79c51-6b9b-4ff9-9ada-dc43fd6ca6e8@github.com>
 <e6bMvI_trIEXu7SAiM98-OpZug3Mwli00owZzLXxJNo=.fa0b5857-28b8-428d-9477-61044e32ad49@github.com>
 <oaMRL-GuwQKYlGByJvPhHH63A4LTvQLsL2W6BOIS6cc=.5ee0e7f9-bdc3-4e51-9fcf-999d607730c1@github.com>
 <7p7PD78B0fKuSonRZ44rQWvBKHabsz4n9VT4WbVluFI=.e4248320-f134-4ed0-b073-a3466970932c@github.com>
 <cedPjc6Gumib0S_yqDLAm8up9lPEGguw5w5LJblpKHM=.cad805fe-ab47-4eb4-8c78-e2a17109a2ce@github.com>
 <69h5uaXSdgc4Fkhla6QdtoezGPyVcFMNasVI8iNxYWI=.3a7c3e6a-8dfa-4ff1-a7cf-db71d3ea7bbf@github.com>
 <2J1CEmVaXJuvU3fseIBYDcJCihqoeAf07bt0hgvJWWE=.259496ed-1883-4035-a4e5-e6c45f511707@github.com>
Message-ID: <rFBFEymgIrkLQdW4dLSSRthpE6vu629ScEsMmO8YM3w=.a8182d50-bb9e-4a2a-9cec-c965f80cca80@github.com>

On Wed, 17 Mar 2021 06:33:41 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> As discussed in CR https://bugs.openjdk.java.net/browse/JDK-8262386, the byte[] list is much more like an optimization. Revert it in the PR and I will create a separate CR and PR for it. 
>> 
>> Thanks,
>> Lin
>
> Hi Lin,
> 
> One concern I have is the naming used in the fix.
> First, the term write-through you use is unusual and confusing.
> Would it better to say 'direct or unbuffered output' instead?
> 
>  612         // Now the total size of data to dump is known and can be filled to segment header.
>  613         // Enable write-through mode to avoid internal buffer copies.
>  614         if (useSegmentedHeapDump) {
>  615             long longBytes = length * typeSize + headerSize;
>  616             int bytesToWrite = (int) (longBytes);
>  617             hprofBufferedOut.fillSegmentSizeAndEnableWriteThrough(bytesToWrite);
>  618         }
> 
> Why 'longBytes' ? The scope of this local variable is very short, and it is clear that its type is long.
> Why not something like 'size' or 'totalSize' ?
> There is no need in parentheses around the 'longBytes' at L616.
> Also, there is no need to for one more local variable 'bytesToWrite'.
> Something like below is more clear:
>   int size = (int)(length * typeSize + headerSize);
> I agree with Chris, it is confusing why the decision about write-trough mode is made in this method.
> The method fillSegmentSizeAndEnableWriteThrough() is called for any array if useSegmentedHeapDump == true,
> so any segmented output for arrays is direct (in write-through mode).
> Is this new dimension really needs to be introduced?
> 
> Thanks,
> Serguei

One more question.
1367         public synchronized void write(int b) throws IOException {
1368            if (segmentMode && !writeThrough) {
1369                if (segmentWritten == 0) {
1370                    // At the begining of the segment.
1371                    writeSegmentHeader();
1372                } else if (segmentWritten == segmentBuffer.length) {
1373                    // Internal buffer is full, extend a larger one.
1374                    int newSize = segmentBuffer.length + SEGMENT_BUFFER_INC_SIZE;
1375                    byte newBuf[] = new byte[newSize];
1376                    System.arraycopy(segmentBuffer, 0, newBuf, 0, segmentWritten);
1377                    segmentBuffer = newBuf;
1378                }
1379                segmentBuffer[segmentWritten++] = (byte)b;
1380                return;
1381            }
1382            super.write(b);
1383         }
Does the check for "!writeThrough" at L1368 means there is no need to write the segment header (as at L1371)?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2803

From sspitsyn at openjdk.java.net  Wed Mar 17 07:06:08 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 17 Mar 2021 07:06:08 GMT
Subject: RFR: 8246494: introduce vm.flagless at-requires property
In-Reply-To: <fC51vNiDPG7UUjFvMEJnbbKV0ejluFe023gEgyFq1eI=.f55fd064-9aba-4f05-a3ea-ad6959e1c9bc@github.com>
References: <fC51vNiDPG7UUjFvMEJnbbKV0ejluFe023gEgyFq1eI=.f55fd064-9aba-4f05-a3ea-ad6959e1c9bc@github.com>
Message-ID: <bBNRweeD_iKNaM75dvHdISVn8dKjGKEkbRagvhxAi_s=.410d0148-9b43-4b84-990a-bbe2455adff3@github.com>

On Tue, 2 Mar 2021 23:27:21 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> resurrecting old [RFR](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-June/041981.html):
> 
>> Hi all,
>> 
>> could you please review the patch which introduces a new @requires property to filter out the tests which ignore externally provided JVM flags?
>> 
>> the idea behind this patch is to have a way to clearly mark tests which ignore flags, so 
>> a) it's obvious that they don't execute a flag-guarded code/feature, and extra care should be taken to use them to verify any flag-guarded changed;
>> b) they can be easily excluded from runs w/ flags.
>> 
>> @requires and VMProps allows us to achieve both, so it's been decided to add a new property `vm.flagless`. `vm.flagless` is set to false if there are any XX flags other than `-XX:MaxRAMPercentage` and `-XX:CreateCoredumpOnCrash` (which are known to be set almost always) or any X flags other `-Xmixed`; in other words any tests w/ `@requires vm.flagless` will be excluded from runs w/ any other X / XX flags passed via `-vmoption` / `-javaoption`. in rare cases, when one still wants to run the tests marked by `vm.flagless`  w/ external flags, `vm.flagless` can be forcefully set to true by setting any value to `TEST_VM_FLAGLESS` env. variable.
>> 
>> this patch adds necessary common changes and marks common tests, namely Scimark, GTestWrapper and TestNativeProcessBuilder. Component-specific tests will be marked separately by the corresponding subtasks of 8151707[1].
>> 
>> please note, the patch depends on CODETOOLS-7902336[2], which will be included in the next jtreg version, so this patch is to be integrated only after jtreg5.1 is promoted and we switch to use it by 8246387[3].
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8246494
>> webrev: http://cr.openjdk.java.net/~iignatyev//8246494/webrev.00
>> testing: marked tests w/ different XX and X flags w/ and w/o TEST_VM_FLAGLESS env. var, and w/o any flags
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8151707
>> [2] https://bugs.openjdk.java.net/browse/CODETOOLS-7902336
>> [3] https://bugs.openjdk.java.net/browse/JDK-8246387
>> 
> 
> after offline discussion with @pliden, it has been decided to reduce the scope of [8246499](https://bugs.openjdk.java.net/browse/JDK-8246499) and not mark the tests that use `UseXGC` flags for selection, e.g. `test/hotspot/jtreg/gc/z/TestSmallHeap.java`.
> 
> Thanks,
> -- Igor

Igor,
The fix looks good to me.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2800

From sspitsyn at openjdk.java.net  Wed Mar 17 07:21:08 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 17 Mar 2021 07:21:08 GMT
Subject: RFR: 8262881: port JVM/DI tests from JDK-4413752 to JVM/TI
In-Reply-To: <XOECrKnBcmSRjfY2cM-GqFs3jMr0fTy7KJUCUHZ0HGw=.54872a68-97e9-481a-871e-eade80a51604@github.com>
References: <XOECrKnBcmSRjfY2cM-GqFs3jMr0fTy7KJUCUHZ0HGw=.54872a68-97e9-481a-871e-eade80a51604@github.com>
Message-ID: <pIS66umBFPY0bsix6EW_zdVNzFG5J6A33FHVrpvEJ64=.c3cc75d9-25cd-4fc0-b3bc-35fe628d5e2c@github.com>

On Tue, 9 Mar 2021 21:08:54 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Add three tests from JDK-4413752 ported to JVM/TI:
> 
> - RawMonitorEnter() with SuspendThread()
>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithRawMonitorEnter/SuspendWithRawMonitorEnter.java
>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithRawMonitorEnter/libSuspendWithRawMonitorEnter.cpp
> 
> - ObjectMonitor enter() with SuspendThread()
>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorEnter/SuspendWithObjectMonitorEnter.java
>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorEnter/libSuspendWithObjectMonitorEnter.cpp
> 
> - ObjectMonitor wait() with SuspendThread
>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java
>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/libSuspendWithObjectMonitorWait.cpp
> 
> The Java files have a transaction diagram to show what each of the
> threads in the test is doing.

Hi Dan,
It is interesting how much these tests were changed when ported.
A couple of indent-related comments.
There are incorrect indents in the following lines in all .cpp files:
 ```
68 Java_SuspendWithObjectMonitorEnter_GetResult(JNIEnv *env, jclass cls) {
 69     return iGlobalStatus;
 70 }
  72 JNIEXPORT void JNICALL
 73 Java_SuspendWithObjectMonitorEnter_SetPrintDebug(JNIEnv *env, jclass cls) {
 74     printdebug = 1;
 75 }
 97 Java_SuspendWithObjectMonitorEnterWorker_GetPrintDebug(JNIEnv *env, jclass cls) {
 98     return printdebug;
 99 }

Thanks,
Serguei

-------------

PR: https://git.openjdk.java.net/jdk/pull/2899

From sspitsyn at openjdk.java.net  Wed Mar 17 07:24:13 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 17 Mar 2021 07:24:13 GMT
Subject: RFR: 8263434: Dangling references after
 MethodComparator::methods_EMCP [v3]
In-Reply-To: <ZlLuPPL3A3B_vg6-2rWPwBjJfY6b8tqQeuDxAYl1EMc=.06497fe9-6e57-4ca4-adb8-29f5a7dcf6ad@github.com>
References: <asxiOdUujvGXb5SvzrRSkAuVcrHz9xTFpwFZ90uJQaM=.f7576bd6-d4ba-4b7a-960f-f8e79ce6c54c@github.com>
 <ZlLuPPL3A3B_vg6-2rWPwBjJfY6b8tqQeuDxAYl1EMc=.06497fe9-6e57-4ca4-adb8-29f5a7dcf6ad@github.com>
Message-ID: <czB0et051O3g1JZyrLbriYMDnuHhv1VI49Cbk0qjzsg=.1ca91b47-f92c-431b-a44c-0cdfb3482d95@github.com>

On Wed, 17 Mar 2021 06:35:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> SonarCloud reports the following problem in MethodComparator::methods_EMCP:
>>  "Address of stack memory associated with local variable 's_new' is still referred to by the global variable '_s_new' upon returning to the caller. This will be a dangling reference"
>> 
>> Code inspection reveals the assignment to static variables is only needed to pass them to helper methods. So, while this is not a detectable bug (yet), it is still cleaner not to expose stack variables in globals.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug `tier1`
>>  - [x] Linux x86_64 fastdebug, `vmTestbase_nsk_jvmti`
>
> Aleksey Shipilev 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:
> 
>  - Update copyrights
>  - Drop excess parentheses
>  - Merge branch 'master' into JDK-8263434-dangling-methodcomparator-ecmp
>  - Sprinkling consts
>  - 8263434: Dangling references after MethodComparator::methods_EMCP

Marked as reviewed by sspitsyn (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2937

From lzang at openjdk.java.net  Wed Mar 17 07:24:09 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 17 Mar 2021 07:24:09 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out
In-Reply-To: <rFBFEymgIrkLQdW4dLSSRthpE6vu629ScEsMmO8YM3w=.a8182d50-bb9e-4a2a-9cec-c965f80cca80@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
 <Zvf7GN59hJdc7SgVRao3cEbcpU99CbGceULIfJnDJOE=.4bd79c51-6b9b-4ff9-9ada-dc43fd6ca6e8@github.com>
 <e6bMvI_trIEXu7SAiM98-OpZug3Mwli00owZzLXxJNo=.fa0b5857-28b8-428d-9477-61044e32ad49@github.com>
 <oaMRL-GuwQKYlGByJvPhHH63A4LTvQLsL2W6BOIS6cc=.5ee0e7f9-bdc3-4e51-9fcf-999d607730c1@github.com>
 <7p7PD78B0fKuSonRZ44rQWvBKHabsz4n9VT4WbVluFI=.e4248320-f134-4ed0-b073-a3466970932c@github.com>
 <cedPjc6Gumib0S_yqDLAm8up9lPEGguw5w5LJblpKHM=.cad805fe-ab47-4eb4-8c78-e2a17109a2ce@github.com>
 <69h5uaXSdgc4Fkhla6QdtoezGPyVcFMNasVI8iNxYWI=.3a7c3e6a-8dfa-4ff1-a7cf-db71d3ea7bbf@github.com>
 <2J1CEmVaXJuvU3fseIBYDcJCihqoeAf07bt0hgvJWWE=.259496ed-1883-4035-a4e5-e6c45f511707@github.com>
 <rFBFEymgIrkLQdW4dLSSRthpE6vu629ScEsMmO8YM3w=.a8182d50-bb9e-4a2a-9cec-c965f80cca80@github.com>
Message-ID: <mzZdkiwtjfisDNUd2cN9YNDYeFDFrj92wsX5tnaqzxA=.96a75c19-42a1-4dfa-960f-910476447ffd@github.com>

On Wed, 17 Mar 2021 06:40:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Hi Lin,
>> 
>> One concern I have is the naming used in the fix.
>> First, the term write-through you use is unusual and confusing.
>> Would it better to say 'direct or unbuffered output' instead?
>> 
>>  612         // Now the total size of data to dump is known and can be filled to segment header.
>>  613         // Enable write-through mode to avoid internal buffer copies.
>>  614         if (useSegmentedHeapDump) {
>>  615             long longBytes = length * typeSize + headerSize;
>>  616             int bytesToWrite = (int) (longBytes);
>>  617             hprofBufferedOut.fillSegmentSizeAndEnableWriteThrough(bytesToWrite);
>>  618         }
>> 
>> Why 'longBytes' ? The scope of this local variable is very short, and it is clear that its type is long.
>> Why not something like 'size' or 'totalSize' ?
>> There is no need in parentheses around the 'longBytes' at L616.
>> Also, there is no need to for one more local variable 'bytesToWrite'.
>> Something like below is more clear:
>>   int size = (int)(length * typeSize + headerSize);
>> I agree with Chris, it is confusing why the decision about write-trough mode is made in this method.
>> The method fillSegmentSizeAndEnableWriteThrough() is called for any array if useSegmentedHeapDump == true,
>> so any segmented output for arrays is direct (in write-through mode).
>> Is this new dimension really needs to be introduced?
>> 
>> Thanks,
>> Serguei
>
> One more question.
> 1367         public synchronized void write(int b) throws IOException {
> 1368            if (segmentMode && !writeThrough) {
> 1369                if (segmentWritten == 0) {
> 1370                    // At the begining of the segment.
> 1371                    writeSegmentHeader();
> 1372                } else if (segmentWritten == segmentBuffer.length) {
> 1373                    // Internal buffer is full, extend a larger one.
> 1374                    int newSize = segmentBuffer.length + SEGMENT_BUFFER_INC_SIZE;
> 1375                    byte newBuf[] = new byte[newSize];
> 1376                    System.arraycopy(segmentBuffer, 0, newBuf, 0, segmentWritten);
> 1377                    segmentBuffer = newBuf;
> 1378                }
> 1379                segmentBuffer[segmentWritten++] = (byte)b;
> 1380                return;
> 1381            }
> 1382            super.write(b);
> 1383         }
> Does the check for "!writeThrough" at L1368 means there is no need to write the segment header (as at L1371)?

Dear Serguei, 
Thanks for review! I will refine it based on your comments.

> I agree with Chris, it is confusing why the decision about write-trough mode is made in this method 

The "write-through" mode requires filling the segment size in segment header before object contents are scanned and written, And it is only in method `calculateArrayMaxLength()` the array size could be known and filled, and therefore the `write-through` mode could be enabled.
(please be aware that current implementation of dumping non-array object does not calculate the object size first, which is 
the reason why internal buffer is required when compressed heap dump was introduced.)

> The method fillSegmentSizeAndEnableWriteThrough() is called for any array if useSegmentedHeapDump == true,
> so any segmented output for arrays is direct (in write-through mode).
> Is this new dimension really needs to be introduced?

IMO, it is better to dump all array object in `write-through` mode, because it could avoid memory consumption and performance issue when dumping large array. And the original implementation of object dump works like `write-through`, so this fix looks like sort of retrieve back to the original behavior.

On the other side, the specific issue described at JDK-8262386 could also be fixed if enable write-through mode only when array size is larger than maxBytes calculated in `calculateArrayMaxLength()`, because the test created an 4GB integer array.  But I suggest to `write-through` all array objects as this could help avoid similar issue that may happen when dump large array whose size is less than 4GB. 

> Does the check for "!writeThrough" at L1368 means there is no need to write the segment header (as at L1371)?
Yes, The `writeSegmentHeader(size)` is invoked in `fillSegmentSizeAndEnableWriteThrough()`, so there is no need to call it here.

Thanks!
Lin

-------------

PR: https://git.openjdk.java.net/jdk/pull/2803

From sspitsyn at openjdk.java.net  Wed Mar 17 07:30:11 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 17 Mar 2021 07:30:11 GMT
Subject: RFR: 8261262: Kitchensink24HStress.java crashed with
 EXCEPTION_ACCESS_VIOLATION [v2]
In-Reply-To: <kz2WEkHRTWF6lmASszUudk-Dkf9xEmWOBJnjXszrmHg=.14a677b7-d7f2-4d1d-b411-f4628a3c812d@github.com>
References: <N8sz_MwKWT2BdcrSQcU0_-2dUm30_AED4dtfUwLkGd0=.e11ba713-3da7-4fe0-ae03-062ec989e1f6@github.com>
 <kz2WEkHRTWF6lmASszUudk-Dkf9xEmWOBJnjXszrmHg=.14a677b7-d7f2-4d1d-b411-f4628a3c812d@github.com>
Message-ID: <BL8kmgjYZIf9gacmxHdMevf7taoExSZQfx9CtzXYJY4=.90ab5f01-944b-4194-9f4e-992844522058@github.com>

On Tue, 16 Mar 2021 08:07:39 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> When returning from the last Java frame back to vm and hitting a safepoint poll on that last return we sometimes have a last java frame but no vframe.
>> This seem to be a bug in itself, handled in: 8263576
>> 
>> Other places which uses vframe NULL checks it before, so let's do that in GetCurrentLocationClosure also.
>> 
>> Testing: nsk jdi/jvmti, jdk jdi, jck vm and t1-3.
>
> Robbin Ehn 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:
> 
>  - Typo
>  - Merge branch 'master' into 8261262
>  - Check vframe non-null

Marked as reviewed by sspitsyn (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3010

From rehn at openjdk.java.net  Wed Mar 17 07:30:12 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 17 Mar 2021 07:30:12 GMT
Subject: Integrated: 8261262: Kitchensink24HStress.java crashed with
 EXCEPTION_ACCESS_VIOLATION
In-Reply-To: <N8sz_MwKWT2BdcrSQcU0_-2dUm30_AED4dtfUwLkGd0=.e11ba713-3da7-4fe0-ae03-062ec989e1f6@github.com>
References: <N8sz_MwKWT2BdcrSQcU0_-2dUm30_AED4dtfUwLkGd0=.e11ba713-3da7-4fe0-ae03-062ec989e1f6@github.com>
Message-ID: <LmggtENLo-U4OKnHP3Mo9U_kdhsyT8lS4td1QElttw0=.20f57ff5-9e69-433e-8916-5f2068018462@github.com>

On Mon, 15 Mar 2021 11:48:38 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> When returning from the last Java frame back to vm and hitting a safepoint poll on that last return we sometimes have a last java frame but no vframe.
> This seem to be a bug in itself, handled in: 8263576
> 
> Other places which uses vframe NULL checks it before, so let's do that in GetCurrentLocationClosure also.
> 
> Testing: nsk jdi/jvmti, jdk jdi, jck vm and t1-3.

This pull request has now been integrated.

Changeset: 7b9d2562
Author:    Robbin Ehn <rehn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7b9d2562
Stats:     10 lines in 1 file changed: 0 ins; 3 del; 7 mod

8261262: Kitchensink24HStress.java crashed with EXCEPTION_ACCESS_VIOLATION

Reviewed-by: dcubed, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3010

From vsharma at openjdk.java.net  Wed Mar 17 08:20:08 2021
From: vsharma at openjdk.java.net (Vipin Sharma)
Date: Wed, 17 Mar 2021 08:20:08 GMT
Subject: RFR: JDK-8261095: Add test for clhsdb "symbol" command [v5]
In-Reply-To: <Pyw3-OnIZfHT6c2eXxsbPOar4KFY_X93WaIW1cKZgz0=.e58e4ecc-feea-495b-9755-3dab6537fc6f@github.com>
References: <vvBz34jYNl1w-989imPpF7K5U-3GYAzTTXGLqV2-2BU=.71fc7da5-36a3-48ba-ba2e-2100f90d1941@github.com>
 <k7f4nhGID78v-mM0t-B4T9jm5TfzWqGti6syAFcIuYY=.4017d209-f363-48e3-a45b-e3c090f3e4ec@github.com>
 <Pyw3-OnIZfHT6c2eXxsbPOar4KFY_X93WaIW1cKZgz0=.e58e4ecc-feea-495b-9755-3dab6537fc6f@github.com>
Message-ID: <DdM-mlrlyTxX28M-00A86iiy0HbkjyH0TrOq8UO5m7M=.71972fef-47b8-4032-8229-d5d3dc1a669e@github.com>

On Wed, 10 Mar 2021 06:04:00 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Vipin Sharma has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated formatting and grammer changes
>
> Marked as reviewed by ysuenaga (Reviewer).

This pull request is reviewed and ready to be integrated, please sponsor the request.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2863

From ysuenaga at openjdk.java.net  Wed Mar 17 08:33:10 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 17 Mar 2021 08:33:10 GMT
Subject: RFR: JDK-8261095: Add test for clhsdb "symbol" command [v5]
In-Reply-To: <DdM-mlrlyTxX28M-00A86iiy0HbkjyH0TrOq8UO5m7M=.71972fef-47b8-4032-8229-d5d3dc1a669e@github.com>
References: <vvBz34jYNl1w-989imPpF7K5U-3GYAzTTXGLqV2-2BU=.71fc7da5-36a3-48ba-ba2e-2100f90d1941@github.com>
 <k7f4nhGID78v-mM0t-B4T9jm5TfzWqGti6syAFcIuYY=.4017d209-f363-48e3-a45b-e3c090f3e4ec@github.com>
 <Pyw3-OnIZfHT6c2eXxsbPOar4KFY_X93WaIW1cKZgz0=.e58e4ecc-feea-495b-9755-3dab6537fc6f@github.com>
 <DdM-mlrlyTxX28M-00A86iiy0HbkjyH0TrOq8UO5m7M=.71972fef-47b8-4032-8229-d5d3dc1a669e@github.com>
Message-ID: <KNQCWL_y-x9j9-5OT1e7n36evruUdL_E2DKImALiHs4=.94cbc45d-33dd-4931-b005-1ab898d09d96@github.com>

On Wed, 17 Mar 2021 08:16:57 GMT, Vipin Sharma <vsharma at openjdk.org> wrote:

>> Marked as reviewed by ysuenaga (Reviewer).
>
> This pull request is reviewed and ready to be integrated, please sponsor the request.

Ok, I will sponsor you.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2863

From vsharma at openjdk.java.net  Wed Mar 17 08:33:12 2021
From: vsharma at openjdk.java.net (Vipin Sharma)
Date: Wed, 17 Mar 2021 08:33:12 GMT
Subject: Integrated: JDK-8261095: Add test for clhsdb "symbol" command
In-Reply-To: <vvBz34jYNl1w-989imPpF7K5U-3GYAzTTXGLqV2-2BU=.71fc7da5-36a3-48ba-ba2e-2100f90d1941@github.com>
References: <vvBz34jYNl1w-989imPpF7K5U-3GYAzTTXGLqV2-2BU=.71fc7da5-36a3-48ba-ba2e-2100f90d1941@github.com>
Message-ID: <LZWxXsz_3rykK17JAqGs8fLfER1CTkIf6-49t-YQPkU=.4d828104-fc4a-4929-8b0f-85feac9ab2d1@github.com>

On Sun, 7 Mar 2021 10:43:34 GMT, Vipin Sharma <vsharma at openjdk.org> wrote:

> JDK-8261095: Add test for clhsdb "symbol" command

This pull request has now been integrated.

Changeset: 086a66a0
Author:    Vipin Sharma <vsharma at openjdk.org>
Committer: Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/086a66a0
Stats:     104 lines in 1 file changed: 104 ins; 0 del; 0 mod

8261095: Add test for clhsdb "symbol" command

Reviewed-by: cjplummer, ysuenaga

-------------

PR: https://git.openjdk.java.net/jdk/pull/2863

From lzang at openjdk.java.net  Wed Mar 17 09:04:37 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 17 Mar 2021 09:04:37 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v6]
In-Reply-To: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
Message-ID: <Fz9pyQgUfQ_5ZfUOsOCbMarSh4haatlI57bkQxbGE1I=.1903232f-f7fc-4749-b62a-10d862e3c69d@github.com>

> 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out

Lin Zang has updated the pull request incrementally with one additional commit since the last revision:

  rename writeThrough to unbufferedMode and code refine

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2803/files
  - new: https://git.openjdk.java.net/jdk/pull/2803/files/7eb475e7..bb5827da

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2803&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2803&range=04-05

  Stats: 24 lines in 1 file changed: 0 ins; 1 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2803.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2803/head:pull/2803

PR: https://git.openjdk.java.net/jdk/pull/2803

From sspitsyn at openjdk.java.net  Wed Mar 17 09:33:11 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 17 Mar 2021 09:33:11 GMT
Subject: RFR: 8262271: SA: Add new stress test that tests getting the
 stack trace of an active thread [v2]
In-Reply-To: <On0kBXAE8Vt_Nc10SdnjaIIK2Q6vdhA5Wv9Ms7B1R2E=.eaf4631d-7bac-435d-950e-5d60282ef6f5@github.com>
References: <59yxshwLvp5MVCYf2F2THU0T-SJjWbQfQTRLpJ3o2K4=.0e2e73cb-71dd-41b1-a86c-3460631c544c@github.com>
 <xmMUx-npHPS9Y5S19PhQ1qFCBECWZGSb_drcjicVRaw=.d6f9c5b7-ed5f-4af2-812b-e133d6c8d8a4@github.com>
 <O6KfpioA7I1thHHw-5fxUQpRpMq50LIVNKtm2tfTt_A=.3195ef3c-1413-432a-9f33-9ce1c6a56145@github.com>
 <On0kBXAE8Vt_Nc10SdnjaIIK2Q6vdhA5Wv9Ms7B1R2E=.eaf4631d-7bac-435d-950e-5d60282ef6f5@github.com>
Message-ID: <JcGDkO_5hmshTmLgaYrFI7_s29tDkBL0EpGNm_fls8E=.096452c2-79e3-4521-b790-b749eb9a861c@github.com>

On Tue, 16 Mar 2021 23:11:49 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Chris,
>> New test looks okay to me.
>> How did you verify it is stable on all platforms?
>> Thanks,
>> Serguei
>
>>  How did you verify it is stable on all platforms?
> 
> I did 100s of runs on all our platforms with both product and debug builds, and also with -Xcomp.

Okay. Thanks, Chris.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2720

From shade at openjdk.java.net  Wed Mar 17 11:01:49 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 17 Mar 2021 11:01:49 GMT
Subject: Integrated: 8263434: Dangling references after
 MethodComparator::methods_EMCP
In-Reply-To: <asxiOdUujvGXb5SvzrRSkAuVcrHz9xTFpwFZ90uJQaM=.f7576bd6-d4ba-4b7a-960f-f8e79ce6c54c@github.com>
References: <asxiOdUujvGXb5SvzrRSkAuVcrHz9xTFpwFZ90uJQaM=.f7576bd6-d4ba-4b7a-960f-f8e79ce6c54c@github.com>
Message-ID: <cippYENDkEcQJwR9VNvEm83Xf4te0td4KXFFLhUD7Dk=.fc8f9e2c-d18b-43d5-ac91-0f2c45f6f379@github.com>

On Thu, 11 Mar 2021 11:02:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports the following problem in MethodComparator::methods_EMCP:
>  "Address of stack memory associated with local variable 's_new' is still referred to by the global variable '_s_new' upon returning to the caller. This will be a dangling reference"
> 
> Code inspection reveals the assignment to static variables is only needed to pass them to helper methods. So, while this is not a detectable bug (yet), it is still cleaner not to expose stack variables in globals.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `tier1`
>  - [x] Linux x86_64 fastdebug, `vmTestbase_nsk_jvmti`

This pull request has now been integrated.

Changeset: f9f2eef9
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f9f2eef9
Stats:     93 lines in 2 files changed: 4 ins; 7 del; 82 mod

8263434: Dangling references after MethodComparator::methods_EMCP

Reviewed-by: coleenp, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/2937

From dcubed at openjdk.java.net  Wed Mar 17 14:55:55 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 17 Mar 2021 14:55:55 GMT
Subject: RFR: 8263732: ProblemList serviceability/sa/ClhsdbSymbol.java on
 ZGC
In-Reply-To: <f0cmnP2-S2c_6UK-SKLtHowQj433qZfyMezU_f7bELs=.032578f8-ba55-4abc-8387-73c22a62f2df@github.com>
References: <f0cmnP2-S2c_6UK-SKLtHowQj433qZfyMezU_f7bELs=.032578f8-ba55-4abc-8387-73c22a62f2df@github.com>
Message-ID: <7LX5PRVkYFL1ylek8J4ita6W42la6C8wwm7afMDWL0c=.c17617ce-8847-45ac-9b32-575177cca300@github.com>

On Wed, 17 Mar 2021 14:49:39 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/sa/ClhsdbSymbol.java on ZGC in
> order to reduce the noise in the JDK17 CI.

@YaSuenag and @plummercj - just a heads up that this new test isn't happy with ZGC.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3050

From dcubed at openjdk.java.net  Wed Mar 17 14:55:55 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 17 Mar 2021 14:55:55 GMT
Subject: RFR: 8263732: ProblemList serviceability/sa/ClhsdbSymbol.java on ZGC
Message-ID: <f0cmnP2-S2c_6UK-SKLtHowQj433qZfyMezU_f7bELs=.032578f8-ba55-4abc-8387-73c22a62f2df@github.com>

A trivial fix to ProblemList serviceability/sa/ClhsdbSymbol.java on ZGC in
order to reduce the noise in the JDK17 CI.

-------------

Commit messages:
 - 8263732: ProblemList serviceability/sa/ClhsdbSymbol.java on ZGC

Changes: https://git.openjdk.java.net/jdk/pull/3050/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3050&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263732
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3050.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3050/head:pull/3050

PR: https://git.openjdk.java.net/jdk/pull/3050

From ysuenaga at openjdk.java.net  Wed Mar 17 15:10:48 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 17 Mar 2021 15:10:48 GMT
Subject: RFR: 8263732: ProblemList serviceability/sa/ClhsdbSymbol.java on
 ZGC
In-Reply-To: <f0cmnP2-S2c_6UK-SKLtHowQj433qZfyMezU_f7bELs=.032578f8-ba55-4abc-8387-73c22a62f2df@github.com>
References: <f0cmnP2-S2c_6UK-SKLtHowQj433qZfyMezU_f7bELs=.032578f8-ba55-4abc-8387-73c22a62f2df@github.com>
Message-ID: <PFlsPdnlm6Cwr1b2r-kc3zLIgfG2KIcwAfYCHTobZVg=.d7359910-68ff-4406-b4ae-bfd327469c06@github.com>

On Wed, 17 Mar 2021 14:49:39 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/sa/ClhsdbSymbol.java on ZGC in
> order to reduce the noise in the JDK17 CI.

LGTM

This problem has not appeared in tests on GitHub Actions.
https://github.com/openjdk/jdk/pull/2863/commits/c977ed1dfd6dafbb9e44e7efcf95c61a732b0989

-------------

Marked as reviewed by ysuenaga (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3050

From dcubed at openjdk.java.net  Wed Mar 17 15:16:51 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 17 Mar 2021 15:16:51 GMT
Subject: RFR: 8263732: ProblemList serviceability/sa/ClhsdbSymbol.java on
 ZGC
In-Reply-To: <PFlsPdnlm6Cwr1b2r-kc3zLIgfG2KIcwAfYCHTobZVg=.d7359910-68ff-4406-b4ae-bfd327469c06@github.com>
References: <f0cmnP2-S2c_6UK-SKLtHowQj433qZfyMezU_f7bELs=.032578f8-ba55-4abc-8387-73c22a62f2df@github.com>
 <PFlsPdnlm6Cwr1b2r-kc3zLIgfG2KIcwAfYCHTobZVg=.d7359910-68ff-4406-b4ae-bfd327469c06@github.com>
Message-ID: <sH9bM1ybqysq33Ja5SJR_p1FeudEnEdTRn7JGuV4jYI=.9a87b9d6-e800-4b0c-b06c-ed8e5a88d1cb@github.com>

On Wed, 17 Mar 2021 15:08:16 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> A trivial fix to ProblemList serviceability/sa/ClhsdbSymbol.java on ZGC in
>> order to reduce the noise in the JDK17 CI.
>
> LGTM
> 
> This problem has not appeared in tests on GitHub Actions.
> https://github.com/openjdk/jdk/pull/2863/commits/c977ed1dfd6dafbb9e44e7efcf95c61a732b0989

@YaSuenag - Thanks for the fast review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3050

From dcubed at openjdk.java.net  Wed Mar 17 15:16:51 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 17 Mar 2021 15:16:51 GMT
Subject: Integrated: 8263732: ProblemList serviceability/sa/ClhsdbSymbol.java
 on ZGC
In-Reply-To: <f0cmnP2-S2c_6UK-SKLtHowQj433qZfyMezU_f7bELs=.032578f8-ba55-4abc-8387-73c22a62f2df@github.com>
References: <f0cmnP2-S2c_6UK-SKLtHowQj433qZfyMezU_f7bELs=.032578f8-ba55-4abc-8387-73c22a62f2df@github.com>
Message-ID: <Pd25Tdbs963yyokO3xPkShZVTOp1TbF2dWy2mAAdidw=.df530270-b6bc-4a54-ae0d-c8c9227883fd@github.com>

On Wed, 17 Mar 2021 14:49:39 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/sa/ClhsdbSymbol.java on ZGC in
> order to reduce the noise in the JDK17 CI.

This pull request has now been integrated.

Changeset: b63b5d4c
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b63b5d4c
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8263732: ProblemList serviceability/sa/ClhsdbSymbol.java on ZGC

Reviewed-by: ysuenaga

-------------

PR: https://git.openjdk.java.net/jdk/pull/3050

From chris.plummer at oracle.com  Wed Mar 17 19:17:28 2021
From: chris.plummer at oracle.com (Chris Plummer)
Date: Wed, 17 Mar 2021 12:17:28 -0700
Subject: RFR: 8263732: ProblemList serviceability/sa/ClhsdbSymbol.java on
 ZGC
In-Reply-To: <7LX5PRVkYFL1ylek8J4ita6W42la6C8wwm7afMDWL0c=.c17617ce-8847-45ac-9b32-575177cca300@github.com>
References: <f0cmnP2-S2c_6UK-SKLtHowQj433qZfyMezU_f7bELs=.032578f8-ba55-4abc-8387-73c22a62f2df@github.com>
 <7LX5PRVkYFL1ylek8J4ita6W42la6C8wwm7afMDWL0c=.c17617ce-8847-45ac-9b32-575177cca300@github.com>
Message-ID: <adf91d0d-c07b-67a5-f98c-bfc3b3e70a51@oracle.com>

On 3/17/21 7:55 AM, Daniel D.Daugherty wrote:
> On Wed, 17 Mar 2021 14:49:39 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:
>
>> A trivial fix to ProblemList serviceability/sa/ClhsdbSymbol.java on ZGC in
>> order to reduce the noise in the JDK17 CI.
> @YaSuenag and @plummercj - just a heads up that this new test isn't happy with ZGC.
No surprising. I don't think any of the heap related GC tests work with ZGC.

However, the right thing to do here would be to problem list it under 
8220624 and close 8263730 as a dup. I'll get another CR and PR out later 
today.

Chris

>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/3050


From cjplummer at openjdk.java.net  Wed Mar 17 19:56:53 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 17 Mar 2021 19:56:53 GMT
Subject: RFR: 8263756: Fix ZGC ProblemList entry for
 serviceability/sa/ClhsdbSymbol.java
Message-ID: <eHvXq_GKVJWUYGNW6sYo1ctyPlhMmbfMO4ccHn2cm4g=.d9c39799-3c5d-4487-93f1-4e028a0e6a34@github.com>

I'd like to push this as a trivial change. serviceability/sa/ClhsdbSymbol.java was problem listed with the wrong CR. This PR will correct that and also put the entry in sorted order.

-------------

Commit messages:
 - Fix problemlist entry for serviceability/sa/ClhsdbSymbol.java

Changes: https://git.openjdk.java.net/jdk/pull/3056/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3056&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263756
  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3056.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3056/head:pull/3056

PR: https://git.openjdk.java.net/jdk/pull/3056

From dcubed at openjdk.java.net  Wed Mar 17 20:18:49 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 17 Mar 2021 20:18:49 GMT
Subject: RFR: 8263756: Fix ZGC ProblemList entry for
 serviceability/sa/ClhsdbSymbol.java
In-Reply-To: <eHvXq_GKVJWUYGNW6sYo1ctyPlhMmbfMO4ccHn2cm4g=.d9c39799-3c5d-4487-93f1-4e028a0e6a34@github.com>
References: <eHvXq_GKVJWUYGNW6sYo1ctyPlhMmbfMO4ccHn2cm4g=.d9c39799-3c5d-4487-93f1-4e028a0e6a34@github.com>
Message-ID: <3IvU89xpJsz0Y7T3GAW6S__MiiF5d5_kU9mJk44jlug=.bb8567bd-a64c-4705-b88e-57650dcbdc42@github.com>

On Wed, 17 Mar 2021 19:35:20 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I'd like to push this as a trivial change. serviceability/sa/ClhsdbSymbol.java was problem listed with the wrong CR. This PR will correct that and also put the entry in sorted order.

Thumbs up.

I agree that this is a trivial change.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3056

From cjplummer at openjdk.java.net  Wed Mar 17 21:20:49 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 17 Mar 2021 21:20:49 GMT
Subject: RFR: 8263670: pmap and pstack in jhsdb do not work on debug server
In-Reply-To: <OzFp9WFONUqIUYqdZ78D04bfnhgOSaeB1WqmPtyUdA0=.7dcf74d3-6819-4c9c-b878-a26cfcd0cbc6@github.com>
References: <OzFp9WFONUqIUYqdZ78D04bfnhgOSaeB1WqmPtyUdA0=.7dcf74d3-6819-4c9c-b878-a26cfcd0cbc6@github.com>
Message-ID: <uDQpuw4KibtXn1vypH3Vg8cV-RTzzkUpfIlH-qI2GnM=.547a2af0-d246-40e8-84e7-9757f7440b8f@github.com>

On Tue, 16 Mar 2021 12:01:30 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> jhsdb supports pmap (jhsdb jmap) and pstack (jhsdb jstack --mixed), and they work fine if they attach to live process or to coredump, however they do not work on debug server as following:
> 
> $ jhsdb jmap --connect localhost
> Attaching to remote server localhost, please wait...
> Debugger attached successfully.
> Server compiler detected.
> JVM version is 11.0.10+9
> remote configuration is not yet implemented
> 
> pmap and pstack depend on CDebugger in SA, however it would not be set in case of remote debugger client. We can avoid it if we can delegate the process to debug server.

test/hotspot/jtreg/serviceability/sa/sadebugd/PmapOnDebugdTest.java line 56:

> 54:             // are not required.
> 55:             throw new SkippedException("Cannot run this test on OSX if adding privileges is required.");
> 56:         }

Also, this code and the giant comment block will now be in 3 places. Maybe it should be moved to SATestUtils. Maybe something like `validateSADebugDPrivileges()`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3027

From amenkov at openjdk.java.net  Wed Mar 17 21:52:07 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 17 Mar 2021 21:52:07 GMT
Subject: RFR: 8262001:
 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java failed with
 "RuntimeException: Current Peak = 14 Expected to be == previous peak = 7 + 8"
 [v2]
In-Reply-To: <TZBFsiqKOxxbp-tN07-glyx947_eN6jTUEJlFWZcpik=.043c257d-d7ec-4df2-8504-1914e55e3975@github.com>
References: <TZBFsiqKOxxbp-tN07-glyx947_eN6jTUEJlFWZcpik=.043c257d-d7ec-4df2-8504-1914e55e3975@github.com>
Message-ID: <0nMXmY43CDnjqzfymVHCcZajdgaJnto5v74vPgS8Zpo=.59f243d3-9e1f-4c5e-b120-a91f03773736@github.com>

> The fix updates ResetPeakThreadCount.java test - increases number of threads, but relaxes conditions so start/termination of system threads don't cause failures.
> Additional changes:
> - store threads in a list instead of array (we need only to start/terminate some number of threads, so linked list works better);
> - flags for thread termination are moved to thread class;
> - store values from ThreadMXBean.getPeakThreadCount() and getThreadCount() in int instead of long (the methods return int values)

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  added dot at the end of comment

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2885/files
  - new: https://git.openjdk.java.net/jdk/pull/2885/files/8252f4bc..b0b33d7d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2885&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2885&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2885.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2885/head:pull/2885

PR: https://git.openjdk.java.net/jdk/pull/2885

From cjplummer at openjdk.java.net  Wed Mar 17 22:06:48 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 17 Mar 2021 22:06:48 GMT
Subject: Integrated: 8263756: Fix ZGC ProblemList entry for
 serviceability/sa/ClhsdbSymbol.java
In-Reply-To: <eHvXq_GKVJWUYGNW6sYo1ctyPlhMmbfMO4ccHn2cm4g=.d9c39799-3c5d-4487-93f1-4e028a0e6a34@github.com>
References: <eHvXq_GKVJWUYGNW6sYo1ctyPlhMmbfMO4ccHn2cm4g=.d9c39799-3c5d-4487-93f1-4e028a0e6a34@github.com>
Message-ID: <209KGiZnH5dx6nR2Uakojs-TwGFY_5XJvGm-DZYeiIY=.5e221739-26d4-432c-8f76-cfe16c8085a3@github.com>

On Wed, 17 Mar 2021 19:35:20 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I'd like to push this as a trivial change. serviceability/sa/ClhsdbSymbol.java was problem listed with the wrong CR. This PR will correct that and also put the entry in sorted order.

This pull request has now been integrated.

Changeset: 50ff0d4d
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/50ff0d4d
Stats:     2 lines in 1 file changed: 1 ins; 1 del; 0 mod

8263756: Fix ZGC ProblemList entry for serviceability/sa/ClhsdbSymbol.java

Reviewed-by: dcubed

-------------

PR: https://git.openjdk.java.net/jdk/pull/3056

From cjplummer at openjdk.java.net  Wed Mar 17 22:28:54 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 17 Mar 2021 22:28:54 GMT
Subject: RFR: 8263757: Remove serviceability/sa/ClhsdClasses.java from ZGC
 problem list
Message-ID: <ZZNqnI3e9hmzSCvzOa_dnZTwGWcGoBMrvEU5GD5yDIQ=.ddcd9eaf-d959-4607-9aa5-bbdfc5089727@github.com>

The test name has a typo (should be ClhsdbClasses - the 'b' is missing). Therefore it was not actually being excluded, and therefore it runs just fine with ZGC. This is expected since it is not a heap related test.

I'd like to push this as a trivial change.

-------------

Commit messages:
 - remove serviceability/sa/ClhsdClasses.java from zgc problemlist

Changes: https://git.openjdk.java.net/jdk/pull/3059/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3059&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263757
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3059.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3059/head:pull/3059

PR: https://git.openjdk.java.net/jdk/pull/3059

From dcubed at openjdk.java.net  Wed Mar 17 23:21:49 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 17 Mar 2021 23:21:49 GMT
Subject: RFR: 8263757: Remove serviceability/sa/ClhsdClasses.java from ZGC
 problem list
In-Reply-To: <ZZNqnI3e9hmzSCvzOa_dnZTwGWcGoBMrvEU5GD5yDIQ=.ddcd9eaf-d959-4607-9aa5-bbdfc5089727@github.com>
References: <ZZNqnI3e9hmzSCvzOa_dnZTwGWcGoBMrvEU5GD5yDIQ=.ddcd9eaf-d959-4607-9aa5-bbdfc5089727@github.com>
Message-ID: <9QB6pwWPTOZgxHjifkIwCtP5lyxM5LNTuavOz5RFcfw=.83cb58a4-abf8-4c71-8e5c-731f19569f0a@github.com>

On Wed, 17 Mar 2021 22:23:43 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The test name has a typo (should be ClhsdbClasses - the 'b' is missing). Therefore it was not actually being excluded, and therefore it runs just fine with ZGC. This is expected since it is not a heap related test.
> 
> I'd like to push this as a trivial change.

Thumbs up.

I agree that this is a trivial change.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3059

From amenkov at openjdk.java.net  Wed Mar 17 23:25:47 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 17 Mar 2021 23:25:47 GMT
Subject: RFR: 8262080:
 vmTestbase/nsk/jdi/Event/request/request001/TestDescription.java failed with
 "ERROR: new event is not ThreadStartEvent" [v4]
In-Reply-To: <YhtdCxNJjupie5CLt9zVrk_7v0KkzgAANlFtfZoVmqU=.2c1a3a90-0cee-407e-85a5-2aa7dbd702f9@github.com>
References: <JzsafYgSso5aYsPImTLCz52dN96s-BJbY3eMrHwxLRw=.9e781f40-5e59-425e-ab83-03872256cb9d@github.com>
 <sr-R0M5HETEwHsjowzDcTsQ3yeZIlwVyi0ew33tlPMc=.5d022524-1bc1-45f5-87d6-5a50cfbfd168@github.com>
 <YhtdCxNJjupie5CLt9zVrk_7v0KkzgAANlFtfZoVmqU=.2c1a3a90-0cee-407e-85a5-2aa7dbd702f9@github.com>
Message-ID: <TEErFEhzAehlqTOF60Wf3LV5AqCvFF_0nN57B8gxFxc=.fb6ad746-d4f0-4af5-ba86-1ffba145c9f0@github.com>

On Wed, 17 Mar 2021 01:11:25 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> More clear message would be something like:
> "Thread is not expected, skipping XXX event: " + ...

To me this version does not look clearer :)
I suppose you want to see a note that the event is skipped.
What do you think about
log2("Got XXXEvent for wrong thread, skipping the event: " + event);

-------------

PR: https://git.openjdk.java.net/jdk/pull/2927

From cjplummer at openjdk.java.net  Wed Mar 17 23:27:50 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 17 Mar 2021 23:27:50 GMT
Subject: RFR: 8263757: Remove serviceability/sa/ClhsdClasses.java from ZGC
 problem list
In-Reply-To: <9QB6pwWPTOZgxHjifkIwCtP5lyxM5LNTuavOz5RFcfw=.83cb58a4-abf8-4c71-8e5c-731f19569f0a@github.com>
References: <ZZNqnI3e9hmzSCvzOa_dnZTwGWcGoBMrvEU5GD5yDIQ=.ddcd9eaf-d959-4607-9aa5-bbdfc5089727@github.com>
 <9QB6pwWPTOZgxHjifkIwCtP5lyxM5LNTuavOz5RFcfw=.83cb58a4-abf8-4c71-8e5c-731f19569f0a@github.com>
Message-ID: <_jnCgBf5A04jdKz_XDVV0LwYqeImcPP4eEZar1O7md4=.d290d2d4-2e9b-443a-a5c6-04253d6d2380@github.com>

On Wed, 17 Mar 2021 23:19:10 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> The test name has a typo (should be ClhsdbClasses - the 'b' is missing). Therefore it was not actually being excluded, and therefore it runs just fine with ZGC. This is expected since it is not a heap related test.
>> 
>> I'd like to push this as a trivial change.
>
> Thumbs up.
> 
> I agree that this is a trivial change.

Thanks, Dan!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3059

From cjplummer at openjdk.java.net  Wed Mar 17 23:27:51 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 17 Mar 2021 23:27:51 GMT
Subject: Integrated: 8263757: Remove serviceability/sa/ClhsdClasses.java from
 ZGC problem list
In-Reply-To: <ZZNqnI3e9hmzSCvzOa_dnZTwGWcGoBMrvEU5GD5yDIQ=.ddcd9eaf-d959-4607-9aa5-bbdfc5089727@github.com>
References: <ZZNqnI3e9hmzSCvzOa_dnZTwGWcGoBMrvEU5GD5yDIQ=.ddcd9eaf-d959-4607-9aa5-bbdfc5089727@github.com>
Message-ID: <G2UH_7jIyNWlB7jToEZrFpjurgG7Greaf6nQNmWaU-s=.a5f0dbb8-ffe7-4c6c-8d8c-c2dd809db04f@github.com>

On Wed, 17 Mar 2021 22:23:43 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The test name has a typo (should be ClhsdbClasses - the 'b' is missing). Therefore it was not actually being excluded, and therefore it runs just fine with ZGC. This is expected since it is not a heap related test.
> 
> I'd like to push this as a trivial change.

This pull request has now been integrated.

Changeset: 5d5813a5
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5d5813a5
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8263757: Remove serviceability/sa/ClhsdClasses.java from ZGC problem list

Reviewed-by: dcubed

-------------

PR: https://git.openjdk.java.net/jdk/pull/3059

From amenkov at openjdk.java.net  Wed Mar 17 23:48:54 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 17 Mar 2021 23:48:54 GMT
Subject: RFR: 8262083:
 vmTestbase/nsk/jvmti/SetEventNotificationMode/setnotif001/TestDescription.java
 failed with "No notification: event JVMTI_EVENT_FRAME_POP (61)"
Message-ID: <qaKtyTEgt_5tOUH_SP_x4sRVTuS8XBW95kSzty7TsAY=.85d10651-f3a1-477d-9e00-2a3a82d171dd@github.com>

The test requests NotifyFrame event from MethodEntry handler expecting that 1st MethodEntry event is generated for main thread.
The fix adds a check that the thread is correct and skips event from other threads

-------------

Commit messages:
 - JDK-8262083

Changes: https://git.openjdk.java.net/jdk/pull/3060/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3060&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262083
  Stats: 35 lines in 2 files changed: 15 ins; 11 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3060.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3060/head:pull/3060

PR: https://git.openjdk.java.net/jdk/pull/3060

From lmesnik at openjdk.java.net  Thu Mar 18 01:45:50 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 18 Mar 2021 01:45:50 GMT
Subject: RFR: 8262083:
 vmTestbase/nsk/jvmti/SetEventNotificationMode/setnotif001/TestDescription.java
 failed with "No notification: event JVMTI_EVENT_FRAME_POP (61)"
In-Reply-To: <qaKtyTEgt_5tOUH_SP_x4sRVTuS8XBW95kSzty7TsAY=.85d10651-f3a1-477d-9e00-2a3a82d171dd@github.com>
References: <qaKtyTEgt_5tOUH_SP_x4sRVTuS8XBW95kSzty7TsAY=.85d10651-f3a1-477d-9e00-2a3a82d171dd@github.com>
Message-ID: <toh4GSy4A10NzfTrmQR1xZ5sSKJpVKPHZEVDghDwyFI=.6504b2ca-57f2-4750-ad65-6c0a0ddc33e5@github.com>

On Wed, 17 Mar 2021 23:42:46 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The test requests NotifyFrame event from MethodEntry handler expecting that 1st MethodEntry event is generated for main thread.
> The fix adds a check that the thread is correct and skips event from other threads

The fix is good. Might be it is needed to comment why the SetEventNotification on a single thread is not used.

-------------

Marked as reviewed by lmesnik (Committer).

PR: https://git.openjdk.java.net/jdk/pull/3060

From minqi at openjdk.java.net  Thu Mar 18 03:34:53 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 18 Mar 2021 03:34:53 GMT
Subject: RFR: 8259070: Add jcmd option to dump CDS [v4]
In-Reply-To: <wwBek7Yf05ftyApvSnOfw3CL3Yb8T38kdpCcv0gOXfM=.c19076b2-25ea-48cf-bc8b-4700b5549fc1@github.com>
References: <hwrc1zAz8G180ToL-C3EuUIF-5R17F5Gm1zcPMBpOtE=.e002a377-e0e2-485b-a08e-b63675a9746b@github.com>
 <wwBek7Yf05ftyApvSnOfw3CL3Yb8T38kdpCcv0gOXfM=.c19076b2-25ea-48cf-bc8b-4700b5549fc1@github.com>
Message-ID: <fLdhEBEa4c5u6a4mevlnTAFPk4AJsHj8VDEjCXedk9M=.47574dac-aaf1-4a4b-a9ec-051891f46a4e@github.com>

On Fri, 26 Feb 2021 21:39:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Yumin Qi 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 filter more flags to exclude in static dump, add more test cases
>>  - Merge branch 'master' into jdk-8259070
>>  - Fix white space in CDS.java
>>  - Add function CDS.dumpSharedArchive in java to dump shared archive
>>  - 8259070: Add jcmd option to dump CDS
>
> src/hotspot/share/memory/dynamicArchive.cpp line 347:
> 
>> 345:   if (Arguments::GetSharedDynamicArchivePath() == NULL) {
>> 346:     if (!RecordDynamicDumpInfo) {
>> 347:       // If run with -XX:+RecordDynamicDumpInfo, DynamicDumpSharedSpaces will be turned on,
> 
> Is this check needed? It looks like `MetaspaceShared::cmd_dump_dynamic` will not call `DynamicArchive::dump()` unless the path was set up correctly.

Fixed. The warning is harmless so I just revert it back.

> src/hotspot/share/memory/metaspaceShared.cpp line 789:
> 
>> 787:   char filename[JVM_MAXPATHLEN];
>> 788:   const char* file = file_name;
>> 789:   assert(strcmp(cmd, "static_dump") == 0 || strcmp(cmd, "dynamic_dump") == 0, "Sanity check");
> 
> Since the caller of this function already performed the string validity check, I think it's better to pass `bool is_static` as a parameter and not pass `cmd`.

Moved to CDS.java, code is simple than this.

> src/hotspot/share/memory/metaspaceShared.cpp line 863:
> 
>> 861:     MutexLocker lock(ClassLoaderDataGraph_lock);
>> 862:     DumpClassListCLDClosure collect_classes(stream);
>> 863:     ClassLoaderDataGraph::loaded_cld_do(&collect_classes);
> 
> Need to close the stream.

Changed to use stack object so it will close the file at destrutor.

> src/hotspot/share/runtime/globals.hpp line 1896:
> 
>> 1894:                                                                             \
>> 1895:   product(bool, RecordDynamicDumpInfo, false,                               \
>> 1896:           "Record class info for jcmd Dynamic dump")                        \
> 
> "Record class info for jcmd VM.cds dynamic_dump"?

Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2737

From minqi at openjdk.java.net  Thu Mar 18 03:34:53 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 18 Mar 2021 03:34:53 GMT
Subject: RFR: 8259070: Add jcmd option to dump CDS [v4]
In-Reply-To: <8BIT_U1LoH-XHUajzOHKBe7xSETc4go9iVbaAlPcTlg=.6d34cc08-ed03-400e-9176-2d809bf1e6a5@github.com>
References: <hwrc1zAz8G180ToL-C3EuUIF-5R17F5Gm1zcPMBpOtE=.e002a377-e0e2-485b-a08e-b63675a9746b@github.com>
 <vYtu_WYJ_s19-jmj6lxvwsS4025cmF6tX-xkS-kQRqc=.afc0066d-84e2-405d-850f-39b349f96921@github.com>
 <8BIT_U1LoH-XHUajzOHKBe7xSETc4go9iVbaAlPcTlg=.6d34cc08-ed03-400e-9176-2d809bf1e6a5@github.com>
Message-ID: <ArECRMWeB6eND2f10GjRq09YWeBzevuCG65SegCLcoo=.f51cc8de-37d4-43fa-b236-9c7ec7853a3b@github.com>

On Sat, 27 Feb 2021 05:12:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/memory/metaspaceShared.cpp line 783:
>> 
>>> 781:   char* start = buffer + strlen(buffer);
>>> 782:   snprintf(start, buff_len, "%s ", arg);
>>> 783: }
>> 
>> Maybe move the above function to the StringUtils class under share/utilities?
>> Use `os::snprintf()` instead of `snprintf()`?
>
> The calculation is also wrong, this would overflow. You need:
>   char* start = buffer + strlen(buffer);
>   snprintf(start, buff_len - (start - buffer), "%s ", arg);
> - and maybe add an assert that strlen(buf) < bufflen. 
> - and as Ioi wrote, I'd use either one of os::snprintf or jio_snprintf since both guarantee zero termination on truncation.
> - or, just use strncat()

The new solution is using CDS.java to do the work.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2737

From minqi at openjdk.java.net  Thu Mar 18 03:34:58 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 18 Mar 2021 03:34:58 GMT
Subject: RFR: 8259070: Add jcmd option to dump CDS [v4]
In-Reply-To: <KwV5lKZ8BOdhaeyc-W9XOxJCdwahl3L_T8_DpJstiW8=.e5173cc7-a897-4b98-842c-07ce4984bb34@github.com>
References: <hwrc1zAz8G180ToL-C3EuUIF-5R17F5Gm1zcPMBpOtE=.e002a377-e0e2-485b-a08e-b63675a9746b@github.com>
 <wwBek7Yf05ftyApvSnOfw3CL3Yb8T38kdpCcv0gOXfM=.c19076b2-25ea-48cf-bc8b-4700b5549fc1@github.com>
 <2ARkZBqUR_xMiSXQYcq-rmOVxB62xIiIjzsJo0ZB9Xo=.1e29924e-5aaf-4356-ac6a-5b4b46c177ee@github.com>
 <KwV5lKZ8BOdhaeyc-W9XOxJCdwahl3L_T8_DpJstiW8=.e5173cc7-a897-4b98-842c-07ce4984bb34@github.com>
Message-ID: <YpYdQ1pDnqzySdQQH9niUTrtyPkNAMi5rP1R6bL_In8=.3ed950a8-be3f-4d61-a030-5102bc98b92b@github.com>

On Sat, 27 Feb 2021 18:11:38 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> How would it overflow? But I agree, I would not add jsa extension if the user did not specify one. I dislike when programs do that.
>
> `file_name` is user input that comes from the jcmd, so it can be arbitrarily long and exceed JVM_MAXPATHLEN characters.

The stuff no in java code, and is simple to deal with.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2737

From minqi at openjdk.java.net  Thu Mar 18 03:34:57 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 18 Mar 2021 03:34:57 GMT
Subject: RFR: 8259070: Add jcmd option to dump CDS [v4]
In-Reply-To: <vYtu_WYJ_s19-jmj6lxvwsS4025cmF6tX-xkS-kQRqc=.afc0066d-84e2-405d-850f-39b349f96921@github.com>
References: <hwrc1zAz8G180ToL-C3EuUIF-5R17F5Gm1zcPMBpOtE=.e002a377-e0e2-485b-a08e-b63675a9746b@github.com>
 <vYtu_WYJ_s19-jmj6lxvwsS4025cmF6tX-xkS-kQRqc=.afc0066d-84e2-405d-850f-39b349f96921@github.com>
Message-ID: <HNQbim4OTp8ChhmcZPaydofHs-qb7U_UMl6o9bXwWH8=.ed97a094-5083-4459-beb7-e3a2e14b3a2d@github.com>

On Fri, 26 Feb 2021 22:01:50 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Yumin Qi 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 filter more flags to exclude in static dump, add more test cases
>>  - Merge branch 'master' into jdk-8259070
>>  - Fix white space in CDS.java
>>  - Add function CDS.dumpSharedArchive in java to dump shared archive
>>  - 8259070: Add jcmd option to dump CDS
>
> src/hotspot/share/memory/metaspaceShared.cpp line 788:
> 
>> 786:   // The existing file will be overwritten.
>> 787:   char filename[JVM_MAXPATHLEN];
>> 788:   const char* file = file_name;
> 
> Is the variable at line 788 necessary? Could you just pass filename to callees?

New solutions using CDS.java to do the dump.

> src/hotspot/share/memory/metaspaceShared.cpp line 801:
> 
>> 799:         file = filename;
>> 800:       }
>> 801:     }
> 
> This block of code is very similar to lines 813 - 821 below. Maybe factor it into another function?

changed to use java to dump. That will be much simple to deal with string.

> src/hotspot/share/memory/metaspaceShared.cpp line 831:
> 
>> 829:   DumpClassListCLDClosure(fileStream* f) : CLDClosure() { _stream = f; }
>> 830:   ~DumpClassListCLDClosure() {
>> 831:     delete _stream; // The file need close since in child process it will be used.
> 
> Can you clarify the above comment?

Changed to use java to do the dump.

> test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTest.java line 213:
> 
>> 211:         if (!cdsEnabled) {
>> 212:             System.out.println("CDS is not available for this JDK, skip the test.");
>> 213:             return;
> 
> Should throw SkippedException instead.

Fixed

-------------

PR: https://git.openjdk.java.net/jdk/pull/2737

From minqi at openjdk.java.net  Thu Mar 18 03:34:58 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 18 Mar 2021 03:34:58 GMT
Subject: RFR: 8259070: Add jcmd option to dump CDS [v3]
In-Reply-To: <B-g8YZqbJMfAFPZvGpllxvOfoohFeI6MzeNdpEhOCvk=.dbdc6f3e-db3f-419b-8dc1-1ecc155b43a8@github.com>
References: <hwrc1zAz8G180ToL-C3EuUIF-5R17F5Gm1zcPMBpOtE=.e002a377-e0e2-485b-a08e-b63675a9746b@github.com>
 <UQ6gbZhxZ-5W1HkjA_XO2RnuEI1U-scC_iJRPD2Mrb4=.99793b9d-3cd6-4fbe-ad98-f418ccbc6f3a@github.com>
 <B-g8YZqbJMfAFPZvGpllxvOfoohFeI6MzeNdpEhOCvk=.dbdc6f3e-db3f-419b-8dc1-1ecc155b43a8@github.com>
Message-ID: <4juIfgbibTnFJn3B8je1VWCuXCnZVOkzdGLomQk0mrE=.62db438e-f873-49c0-82f5-399017dd5ede@github.com>

On Wed, 10 Mar 2021 04:28:04 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix white space in CDS.java
>
> src/java.base/share/classes/jdk/internal/misc/CDS.java line 256:
> 
>> 254: 
>> 255:             // Do not take parent env which will cause dumping fail.
>> 256:             Process proc = Runtime.getRuntime().exec(cmds.toArray(new String[0]),
> 
> Could you explain why the parent's env variables will cause dumping to fail?

I found jtreg env will be brought in to the children env which is not needed in this case. Add comment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2737

From minqi at openjdk.java.net  Thu Mar 18 03:39:53 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 18 Mar 2021 03:39:53 GMT
Subject: RFR: 8259070: Add jcmd option to dump CDS [v4]
In-Reply-To: <wwBek7Yf05ftyApvSnOfw3CL3Yb8T38kdpCcv0gOXfM=.c19076b2-25ea-48cf-bc8b-4700b5549fc1@github.com>
References: <hwrc1zAz8G180ToL-C3EuUIF-5R17F5Gm1zcPMBpOtE=.e002a377-e0e2-485b-a08e-b63675a9746b@github.com>
 <wwBek7Yf05ftyApvSnOfw3CL3Yb8T38kdpCcv0gOXfM=.c19076b2-25ea-48cf-bc8b-4700b5549fc1@github.com>
Message-ID: <KaiBgheviyRfNEvxa7FKlZMIatuk6wQbdyVnLF9htR0=.2f655021-444f-413c-b144-3e1cbb32e633@github.com>

On Fri, 26 Feb 2021 22:46:07 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Yumin Qi 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 filter more flags to exclude in static dump, add more test cases
>>  - Merge branch 'master' into jdk-8259070
>>  - Fix white space in CDS.java
>>  - Add function CDS.dumpSharedArchive in java to dump shared archive
>>  - 8259070: Add jcmd option to dump CDS
>
> src/hotspot/share/runtime/arguments.cpp line 3525:
> 
>> 3523:       os::free(SharedDynamicArchivePath);
>> 3524:       SharedDynamicArchivePath = nullptr;
>> 3525:     }
> 
> Is this necessary?

When do dynamic dump, we set SharedDynamicArchivePath to the given file name, after that, restore the original value so free the old one to prevent memory leak.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2737

From ysuenaga at openjdk.java.net  Thu Mar 18 05:17:10 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 18 Mar 2021 05:17:10 GMT
Subject: RFR: 8263670: pmap and pstack in jhsdb do not work on debug
 server [v2]
In-Reply-To: <OzFp9WFONUqIUYqdZ78D04bfnhgOSaeB1WqmPtyUdA0=.7dcf74d3-6819-4c9c-b878-a26cfcd0cbc6@github.com>
References: <OzFp9WFONUqIUYqdZ78D04bfnhgOSaeB1WqmPtyUdA0=.7dcf74d3-6819-4c9c-b878-a26cfcd0cbc6@github.com>
Message-ID: <8nzlQFRQWlro_1j_47-7QTdhmFzm3gGIwGTrGWyQqFA=.fe77d8a2-c9c5-4c86-885e-ebb7850a1d00@github.com>

> jhsdb supports pmap (jhsdb jmap) and pstack (jhsdb jstack --mixed), and they work fine if they attach to live process or to coredump, however they do not work on debug server as following:
> 
> $ jhsdb jmap --connect localhost
> Attaching to remote server localhost, please wait...
> Debugger attached successfully.
> Server compiler detected.
> JVM version is 11.0.10+9
> remote configuration is not yet implemented
> 
> pmap and pstack depend on CDebugger in SA, however it would not be set in case of remote debugger client. We can avoid it if we can delegate the process to debug server.

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Update testcases

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3027/files
  - new: https://git.openjdk.java.net/jdk/pull/3027/files/e00d9788..57149ae1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3027&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3027&range=00-01

  Stats: 56 lines in 4 files changed: 16 ins; 33 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3027.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3027/head:pull/3027

PR: https://git.openjdk.java.net/jdk/pull/3027

From ysuenaga at openjdk.java.net  Thu Mar 18 05:17:10 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 18 Mar 2021 05:17:10 GMT
Subject: RFR: 8263670: pmap and pstack in jhsdb do not work on debug server
In-Reply-To: <6ShRMqQdyZulms0svEnGT2TT4an_ulqoVovPABis9fE=.b523a7e7-1bf8-41e9-aca2-af6f1a0aa556@github.com>
References: <OzFp9WFONUqIUYqdZ78D04bfnhgOSaeB1WqmPtyUdA0=.7dcf74d3-6819-4c9c-b878-a26cfcd0cbc6@github.com>
 <mFfeltfVRsGye7-4X9XJ1czWg022dMyk9mm38R-852U=.653f92cb-e119-49c8-84d0-6c273ef8077b@github.com>
 <q_jnJYTkJ2QYQh5K1AWHbw5Kt3cHt7__F77ru2lQKII=.732206cc-0825-4c0a-b315-f05237dffa57@github.com>
 <6ShRMqQdyZulms0svEnGT2TT4an_ulqoVovPABis9fE=.b523a7e7-1bf8-41e9-aca2-af6f1a0aa556@github.com>
Message-ID: <ey9xknBtIDT8iN9zp8CyAYzkkeir-vPUUzGVGZpKZpY=.754a0671-1493-46fd-b51f-8056476ecaf1@github.com>

On Wed, 17 Mar 2021 04:55:27 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>>> If I understand correctly, this is very different than the way we normally implement remote debugging support. Normally pages are read in from the remote VM process and into the local SA client, where it can then implement SA support in much the same way as it normally does. For PStack and PMap, you've chosen to instead just execute the commands in the remote debugd server, and return the (text) result to the client.
>> 
>> Yes.
>> 
>>> It's not clear to me why the normal model (of reading in the remote pages and leveraging existing PStack and PMAp supprt) can't instead be used so we can keep the remote debugging support consistent. How are PStack and PMap different from other SA support that does not require remote execution of commands.
>> 
>> SA would set various information when it attaches to debuggee, so it is difficult to catch up them when remote debugger attached because only debugd can attach to debuggee directly.
>> As I said in the description of this PR, both PMap and PStack depend on CDebugger. CDebugger holds low-level information such as library list and native thread list. They would be initialized when it attached - it is startup of debugd, and we cannot get them when we connect to debugd.
>> 
>> I thought to export CDebugger as RMI object, but it seems to complex. So I decided to run both pmap and pstack on debugd.
>
> Do we have any issues with any other clhsdb commands that rely CDebugger. I haven't looked into the implementation, but I'm suspicious of `thread`, `threads`, `findpc` of an address in the executable, and `findsym`.
> 
> And speaking of CDebugger, the SA "debugger" hierarchy is too heavily abstracted. I counted about 18 classes and interfaces that have "Debugger" in their name, and some of the interfaces get inherited more than once. I really wonder if it has to be that complex. My first adventure into this mess was for [JDK-8239062](https://bugs.openjdk.java.net/browse/JDK-8239062), a time when I knew close to nothing about SA. Was not fun and I eventually gave up. You might want to have a look at the CR, if not just to add some comments and maybe enlighten me on some things.

Thanks @plummercj for the comment! I updated testcases.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3027

From lzang at openjdk.java.net  Thu Mar 18 10:48:56 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 18 Mar 2021 10:48:56 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v7]
In-Reply-To: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
Message-ID: <ej0YPaHFmn1obK9e69RzT37pT7AIf3bpIIJANEI9vg8=.999f1fc1-c0fd-4519-aa1a-a632d139611b@github.com>

> 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out

Lin Zang 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 eight additional commits since the last revision:

 - Merge branch 'master' into sf
 - rename writeThrough to unbufferedMode and code refine
 - fix typo in comments
 - Merge branch 'master' into sf
 - Revert "reduce memory consumption"
   
   This reverts commit 70e43ddd453724ce36bf729fa6489c0027957b8e.
 - reduce memory consumption
 - code refine
 - 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2803/files
  - new: https://git.openjdk.java.net/jdk/pull/2803/files/bb5827da..a1732514

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2803&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2803&range=05-06

  Stats: 4276 lines in 295 files changed: 2033 ins; 1240 del; 1003 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2803.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2803/head:pull/2803

PR: https://git.openjdk.java.net/jdk/pull/2803

From lzang at openjdk.java.net  Thu Mar 18 11:09:41 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 18 Mar 2021 11:09:41 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v10]
In-Reply-To: <yQM1ngC5wGvP2xr5TvcbZo4JtlF6QttL9owYSUQHEy4=.e14e3464-fa3e-4448-978c-721cf85875d3@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <6l7TqqEmupdBa2J8b_NlWif5oVY2SGpu7iKeJMM97ic=.bf63c6e2-878d-4c2a-9a1e-336419c88b58@github.com>
 <CvuSjdeAKN93mwFqzHEya8ho-ONmC_TYAokqDeat3RQ=.ab576df3-1635-45d6-a72f-7aac0a55c34e@github.com>
 <ebrfA2bFIIPhcpZkO75uUvbJ3aMJFoHq_JR46AAEdfQ=.e3dee042-dff0-4b80-8cb0-5c9dae722be7@github.com>
 <HrPwAUu3BrXj3C5fPIjZD3xEO0n2fKoQywKfOiebc7o=.193f9f06-0025-4251-baef-4288aea793b1@github.com>
 <89stqatP7KevfaFqJiTJyoi1q9PdIjR9VpYrK4KzVLE=.120ae881-06b8-4f75-9d51-ff8ea05cac63@github.com>
 <W2I3fgh9yhgn7dm7PM491TkzQ-wbhe_hvqNdZqfW8wU=.7e2e1b13-9138-4c00-94e7-f500e9432c33@github.com>
 <MExJEiIs3e_zBbegggS5C4LSZBcPwDplOchJaztsWeg=.60fc0ca0-3958-4a89-af53-65c896b0c573@github.com>
 <yQM1ngC5wGvP2xr5TvcbZo4JtlF6QttL9owYSUQHEy4=.e14e3464-fa3e-4448-978c-721cf85875d3@github.com>
Message-ID: <_FI8c6_e9Bn7iQFGK7CZwP9bHQCv--D08Hm6xqjj1zI=.31734f4e-5824-475f-a46c-6630433aa62f@github.com>

On Wed, 10 Mar 2021 11:33:00 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> Hi @linzang
>> 
>> 
>>> This data are really interest to me, it seems using gzipped dump is faster than unzipped dump, is the because of disk writing or something else? I would investigate more about it~
>> 
>> I would guess that is the case. In the compressed case we write about 800 MB per second, that is as fast as my SSD goes.
>> 
>> Here are some actual results I've gotten (uncompressed):
>> 
>>     jmap.exe -dump:file=ser.hprof,all 30600 
>>     Dumping heap to ser.hprof ...
>>     Heap dump file created [32009882362 bytes in 59.303 secs]
>> 
>>     jmap.exe -dump:file=par1.hprof,parallel=1,all 30600
>>     Dumping heap to par1.hprof ...
>>     Heap dump file created [32009885809 bytes in 72.719 secs]
>> 
>>     jmap.exe -dump:file=par2.hprof,parallel=2,all 30600
>>     Dumping heap to par2.hprof ...
>>     Heap dump file created [32009881876 bytes in 57.546 secs]
>> 
>>     jmap.exe -dump:file=par4.hprof,parallel=4,all 30600
>>     Dumping heap to par4.hprof ...
>>     Heap dump file created [32009882956 bytes in 44.301 secs]
>> 
>>     jmap.exe -dump:file=par5.hprof,parallel=5,all 30600
>>     Dumping heap to par5.hprof ...
>>     Heap dump file created [32009882164 bytes in 40.282 secs]
>> 
>>     jmap.exe -dump:file=par6.hprof,parallel=6,all 30600
>>     Dumping heap to par6.hprof ...
>>     Heap dump file created [32009881156 bytes in 45.988 secs]
>> 
>> And here for the compressed case:
>> 
>>     jmap.exe -dump:file=par1.hprof.gz,parallel=1,all,gz=1 52372
>>     Dumping heap to par1.hprof.gz ...
>>     Heap dump file created [8076994216 bytes in 54.057 secs]
>> 
>>     jmap.exe -dump:file=par2.hprof.gz,parallel=2,all,gz=1 52372
>>     Dumping heap to par2.hprof.gz ...
>>     Heap dump file created [8075859421 bytes in 43.442 secs]
>> 
>>     jmap.exe -dump:file=par4.hprof.gz,parallel=4,all,gz=1 52372
>>     Dumping heap to par4.hprof.gz ...
>>     Heap dump file created [8075886152 bytes in 28.710 secs]
>> 
>>     jmap.exe -dump:file=par6.hprof.gz,parallel=6,all,gz=1 52372
>>     Dumping heap to par6.hprof.gz ...
>>     Heap dump file created [8075758374 bytes in 25.730 secs]
>> 
>>     jmap.exe -dump:file=par8.hprof.gz,parallel=8,all,gz=1 52372
>>     Dumping heap to par8.hprof.gz ...
>>     Heap dump file created [8075652558 bytes in 26.039 secs]
>> 
>>     jmap.exe -dump:file=par16.hprof.gz,parallel=16,all,gz=1 52372
>>     Dumping heap to par16.hprof.gz ...
>>     Heap dump file created [8075644423 bytes in 31.977 secs]
>> 
>>     jmap.exe -dump:file=par24.hprof.gz,parallel=24,all,gz=1 52372
>>     Dumping heap to par24.hprof.gz ...
>>     Heap dump file created [8075579546 bytes in 41.094 secs]
>> 
>> Best regards,
>> Ralf
>
> Dear Ralf @schmelter-sap, 
> Sorry for late response, I got stuck in other work recently.
> I have uploaded a new update that could help reduce memory consumption and also fix the assertion issue. 
> I have verified it on my machine, May I ask your help to double check it on your side? 
> Thanks!
> Lin

Dear Chris and Ralf,
May I ask your help to review the related CSR first? both JDK-8260424  and JDK-8261943? 
https://bugs.openjdk.java.net/browse/JDK-8260424 is for adding `parallel=<N>` option, which IMO also block the merge of #2379. 
https://bugs.openjdk.java.net/browse/JDK-8261943 is for adding new attach api comment `dumpheapext`

Thanks
Lin

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From rschmelter at openjdk.java.net  Thu Mar 18 12:12:41 2021
From: rschmelter at openjdk.java.net (Ralf Schmelter)
Date: Thu, 18 Mar 2021 12:12:41 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v13]
In-Reply-To: <5P7_HEiPQT5u9elB2S-xWzsFn-InsPPAWsb2-re38jg=.c725a88c-b4c6-4802-b9a6-65bdf62791ca@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <5P7_HEiPQT5u9elB2S-xWzsFn-InsPPAWsb2-re38jg=.c725a88c-b4c6-4802-b9a6-65bdf62791ca@github.com>
Message-ID: <gzkSdt4Adb-sGHNRPM5rbVTXLqMOxVyTaiCVXuGaKGA=.5f63769f-9084-4091-be6d-8880f6e57bbc@github.com>

On Wed, 10 Mar 2021 09:41:21 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8252842: Extend jmap to support parallel heap dump
>
> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reduce memory consumption and fix memory leak issue

src/hotspot/share/services/heapDumper.cpp line 1741:

> 1739:   uint length() { return _length; }
> 1740: 
> 1741:   static const size_t LargeObjectSizeThreshold = 128 * (1 << 20); // 128 MB

I think this threshold is much too large. I've instrumented the code to track the maximum memory use of the buffers and tested the max memory use and the performance for 2, 4 and 8 parallel iteration threads and for a threshold of 128 MB and 1 MB (using my scenario with a 32 GB heap):

128 MB threshold:
2 threads -> 57 MB max memory, 64.6 seconds duration
4 threads -> 88 MB max memory, 40.5 seconds duration
8 threads -> 170 MB max memory, 29.6 seconds duration

1MB threshold:
2 threads -> 8 MB max memory, 64.6 seconds duration
4 threads -> 15 MB max memory, 39.5 seconds duration
8 threads -> 32 MB max memory, 28.9 seconds duration

As you can see, using a much lower threshold has no discernable performance impact, but uses a lot less memory. Also note that the memory consumption can be much higher in the worst case scenario.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From rschmelter at openjdk.java.net  Thu Mar 18 12:23:41 2021
From: rschmelter at openjdk.java.net (Ralf Schmelter)
Date: Thu, 18 Mar 2021 12:23:41 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v10]
In-Reply-To: <_FI8c6_e9Bn7iQFGK7CZwP9bHQCv--D08Hm6xqjj1zI=.31734f4e-5824-475f-a46c-6630433aa62f@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <6l7TqqEmupdBa2J8b_NlWif5oVY2SGpu7iKeJMM97ic=.bf63c6e2-878d-4c2a-9a1e-336419c88b58@github.com>
 <CvuSjdeAKN93mwFqzHEya8ho-ONmC_TYAokqDeat3RQ=.ab576df3-1635-45d6-a72f-7aac0a55c34e@github.com>
 <ebrfA2bFIIPhcpZkO75uUvbJ3aMJFoHq_JR46AAEdfQ=.e3dee042-dff0-4b80-8cb0-5c9dae722be7@github.com>
 <HrPwAUu3BrXj3C5fPIjZD3xEO0n2fKoQywKfOiebc7o=.193f9f06-0025-4251-baef-4288aea793b1@github.com>
 <89stqatP7KevfaFqJiTJyoi1q9PdIjR9VpYrK4KzVLE=.120ae881-06b8-4f75-9d51-ff8ea05cac63@github.com>
 <W2I3fgh9yhgn7dm7PM491TkzQ-wbhe_hvqNdZqfW8wU=.7e2e1b13-9138-4c00-94e7-f500e9432c33@github.com>
 <MExJEiIs3e_zBbegggS5C4LSZBcPwDplOchJaztsWeg=.60fc0ca0-3958-4a89-af53-65c896b0c573@github.com>
 <yQM1ngC5wGvP2xr5TvcbZo4JtlF6QttL9owYSUQHEy4=.e14e3464-fa3e-4448-978c-721cf85875d3@github.com>
 <_FI8c6_e9Bn7iQFGK7CZwP9bHQCv--D08Hm6xqjj1zI=.31734f4e-5824-475f-a46c-6630433aa62f@github.com>
Message-ID: <TVIEliaruP7Sv4OIdxiUrpkAlQOKavCJwmCpKxPAqdY=.b2963edb-6b41-4c7d-8e35-22019326c586@github.com>

On Thu, 18 Mar 2021 11:07:16 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> Dear Ralf @schmelter-sap, 
>> Sorry for late response, I got stuck in other work recently.
>> I have uploaded a new update that could help reduce memory consumption and also fix the assertion issue. 
>> I have verified it on my machine, May I ask your help to double check it on your side? 
>> Thanks!
>> Lin
>
> Dear Chris and Ralf,
> May I ask your help to review the related CSR first? both JDK-8260424  and JDK-8261943? 
> https://bugs.openjdk.java.net/browse/JDK-8260424 is for adding `parallel=<N>` option, which IMO also block the merge of #2379. 
> https://bugs.openjdk.java.net/browse/JDK-8261943 is for adding new attach api comment `dumpheapext`
> 
> Thanks
> Lin

Hi Lin,

to be honest I would prefer if we would not add the parallel option but instead do it automatically depending on the number of GC threads available. I doubt that the user has a good idea about number of threads to use, so I think it is better to just use a sensible default derived from the number of threads available and if compression is enabled or not.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From lzang at openjdk.java.net  Thu Mar 18 13:20:42 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 18 Mar 2021 13:20:42 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v13]
In-Reply-To: <gzkSdt4Adb-sGHNRPM5rbVTXLqMOxVyTaiCVXuGaKGA=.5f63769f-9084-4091-be6d-8880f6e57bbc@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <5P7_HEiPQT5u9elB2S-xWzsFn-InsPPAWsb2-re38jg=.c725a88c-b4c6-4802-b9a6-65bdf62791ca@github.com>
 <gzkSdt4Adb-sGHNRPM5rbVTXLqMOxVyTaiCVXuGaKGA=.5f63769f-9084-4091-be6d-8880f6e57bbc@github.com>
Message-ID: <MWRG_IZylxPQ3XdKeOrh98kyOFzHnqMBhWrIEbhni4k=.e9198253-5abd-4399-ac71-71ac7e8e35a8@github.com>

On Thu, 18 Mar 2021 12:09:25 GMT, Ralf Schmelter <rschmelter at openjdk.org> wrote:

>> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reduce memory consumption and fix memory leak issue
>
> src/hotspot/share/services/heapDumper.cpp line 1741:
> 
>> 1739:   uint length() { return _length; }
>> 1740: 
>> 1741:   static const size_t LargeObjectSizeThreshold = 128 * (1 << 20); // 128 MB
> 
> I think this threshold is much too large. I've instrumented the code to track the maximum memory use of the buffers and tested the max memory use and the performance for 2, 4 and 8 parallel iteration threads and for a threshold of 128 MB and 1 MB (using my scenario with a 32 GB heap):
> 
> 128 MB threshold:
> 2 threads -> 57 MB max memory, 64.6 seconds duration
> 4 threads -> 88 MB max memory, 40.5 seconds duration
> 8 threads -> 170 MB max memory, 29.6 seconds duration
> 
> 1MB threshold:
> 2 threads -> 8 MB max memory, 64.6 seconds duration
> 4 threads -> 15 MB max memory, 39.5 seconds duration
> 8 threads -> 32 MB max memory, 28.9 seconds duration
> 
> As you can see, using a much lower threshold has no discernable performance impact, but uses a lot less memory. Also note that the memory consumption can be much higher in the worst case scenario.

I agree? Thanks for the evaluation!  I think 1MB is reasonable. Will made the change in next update.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From lzang at openjdk.java.net  Thu Mar 18 14:43:45 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 18 Mar 2021 14:43:45 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v10]
In-Reply-To: <TVIEliaruP7Sv4OIdxiUrpkAlQOKavCJwmCpKxPAqdY=.b2963edb-6b41-4c7d-8e35-22019326c586@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <6l7TqqEmupdBa2J8b_NlWif5oVY2SGpu7iKeJMM97ic=.bf63c6e2-878d-4c2a-9a1e-336419c88b58@github.com>
 <CvuSjdeAKN93mwFqzHEya8ho-ONmC_TYAokqDeat3RQ=.ab576df3-1635-45d6-a72f-7aac0a55c34e@github.com>
 <ebrfA2bFIIPhcpZkO75uUvbJ3aMJFoHq_JR46AAEdfQ=.e3dee042-dff0-4b80-8cb0-5c9dae722be7@github.com>
 <HrPwAUu3BrXj3C5fPIjZD3xEO0n2fKoQywKfOiebc7o=.193f9f06-0025-4251-baef-4288aea793b1@github.com>
 <89stqatP7KevfaFqJiTJyoi1q9PdIjR9VpYrK4KzVLE=.120ae881-06b8-4f75-9d51-ff8ea05cac63@github.com>
 <W2I3fgh9yhgn7dm7PM491TkzQ-wbhe_hvqNdZqfW8wU=.7e2e1b13-9138-4c00-94e7-f500e9432c33@github.com>
 <MExJEiIs3e_zBbegggS5C4LSZBcPwDplOchJaztsWeg=.60fc0ca0-3958-4a89-af53-65c896b0c573@github.com>
 <yQM1ngC5wGvP2xr5TvcbZo4JtlF6QttL9owYSUQHEy4=.e14e3464-fa3e-4448-978c-721cf85875d3@github.com>
 <_FI8c6_e9Bn7iQFGK7CZwP9bHQCv--D08Hm6xqjj1zI=.31734f4e-5824-475f-a46c-6630433aa62f@github.com>
 <TVIEliaruP7Sv4OIdxiUrpkAlQOKavCJwmC
 pKxPAqdY=.b2963edb-6b41-4c7d-8e35-22019326c586@github.com>
Message-ID: <QreuPRxLFccE_PiVXh7gZp1lPJGK_tjv5k7RsYgGdA0=.35676d23-d59a-40ff-a3dc-eec2caf7ed01@github.com>

On Thu, 18 Mar 2021 12:20:25 GMT, Ralf Schmelter <rschmelter at openjdk.org> wrote:

>> Dear Chris and Ralf,
>> May I ask your help to review the related CSR first? both JDK-8260424  and JDK-8261943? 
>> https://bugs.openjdk.java.net/browse/JDK-8260424 is for adding `parallel=<N>` option, which IMO also block the merge of #2379. 
>> https://bugs.openjdk.java.net/browse/JDK-8261943 is for adding new attach api comment `dumpheapext`
>> 
>> Thanks
>> Lin
>
> Hi Lin,
> 
> to be honest I would prefer if we would not add the parallel option but instead do it automatically depending on the number of GC threads available. I doubt that the user has a good idea about number of threads to use, so I think it is better to just use a sensible default derived from the number of threads available and if compression is enabled or not.

Dear Ralf and Chris,

> to be honest I would prefer if we would not add the parallel option but instead do it automatically depending on the number of GC threads available. I doubt that the user has a good idea about number of threads to use, so I think it is better to just use a sensible default derived from the number of threads available and if compression is enabled or not.

Thanks Ralf for your comments!

@plummercj and I have discussed the `parallel=` option several rounds, also together with Serguei @sspitsyn  and Ham-Lin @Hamlin-Li . And I recently also re-considered this option for dumping. here I list my opinion and hope we could made the final decision this time :-)

- The `parallel=<N>` option for `jmap -histo` has been discussed and finalized, I think we could leave it as it is. Because user may get general info about their system, such as core number and multi-process workload, these could help them tuning.  And also because the `parallel=<N>` option only affects how many threads would be used for object iteration (this is different with `jmap -dump`, I will explain in following comments), it is easy to observe the output or time and then adjust the number.

- The `parallel=<N>` option for `jmap -dump` is complicated, it has to consider the file writer threads and the disk writing speed. let me try to explain the implementation briefly:

In current implementation, the heap dump actaully has two kind of worker threads - dumper and writter. The dumper iterates over the heap and send data to the writer; the writer does compression if required and writes data to the file. There is buffer queue between dumper and writer: dumper grab empty buffer and fill data into the queue , and the writer threads grab the filled buffer from the queue, write data to file and then return empty buffer for futurn use. 
In summary it looks like following graph:

` Dumper  --> BufferQueue (size == #writers) --> writer(multiple) ==> disk(file)`

Before this patch, there is only one dumper (the VMThread) and all other worker threads are writer, that is, all GC threads work as writer. The only dumper iterate heap and the multiple writers write data to file. So the bottomneck is more likely to be heap iteration (dumper side).

With this patch,  there are multiple dumpers and multiple writers,  they all divided the gc thread number (plus 1 vmthread). And since there are multiple dumpers, the buffer queue is more likely to be filled.  So the bottomneck move from heap iteration to two aspect (writer side):
- drain of buffer queue 
- speed of disk writing

Since the buffer queue size is determined by number of writers, and the disk writing speed determines how fast the buffer can be empty again, it is important to keep the writer number as much as it can be to satisfy the dumper's requirement.

The `parallel=<N>` option only control the dumper thread number, and it indirectly affects the writer's thread number (as they all divide the total thread number). it is really hard for user to understand these internal mechanism and do tuning.  

And by default, the number of dumpers and writers are half : half of GC threads +1(vmThread), my testing shown this configuration is likly to be optimal. ( But maybe more evalution is required to confirm)

In summary, I think it is very hard for user to tune the parallel thread number for heap dump. So I suggest to remove it for dump and enable the parallel by default. 

Again, For `jmap -histo`, I suggest to keep this since it is more easy to be understood.

IMO, to make final decision, we need to consider following:
- Is it acceptable that `jmap -dump` and `jmap -histo` have different behavior about the option of `parallel`, that is, `heapdump` does not use it and `heaphisto` does.
- If we decide to not introduce the `parallel` option, we don't need to introduce the `heapdumpext` attach api command, so the 2 CSRs related to this PR could be closed. But this may leave the argument count problem to future, when more argumebts is introduced, is this acceptable? 
- if we decide to introduce `parallel=<N>` option, do we need to add explaination in the document? or docs like tuning guide? 

Welcome for any of your comments!

BRs,
Lin

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From iignatyev at openjdk.java.net  Thu Mar 18 15:37:39 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 18 Mar 2021 15:37:39 GMT
Subject: RFR: 8246494: introduce vm.flagless at-requires property
In-Reply-To: <bBNRweeD_iKNaM75dvHdISVn8dKjGKEkbRagvhxAi_s=.410d0148-9b43-4b84-990a-bbe2455adff3@github.com>
References: <fC51vNiDPG7UUjFvMEJnbbKV0ejluFe023gEgyFq1eI=.f55fd064-9aba-4f05-a3ea-ad6959e1c9bc@github.com>
 <bBNRweeD_iKNaM75dvHdISVn8dKjGKEkbRagvhxAi_s=.410d0148-9b43-4b84-990a-bbe2455adff3@github.com>
Message-ID: <SJT76F2VfWBlDrfKmtdTEpphj458idmjLdfm2pX2VRA=.c8be6456-509b-4713-930e-5fa6ac977d6d@github.com>

On Wed, 17 Mar 2021 07:02:59 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> resurrecting old [RFR](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-June/041981.html):
>> 
>>> Hi all,
>>> 
>>> could you please review the patch which introduces a new @requires property to filter out the tests which ignore externally provided JVM flags?
>>> 
>>> the idea behind this patch is to have a way to clearly mark tests which ignore flags, so 
>>> a) it's obvious that they don't execute a flag-guarded code/feature, and extra care should be taken to use them to verify any flag-guarded changed;
>>> b) they can be easily excluded from runs w/ flags.
>>> 
>>> @requires and VMProps allows us to achieve both, so it's been decided to add a new property `vm.flagless`. `vm.flagless` is set to false if there are any XX flags other than `-XX:MaxRAMPercentage` and `-XX:CreateCoredumpOnCrash` (which are known to be set almost always) or any X flags other `-Xmixed`; in other words any tests w/ `@requires vm.flagless` will be excluded from runs w/ any other X / XX flags passed via `-vmoption` / `-javaoption`. in rare cases, when one still wants to run the tests marked by `vm.flagless`  w/ external flags, `vm.flagless` can be forcefully set to true by setting any value to `TEST_VM_FLAGLESS` env. variable.
>>> 
>>> this patch adds necessary common changes and marks common tests, namely Scimark, GTestWrapper and TestNativeProcessBuilder. Component-specific tests will be marked separately by the corresponding subtasks of 8151707[1].
>>> 
>>> please note, the patch depends on CODETOOLS-7902336[2], which will be included in the next jtreg version, so this patch is to be integrated only after jtreg5.1 is promoted and we switch to use it by 8246387[3].
>>> 
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8246494
>>> webrev: http://cr.openjdk.java.net/~iignatyev//8246494/webrev.00
>>> testing: marked tests w/ different XX and X flags w/ and w/o TEST_VM_FLAGLESS env. var, and w/o any flags
>>> 
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8151707
>>> [2] https://bugs.openjdk.java.net/browse/CODETOOLS-7902336
>>> [3] https://bugs.openjdk.java.net/browse/JDK-8246387
>>> 
>> 
>> after offline discussion with @pliden, it has been decided to reduce the scope of [8246499](https://bugs.openjdk.java.net/browse/JDK-8246499) and not mark the tests that use `UseXGC` flags for selection, e.g. `test/hotspot/jtreg/gc/z/TestSmallHeap.java`.
>> 
>> Thanks,
>> -- Igor
>
> Igor,
> The fix looks good to me.
> Thanks,
> Serguei

Thanks, Serguei!

-------------

PR: https://git.openjdk.java.net/jdk/pull/2800

From iignatyev at openjdk.java.net  Thu Mar 18 15:37:40 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 18 Mar 2021 15:37:40 GMT
Subject: Integrated: 8246494: introduce vm.flagless at-requires property
In-Reply-To: <fC51vNiDPG7UUjFvMEJnbbKV0ejluFe023gEgyFq1eI=.f55fd064-9aba-4f05-a3ea-ad6959e1c9bc@github.com>
References: <fC51vNiDPG7UUjFvMEJnbbKV0ejluFe023gEgyFq1eI=.f55fd064-9aba-4f05-a3ea-ad6959e1c9bc@github.com>
Message-ID: <vf6fXoBgysQtL4BY4UdoytHNuzW-sfvVvIiwy7CkCXA=.e82a1345-f27b-4978-982a-d3a071211a7c@github.com>

On Tue, 2 Mar 2021 23:27:21 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> resurrecting old [RFR](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-June/041981.html):
> 
>> Hi all,
>> 
>> could you please review the patch which introduces a new @requires property to filter out the tests which ignore externally provided JVM flags?
>> 
>> the idea behind this patch is to have a way to clearly mark tests which ignore flags, so 
>> a) it's obvious that they don't execute a flag-guarded code/feature, and extra care should be taken to use them to verify any flag-guarded changed;
>> b) they can be easily excluded from runs w/ flags.
>> 
>> @requires and VMProps allows us to achieve both, so it's been decided to add a new property `vm.flagless`. `vm.flagless` is set to false if there are any XX flags other than `-XX:MaxRAMPercentage` and `-XX:CreateCoredumpOnCrash` (which are known to be set almost always) or any X flags other `-Xmixed`; in other words any tests w/ `@requires vm.flagless` will be excluded from runs w/ any other X / XX flags passed via `-vmoption` / `-javaoption`. in rare cases, when one still wants to run the tests marked by `vm.flagless`  w/ external flags, `vm.flagless` can be forcefully set to true by setting any value to `TEST_VM_FLAGLESS` env. variable.
>> 
>> this patch adds necessary common changes and marks common tests, namely Scimark, GTestWrapper and TestNativeProcessBuilder. Component-specific tests will be marked separately by the corresponding subtasks of 8151707[1].
>> 
>> please note, the patch depends on CODETOOLS-7902336[2], which will be included in the next jtreg version, so this patch is to be integrated only after jtreg5.1 is promoted and we switch to use it by 8246387[3].
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8246494
>> webrev: http://cr.openjdk.java.net/~iignatyev//8246494/webrev.00
>> testing: marked tests w/ different XX and X flags w/ and w/o TEST_VM_FLAGLESS env. var, and w/o any flags
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8151707
>> [2] https://bugs.openjdk.java.net/browse/CODETOOLS-7902336
>> [3] https://bugs.openjdk.java.net/browse/JDK-8246387
>> 
> 
> after offline discussion with @pliden, it has been decided to reduce the scope of [8246499](https://bugs.openjdk.java.net/browse/JDK-8246499) and not mark the tests that use `UseXGC` flags for selection, e.g. `test/hotspot/jtreg/gc/z/TestSmallHeap.java`.
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: e333b6e1
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e333b6e1
Stats:     81 lines in 6 files changed: 75 ins; 0 del; 6 mod

8246494: introduce vm.flagless at-requires property

Reviewed-by: mseledtsov, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/2800

From amenkov at openjdk.java.net  Thu Mar 18 20:05:39 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 18 Mar 2021 20:05:39 GMT
Subject: RFR: 8262083:
 vmTestbase/nsk/jvmti/SetEventNotificationMode/setnotif001/TestDescription.java
 failed with "No notification: event JVMTI_EVENT_FRAME_POP (61)"
In-Reply-To: <toh4GSy4A10NzfTrmQR1xZ5sSKJpVKPHZEVDghDwyFI=.6504b2ca-57f2-4750-ad65-6c0a0ddc33e5@github.com>
References: <qaKtyTEgt_5tOUH_SP_x4sRVTuS8XBW95kSzty7TsAY=.85d10651-f3a1-477d-9e00-2a3a82d171dd@github.com>
 <toh4GSy4A10NzfTrmQR1xZ5sSKJpVKPHZEVDghDwyFI=.6504b2ca-57f2-4750-ad65-6c0a0ddc33e5@github.com>
Message-ID: <eHWV-pPX2_wUmN53IA_jAYvuTiodtt1AHYjZohCgRbc=.4d9cab2f-af1a-4dc9-a1f9-34d5b958cede@github.com>

On Thu, 18 Mar 2021 01:43:04 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Might be it is needed to comment why the SetEventNotification on a single thread is not used.

I think this is what the test about. Description says:
Profiling agent setnotif001.c enables globally events
...
and checks if all they are sent after been enabled and are not
sent before that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3060

From amenkov at openjdk.java.net  Thu Mar 18 20:14:39 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 18 Mar 2021 20:14:39 GMT
Subject: Integrated: 8262001:
 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java failed with
 "RuntimeException: Current Peak = 14 Expected to be == previous peak = 7 + 8"
In-Reply-To: <TZBFsiqKOxxbp-tN07-glyx947_eN6jTUEJlFWZcpik=.043c257d-d7ec-4df2-8504-1914e55e3975@github.com>
References: <TZBFsiqKOxxbp-tN07-glyx947_eN6jTUEJlFWZcpik=.043c257d-d7ec-4df2-8504-1914e55e3975@github.com>
Message-ID: <-zHu5oFZnT_z4wv_637ya2SYe2ZDkLz0s9o8mWVAE9w=.1d9b0b4c-4ace-404b-89cc-5981544201d8@github.com>

On Tue, 9 Mar 2021 01:31:33 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates ResetPeakThreadCount.java test - increases number of threads, but relaxes conditions so start/termination of system threads don't cause failures.
> Additional changes:
> - store threads in a list instead of array (we need only to start/terminate some number of threads, so linked list works better);
> - flags for thread termination are moved to thread class;
> - store values from ThreadMXBean.getPeakThreadCount() and getThreadCount() in int instead of long (the methods return int values)

This pull request has now been integrated.

Changeset: c82a673c
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c82a673c
Stats:     139 lines in 1 file changed: 20 ins; 61 del; 58 mod

8262001: java/lang/management/ThreadMXBean/ResetPeakThreadCount.java failed with "RuntimeException: Current Peak = 14 Expected to be == previous peak = 7 + 8"

Reviewed-by: dfuchs, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/2885

From cjplummer at openjdk.java.net  Thu Mar 18 21:13:41 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 18 Mar 2021 21:13:41 GMT
Subject: RFR: 8262083:
 vmTestbase/nsk/jvmti/SetEventNotificationMode/setnotif001/TestDescription.java
 failed with "No notification: event JVMTI_EVENT_FRAME_POP (61)"
In-Reply-To: <qaKtyTEgt_5tOUH_SP_x4sRVTuS8XBW95kSzty7TsAY=.85d10651-f3a1-477d-9e00-2a3a82d171dd@github.com>
References: <qaKtyTEgt_5tOUH_SP_x4sRVTuS8XBW95kSzty7TsAY=.85d10651-f3a1-477d-9e00-2a3a82d171dd@github.com>
Message-ID: <qBbpLKMYU2ay5bohH-rTJBA2fBM3e7es3iWOINsoHio=.5d8847db-9a36-45fd-b6a5-41d14f6bbe9d@github.com>

On Wed, 17 Mar 2021 23:42:46 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The test requests NotifyFrame event from MethodEntry handler expecting that 1st MethodEntry event is generated for main thread.
> The fix adds a check that the thread is correct and skips event from other threads

Changes look good. Don't know why git.diff butchered what should have been a very simple to read diff so much.

-------------

Marked as reviewed by cjplummer (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3060

From cjplummer at openjdk.java.net  Fri Mar 19 02:02:38 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 19 Mar 2021 02:02:38 GMT
Subject: RFR: 8263546: Add "findsym" command to clhsdb.html help file
In-Reply-To: <6_R3cNYIG76RA_72ejNGVNnQ738vRLu9ApewQtVXv6M=.50799689-5eb8-4dc3-aa0b-5a99c3ab44b3@github.com>
References: <-u_1bRA3RlHlR4Dh9NkqqlUG3ax86emRoKs5UeGvJXs=.066f58c0-40f7-46d4-bc1b-00f01d2c825e@github.com>
 <6_R3cNYIG76RA_72ejNGVNnQ738vRLu9ApewQtVXv6M=.50799689-5eb8-4dc3-aa0b-5a99c3ab44b3@github.com>
Message-ID: <1eOBghYzIqQ7pPEb_nQFxycsgSHWR5NFdAxhnjGs0p4=.cb77c169-0ed6-4af6-b5c7-b3e51a216988@github.com>

On Sat, 13 Mar 2021 01:17:25 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Added clhsdb help for findsym, which was missed when the findsym command was recently added. Also fixed a very minor typo in the findpc help.
>
> Marked as reviewed by ysuenaga (Reviewer).

Ping! Need one more reviewer. This is a pretty trivial doc change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2983

From lmesnik at openjdk.java.net  Fri Mar 19 04:52:37 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Fri, 19 Mar 2021 04:52:37 GMT
Subject: RFR: 8263546: Add "findsym" command to clhsdb.html help file
In-Reply-To: <-u_1bRA3RlHlR4Dh9NkqqlUG3ax86emRoKs5UeGvJXs=.066f58c0-40f7-46d4-bc1b-00f01d2c825e@github.com>
References: <-u_1bRA3RlHlR4Dh9NkqqlUG3ax86emRoKs5UeGvJXs=.066f58c0-40f7-46d4-bc1b-00f01d2c825e@github.com>
Message-ID: <Vfe4uC7vSsCh58yQGx-H0TypRXHSlKKiRU_rmTCQdNs=.b27be956-7bc7-4daa-9770-22a9e337ade7@github.com>

On Sat, 13 Mar 2021 00:28:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Added clhsdb help for findsym, which was missed when the findsym command was recently added. Also fixed a very minor typo in the findpc help.

Marked as reviewed by lmesnik (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2983

From iklam at openjdk.java.net  Fri Mar 19 05:42:42 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 19 Mar 2021 05:42:42 GMT
Subject: RFR: 8259070: Add jcmd option to dump CDS [v4]
In-Reply-To: <9EU_DwWh3XcyBxJkxgPH1qzvbaa2hvWQYuccdRXWKj0=.c6816df0-6e73-45bc-9e52-caa70b0611fd@github.com>
References: <hwrc1zAz8G180ToL-C3EuUIF-5R17F5Gm1zcPMBpOtE=.e002a377-e0e2-485b-a08e-b63675a9746b@github.com>
 <9EU_DwWh3XcyBxJkxgPH1qzvbaa2hvWQYuccdRXWKj0=.c6816df0-6e73-45bc-9e52-caa70b0611fd@github.com>
Message-ID: <x6lHyc-dfQ7nvJWtJQG0hUWTbGe8NlfZmzDkEBNGcjk=.dba20bd5-693b-4bc2-957c-781dcf4e5bc2@github.com>

On Thu, 11 Mar 2021 04:03:29 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Hi, Please review
>> 
>>   Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with
>>   `java -XX:DumpLoadedClassList=<classlist> .... `  
>>  to collect shareable class names and saved in file `<classlist>` , then 
>>   `java -Xshare:dump -XX:SharedClassListFile=<classlist> -XX:SharedArchiveFile=<archivefile> ...`
>>   With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime  to dump an archive.
>>    The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved.
>>    New added jcmd option:
>>    `jcmd <pid or AppName> VM.cds static_dump <filename>`
>>    or
>>     `jcmd <pid or AppName> VM.cds dynamic_dump <filename>`
>>   To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. 
>>    The file name is optional, if the file name is not supplied, the file name will take format of `java_pid<number>_static.jsa` or `java_pid<number>_dynamic.jsa` for static and dynamic respectively. The `<number>` is the application process ID.
>> 
>>   Tests: tier1,tier2,tier3,tier4
>> 
>> Thanks
>> Yumin
>
> Yumin Qi 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 filter more flags to exclude in static dump, add more test cases
>  - Merge branch 'master' into jdk-8259070
>  - Fix white space in CDS.java
>  - Add function CDS.dumpSharedArchive in java to dump shared archive
>  - 8259070: Add jcmd option to dump CDS

Changes requested by iklam (Reviewer).

src/hotspot/share/memory/metaspaceShared.cpp line 50:

> 48: #include "memory/cppVtables.hpp"
> 49: #include "memory/dumpAllocStats.hpp"
> 50: #include "memory/dynamicArchive.hpp"

This is not needed anymore.

src/hotspot/share/prims/jvm.cpp line 3766:

> 3764: JVM_ENTRY(void, JVM_DumpDynamicArchive(JNIEnv *env, jstring archiveName))
> 3765: #if INCLUDE_CDS
> 3766:   assert(UseSharedSpaces && RecordDynamicDumpInfo, "Sanity check");

I think the message should say why this is true.

How about `assert(UseSharedSpaces && RecordDynamicDumpInfo, "already checked in arguments.cpp");`?

(same for the next assert statement at line 3774)

src/hotspot/share/services/diagnosticCommand.cpp line 1139:

> 1137:     Handle throwable(THREAD, PENDING_EXCEPTION);
> 1138:     CLEAR_PENDING_EXCEPTION;
> 1139:     java_lang_Throwable::print_stack_trace(throwable, output());

Actually, it's not necessary to print the stack trace here. This function is called by `jcmd` in attachListener.cpp which will print the stack trace for you.

static jint jcmd(AttachOperation* op, outputStream* out) {
  Thread* THREAD = Thread::current();
  // All the supplied jcmd arguments are stored as a single
  // string (op->arg(0)). This is parsed by the Dcmd framework.
  DCmd::parse_and_execute(DCmd_Source_AttachAPI, out, op->arg(0), ' ', THREAD);
  if (HAS_PENDING_EXCEPTION) {
    java_lang_Throwable::print(PENDING_EXCEPTION, out);
    out->cr();
    CLEAR_PENDING_EXCEPTION;
    return JNI_ERR;
  }
  return JNI_OK;
}

-------------

PR: https://git.openjdk.java.net/jdk/pull/2737

From iklam at openjdk.java.net  Fri Mar 19 05:42:43 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 19 Mar 2021 05:42:43 GMT
Subject: RFR: 8259070: Add jcmd option to dump CDS [v3]
In-Reply-To: <B-g8YZqbJMfAFPZvGpllxvOfoohFeI6MzeNdpEhOCvk=.dbdc6f3e-db3f-419b-8dc1-1ecc155b43a8@github.com>
References: <hwrc1zAz8G180ToL-C3EuUIF-5R17F5Gm1zcPMBpOtE=.e002a377-e0e2-485b-a08e-b63675a9746b@github.com>
 <UQ6gbZhxZ-5W1HkjA_XO2RnuEI1U-scC_iJRPD2Mrb4=.99793b9d-3cd6-4fbe-ad98-f418ccbc6f3a@github.com>
 <B-g8YZqbJMfAFPZvGpllxvOfoohFeI6MzeNdpEhOCvk=.dbdc6f3e-db3f-419b-8dc1-1ecc155b43a8@github.com>
Message-ID: <D4Mrjlq5YbhLB_xCYOgIiF7I3A78marhQFPJJVLLCeg=.abd25b27-b9ff-4530-b86b-b836944b76e8@github.com>

On Wed, 10 Mar 2021 04:22:07 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix white space in CDS.java
>
> src/java.base/share/classes/jdk/internal/misc/CDS.java line 278:
> 
>> 276:             dumpDynamicArchive(archiveFile);
>> 277:         }
>> 278:     }
> 
> I think we should have some error checks and clean up:
> 
> - Remove the classlist file
> - Check if if the process exit status is 0
> - Remove the JSA file first, then try to dump it, and check if the file exists afterwards. If not, report the error. (For both dynamic and static dumps)

The classlist file is not deleted after the dump has finished.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2737

From ysuenaga at openjdk.java.net  Fri Mar 19 09:49:40 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Fri, 19 Mar 2021 09:49:40 GMT
Subject: RFR: 8263342: Add --connect option to jhsdb hsdb/clhsdb [v2]
In-Reply-To: <QdBCJWVSgvrvLdXM17Qdes9ZLd-kJZkKx4AOVo5hTUE=.3abec670-10d2-44ab-9977-ceb78d856895@github.com>
References: <8P9wnEz8u2vWe__AzCvHn5WA12MV-psaP-2y7ZDbr0Q=.21b05c15-b33a-4577-8bb3-4b6b6498e456@github.com>
 <QZ1vc_jKjLAdm9d-FuP43SwUC27uzy32ugiwnpphNgU=.b0f3a1bb-3b49-4621-aadf-ab5dfe75b654@github.com>
 <QdBCJWVSgvrvLdXM17Qdes9ZLd-kJZkKx4AOVo5hTUE=.3abec670-10d2-44ab-9977-ceb78d856895@github.com>
Message-ID: <HxFwzIkToZ0VIZpTVmF4JhofD36A89FDmMf9Ly78aYk=.2c1309dc-d7c5-4022-a6f5-1fbe931116bf@github.com>

On Thu, 11 Mar 2021 03:11:32 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update testcase name
>
> Marked as reviewed by cjplummer (Reviewer).

PiNG: could you review this? I need one more reviewer. CSR has been approved.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2908

From ksakata at openjdk.java.net  Fri Mar 19 10:08:39 2021
From: ksakata at openjdk.java.net (Koichi Sakata)
Date: Fri, 19 Mar 2021 10:08:39 GMT
Subject: RFR: 8263572: Output from jstack mixed mode is misaligned [v2]
In-Reply-To: <gYeX6zc2LJyZREfGeH_Aip3pp48ygBHyWWP_E31hQ_g=.9476f576-66e4-46ed-bcb9-c715b859208d@github.com>
References: <LiAjqiWikfy0llyWM79wX1pZQO4JkNsO8WwjWqcAAKg=.e177e030-08cf-42cd-aaee-27d530b5ed02@github.com>
 <zzzXtXaBXSToz6gz_wS5wRTkr_up1vwa7_vywLbYUMY=.5d9441b0-f92c-448c-818c-8eed4a73ed89@github.com>
 <FkWKGIb6fjNq8lClZzMl-rO5q2-TAAYRGyKT6v_XS6U=.ef40f45e-286f-410d-b1e6-5d670291743a@github.com>
 <gYeX6zc2LJyZREfGeH_Aip3pp48ygBHyWWP_E31hQ_g=.9476f576-66e4-46ed-bcb9-c715b859208d@github.com>
Message-ID: <Eshhp4nHvRj6mglVdrSfoJG5lZoXpa9dgYO4PbrH_aM=.507bb5ae-c9b5-4328-84cc-03aeb4f5584e@github.com>

On Tue, 16 Mar 2021 23:29:31 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Thank you for your comment, @plummercj.
>> 
>>> What testing have you done?
>> 
>> I added the content of the test that I've done in the body text.
>> 
>>> Please update the copyright to 2021.
>> 
>> Sure!
>> 
>>> I noticed that in you original jstack output there is only 1 space after the address, and now there appears to be multiple spaces. However, when I produce the jstack out there's already multiple spaces. Was there some formatting issue with your original output?
>> 
>> I'm sorry. It seemed that a tab after the address was lost on pasting. I pasted proper one once again. So there is no format issue after the address.
>
>> > What testing have you done?
>> 
>> I added the content of the test that I've done in the body text.
> 
> I was referring to the running of existing tests. I just want to make sure the format changes don't cause any tests to fail. It looks like the only test we have that uses `--mixed` is `test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixed.java`. This test is normally run as part of the git automated testing, but it is only run on linux, and I'm seeing the following in the test results:
> 
> `TEST RESULT: Passed. Skipped: jtreg.SkippedException: SA Attach not expected to work. Ptrace attach not supported.`
> 
> So it was skipped since the machine does not support Ptrace attach, and this was the only attempt to run the test.

Thank you. I understand it.

I ran that jtreg test by myself. `TestJhsdbJstackMixed.java` wasn't skipped and the execution was successful as follows.
$ sudo make run-test TEST=serviceability/sa/TestJhsdbJstackMixed.java

$ cat ./jdk/build/linux-x86_64-server-fastdebug/test-results/jtreg_test_hotspot_jtreg_serviceability_sa_TestJhsdbJstackMixed_java/text/summary.txt
serviceability/sa/TestJhsdbJstackMixed.java  Passed. Execution successful
I also added this test result to the body.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3004

From ksakata at openjdk.java.net  Fri Mar 19 12:11:53 2021
From: ksakata at openjdk.java.net (Koichi Sakata)
Date: Fri, 19 Mar 2021 12:11:53 GMT
Subject: RFR: 8176026: SA: Huge heap sizes cause a negative value to be
 displayed in the jhisto heap total
Message-ID: <h_pqXvxIEJRhxH3sEA5fO8Z1XidOU3aZZij_ZVUx1kw=.1cf3982e-7dac-4d2d-80a0-9629eb50c203@github.com>

When a heap is used more than about 2.1GB, clhsdb jhisto shows a negative number in the total field.

$ java -Xmx20g Sample

$ jhsdb clhsdb --pid 5773
Attaching to process 5773, please wait...
hsdb> jhisto
...
299:            1       16      jdk.internal.misc.Unsafe
300:            3402    10737610256     byte[]
Total :         15823   -2146661280
Heap traversal took 1.793 seconds.
(Incidentally, the Sample is a program that only allocates many objects.)

#### Details
This is because in ObjectHistogram class the totalSize variable is int type.

The total size is the total of ObjectHistogramElement#getSize() and getSize() returns long. So I changed int to long in the ObjectHistogram class.

Additionally, I changed the type of the totalCount. This doesn't cause a bug, but ObjectHistogramElement#getCount() also returns long. So it doesn't need to treat it as int, I think.

#### Tests
The jtreg test was successful.
$ sudo make run-test TEST=serviceability/sa/ClhsdbJhisto.java

$ cat build/linux-x86_64-server-fastdebug/test-results/jtreg_test_hotspot_jtreg_serviceability_sa_ClhsdbJhisto_java/text/summary.txt
serviceability/sa/ClhsdbJhisto.java  Passed. Execution successful

I confirmed the output with the same program.

$ ./jdk/build/linux-x86_64-server-fastdebug/jdk/bin/java -Xmx20g Sample
$ ./jdk/build/linux-x86_64-server-fastdebug/jdk/bin/jhsdb clhsdb --pid 22463
Attaching to process 22463, please wait...
hsdb> jhisto

300:            3410    19327547600     byte[]
Total :         16145   19328155080
Heap traversal took 1.981 seconds.

-------------

Commit messages:
 - Use long instead of int
 - Output proper total size when using huge heap

Changes: https://git.openjdk.java.net/jdk/pull/3087/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3087&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8176026
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3087.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3087/head:pull/3087

PR: https://git.openjdk.java.net/jdk/pull/3087

From github.com+76791+alblue at openjdk.java.net  Fri Mar 19 13:11:45 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Fri, 19 Mar 2021 13:11:45 GMT
Subject: RFR: 8263855: Use the blessed modifier order in
 java.management/naming
In-Reply-To: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>
References: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>
Message-ID: <WZ-BfQasElpWpPLI4ACQCdznD25ms1EGTmHTjn-Q2Ss=.6a890ef4-a1fe-4216-a114-a9962dee28de@github.com>

On Thu, 18 Mar 2021 18:26:20 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules.

Would someone mind creating a bug for me? In addition, if it would help, we could create a parent bug for applying cleanups  and associate #2993 and #2991.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3078

From github.com+76791+alblue at openjdk.java.net  Fri Mar 19 13:11:45 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Fri, 19 Mar 2021 13:11:45 GMT
Subject: RFR: 8263855: Use the blessed modifier order in java.management/naming
Message-ID: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>

As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules.

-------------

Commit messages:
 - Use the blessed modifier order in java.management/naming

Changes: https://git.openjdk.java.net/jdk/pull/3078/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3078&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263855
  Stats: 158 lines in 39 files changed: 0 ins; 0 del; 158 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3078.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3078/head:pull/3078

PR: https://git.openjdk.java.net/jdk/pull/3078

From github.com+76791+alblue at openjdk.java.net  Fri Mar 19 13:11:45 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Fri, 19 Mar 2021 13:11:45 GMT
Subject: RFR: 8263855: Use the blessed modifier order in
 java.management/naming
In-Reply-To: <WZ-BfQasElpWpPLI4ACQCdznD25ms1EGTmHTjn-Q2Ss=.6a890ef4-a1fe-4216-a114-a9962dee28de@github.com>
References: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>
 <WZ-BfQasElpWpPLI4ACQCdznD25ms1EGTmHTjn-Q2Ss=.6a890ef4-a1fe-4216-a114-a9962dee28de@github.com>
Message-ID: <ywDO5blMUHP4cs9Yyome20z6r4zPUYxKu5sDkQYrBrE=.447a7f01-fd2e-4319-a083-07a72a722dff@github.com>

On Thu, 18 Mar 2021 19:33:59 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

>> As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules.
>
> Would someone mind creating a bug for me? In addition, if it would help, we could create a parent bug for applying cleanups  and associate #2993 and #2991.

@cl4es would you mind creating a parent task of something like "Source code cleanups" and then another sub task for this change please?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3078

From redestad at openjdk.java.net  Fri Mar 19 13:11:46 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 19 Mar 2021 13:11:46 GMT
Subject: RFR: 8263855: Use the blessed modifier order in
 java.management/naming
In-Reply-To: <ywDO5blMUHP4cs9Yyome20z6r4zPUYxKu5sDkQYrBrE=.447a7f01-fd2e-4319-a083-07a72a722dff@github.com>
References: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>
 <WZ-BfQasElpWpPLI4ACQCdznD25ms1EGTmHTjn-Q2Ss=.6a890ef4-a1fe-4216-a114-a9962dee28de@github.com>
 <ywDO5blMUHP4cs9Yyome20z6r4zPUYxKu5sDkQYrBrE=.447a7f01-fd2e-4319-a083-07a72a722dff@github.com>
Message-ID: <7ty0ud28Z7ozfWLhyqFcrZV7kmDp43KHakhBjcu2FAU=.f56134f2-d2ea-46b7-85a8-4b965a904e1b@github.com>

On Fri, 19 Mar 2021 10:20:39 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

>> Would someone mind creating a bug for me? In addition, if it would help, we could create a parent bug for applying cleanups  and associate #2993 and #2991.
>
> @cl4es would you mind creating a parent task of something like "Source code cleanups" and then another sub task for this change please?

Created the subtask https://bugs.openjdk.java.net/browse/JDK-8263855 for this along with an umbrella RFE.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3078

From github.com+76791+alblue at openjdk.java.net  Fri Mar 19 13:11:46 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Fri, 19 Mar 2021 13:11:46 GMT
Subject: RFR: 8263855: Use the blessed modifier order in
 java.management/naming
In-Reply-To: <7ty0ud28Z7ozfWLhyqFcrZV7kmDp43KHakhBjcu2FAU=.f56134f2-d2ea-46b7-85a8-4b965a904e1b@github.com>
References: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>
 <WZ-BfQasElpWpPLI4ACQCdznD25ms1EGTmHTjn-Q2Ss=.6a890ef4-a1fe-4216-a114-a9962dee28de@github.com>
 <ywDO5blMUHP4cs9Yyome20z6r4zPUYxKu5sDkQYrBrE=.447a7f01-fd2e-4319-a083-07a72a722dff@github.com>
 <7ty0ud28Z7ozfWLhyqFcrZV7kmDp43KHakhBjcu2FAU=.f56134f2-d2ea-46b7-85a8-4b965a904e1b@github.com>
Message-ID: <zOTCpEofKS0qHGhwHjUXpDnO1ySeTely4K7Fjbwc7Ms=.442e8b8f-55a3-485f-ac68-c1138f8d0bb6@github.com>

On Fri, 19 Mar 2021 11:01:45 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> @cl4es would you mind creating a parent task of something like "Source code cleanups" and then another sub task for this change please?
>
> Created the subtask https://bugs.openjdk.java.net/browse/JDK-8263855 for this along with an umbrella RFE.

Thanks @cl4es -- do I need to update the git commit message as well, or is updating the title of the PR sufficient? I recall you suggesting not to do amend/rebases previously.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3078

From redestad at openjdk.java.net  Fri Mar 19 13:30:39 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 19 Mar 2021 13:30:39 GMT
Subject: RFR: 8263855: Use the blessed modifier order in
 java.management/naming
In-Reply-To: <zOTCpEofKS0qHGhwHjUXpDnO1ySeTely4K7Fjbwc7Ms=.442e8b8f-55a3-485f-ac68-c1138f8d0bb6@github.com>
References: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>
 <WZ-BfQasElpWpPLI4ACQCdznD25ms1EGTmHTjn-Q2Ss=.6a890ef4-a1fe-4216-a114-a9962dee28de@github.com>
 <ywDO5blMUHP4cs9Yyome20z6r4zPUYxKu5sDkQYrBrE=.447a7f01-fd2e-4319-a083-07a72a722dff@github.com>
 <7ty0ud28Z7ozfWLhyqFcrZV7kmDp43KHakhBjcu2FAU=.f56134f2-d2ea-46b7-85a8-4b965a904e1b@github.com>
 <zOTCpEofKS0qHGhwHjUXpDnO1ySeTely4K7Fjbwc7Ms=.442e8b8f-55a3-485f-ac68-c1138f8d0bb6@github.com>
Message-ID: <xQ55QiAmbH2FQWrJk3zsSS1EwCFS5V1MNN6Z4WKKoSM=.bb3f4dbd-48d3-4e7d-a692-a9d5d92f3e7e@github.com>

On Fri, 19 Mar 2021 13:08:24 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

>> Created the subtask https://bugs.openjdk.java.net/browse/JDK-8263855 for this along with an umbrella RFE.
>
> Thanks @cl4es -- do I need to update the git commit message as well, or is updating the title of the PR sufficient? I recall you suggesting not to do amend/rebases previously.

No, the git commit messages here doesn't matter, the bots will use the PR name when merging into master. It's good form to use reasonably consistent commit messages as you add commits to a PR, but altering commit history is not necessary and might even be disruptive once a PR has been opened.

There's the /summary command you could use to add additional comments to the final commit, see https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/summary

-------------

PR: https://git.openjdk.java.net/jdk/pull/3078

From github.com+76791+alblue at openjdk.java.net  Fri Mar 19 13:34:46 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Fri, 19 Mar 2021 13:34:46 GMT
Subject: RFR: 8263855: Use the blessed modifier order in
 java.management/naming
In-Reply-To: <xQ55QiAmbH2FQWrJk3zsSS1EwCFS5V1MNN6Z4WKKoSM=.bb3f4dbd-48d3-4e7d-a692-a9d5d92f3e7e@github.com>
References: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>
 <WZ-BfQasElpWpPLI4ACQCdznD25ms1EGTmHTjn-Q2Ss=.6a890ef4-a1fe-4216-a114-a9962dee28de@github.com>
 <ywDO5blMUHP4cs9Yyome20z6r4zPUYxKu5sDkQYrBrE=.447a7f01-fd2e-4319-a083-07a72a722dff@github.com>
 <7ty0ud28Z7ozfWLhyqFcrZV7kmDp43KHakhBjcu2FAU=.f56134f2-d2ea-46b7-85a8-4b965a904e1b@github.com>
 <zOTCpEofKS0qHGhwHjUXpDnO1ySeTely4K7Fjbwc7Ms=.442e8b8f-55a3-485f-ac68-c1138f8d0bb6@github.com>
 <xQ55QiAmbH2FQWrJk3zsSS1EwCFS5V1MNN6Z4WKKoSM=.bb3f4dbd-48d3-4e7d-a692-a9d5d92f3e7e@github.com>
Message-ID: <mvf3ZlfloBYu0vGA-b8gmlIGU8Kbjtnm1EyYljDi6pM=.71fe03be-41a4-48d1-9097-e784c6ea91a3@github.com>

On Fri, 19 Mar 2021 13:28:12 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Thanks @cl4es -- do I need to update the git commit message as well, or is updating the title of the PR sufficient? I recall you suggesting not to do amend/rebases previously.
>
> No, the git commit messages here doesn't matter, the bots will use the PR name when merging into master. It's good form to use reasonably consistent commit messages as you add commits to a PR, but altering commit history is not necessary and might even be disruptive once a PR has been opened.
> 
> There's the /summary command you could use to add additional comments to the final commit, see https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/summary

Thanks @cl4es will adjust my submissions appropriately in the future.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3078

From redestad at openjdk.java.net  Fri Mar 19 14:13:40 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 19 Mar 2021 14:13:40 GMT
Subject: RFR: 8263855: Use the blessed modifier order in
 java.management/naming
In-Reply-To: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>
References: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>
Message-ID: <S1mUeGX1323bhwIudf7rhQb0OExKYEQ5aSwmR0py0fQ=.fa39716f-40c0-4421-ae70-611e14f30c8c@github.com>

On Thu, 18 Mar 2021 18:26:20 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules.

Overall good - found a few cases where the private modifier is in the wrong place that ought to be fixed as well.

src/java.naming/share/classes/com/sun/jndi/ldap/EventQueue.java line 48:

> 46:  */
> 47: final class EventQueue implements Runnable {
> 48:     static final private boolean debug = false;

Move private to the front?

src/java.naming/share/classes/com/sun/jndi/ldap/EventSupport.java line 116:

> 114:  */
> 115: final class EventSupport {
> 116:     static final private boolean debug = false;

Move private to the front?

src/java.naming/share/classes/com/sun/jndi/ldap/LdapSchemaCtx.java line 389:

> 387:     }
> 388: 
> 389:     static final private class SchemaInfo {

Move private to the front?

-------------

Changes requested by redestad (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3078

From github.com+76791+alblue at openjdk.java.net  Fri Mar 19 17:13:58 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Fri, 19 Mar 2021 17:13:58 GMT
Subject: RFR: 8263855: Use the blessed modifier order in
 java.management/naming [v2]
In-Reply-To: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>
References: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>
Message-ID: <6ITH9DKMFtUme7hcRYi9iw8SZgF6d9jE_OJfjtfGsPI=.5c05ae45-f88c-4abf-9786-8520f66f2ab5@github.com>

> As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules.

Alex Blewitt has updated the pull request incrementally with one additional commit since the last revision:

  Added more replacements of 'final public' with 'public final'

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3078/files
  - new: https://git.openjdk.java.net/jdk/pull/3078/files/f1bc7269..1c900d2d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3078&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3078&range=00-01

  Stats: 106 lines in 37 files changed: 0 ins; 0 del; 106 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3078.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3078/head:pull/3078

PR: https://git.openjdk.java.net/jdk/pull/3078

From redestad at openjdk.java.net  Fri Mar 19 18:02:41 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 19 Mar 2021 18:02:41 GMT
Subject: RFR: 8263855: Use the blessed modifier order in
 java.management/naming [v2]
In-Reply-To: <6ITH9DKMFtUme7hcRYi9iw8SZgF6d9jE_OJfjtfGsPI=.5c05ae45-f88c-4abf-9786-8520f66f2ab5@github.com>
References: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>
 <6ITH9DKMFtUme7hcRYi9iw8SZgF6d9jE_OJfjtfGsPI=.5c05ae45-f88c-4abf-9786-8520f66f2ab5@github.com>
Message-ID: <rInyl7rpONuJlsuBSgPQe142X9s8N040ZraY73FMXCI=.17c07e75-07f4-464b-a50e-891cd6ce78d7@github.com>

On Fri, 19 Mar 2021 17:13:58 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

>> As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules.
>
> Alex Blewitt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added more replacements of 'final public' with 'public final'

Marked as reviewed by redestad (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3078

From cjplummer at openjdk.java.net  Fri Mar 19 19:20:40 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 19 Mar 2021 19:20:40 GMT
Subject: Integrated: 8263546: Add "findsym" command to clhsdb.html help file
In-Reply-To: <-u_1bRA3RlHlR4Dh9NkqqlUG3ax86emRoKs5UeGvJXs=.066f58c0-40f7-46d4-bc1b-00f01d2c825e@github.com>
References: <-u_1bRA3RlHlR4Dh9NkqqlUG3ax86emRoKs5UeGvJXs=.066f58c0-40f7-46d4-bc1b-00f01d2c825e@github.com>
Message-ID: <wZ7bcf6t9EQbOBNvGNcdxjJQ5oHEkLDOQn3-fA-zQvk=.0161e646-4e73-4aca-bb53-694b535947ed@github.com>

On Sat, 13 Mar 2021 00:28:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Added clhsdb help for findsym, which was missed when the findsym command was recently added. Also fixed a very minor typo in the findpc help.

This pull request has now been integrated.

Changeset: 30da9bc3
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/30da9bc3
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8263546: Add "findsym" command to clhsdb.html help file

Reviewed-by: ysuenaga, lmesnik

-------------

PR: https://git.openjdk.java.net/jdk/pull/2983

From cjplummer at openjdk.java.net  Fri Mar 19 19:23:43 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 19 Mar 2021 19:23:43 GMT
Subject: Integrated: 8262271: SA: Add new stress test that tests getting the
 stack trace of an active thread
In-Reply-To: <59yxshwLvp5MVCYf2F2THU0T-SJjWbQfQTRLpJ3o2K4=.0e2e73cb-71dd-41b1-a86c-3460631c544c@github.com>
References: <59yxshwLvp5MVCYf2F2THU0T-SJjWbQfQTRLpJ3o2K4=.0e2e73cb-71dd-41b1-a86c-3460631c544c@github.com>
Message-ID: <2NO9AS8fgo79OoffY5rFMLstlf_uZqTFrfdF4t4L2E0=.4f82da34-d3a1-474b-b04f-defbc1ba37f0@github.com>

On Thu, 25 Feb 2021 03:54:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This a new test that runs jstack on a process that is busy doing things. It runs jstack 4 times as the process is starting up.

This pull request has now been integrated.

Changeset: ed701ea6
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ed701ea6
Stats:     112 lines in 1 file changed: 112 ins; 0 del; 0 mod

8262271: SA: Add new stress test that tests getting the stack trace of an active thread

Reviewed-by: ysuenaga, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/2720

From cjplummer at openjdk.java.net  Fri Mar 19 19:42:40 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 19 Mar 2021 19:42:40 GMT
Subject: RFR: 8176026: SA: Huge heap sizes cause a negative value to be
 displayed in the jhisto heap total
In-Reply-To: <h_pqXvxIEJRhxH3sEA5fO8Z1XidOU3aZZij_ZVUx1kw=.1cf3982e-7dac-4d2d-80a0-9629eb50c203@github.com>
References: <h_pqXvxIEJRhxH3sEA5fO8Z1XidOU3aZZij_ZVUx1kw=.1cf3982e-7dac-4d2d-80a0-9629eb50c203@github.com>
Message-ID: <KL-ucPhcexqe_zD0xC2Ngup_mDl_m1B7FCqwqmur4Go=.71239ad8-c2ec-4df7-aaef-d7f1309005e6@github.com>

On Fri, 19 Mar 2021 11:49:39 GMT, Koichi Sakata <ksakata at openjdk.org> wrote:

> When a heap is used more than about 2.1GB, clhsdb jhisto shows a negative number in the total field.
> 
> $ java -Xmx20g Sample
> 
> $ jhsdb clhsdb --pid 5773
> Attaching to process 5773, please wait...
> hsdb> jhisto
> ...
> 299:            1       16      jdk.internal.misc.Unsafe
> 300:            3402    10737610256     byte[]
> Total :         15823   -2146661280
> Heap traversal took 1.793 seconds.
> (Incidentally, the Sample is a program that only allocates many objects.)
> 
> #### Details
> This is because in ObjectHistogram class the totalSize variable is int type.
> 
> The total size is the total of ObjectHistogramElement#getSize() and getSize() returns long. So I changed int to long in the ObjectHistogram class.
> 
> Additionally, I changed the type of the totalCount. This doesn't cause a bug, but ObjectHistogramElement#getCount() also returns long. So it doesn't need to treat it as int, I think.
> 
> #### Tests
> The jtreg test was successful.
> $ sudo make run-test TEST=serviceability/sa/ClhsdbJhisto.java
> 
> $ cat build/linux-x86_64-server-fastdebug/test-results/jtreg_test_hotspot_jtreg_serviceability_sa_ClhsdbJhisto_java/text/summary.txt
> serviceability/sa/ClhsdbJhisto.java  Passed. Execution successful
> 
> I confirmed the output with the same program.
> 
> $ ./jdk/build/linux-x86_64-server-fastdebug/jdk/bin/java -Xmx20g Sample
> $ ./jdk/build/linux-x86_64-server-fastdebug/jdk/bin/jhsdb clhsdb --pid 22463
> Attaching to process 22463, please wait...
> hsdb> jhisto
> 
> 300:            3410    19327547600     byte[]
> Total :         16145   19328155080
> Heap traversal took 1.981 seconds.

I see another cast-to-int related bug, and it's visible in your jhisto output (both before and after):

304: 1 16 jdk.internal.perf.Perf
305: 1 16 java.util.jar.JavaUtilJarAccessImpl
306: 254 2863336944 int[]
Total : 22803 -1430650672 

The large `int[]` array should be at the top of the list, not the bottom. The issue is in ObjectHistogramElement.java:

  public int compare(ObjectHistogramElement other) {
    return (int) (other.size - size);
  }

So this will result in the returned value having the wrong sign if the difference between `other.size` and `size` is too large.  In ObjectHistogram.java, just above the code you fixed, we have:

  public List<ObjectHistogramElement> getElements() {
    List<ObjectHistogramElement> list = new ArrayList<>();
    list.addAll(map.values());
    Collections.sort(list, new Comparator<>() {
      public int compare(ObjectHistogramElement o1, ObjectHistogramElement o2) {
        return o1.compare(o2);
      }
    });
    return list;
  }
So it looks like this is calling the buggy `compare()` method. I think the fix is to have `compare()` return -1, 0, or 1 depending on the `long` value of `(other.size - size)`, rather than just trying to return `(other.size - size)`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3087

From cjplummer at openjdk.java.net  Fri Mar 19 19:48:40 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 19 Mar 2021 19:48:40 GMT
Subject: RFR: 8263572: Output from jstack mixed mode is misaligned [v2]
In-Reply-To: <Tk1-poV1F49pg7TH4c9636JUsJvTk0Q9cK-AZX3uPQM=.b5d134e9-f4bd-48d2-97c4-c8f7776077ad@github.com>
References: <LiAjqiWikfy0llyWM79wX1pZQO4JkNsO8WwjWqcAAKg=.e177e030-08cf-42cd-aaee-27d530b5ed02@github.com>
 <Tk1-poV1F49pg7TH4c9636JUsJvTk0Q9cK-AZX3uPQM=.b5d134e9-f4bd-48d2-97c4-c8f7776077ad@github.com>
Message-ID: <nutWLktEPcQN1uB_B7Rk0sjuGS7nKr0l6E8p2tknTRs=.4fff417a-a6e2-4bf7-87b3-4cd0b2435b38@github.com>

On Tue, 16 Mar 2021 06:09:25 GMT, Koichi Sakata <ksakata at openjdk.org> wrote:

>> When running jstack with mixed option, the output of the lines that doesn't have an address are misaligned as followings. 
>> 
>> $ sudo jhsdb jstack --mixed --pid 8281
>> ----------------- 8330 -----------------
>> "event-handler" #20 daemon prio=5 tid=0x00007f2384838490 nid=0x208a in Object.wait() [0x00007f23585ec000]
>>    java.lang.Thread.State: WAITING (on object monitor)
>>    JavaThread state: _thread_blocked
>> 0x00007f238da899f3      __pthread_cond_wait + 0x243
>> 0x00007f238c63a26b      os::PlatformEvent::park() + 0x8b
>> 0x00007f238c5e689d      ObjectMonitor::wait(long, bool, Thread*) + 0xfed
>> 0x00007f238ca1f1d6      ObjectSynchronizer::wait(Handle, long, Thread*) + 0x96
>> 0x00007f238c0b4d71      JVM_MonitorWait + 0x241
>> 0x00007f237cb246b7      java.lang.Object.wait(long) + 0xd7 (Native method)
>> 0x00007f2375777344      * java.lang.Object.wait() bci:2 line:338 (Compiled frame)
>> * com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(long) bci:64 line:190 (Compiled frame)
>> * com.sun.tools.jdi.EventQueueImpl.remove(long) bci:18 line:97 (Interpreted frame)
>> 0x00007f2375009543      * com.sun.tools.jdi.EventQueueImpl.remove() bci:2 line:83 (Interpreted frame)
>> 
>> This pull request aligns the indentation. So It will be able to improve readability.
>> 
>> In this pull request the address part is filled with white spaces. The amount of space is calculated from VM's address size and lastly 2, which is the length of "0x", is added.
>> 
>> ### jtreg test
>> 
>> $ sudo make run-test TEST=serviceability/sa/TestJhsdbJstackMixed.java
>> 
>> $ cat ./jdk/build/linux-x86_64-server-fastdebug/test-results/jtreg_test_hotspot_jtreg_serviceability_sa_TestJhsdbJstackMixed_java/text/summary.txt
>> serviceability/sa/TestJhsdbJstackMixed.java  Passed. Execution successful
>> 
>> ### Output Confirmation
>> 
>> I checked the output on 64-bit and 32-bit JDK.
>> 
>> First, I ran JShell. Next, on another shell, I ran jstack with mixed option for the JShell process and checked the output.
>> 
>> #### Linux 64-bit JDK
>>  $ ./jdk/build/linux-x86_64-server-fastdebug/jdk/bin/jshell
>> |  Welcome to JShell -- Version 16-internal
>> |  For an introduction type: /help intro
>> 
>> jshell>
>> 
>> $ ./jdk/build/linux-x86_64-server-fastdebug/jdk/bin/jhsdb jstack --mixed --pid 19272
>> ...
>> ----------------- 19324 -----------------
>> "output reader" #21 daemon prio=5 tid=0x00007f2ae4783760 nid=0x4b7c runnable [0x00007f2a86efd000]
>>    java.lang.Thread.State: RUNNABLE
>>    JavaThread state: _thread_in_native
>> 0x00007f2aed5d2394      __libc_read + 0x44
>> 0x00007f2ac450f93b      Java_sun_nio_ch_SocketDispatcher_read0 + 0x2b
>> 0x00007f2adcb2045a      sun.nio.ch.SocketDispatcher.read0(java.io.FileDescriptor, long, int) + 0xfa (Native method)
>> 0x00007f2ad573e024      * sun.nio.ch.SocketDispatcher.read(java.io.FileDescriptor, long, int) bci:4 line:47 (Compiled frame)
>>                         * sun.nio.ch.NioSocketImpl.tryRead(java.io.FileDescriptor, byte[], int, int) bci:45 line:261 (Compiled frame)
>>                         * sun.nio.ch.NioSocketImpl.implRead(byte[], int, int) bci:99 line:312 (Compiled frame)
>>                         * sun.nio.ch.NioSocketImpl.read(byte[], int, int) bci:54 line:350 (Compiled frame)
>>                         * sun.nio.ch.NioSocketImpl$1.read(byte[], int, int) bci:7 line:803 (Compiled frame)
>>                         * java.net.Socket$SocketInputStream.read(byte[], int, int) bci:7 line:961 (Compiled frame)
>>                         * java.net.Socket$SocketInputStream.read() bci:8 line:956 (Compiled frame)
>>                         * java.io.FilterInputStream.read() bci:4 line:82 (Interpreted frame)
>> 0x00007f2ad50094fe      * jdk.jshell.execution.DemultiplexInput.run() bci:4 line:58 (Interpreted frame)
>> 0x00007f2ad5000d4a      <StubRoutines>
>> ...
>> 
>> #### Windows 32-bit JDK
>> $ ./jdk/build/windows-x86-server-fastdebug/jdk/bin/jhsdb.exe jstack --mixed --pid 78808
>> ...
>> ----------------- 29 -----------------
>> "output reader" #17 daemon prio=5 tid=0x2711c3b8 nid=0x13178 runnable [0x27d6f000]
>>    java.lang.Thread.State: RUNNABLE
>>    JavaThread state: _thread_in_native
>> 0x77ae2f5c      ntdll!NtWaitForSingleObject + 0xc
>> 0x6dc5cb18      mswsock!sethostname + 0xbdc8
>> 0x753cdecc      WS2_32!WSARecv + 0x11c
>> 0x6c0d35f8      nio!Java_sun_nio_ch_SocketDispatcher_read0 + 0x48
>> 0x02d15ee9      sun.nio.ch.SocketDispatcher.read0(java.io.FileDescriptor, long, int) + 0xa9 (Native method)
>> 0x02d16540      * sun.nio.ch.SocketDispatcher.read(java.io.FileDescriptor, long, int) bci:4 line:46 (Compiled frame)
>>                 * sun.nio.ch.NioSocketImpl.tryRead(java.io.FileDescriptor, byte[], int, int) bci:45 line:261 (Compiled frame)
>>                 * sun.nio.ch.NioSocketImpl.implRead(byte[], int, int) bci:99 line:312 (Compiled frame)
>>                 * sun.nio.ch.NioSocketImpl.read(byte[], int, int) bci:54 line:350 (Compiled frame)
>>                 * sun.nio.ch.NioSocketImpl$1.read(byte[], int, int) bci:7 line:803 (Compiled frame)
>>                 * java.net.Socket$SocketInputStream.read(byte[], int, int) bci:7 line:961 (Compiled frame)
>>                 * java.net.Socket$SocketInputStream.read() bci:8 line:956 (Compiled frame)
>>                 * java.io.FilterInputStream.read() bci:4 line:82 (Interpreted frame)
>> 0x02ac6804      * jdk.jshell.execution.DemultiplexInput.run() bci:4 line:58 (Interpreted frame)
>> 0x02ac0cdc      <StubRoutines>
>> ...
>
> Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix calculation for the length of white space

Marked as reviewed by cjplummer (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3004

From cjplummer at openjdk.java.net  Fri Mar 19 20:03:40 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 19 Mar 2021 20:03:40 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v10]
In-Reply-To: <QreuPRxLFccE_PiVXh7gZp1lPJGK_tjv5k7RsYgGdA0=.35676d23-d59a-40ff-a3dc-eec2caf7ed01@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <6l7TqqEmupdBa2J8b_NlWif5oVY2SGpu7iKeJMM97ic=.bf63c6e2-878d-4c2a-9a1e-336419c88b58@github.com>
 <CvuSjdeAKN93mwFqzHEya8ho-ONmC_TYAokqDeat3RQ=.ab576df3-1635-45d6-a72f-7aac0a55c34e@github.com>
 <ebrfA2bFIIPhcpZkO75uUvbJ3aMJFoHq_JR46AAEdfQ=.e3dee042-dff0-4b80-8cb0-5c9dae722be7@github.com>
 <HrPwAUu3BrXj3C5fPIjZD3xEO0n2fKoQywKfOiebc7o=.193f9f06-0025-4251-baef-4288aea793b1@github.com>
 <89stqatP7KevfaFqJiTJyoi1q9PdIjR9VpYrK4KzVLE=.120ae881-06b8-4f75-9d51-ff8ea05cac63@github.com>
 <W2I3fgh9yhgn7dm7PM491TkzQ-wbhe_hvqNdZqfW8wU=.7e2e1b13-9138-4c00-94e7-f500e9432c33@github.com>
 <MExJEiIs3e_zBbegggS5C4LSZBcPwDplOchJaztsWeg=.60fc0ca0-3958-4a89-af53-65c896b0c573@github.com>
 <yQM1ngC5wGvP2xr5TvcbZo4JtlF6QttL9owYSUQHEy4=.e14e3464-fa3e-4448-978c-721cf85875d3@github.com>
 <_FI8c6_e9Bn7iQFGK7CZwP9bHQCv--D08Hm6xqjj1zI=.31734f4e-5824-475f-a46c-6630433aa62f@github.com>
 <TVIEliaruP7Sv4OIdxiUrpkAlQOKavCJwmC
 pKxPAqdY=.b2963edb-6b41-4c7d-8e35-22019326c586@github.com>
 <QreuPRxLFccE_PiVXh7gZp1lPJGK_tjv5k7RsYgGdA0=.35676d23-d59a-40ff-a3dc-eec2caf7ed01@github.com>
Message-ID: <pZb37I07a7RIq9jmoDNGQUIJQBJvtSrfYOe9dE2IGy4=.abc073ff-a6d1-48e6-a1fd-56741b4aee91@github.com>

On Thu, 18 Mar 2021 14:40:57 GMT, Lin Zang <lzang at openjdk.org> wrote:

> * Is it acceptable that `jmap -dump` and `jmap -histo` have different behavior about the option of `parallel`, that is, `heapdump` does not use it and `heaphisto` does.

And just to further clarify, the parallel support for `jmap -histo` is already in JDK 16, which is one reason we were swayed towards including it with `jmap -dump`. If we didn't we were thinking in order to be consistent we would need to pull the parallel support for `jmap -histo`, which would be somewhat problematic since it will already have shipped in 16. However, given that these are really two different commands, and we have some good arguments for not including parallel support for `jmap -dump`, I can see leaving it out.

> * If we decide to not introduce the `parallel` option, we don't need to introduce the `heapdumpext` attach api command, so the 2 CSRs related to this PR could be closed. But this may leave the argument count problem to future, when more argumebts is introduced, is this acceptable?

Yes, and in fact I would argue that we should not be doing the `heapdumpext` solution now if we no longer have a need for it.

> * if we decide to introduce `parallel=<N>` option, do we need to add explaination in the document? or docs like tuning guide?

Which document were you thinking? Is the turning guide a hotspot tuning guide? If so, I don't think that's the right place for it. The focus should be in any jmap documentation.

And to add a 4th bullet item to your list, we also have the `GC.heap_dump` jcmd. I think there as a CR and CSR to add parallel support to it (but honestly I've lost track). If we choose not to include parallel support for `jmap -dump`, I think we should exclude it from `GC.heap_dump` also.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From amenkov at openjdk.java.net  Fri Mar 19 20:14:42 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Fri, 19 Mar 2021 20:14:42 GMT
Subject: Integrated: 8262080:
 vmTestbase/nsk/jdi/Event/request/request001/TestDescription.java failed with
 "ERROR: new event is not ThreadStartEvent"
In-Reply-To: <JzsafYgSso5aYsPImTLCz52dN96s-BJbY3eMrHwxLRw=.9e781f40-5e59-425e-ab83-03872256cb9d@github.com>
References: <JzsafYgSso5aYsPImTLCz52dN96s-BJbY3eMrHwxLRw=.9e781f40-5e59-425e-ab83-03872256cb9d@github.com>
Message-ID: <TBZX5nGHfQsdx1gOOkmFGY0YjSaoX4dklPxOzDDcfug=.ed0d2410-bb4a-40a3-8fba-aa4febe793b9@github.com>

On Wed, 10 Mar 2021 23:12:47 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates the test to skip ThreadStartEvent/ThreadDeathEvent from other threads

This pull request has now been integrated.

Changeset: 57fc8e9b
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/57fc8e9b
Stats:     37 lines in 2 files changed: 33 ins; 0 del; 4 mod

8262080: vmTestbase/nsk/jdi/Event/request/request001/TestDescription.java failed with "ERROR: new event is not ThreadStartEvent"

Reviewed-by: cjplummer, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/2927

From amenkov at openjdk.java.net  Fri Mar 19 20:16:40 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Fri, 19 Mar 2021 20:16:40 GMT
Subject: Integrated: 8262083:
 vmTestbase/nsk/jvmti/SetEventNotificationMode/setnotif001/TestDescription.java
 failed with "No notification: event JVMTI_EVENT_FRAME_POP (61)"
In-Reply-To: <qaKtyTEgt_5tOUH_SP_x4sRVTuS8XBW95kSzty7TsAY=.85d10651-f3a1-477d-9e00-2a3a82d171dd@github.com>
References: <qaKtyTEgt_5tOUH_SP_x4sRVTuS8XBW95kSzty7TsAY=.85d10651-f3a1-477d-9e00-2a3a82d171dd@github.com>
Message-ID: <dmrPLEzJP025nXqGrUUBVTz-M5fhFVijpF0kMUZcI5o=.039b8b09-adaf-448b-867c-8cc9c0a1f50a@github.com>

On Wed, 17 Mar 2021 23:42:46 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The test requests NotifyFrame event from MethodEntry handler expecting that 1st MethodEntry event is generated for main thread.
> The fix adds a check that the thread is correct and skips event from other threads

This pull request has now been integrated.

Changeset: 6737135b
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6737135b
Stats:     35 lines in 2 files changed: 15 ins; 11 del; 9 mod

8262083: vmTestbase/nsk/jvmti/SetEventNotificationMode/setnotif001/TestDescription.java failed with "No notification: event JVMTI_EVENT_FRAME_POP (61)"

Reviewed-by: lmesnik, cjplummer

-------------

PR: https://git.openjdk.java.net/jdk/pull/3060

From dcubed at openjdk.java.net  Fri Mar 19 20:19:45 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 19 Mar 2021 20:19:45 GMT
Subject: RFR: 8262881: port JVM/DI tests from JDK-4413752 to JVM/TI
In-Reply-To: <pIS66umBFPY0bsix6EW_zdVNzFG5J6A33FHVrpvEJ64=.c3cc75d9-25cd-4fc0-b3bc-35fe628d5e2c@github.com>
References: <XOECrKnBcmSRjfY2cM-GqFs3jMr0fTy7KJUCUHZ0HGw=.54872a68-97e9-481a-871e-eade80a51604@github.com>
 <pIS66umBFPY0bsix6EW_zdVNzFG5J6A33FHVrpvEJ64=.c3cc75d9-25cd-4fc0-b3bc-35fe628d5e2c@github.com>
Message-ID: <FTPu45SOPngFqXyPfuBhBewCMrOKmxVWMM1c5shSAk0=.f2ae0a1f-d047-4e38-9646-973cea5d14bd@github.com>

On Wed, 17 Mar 2021 07:18:07 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Add three tests from JDK-4413752 ported to JVM/TI:
>> 
>> - RawMonitorEnter() with SuspendThread()
>>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithRawMonitorEnter/SuspendWithRawMonitorEnter.java
>>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithRawMonitorEnter/libSuspendWithRawMonitorEnter.cpp
>> 
>> - ObjectMonitor enter() with SuspendThread()
>>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorEnter/SuspendWithObjectMonitorEnter.java
>>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorEnter/libSuspendWithObjectMonitorEnter.cpp
>> 
>> - ObjectMonitor wait() with SuspendThread
>>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java
>>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/libSuspendWithObjectMonitorWait.cpp
>> 
>> The Java files have a transaction diagram to show what each of the
>> threads in the test is doing.
>
> Hi Dan,
> It is interesting how much these tests were changed when ported.
> A couple of indent-related comments.
> There are incorrect indents in the following lines in all .cpp files:
>  ```
> 68 Java_SuspendWithObjectMonitorEnter_GetResult(JNIEnv *env, jclass cls) {
>  69     return iGlobalStatus;
>  70 }
>   72 JNIEXPORT void JNICALL
>  73 Java_SuspendWithObjectMonitorEnter_SetPrintDebug(JNIEnv *env, jclass cls) {
>  74     printdebug = 1;
>  75 }
>  97 Java_SuspendWithObjectMonitorEnterWorker_GetPrintDebug(JNIEnv *env, jclass cls) {
>  98     return printdebug;
>  99 }
> 
> Thanks,
> Serguei

@sspitsyn - Thanks for the review! I figured you would enjoy this 20 year old
blast from the past! I'm tempted to ping @karenkinnear just to see if she'll
remember these tests!

I'll fix the indents in the .cpp files. Right now I'm using these tests to shake
out @robehn's work on "JDK-8257831 Suspend with handshakes".

-------------

PR: https://git.openjdk.java.net/jdk/pull/2899

From cjplummer at openjdk.java.net  Fri Mar 19 20:23:39 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 19 Mar 2021 20:23:39 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out
In-Reply-To: <mzZdkiwtjfisDNUd2cN9YNDYeFDFrj92wsX5tnaqzxA=.96a75c19-42a1-4dfa-960f-910476447ffd@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
 <Zvf7GN59hJdc7SgVRao3cEbcpU99CbGceULIfJnDJOE=.4bd79c51-6b9b-4ff9-9ada-dc43fd6ca6e8@github.com>
 <e6bMvI_trIEXu7SAiM98-OpZug3Mwli00owZzLXxJNo=.fa0b5857-28b8-428d-9477-61044e32ad49@github.com>
 <oaMRL-GuwQKYlGByJvPhHH63A4LTvQLsL2W6BOIS6cc=.5ee0e7f9-bdc3-4e51-9fcf-999d607730c1@github.com>
 <7p7PD78B0fKuSonRZ44rQWvBKHabsz4n9VT4WbVluFI=.e4248320-f134-4ed0-b073-a3466970932c@github.com>
 <cedPjc6Gumib0S_yqDLAm8up9lPEGguw5w5LJblpKHM=.cad805fe-ab47-4eb4-8c78-e2a17109a2ce@github.com>
 <69h5uaXSdgc4Fkhla6QdtoezGPyVcFMNasVI8iNxYWI=.3a7c3e6a-8dfa-4ff1-a7cf-db71d3ea7bbf@github.com>
 <2J1CEmVaXJuvU3fseIBYDcJCihqoeAf07bt0hgvJWWE=.259496ed-1883-4035-a4e5-e6c45f511707@github.com>
 <rFBFEymgIrkLQdW4dLSSRthpE6vu629ScEsMmO8YM3w=.a8182d50-bb9e-4a2a-9cec-c965f80cca80@github.com>
 <mzZdkiwtjfisDNUd2cN9YNDYeFDFrj92wsX5tnaqzxA=.96a75c19-42a1-4dfa-960f-910476447ffd@github.com>
Message-ID: <cj2qtJhobkpGMwLJ7BFF601v7lknxONwm2lnzHHe8gA=.ad2a9371-f39c-4099-b879-882f27f9a9a9@github.com>

On Wed, 17 Mar 2021 07:21:06 GMT, Lin Zang <lzang at openjdk.org> wrote:

> IMO, it is better to dump all array object in `write-through` mode, because it could avoid memory consumption and performance issue when dumping large array. And the original implementation of object dump works like `write-through`, so this fix looks like sort of retrieve back to the original behavior.

I guess I don't understand why you would want write-through for small arrays but not large objects. I also have to admit I don't fully grasp the purpose of "segment mode". I see the docs say:

 301  * A heap dump can optionally be generated as a sequence of heap dump
 302  * segments. This sequence is terminated by an end record. The additional
 303  * tags allowed by format "JAVA PROFILE 1.0.2" are:
 304  *
 305  * HPROF_HEAP_DUMP_SEGMENT  denote a heap dump segment
 306  *
 307  *               [heap dump sub-records]*
 308  *               The same sub-record types allowed by HPROF_HEAP_DUMP
 309  *
 310  * HPROF_HEAP_DUMP_END      denotes the end of a heap dump

But all this seems to be doing is grouping the HPROF_HEAP_DUMP records into an array rather than having them interspersed with other types of records. How does this help, and why would this mode not always be enabled?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2803

From cjplummer at openjdk.java.net  Fri Mar 19 20:36:39 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 19 Mar 2021 20:36:39 GMT
Subject: RFR: 8263670: pmap and pstack in jhsdb do not work on debug
 server [v2]
In-Reply-To: <8nzlQFRQWlro_1j_47-7QTdhmFzm3gGIwGTrGWyQqFA=.fe77d8a2-c9c5-4c86-885e-ebb7850a1d00@github.com>
References: <OzFp9WFONUqIUYqdZ78D04bfnhgOSaeB1WqmPtyUdA0=.7dcf74d3-6819-4c9c-b878-a26cfcd0cbc6@github.com>
 <8nzlQFRQWlro_1j_47-7QTdhmFzm3gGIwGTrGWyQqFA=.fe77d8a2-c9c5-4c86-885e-ebb7850a1d00@github.com>
Message-ID: <OuGZ5dVw9QTE7sdNFFkGcE_CYZkh_bC3-QrwjF9aOfQ=.104dc0d1-b297-4fb5-9637-a0d5c23ec1bf@github.com>

On Thu, 18 Mar 2021 05:17:10 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> jhsdb supports pmap (jhsdb jmap) and pstack (jhsdb jstack --mixed), and they work fine if they attach to live process or to coredump, however they do not work on debug server as following:
>> 
>> $ jhsdb jmap --connect localhost
>> Attaching to remote server localhost, please wait...
>> Debugger attached successfully.
>> Server compiler detected.
>> JVM version is 11.0.10+9
>> remote configuration is not yet implemented
>> 
>> pmap and pstack depend on CDebugger in SA, however it would not be set in case of remote debugger client. We can avoid it if we can delegate the process to debug server.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update testcases

The changes look good. Just curious though, why are all the debugd tests excluded on windows?

-------------

Marked as reviewed by cjplummer (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3027

From dcubed at openjdk.java.net  Fri Mar 19 21:28:09 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 19 Mar 2021 21:28:09 GMT
Subject: RFR: 8262881: port JVM/DI tests from JDK-4413752 to JVM/TI [v2]
In-Reply-To: <XOECrKnBcmSRjfY2cM-GqFs3jMr0fTy7KJUCUHZ0HGw=.54872a68-97e9-481a-871e-eade80a51604@github.com>
References: <XOECrKnBcmSRjfY2cM-GqFs3jMr0fTy7KJUCUHZ0HGw=.54872a68-97e9-481a-871e-eade80a51604@github.com>
Message-ID: <wUCvQfmlMD5sMgBEIDspFQigcEMfmJWrJW6LcRxdFJo=.46453b48-b28f-4740-80b5-0909e980d1c7@github.com>

> Add three tests from JDK-4413752 ported to JVM/TI:
> 
> - RawMonitorEnter() with SuspendThread()
>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithRawMonitorEnter/SuspendWithRawMonitorEnter.java
>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithRawMonitorEnter/libSuspendWithRawMonitorEnter.cpp
> 
> - ObjectMonitor enter() with SuspendThread()
>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorEnter/SuspendWithObjectMonitorEnter.java
>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorEnter/libSuspendWithObjectMonitorEnter.cpp
> 
> - ObjectMonitor wait() with SuspendThread
>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java
>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/libSuspendWithObjectMonitorWait.cpp
> 
> The Java files have a transaction diagram to show what each of the
> threads in the test is doing.

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  sspitsyn - fix white space indents problems.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2899/files
  - new: https://git.openjdk.java.net/jdk/pull/2899/files/3e719713..fb564a25

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2899&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2899&range=00-01

  Stats: 9 lines in 3 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2899.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2899/head:pull/2899

PR: https://git.openjdk.java.net/jdk/pull/2899

From lmesnik at openjdk.java.net  Fri Mar 19 22:25:49 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Fri, 19 Mar 2021 22:25:49 GMT
Subject: RFR: 8263895: Test
 nsk/jvmti/GetThreadGroupChildren/getthrdgrpchld001/getthrdgrpchld001.cpp uses
 incorrect indices
Message-ID: <hUFzfiR5CfIVjDpxAaM5GVhqVzDhrhakVqSU5YRIxVg=.ce231115-3b9c-4244-b19f-300b719bef10@github.com>

8263895: Test nsk/jvmti/GetThreadGroupChildren/getthrdgrpchld001/getthrdgrpchld001.cpp uses incorrect indices

-------------

Commit messages:
 - 8263895: Test nsk/jvmti/GetThreadGroupChildren/getthrdgrpchld001/getthrdgrpchld001.cpp uses incorrect indices

Changes: https://git.openjdk.java.net/jdk/pull/3098/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3098&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263895
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3098.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3098/head:pull/3098

PR: https://git.openjdk.java.net/jdk/pull/3098

From amenkov at openjdk.java.net  Fri Mar 19 23:42:38 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Fri, 19 Mar 2021 23:42:38 GMT
Subject: RFR: 8263895: Test
 nsk/jvmti/GetThreadGroupChildren/getthrdgrpchld001/getthrdgrpchld001.cpp uses
 incorrect indices
In-Reply-To: <hUFzfiR5CfIVjDpxAaM5GVhqVzDhrhakVqSU5YRIxVg=.ce231115-3b9c-4244-b19f-300b719bef10@github.com>
References: <hUFzfiR5CfIVjDpxAaM5GVhqVzDhrhakVqSU5YRIxVg=.ce231115-3b9c-4244-b19f-300b719bef10@github.com>
Message-ID: <IlHWFDZtdNFcfvpi7XDDSAKF1nhCG4iGDDJhT1f40fg=.62bad29b-7b67-4997-9619-f898d2ba1f3d@github.com>

On Fri, 19 Mar 2021 22:20:35 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> 8263895: Test nsk/jvmti/GetThreadGroupChildren/getthrdgrpchld001/getthrdgrpchld001.cpp uses incorrect indices

Marked as reviewed by amenkov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3098

From ysuenaga at openjdk.java.net  Sat Mar 20 02:10:38 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sat, 20 Mar 2021 02:10:38 GMT
Subject: RFR: 8263670: pmap and pstack in jhsdb do not work on debug
 server [v2]
In-Reply-To: <OuGZ5dVw9QTE7sdNFFkGcE_CYZkh_bC3-QrwjF9aOfQ=.104dc0d1-b297-4fb5-9637-a0d5c23ec1bf@github.com>
References: <OzFp9WFONUqIUYqdZ78D04bfnhgOSaeB1WqmPtyUdA0=.7dcf74d3-6819-4c9c-b878-a26cfcd0cbc6@github.com>
 <8nzlQFRQWlro_1j_47-7QTdhmFzm3gGIwGTrGWyQqFA=.fe77d8a2-c9c5-4c86-885e-ebb7850a1d00@github.com>
 <OuGZ5dVw9QTE7sdNFFkGcE_CYZkh_bC3-QrwjF9aOfQ=.104dc0d1-b297-4fb5-9637-a0d5c23ec1bf@github.com>
Message-ID: <az2jW_c0Pm9kvhMHoHf8eMA9Z7kVIBHdNKnx6Fr11mU=.3818cae5-dac3-44d3-a989-29efe356d9e9@github.com>

On Fri, 19 Mar 2021 20:33:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update testcases
>
> The changes look good. Just curious though, why are all the debugd tests excluded on windows?

@plummercj Thanks for your reivew!

> The changes look good. Just curious though, why are all the debugd tests excluded on windows?

It is caused by JDK-8224252. I left a [comment](https://bugs.openjdk.java.net/browse/JDK-8224252?focusedCommentId=14265851&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14265851) on it that we cannot destroy debugd process normally on Windows.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3027

From lmesnik at openjdk.java.net  Sat Mar 20 03:00:52 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Sat, 20 Mar 2021 03:00:52 GMT
Subject: RFR: 8263895: Test
 nsk/jvmti/GetThreadGroupChildren/getthrdgrpchld001/getthrdgrpchld001.cpp uses
 incorrect indices [v2]
In-Reply-To: <hUFzfiR5CfIVjDpxAaM5GVhqVzDhrhakVqSU5YRIxVg=.ce231115-3b9c-4244-b19f-300b719bef10@github.com>
References: <hUFzfiR5CfIVjDpxAaM5GVhqVzDhrhakVqSU5YRIxVg=.ce231115-3b9c-4244-b19f-300b719bef10@github.com>
Message-ID: <R1YbXvN76LLc7aqagS6O6aRjiATSwGS2B1qCfEsb2vg=.dae2982a-90f3-418c-9452-5c31b21308de@github.com>

> 8263895: Test nsk/jvmti/GetThreadGroupChildren/getthrdgrpchld001/getthrdgrpchld001.cpp uses incorrect indices

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  Copyright updated.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3098/files
  - new: https://git.openjdk.java.net/jdk/pull/3098/files/aebc0d3d..ceffc3fb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3098&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3098&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3098.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3098/head:pull/3098

PR: https://git.openjdk.java.net/jdk/pull/3098

From lzang at openjdk.java.net  Mon Mar 22 04:14:39 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 22 Mar 2021 04:14:39 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out
In-Reply-To: <cj2qtJhobkpGMwLJ7BFF601v7lknxONwm2lnzHHe8gA=.ad2a9371-f39c-4099-b879-882f27f9a9a9@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
 <Zvf7GN59hJdc7SgVRao3cEbcpU99CbGceULIfJnDJOE=.4bd79c51-6b9b-4ff9-9ada-dc43fd6ca6e8@github.com>
 <e6bMvI_trIEXu7SAiM98-OpZug3Mwli00owZzLXxJNo=.fa0b5857-28b8-428d-9477-61044e32ad49@github.com>
 <oaMRL-GuwQKYlGByJvPhHH63A4LTvQLsL2W6BOIS6cc=.5ee0e7f9-bdc3-4e51-9fcf-999d607730c1@github.com>
 <7p7PD78B0fKuSonRZ44rQWvBKHabsz4n9VT4WbVluFI=.e4248320-f134-4ed0-b073-a3466970932c@github.com>
 <cedPjc6Gumib0S_yqDLAm8up9lPEGguw5w5LJblpKHM=.cad805fe-ab47-4eb4-8c78-e2a17109a2ce@github.com>
 <69h5uaXSdgc4Fkhla6QdtoezGPyVcFMNasVI8iNxYWI=.3a7c3e6a-8dfa-4ff1-a7cf-db71d3ea7bbf@github.com>
 <2J1CEmVaXJuvU3fseIBYDcJCihqoeAf07bt0hgvJWWE=.259496ed-1883-4035-a4e5-e6c45f511707@github.com>
 <rFBFEymgIrkLQdW4dLSSRthpE6vu629ScEsMmO8YM3w=.a8182d50-bb9e-4a2a-9cec-c965f80cca80@github.com>
 <mzZdkiwtjfisDNUd2cN9YNDYeFDFrj92wsX5tnaqzxA=.96a75c19-42a1-4dfa-960f-910476447ffd@github.com>
 <cj2qtJhobkpGMwLJ7BFF601v7lknxONwm2l
 nzHHe8gA=.ad2a9371-f39c-4099-b879-882f27f9a9a9@github.com>
Message-ID: <yqd0Jb9DZkjgxXV8qWHjBoDIIttmvON85ZfsWrP7-gg=.36b85cd4-acdd-475b-bc5f-3c882ea99358@github.com>

On Fri, 19 Mar 2021 20:21:12 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Dear Serguei, 
>> Thanks for review! I will refine it based on your comments.
>> 
>>> I agree with Chris, it is confusing why the decision about write-trough mode is made in this method 
>> 
>> The "write-through" mode requires filling the segment size in segment header before object contents are scanned and written, And it is only in method `calculateArrayMaxLength()` the array size could be known and filled, and therefore the `write-through` mode could be enabled.
>> (please be aware that current implementation of dumping non-array object does not calculate the object size first, which is 
>> the reason why internal buffer is required when compressed heap dump was introduced.)
>> 
>>> The method fillSegmentSizeAndEnableWriteThrough() is called for any array if useSegmentedHeapDump == true,
>>> so any segmented output for arrays is direct (in write-through mode).
>>> Is this new dimension really needs to be introduced?
>> 
>> IMO, it is better to dump all array object in `write-through` mode, because it could avoid memory consumption and performance issue when dumping large array. And the original implementation of object dump works like `write-through`, so this fix looks like sort of retrieve back to the original behavior.
>> 
>> On the other side, the specific issue described at JDK-8262386 could also be fixed if enable write-through mode only when array size is larger than maxBytes calculated in `calculateArrayMaxLength()`, because the test created an 4GB integer array.  But I suggest to `write-through` all array objects as this could help avoid similar issue that may happen when dump large array whose size is less than 4GB. 
>> 
>>> Does the check for "!writeThrough" at L1368 means there is no need to write the segment header (as at L1371)?
>> 
>> Yes, The `writeSegmentHeader(size)` is invoked in `fillSegmentSizeAndEnableWriteThrough()`, so there is no need to call it here.
>> 
>> Thanks!
>> Lin
>
>> IMO, it is better to dump all array object in `write-through` mode, because it could avoid memory consumption and performance issue when dumping large array. And the original implementation of object dump works like `write-through`, so this fix looks like sort of retrieve back to the original behavior.
> 
> I guess I don't understand why you would want write-through for small arrays but not large objects. I also have to admit I don't fully grasp the purpose of "segment mode". I see the docs say:
> 
>  301  * A heap dump can optionally be generated as a sequence of heap dump
>  302  * segments. This sequence is terminated by an end record. The additional
>  303  * tags allowed by format "JAVA PROFILE 1.0.2" are:
>  304  *
>  305  * HPROF_HEAP_DUMP_SEGMENT  denote a heap dump segment
>  306  *
>  307  *               [heap dump sub-records]*
>  308  *               The same sub-record types allowed by HPROF_HEAP_DUMP
>  309  *
>  310  * HPROF_HEAP_DUMP_END      denotes the end of a heap dump
> 
> But all this seems to be doing is grouping the HPROF_HEAP_DUMP records into an array rather than having them interspersed with other types of records. How does this help, and why would this mode not always be enabled?
> 
> Also I'm not so sure the above documentation is fully accurate. It looks like both HPROF_HEAP_DUMP_SEGMENT and HPROF_HEAP_DUMP_END are followed by a 4-byte size and 4-byte timestamp, although the timestamp seems to always be 0, and the size for END is also always 0.

Dear Chris?

> I guess I don't understand why you would want write-through for small arrays but not large objects.

I think it is because that the current implementation does not have code which could calculate the object size before scan it. but it has the logic for calculate array length (`calculateArrayMaxLength()`) ahead of scaning.  ( BTW, I am planing to add the logic for object, and then rewrite the whole heap dump impl to use writeThrough also for compressed dump, I think that should be in a separate PR)

> But all this seems to be doing is grouping the HPROF_HEAP_DUMP records into an array rather than having them interspersed with other types of records. How does this help, and why would this mode not always be enabled?

I think the original pupose of SEGMENT heap dump is to handle the case for large heap. In the hprof format spec, the size slot of the heap dump is 32bit, which means it has limitation of dump 4GB used heap.  so use segmental dump could help resolve the problem. And IMO the reason for not always enable it is because every segment has a header and tail, which may introduce extra memory, althogh it is not much.

> It looks like both HPROF_HEAP_DUMP_SEGMENT and HPROF_HEAP_DUMP_END are followed by a 4-byte size and 4-byte timestamp, although the timestamp seems to always be 0, and the size for END is also always 0.

My understand  from code is that 4-byte size and 4-byte timestamp only exist after HPROF_HEAP_DUMP_SEGMENT, and the HPROF_HEAP_DUMP_END actually is the end of the segment.  So I think the specification is not accurate.

Thanks,
Lin

-------------

PR: https://git.openjdk.java.net/jdk/pull/2803

From lzang at openjdk.java.net  Mon Mar 22 08:01:49 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 22 Mar 2021 08:01:49 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v10]
In-Reply-To: <pZb37I07a7RIq9jmoDNGQUIJQBJvtSrfYOe9dE2IGy4=.abc073ff-a6d1-48e6-a1fd-56741b4aee91@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <6l7TqqEmupdBa2J8b_NlWif5oVY2SGpu7iKeJMM97ic=.bf63c6e2-878d-4c2a-9a1e-336419c88b58@github.com>
 <CvuSjdeAKN93mwFqzHEya8ho-ONmC_TYAokqDeat3RQ=.ab576df3-1635-45d6-a72f-7aac0a55c34e@github.com>
 <ebrfA2bFIIPhcpZkO75uUvbJ3aMJFoHq_JR46AAEdfQ=.e3dee042-dff0-4b80-8cb0-5c9dae722be7@github.com>
 <HrPwAUu3BrXj3C5fPIjZD3xEO0n2fKoQywKfOiebc7o=.193f9f06-0025-4251-baef-4288aea793b1@github.com>
 <89stqatP7KevfaFqJiTJyoi1q9PdIjR9VpYrK4KzVLE=.120ae881-06b8-4f75-9d51-ff8ea05cac63@github.com>
 <W2I3fgh9yhgn7dm7PM491TkzQ-wbhe_hvqNdZqfW8wU=.7e2e1b13-9138-4c00-94e7-f500e9432c33@github.com>
 <MExJEiIs3e_zBbegggS5C4LSZBcPwDplOchJaztsWeg=.60fc0ca0-3958-4a89-af53-65c896b0c573@github.com>
 <yQM1ngC5wGvP2xr5TvcbZo4JtlF6QttL9owYSUQHEy4=.e14e3464-fa3e-4448-978c-721cf85875d3@github.com>
 <_FI8c6_e9Bn7iQFGK7CZwP9bHQCv--D08Hm6xqjj1zI=.31734f4e-5824-475f-a46c-6630433aa62f@github.com>
 <TVIEliaruP7Sv4OIdxiUrpkAlQOKavCJwmC
 pKxPAqdY=.b2963edb-6b41-4c7d-8e35-22019326c586@github.com>
 <QreuPRxLFccE_PiVXh7gZp1lPJGK_tjv5k7RsYgGdA0=.35676d23-d59a-40ff-a3dc-eec2caf7ed01@github.com>
 <pZb37I07a7RIq9jmoDNGQUIJQBJvtSrfYOe9dE2IGy4=.abc073ff-a6d1-48e6-a1fd-56741b4aee91@github.com>
Message-ID: <wuRrzksQqDdVecK83-rIuYaLLefZTTKCMqPsdHhwQi4=.f2043160-4833-4ebd-b7a9-504b043967a6@github.com>

On Fri, 19 Mar 2021 20:01:01 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Dear Ralf and Chris,
>> 
>>> to be honest I would prefer if we would not add the parallel option but instead do it automatically depending on the number of GC threads available. I doubt that the user has a good idea about number of threads to use, so I think it is better to just use a sensible default derived from the number of threads available and if compression is enabled or not.
>> 
>> Thanks Ralf for your comments!
>> 
>> @plummercj and I have discussed the `parallel=` option several rounds, also together with Serguei @sspitsyn  and Ham-Lin @Hamlin-Li . And I recently also re-considered this option for dumping. here I list my opinion and hope we could made the final decision this time :-)
>> 
>> - The `parallel=<N>` option for `jmap -histo` has been discussed and finalized, I think we could leave it as it is. Because user may get general info about their system, such as core number and multi-process workload, these could help them tuning.  And also because the `parallel=<N>` option only affects how many threads would be used for object iteration (this is different with `jmap -dump`, I will explain in following comments), it is easy to observe the output or time and then adjust the number.
>> 
>> - The `parallel=<N>` option for `jmap -dump` is complicated, it has to consider the file writer threads and the disk writing speed. let me try to explain the implementation briefly:
>> 
>> In current implementation, the heap dump actaully has two kind of worker threads - dumper and writter. The dumper iterates over the heap and send data to the writer; the writer does compression if required and writes data to the file. There is buffer queue between dumper and writer: dumper grab empty buffer and fill data into the queue , and the writer threads grab the filled buffer from the queue, write data to file and then return empty buffer for futurn use. 
>> In summary it looks like following graph:
>> 
>> ` Dumper  --> BufferQueue (size == #writers) --> writer(multiple) ==> disk(file)`
>> 
>> Before this patch, there is only one dumper (the VMThread) and all other worker threads are writer, that is, all GC threads work as writer. The only dumper iterate heap and the multiple writers write data to file. So the bottomneck is more likely to be heap iteration (dumper side).
>> 
>> With this patch,  there are multiple dumpers and multiple writers,  they all divided the gc thread number (plus 1 vmthread). And since there are multiple dumpers, the buffer queue is more likely to be filled.  So the bottomneck move from heap iteration to two aspect (writer side):
>> - drain of buffer queue 
>> - speed of disk writing
>> 
>> Since the buffer queue size is determined by number of writers, and the disk writing speed determines how fast the buffer can be empty again, it is important to keep the writer number as much as it can be to satisfy the dumper's requirement.
>> 
>> The `parallel=<N>` option only control the dumper thread number, and it indirectly affects the writer's thread number (as they all divide the total thread number). it is really hard for user to understand these internal mechanism and do tuning.  
>> 
>> And by default, the number of dumpers and writers are half : half of GC threads +1(vmThread), my testing shown this configuration is likly to be optimal. ( But maybe more evalution is required to confirm)
>> 
>> In summary, I think it is very hard for user to tune the parallel thread number for heap dump. So I suggest to remove it for dump and enable the parallel by default. 
>> 
>> Again, For `jmap -histo`, I suggest to keep this since it is more easy to be understood.
>> 
>> IMO, to make final decision, we need to consider following:
>> - Is it acceptable that `jmap -dump` and `jmap -histo` have different behavior about the option of `parallel`, that is, `heapdump` does not use it and `heaphisto` does.
>> - If we decide to not introduce the `parallel` option, we don't need to introduce the `heapdumpext` attach api command, so the 2 CSRs related to this PR could be closed. But this may leave the argument count problem to future, when more argumebts is introduced, is this acceptable? 
>> - if we decide to introduce `parallel=<N>` option, do we need to add explaination in the document? or docs like tuning guide? 
>> 
>> Welcome for any of your comments!
>> 
>> BRs,
>> Lin
>
>> * Is it acceptable that `jmap -dump` and `jmap -histo` have different behavior about the option of `parallel`, that is, `heapdump` does not use it and `heaphisto` does.
> 
> And just to further clarify, the parallel support for `jmap -histo` is already in JDK 16, which is one reason we were swayed towards including it with `jmap -dump`. If we didn't we were thinking in order to be consistent we would need to pull the parallel support for `jmap -histo`, which would be somewhat problematic since it will already have shipped in 16. However, given that these are really two different commands, and we have some good arguments for not including parallel support for `jmap -dump`, I can see leaving it out.
> 
>> * If we decide to not introduce the `parallel` option, we don't need to introduce the `heapdumpext` attach api command, so the 2 CSRs related to this PR could be closed. But this may leave the argument count problem to future, when more argumebts is introduced, is this acceptable?
> 
> Yes, and in fact I would argue that we should not be doing the `heapdumpext` solution now if we no longer have a need for it.
> 
>> * if we decide to introduce `parallel=<N>` option, do we need to add explaination in the document? or docs like tuning guide?
> 
> Which document were you thinking? Is the turning guide a hotspot tuning guide? If so, I don't think that's the right place for it. The focus should be in any jmap documentation.
> 
> And to add a 4th bullet item to your list, we also have the `GC.heap_dump` jcmd. I think there as a CR and CSR to add parallel support to it (but honestly I've lost track). If we choose not to include parallel support for `jmap -dump`, I think we should exclude it from `GC.heap_dump` also.

Hi Chris, 
Thanks for your comments!

So I think we agree on keep `parallel=N` option for hitogram to keep it as JDK16 and not use it for heapdump. I will close related CSR and revert related codes.

> Yes, and in fact I would argue that we should not be doing the heapdumpext solution now if we no longer have a need for it.

Agree, at least I don't have any idea for adding new features that require new options

> Which document were you thinking? Is the turning guide a hotspot tuning guide? If so, I don't think that's the right place for it. The focus should be in any jmap documentation.

I was thinking of the tuning guide. but it seems even there is explaination of the parallel implementation of heap dump, it is hard to do tuning...

> And to add a 4th bullet item to your list, we also have the `GC.heap_dump` jcmd. I think there as a CR and CSR to add parallel support to it (but honestly I've lost track). If we choose not to include parallel support for `jmap -dump`, I think we should exclude it from `GC.heap_dump` also.

There are CSRs created for the parallel option for GC.class_histogram, the one for GC.heap_dump is not created yet (or I cannot find one)

Thanks,
Lin

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From rehn at openjdk.java.net  Mon Mar 22 09:05:01 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Mon, 22 Mar 2021 09:05:01 GMT
Subject: RFR: 8262881: port JVM/DI tests from JDK-4413752 to JVM/TI [v2]
In-Reply-To: <FTPu45SOPngFqXyPfuBhBewCMrOKmxVWMM1c5shSAk0=.f2ae0a1f-d047-4e38-9646-973cea5d14bd@github.com>
References: <XOECrKnBcmSRjfY2cM-GqFs3jMr0fTy7KJUCUHZ0HGw=.54872a68-97e9-481a-871e-eade80a51604@github.com>
 <pIS66umBFPY0bsix6EW_zdVNzFG5J6A33FHVrpvEJ64=.c3cc75d9-25cd-4fc0-b3bc-35fe628d5e2c@github.com>
 <FTPu45SOPngFqXyPfuBhBewCMrOKmxVWMM1c5shSAk0=.f2ae0a1f-d047-4e38-9646-973cea5d14bd@github.com>
Message-ID: <mt28C9CCpgvEssnL1Wo548FPnwpC3dkZlNlUy8IswcQ=.b0b9439a-7dbd-4fb7-b634-cad50617f38b@github.com>

On Fri, 19 Mar 2021 20:16:29 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Hi Dan,
>> It is interesting how much these tests were changed when ported.
>> A couple of indent-related comments.
>> There are incorrect indents in the following lines in all .cpp files:
>>  ```
>> 68 Java_SuspendWithObjectMonitorEnter_GetResult(JNIEnv *env, jclass cls) {
>>  69     return iGlobalStatus;
>>  70 }
>>   72 JNIEXPORT void JNICALL
>>  73 Java_SuspendWithObjectMonitorEnter_SetPrintDebug(JNIEnv *env, jclass cls) {
>>  74     printdebug = 1;
>>  75 }
>>  97 Java_SuspendWithObjectMonitorEnterWorker_GetPrintDebug(JNIEnv *env, jclass cls) {
>>  98     return printdebug;
>>  99 }
>> 
>> Thanks,
>> Serguei
>
> @sspitsyn - Thanks for the review! I figured you would enjoy this 20 year old
> blast from the past! I'm tempted to ping @karenkinnear just to see if she'll
> remember these tests!
> 
> I'll fix the indents in the .cpp files. Right now I'm using these tests to shake
> out @robehn's work on "JDK-8257831 Suspend with handshakes".

Hi Dan,

If you change the native methods, e.g. :
native static void RawMonitorEnter(int id);
To something like:
native static int RawMonitorEnter();

You can then handle the jvmti error in the Java code, so you don't need to pass down the 'id' of the thread.
You then remove all debug code from the C-code agent, which removes some native methods also.
Which also leads to that you don't need  the thread 'id', instead you can just use the thread name, which removes some Java code.

Also you shouldn't catch the UnsatisfiedLinkError, as docs also says: "An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch."

You also have a lot of code for argument parsing which is not used by the test inside the test methods.
Can you either remove that or if you want it put it in a separate class/method, so e.g. "doWork()" takes parsed arguments instead.

Thanks, Robbin

-------------

PR: https://git.openjdk.java.net/jdk/pull/2899

From lzang at openjdk.java.net  Mon Mar 22 09:48:09 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 22 Mar 2021 09:48:09 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v17]
In-Reply-To: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
Message-ID: <sUbGpKaPD8xvhYtOb82L1PPdzbcKcKLkc1PnJAzTJqo=.bc90a3d5-47c7-4e41-82ef-211f31ad0d72@github.com>

> 8252842: Extend jmap to support parallel heap dump

Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - resize large object threshold
 - Merge branch 'master' into par-dump
 - Merge branch 'master' into par-dump
 - code clean
 - fix trailing white space issue
 - reduce memory consumption and fix memory leak issue
 - Revise jmap help info
 - Merge master
 - fix build fail issue on windows
 - hide the dumpheapext error message
 - ... and 10 more: https://git.openjdk.java.net/jdk/compare/d2144a5b...f0c8a6eb

-------------

Changes: https://git.openjdk.java.net/jdk/pull/2261/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=16
  Stats: 996 lines in 6 files changed: 796 ins; 58 del; 142 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2261.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2261/head:pull/2261

PR: https://git.openjdk.java.net/jdk/pull/2261

From kevinw at openjdk.java.net  Mon Mar 22 11:30:45 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Mon, 22 Mar 2021 11:30:45 GMT
Subject: RFR: 8263895: Test
 nsk/jvmti/GetThreadGroupChildren/getthrdgrpchld001/getthrdgrpchld001.cpp uses
 incorrect indices [v2]
In-Reply-To: <R1YbXvN76LLc7aqagS6O6aRjiATSwGS2B1qCfEsb2vg=.dae2982a-90f3-418c-9452-5c31b21308de@github.com>
References: <hUFzfiR5CfIVjDpxAaM5GVhqVzDhrhakVqSU5YRIxVg=.ce231115-3b9c-4244-b19f-300b719bef10@github.com>
 <R1YbXvN76LLc7aqagS6O6aRjiATSwGS2B1qCfEsb2vg=.dae2982a-90f3-418c-9452-5c31b21308de@github.com>
Message-ID: <YGfnb9CgOboIsEmwr0z34Q6FiTXbbYC03v3ewVK4aaQ=.862eec98-703a-47b3-bace-f2c6e9e55faa@github.com>

On Sat, 20 Mar 2021 03:00:52 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> 8263895: Test nsk/jvmti/GetThreadGroupChildren/getthrdgrpchld001/getthrdgrpchld001.cpp uses incorrect indices
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright updated.

Marked as reviewed by kevinw (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3098

From kevinw at openjdk.java.net  Mon Mar 22 11:35:41 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Mon, 22 Mar 2021 11:35:41 GMT
Subject: RFR: 8176026: SA: Huge heap sizes cause a negative value to be
 displayed in the jhisto heap total
In-Reply-To: <h_pqXvxIEJRhxH3sEA5fO8Z1XidOU3aZZij_ZVUx1kw=.1cf3982e-7dac-4d2d-80a0-9629eb50c203@github.com>
References: <h_pqXvxIEJRhxH3sEA5fO8Z1XidOU3aZZij_ZVUx1kw=.1cf3982e-7dac-4d2d-80a0-9629eb50c203@github.com>
Message-ID: <FCB0OYVfhteyHjRM9BSH0dUOQfcFrM3wsIgwqzbboCI=.2cf05f73-01b9-4260-b3c5-0da6e8bda3ee@github.com>

On Fri, 19 Mar 2021 11:49:39 GMT, Koichi Sakata <ksakata at openjdk.org> wrote:

> When a heap is used more than about 2.1GB, clhsdb jhisto shows a negative number in the total field.
> 
> $ java -Xmx20g Sample
> 
> $ jhsdb clhsdb --pid 5773
> Attaching to process 5773, please wait...
> hsdb> jhisto
> ...
> 299:            1       16      jdk.internal.misc.Unsafe
> 300:            3402    10737610256     byte[]
> Total :         15823   -2146661280
> Heap traversal took 1.793 seconds.
> (Incidentally, the Sample is a program that only allocates many objects.)
> 
> #### Details
> This is because in ObjectHistogram class the totalSize variable is int type.
> 
> The total size is the total of ObjectHistogramElement#getSize() and getSize() returns long. So I changed int to long in the ObjectHistogram class.
> 
> Additionally, I changed the type of the totalCount. This doesn't cause a bug, but ObjectHistogramElement#getCount() also returns long. So it doesn't need to treat it as int, I think.
> 
> #### Tests
> The jtreg test was successful.
> $ sudo make run-test TEST=serviceability/sa/ClhsdbJhisto.java
> 
> $ cat build/linux-x86_64-server-fastdebug/test-results/jtreg_test_hotspot_jtreg_serviceability_sa_ClhsdbJhisto_java/text/summary.txt
> serviceability/sa/ClhsdbJhisto.java  Passed. Execution successful
> 
> I confirmed the output with the same program.
> 
> $ ./jdk/build/linux-x86_64-server-fastdebug/jdk/bin/java -Xmx20g Sample
> $ ./jdk/build/linux-x86_64-server-fastdebug/jdk/bin/jhsdb clhsdb --pid 22463
> Attaching to process 22463, please wait...
> hsdb> jhisto
> 
> 300:            3410    19327547600     byte[]
> Total :         16145   19328155080
> Heap traversal took 1.981 seconds.

Marked as reviewed by kevinw (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3087

From aefimov at openjdk.java.net  Mon Mar 22 12:16:40 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Mon, 22 Mar 2021 12:16:40 GMT
Subject: RFR: 8263855: Use the blessed modifier order in
 java.management/naming [v2]
In-Reply-To: <6ITH9DKMFtUme7hcRYi9iw8SZgF6d9jE_OJfjtfGsPI=.5c05ae45-f88c-4abf-9786-8520f66f2ab5@github.com>
References: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>
 <6ITH9DKMFtUme7hcRYi9iw8SZgF6d9jE_OJfjtfGsPI=.5c05ae45-f88c-4abf-9786-8520f66f2ab5@github.com>
Message-ID: <o_BVfcyKADFKHvcuIpccL3UlxojhCklcVrG2MCHC0SY=.9be0d226-6ede-4360-a1b7-633bb6ebf97b@github.com>

On Fri, 19 Mar 2021 17:13:58 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

>> As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules.
>
> Alex Blewitt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added more replacements of 'final public' with 'public final'

`java.naming` module changes look good to me.

-------------

Marked as reviewed by aefimov (Committer).

PR: https://git.openjdk.java.net/jdk/pull/3078

From lzang at openjdk.java.net  Mon Mar 22 12:35:52 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 22 Mar 2021 12:35:52 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v18]
In-Reply-To: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
Message-ID: <fMCSwROv0RqaM7hs3ZZR0veUjagjo8hQ7O3iUS64vWs=.77a61291-4eae-406f-8d15-8990bf86085f@github.com>

> 8252842: Extend jmap to support parallel heap dump

Lin Zang has updated the pull request incrementally with two additional commits since the last revision:

 - remove parallel option and dumpheapext command
 - Revert "hide the dumpheapext error message"
   
   This reverts commit 1af0e1e2bfab4f5d079c03ff0cb25067acacdac4.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2261/files
  - new: https://git.openjdk.java.net/jdk/pull/2261/files/f0c8a6eb..4f221bd9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=17
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=16-17

  Stats: 138 lines in 2 files changed: 0 ins; 136 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2261.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2261/head:pull/2261

PR: https://git.openjdk.java.net/jdk/pull/2261

From akozlov at openjdk.java.net  Mon Mar 22 12:50:14 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 22 Mar 2021 12:50:14 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:

 - Merge branch 'master' into jdk-macos
 - JDK-8262491: bsd_aarch64 part
 - JDK-8263002: bsd_aarch64 part
 - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
 - Wider #ifdef block
 - Fix most of issues in java/foreign/ tests
   
   Failures related to va_args are tracked in JDK-8263512.
 - Add Azul copyright
 - Update Oracle copyright years
 - Use Thread::current_or_null_safe in SafeFetch
 - 8262903: [macos_aarch64] Thread::current() called on detached thread
 - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269

-------------

Changes: https://git.openjdk.java.net/jdk/pull/2200/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=28
  Stats: 2947 lines in 75 files changed: 2838 ins; 27 del; 82 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

PR: https://git.openjdk.java.net/jdk/pull/2200

From dfuchs at openjdk.java.net  Mon Mar 22 13:09:40 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 22 Mar 2021 13:09:40 GMT
Subject: RFR: 8263855: Use the blessed modifier order in
 java.management/naming [v2]
In-Reply-To: <6ITH9DKMFtUme7hcRYi9iw8SZgF6d9jE_OJfjtfGsPI=.5c05ae45-f88c-4abf-9786-8520f66f2ab5@github.com>
References: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>
 <6ITH9DKMFtUme7hcRYi9iw8SZgF6d9jE_OJfjtfGsPI=.5c05ae45-f88c-4abf-9786-8520f66f2ab5@github.com>
Message-ID: <QTMtp48vG2xbXUGjxEioHO3SemUybTwf4fWP3UgajA0=.92085ad2-a27b-47c8-a4a4-3c92fa65c8c2@github.com>

On Fri, 19 Mar 2021 17:13:58 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

>> As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules.
>
> Alex Blewitt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added more replacements of 'final public' with 'public final'

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3078

From github.com+76791+alblue at openjdk.java.net  Mon Mar 22 13:41:39 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Mon, 22 Mar 2021 13:41:39 GMT
Subject: Integrated: 8263855: Use the blessed modifier order in
 java.management/naming
In-Reply-To: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>
References: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>
Message-ID: <lOh9blbaBQM3sn-pNHzWhwpooqD8vj4DJ5uDL12gShg=.477d7f94-12a4-4ac2-a3aa-9dfab4499fee@github.com>

On Thu, 18 Mar 2021 18:26:20 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules.

This pull request has now been integrated.

Changeset: 5262d95b
Author:    Alex Blewitt <alex.blewitt at gmail.com>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5262d95b
Stats:     261 lines in 69 files changed: 0 ins; 0 del; 261 mod

8263855: Use the blessed modifier order in java.management/naming

Reviewed-by: redestad, aefimov, dfuchs

-------------

PR: https://git.openjdk.java.net/jdk/pull/3078

From dcubed at openjdk.java.net  Mon Mar 22 14:25:39 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 22 Mar 2021 14:25:39 GMT
Subject: RFR: 8262881: port JVM/DI tests from JDK-4413752 to JVM/TI [v2]
In-Reply-To: <mt28C9CCpgvEssnL1Wo548FPnwpC3dkZlNlUy8IswcQ=.b0b9439a-7dbd-4fb7-b634-cad50617f38b@github.com>
References: <XOECrKnBcmSRjfY2cM-GqFs3jMr0fTy7KJUCUHZ0HGw=.54872a68-97e9-481a-871e-eade80a51604@github.com>
 <pIS66umBFPY0bsix6EW_zdVNzFG5J6A33FHVrpvEJ64=.c3cc75d9-25cd-4fc0-b3bc-35fe628d5e2c@github.com>
 <FTPu45SOPngFqXyPfuBhBewCMrOKmxVWMM1c5shSAk0=.f2ae0a1f-d047-4e38-9646-973cea5d14bd@github.com>
 <mt28C9CCpgvEssnL1Wo548FPnwpC3dkZlNlUy8IswcQ=.b0b9439a-7dbd-4fb7-b634-cad50617f38b@github.com>
Message-ID: <N2ttOL2H2afquWau8ZwL41-V1XapL9O7HoZvIuPw7UA=.073dac9f-ba95-4caf-950f-f0576e93732f@github.com>

On Mon, 22 Mar 2021 09:02:02 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> @sspitsyn - Thanks for the review! I figured you would enjoy this 20 year old
>> blast from the past! I'm tempted to ping @karenkinnear just to see if she'll
>> remember these tests!
>> 
>> I'll fix the indents in the .cpp files. Right now I'm using these tests to shake
>> out @robehn's work on "JDK-8257831 Suspend with handshakes".
>
> Hi Dan,
> 
> If you change the native methods, e.g. :
> native static void RawMonitorEnter(int id);
> To something like:
> native static int RawMonitorEnter();
> 
> You can then handle the jvmti error in the Java code, so you don't need to pass down the 'id' of the thread.
> You then remove all debug code from the C-code agent, which removes some native methods also.
> Which also leads to that you don't need  the thread 'id', instead you can just use the thread name, which removes some Java code.
> 
> Also you shouldn't catch the UnsatisfiedLinkError, as docs also says: "An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch."
> 
> You also have a lot of code for argument parsing which is not used by the test inside the test methods.
> Can you either remove that or if you want it put it in a separate class/method, so e.g. "doWork()" takes parsed arguments instead.
> 
> Thanks, Robbin

@robehn - Thanks for the review and for the suggested improvements to the tests.
It will take me a bit of time to make and test these suggestions.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2899

From coleenp at openjdk.java.net  Mon Mar 22 15:55:58 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 22 Mar 2021 15:55:58 GMT
Subject: RFR: 8263976: Remove block allocation from BasicHashtable
Message-ID: <ZkxFGxje18XFb3qVxeUqtcv1Y_Hi4SpeILatMXo-vzY=.c69c035d-80c7-4715-be45-c5d0d7f61b33@github.com>

>From CR:
The useful/general BasicHashtable uses a block allocation scheme to reportedly reduce fragmentation. When the StringTable and SymbolTable used to use this hashtable, performance benefits were reportedly observed because of the block allocation scheme. Since these tables were moved to the concurrent hashtables, the tables left that use the block allocation scheme are:

AdapterHandlerLibrary, ResolutionError, LoaderConstraints, Leak profiler bitset table and Placeholders. 3 of these tables are very small and never needed block allocation to prevent fragmentation at least. Also there are 3 KVHashtables, which are built from BasicHashtable. 2 are used during dumping and 1 is ID2KlassTable which appears small.

ModuleEntry, PackageEntry, Dictionary, G1RootSet for nmethods, and JvmtiTagMap tables didn't use the block allocation scheme.

Removing this removes 7 pointers per table, and for each ClassLoaderData, which has 3 tables, removes 21 pointers.

This change was performance tested on linux and windows.

It was also tested with tier1-6.

-------------

Commit messages:
 - 8263976: Remove block allocation from BasicHashtable

Changes: https://git.openjdk.java.net/jdk/pull/3123/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3123&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263976
  Stats: 169 lines in 16 files changed: 17 ins; 122 del; 30 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3123.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3123/head:pull/3123

PR: https://git.openjdk.java.net/jdk/pull/3123

From coleenp at openjdk.java.net  Mon Mar 22 16:56:41 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 22 Mar 2021 16:56:41 GMT
Subject: RFR: 8263976: Remove block allocation from BasicHashtable
In-Reply-To: <ZkxFGxje18XFb3qVxeUqtcv1Y_Hi4SpeILatMXo-vzY=.c69c035d-80c7-4715-be45-c5d0d7f61b33@github.com>
References: <ZkxFGxje18XFb3qVxeUqtcv1Y_Hi4SpeILatMXo-vzY=.c69c035d-80c7-4715-be45-c5d0d7f61b33@github.com>
Message-ID: <FAZxth_T6NvAqWgFl-R_Q7ZvlIHOBcI8TzQ9YRnquYE=.d77cecb7-980f-4cbc-b869-994d06895774@github.com>

On Mon, 22 Mar 2021 15:49:24 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> From CR:
> The useful/general BasicHashtable uses a block allocation scheme to reportedly reduce fragmentation. When the StringTable and SymbolTable used to use this hashtable, performance benefits were reportedly observed because of the block allocation scheme. Since these tables were moved to the concurrent hashtables, the tables left that use the block allocation scheme are:
> 
> AdapterHandlerLibrary, ResolutionError, LoaderConstraints, Leak profiler bitset table and Placeholders. 3 of these tables are very small and never needed block allocation to prevent fragmentation at least. Also there are 3 KVHashtables, which are built from BasicHashtable. 2 are used during dumping and 1 is ID2KlassTable which appears small.
> 
> ModuleEntry, PackageEntry, Dictionary, G1RootSet for nmethods, and JvmtiTagMap tables didn't use the block allocation scheme.
> 
> Removing this removes 7 pointers per table, and for each ClassLoaderData, which has 3 tables, removes 21 pointers.
> 
> This change was performance tested on linux and windows.
> 
> It was also tested with tier1-6.

I forgot to add that we can eventually replace these tables with std::unordered_set once the allocation and other template parameters are decided on.  There are also other cleanups that we could do with this code, ie. Hashtable isn't that different from BasicHashtable so really isn't needed. We could make the Entry type a template parameter.  This change is only a step in this direction.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3123

From lmesnik at openjdk.java.net  Mon Mar 22 18:00:40 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Mon, 22 Mar 2021 18:00:40 GMT
Subject: Integrated: 8263895: Test
 nsk/jvmti/GetThreadGroupChildren/getthrdgrpchld001/getthrdgrpchld001.cpp uses
 incorrect indices
In-Reply-To: <hUFzfiR5CfIVjDpxAaM5GVhqVzDhrhakVqSU5YRIxVg=.ce231115-3b9c-4244-b19f-300b719bef10@github.com>
References: <hUFzfiR5CfIVjDpxAaM5GVhqVzDhrhakVqSU5YRIxVg=.ce231115-3b9c-4244-b19f-300b719bef10@github.com>
Message-ID: <n9j_3AzNTNCwYIO2lqvSjwqBhky0KxpRImHFECgDp8M=.c42462ff-d0f4-4383-b106-e99d4bc86692@github.com>

On Fri, 19 Mar 2021 22:20:35 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> 8263895: Test nsk/jvmti/GetThreadGroupChildren/getthrdgrpchld001/getthrdgrpchld001.cpp uses incorrect indices

This pull request has now been integrated.

Changeset: f62b1008
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f62b1008
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8263895: Test nsk/jvmti/GetThreadGroupChildren/getthrdgrpchld001/getthrdgrpchld001.cpp uses incorrect indices

Reviewed-by: amenkov, kevinw

-------------

PR: https://git.openjdk.java.net/jdk/pull/3098

From lfoltan at openjdk.java.net  Mon Mar 22 20:45:40 2021
From: lfoltan at openjdk.java.net (Lois Foltan)
Date: Mon, 22 Mar 2021 20:45:40 GMT
Subject: RFR: 8263976: Remove block allocation from BasicHashtable
In-Reply-To: <ZkxFGxje18XFb3qVxeUqtcv1Y_Hi4SpeILatMXo-vzY=.c69c035d-80c7-4715-be45-c5d0d7f61b33@github.com>
References: <ZkxFGxje18XFb3qVxeUqtcv1Y_Hi4SpeILatMXo-vzY=.c69c035d-80c7-4715-be45-c5d0d7f61b33@github.com>
Message-ID: <m4syZcnIPldbeSrByXJzabCiNO6GN1JT-nuSofAAzes=.8f2f6e4a-e81e-4ed9-8b90-a53c839015f2@github.com>

On Mon, 22 Mar 2021 15:49:24 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> From CR:
> The useful/general BasicHashtable uses a block allocation scheme to reportedly reduce fragmentation. When the StringTable and SymbolTable used to use this hashtable, performance benefits were reportedly observed because of the block allocation scheme. Since these tables were moved to the concurrent hashtables, the tables left that use the block allocation scheme are:
> 
> AdapterHandlerLibrary, ResolutionError, LoaderConstraints, Leak profiler bitset table and Placeholders. 3 of these tables are very small and never needed block allocation to prevent fragmentation at least. Also there are 3 KVHashtables, which are built from BasicHashtable. 2 are used during dumping and 1 is ID2KlassTable which appears small.
> 
> ModuleEntry, PackageEntry, Dictionary, G1RootSet for nmethods, and JvmtiTagMap tables didn't use the block allocation scheme.
> 
> Removing this removes 7 pointers per table, and for each ClassLoaderData, which has 3 tables, removes 21 pointers.
> 
> This change was performance tested on linux and windows.
> 
> It was also tested with tier1-6.

Great clean up Coleen!  ModuleEntryTable and PackageEntryTable changes looks good as does the other changes as well.
Lois

-------------

Marked as reviewed by lfoltan (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3123

From iklam at openjdk.java.net  Mon Mar 22 21:57:41 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 22 Mar 2021 21:57:41 GMT
Subject: RFR: 8263976: Remove block allocation from BasicHashtable
In-Reply-To: <ZkxFGxje18XFb3qVxeUqtcv1Y_Hi4SpeILatMXo-vzY=.c69c035d-80c7-4715-be45-c5d0d7f61b33@github.com>
References: <ZkxFGxje18XFb3qVxeUqtcv1Y_Hi4SpeILatMXo-vzY=.c69c035d-80c7-4715-be45-c5d0d7f61b33@github.com>
Message-ID: <SLKd2-TUbTkTfl7u8PcbocY2N6f-BGPKDHxsFBHtCIg=.02e01d1a-5c98-4517-8303-71f96fe41fb1@github.com>

On Mon, 22 Mar 2021 15:49:24 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> From CR:
> The useful/general BasicHashtable uses a block allocation scheme to reportedly reduce fragmentation. When the StringTable and SymbolTable used to use this hashtable, performance benefits were reportedly observed because of the block allocation scheme. Since these tables were moved to the concurrent hashtables, the tables left that use the block allocation scheme are:
> 
> AdapterHandlerLibrary, ResolutionError, LoaderConstraints, Leak profiler bitset table and Placeholders. 3 of these tables are very small and never needed block allocation to prevent fragmentation at least. Also there are 3 KVHashtables, which are built from BasicHashtable. 2 are used during dumping and 1 is ID2KlassTable which appears small.
> 
> ModuleEntry, PackageEntry, Dictionary, G1RootSet for nmethods, and JvmtiTagMap tables didn't use the block allocation scheme.
> 
> Removing this removes 7 pointers per table, and for each ClassLoaderData, which has 3 tables, removes 21 pointers.
> 
> This change was performance tested on linux and windows.
> 
> It was also tested with tier1-6.

Looks good overall. Just some small nits.

src/hotspot/share/utilities/hashtable.cpp line 54:

> 52:   BasicHashtableEntry<F>* entry = ::new (NEW_C_HEAP_ARRAY(char, this->entry_size(), F))
> 53:                                         BasicHashtableEntry<F>(hashValue);
> 54:   assert(_entry_size % HeapWordSize == 0, "");

Is this assert still needed? What's its purpose?

src/hotspot/share/utilities/hashtable.cpp line 64:

> 62: 
> 63:   if (DumpSharedSpaces) {
> 64:     // Avoid random bits in structure padding so we can have deterministic content in CDS archive

Hmm, the sequence looks a little odd: the constructor initializes some fields, they are then zeroed here, and then initialized again below ....

Actually, I think you can get rid of the `if (DumpSharedSpaces)` block for now. I am not sure if it's needed. Deterministic CDS archive is broken anyway (https://bugs.openjdk.java.net/browse/JDK-8253495).

That way you can get rid of the entry->set_xxx below as well.

-------------

Changes requested by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3123

From coleenp at openjdk.java.net  Mon Mar 22 21:57:43 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 22 Mar 2021 21:57:43 GMT
Subject: RFR: 8263976: Remove block allocation from BasicHashtable
In-Reply-To: <SLKd2-TUbTkTfl7u8PcbocY2N6f-BGPKDHxsFBHtCIg=.02e01d1a-5c98-4517-8303-71f96fe41fb1@github.com>
References: <ZkxFGxje18XFb3qVxeUqtcv1Y_Hi4SpeILatMXo-vzY=.c69c035d-80c7-4715-be45-c5d0d7f61b33@github.com>
 <SLKd2-TUbTkTfl7u8PcbocY2N6f-BGPKDHxsFBHtCIg=.02e01d1a-5c98-4517-8303-71f96fe41fb1@github.com>
Message-ID: <tc9ul_NXsykXe8UH0BZNoMi41yAsA3LE3eTzOWnReHw=.48ab1a64-17c6-4aa2-ad9c-bf5650e8f622@github.com>

On Mon, 22 Mar 2021 21:42:51 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> From CR:
>> The useful/general BasicHashtable uses a block allocation scheme to reportedly reduce fragmentation. When the StringTable and SymbolTable used to use this hashtable, performance benefits were reportedly observed because of the block allocation scheme. Since these tables were moved to the concurrent hashtables, the tables left that use the block allocation scheme are:
>> 
>> AdapterHandlerLibrary, ResolutionError, LoaderConstraints, Leak profiler bitset table and Placeholders. 3 of these tables are very small and never needed block allocation to prevent fragmentation at least. Also there are 3 KVHashtables, which are built from BasicHashtable. 2 are used during dumping and 1 is ID2KlassTable which appears small.
>> 
>> ModuleEntry, PackageEntry, Dictionary, G1RootSet for nmethods, and JvmtiTagMap tables didn't use the block allocation scheme.
>> 
>> Removing this removes 7 pointers per table, and for each ClassLoaderData, which has 3 tables, removes 21 pointers.
>> 
>> This change was performance tested on linux and windows.
>> 
>> It was also tested with tier1-6.
>
> src/hotspot/share/utilities/hashtable.cpp line 54:
> 
>> 52:   BasicHashtableEntry<F>* entry = ::new (NEW_C_HEAP_ARRAY(char, this->entry_size(), F))
>> 53:                                         BasicHashtableEntry<F>(hashValue);
>> 54:   assert(_entry_size % HeapWordSize == 0, "");
> 
> Is this assert still needed? What's its purpose?

Yeah, seems a bit strange.  Of course the entry is a heapword size.  I'll remove the assert.

> src/hotspot/share/utilities/hashtable.cpp line 64:
> 
>> 62: 
>> 63:   if (DumpSharedSpaces) {
>> 64:     // Avoid random bits in structure padding so we can have deterministic content in CDS archive
> 
> Hmm, the sequence looks a little odd: the constructor initializes some fields, they are then zeroed here, and then initialized again below ....
> 
> Actually, I think you can get rid of the `if (DumpSharedSpaces)` block for now. I am not sure if it's needed. Deterministic CDS archive is broken anyway (https://bugs.openjdk.java.net/browse/JDK-8253495).
> 
> That way you can get rid of the entry->set_xxx below as well.

Yes, I'd like to make the constructors initialize the fields, but didn't know what to do about this block zeroing code.  Would you have to add it back with deterministic GC?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3123

From iklam at openjdk.java.net  Mon Mar 22 22:00:43 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 22 Mar 2021 22:00:43 GMT
Subject: RFR: 8263976: Remove block allocation from BasicHashtable
In-Reply-To: <tc9ul_NXsykXe8UH0BZNoMi41yAsA3LE3eTzOWnReHw=.48ab1a64-17c6-4aa2-ad9c-bf5650e8f622@github.com>
References: <ZkxFGxje18XFb3qVxeUqtcv1Y_Hi4SpeILatMXo-vzY=.c69c035d-80c7-4715-be45-c5d0d7f61b33@github.com>
 <SLKd2-TUbTkTfl7u8PcbocY2N6f-BGPKDHxsFBHtCIg=.02e01d1a-5c98-4517-8303-71f96fe41fb1@github.com>
 <tc9ul_NXsykXe8UH0BZNoMi41yAsA3LE3eTzOWnReHw=.48ab1a64-17c6-4aa2-ad9c-bf5650e8f622@github.com>
Message-ID: <WgX0YQJERjMs1lUj2Qw4xTjzrU7gyyat18Qbf7kJX-U=.a42506b2-7511-4369-9c0b-8bc4fbaba305@github.com>

On Mon, 22 Mar 2021 21:54:23 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/utilities/hashtable.cpp line 64:
>> 
>>> 62: 
>>> 63:   if (DumpSharedSpaces) {
>>> 64:     // Avoid random bits in structure padding so we can have deterministic content in CDS archive
>> 
>> Hmm, the sequence looks a little odd: the constructor initializes some fields, they are then zeroed here, and then initialized again below ....
>> 
>> Actually, I think you can get rid of the `if (DumpSharedSpaces)` block for now. I am not sure if it's needed. Deterministic CDS archive is broken anyway (https://bugs.openjdk.java.net/browse/JDK-8253495).
>> 
>> That way you can get rid of the entry->set_xxx below as well.
>
> Yes, I'd like to make the constructors initialize the fields, but didn't know what to do about this block zeroing code.  Would you have to add it back with deterministic GC?

> Yes, I'd like to make the constructors initialize the fields, but didn't know what to do about this block zeroing code. Would you have to add it back with deterministic CDS?

I am not sure yet. I think we may not need it because CDS doesn't copy HashtableEntries into the archive anymore.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3123

From amenkov at openjdk.java.net  Mon Mar 22 22:02:48 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Mon, 22 Mar 2021 22:02:48 GMT
Subject: RFR: 8262081:
 vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter001/TestDescription.java
 failed with "ERROR: eventSet1.size() != 3 :: 2"
Message-ID: <-WEaFWU7bEOckY-ltHYclBwZMbgrKw5ye8TaZ7cryn4=.2ef514f2-9881-400b-b53f-fc1b3465b177@github.com>

The fix updates the test to use special method to wait for ThreadDeathEvent for the specific thread, ignoring event from other threads

-------------

Commit messages:
 - Filter out events from unexpected threads

Changes: https://git.openjdk.java.net/jdk/pull/3133/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3133&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262081
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3133.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3133/head:pull/3133

PR: https://git.openjdk.java.net/jdk/pull/3133

From coleenp at openjdk.java.net  Mon Mar 22 22:03:38 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 22 Mar 2021 22:03:38 GMT
Subject: RFR: 8263976: Remove block allocation from BasicHashtable
In-Reply-To: <WgX0YQJERjMs1lUj2Qw4xTjzrU7gyyat18Qbf7kJX-U=.a42506b2-7511-4369-9c0b-8bc4fbaba305@github.com>
References: <ZkxFGxje18XFb3qVxeUqtcv1Y_Hi4SpeILatMXo-vzY=.c69c035d-80c7-4715-be45-c5d0d7f61b33@github.com>
 <SLKd2-TUbTkTfl7u8PcbocY2N6f-BGPKDHxsFBHtCIg=.02e01d1a-5c98-4517-8303-71f96fe41fb1@github.com>
 <tc9ul_NXsykXe8UH0BZNoMi41yAsA3LE3eTzOWnReHw=.48ab1a64-17c6-4aa2-ad9c-bf5650e8f622@github.com>
 <WgX0YQJERjMs1lUj2Qw4xTjzrU7gyyat18Qbf7kJX-U=.a42506b2-7511-4369-9c0b-8bc4fbaba305@github.com>
Message-ID: <_BbDo3ko5RZXjFskK5vat6YiY9_80_h9uiY3cJqmNd4=.384b4792-1690-4e99-a8ec-cae1a23ef39e@github.com>

On Mon, 22 Mar 2021 21:58:09 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Yes, I'd like to make the constructors initialize the fields, but didn't know what to do about this block zeroing code.  Would you have to add it back with deterministic GC?
>
>> Yes, I'd like to make the constructors initialize the fields, but didn't know what to do about this block zeroing code. Would you have to add it back with deterministic CDS?
> 
> I am not sure yet. I think we may not need it because CDS doesn't copy HashtableEntries into the archive anymore.

Instead of block zeroing hashtableEntry, you could add a field to zero in between _hash and _next and that would not have stray unaligned bytes.
template <MEMFLAGS F> class BasicHashtableEntry {
  friend class VMStructs;
private:
  unsigned int         _hash;           // 32-bit hash for item

  // Link to next element in the linked list for this bucket.
  BasicHashtableEntry<F>* _next;

-------------

PR: https://git.openjdk.java.net/jdk/pull/3123

From coleenp at openjdk.java.net  Mon Mar 22 22:48:05 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 22 Mar 2021 22:48:05 GMT
Subject: RFR: 8263976: Remove block allocation from BasicHashtable [v2]
In-Reply-To: <ZkxFGxje18XFb3qVxeUqtcv1Y_Hi4SpeILatMXo-vzY=.c69c035d-80c7-4715-be45-c5d0d7f61b33@github.com>
References: <ZkxFGxje18XFb3qVxeUqtcv1Y_Hi4SpeILatMXo-vzY=.c69c035d-80c7-4715-be45-c5d0d7f61b33@github.com>
Message-ID: <27GM9pmZuaikjHuuvXVRYgOPnTqMxNOXhd1CR7BzaKo=.ab0ec842-335c-4c85-807b-dc6bcb6b77e3@github.com>

> From CR:
> The useful/general BasicHashtable uses a block allocation scheme to reportedly reduce fragmentation. When the StringTable and SymbolTable used to use this hashtable, performance benefits were reportedly observed because of the block allocation scheme. Since these tables were moved to the concurrent hashtables, the tables left that use the block allocation scheme are:
> 
> AdapterHandlerLibrary, ResolutionError, LoaderConstraints, Leak profiler bitset table and Placeholders. 3 of these tables are very small and never needed block allocation to prevent fragmentation at least. Also there are 3 KVHashtables, which are built from BasicHashtable. 2 are used during dumping and 1 is ID2KlassTable which appears small.
> 
> ModuleEntry, PackageEntry, Dictionary, G1RootSet for nmethods, and JvmtiTagMap tables didn't use the block allocation scheme.
> 
> Removing this removes 7 pointers per table, and for each ClassLoaderData, which has 3 tables, removes 21 pointers.
> 
> This change was performance tested on linux and windows.
> 
> It was also tested with tier1-6.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix Hashtable constructor and comments.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3123/files
  - new: https://git.openjdk.java.net/jdk/pull/3123/files/328f72c5..7a0ad9ee

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3123&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3123&range=00-01

  Stats: 20 lines in 2 files changed: 0 ins; 16 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3123.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3123/head:pull/3123

PR: https://git.openjdk.java.net/jdk/pull/3123

From iklam at openjdk.java.net  Mon Mar 22 23:10:40 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 22 Mar 2021 23:10:40 GMT
Subject: RFR: 8263976: Remove block allocation from BasicHashtable [v2]
In-Reply-To: <27GM9pmZuaikjHuuvXVRYgOPnTqMxNOXhd1CR7BzaKo=.ab0ec842-335c-4c85-807b-dc6bcb6b77e3@github.com>
References: <ZkxFGxje18XFb3qVxeUqtcv1Y_Hi4SpeILatMXo-vzY=.c69c035d-80c7-4715-be45-c5d0d7f61b33@github.com>
 <27GM9pmZuaikjHuuvXVRYgOPnTqMxNOXhd1CR7BzaKo=.ab0ec842-335c-4c85-807b-dc6bcb6b77e3@github.com>
Message-ID: <xx8pgLmlXYVJ0u-15IAwrB31QifUKt48UtyKlrQEfUk=.c0273068-32b3-4d04-9414-dd303880f8ad@github.com>

On Mon, 22 Mar 2021 22:48:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> From CR:
>> The useful/general BasicHashtable uses a block allocation scheme to reportedly reduce fragmentation. When the StringTable and SymbolTable used to use this hashtable, performance benefits were reportedly observed because of the block allocation scheme. Since these tables were moved to the concurrent hashtables, the tables left that use the block allocation scheme are:
>> 
>> AdapterHandlerLibrary, ResolutionError, LoaderConstraints, Leak profiler bitset table and Placeholders. 3 of these tables are very small and never needed block allocation to prevent fragmentation at least. Also there are 3 KVHashtables, which are built from BasicHashtable. 2 are used during dumping and 1 is ID2KlassTable which appears small.
>> 
>> ModuleEntry, PackageEntry, Dictionary, G1RootSet for nmethods, and JvmtiTagMap tables didn't use the block allocation scheme.
>> 
>> Removing this removes 7 pointers per table, and for each ClassLoaderData, which has 3 tables, removes 21 pointers.
>> 
>> This change was performance tested on linux and windows.
>> 
>> It was also tested with tier1-6.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Hashtable constructor and comments.

Marked as reviewed by iklam (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3123

From minqi at openjdk.java.net  Mon Mar 22 23:32:05 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Mon, 22 Mar 2021 23:32:05 GMT
Subject: RFR: 8259070: Add jcmd option to dump CDS [v5]
In-Reply-To: <hwrc1zAz8G180ToL-C3EuUIF-5R17F5Gm1zcPMBpOtE=.e002a377-e0e2-485b-a08e-b63675a9746b@github.com>
References: <hwrc1zAz8G180ToL-C3EuUIF-5R17F5Gm1zcPMBpOtE=.e002a377-e0e2-485b-a08e-b63675a9746b@github.com>
Message-ID: <7MvNg06FGz8ZD3bUvH9FbCKYmqTX7V0XMUgh3jnQUwc=.0d011816-9758-4173-919c-00c45b203584@github.com>

> Hi, Please review
> 
>   Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with
>   `java -XX:DumpLoadedClassList=<classlist> .... `  
>  to collect shareable class names and saved in file `<classlist>` , then 
>   `java -Xshare:dump -XX:SharedClassListFile=<classlist> -XX:SharedArchiveFile=<archivefile> ...`
>   With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime  to dump an archive.
>    The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved.
>    New added jcmd option:
>    `jcmd <pid or AppName> VM.cds static_dump <filename>`
>    or
>     `jcmd <pid or AppName> VM.cds dynamic_dump <filename>`
>   To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. 
>    The file name is optional, if the file name is not supplied, the file name will take format of `java_pid<number>_static.jsa` or `java_pid<number>_dynamic.jsa` for static and dynamic respectively. The `<number>` is the application process ID.
> 
>   Tests: tier1,tier2,tier3,tier4
> 
> Thanks
> Yumin

Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:

  Fix according to review comment and add more tests

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2737/files
  - new: https://git.openjdk.java.net/jdk/pull/2737/files/a9010f8f..e882a074

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2737&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2737&range=03-04

  Stats: 142 lines in 7 files changed: 61 ins; 35 del; 46 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2737.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2737/head:pull/2737

PR: https://git.openjdk.java.net/jdk/pull/2737

From cjplummer at openjdk.java.net  Tue Mar 23 00:03:39 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 23 Mar 2021 00:03:39 GMT
Subject: RFR: 8262081:
 vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter001/TestDescription.java
 failed with "ERROR: eventSet1.size() != 3 :: 2"
In-Reply-To: <-WEaFWU7bEOckY-ltHYclBwZMbgrKw5ye8TaZ7cryn4=.2ef514f2-9881-400b-b53f-fc1b3465b177@github.com>
References: <-WEaFWU7bEOckY-ltHYclBwZMbgrKw5ye8TaZ7cryn4=.2ef514f2-9881-400b-b53f-fc1b3465b177@github.com>
Message-ID: <OywuIOHEIJhDboh6w8w1t8zQd-3GcpSNOrD04LvrBhc=.a6481bd8-e433-490b-b63a-ebb97ff506c7@github.com>

On Mon, 22 Mar 2021 21:56:01 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates the test to use special method to wait for ThreadDeathEvent for the specific thread, ignoring event from other threads

Marked as reviewed by cjplummer (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3133

From lmesnik at openjdk.java.net  Tue Mar 23 00:48:37 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 23 Mar 2021 00:48:37 GMT
Subject: RFR: 8262081:
 vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter001/TestDescription.java
 failed with "ERROR: eventSet1.size() != 3 :: 2"
In-Reply-To: <-WEaFWU7bEOckY-ltHYclBwZMbgrKw5ye8TaZ7cryn4=.2ef514f2-9881-400b-b53f-fc1b3465b177@github.com>
References: <-WEaFWU7bEOckY-ltHYclBwZMbgrKw5ye8TaZ7cryn4=.2ef514f2-9881-400b-b53f-fc1b3465b177@github.com>
Message-ID: <QqzbPPaB2zYiKHfFN-7kJkMdHmMDW6lQL3WG9J9IWY0=.fa292231-d0c8-4a91-9e03-27be9704b724@github.com>

On Mon, 22 Mar 2021 21:56:01 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates the test to use special method to wait for ThreadDeathEvent for the specific thread, ignoring event from other threads

Marked as reviewed by lmesnik (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3133

From coleenp at openjdk.java.net  Tue Mar 23 01:10:46 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 23 Mar 2021 01:10:46 GMT
Subject: RFR: 8264004: Don't use TRAPS if no exceptions are thrown
Message-ID: <1KBghJAnPzq1F4LTwaaa8sUTy-BiLlO4uXSmYC1XGPA=.46cc3327-0af0-409f-bf1a-07066c60b0de@github.com>

Removed the TRAPS in function declarations in jvmtiRedefineClasses and in ConstantPool merging functions.
Tested with vmTestbase/nsk/jvmti and tier1 (in progress).

-------------

Commit messages:
 - Don't pass TRAPS to functions that don't throw exceptions.

Changes: https://git.openjdk.java.net/jdk/pull/3141/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3141&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264004
  Stats: 179 lines in 4 files changed: 1 ins; 32 del; 146 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3141.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3141/head:pull/3141

PR: https://git.openjdk.java.net/jdk/pull/3141

From coleenp at openjdk.java.net  Tue Mar 23 01:22:56 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 23 Mar 2021 01:22:56 GMT
Subject: RFR: 8264004: Don't use TRAPS if no exceptions are thrown [v2]
In-Reply-To: <1KBghJAnPzq1F4LTwaaa8sUTy-BiLlO4uXSmYC1XGPA=.46cc3327-0af0-409f-bf1a-07066c60b0de@github.com>
References: <1KBghJAnPzq1F4LTwaaa8sUTy-BiLlO4uXSmYC1XGPA=.46cc3327-0af0-409f-bf1a-07066c60b0de@github.com>
Message-ID: <uYmLht5CfEs4CxvJQl5vCFBqoH5RitXnZY2lKG0Y7NM=.1c5b2fe2-9e95-41a7-84e3-d95e1a294d14@github.com>

> Removed the TRAPS in function declarations in jvmtiRedefineClasses and in ConstantPool merging functions.
> Tested with vmTestbase/nsk/jvmti and tier1 (in progress).

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  missed THREAD that should be CHECK_false argument.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3141/files
  - new: https://git.openjdk.java.net/jdk/pull/3141/files/c3f57eb7..1e3f00d4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3141&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3141&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3141.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3141/head:pull/3141

PR: https://git.openjdk.java.net/jdk/pull/3141

From sspitsyn at openjdk.java.net  Tue Mar 23 01:50:38 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 23 Mar 2021 01:50:38 GMT
Subject: RFR: 8262881: port JVM/DI tests from JDK-4413752 to JVM/TI [v2]
In-Reply-To: <N2ttOL2H2afquWau8ZwL41-V1XapL9O7HoZvIuPw7UA=.073dac9f-ba95-4caf-950f-f0576e93732f@github.com>
References: <XOECrKnBcmSRjfY2cM-GqFs3jMr0fTy7KJUCUHZ0HGw=.54872a68-97e9-481a-871e-eade80a51604@github.com>
 <pIS66umBFPY0bsix6EW_zdVNzFG5J6A33FHVrpvEJ64=.c3cc75d9-25cd-4fc0-b3bc-35fe628d5e2c@github.com>
 <FTPu45SOPngFqXyPfuBhBewCMrOKmxVWMM1c5shSAk0=.f2ae0a1f-d047-4e38-9646-973cea5d14bd@github.com>
 <mt28C9CCpgvEssnL1Wo548FPnwpC3dkZlNlUy8IswcQ=.b0b9439a-7dbd-4fb7-b634-cad50617f38b@github.com>
 <N2ttOL2H2afquWau8ZwL41-V1XapL9O7HoZvIuPw7UA=.073dac9f-ba95-4caf-950f-f0576e93732f@github.com>
Message-ID: <fA0PdwEJ8CGXaEB7etUKosA4-4loLHXIKNTbxNQzsdc=.eb457518-0a73-4385-bb8d-86ef2a0a014b@github.com>

On Mon, 22 Mar 2021 14:22:36 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Hi Dan,
>> 
>> If you change the native methods, e.g. :
>> native static void RawMonitorEnter(int id);
>> To something like:
>> native static int RawMonitorEnter();
>> 
>> You can then handle the jvmti error in the Java code, so you don't need to pass down the 'id' of the thread.
>> You then remove all debug code from the C-code agent, which removes some native methods also.
>> Which also leads to that you don't need  the thread 'id', instead you can just use the thread name, which removes some Java code.
>> 
>> Also you shouldn't catch the UnsatisfiedLinkError, as docs also says: "An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch."
>> 
>> You also have a lot of code for argument parsing which is not used by the test inside the test methods.
>> Can you either remove that or if you want it put it in a separate class/method, so e.g. "doWork()" takes parsed arguments instead.
>> 
>> Thanks, Robbin
>
> @robehn - Thanks for the review and for the suggested improvements to the tests.
> It will take me a bit of time to make and test these suggestions.

Hi Dan,
> I figured you would enjoy this 20 year old blast from the past!
Yes, of course, but these tests look like they have been written today! :)

Thank you for making changes!
I've just noticed one minor issue:

libSuspendWithObjectMonitorEnter.cpp
libSuspendWithObjectMonitorWait.cpp:
The static variables below are not used and can be removed:
 32 static jrawMonitorID threadLock = NULL;
 33 static char threadLockName[] = "threadLock";

Thanks,
Serguei

-------------

PR: https://git.openjdk.java.net/jdk/pull/2899

From sspitsyn at openjdk.java.net  Tue Mar 23 02:20:42 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 23 Mar 2021 02:20:42 GMT
Subject: RFR: 8263670: pmap and pstack in jhsdb do not work on debug
 server [v2]
In-Reply-To: <8nzlQFRQWlro_1j_47-7QTdhmFzm3gGIwGTrGWyQqFA=.fe77d8a2-c9c5-4c86-885e-ebb7850a1d00@github.com>
References: <OzFp9WFONUqIUYqdZ78D04bfnhgOSaeB1WqmPtyUdA0=.7dcf74d3-6819-4c9c-b878-a26cfcd0cbc6@github.com>
 <8nzlQFRQWlro_1j_47-7QTdhmFzm3gGIwGTrGWyQqFA=.fe77d8a2-c9c5-4c86-885e-ebb7850a1d00@github.com>
Message-ID: <zEsPm-p_0scJs8O_N4rnp0YgjwHOAvB2UPVDGWOIATg=.fa4df313-860f-4f8b-9cd4-2bf29261f150@github.com>

On Thu, 18 Mar 2021 05:17:10 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> jhsdb supports pmap (jhsdb jmap) and pstack (jhsdb jstack --mixed), and they work fine if they attach to live process or to coredump, however they do not work on debug server as following:
>> 
>> $ jhsdb jmap --connect localhost
>> Attaching to remote server localhost, please wait...
>> Debugger attached successfully.
>> Server compiler detected.
>> JVM version is 11.0.10+9
>> remote configuration is not yet implemented
>> 
>> pmap and pstack depend on CDebugger in SA, however it would not be set in case of remote debugger client. We can avoid it if we can delegate the process to debug server.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update testcases

Hi Yasumasa,
The fix looks good. I've added one nit.
Thanks,
Serguei

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PMap.java line 81:

> 79:       } else {
> 80:           if (getDebugeeType() == DEBUGEE_REMOTE) {
> 81:             out.print(((RemoteDebuggerClient)dbg).execCommandOnServer("pmap", null));

Nit: Indent is incorrect now.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3027

From sspitsyn at openjdk.java.net  Tue Mar 23 02:44:38 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 23 Mar 2021 02:44:38 GMT
Subject: RFR: 8263342: Add --connect option to jhsdb hsdb/clhsdb [v2]
In-Reply-To: <QZ1vc_jKjLAdm9d-FuP43SwUC27uzy32ugiwnpphNgU=.b0f3a1bb-3b49-4621-aadf-ab5dfe75b654@github.com>
References: <8P9wnEz8u2vWe__AzCvHn5WA12MV-psaP-2y7ZDbr0Q=.21b05c15-b33a-4577-8bb3-4b6b6498e456@github.com>
 <QZ1vc_jKjLAdm9d-FuP43SwUC27uzy32ugiwnpphNgU=.b0f3a1bb-3b49-4621-aadf-ab5dfe75b654@github.com>
Message-ID: <Lkf784EvcJH2BpnbNFLAGGAkxiYHmiJXYEe6npizIPw=.6f984318-c020-40cc-a208-4cce0ea463fc@github.com>

On Thu, 11 Mar 2021 00:20:35 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Most of subcommands in jhsdb supports to connect to debug server via `--connect` command line option, however `hsdb` and `clhsdb` do not accept it.
>> 
>> Both HSDB and CLHSDB support to connect to debug server, so they should have capability to do it via command line option.
>> 
>> I also filed [CSR for this issue](https://bugs.openjdk.java.net/browse/JDK-8263345). Please review it as well.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update testcase name

Hi Yasumasa,
This looks good.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2908

From sspitsyn at openjdk.java.net  Tue Mar 23 02:52:39 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 23 Mar 2021 02:52:39 GMT
Subject: RFR: 8263572: Output from jstack mixed mode is misaligned [v2]
In-Reply-To: <Tk1-poV1F49pg7TH4c9636JUsJvTk0Q9cK-AZX3uPQM=.b5d134e9-f4bd-48d2-97c4-c8f7776077ad@github.com>
References: <LiAjqiWikfy0llyWM79wX1pZQO4JkNsO8WwjWqcAAKg=.e177e030-08cf-42cd-aaee-27d530b5ed02@github.com>
 <Tk1-poV1F49pg7TH4c9636JUsJvTk0Q9cK-AZX3uPQM=.b5d134e9-f4bd-48d2-97c4-c8f7776077ad@github.com>
Message-ID: <ow8sEOfs5APyob8NNGMU50pFLrEKvKutL4-eBBYIvXo=.ca56feb5-36fc-4413-95be-f1fcad885204@github.com>

On Tue, 16 Mar 2021 06:09:25 GMT, Koichi Sakata <ksakata at openjdk.org> wrote:

>> When running jstack with mixed option, the output of the lines that doesn't have an address are misaligned as followings. 
>> 
>> $ sudo jhsdb jstack --mixed --pid 8281
>> ----------------- 8330 -----------------
>> "event-handler" #20 daemon prio=5 tid=0x00007f2384838490 nid=0x208a in Object.wait() [0x00007f23585ec000]
>>    java.lang.Thread.State: WAITING (on object monitor)
>>    JavaThread state: _thread_blocked
>> 0x00007f238da899f3      __pthread_cond_wait + 0x243
>> 0x00007f238c63a26b      os::PlatformEvent::park() + 0x8b
>> 0x00007f238c5e689d      ObjectMonitor::wait(long, bool, Thread*) + 0xfed
>> 0x00007f238ca1f1d6      ObjectSynchronizer::wait(Handle, long, Thread*) + 0x96
>> 0x00007f238c0b4d71      JVM_MonitorWait + 0x241
>> 0x00007f237cb246b7      java.lang.Object.wait(long) + 0xd7 (Native method)
>> 0x00007f2375777344      * java.lang.Object.wait() bci:2 line:338 (Compiled frame)
>> * com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(long) bci:64 line:190 (Compiled frame)
>> * com.sun.tools.jdi.EventQueueImpl.remove(long) bci:18 line:97 (Interpreted frame)
>> 0x00007f2375009543      * com.sun.tools.jdi.EventQueueImpl.remove() bci:2 line:83 (Interpreted frame)
>> 
>> This pull request aligns the indentation. So It will be able to improve readability.
>> 
>> In this pull request the address part is filled with white spaces. The amount of space is calculated from VM's address size and lastly 2, which is the length of "0x", is added.
>> 
>> ### jtreg test
>> 
>> $ sudo make run-test TEST=serviceability/sa/TestJhsdbJstackMixed.java
>> 
>> $ cat ./jdk/build/linux-x86_64-server-fastdebug/test-results/jtreg_test_hotspot_jtreg_serviceability_sa_TestJhsdbJstackMixed_java/text/summary.txt
>> serviceability/sa/TestJhsdbJstackMixed.java  Passed. Execution successful
>> 
>> ### Output Confirmation
>> 
>> I checked the output on 64-bit and 32-bit JDK.
>> 
>> First, I ran JShell. Next, on another shell, I ran jstack with mixed option for the JShell process and checked the output.
>> 
>> #### Linux 64-bit JDK
>>  $ ./jdk/build/linux-x86_64-server-fastdebug/jdk/bin/jshell
>> |  Welcome to JShell -- Version 16-internal
>> |  For an introduction type: /help intro
>> 
>> jshell>
>> 
>> $ ./jdk/build/linux-x86_64-server-fastdebug/jdk/bin/jhsdb jstack --mixed --pid 19272
>> ...
>> ----------------- 19324 -----------------
>> "output reader" #21 daemon prio=5 tid=0x00007f2ae4783760 nid=0x4b7c runnable [0x00007f2a86efd000]
>>    java.lang.Thread.State: RUNNABLE
>>    JavaThread state: _thread_in_native
>> 0x00007f2aed5d2394      __libc_read + 0x44
>> 0x00007f2ac450f93b      Java_sun_nio_ch_SocketDispatcher_read0 + 0x2b
>> 0x00007f2adcb2045a      sun.nio.ch.SocketDispatcher.read0(java.io.FileDescriptor, long, int) + 0xfa (Native method)
>> 0x00007f2ad573e024      * sun.nio.ch.SocketDispatcher.read(java.io.FileDescriptor, long, int) bci:4 line:47 (Compiled frame)
>>                         * sun.nio.ch.NioSocketImpl.tryRead(java.io.FileDescriptor, byte[], int, int) bci:45 line:261 (Compiled frame)
>>                         * sun.nio.ch.NioSocketImpl.implRead(byte[], int, int) bci:99 line:312 (Compiled frame)
>>                         * sun.nio.ch.NioSocketImpl.read(byte[], int, int) bci:54 line:350 (Compiled frame)
>>                         * sun.nio.ch.NioSocketImpl$1.read(byte[], int, int) bci:7 line:803 (Compiled frame)
>>                         * java.net.Socket$SocketInputStream.read(byte[], int, int) bci:7 line:961 (Compiled frame)
>>                         * java.net.Socket$SocketInputStream.read() bci:8 line:956 (Compiled frame)
>>                         * java.io.FilterInputStream.read() bci:4 line:82 (Interpreted frame)
>> 0x00007f2ad50094fe      * jdk.jshell.execution.DemultiplexInput.run() bci:4 line:58 (Interpreted frame)
>> 0x00007f2ad5000d4a      <StubRoutines>
>> ...
>> 
>> #### Windows 32-bit JDK
>> $ ./jdk/build/windows-x86-server-fastdebug/jdk/bin/jhsdb.exe jstack --mixed --pid 78808
>> ...
>> ----------------- 29 -----------------
>> "output reader" #17 daemon prio=5 tid=0x2711c3b8 nid=0x13178 runnable [0x27d6f000]
>>    java.lang.Thread.State: RUNNABLE
>>    JavaThread state: _thread_in_native
>> 0x77ae2f5c      ntdll!NtWaitForSingleObject + 0xc
>> 0x6dc5cb18      mswsock!sethostname + 0xbdc8
>> 0x753cdecc      WS2_32!WSARecv + 0x11c
>> 0x6c0d35f8      nio!Java_sun_nio_ch_SocketDispatcher_read0 + 0x48
>> 0x02d15ee9      sun.nio.ch.SocketDispatcher.read0(java.io.FileDescriptor, long, int) + 0xa9 (Native method)
>> 0x02d16540      * sun.nio.ch.SocketDispatcher.read(java.io.FileDescriptor, long, int) bci:4 line:46 (Compiled frame)
>>                 * sun.nio.ch.NioSocketImpl.tryRead(java.io.FileDescriptor, byte[], int, int) bci:45 line:261 (Compiled frame)
>>                 * sun.nio.ch.NioSocketImpl.implRead(byte[], int, int) bci:99 line:312 (Compiled frame)
>>                 * sun.nio.ch.NioSocketImpl.read(byte[], int, int) bci:54 line:350 (Compiled frame)
>>                 * sun.nio.ch.NioSocketImpl$1.read(byte[], int, int) bci:7 line:803 (Compiled frame)
>>                 * java.net.Socket$SocketInputStream.read(byte[], int, int) bci:7 line:961 (Compiled frame)
>>                 * java.net.Socket$SocketInputStream.read() bci:8 line:956 (Compiled frame)
>>                 * java.io.FilterInputStream.read() bci:4 line:82 (Interpreted frame)
>> 0x02ac6804      * jdk.jshell.execution.DemultiplexInput.run() bci:4 line:58 (Interpreted frame)
>> 0x02ac0cdc      <StubRoutines>
>> ...
>
> Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix calculation for the length of white space

Hi Koichi,
It looks good to me. Thank you for the contribution!
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3004

From sspitsyn at openjdk.java.net  Tue Mar 23 03:16:39 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 23 Mar 2021 03:16:39 GMT
Subject: RFR: 8262081:
 vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter001/TestDescription.java
 failed with "ERROR: eventSet1.size() != 3 :: 2"
In-Reply-To: <-WEaFWU7bEOckY-ltHYclBwZMbgrKw5ye8TaZ7cryn4=.2ef514f2-9881-400b-b53f-fc1b3465b177@github.com>
References: <-WEaFWU7bEOckY-ltHYclBwZMbgrKw5ye8TaZ7cryn4=.2ef514f2-9881-400b-b53f-fc1b3465b177@github.com>
Message-ID: <bmDEHO4QR0U1up7JqwhEqENbePbuCB3mD8efxLJXueA=.0db1aa10-c578-4a4a-b1da-135c1a30cf62@github.com>

On Mon, 22 Mar 2021 21:56:01 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates the test to use special method to wait for ThreadDeathEvent for the specific thread, ignoring event from other threads

Hi Alex,
LGTM++
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3133

From github.com+81080647+lyndseybeil at openjdk.java.net  Tue Mar 23 04:50:40 2021
From: github.com+81080647+lyndseybeil at openjdk.java.net (lyndseyBeil)
Date: Tue, 23 Mar 2021 04:50:40 GMT
Subject: RFR: 8262881: port JVM/DI tests from JDK-4413752 to JVM/TI [v2]
In-Reply-To: <wUCvQfmlMD5sMgBEIDspFQigcEMfmJWrJW6LcRxdFJo=.46453b48-b28f-4740-80b5-0909e980d1c7@github.com>
References: <XOECrKnBcmSRjfY2cM-GqFs3jMr0fTy7KJUCUHZ0HGw=.54872a68-97e9-481a-871e-eade80a51604@github.com>
 <wUCvQfmlMD5sMgBEIDspFQigcEMfmJWrJW6LcRxdFJo=.46453b48-b28f-4740-80b5-0909e980d1c7@github.com>
Message-ID: <dhvs0X9kIhM_K0-b978ErwPXkaF26lctQt35M0dTJxE=.118a02b2-b65c-4e2b-a637-6b5d6e70f3d4@github.com>

On Fri, 19 Mar 2021 21:28:09 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Add three tests from JDK-4413752 ported to JVM/TI:
>> 
>> - RawMonitorEnter() with SuspendThread()
>>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithRawMonitorEnter/SuspendWithRawMonitorEnter.java
>>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithRawMonitorEnter/libSuspendWithRawMonitorEnter.cpp
>> 
>> - ObjectMonitor enter() with SuspendThread()
>>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorEnter/SuspendWithObjectMonitorEnter.java
>>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorEnter/libSuspendWithObjectMonitorEnter.cpp
>> 
>> - ObjectMonitor wait() with SuspendThread
>>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java
>>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/libSuspendWithObjectMonitorWait.cpp
>> 
>> The Java files have a transaction diagram to show what each of the
>> threads in the test is doing.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   sspitsyn - fix white space indents problems.

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorEnter/SuspendWithObjectMonitorEnter.java line 92:

> 90:     native static int GetResult();
> 91:     native static void SetPrintDebug();
> 92:     native static void SuspendThread(int id, SuspendWithObjectMonitorEnterWorker thr);

I detect that this code is problematic. According to the [Bad practice (BAD_PRACTICE)](https://spotbugs.readthedocs.io/en/stable/bugDescriptions.html#bad-practice-bad-practice), [Nm: Method names should start with a lower case letter (NM_METHOD_NAMING_CONVENTION)](https://spotbugs.readthedocs.io/en/stable/bugDescriptions.html#nm-method-names-should-start-with-a-lower-case-letter-nm-method-naming-convention).
Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2899

From ysuenaga at openjdk.java.net  Tue Mar 23 04:58:01 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 23 Mar 2021 04:58:01 GMT
Subject: RFR: 8263670: pmap and pstack in jhsdb do not work on debug
 server [v3]
In-Reply-To: <OzFp9WFONUqIUYqdZ78D04bfnhgOSaeB1WqmPtyUdA0=.7dcf74d3-6819-4c9c-b878-a26cfcd0cbc6@github.com>
References: <OzFp9WFONUqIUYqdZ78D04bfnhgOSaeB1WqmPtyUdA0=.7dcf74d3-6819-4c9c-b878-a26cfcd0cbc6@github.com>
Message-ID: <xlLslJEJqZ606QtYjVgkCTydO_AYaoL80fn6M8c2mbM=.262098c7-7f52-43ad-820c-3e17ee83bfcb@github.com>

> jhsdb supports pmap (jhsdb jmap) and pstack (jhsdb jstack --mixed), and they work fine if they attach to live process or to coredump, however they do not work on debug server as following:
> 
> $ jhsdb jmap --connect localhost
> Attaching to remote server localhost, please wait...
> Debugger attached successfully.
> Server compiler detected.
> JVM version is 11.0.10+9
> remote configuration is not yet implemented
> 
> pmap and pstack depend on CDebugger in SA, however it would not be set in case of remote debugger client. We can avoid it if we can delegate the process to debug server.

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Fix indent

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3027/files
  - new: https://git.openjdk.java.net/jdk/pull/3027/files/57149ae1..f9e9b03e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3027&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3027&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3027.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3027/head:pull/3027

PR: https://git.openjdk.java.net/jdk/pull/3027

From ysuenaga at openjdk.java.net  Tue Mar 23 04:58:02 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 23 Mar 2021 04:58:02 GMT
Subject: RFR: 8263670: pmap and pstack in jhsdb do not work on debug
 server [v2]
In-Reply-To: <zEsPm-p_0scJs8O_N4rnp0YgjwHOAvB2UPVDGWOIATg=.fa4df313-860f-4f8b-9cd4-2bf29261f150@github.com>
References: <OzFp9WFONUqIUYqdZ78D04bfnhgOSaeB1WqmPtyUdA0=.7dcf74d3-6819-4c9c-b878-a26cfcd0cbc6@github.com>
 <8nzlQFRQWlro_1j_47-7QTdhmFzm3gGIwGTrGWyQqFA=.fe77d8a2-c9c5-4c86-885e-ebb7850a1d00@github.com>
 <zEsPm-p_0scJs8O_N4rnp0YgjwHOAvB2UPVDGWOIATg=.fa4df313-860f-4f8b-9cd4-2bf29261f150@github.com>
Message-ID: <VLNkM3h03B90B-vg4y6NWA1j1eh3rIr_fw1Lalcj8pM=.227dbe24-40a3-4f53-bdf3-86a0a4a26f26@github.com>

On Tue, 23 Mar 2021 02:16:43 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update testcases
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PMap.java line 81:
> 
>> 79:       } else {
>> 80:           if (getDebugeeType() == DEBUGEE_REMOTE) {
>> 81:             out.print(((RemoteDebuggerClient)dbg).execCommandOnServer("pmap", null));
> 
> Nit: Indent is incorrect now.

Thanks! I fixed it in new commit.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3027

From dholmes at openjdk.java.net  Tue Mar 23 05:04:39 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 23 Mar 2021 05:04:39 GMT
Subject: RFR: 8264004: Don't use TRAPS if no exceptions are thrown [v2]
In-Reply-To: <uYmLht5CfEs4CxvJQl5vCFBqoH5RitXnZY2lKG0Y7NM=.1c5b2fe2-9e95-41a7-84e3-d95e1a294d14@github.com>
References: <1KBghJAnPzq1F4LTwaaa8sUTy-BiLlO4uXSmYC1XGPA=.46cc3327-0af0-409f-bf1a-07066c60b0de@github.com>
 <uYmLht5CfEs4CxvJQl5vCFBqoH5RitXnZY2lKG0Y7NM=.1c5b2fe2-9e95-41a7-84e3-d95e1a294d14@github.com>
Message-ID: <pgPa6Dh3Bfe1vIGexjO2sFv6Oz-g4HBXPFums7mpSiQ=.de8aed74-a053-4921-aca1-a74ae5a728d7@github.com>

On Tue, 23 Mar 2021 01:22:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Removed the TRAPS in function declarations in jvmtiRedefineClasses and in ConstantPool merging functions.
>> Tested with vmTestbase/nsk/jvmti and tier1 (in progress).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missed THREAD that should be CHECK_false argument.

Hi Coleen,

This looks great! Good to see all those false TRAPS usages disappear. I found one more.

Thanks,
David

PS. Annoying that we often needs TRAPS through a call chain just because some leaf method may trigger an OOME. <sigh> No escaping that unfortunately.

src/hotspot/share/prims/jvmtiRedefineClasses.hpp line 484:

> 482:   void rewrite_cp_refs_in_method(methodHandle method,
> 483:     methodHandle * new_method_p, TRAPS);
> 484:   bool rewrite_cp_refs_in_methods(InstanceKlass* scratch_class, TRAPS);

This method clears any pending exception and so should not be a TRAPS method.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3141

From iklam at openjdk.java.net  Tue Mar 23 05:56:40 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 23 Mar 2021 05:56:40 GMT
Subject: RFR: 8264004: Don't use TRAPS if no exceptions are thrown [v2]
In-Reply-To: <uYmLht5CfEs4CxvJQl5vCFBqoH5RitXnZY2lKG0Y7NM=.1c5b2fe2-9e95-41a7-84e3-d95e1a294d14@github.com>
References: <1KBghJAnPzq1F4LTwaaa8sUTy-BiLlO4uXSmYC1XGPA=.46cc3327-0af0-409f-bf1a-07066c60b0de@github.com>
 <uYmLht5CfEs4CxvJQl5vCFBqoH5RitXnZY2lKG0Y7NM=.1c5b2fe2-9e95-41a7-84e3-d95e1a294d14@github.com>
Message-ID: <H3H6dOTtQZuQxHSkwFKihpcVQnZLZcWj1pKCnL1vo2E=.fdea5be7-d8c9-417b-b376-32ac0cbd6924@github.com>

On Tue, 23 Mar 2021 01:22:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Removed the TRAPS in function declarations in jvmtiRedefineClasses and in ConstantPool merging functions.
>> Tested with vmTestbase/nsk/jvmti and tier1 (in progress).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missed THREAD that should be CHECK_false argument.

LGTM. I think suggested TRAPS changes could be done in a separate REF.

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3141

From iklam at openjdk.java.net  Tue Mar 23 05:56:41 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 23 Mar 2021 05:56:41 GMT
Subject: RFR: 8264004: Don't use TRAPS if no exceptions are thrown [v2]
In-Reply-To: <pgPa6Dh3Bfe1vIGexjO2sFv6Oz-g4HBXPFums7mpSiQ=.de8aed74-a053-4921-aca1-a74ae5a728d7@github.com>
References: <1KBghJAnPzq1F4LTwaaa8sUTy-BiLlO4uXSmYC1XGPA=.46cc3327-0af0-409f-bf1a-07066c60b0de@github.com>
 <uYmLht5CfEs4CxvJQl5vCFBqoH5RitXnZY2lKG0Y7NM=.1c5b2fe2-9e95-41a7-84e3-d95e1a294d14@github.com>
 <pgPa6Dh3Bfe1vIGexjO2sFv6Oz-g4HBXPFums7mpSiQ=.de8aed74-a053-4921-aca1-a74ae5a728d7@github.com>
Message-ID: <M0C36h2uqgZrcFQJ8TwdMqYYdpbhtc6NXuY6tQDZSJc=.265f359d-1569-4548-93a8-d5c8d67c30bf@github.com>

On Tue, 23 Mar 2021 04:59:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   missed THREAD that should be CHECK_false argument.
>
> src/hotspot/share/prims/jvmtiRedefineClasses.hpp line 484:
> 
>> 482:   void rewrite_cp_refs_in_method(methodHandle method,
>> 483:     methodHandle * new_method_p, TRAPS);
>> 484:   bool rewrite_cp_refs_in_methods(InstanceKlass* scratch_class, TRAPS);
> 
> This method clears any pending exception and so should not be a TRAPS method.

`VM_RedefineClasses::load_new_class_versions` also seems to never throw. These functions should be changed to take a `Thread*` parameter, and should use `HandleMark em(thread);` to guarantee that an exception never leaves the function.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3141

From ysuenaga at openjdk.java.net  Tue Mar 23 06:30:43 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 23 Mar 2021 06:30:43 GMT
Subject: Integrated: 8263342: Add --connect option to jhsdb hsdb/clhsdb
In-Reply-To: <8P9wnEz8u2vWe__AzCvHn5WA12MV-psaP-2y7ZDbr0Q=.21b05c15-b33a-4577-8bb3-4b6b6498e456@github.com>
References: <8P9wnEz8u2vWe__AzCvHn5WA12MV-psaP-2y7ZDbr0Q=.21b05c15-b33a-4577-8bb3-4b6b6498e456@github.com>
Message-ID: <NEMSgAJ-D5i-l_n3SVTq9cY_tVDAgZlLkae2UigGMoM=.8b3c9571-9127-4bfc-95cb-a570fe7e814b@github.com>

On Wed, 10 Mar 2021 08:29:37 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> Most of subcommands in jhsdb supports to connect to debug server via `--connect` command line option, however `hsdb` and `clhsdb` do not accept it.
> 
> Both HSDB and CLHSDB support to connect to debug server, so they should have capability to do it via command line option.
> 
> I also filed [CSR for this issue](https://bugs.openjdk.java.net/browse/JDK-8263345). Please review it as well.

This pull request has now been integrated.

Changeset: b2a52ea5
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b2a52ea5
Stats:     130 lines in 5 files changed: 114 ins; 4 del; 12 mod

8263342: Add --connect option to jhsdb hsdb/clhsdb

Reviewed-by: cjplummer, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/2908

From aph at openjdk.java.net  Tue Mar 23 09:56:56 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 23 Mar 2021 09:56:56 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v24]
In-Reply-To: <Lw_ar-Qr7JWxNWFgRc4qBWYsL12i8-eRmarTyB3gGto=.f3c76e3e-626d-468b-9c03-e4ce9f7ecf33@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <LMAOpd9DlD4esG9l4lwxtOe5_j1Cpi6aU33tVWCz3bE=.b4ab8215-55c0-43b4-a222-03e5aa0862e3@github.com>
 <Lw_ar-Qr7JWxNWFgRc4qBWYsL12i8-eRmarTyB3gGto=.f3c76e3e-626d-468b-9c03-e4ce9f7ecf33@github.com>
Message-ID: <3fAiKgcWOdYNUYMfY0LSvyMswzjlKJWJaxZgGf7tdYE=.aa5e7ae8-2744-4c2c-9e66-b72e19d9ebec@github.com>

On Fri, 12 Mar 2021 16:32:10 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 105 commits:
>> 
>>  - Merge commit 'refs/pull/11/head' of https://github.com/AntonKozlov/jdk into jdk-macos
>>  - workaround JDK-8262895 by disabling subtest
>>  - Fix typo
>>  - Rename threadWXSetters.hpp -> threadWXSetters.inline.hpp
>>  - JDK-8259937: bsd_aarch64 part
>>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>>  - Fix after JDK-8259539, partially revert preconditions
>>  - JDK-8260471: bsd_aarch64 part
>>  - JDK-8259539: bsd_aarch64 part
>>  - JDK-8257828: bsd_aarch64 part
>>  - ... and 95 more: https://git.openjdk.java.net/jdk/compare/a6e34b3d...a72f6834
>
>> @theRealAph, could you elaborate on what is need to be done for [#2200 (review)](https://github.com/openjdk/jdk/pull/2200#pullrequestreview-600597066).
> 
> I think that what you've got now is fine.

> _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [build-dev](mailto:build-dev at openjdk.java.net):_
> 
> On 3/15/21 6:56 PM, Anton Kozlov wrote:
> 
> > On Wed, 10 Mar 2021 11:21:44 GMT, Andrew Haley <aph at openjdk.org> wrote:
> > > > We always check for `R18_RESERVED` with `#if(n)def`, is there any reason to define the value for the macro?
> > > 
> > > 
> > > Robustness, clarity, maintainability, convention. Why not?
> > 
> > 
> > I've tried to implement the suggestion, but it pulled more unnecessary changes. It makes the intended way to check the condition less clear (`#ifdef` and not `#if`).
> 
> No, no, no! I am not suggesting you change anything else, just that
> you do not define contentless macros. You might as well define it
> to be something, and true is a reasonable default, that's all. It's
> not terribly important, it's just good practice.

I'm quite prepared to drop this if it's holding up the port. It's a style thing, but it's not critical.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From aph at openjdk.java.net  Tue Mar 23 09:56:57 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 23 Mar 2021 09:56:57 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v24]
In-Reply-To: <3fAiKgcWOdYNUYMfY0LSvyMswzjlKJWJaxZgGf7tdYE=.aa5e7ae8-2744-4c2c-9e66-b72e19d9ebec@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <LMAOpd9DlD4esG9l4lwxtOe5_j1Cpi6aU33tVWCz3bE=.b4ab8215-55c0-43b4-a222-03e5aa0862e3@github.com>
 <Lw_ar-Qr7JWxNWFgRc4qBWYsL12i8-eRmarTyB3gGto=.f3c76e3e-626d-468b-9c03-e4ce9f7ecf33@github.com>
 <3fAiKgcWOdYNUYMfY0LSvyMswzjlKJWJaxZgGf7tdYE=.aa5e7ae8-2744-4c2c-9e66-b72e19d9ebec@github.com>
Message-ID: <YVVYsQezst6QHcY0q_q-dmOYnzGiMdXaqabDahOmqO4=.1c0a67c6-1db1-4975-8c87-fb5308ac18dc@github.com>

On Tue, 23 Mar 2021 09:53:54 GMT, Andrew Haley <aph at openjdk.org> wrote:

>>> @theRealAph, could you elaborate on what is need to be done for [#2200 (review)](https://github.com/openjdk/jdk/pull/2200#pullrequestreview-600597066).
>> 
>> I think that what you've got now is fine.
>
>> _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [build-dev](mailto:build-dev at openjdk.java.net):_
>> 
>> On 3/15/21 6:56 PM, Anton Kozlov wrote:
>> 
>> > On Wed, 10 Mar 2021 11:21:44 GMT, Andrew Haley <aph at openjdk.org> wrote:
>> > > > We always check for `R18_RESERVED` with `#if(n)def`, is there any reason to define the value for the macro?
>> > > 
>> > > 
>> > > Robustness, clarity, maintainability, convention. Why not?
>> > 
>> > 
>> > I've tried to implement the suggestion, but it pulled more unnecessary changes. It makes the intended way to check the condition less clear (`#ifdef` and not `#if`).
>> 
>> No, no, no! I am not suggesting you change anything else, just that
>> you do not define contentless macros. You might as well define it
>> to be something, and true is a reasonable default, that's all. It's
>> not terribly important, it's just good practice.
> 
> I'm quite prepared to drop this if it's holding up the port. It's a style thing, but it's not critical.

So, where are we up to now? Are we done yet?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From vkempik at openjdk.java.net  Tue Mar 23 11:20:52 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Tue, 23 Mar 2021 11:20:52 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v24]
In-Reply-To: <YVVYsQezst6QHcY0q_q-dmOYnzGiMdXaqabDahOmqO4=.1c0a67c6-1db1-4975-8c87-fb5308ac18dc@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <LMAOpd9DlD4esG9l4lwxtOe5_j1Cpi6aU33tVWCz3bE=.b4ab8215-55c0-43b4-a222-03e5aa0862e3@github.com>
 <Lw_ar-Qr7JWxNWFgRc4qBWYsL12i8-eRmarTyB3gGto=.f3c76e3e-626d-468b-9c03-e4ce9f7ecf33@github.com>
 <3fAiKgcWOdYNUYMfY0LSvyMswzjlKJWJaxZgGf7tdYE=.aa5e7ae8-2744-4c2c-9e66-b72e19d9ebec@github.com>
 <YVVYsQezst6QHcY0q_q-dmOYnzGiMdXaqabDahOmqO4=.1c0a67c6-1db1-4975-8c87-fb5308ac18dc@github.com>
Message-ID: <Rdc-1pvRQKF9q1HEI0zkO7Dgn5GAu1rgDZ_vH-5J5nM=.637e4903-b31d-4f06-8e98-473a057f13fc@github.com>

On Tue, 23 Mar 2021 09:54:16 GMT, Andrew Haley <aph at openjdk.org> wrote:

> So, where are we up to now? Are we done yet?

Hello
we would like to get approval for the final version we have now and then integrate this pr as soon as Mark will target it to jdk17

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From github.com+22524871+horizonzy at openjdk.java.net  Tue Mar 23 11:39:00 2021
From: github.com+22524871+horizonzy at openjdk.java.net (=?UTF-8?B?6LW15bu2?=)
Date: Tue, 23 Mar 2021 11:39:00 GMT
Subject: RFR: 8264028: Typo in
 javax.management.relation.RelationService::purgeRelations
Message-ID: <9LcMa_awvTUUQUrc8y_D3kQl2wFTraWLYfK_prqwsvI=.9a10ef23-f23d-4e1d-8833-c25af1067deb@github.com>

8264028: Typo in javax.management.relation.RelationService::purgeRelations

-------------

Commit messages:
 - update copyright.
 - typo fix.

Changes: https://git.openjdk.java.net/jdk/pull/2765/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2765&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264028
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2765.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2765/head:pull/2765

PR: https://git.openjdk.java.net/jdk/pull/2765

From robilad at openjdk.java.net  Tue Mar 23 11:39:00 2021
From: robilad at openjdk.java.net (Dalibor Topic)
Date: Tue, 23 Mar 2021 11:39:00 GMT
Subject: RFR: 8264028: Typo in
 javax.management.relation.RelationService::purgeRelations
In-Reply-To: <9LcMa_awvTUUQUrc8y_D3kQl2wFTraWLYfK_prqwsvI=.9a10ef23-f23d-4e1d-8833-c25af1067deb@github.com>
References: <9LcMa_awvTUUQUrc8y_D3kQl2wFTraWLYfK_prqwsvI=.9a10ef23-f23d-4e1d-8833-c25af1067deb@github.com>
Message-ID: <_saybEKJgMmhSIcPF2amITOmcj8GsOVzsD9iJxTXuy0=.48822974-c90e-4d7a-8597-c875ce1e6eb6@github.com>

On Sun, 28 Feb 2021 10:48:55 GMT, ?? <github.com+22524871+horizonzy at openjdk.org> wrote:

> 8264028: Typo in javax.management.relation.RelationService::purgeRelations

Hi, please contact me at Dalibor.topic at oracle.com so that I can validate your OCA.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2765

From haosun at openjdk.java.net  Tue Mar 23 11:39:00 2021
From: haosun at openjdk.java.net (Hao Sun)
Date: Tue, 23 Mar 2021 11:39:00 GMT
Subject: RFR: 8264028: Typo in
 javax.management.relation.RelationService::purgeRelations
In-Reply-To: <_saybEKJgMmhSIcPF2amITOmcj8GsOVzsD9iJxTXuy0=.48822974-c90e-4d7a-8597-c875ce1e6eb6@github.com>
References: <9LcMa_awvTUUQUrc8y_D3kQl2wFTraWLYfK_prqwsvI=.9a10ef23-f23d-4e1d-8833-c25af1067deb@github.com>
 <_saybEKJgMmhSIcPF2amITOmcj8GsOVzsD9iJxTXuy0=.48822974-c90e-4d7a-8597-c875ce1e6eb6@github.com>
Message-ID: <RQnGNAJ4-qQ5Y2pG94JiO3W68Hemswbu_Otm-OGP1lM=.88abfda8-7336-41ef-8cec-b7825e55690c@github.com>

On Wed, 3 Mar 2021 16:52:36 GMT, Dalibor Topic <robilad at openjdk.org> wrote:

>> 8264028: Typo in javax.management.relation.RelationService::purgeRelations
>
> Hi, please contact me at Dalibor.topic at oracle.com so that I can validate your OCA.

Hi. Just a reminder for you that the copyright year should be updated to 2021.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2765

From github.com+22524871+horizonzy at openjdk.java.net  Tue Mar 23 11:39:01 2021
From: github.com+22524871+horizonzy at openjdk.java.net (=?UTF-8?B?6LW15bu2?=)
Date: Tue, 23 Mar 2021 11:39:01 GMT
Subject: RFR: 8264028: Typo in
 javax.management.relation.RelationService::purgeRelations
In-Reply-To: <RQnGNAJ4-qQ5Y2pG94JiO3W68Hemswbu_Otm-OGP1lM=.88abfda8-7336-41ef-8cec-b7825e55690c@github.com>
References: <9LcMa_awvTUUQUrc8y_D3kQl2wFTraWLYfK_prqwsvI=.9a10ef23-f23d-4e1d-8833-c25af1067deb@github.com>
 <_saybEKJgMmhSIcPF2amITOmcj8GsOVzsD9iJxTXuy0=.48822974-c90e-4d7a-8597-c875ce1e6eb6@github.com>
 <RQnGNAJ4-qQ5Y2pG94JiO3W68Hemswbu_Otm-OGP1lM=.88abfda8-7336-41ef-8cec-b7825e55690c@github.com>
Message-ID: <C2Ebw8FLQOZXOB3gF5N8CeMzWG2JEr2Zz8xuZHCU_VY=.097b1ddc-f3fe-46f9-82a0-23336f275cc3@github.com>

On Tue, 9 Mar 2021 01:19:11 GMT, Hao Sun <haosun at openjdk.org> wrote:

> Hi. Just a reminder for you that the copyright year should be updated to 2021.

thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/2765

From shade at openjdk.java.net  Tue Mar 23 11:39:01 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 23 Mar 2021 11:39:01 GMT
Subject: RFR: 8264028: Typo in
 javax.management.relation.RelationService::purgeRelations
In-Reply-To: <C2Ebw8FLQOZXOB3gF5N8CeMzWG2JEr2Zz8xuZHCU_VY=.097b1ddc-f3fe-46f9-82a0-23336f275cc3@github.com>
References: <9LcMa_awvTUUQUrc8y_D3kQl2wFTraWLYfK_prqwsvI=.9a10ef23-f23d-4e1d-8833-c25af1067deb@github.com>
 <_saybEKJgMmhSIcPF2amITOmcj8GsOVzsD9iJxTXuy0=.48822974-c90e-4d7a-8597-c875ce1e6eb6@github.com>
 <RQnGNAJ4-qQ5Y2pG94JiO3W68Hemswbu_Otm-OGP1lM=.88abfda8-7336-41ef-8cec-b7825e55690c@github.com>
 <C2Ebw8FLQOZXOB3gF5N8CeMzWG2JEr2Zz8xuZHCU_VY=.097b1ddc-f3fe-46f9-82a0-23336f275cc3@github.com>
Message-ID: <xoAzn6-QEfjIwJEogjpYL2Ez8LS3Q2-eLQRG_PUavbE=.fcd0cd37-e0cb-48c1-b0f7-4e9d3e4740e8@github.com>

On Tue, 9 Mar 2021 01:25:10 GMT, ?? <github.com+22524871+horizonzy at openjdk.org> wrote:

>> Hi. Just a reminder for you that the copyright year should be updated to 2021.
>
>> Hi. Just a reminder for you that the copyright year should be updated to 2021.
> 
> thanks

Hi, I have submitted the bug for it: https://bugs.openjdk.java.net/browse/JDK-8264028 -- please change the PR synopsis to "8264028: Typo in javax.management.relation.RelationService::purgeRelations" to get it properly hooked to PR metadata. After that, bots should tell what is next.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2765

From github.com+22524871+horizonzy at openjdk.java.net  Tue Mar 23 11:39:01 2021
From: github.com+22524871+horizonzy at openjdk.java.net (=?UTF-8?B?6LW15bu2?=)
Date: Tue, 23 Mar 2021 11:39:01 GMT
Subject: RFR: 8264028: Typo in
 javax.management.relation.RelationService::purgeRelations
In-Reply-To: <xoAzn6-QEfjIwJEogjpYL2Ez8LS3Q2-eLQRG_PUavbE=.fcd0cd37-e0cb-48c1-b0f7-4e9d3e4740e8@github.com>
References: <9LcMa_awvTUUQUrc8y_D3kQl2wFTraWLYfK_prqwsvI=.9a10ef23-f23d-4e1d-8833-c25af1067deb@github.com>
 <_saybEKJgMmhSIcPF2amITOmcj8GsOVzsD9iJxTXuy0=.48822974-c90e-4d7a-8597-c875ce1e6eb6@github.com>
 <RQnGNAJ4-qQ5Y2pG94JiO3W68Hemswbu_Otm-OGP1lM=.88abfda8-7336-41ef-8cec-b7825e55690c@github.com>
 <C2Ebw8FLQOZXOB3gF5N8CeMzWG2JEr2Zz8xuZHCU_VY=.097b1ddc-f3fe-46f9-82a0-23336f275cc3@github.com>
 <xoAzn6-QEfjIwJEogjpYL2Ez8LS3Q2-eLQRG_PUavbE=.fcd0cd37-e0cb-48c1-b0f7-4e9d3e4740e8@github.com>
Message-ID: <TmTRqpzkXsCeS5IZ3bcxRmFwhBvW-4P4xnLpefPkEAE=.f2fbb000-2ce0-4d43-ab09-0b5b0e290a1d@github.com>

On Tue, 23 Mar 2021 11:01:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Hi, I have submitted the bug for it: https://bugs.openjdk.java.net/browse/JDK-8264028 -- please change the PR synopsis to "8264028: Typo in javax.management.relation.RelationService::purgeRelations" to get it properly hooked to PR metadata. After that, bots should tell what is next.

ok, thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2765

From coleenp at openjdk.java.net  Tue Mar 23 11:54:39 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 23 Mar 2021 11:54:39 GMT
Subject: RFR: 8264004: Don't use TRAPS if no exceptions are thrown [v2]
In-Reply-To: <M0C36h2uqgZrcFQJ8TwdMqYYdpbhtc6NXuY6tQDZSJc=.265f359d-1569-4548-93a8-d5c8d67c30bf@github.com>
References: <1KBghJAnPzq1F4LTwaaa8sUTy-BiLlO4uXSmYC1XGPA=.46cc3327-0af0-409f-bf1a-07066c60b0de@github.com>
 <uYmLht5CfEs4CxvJQl5vCFBqoH5RitXnZY2lKG0Y7NM=.1c5b2fe2-9e95-41a7-84e3-d95e1a294d14@github.com>
 <pgPa6Dh3Bfe1vIGexjO2sFv6Oz-g4HBXPFums7mpSiQ=.de8aed74-a053-4921-aca1-a74ae5a728d7@github.com>
 <M0C36h2uqgZrcFQJ8TwdMqYYdpbhtc6NXuY6tQDZSJc=.265f359d-1569-4548-93a8-d5c8d67c30bf@github.com>
Message-ID: <on9nWqZmBZpzDWN__6thbttucJ-4E1kmwdAGoVvfZnA=.29d4b52a-2446-4e5b-96b7-fc7e63c5d826@github.com>

On Tue, 23 Mar 2021 05:52:51 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiRedefineClasses.hpp line 484:
>> 
>>> 482:   void rewrite_cp_refs_in_method(methodHandle method,
>>> 483:     methodHandle * new_method_p, TRAPS);
>>> 484:   bool rewrite_cp_refs_in_methods(InstanceKlass* scratch_class, TRAPS);
>> 
>> This method clears any pending exception and so should not be a TRAPS method.
>
> `VM_RedefineClasses::load_new_class_versions` also seems to never throw. These functions should be changed to take a `Thread*` parameter, and should use `HandleMark em(thread);` to guarantee that an exception never leaves the function.

Both of these functions are good examples of the convention that we're trying to agree on.   In, load_new_class_versions, TRAPS is passed to materialize THREAD.  THREAD is used then in a lot of places, and also to pass to SystemDictionary::parse_stream(...TRAPS), which does have an exceptional return that must be handled.
Removing TRAPS then adding:
JavaThread* current = JavaThread::current();
changing THREAD to current in most of the places seems ok, but passing 'current' to SystemDictionary::resolve_from_stream loses the information visually that this function returns an exception that must be handled.
We need some meta-writeup rather than these decisions made in pull requests, because if we made these decisions collectively, I missed out.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3141

From coleenp at openjdk.java.net  Tue Mar 23 12:14:40 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 23 Mar 2021 12:14:40 GMT
Subject: RFR: 8263976: Remove block allocation from BasicHashtable [v2]
In-Reply-To: <xx8pgLmlXYVJ0u-15IAwrB31QifUKt48UtyKlrQEfUk=.c0273068-32b3-4d04-9414-dd303880f8ad@github.com>
References: <ZkxFGxje18XFb3qVxeUqtcv1Y_Hi4SpeILatMXo-vzY=.c69c035d-80c7-4715-be45-c5d0d7f61b33@github.com>
 <27GM9pmZuaikjHuuvXVRYgOPnTqMxNOXhd1CR7BzaKo=.ab0ec842-335c-4c85-807b-dc6bcb6b77e3@github.com>
 <xx8pgLmlXYVJ0u-15IAwrB31QifUKt48UtyKlrQEfUk=.c0273068-32b3-4d04-9414-dd303880f8ad@github.com>
Message-ID: <Yy4aKGiGS_6cqHApLC5JQrzkIE3aunnOYCQVPSIVHAY=.f0e76eb8-6751-44ef-b2f9-4df318b46ea2@github.com>

On Mon, 22 Mar 2021 23:08:09 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix Hashtable constructor and comments.
>
> Marked as reviewed by iklam (Reviewer).

Thanks Lois and Ioi!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3123

From coleenp at openjdk.java.net  Tue Mar 23 12:14:41 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 23 Mar 2021 12:14:41 GMT
Subject: Integrated: 8263976: Remove block allocation from BasicHashtable
In-Reply-To: <ZkxFGxje18XFb3qVxeUqtcv1Y_Hi4SpeILatMXo-vzY=.c69c035d-80c7-4715-be45-c5d0d7f61b33@github.com>
References: <ZkxFGxje18XFb3qVxeUqtcv1Y_Hi4SpeILatMXo-vzY=.c69c035d-80c7-4715-be45-c5d0d7f61b33@github.com>
Message-ID: <OmN0ufM3zp6YbT5SvEJbwUB1k2G-0bt8Qz7wn3Who40=.c37d00bc-468f-4812-a7aa-38edfd7e26db@github.com>

On Mon, 22 Mar 2021 15:49:24 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> From CR:
> The useful/general BasicHashtable uses a block allocation scheme to reportedly reduce fragmentation. When the StringTable and SymbolTable used to use this hashtable, performance benefits were reportedly observed because of the block allocation scheme. Since these tables were moved to the concurrent hashtables, the tables left that use the block allocation scheme are:
> 
> AdapterHandlerLibrary, ResolutionError, LoaderConstraints, Leak profiler bitset table and Placeholders. 3 of these tables are very small and never needed block allocation to prevent fragmentation at least. Also there are 3 KVHashtables, which are built from BasicHashtable. 2 are used during dumping and 1 is ID2KlassTable which appears small.
> 
> ModuleEntry, PackageEntry, Dictionary, G1RootSet for nmethods, and JvmtiTagMap tables didn't use the block allocation scheme.
> 
> Removing this removes 7 pointers per table, and for each ClassLoaderData, which has 3 tables, removes 21 pointers.
> 
> This change was performance tested on linux and windows.
> 
> It was also tested with tier1-6.

This pull request has now been integrated.

Changeset: 5bc382fb
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5bc382fb
Stats:     178 lines in 16 files changed: 10 ins; 131 del; 37 mod

8263976: Remove block allocation from BasicHashtable

Reviewed-by: lfoltan, iklam

-------------

PR: https://git.openjdk.java.net/jdk/pull/3123

From ksakata at openjdk.java.net  Tue Mar 23 12:22:40 2021
From: ksakata at openjdk.java.net (Koichi Sakata)
Date: Tue, 23 Mar 2021 12:22:40 GMT
Subject: RFR: 8263572: Output from jstack mixed mode is misaligned [v2]
In-Reply-To: <ow8sEOfs5APyob8NNGMU50pFLrEKvKutL4-eBBYIvXo=.ca56feb5-36fc-4413-95be-f1fcad885204@github.com>
References: <LiAjqiWikfy0llyWM79wX1pZQO4JkNsO8WwjWqcAAKg=.e177e030-08cf-42cd-aaee-27d530b5ed02@github.com>
 <Tk1-poV1F49pg7TH4c9636JUsJvTk0Q9cK-AZX3uPQM=.b5d134e9-f4bd-48d2-97c4-c8f7776077ad@github.com>
 <ow8sEOfs5APyob8NNGMU50pFLrEKvKutL4-eBBYIvXo=.ca56feb5-36fc-4413-95be-f1fcad885204@github.com>
Message-ID: <L8WyGiqPIbtraLUWV0UYwyeZhNRWkKWIuVC9cykFrmA=.1e9b4910-97f8-4a06-a82c-0b526417ccb3@github.com>

On Tue, 23 Mar 2021 02:49:52 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix calculation for the length of white space
>
> Hi Koichi,
> It looks good to me. Thank you for the contribution!
> Thanks,
> Serguei

Hi Serguei,
Thank you! I'll continue to contribute to OpenJDK.

Now this pull request is approved by two reviewers. Can someone sponsor it?

Regards,
Koichi

-------------

PR: https://git.openjdk.java.net/jdk/pull/3004

From ihse at openjdk.java.net  Tue Mar 23 12:52:56 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 23 Mar 2021 12:52:56 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
Message-ID: <ee0H_EQKtLdriO2ohEbSJTCgQLo6pkpNrM4q8gZkq1M=.6a33a0af-4134-4216-97fd-188bbfb7124b@github.com>

On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
> 
>  - Merge branch 'master' into jdk-macos
>  - JDK-8262491: bsd_aarch64 part
>  - JDK-8263002: bsd_aarch64 part
>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>  - Wider #ifdef block
>  - Fix most of issues in java/foreign/ tests
>    
>    Failures related to va_args are tracked in JDK-8263512.
>  - Add Azul copyright
>  - Update Oracle copyright years
>  - Use Thread::current_or_null_safe in SafeFetch
>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>  - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269

Build changes still look good. Hope you can get this done now! :)

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2200

From erikj at openjdk.java.net  Tue Mar 23 12:52:55 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 23 Mar 2021 12:52:55 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
Message-ID: <Xu_AFSUmt_tBHnpdHhAaUZOzuYq-L4_nGbwq_OMQk78=.8f69da0c-abd5-4688-855f-69cbbdc87770@github.com>

On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
> 
>  - Merge branch 'master' into jdk-macos
>  - JDK-8262491: bsd_aarch64 part
>  - JDK-8263002: bsd_aarch64 part
>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>  - Wider #ifdef block
>  - Fix most of issues in java/foreign/ tests
>    
>    Failures related to va_args are tracked in JDK-8263512.
>  - Add Azul copyright
>  - Update Oracle copyright years
>  - Use Thread::current_or_null_safe in SafeFetch
>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>  - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269

Build changes look good.

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2200

From david.holmes at oracle.com  Tue Mar 23 13:01:40 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 23 Mar 2021 23:01:40 +1000
Subject: RFR: 8264004: Don't use TRAPS if no exceptions are thrown [v2]
In-Reply-To: <on9nWqZmBZpzDWN__6thbttucJ-4E1kmwdAGoVvfZnA=.29d4b52a-2446-4e5b-96b7-fc7e63c5d826@github.com>
References: <1KBghJAnPzq1F4LTwaaa8sUTy-BiLlO4uXSmYC1XGPA=.46cc3327-0af0-409f-bf1a-07066c60b0de@github.com>
 <uYmLht5CfEs4CxvJQl5vCFBqoH5RitXnZY2lKG0Y7NM=.1c5b2fe2-9e95-41a7-84e3-d95e1a294d14@github.com>
 <pgPa6Dh3Bfe1vIGexjO2sFv6Oz-g4HBXPFums7mpSiQ=.de8aed74-a053-4921-aca1-a74ae5a728d7@github.com>
 <M0C36h2uqgZrcFQJ8TwdMqYYdpbhtc6NXuY6tQDZSJc=.265f359d-1569-4548-93a8-d5c8d67c30bf@github.com>
 <on9nWqZmBZpzDWN__6thbttucJ-4E1kmwdAGoVvfZnA=.29d4b52a-2446-4e5b-96b7-fc7e63c5d826@github.com>
Message-ID: <754425a7-49e7-d84b-f655-30a80e38e358@oracle.com>

On 23/03/2021 9:54 pm, Coleen Phillimore wrote:
> On Tue, 23 Mar 2021 05:52:51 GMT, Ioi Lam <iklam at openjdk.org> wrote:
> 
>>> src/hotspot/share/prims/jvmtiRedefineClasses.hpp line 484:
>>>
>>>> 482:   void rewrite_cp_refs_in_method(methodHandle method,
>>>> 483:     methodHandle * new_method_p, TRAPS);
>>>> 484:   bool rewrite_cp_refs_in_methods(InstanceKlass* scratch_class, TRAPS);
>>>
>>> This method clears any pending exception and so should not be a TRAPS method.
>>
>> `VM_RedefineClasses::load_new_class_versions` also seems to never throw. These functions should be changed to take a `Thread*` parameter, and should use `HandleMark em(thread);` to guarantee that an exception never leaves the function.
> 
> Both of these functions are good examples of the convention that we're trying to agree on.   In, load_new_class_versions, TRAPS is passed to materialize THREAD.  THREAD is used then in a lot of places, and also to pass to SystemDictionary::parse_stream(...TRAPS), which does have an exceptional return that must be handled.
> Removing TRAPS then adding:
> JavaThread* current = JavaThread::current();
> changing THREAD to current in most of the places seems ok, but passing 'current' to SystemDictionary::resolve_from_stream loses the information visually that this function returns an exception that must be handled.

Okay ...

Only a function that upon return may have directly, or indirectly, 
caused an exception to be pending should be declared with TRAPS. The 
caller is then expected to use the CHECK macros under most conditions.

If a function is going to call a TRAPS function but clear the exception, 
then it should manifest a THREAD variable and pass that, both to 
indicate the called function is TRAPS and to allow its own use of the 
exception macros that depend on THREAD. But that function should not 
itself declare TRAPS just to get THREAD.

How to manifest THREAD depends on the exact context, and we already have 
these cases today:
- Thread* THREAD = Thread::current();
- Thread* THREAD = <pre-existing current thread variable by some name>

In this case I would expect to see:

jvmtiError VM_RedefineClasses::load_new_class_versions(Thread* current) {
...
  ResourceMark rm(current);
  JvmtiThreadState *state = 
JvmtiThreadState::state_for(current->as_Java_thread());
...
   HandleMark hm(current);
...
   Handle the_class_loader(current, the_class->class_loader());
   Handle protection_domain(current, the_class->protection_domain());
...
   Thread* THREAD = current; // For exception processing
   InstanceKlass* scratch_class = SystemDictionary::parse_stream(
                                                       the_class_sym,
                                                       the_class_loader,
                                                       &st,
                                                       cl_info,
                                                       THREAD);
...
   if (HAS_PENDING_EXCEPTION) {
...
       the_class->link_class(THREAD);
       if (HAS_PENDING_EXCEPTION) {
...


I'll point out, to be clear that I recognise it, that the existing CATCH 
macro does not fit in with these conventions as you only apply CATCH to 
a function that never lets an exception escape, and such a function 
should not be declared TRAPS and should never be passed THREAD, but you 
need to manifest THREAD to use CATCH. I consider the CATCH macro to be a 
well-intentioned mistake.

> We need some meta-writeup rather than these decisions made in pull requests, because if we made these decisions collectively, I missed out.

Once we've fleshed things out we can propose them for the style guide. 
But it is easier to discuss concrete examples.

The important things (to me at least) at the moment are:

- we get rid of TRAPS from non-exception throwing code
- we pave the way to allow changing of TRAPS to declare "JavaThread* 
THREAD" so that functions that always expect to be called on a 
JavaThread can explicitly indicate that. (And that goes for non-TRAPS 
functions too.)
- we simplify/clarify code that uses an arbitrary mix of names for the 
current thread, and establish simple conventions to use going forward 
and to apply a-posteri on a time available basis when we do cleanups

Cheers,
David
-----

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3141
> 

From hseigel at openjdk.java.net  Tue Mar 23 13:16:42 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 23 Mar 2021 13:16:42 GMT
Subject: RFR: 8264004: Don't use TRAPS if no exceptions are thrown [v2]
In-Reply-To: <uYmLht5CfEs4CxvJQl5vCFBqoH5RitXnZY2lKG0Y7NM=.1c5b2fe2-9e95-41a7-84e3-d95e1a294d14@github.com>
References: <1KBghJAnPzq1F4LTwaaa8sUTy-BiLlO4uXSmYC1XGPA=.46cc3327-0af0-409f-bf1a-07066c60b0de@github.com>
 <uYmLht5CfEs4CxvJQl5vCFBqoH5RitXnZY2lKG0Y7NM=.1c5b2fe2-9e95-41a7-84e3-d95e1a294d14@github.com>
Message-ID: <BCzo4VSYwH19jJrlZuMsnEurmTadI0Y7lbaVqJ03zAs=.b7cc8f75-a55d-4a60-a91c-babb29d906f9@github.com>

On Tue, 23 Mar 2021 01:22:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Removed the TRAPS in function declarations in jvmtiRedefineClasses and in ConstantPool merging functions.
>> Tested with vmTestbase/nsk/jvmti and tier1 (in progress).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missed THREAD that should be CHECK_false argument.

src/hotspot/share/oops/constantPool.cpp line 1426:

> 1424:     bool match_entry = compare_entry_to(k1, cp2, k2);
> 1425:     bool match_operand = compare_operand_to(i1, cp2, i2);
> 1426:     return (match_entry && match_operand);

Is it worth changing this to:  If (compare_entry_to(...) && compare_operand_to(..)) { .. }
Then if the first one is false the second call isn't needed?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3141

From akozlov at openjdk.java.net  Tue Mar 23 13:28:52 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 23 Mar 2021 13:28:52 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: <ee0H_EQKtLdriO2ohEbSJTCgQLo6pkpNrM4q8gZkq1M=.6a33a0af-4134-4216-97fd-188bbfb7124b@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
 <ee0H_EQKtLdriO2ohEbSJTCgQLo6pkpNrM4q8gZkq1M=.6a33a0af-4134-4216-97fd-188bbfb7124b@github.com>
Message-ID: <VELjoQXnn9AqZJ5xS5fBeZITIpOuJ7_AyRr7Vxl5m0I=.8ec3a1cd-6af2-4bb7-9c43-2fa4a1474a24@github.com>

On Tue, 23 Mar 2021 12:49:34 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
>> 
>>  - Merge branch 'master' into jdk-macos
>>  - JDK-8262491: bsd_aarch64 part
>>  - JDK-8263002: bsd_aarch64 part
>>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>>  - Wider #ifdef block
>>  - Fix most of issues in java/foreign/ tests
>>    
>>    Failures related to va_args are tracked in JDK-8263512.
>>  - Add Azul copyright
>>  - Update Oracle copyright years
>>  - Use Thread::current_or_null_safe in SafeFetch
>>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>>  - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269
>
> Build changes still look good. Hope you can get this done now! :)

> > No, no, no! I am not suggesting you change anything else, just that
> > you do not define contentless macros. You might as well define it
> > to be something, and true is a reasonable default, that's all. It's
> > not terribly important, it's just good practice.
> 
> I'm quite prepared to drop this if it's holding up the port. It's a style thing, but it's not critical.

Sorry, I missed your reply.

R18_RESERVED is also defined in https://github.com/openjdk/jdk/blob/master/make/hotspot/gensrc/GensrcAdlc.gmk#L96. I think changing the value here and there would be slightly out of the scope of this PR, so I would prefer to avoid the suggested change. 

The biggest argument from my side is that the current macro value is consistent with the rest of the macros in this file. For example https://github.com/openjdk/jdk/blob/8c1ab38ee20ed61fefbb64b6a9ee605c52d2cb4e/src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp#L35
and https://github.com/openjdk/jdk/blob/b7b391b2ac4208eabdee4e93acd5b0e364953f94/src/hotspot/share/runtime/mutexLocker.cpp#L137

But https://github.com/openjdk/jdk/blob/8c1ab38ee20ed61fefbb64b6a9ee605c52d2cb4e/src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp#L59
and       
https://github.com/openjdk/jdk/blob/b23228d152ff8fa27bd32d9ef1307bf315039dea/src/hotspot/share/runtime/arguments.cpp#L1540

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From ksakata at openjdk.java.net  Tue Mar 23 13:35:05 2021
From: ksakata at openjdk.java.net (Koichi Sakata)
Date: Tue, 23 Mar 2021 13:35:05 GMT
Subject: RFR: 8176026: SA: Huge heap sizes cause a negative value to be
 displayed in the jhisto heap total [v2]
In-Reply-To: <h_pqXvxIEJRhxH3sEA5fO8Z1XidOU3aZZij_ZVUx1kw=.1cf3982e-7dac-4d2d-80a0-9629eb50c203@github.com>
References: <h_pqXvxIEJRhxH3sEA5fO8Z1XidOU3aZZij_ZVUx1kw=.1cf3982e-7dac-4d2d-80a0-9629eb50c203@github.com>
Message-ID: <-OxCoBAqyBOqOS5DP3C4NPkq8PFLwwCL6wBXmiqeEzU=.f62e8e0f-418e-4129-a91a-c10e1571466e@github.com>

> When a heap is used more than about 2.1GB, clhsdb jhisto shows a negative number in the total field.
> 
> $ java -Xmx20g Sample
> 
> $ jhsdb clhsdb --pid 5773
> Attaching to process 5773, please wait...
> hsdb> jhisto
> ...
> 299:            1       16      jdk.internal.misc.Unsafe
> 300:            3402    10737610256     byte[]
> Total :         15823   -2146661280
> Heap traversal took 1.793 seconds.
> (Incidentally, the Sample is a program that only allocates many objects.)
> 
> #### Details
> This is because in ObjectHistogram class the totalSize variable is int type.
> 
> The total size is the total of ObjectHistogramElement#getSize() and getSize() returns long. So I changed int to long in the ObjectHistogram class.
> 
> Additionally, I changed the type of the totalCount. This doesn't cause a bug, but ObjectHistogramElement#getCount() also returns long. So it doesn't need to treat it as int, I think.
> 
> #### Tests
> The jtreg test was successful.
> $ sudo make run-test TEST=serviceability/sa/ClhsdbJhisto.java
> 
> $ cat build/linux-x86_64-server-fastdebug/test-results/jtreg_test_hotspot_jtreg_serviceability_sa_ClhsdbJhisto_java/text/summary.txt
> serviceability/sa/ClhsdbJhisto.java  Passed. Execution successful
> 
> I confirmed the output with the same program.
> 
> $ ./jdk/build/linux-x86_64-server-fastdebug/jdk/bin/java -Xmx20g Sample
> $ ./jdk/build/linux-x86_64-server-fastdebug/jdk/bin/jhsdb clhsdb --pid 22463
> Attaching to process 22463, please wait...
> hsdb> jhisto
> 
> 300:            3410    19327547600     byte[]
> Total :         16145   19328155080
> Heap traversal took 1.981 seconds.

Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision:

  Fix the sort bug for huge bytes in jhisto

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3087/files
  - new: https://git.openjdk.java.net/jdk/pull/3087/files/a9447ca4..248d49fe

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3087&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3087&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3087.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3087/head:pull/3087

PR: https://git.openjdk.java.net/jdk/pull/3087

From hseigel at openjdk.java.net  Tue Mar 23 13:37:40 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 23 Mar 2021 13:37:40 GMT
Subject: RFR: 8264004: Don't use TRAPS if no exceptions are thrown [v2]
In-Reply-To: <uYmLht5CfEs4CxvJQl5vCFBqoH5RitXnZY2lKG0Y7NM=.1c5b2fe2-9e95-41a7-84e3-d95e1a294d14@github.com>
References: <1KBghJAnPzq1F4LTwaaa8sUTy-BiLlO4uXSmYC1XGPA=.46cc3327-0af0-409f-bf1a-07066c60b0de@github.com>
 <uYmLht5CfEs4CxvJQl5vCFBqoH5RitXnZY2lKG0Y7NM=.1c5b2fe2-9e95-41a7-84e3-d95e1a294d14@github.com>
Message-ID: <5XKapnZtZxjCTYxbXI4iep2_lzry40YppJM554ao4vI=.abb36d69-f855-4fbb-a8cd-e1ea32ab1c40@github.com>

On Tue, 23 Mar 2021 01:22:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Removed the TRAPS in function declarations in jvmtiRedefineClasses and in ConstantPool merging functions.
>> Tested with vmTestbase/nsk/jvmti and tier1 (in progress).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missed THREAD that should be CHECK_false argument.

The changes look good!
Thanks, Harold

-------------

Marked as reviewed by hseigel (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3141

From coleenp at openjdk.java.net  Tue Mar 23 13:37:41 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 23 Mar 2021 13:37:41 GMT
Subject: RFR: 8264004: Don't use TRAPS if no exceptions are thrown [v2]
In-Reply-To: <BCzo4VSYwH19jJrlZuMsnEurmTadI0Y7lbaVqJ03zAs=.b7cc8f75-a55d-4a60-a91c-babb29d906f9@github.com>
References: <1KBghJAnPzq1F4LTwaaa8sUTy-BiLlO4uXSmYC1XGPA=.46cc3327-0af0-409f-bf1a-07066c60b0de@github.com>
 <uYmLht5CfEs4CxvJQl5vCFBqoH5RitXnZY2lKG0Y7NM=.1c5b2fe2-9e95-41a7-84e3-d95e1a294d14@github.com>
 <BCzo4VSYwH19jJrlZuMsnEurmTadI0Y7lbaVqJ03zAs=.b7cc8f75-a55d-4a60-a91c-babb29d906f9@github.com>
Message-ID: <TPWUJ6377ch7pudqGGZQYle7cjrxzBDYx5Z-3i-5qT4=.fd7a3c21-0298-408f-8431-f0c5b770e038@github.com>

On Tue, 23 Mar 2021 13:14:15 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   missed THREAD that should be CHECK_false argument.
>
> src/hotspot/share/oops/constantPool.cpp line 1426:
> 
>> 1424:     bool match_entry = compare_entry_to(k1, cp2, k2);
>> 1425:     bool match_operand = compare_operand_to(i1, cp2, i2);
>> 1426:     return (match_entry && match_operand);
> 
> Is it worth changing this to:  return (compare_entry_to(...) && compare_operand_to(..));
> Then if the first one is false the second call isn't needed?

I kind of thought these would make a long complicated expression and so the single use variables is helpful.  I don't think performance is important here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3141

From coleenp at openjdk.java.net  Tue Mar 23 13:42:42 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 23 Mar 2021 13:42:42 GMT
Subject: RFR: 8264004: Don't use TRAPS if no exceptions are thrown [v2]
In-Reply-To: <TPWUJ6377ch7pudqGGZQYle7cjrxzBDYx5Z-3i-5qT4=.fd7a3c21-0298-408f-8431-f0c5b770e038@github.com>
References: <1KBghJAnPzq1F4LTwaaa8sUTy-BiLlO4uXSmYC1XGPA=.46cc3327-0af0-409f-bf1a-07066c60b0de@github.com>
 <uYmLht5CfEs4CxvJQl5vCFBqoH5RitXnZY2lKG0Y7NM=.1c5b2fe2-9e95-41a7-84e3-d95e1a294d14@github.com>
 <BCzo4VSYwH19jJrlZuMsnEurmTadI0Y7lbaVqJ03zAs=.b7cc8f75-a55d-4a60-a91c-babb29d906f9@github.com>
 <TPWUJ6377ch7pudqGGZQYle7cjrxzBDYx5Z-3i-5qT4=.fd7a3c21-0298-408f-8431-f0c5b770e038@github.com>
Message-ID: <SYs6Px0DWxxDjUHtY-IOcxlLlj0ro_TZhHW8-lT2HD0=.5f11d0e6-0549-47e1-8d5c-a634b569e80e@github.com>

On Tue, 23 Mar 2021 13:33:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/oops/constantPool.cpp line 1426:
>> 
>>> 1424:     bool match_entry = compare_entry_to(k1, cp2, k2);
>>> 1425:     bool match_operand = compare_operand_to(i1, cp2, i2);
>>> 1426:     return (match_entry && match_operand);
>> 
>> Is it worth changing this to:  return (compare_entry_to(...) && compare_operand_to(..));
>> Then if the first one is false the second call isn't needed?
>
> I kind of thought these would make a long complicated expression and so the single use variables is helpful.  I don't think performance is important here.

{code}
      -      match = compare_entry_to(recur1, cp2, recur2);
      -      if (match) {
     +      if (compare_entry_to(recur1, cp2, recur2)) {
              return true;
            }
I could do this

-------------

PR: https://git.openjdk.java.net/jdk/pull/3141

From vkempik at openjdk.java.net  Tue Mar 23 13:47:49 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Tue, 23 Mar 2021 13:47:49 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: <VELjoQXnn9AqZJ5xS5fBeZITIpOuJ7_AyRr7Vxl5m0I=.8ec3a1cd-6af2-4bb7-9c43-2fa4a1474a24@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
 <ee0H_EQKtLdriO2ohEbSJTCgQLo6pkpNrM4q8gZkq1M=.6a33a0af-4134-4216-97fd-188bbfb7124b@github.com>
 <VELjoQXnn9AqZJ5xS5fBeZITIpOuJ7_AyRr7Vxl5m0I=.8ec3a1cd-6af2-4bb7-9c43-2fa4a1474a24@github.com>
Message-ID: <T87R9g8k9sUgph0vNreusY9OU1KJ438OoWvqz75qNfY=.05d35de2-8566-4f10-8780-86e79bbce005@github.com>

On Tue, 23 Mar 2021 13:26:19 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Build changes still look good. Hope you can get this done now! :)
>
>> > No, no, no! I am not suggesting you change anything else, just that
>> > you do not define contentless macros. You might as well define it
>> > to be something, and true is a reasonable default, that's all. It's
>> > not terribly important, it's just good practice.
>> 
>> I'm quite prepared to drop this if it's holding up the port. It's a style thing, but it's not critical.
> 
> Sorry, I missed your reply.
> 
> R18_RESERVED is also defined in https://github.com/openjdk/jdk/blob/master/make/hotspot/gensrc/GensrcAdlc.gmk#L96. I think changing the value here and there would be slightly out of the scope of this PR, so I would prefer to avoid the suggested change. 
> 
> The biggest argument from my side is that the current macro value is consistent with the rest of the macros in this file. For example https://github.com/openjdk/jdk/blob/8c1ab38ee20ed61fefbb64b6a9ee605c52d2cb4e/src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp#L35
> and https://github.com/openjdk/jdk/blob/b7b391b2ac4208eabdee4e93acd5b0e364953f94/src/hotspot/share/runtime/mutexLocker.cpp#L137
> 
> But https://github.com/openjdk/jdk/blob/8c1ab38ee20ed61fefbb64b6a9ee605c52d2cb4e/src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp#L59
> and       
> https://github.com/openjdk/jdk/blob/b23228d152ff8fa27bd32d9ef1307bf315039dea/src/hotspot/share/runtime/arguments.cpp#L1540

Hello
That depends on the will of openjdk11 maintainers to accept this (and few other, like jep-388, as we depend on it) contribution.

> 23 ????? 2021 ?., ? 16:39, drej1 ***@***.***> ???????(?):
> 
> 
> So, where are we up to now? Are we done yet?
> 
> Hello
> we would like to get approval for the final version we have now and then integrate this pr as soon as Mark will target it to jdk17
> 
> Hi there, will this be also supported backwards? To support java11 LTS version?
> 
> ?
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub <https://github.com/openjdk/jdk/pull/2200#issuecomment-804910300>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQS2KRC6LT7BKA37RMS5I5DTFCKX7ANCNFSM4WO4SQXQ>.
>

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From aph at openjdk.java.net  Tue Mar 23 13:56:59 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 23 Mar 2021 13:56:59 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
Message-ID: <RJPhWu2ZJPvYw-KPhSNjl-pzzrgjplu6BKzBIqaaydc=.c94c5bac-4490-4b86-a619-2e53253abdce@github.com>

On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
> 
>  - Merge branch 'master' into jdk-macos
>  - JDK-8262491: bsd_aarch64 part
>  - JDK-8263002: bsd_aarch64 part
>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>  - Wider #ifdef block
>  - Fix most of issues in java/foreign/ tests
>    
>    Failures related to va_args are tracked in JDK-8263512.
>  - Add Azul copyright
>  - Update Oracle copyright years
>  - Use Thread::current_or_null_safe in SafeFetch
>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>  - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269

Marked as reviewed by aph (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From aph at openjdk.java.net  Tue Mar 23 14:00:58 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 23 Mar 2021 14:00:58 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: <RJPhWu2ZJPvYw-KPhSNjl-pzzrgjplu6BKzBIqaaydc=.c94c5bac-4490-4b86-a619-2e53253abdce@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
 <RJPhWu2ZJPvYw-KPhSNjl-pzzrgjplu6BKzBIqaaydc=.c94c5bac-4490-4b86-a619-2e53253abdce@github.com>
Message-ID: <EV4vZgtlo7uhG-pv-x40pOoE9_JNS_4sm1q-xtA1x2w=.4e7eb6ea-fefb-452c-b127-dc478c629eaa@github.com>

On Tue, 23 Mar 2021 13:54:24 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
>> 
>>  - Merge branch 'master' into jdk-macos
>>  - JDK-8262491: bsd_aarch64 part
>>  - JDK-8263002: bsd_aarch64 part
>>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>>  - Wider #ifdef block
>>  - Fix most of issues in java/foreign/ tests
>>    
>>    Failures related to va_args are tracked in JDK-8263512.
>>  - Add Azul copyright
>>  - Update Oracle copyright years
>>  - Use Thread::current_or_null_safe in SafeFetch
>>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>>  - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269
>
> Marked as reviewed by aph (Reviewer).

> [ Back-porting this patch to JDK 11] depends on the will of openjdk11 maintainers to accept this (and few other, like jep-388, as we depend on it) contribution.

To the extent that 11u has fixed policies :)  we definitely have a policy of accepting patches to keep 11u working on current hardware. So yes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From vkempik at openjdk.java.net  Tue Mar 23 14:03:52 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Tue, 23 Mar 2021 14:03:52 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: <EV4vZgtlo7uhG-pv-x40pOoE9_JNS_4sm1q-xtA1x2w=.4e7eb6ea-fefb-452c-b127-dc478c629eaa@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
 <RJPhWu2ZJPvYw-KPhSNjl-pzzrgjplu6BKzBIqaaydc=.c94c5bac-4490-4b86-a619-2e53253abdce@github.com>
 <EV4vZgtlo7uhG-pv-x40pOoE9_JNS_4sm1q-xtA1x2w=.4e7eb6ea-fefb-452c-b127-dc478c629eaa@github.com>
Message-ID: <sEsT_ZQ0CBgs8Xc8h1NE32bgZ9SGwyIZ2o8Jl8Hx5cY=.3febcdec-8b29-457a-82fa-123c2a98c328@github.com>

On Tue, 23 Mar 2021 13:58:03 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > [ Back-porting this patch to JDK 11] depends on the will of openjdk11 maintainers to accept this (and few other, like jep-388, as we depend on it) contribution.
> 
> To the extent that 11u has fixed policies :) we definitely have a policy of accepting patches to keep 11u working on current hardware. So yes.

@lewurm That sounds like a green flag for you and jep-388 (with its R18_RESERVED functionality) ;)

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From ksakata at openjdk.java.net  Tue Mar 23 14:09:40 2021
From: ksakata at openjdk.java.net (Koichi Sakata)
Date: Tue, 23 Mar 2021 14:09:40 GMT
Subject: RFR: 8176026: SA: Huge heap sizes cause a negative value to be
 displayed in the jhisto heap total [v2]
In-Reply-To: <KL-ucPhcexqe_zD0xC2Ngup_mDl_m1B7FCqwqmur4Go=.71239ad8-c2ec-4df7-aaef-d7f1309005e6@github.com>
References: <h_pqXvxIEJRhxH3sEA5fO8Z1XidOU3aZZij_ZVUx1kw=.1cf3982e-7dac-4d2d-80a0-9629eb50c203@github.com>
 <KL-ucPhcexqe_zD0xC2Ngup_mDl_m1B7FCqwqmur4Go=.71239ad8-c2ec-4df7-aaef-d7f1309005e6@github.com>
Message-ID: <I3RFL1Hk_WLbdvjXwz--BNhNm18Euu9MJSVmdHykqL4=.ad15cefd-7c50-49e2-89af-5579744e48ab@github.com>

On Fri, 19 Mar 2021 19:40:13 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix the sort bug for huge bytes in jhisto
>
> I see another cast-to-int related bug, and it's visible in your jhisto output (both before and after):
> 
> 304: 1 16 jdk.internal.perf.Perf
> 305: 1 16 java.util.jar.JavaUtilJarAccessImpl
> 306: 254 2863336944 int[]
> Total : 22803 -1430650672 
> 
> The large `int[]` array should be at the top of the list, not the bottom. The issue is in ObjectHistogramElement.java:
> 
>   public int compare(ObjectHistogramElement other) {
>     return (int) (other.size - size);
>   }
> 
> So this will result in the returned value having the wrong sign if the difference between `other.size` and `size` is too large.  In ObjectHistogram.java, just above the code you fixed, we have:
> 
>   public List<ObjectHistogramElement> getElements() {
>     List<ObjectHistogramElement> list = new ArrayList<>();
>     list.addAll(map.values());
>     Collections.sort(list, new Comparator<>() {
>       public int compare(ObjectHistogramElement o1, ObjectHistogramElement o2) {
>         return o1.compare(o2);
>       }
>     });
>     return list;
>   }
> So it looks like this is calling the buggy `compare()` method. I think the fix is to have `compare()` return -1, 0, or 1 depending on the `long` value of `(other.size - size)`, rather than just trying to return `(other.size - size)`.

@plummercj That is right! I fixed that bug and pasted the latest output of jhisto to the body. Of course I re-ran the jtreg test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3087

From dcubed at openjdk.java.net  Tue Mar 23 14:13:42 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 23 Mar 2021 14:13:42 GMT
Subject: RFR: 8262881: port JVM/DI tests from JDK-4413752 to JVM/TI [v2]
In-Reply-To: <fA0PdwEJ8CGXaEB7etUKosA4-4loLHXIKNTbxNQzsdc=.eb457518-0a73-4385-bb8d-86ef2a0a014b@github.com>
References: <XOECrKnBcmSRjfY2cM-GqFs3jMr0fTy7KJUCUHZ0HGw=.54872a68-97e9-481a-871e-eade80a51604@github.com>
 <pIS66umBFPY0bsix6EW_zdVNzFG5J6A33FHVrpvEJ64=.c3cc75d9-25cd-4fc0-b3bc-35fe628d5e2c@github.com>
 <FTPu45SOPngFqXyPfuBhBewCMrOKmxVWMM1c5shSAk0=.f2ae0a1f-d047-4e38-9646-973cea5d14bd@github.com>
 <mt28C9CCpgvEssnL1Wo548FPnwpC3dkZlNlUy8IswcQ=.b0b9439a-7dbd-4fb7-b634-cad50617f38b@github.com>
 <N2ttOL2H2afquWau8ZwL41-V1XapL9O7HoZvIuPw7UA=.073dac9f-ba95-4caf-950f-f0576e93732f@github.com>
 <fA0PdwEJ8CGXaEB7etUKosA4-4loLHXIKNTbxNQzsdc=.eb457518-0a73-4385-bb8d-86ef2a0a014b@github.com>
Message-ID: <b8MW88KMcGQ5pmial0JpRyYo3WSkxHkurBUCXigmXDg=.5728035a-26c0-46b6-9f54-1a8b34c2b9fc@github.com>

On Tue, 23 Mar 2021 01:47:45 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> @robehn - Thanks for the review and for the suggested improvements to the tests.
>> It will take me a bit of time to make and test these suggestions.
>
> Hi Dan,
>> I figured you would enjoy this 20 year old blast from the past!
> Yes, of course, but these tests look like they have been written today! :)
> 
> Thank you for making changes!
> I've just noticed one minor issue:
> 
> libSuspendWithObjectMonitorEnter.cpp
> libSuspendWithObjectMonitorWait.cpp:
> The static variables below are not used and can be removed:
>  32 static jrawMonitorID threadLock = NULL;
>  33 static char threadLockName[] = "threadLock";
> 
> Thanks,
> Serguei

@sspitsyn - Thanks for the re-review. I'll take care of the unused variables
and I'll do an audit of all three tests and look for more.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2899

From mbeckwit at openjdk.java.net  Tue Mar 23 14:27:53 2021
From: mbeckwit at openjdk.java.net (Monica Beckwith)
Date: Tue, 23 Mar 2021 14:27:53 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: <sEsT_ZQ0CBgs8Xc8h1NE32bgZ9SGwyIZ2o8Jl8Hx5cY=.3febcdec-8b29-457a-82fa-123c2a98c328@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
 <RJPhWu2ZJPvYw-KPhSNjl-pzzrgjplu6BKzBIqaaydc=.c94c5bac-4490-4b86-a619-2e53253abdce@github.com>
 <EV4vZgtlo7uhG-pv-x40pOoE9_JNS_4sm1q-xtA1x2w=.4e7eb6ea-fefb-452c-b127-dc478c629eaa@github.com>
 <sEsT_ZQ0CBgs8Xc8h1NE32bgZ9SGwyIZ2o8Jl8Hx5cY=.3febcdec-8b29-457a-82fa-123c2a98c328@github.com>
Message-ID: <yPvOw_97zvTpNmDvNRx0B8qqBIoqlnbJY5erdMrSTog=.0be084ee-92cd-4466-9120-9079aa5d9db3@github.com>

On Tue, 23 Mar 2021 14:01:12 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

> > > [ Back-porting this patch to JDK 11] depends on the will of openjdk11 maintainers to accept this (and few other, like jep-388, as we depend on it) contribution.
> > 
> > 
> > To the extent that 11u has fixed policies :) we definitely have a policy of accepting patches to keep 11u working on current hardware. So yes.
> 
> @lewurm That sounds like a green flag for you and jep-388 (with its R18_RESERVED functionality) ;)

Thanks, @theRealAph, and @VladimirKempik . We are on it!

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From dcubed at openjdk.java.net  Tue Mar 23 14:28:46 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 23 Mar 2021 14:28:46 GMT
Subject: RFR: 8262881: port JVM/DI tests from JDK-4413752 to JVM/TI [v2]
In-Reply-To: <dhvs0X9kIhM_K0-b978ErwPXkaF26lctQt35M0dTJxE=.118a02b2-b65c-4e2b-a637-6b5d6e70f3d4@github.com>
References: <XOECrKnBcmSRjfY2cM-GqFs3jMr0fTy7KJUCUHZ0HGw=.54872a68-97e9-481a-871e-eade80a51604@github.com>
 <wUCvQfmlMD5sMgBEIDspFQigcEMfmJWrJW6LcRxdFJo=.46453b48-b28f-4740-80b5-0909e980d1c7@github.com>
 <dhvs0X9kIhM_K0-b978ErwPXkaF26lctQt35M0dTJxE=.118a02b2-b65c-4e2b-a637-6b5d6e70f3d4@github.com>
Message-ID: <t2xUDCqO-9ONpYTL0W85OUwmcOMb9ucoot9mB5-YFoQ=.59c3931f-7194-4a8b-b1e7-f8c0626c7a88@github.com>

On Sun, 21 Mar 2021 15:15:54 GMT, lyndseyBeil <github.com+81080647+lyndseyBeil at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   sspitsyn - fix white space indents problems.
>
> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorEnter/SuspendWithObjectMonitorEnter.java line 92:
> 
>> 90:     native static int GetResult();
>> 91:     native static void SetPrintDebug();
>> 92:     native static void SuspendThread(int id, SuspendWithObjectMonitorEnterWorker thr);
> 
> I detect that this code is problematic. According to the [Bad practice (BAD_PRACTICE)](https://spotbugs.readthedocs.io/en/stable/bugDescriptions.html#bad-practice-bad-practice), [Nm: Method names should start with a lower case letter (NM_METHOD_NAMING_CONVENTION)](https://spotbugs.readthedocs.io/en/stable/bugDescriptions.html#nm-method-names-should-start-with-a-lower-case-letter-nm-method-naming-convention).
> Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized.

Nice catch. In the original 20 year old test those methods were:
    native static int diobj4413752GetMonitorInfo(int id, Object mon);
    native static int diobj4413752GetResult();
    native static int diobj4413752SuspendThread(int id, diobjWorker thr);
    native static int diobj4413752Wait4ContendedEnter(int id, diobjWorker thr);
so when I got rid of the `diobj4413752` prefix I forgot to fix the new first letter.
I'll take care of those method renames and I'll double check for others.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2899

From coleenp at openjdk.java.net  Tue Mar 23 15:05:59 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 23 Mar 2021 15:05:59 GMT
Subject: RFR: 8264004: Don't use TRAPS if no exceptions are thrown [v3]
In-Reply-To: <1KBghJAnPzq1F4LTwaaa8sUTy-BiLlO4uXSmYC1XGPA=.46cc3327-0af0-409f-bf1a-07066c60b0de@github.com>
References: <1KBghJAnPzq1F4LTwaaa8sUTy-BiLlO4uXSmYC1XGPA=.46cc3327-0af0-409f-bf1a-07066c60b0de@github.com>
Message-ID: <vM0gdgROhY6fPNtDJOIBJO4BqnOFp5DhAk7lRbRNm30=.ab48b8c9-942c-4487-b541-8ab5ac179f9d@github.com>

> Removed the TRAPS in function declarations in jvmtiRedefineClasses and in ConstantPool merging functions.
> Tested with vmTestbase/nsk/jvmti and tier1 (in progress).

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix some obvious single use variables.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3141/files
  - new: https://git.openjdk.java.net/jdk/pull/3141/files/1e3f00d4..36006162

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3141&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3141&range=01-02

  Stats: 14 lines in 1 file changed: 0 ins; 7 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3141.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3141/head:pull/3141

PR: https://git.openjdk.java.net/jdk/pull/3141

From shade at openjdk.java.net  Tue Mar 23 15:11:50 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 23 Mar 2021 15:11:50 GMT
Subject: RFR: 8264050: Remove unused field
 VM_HeapWalkOperation::_collecting_heap_roots
Message-ID: <jx3PUDxkUXv-UzofQAxxTlVGfipkCCPaXXEaZZ96OHM=.13a22fe4-25f2-4eb1-b4ee-af0394d4392a@github.com>

SonarCloud reports field `_collecting_heap_roots` is not initialized after constructor ends. In fact, that field is not used anywhere. It was like that since the initial load. We can trivially remove it.

-------------

Commit messages:
 - 8264050: Remove unused field VM_HeapWalkOperation::_collecting_heap_roots

Changes: https://git.openjdk.java.net/jdk/pull/3153/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3153&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264050
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3153.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3153/head:pull/3153

PR: https://git.openjdk.java.net/jdk/pull/3153

From coleenp at openjdk.java.net  Tue Mar 23 15:19:41 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 23 Mar 2021 15:19:41 GMT
Subject: RFR: 8264050: Remove unused field
 VM_HeapWalkOperation::_collecting_heap_roots
In-Reply-To: <jx3PUDxkUXv-UzofQAxxTlVGfipkCCPaXXEaZZ96OHM=.13a22fe4-25f2-4eb1-b4ee-af0394d4392a@github.com>
References: <jx3PUDxkUXv-UzofQAxxTlVGfipkCCPaXXEaZZ96OHM=.13a22fe4-25f2-4eb1-b4ee-af0394d4392a@github.com>
Message-ID: <It7zG03dSUKNofUSNh1OltvJd4BKkBWgJ517XCnXHDA=.a7881cdf-365a-407b-9354-477faf5e50cb@github.com>

On Tue, 23 Mar 2021 15:06:02 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports field `_collecting_heap_roots` is not initialized after constructor ends. In fact, that field is not used anywhere. It was like that since the initial load. We can trivially remove it.

SCCS says it was used once. Thanks for removing it.

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3153

From mbeckwit at openjdk.java.net  Tue Mar 23 15:27:56 2021
From: mbeckwit at openjdk.java.net (Monica Beckwith)
Date: Tue, 23 Mar 2021 15:27:56 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
Message-ID: <8y8WYVmVF_qrroxDo516Ucz1qWX5kMpPQHeqZgJNI2Q=.004fe86c-2b18-4a90-8499-1a34e64da3db@github.com>

On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
> 
>  - Merge branch 'master' into jdk-macos
>  - JDK-8262491: bsd_aarch64 part
>  - JDK-8263002: bsd_aarch64 part
>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>  - Wider #ifdef block
>  - Fix most of issues in java/foreign/ tests
>    
>    Failures related to va_args are tracked in JDK-8263512.
>  - Add Azul copyright
>  - Update Oracle copyright years
>  - Use Thread::current_or_null_safe in SafeFetch
>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>  - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269

Marked as reviewed by mbeckwit (Author).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From hseigel at openjdk.java.net  Tue Mar 23 15:38:42 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 23 Mar 2021 15:38:42 GMT
Subject: RFR: 8264004: Don't use TRAPS if no exceptions are thrown [v3]
In-Reply-To: <vM0gdgROhY6fPNtDJOIBJO4BqnOFp5DhAk7lRbRNm30=.ab48b8c9-942c-4487-b541-8ab5ac179f9d@github.com>
References: <1KBghJAnPzq1F4LTwaaa8sUTy-BiLlO4uXSmYC1XGPA=.46cc3327-0af0-409f-bf1a-07066c60b0de@github.com>
 <vM0gdgROhY6fPNtDJOIBJO4BqnOFp5DhAk7lRbRNm30=.ab48b8c9-942c-4487-b541-8ab5ac179f9d@github.com>
Message-ID: <vJKsUPJa3LfrC_untBN0JqehNAf_5VOVdkMLkvA-F6o=.4e29819d-ff56-4af9-9ecf-ea08d1e0548d@github.com>

On Tue, 23 Mar 2021 15:05:59 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Removed the TRAPS in function declarations in jvmtiRedefineClasses and in ConstantPool merging functions.
>> Tested with vmTestbase/nsk/jvmti and tier1 (in progress).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix some obvious single use variables.

Latest changes look good.
Thanks, Harold

-------------

Marked as reviewed by hseigel (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3141

From coleenp at openjdk.java.net  Tue Mar 23 15:48:43 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 23 Mar 2021 15:48:43 GMT
Subject: RFR: 8264004: Don't use TRAPS if no exceptions are thrown [v3]
In-Reply-To: <vJKsUPJa3LfrC_untBN0JqehNAf_5VOVdkMLkvA-F6o=.4e29819d-ff56-4af9-9ecf-ea08d1e0548d@github.com>
References: <1KBghJAnPzq1F4LTwaaa8sUTy-BiLlO4uXSmYC1XGPA=.46cc3327-0af0-409f-bf1a-07066c60b0de@github.com>
 <vM0gdgROhY6fPNtDJOIBJO4BqnOFp5DhAk7lRbRNm30=.ab48b8c9-942c-4487-b541-8ab5ac179f9d@github.com>
 <vJKsUPJa3LfrC_untBN0JqehNAf_5VOVdkMLkvA-F6o=.4e29819d-ff56-4af9-9ecf-ea08d1e0548d@github.com>
Message-ID: <HfhqyaAW-Iu7Oxzd_FmdR0HZXslXSMghkJARJZdWjDM=.f01a812d-a56b-426d-a0e8-457801c3a38b@github.com>

On Tue, 23 Mar 2021 15:36:02 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix some obvious single use variables.
>
> Latest changes look good.
> Thanks, Harold

In your comments above, this makes sense to me:
Thread* THREAD = current; // For exception processing
This way we can keep the existing macros HAS_PENDING_EXCEPTION, etc.
I'll make this change here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3141

From coleenp at openjdk.java.net  Tue Mar 23 16:08:59 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 23 Mar 2021 16:08:59 GMT
Subject: RFR: 8264004: Don't use TRAPS if no exceptions are thrown [v4]
In-Reply-To: <1KBghJAnPzq1F4LTwaaa8sUTy-BiLlO4uXSmYC1XGPA=.46cc3327-0af0-409f-bf1a-07066c60b0de@github.com>
References: <1KBghJAnPzq1F4LTwaaa8sUTy-BiLlO4uXSmYC1XGPA=.46cc3327-0af0-409f-bf1a-07066c60b0de@github.com>
Message-ID: <s4YsC_lkc8BSre0H2G03vTNkAOWyUneoCvzNyuoqizQ=.77b91340-600d-433a-aa89-64379e2e446f@github.com>

> Removed the TRAPS in function declarations in jvmtiRedefineClasses and in ConstantPool merging functions.
> Tested with vmTestbase/nsk/jvmti and tier1 (in progress).

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix load_new_class_versions and remove more traps.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3141/files
  - new: https://git.openjdk.java.net/jdk/pull/3141/files/36006162..9134ce0b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3141&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3141&range=02-03

  Stats: 21 lines in 2 files changed: 4 ins; 2 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3141.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3141/head:pull/3141

PR: https://git.openjdk.java.net/jdk/pull/3141

From luhenry at openjdk.java.net  Tue Mar 23 16:23:54 2021
From: luhenry at openjdk.java.net (Ludovic Henry)
Date: Tue, 23 Mar 2021 16:23:54 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
Message-ID: <RIXlvES_OOQ47-4YI1CLX7kLG4JJ70NRr0g0G0X6zb0=.4a106aa2-8e76-4b5a-9206-cebc6f17472e@github.com>

On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
> 
>  - Merge branch 'master' into jdk-macos
>  - JDK-8262491: bsd_aarch64 part
>  - JDK-8263002: bsd_aarch64 part
>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>  - Wider #ifdef block
>  - Fix most of issues in java/foreign/ tests
>    
>    Failures related to va_args are tracked in JDK-8263512.
>  - Add Azul copyright
>  - Update Oracle copyright years
>  - Use Thread::current_or_null_safe in SafeFetch
>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>  - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269

Marked as reviewed by luhenry (Author).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From dcubed at openjdk.java.net  Tue Mar 23 16:35:43 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 23 Mar 2021 16:35:43 GMT
Subject: RFR: 8264004: Don't use TRAPS if no exceptions are thrown [v4]
In-Reply-To: <s4YsC_lkc8BSre0H2G03vTNkAOWyUneoCvzNyuoqizQ=.77b91340-600d-433a-aa89-64379e2e446f@github.com>
References: <1KBghJAnPzq1F4LTwaaa8sUTy-BiLlO4uXSmYC1XGPA=.46cc3327-0af0-409f-bf1a-07066c60b0de@github.com>
 <s4YsC_lkc8BSre0H2G03vTNkAOWyUneoCvzNyuoqizQ=.77b91340-600d-433a-aa89-64379e2e446f@github.com>
Message-ID: <jqALU70O7OybYpEx2peXeOxhtgsvG-f2uOlcpVZWPhc=.09f76f2e-031e-4170-a4f0-5dbe121d15fd@github.com>

On Tue, 23 Mar 2021 16:08:59 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Removed the TRAPS in function declarations in jvmtiRedefineClasses and in ConstantPool merging functions.
>> Tested with vmTestbase/nsk/jvmti and tier1 (in progress).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix load_new_class_versions and remove more traps.

Looks good. 

You should also do JDI test runs for this changeset and you should wait
to hear from the Serviceability team before integration.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3141

From dcubed at openjdk.java.net  Tue Mar 23 16:35:43 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 23 Mar 2021 16:35:43 GMT
Subject: RFR: 8264004: Don't use TRAPS if no exceptions are thrown [v2]
In-Reply-To: <SYs6Px0DWxxDjUHtY-IOcxlLlj0ro_TZhHW8-lT2HD0=.5f11d0e6-0549-47e1-8d5c-a634b569e80e@github.com>
References: <1KBghJAnPzq1F4LTwaaa8sUTy-BiLlO4uXSmYC1XGPA=.46cc3327-0af0-409f-bf1a-07066c60b0de@github.com>
 <uYmLht5CfEs4CxvJQl5vCFBqoH5RitXnZY2lKG0Y7NM=.1c5b2fe2-9e95-41a7-84e3-d95e1a294d14@github.com>
 <BCzo4VSYwH19jJrlZuMsnEurmTadI0Y7lbaVqJ03zAs=.b7cc8f75-a55d-4a60-a91c-babb29d906f9@github.com>
 <TPWUJ6377ch7pudqGGZQYle7cjrxzBDYx5Z-3i-5qT4=.fd7a3c21-0298-408f-8431-f0c5b770e038@github.com>
 <SYs6Px0DWxxDjUHtY-IOcxlLlj0ro_TZhHW8-lT2HD0=.5f11d0e6-0549-47e1-8d5c-a634b569e80e@github.com>
Message-ID: <UvJ9WAWbkJciLeh_pXo1FAFuPuFB_wpdkW9QuD_pp08=.626a1950-58f9-44e0-8349-565cd9c7b073@github.com>

On Tue, 23 Mar 2021 13:39:06 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I kind of thought these would make a long complicated expression and so the single use variables is helpful.  I don't think performance is important here.
>
> {code}
>       -      match = compare_entry_to(recur1, cp2, recur2);
>       -      if (match) {
>      +      if (compare_entry_to(recur1, cp2, recur2)) {
>               return true;
>             }
> I could do this

You can't return `true` after just `compare_entry_to()` because you still
have to check `compare_operand_to()`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3141

From aph at openjdk.java.net  Tue Mar 23 16:36:55 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 23 Mar 2021 16:36:55 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: <RIXlvES_OOQ47-4YI1CLX7kLG4JJ70NRr0g0G0X6zb0=.4a106aa2-8e76-4b5a-9206-cebc6f17472e@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
 <RIXlvES_OOQ47-4YI1CLX7kLG4JJ70NRr0g0G0X6zb0=.4a106aa2-8e76-4b5a-9206-cebc6f17472e@github.com>
Message-ID: <HVuUWfsnr8fqATnVU2b4S7VdSOwuKg1xxEZW-islB2g=.56d118c4-745d-4371-91a9-3bb250c9b7a3@github.com>

On Tue, 23 Mar 2021 16:20:47 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
>> 
>>  - Merge branch 'master' into jdk-macos
>>  - JDK-8262491: bsd_aarch64 part
>>  - JDK-8263002: bsd_aarch64 part
>>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>>  - Wider #ifdef block
>>  - Fix most of issues in java/foreign/ tests
>>    
>>    Failures related to va_args are tracked in JDK-8263512.
>>  - Add Azul copyright
>>  - Update Oracle copyright years
>>  - Use Thread::current_or_null_safe in SafeFetch
>>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>>  - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269
>
> Marked as reviewed by luhenry (Author).

> > > > [ Back-porting this patch to JDK 11] depends on the will of openjdk11 maintainers to accept this (and few other, like jep-388, as we depend on it) contribution.
> > > 
> > > 
> > > To the extent that 11u has fixed policies :) we definitely have a policy of accepting patches to keep 11u working on current hardware. So yes.
> > 
> > 
> > @lewurm That sounds like a green flag for you and jep-388 (with its R18_RESERVED functionality) ;)
> 
> Thanks, @theRealAph, and @VladimirKempik . We are on it!

It's going to be tricky to do in a really clean way, given some of the weirdnesses of the ABI. However, I think there's probably a need for it

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From coleenp at openjdk.java.net  Tue Mar 23 16:45:52 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 23 Mar 2021 16:45:52 GMT
Subject: RFR: 8264051: Remove unused TRAPS parameters from runtime functions
Message-ID: <QilnkRJZ0jTihZLCVVaOduS_DDY8tf5AsniNIdfhkEA=.ea89688e-e158-47bd-92b8-979ee1d84c59@github.com>

This change removes the TRAPS parameter from compute_modifier_flags(), lookup_instance_method_in_klasses and nest_host_error.

There's a progressive effort to remove cases where the last parameter of a function is THREAD, and it's unclear why it is ignoring an exception or whether an exception is expected, if it doesn't subsequently have a check for HAS_PENDING_EXCEPTION.

Tested locally with tier1 tests and tier1 tests on 4 Oracle platforms in progress.

-------------

Commit messages:
 - removed more TRAPS
 - 8264051: Remove unused TRAPS parameters from runtime functions

Changes: https://git.openjdk.java.net/jdk/pull/3157/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3157&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264051
  Stats: 52 lines in 16 files changed: 0 ins; 17 del; 35 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3157.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3157/head:pull/3157

PR: https://git.openjdk.java.net/jdk/pull/3157

From tschatzl at openjdk.java.net  Tue Mar 23 17:02:39 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 23 Mar 2021 17:02:39 GMT
Subject: RFR: 8264050: Remove unused field
 VM_HeapWalkOperation::_collecting_heap_roots
In-Reply-To: <jx3PUDxkUXv-UzofQAxxTlVGfipkCCPaXXEaZZ96OHM=.13a22fe4-25f2-4eb1-b4ee-af0394d4392a@github.com>
References: <jx3PUDxkUXv-UzofQAxxTlVGfipkCCPaXXEaZZ96OHM=.13a22fe4-25f2-4eb1-b4ee-af0394d4392a@github.com>
Message-ID: <HiiHdwagz_djgN8KNPdKZX9FdcOkLL0SROv5EdHZRas=.76e5450e-b034-4441-a43a-d8d83e502d11@github.com>

On Tue, 23 Mar 2021 15:06:02 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports field `_collecting_heap_roots` is not initialized after constructor ends. In fact, that field is not used anywhere. It was like that since the initial load. We can trivially remove it.

Lgtm and trivial.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3153

From iklam at openjdk.java.net  Tue Mar 23 17:33:43 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 23 Mar 2021 17:33:43 GMT
Subject: RFR: 8264051: Remove unused TRAPS parameters from runtime
 functions
In-Reply-To: <QilnkRJZ0jTihZLCVVaOduS_DDY8tf5AsniNIdfhkEA=.ea89688e-e158-47bd-92b8-979ee1d84c59@github.com>
References: <QilnkRJZ0jTihZLCVVaOduS_DDY8tf5AsniNIdfhkEA=.ea89688e-e158-47bd-92b8-979ee1d84c59@github.com>
Message-ID: <9uxwV28iiTNXulJXZMM5HTpRa0DJ8cske7FRh_cyTvw=.1f44c247-929a-46af-be32-8f0c462deca4@github.com>

On Tue, 23 Mar 2021 16:40:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the TRAPS parameter from compute_modifier_flags(), lookup_instance_method_in_klasses and nest_host_error.
> 
> There's a progressive effort to remove cases where the last parameter of a function is THREAD, and it's unclear why it is ignoring an exception or whether an exception is expected, if it doesn't subsequently have a check for HAS_PENDING_EXCEPTION.
> 
> Tested locally with tier1 tests and tier1 tests on 4 Oracle platforms in progress.

LGTM. Thanks for doing the cleanup.

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3157

From coleenp at openjdk.java.net  Tue Mar 23 19:18:40 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 23 Mar 2021 19:18:40 GMT
Subject: RFR: 8264004: Don't use TRAPS if no exceptions are thrown [v4]
In-Reply-To: <jqALU70O7OybYpEx2peXeOxhtgsvG-f2uOlcpVZWPhc=.09f76f2e-031e-4170-a4f0-5dbe121d15fd@github.com>
References: <1KBghJAnPzq1F4LTwaaa8sUTy-BiLlO4uXSmYC1XGPA=.46cc3327-0af0-409f-bf1a-07066c60b0de@github.com>
 <s4YsC_lkc8BSre0H2G03vTNkAOWyUneoCvzNyuoqizQ=.77b91340-600d-433a-aa89-64379e2e446f@github.com>
 <jqALU70O7OybYpEx2peXeOxhtgsvG-f2uOlcpVZWPhc=.09f76f2e-031e-4170-a4f0-5dbe121d15fd@github.com>
Message-ID: <BNV7vo-jDOs9AhRmzqj1XrbwY7gWXsvPE1rJdU43wYU=.4dd77d16-3e3b-4d9a-82ec-52008d635e5e@github.com>

On Tue, 23 Mar 2021 16:33:15 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix load_new_class_versions and remove more traps.
>
> Looks good. 
> 
> You should also do JDI test runs for this changeset and you should wait
> to hear from the Serviceability team before integration.

I ran the jvmti and jdi tests, as well as the serviceability/jvmti/RedefineClasses tests, and jdk/java/lang/instrument tests.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3141

From cjplummer at openjdk.java.net  Tue Mar 23 21:10:40 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 23 Mar 2021 21:10:40 GMT
Subject: RFR: 8176026: SA: Huge heap sizes cause a negative value to be
 displayed in the jhisto heap total [v2]
In-Reply-To: <-OxCoBAqyBOqOS5DP3C4NPkq8PFLwwCL6wBXmiqeEzU=.f62e8e0f-418e-4129-a91a-c10e1571466e@github.com>
References: <h_pqXvxIEJRhxH3sEA5fO8Z1XidOU3aZZij_ZVUx1kw=.1cf3982e-7dac-4d2d-80a0-9629eb50c203@github.com>
 <-OxCoBAqyBOqOS5DP3C4NPkq8PFLwwCL6wBXmiqeEzU=.f62e8e0f-418e-4129-a91a-c10e1571466e@github.com>
Message-ID: <cxXOVT3nVKOB3kO5AJeHNfiChDk0z4Kc2rHMuAn7ybE=.be5b748a-99a4-4226-ad95-c7b3ef599ab2@github.com>

On Tue, 23 Mar 2021 13:35:05 GMT, Koichi Sakata <ksakata at openjdk.org> wrote:

>> When a heap is used more than about 2.1GB, clhsdb jhisto shows a negative number in the total field.
>> 
>> $ java -Xmx20g Sample
>> 
>> $ jhsdb clhsdb --pid 5773
>> Attaching to process 5773, please wait...
>> hsdb> jhisto
>> ...
>> 299:            1       16      jdk.internal.misc.Unsafe
>> 300:            3402    10737610256     byte[]
>> Total :         15823   -2146661280
>> Heap traversal took 1.793 seconds.
>> (Incidentally, the Sample is a program that only allocates many objects.)
>> 
>> #### Details
>> This is because in ObjectHistogram class the totalSize variable is int type.
>> 
>> The total size is the total of ObjectHistogramElement#getSize() and getSize() returns long. So I changed int to long in the ObjectHistogram class.
>> 
>> Additionally, I changed the type of the totalCount. This doesn't cause a bug, but ObjectHistogramElement#getCount() also returns long. So it doesn't need to treat it as int, I think. ObjectHistogramElement#compare() also do the same thing, so a class that is a huge size show the bottom of the list.
>> 
>> #### Tests
>> The jtreg test was successful.
>> $ sudo make run-test TEST=serviceability/sa/ClhsdbJhisto.java
>> 
>> $ cat build/linux-x86_64-server-fastdebug/test-results/jtreg_test_hotspot_jtreg_serviceability_sa_ClhsdbJhisto_java/text/summary.txt
>> serviceability/sa/ClhsdbJhisto.java  Passed. Execution successful
>> 
>> I confirmed the output with the same program.
>> 
>> $ ./jdk/build/linux-x86_64-server-fastdebug/jdk/bin/java -Xmx20g Sample
>> $ ./jdk/build/linux-x86_64-server-fastdebug/jdk/bin/jhsdb clhsdb --pid 10196
>> Attaching to process 10196, please wait...
>> hsdb> jhisto
>> Object Histogram:
>> 
>> num       #instances    #bytes  Class description
>> --------------------------------------------------------------------------
>> 1:              3405    13958838400     byte[]
>> 2:              887     109032  java.lang.Class
>> ...
>> 300:            1       16      jdk.internal.misc.Unsafe
>> Total :         15827   13959470288
>> Heap traversal took 1.72 seconds.
>
> Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the sort bug for huge bytes in jhisto

The copyright needs updating in ObjectHistogramElement.java. Otherwise the changes look good.

-------------

Marked as reviewed by cjplummer (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3087

From ksakata at openjdk.java.net  Tue Mar 23 21:15:44 2021
From: ksakata at openjdk.java.net (Koichi Sakata)
Date: Tue, 23 Mar 2021 21:15:44 GMT
Subject: Integrated: 8263572: Output from jstack mixed mode is misaligned
In-Reply-To: <LiAjqiWikfy0llyWM79wX1pZQO4JkNsO8WwjWqcAAKg=.e177e030-08cf-42cd-aaee-27d530b5ed02@github.com>
References: <LiAjqiWikfy0llyWM79wX1pZQO4JkNsO8WwjWqcAAKg=.e177e030-08cf-42cd-aaee-27d530b5ed02@github.com>
Message-ID: <QAaQ23og6FRXG-I7GgtQMyrCYkj_hpAsyhHcDEQvz7I=.f03047a5-671e-4341-91e2-05cc32145fb4@github.com>

On Mon, 15 Mar 2021 07:29:16 GMT, Koichi Sakata <ksakata at openjdk.org> wrote:

> When running jstack with mixed option, the output of the lines that doesn't have an address are misaligned as followings. 
> 
> $ sudo jhsdb jstack --mixed --pid 8281
> ----------------- 8330 -----------------
> "event-handler" #20 daemon prio=5 tid=0x00007f2384838490 nid=0x208a in Object.wait() [0x00007f23585ec000]
>    java.lang.Thread.State: WAITING (on object monitor)
>    JavaThread state: _thread_blocked
> 0x00007f238da899f3      __pthread_cond_wait + 0x243
> 0x00007f238c63a26b      os::PlatformEvent::park() + 0x8b
> 0x00007f238c5e689d      ObjectMonitor::wait(long, bool, Thread*) + 0xfed
> 0x00007f238ca1f1d6      ObjectSynchronizer::wait(Handle, long, Thread*) + 0x96
> 0x00007f238c0b4d71      JVM_MonitorWait + 0x241
> 0x00007f237cb246b7      java.lang.Object.wait(long) + 0xd7 (Native method)
> 0x00007f2375777344      * java.lang.Object.wait() bci:2 line:338 (Compiled frame)
> * com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(long) bci:64 line:190 (Compiled frame)
> * com.sun.tools.jdi.EventQueueImpl.remove(long) bci:18 line:97 (Interpreted frame)
> 0x00007f2375009543      * com.sun.tools.jdi.EventQueueImpl.remove() bci:2 line:83 (Interpreted frame)
> 
> This pull request aligns the indentation. So It will be able to improve readability.
> 
> In this pull request the address part is filled with white spaces. The amount of space is calculated from VM's address size and lastly 2, which is the length of "0x", is added.
> 
> ### jtreg test
> 
> $ sudo make run-test TEST=serviceability/sa/TestJhsdbJstackMixed.java
> 
> $ cat ./jdk/build/linux-x86_64-server-fastdebug/test-results/jtreg_test_hotspot_jtreg_serviceability_sa_TestJhsdbJstackMixed_java/text/summary.txt
> serviceability/sa/TestJhsdbJstackMixed.java  Passed. Execution successful
> 
> ### Output Confirmation
> 
> I checked the output on 64-bit and 32-bit JDK.
> 
> First, I ran JShell. Next, on another shell, I ran jstack with mixed option for the JShell process and checked the output.
> 
> #### Linux 64-bit JDK
>  $ ./jdk/build/linux-x86_64-server-fastdebug/jdk/bin/jshell
> |  Welcome to JShell -- Version 16-internal
> |  For an introduction type: /help intro
> 
> jshell>
> 
> $ ./jdk/build/linux-x86_64-server-fastdebug/jdk/bin/jhsdb jstack --mixed --pid 19272
> ...
> ----------------- 19324 -----------------
> "output reader" #21 daemon prio=5 tid=0x00007f2ae4783760 nid=0x4b7c runnable [0x00007f2a86efd000]
>    java.lang.Thread.State: RUNNABLE
>    JavaThread state: _thread_in_native
> 0x00007f2aed5d2394      __libc_read + 0x44
> 0x00007f2ac450f93b      Java_sun_nio_ch_SocketDispatcher_read0 + 0x2b
> 0x00007f2adcb2045a      sun.nio.ch.SocketDispatcher.read0(java.io.FileDescriptor, long, int) + 0xfa (Native method)
> 0x00007f2ad573e024      * sun.nio.ch.SocketDispatcher.read(java.io.FileDescriptor, long, int) bci:4 line:47 (Compiled frame)
>                         * sun.nio.ch.NioSocketImpl.tryRead(java.io.FileDescriptor, byte[], int, int) bci:45 line:261 (Compiled frame)
>                         * sun.nio.ch.NioSocketImpl.implRead(byte[], int, int) bci:99 line:312 (Compiled frame)
>                         * sun.nio.ch.NioSocketImpl.read(byte[], int, int) bci:54 line:350 (Compiled frame)
>                         * sun.nio.ch.NioSocketImpl$1.read(byte[], int, int) bci:7 line:803 (Compiled frame)
>                         * java.net.Socket$SocketInputStream.read(byte[], int, int) bci:7 line:961 (Compiled frame)
>                         * java.net.Socket$SocketInputStream.read() bci:8 line:956 (Compiled frame)
>                         * java.io.FilterInputStream.read() bci:4 line:82 (Interpreted frame)
> 0x00007f2ad50094fe      * jdk.jshell.execution.DemultiplexInput.run() bci:4 line:58 (Interpreted frame)
> 0x00007f2ad5000d4a      <StubRoutines>
> ...
> 
> #### Windows 32-bit JDK
> $ ./jdk/build/windows-x86-server-fastdebug/jdk/bin/jhsdb.exe jstack --mixed --pid 78808
> ...
> ----------------- 29 -----------------
> "output reader" #17 daemon prio=5 tid=0x2711c3b8 nid=0x13178 runnable [0x27d6f000]
>    java.lang.Thread.State: RUNNABLE
>    JavaThread state: _thread_in_native
> 0x77ae2f5c      ntdll!NtWaitForSingleObject + 0xc
> 0x6dc5cb18      mswsock!sethostname + 0xbdc8
> 0x753cdecc      WS2_32!WSARecv + 0x11c
> 0x6c0d35f8      nio!Java_sun_nio_ch_SocketDispatcher_read0 + 0x48
> 0x02d15ee9      sun.nio.ch.SocketDispatcher.read0(java.io.FileDescriptor, long, int) + 0xa9 (Native method)
> 0x02d16540      * sun.nio.ch.SocketDispatcher.read(java.io.FileDescriptor, long, int) bci:4 line:46 (Compiled frame)
>                 * sun.nio.ch.NioSocketImpl.tryRead(java.io.FileDescriptor, byte[], int, int) bci:45 line:261 (Compiled frame)
>                 * sun.nio.ch.NioSocketImpl.implRead(byte[], int, int) bci:99 line:312 (Compiled frame)
>                 * sun.nio.ch.NioSocketImpl.read(byte[], int, int) bci:54 line:350 (Compiled frame)
>                 * sun.nio.ch.NioSocketImpl$1.read(byte[], int, int) bci:7 line:803 (Compiled frame)
>                 * java.net.Socket$SocketInputStream.read(byte[], int, int) bci:7 line:961 (Compiled frame)
>                 * java.net.Socket$SocketInputStream.read() bci:8 line:956 (Compiled frame)
>                 * java.io.FilterInputStream.read() bci:4 line:82 (Interpreted frame)
> 0x02ac6804      * jdk.jshell.execution.DemultiplexInput.run() bci:4 line:58 (Interpreted frame)
> 0x02ac0cdc      <StubRoutines>
> ...

This pull request has now been integrated.

Changeset: 91d86e6a
Author:    Koichi Sakata <ksakata at openjdk.org>
Committer: Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/91d86e6a
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8263572: Output from jstack mixed mode is misaligned

Reviewed-by: cjplummer, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3004

From iklam at openjdk.java.net  Tue Mar 23 21:15:44 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 23 Mar 2021 21:15:44 GMT
Subject: RFR: 8264004: Don't use TRAPS if no exceptions are thrown [v4]
In-Reply-To: <s4YsC_lkc8BSre0H2G03vTNkAOWyUneoCvzNyuoqizQ=.77b91340-600d-433a-aa89-64379e2e446f@github.com>
References: <1KBghJAnPzq1F4LTwaaa8sUTy-BiLlO4uXSmYC1XGPA=.46cc3327-0af0-409f-bf1a-07066c60b0de@github.com>
 <s4YsC_lkc8BSre0H2G03vTNkAOWyUneoCvzNyuoqizQ=.77b91340-600d-433a-aa89-64379e2e446f@github.com>
Message-ID: <rHf3sqAHf2xm3Zf9f2T96QEjnhD0fPGqMuiUQ_Gt6DY=.ca942133-7150-4876-96cc-d6c913914386@github.com>

On Tue, 23 Mar 2021 16:08:59 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Removed the TRAPS in function declarations in jvmtiRedefineClasses and in ConstantPool merging functions.
>> Tested with vmTestbase/nsk/jvmti and tier1 (in progress).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix load_new_class_versions and remove more traps.

* THREAD = current; // for exception processing``` 

is used only when the current method does not declare TRAPS, which means it should never throw. As a convention, I think the above code should be accompanied with by 

 em(THREAD);``` 

to ensure that the exceptions are not unintentionally leaked.

src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1389:

> 1387:     state->set_class_being_redefined(the_class, _class_load_kind);
> 1388: 
> 1389:     Thread* THREAD = current;  // for exception processing

Add `ExceptionMark em(THREAD);`

src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 2118:

> 2116:     methodHandle method(current, methods->at(i));
> 2117:     methodHandle new_method;
> 2118:     Thread* THREAD = current; // For exception handling

Add `ExceptionMark em(THREAD);`

-------------

Changes requested by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3141

From github.com+76791+alblue at openjdk.java.net  Tue Mar 23 21:50:52 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Tue, 23 Mar 2021 21:50:52 GMT
Subject: RFR: 8264087: Use the blessed modifier order in jdk.jconsole
Message-ID: <uYAxme-SvM9eepxk7ZJfI8_6qmVbtcCrhx7z_Vj_gEw=.e6392a25-ee6c-40a5-9808-1ae1e42b3428@github.com>

8264087: Use the blessed modifier order in jdk.jconsole

-------------

Commit messages:
 - 8264087: Use the blessed modifier order in jdk.jconsole

Changes: https://git.openjdk.java.net/jdk/pull/3164/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3164&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264087
  Stats: 31 lines in 11 files changed: 0 ins; 0 del; 31 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3164.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3164/head:pull/3164

PR: https://git.openjdk.java.net/jdk/pull/3164

From cjplummer at openjdk.java.net  Tue Mar 23 23:27:39 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 23 Mar 2021 23:27:39 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out
In-Reply-To: <yqd0Jb9DZkjgxXV8qWHjBoDIIttmvON85ZfsWrP7-gg=.36b85cd4-acdd-475b-bc5f-3c882ea99358@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
 <Zvf7GN59hJdc7SgVRao3cEbcpU99CbGceULIfJnDJOE=.4bd79c51-6b9b-4ff9-9ada-dc43fd6ca6e8@github.com>
 <e6bMvI_trIEXu7SAiM98-OpZug3Mwli00owZzLXxJNo=.fa0b5857-28b8-428d-9477-61044e32ad49@github.com>
 <oaMRL-GuwQKYlGByJvPhHH63A4LTvQLsL2W6BOIS6cc=.5ee0e7f9-bdc3-4e51-9fcf-999d607730c1@github.com>
 <7p7PD78B0fKuSonRZ44rQWvBKHabsz4n9VT4WbVluFI=.e4248320-f134-4ed0-b073-a3466970932c@github.com>
 <cedPjc6Gumib0S_yqDLAm8up9lPEGguw5w5LJblpKHM=.cad805fe-ab47-4eb4-8c78-e2a17109a2ce@github.com>
 <69h5uaXSdgc4Fkhla6QdtoezGPyVcFMNasVI8iNxYWI=.3a7c3e6a-8dfa-4ff1-a7cf-db71d3ea7bbf@github.com>
 <2J1CEmVaXJuvU3fseIBYDcJCihqoeAf07bt0hgvJWWE=.259496ed-1883-4035-a4e5-e6c45f511707@github.com>
 <rFBFEymgIrkLQdW4dLSSRthpE6vu629ScEsMmO8YM3w=.a8182d50-bb9e-4a2a-9cec-c965f80cca80@github.com>
 <mzZdkiwtjfisDNUd2cN9YNDYeFDFrj92wsX5tnaqzxA=.96a75c19-42a1-4dfa-960f-910476447ffd@github.com>
 <cj2qtJhobkpGMwLJ7BFF601v7lknxONwm2l
 nzHHe8gA=.ad2a9371-f39c-4099-b879-882f27f9a9a9@github.com>
 <yqd0Jb9DZkjgxXV8qWHjBoDIIttmvON85ZfsWrP7-gg=.36b85cd4-acdd-475b-bc5f-3c882ea99358@github.com>
Message-ID: <TtVA6VOakuJJl48mLXYCmwjTil7Ys1r7YLTGwA70ZRo=.9af751e7-4958-4df8-8edf-e638bd78314e@github.com>

On Mon, 22 Mar 2021 04:12:18 GMT, Lin Zang <lzang at openjdk.org> wrote:

> > I guess I don't understand why you would want write-through for small arrays but not large objects.
> 
> I think it is because that the current implementation does not have code which could calculate the object size before scan it. but it has the logic for calculate array length (`calculateArrayMaxLength()`) ahead of scaning. ( BTW, I am planing to add the logic for object, and then rewrite the whole heap dump impl to use writeThrough also for compressed dump, I think that should be in a separate PR)

Can't you just call `Oop.getObjectSize()`?

> > But all this seems to be doing is grouping the HPROF_HEAP_DUMP records into an array rather than having them interspersed with other types of records. How does this help, and why would this mode not always be enabled?
> 
> I think the original pupose of SEGMENT heap dump is to handle the case for large heap. In the hprof format spec, the size slot of the heap dump is 32bit, which means it has limitation of dump 4GB used heap. so use segmental dump could help resolve the problem. And IMO the reason for not always enable it is because every segment has a header and tail, which may introduce extra memory, althogh it is not much.

Ok. So `HPROF_HEAP_DUMP` is just a record, and records have a 32-bit size limit. I assume that previously only one such record was allowed. So `HPROF_HEAP_DUMP_SEGMENT` was created, and the only difference between it and `HPROF_HEAP_DUMP` is that you can have more than one `HPROF_HEAP_DUMP_SEGMENT`. Am I understanding it correctly?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2803

From dholmes at openjdk.java.net  Tue Mar 23 23:28:40 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 23 Mar 2021 23:28:40 GMT
Subject: RFR: 8264004: Don't use TRAPS if no exceptions are thrown [v4]
In-Reply-To: <s4YsC_lkc8BSre0H2G03vTNkAOWyUneoCvzNyuoqizQ=.77b91340-600d-433a-aa89-64379e2e446f@github.com>
References: <1KBghJAnPzq1F4LTwaaa8sUTy-BiLlO4uXSmYC1XGPA=.46cc3327-0af0-409f-bf1a-07066c60b0de@github.com>
 <s4YsC_lkc8BSre0H2G03vTNkAOWyUneoCvzNyuoqizQ=.77b91340-600d-433a-aa89-64379e2e446f@github.com>
Message-ID: <FO24pINoRLstzCLlcvIH_Shy0-YI3f5kpkINAHkjuCc=.e4dd9896-b7a3-4c98-850d-05e41fc824c7@github.com>

On Tue, 23 Mar 2021 16:08:59 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Removed the TRAPS in function declarations in jvmtiRedefineClasses and in ConstantPool merging functions.
>> Tested with vmTestbase/nsk/jvmti and tier1 (in progress).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix load_new_class_versions and remove more traps.

Updates look good - thanks.

I agree with Ioi about adding ExceptionMark as part of this usage pattern - it captures the intent that no exceptions are allowed to escape.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3141

From cjplummer at openjdk.java.net  Tue Mar 23 23:35:43 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 23 Mar 2021 23:35:43 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v18]
In-Reply-To: <fMCSwROv0RqaM7hs3ZZR0veUjagjo8hQ7O3iUS64vWs=.77a61291-4eae-406f-8d15-8990bf86085f@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <fMCSwROv0RqaM7hs3ZZR0veUjagjo8hQ7O3iUS64vWs=.77a61291-4eae-406f-8d15-8990bf86085f@github.com>
Message-ID: <TMLpyyopaWJfO3qZh-e8oSeuBH-3oNlTbSruLH-pED4=.ecaeda71-c56a-42b7-8eb2-61c658620c3e@github.com>

On Mon, 22 Mar 2021 12:35:52 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8252842: Extend jmap to support parallel heap dump
>
> Lin Zang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove parallel option and dumpheapext command
>  - Revert "hide the dumpheapext error message"
>    
>    This reverts commit 1af0e1e2bfab4f5d079c03ff0cb25067acacdac4.

I've only had a chance to skim over the code, so I just noted a few comment and wording related fixes while doing that. I'll need to set aside some more time for a more in depth review since the changes are pretty extensive.

src/hotspot/share/services/heapDumper.cpp line 556:

> 554:                          (u4) (position() - dump_segment_header_size));
> 555:     } else {
> 556:       // Finished process huge sub record

Is this suppose to be "Finished processing" or maybe "Finish processing".

src/hotspot/share/services/heapDumper.cpp line 557:

> 555:     } else {
> 556:       // Finished process huge sub record
> 557:       // Set _is_huge_sub_record to false so the parallel dump writer could flush data to file.

"can flush"

src/hotspot/share/services/heapDumper.cpp line 1665:

> 1663: // To avoid memory consumption, when dumping large objects such as huge array and
> 1664: // large objects whose size are larger than LARGE_OBJECT_DUMP_THRESHOLD, the scanned
> 1665: // partial object/array data will be send to backend directly instead of caching the

"will be sent to the backend..."

src/hotspot/share/services/heapDumper.cpp line 1666:

> 1664: // large objects whose size are larger than LARGE_OBJECT_DUMP_THRESHOLD, the scanned
> 1665: // partial object/array data will be send to backend directly instead of caching the
> 1666: // whole object/array internal buffer.

Should this be "...in the internal buffer"?

src/hotspot/share/services/heapDumper.cpp line 1668:

> 1666: // whole object/array internal buffer.
> 1667: // The HeapDumpLargeObjectList is used to save the large object when dumper scanning
> 1668: // the heap. The large objects could be added (push) parallelly by multiple dumpers.

Should this be "...when the dumper scans the heap."?

src/hotspot/share/services/heapDumper.cpp line 1884:

> 1882:   // parallel heap dump support
> 1883:   uint                    _num_dumper_threads;
> 1884:   uint                    _num_writter_threads;

Should be "writer", not "writter". This appears in a few fields and comments.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From ysuenaga at openjdk.java.net  Wed Mar 24 00:57:39 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 24 Mar 2021 00:57:39 GMT
Subject: RFR: 8263565: NPE was thrown when
 sun.jvm.hotspot.rmi.serverNamePrefix was set
In-Reply-To: <Gh6Y3JRuCVE4uYIRKRS6Y8JS3R9EHcOBwRRcJQIfVMk=.66883f2d-d108-4c7e-a5f2-380a386b709e@github.com>
References: <h7RuyZ_VM6x6IdDGSictAFUFZJ8C87UuUJIbjpJ_yWs=.94f55574-c7df-4af8-96c5-0c0ac7ced239@github.com>
 <-T97PgdhcBLuWZjkxqtWvE0M-XQKxqC0CJBY88mViKg=.e0a6ba57-7b1e-41ad-961b-0e465710eba6@github.com>
 <F0Kt8lyJ_iMtupUqxAnjLwGD4S-aTd52ZkJ83yAl6_U=.76bbd6e7-53ae-4c05-a3aa-7a3a6df9d736@github.com>
 <6LQOt0nW3vbivpTsKAwxd2Pz5OtcAWo3qZtnlKRk6vE=.3b814361-085a-4298-a73e-eeecaa2815f7@github.com>
 <PI-TJh7srlhNOH20gQl7jz5pSv0X-xQVgoZB8LDyBf0=.fa5aa28a-03fe-4e03-846a-76ec52122352@github.com>
 <EL2_24odQcZwvRkaCK6Yt7ApbL9YVke5VU8OCaKggyg=.0b56f5c1-ac04-48e7-a323-7bf8fb82006d@github.com>
 <A8MFIMdh8S0c7S_C60aT3wCogdSKomW4_65tyZN-i9U=.8e9e9ace-b95d-4717-85c3-231ad76e5bd7@github.com>
 <HOOdXVJdMNOXotrDjCGs_2gtmjAuoOoRE5YE0Ny46jM=.5f1432b0-e42f-4266-b7f3-5afa940a2f7f@github.com>
 <G6mrFXaWNzvC0d-41PbYLTUwSvSl2sTTdeZ9Xdcx4Q0=.7bca3389-4492-4bea-9e8a-f5bb6dd30b81@github.com>
 <Gh6Y3JRuCVE4uYIRKRS6Y8JS3R9EHcOBwRRcJQIfVMk=.66883f2d-d108-4c7e-a5f2-380a386b709e@github.com>
Message-ID: <Rw9czMbG2YnOh6BtTBm89t3KqjHkZ9gCt-NRkObaXBE=.42e18d6b-eb31-46e5-bda9-547223f771ee@github.com>

On Tue, 16 Mar 2021 02:39:02 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Sorry. I was running an old jhsdb. So we already have --registryport 2000 --rmiport, and you can already specify [:<registryport>] as part of the debugserver. So what needs to be added is just --servernameprefix, and better help for explaining all the parts of the debugserver that are specified with --connect. You also want to add --disableregistry, but I think that's kind of separate from the above and probably needs its own CR and CSR.
>
>> So what needs to be added is just --servernameprefix, and better help for explaining all the parts of the debugserver that are specified with --connect. You also want to add --disableregistry, but I think that's kind of separate from the above and probably needs its own CR and CSR.
> 
> I filed them to JBS. I will work for them later.
> 
> * --servernameprefix: https://bugs.openjdk.java.net/browse/JDK-8263635
> * --disableregistry: https://bugs.openjdk.java.net/browse/JDK-8263636

Ping: could you review it? I need one more reviewer to push.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3000

From coleenp at openjdk.java.net  Wed Mar 24 02:10:53 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 24 Mar 2021 02:10:53 GMT
Subject: RFR: 8264004: Don't use TRAPS if no exceptions are thrown [v5]
In-Reply-To: <1KBghJAnPzq1F4LTwaaa8sUTy-BiLlO4uXSmYC1XGPA=.46cc3327-0af0-409f-bf1a-07066c60b0de@github.com>
References: <1KBghJAnPzq1F4LTwaaa8sUTy-BiLlO4uXSmYC1XGPA=.46cc3327-0af0-409f-bf1a-07066c60b0de@github.com>
Message-ID: <n2HdYApTaHGqyN89hvKmg_3Hk-SUNRGczIpjphj3nRw=.15335430-5776-48ad-bbe1-d18aa8473660@github.com>

> Removed the TRAPS in function declarations in jvmtiRedefineClasses and in ConstantPool merging functions.
> Tested with vmTestbase/nsk/jvmti and tier1 (in progress).

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Add ExceptionMarks.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3141/files
  - new: https://git.openjdk.java.net/jdk/pull/3141/files/9134ce0b..2080b946

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3141&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3141&range=03-04

  Stats: 6 lines in 1 file changed: 3 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3141.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3141/head:pull/3141

PR: https://git.openjdk.java.net/jdk/pull/3141

From dholmes at openjdk.java.net  Wed Mar 24 02:25:41 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 24 Mar 2021 02:25:41 GMT
Subject: RFR: 8264004: Don't use TRAPS if no exceptions are thrown [v5]
In-Reply-To: <n2HdYApTaHGqyN89hvKmg_3Hk-SUNRGczIpjphj3nRw=.15335430-5776-48ad-bbe1-d18aa8473660@github.com>
References: <1KBghJAnPzq1F4LTwaaa8sUTy-BiLlO4uXSmYC1XGPA=.46cc3327-0af0-409f-bf1a-07066c60b0de@github.com>
 <n2HdYApTaHGqyN89hvKmg_3Hk-SUNRGczIpjphj3nRw=.15335430-5776-48ad-bbe1-d18aa8473660@github.com>
Message-ID: <o0GIx8djDodjYwQMGF2y7tn8hdT1S7wHAB3bT7eTKQc=.087dbbcb-e637-452b-a49c-2de666f15aa3@github.com>

On Wed, 24 Mar 2021 02:10:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Removed the TRAPS in function declarations in jvmtiRedefineClasses and in ConstantPool merging functions.
>> Tested with vmTestbase/nsk/jvmti and tier1 (in progress).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add ExceptionMarks.

Looks good!

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3141

From dholmes at openjdk.java.net  Wed Mar 24 02:57:42 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 24 Mar 2021 02:57:42 GMT
Subject: RFR: 8264051: Remove unused TRAPS parameters from runtime
 functions
In-Reply-To: <QilnkRJZ0jTihZLCVVaOduS_DDY8tf5AsniNIdfhkEA=.ea89688e-e158-47bd-92b8-979ee1d84c59@github.com>
References: <QilnkRJZ0jTihZLCVVaOduS_DDY8tf5AsniNIdfhkEA=.ea89688e-e158-47bd-92b8-979ee1d84c59@github.com>
Message-ID: <T0x2UlXa4S9T-IpCKu_59kzDyw6mciA9AdgncPdSq5s=.487dc487-8fba-4ea0-9b3d-ef0994f37018@github.com>

On Tue, 23 Mar 2021 16:40:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the TRAPS parameter from compute_modifier_flags(), lookup_instance_method_in_klasses and nest_host_error.
> 
> There's a progressive effort to remove cases where the last parameter of a function is THREAD, and it's unclear why it is ignoring an exception or whether an exception is expected, if it doesn't subsequently have a check for HAS_PENDING_EXCEPTION.
> 
> Tested locally with tier1 tests and tier1 tests on 4 Oracle platforms in progress.

Nice cleanup Coleen!

I have a further suggested change to simplify things further - see below.

Thanks,
David

src/hotspot/share/oops/instanceKlass.hpp line 468:

> 466:   void set_nest_host_index(u2 i)  { _nest_host_index = i; }
> 467:   // dynamic nest member support
> 468:   void set_nest_host(InstanceKlass* host, JavaThread* current);

I think we should drop the thread parameter for this method and nest_host_error and avoid the tramp data. We only need the current thread for a ResourceMark in a logging clause in set_nest_host, and for a ConstantPoolHandle in nest_host_error. Neither of these codepaths are hot so we can just manifest Thread::current() when needed there.
Then you can also remove the thread parameter from print_nest_host_error_on.

-------------

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3157

From coleenp at openjdk.java.net  Wed Mar 24 03:10:39 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 24 Mar 2021 03:10:39 GMT
Subject: RFR: 8264051: Remove unused TRAPS parameters from runtime
 functions
In-Reply-To: <T0x2UlXa4S9T-IpCKu_59kzDyw6mciA9AdgncPdSq5s=.487dc487-8fba-4ea0-9b3d-ef0994f37018@github.com>
References: <QilnkRJZ0jTihZLCVVaOduS_DDY8tf5AsniNIdfhkEA=.ea89688e-e158-47bd-92b8-979ee1d84c59@github.com>
 <T0x2UlXa4S9T-IpCKu_59kzDyw6mciA9AdgncPdSq5s=.487dc487-8fba-4ea0-9b3d-ef0994f37018@github.com>
Message-ID: <_Kcj8x3UIVkABjqGI3izel_-s2Xsak7UsGQiXQ0Xtms=.ecc09e06-2f9b-44b6-9596-df3319ccfd26@github.com>

On Wed, 24 Mar 2021 02:45:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This change removes the TRAPS parameter from compute_modifier_flags(), lookup_instance_method_in_klasses and nest_host_error.
>> 
>> There's a progressive effort to remove cases where the last parameter of a function is THREAD, and it's unclear why it is ignoring an exception or whether an exception is expected, if it doesn't subsequently have a check for HAS_PENDING_EXCEPTION.
>> 
>> Tested locally with tier1 tests and tier1 tests on 4 Oracle platforms in progress.
>
> src/hotspot/share/oops/instanceKlass.hpp line 468:
> 
>> 466:   void set_nest_host_index(u2 i)  { _nest_host_index = i; }
>> 467:   // dynamic nest member support
>> 468:   void set_nest_host(InstanceKlass* host, JavaThread* current);
> 
> I think we should drop the thread parameter for this method and nest_host_error and avoid the tramp data. We only need the current thread for a ResourceMark in a logging clause in set_nest_host, and for a ConstantPoolHandle in nest_host_error. Neither of these codepaths are hot so we can just manifest Thread::current() when needed there.
> Then you can also remove the thread parameter from print_nest_host_error_on.

You're right. I can remove a lot of thread arguments this way.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3157

From coleenp at openjdk.java.net  Wed Mar 24 03:20:41 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 24 Mar 2021 03:20:41 GMT
Subject: RFR: 8264004: Don't use TRAPS if no exceptions are thrown [v4]
In-Reply-To: <rHf3sqAHf2xm3Zf9f2T96QEjnhD0fPGqMuiUQ_Gt6DY=.ca942133-7150-4876-96cc-d6c913914386@github.com>
References: <1KBghJAnPzq1F4LTwaaa8sUTy-BiLlO4uXSmYC1XGPA=.46cc3327-0af0-409f-bf1a-07066c60b0de@github.com>
 <s4YsC_lkc8BSre0H2G03vTNkAOWyUneoCvzNyuoqizQ=.77b91340-600d-433a-aa89-64379e2e446f@github.com>
 <rHf3sqAHf2xm3Zf9f2T96QEjnhD0fPGqMuiUQ_Gt6DY=.ca942133-7150-4876-96cc-d6c913914386@github.com>
Message-ID: <e6sAbydtz1LnvnCjX__cB6xzEte1H5KKkEVQdYbqG7Y=.8fc22213-f4d5-442f-88ad-926ecda37f87@github.com>

On Tue, 23 Mar 2021 21:07:02 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix load_new_class_versions and remove more traps.
>
> src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1389:
> 
>> 1387:     state->set_class_being_redefined(the_class, _class_load_kind);
>> 1388: 
>> 1389:     Thread* THREAD = current;  // for exception processing
> 
> Add `ExceptionMark em(THREAD);`

Done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3141

From coleenp at openjdk.java.net  Wed Mar 24 03:22:05 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 24 Mar 2021 03:22:05 GMT
Subject: RFR: 8264051: Remove unused TRAPS parameters from runtime
 functions [v2]
In-Reply-To: <_Kcj8x3UIVkABjqGI3izel_-s2Xsak7UsGQiXQ0Xtms=.ecc09e06-2f9b-44b6-9596-df3319ccfd26@github.com>
References: <QilnkRJZ0jTihZLCVVaOduS_DDY8tf5AsniNIdfhkEA=.ea89688e-e158-47bd-92b8-979ee1d84c59@github.com>
 <T0x2UlXa4S9T-IpCKu_59kzDyw6mciA9AdgncPdSq5s=.487dc487-8fba-4ea0-9b3d-ef0994f37018@github.com>
 <_Kcj8x3UIVkABjqGI3izel_-s2Xsak7UsGQiXQ0Xtms=.ecc09e06-2f9b-44b6-9596-df3319ccfd26@github.com>
Message-ID: <DsSo0svM81GhBLJaj76vz-Dflur0O3LdLM7ihDgD09U=.29d61bdd-be0d-43e3-aaed-0c1f5a92ee78@github.com>

On Wed, 24 Mar 2021 03:07:42 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/oops/instanceKlass.hpp line 468:
>> 
>>> 466:   void set_nest_host_index(u2 i)  { _nest_host_index = i; }
>>> 467:   // dynamic nest member support
>>> 468:   void set_nest_host(InstanceKlass* host, JavaThread* current);
>> 
>> I think we should drop the thread parameter for this method and nest_host_error and avoid the tramp data. We only need the current thread for a ResourceMark in a logging clause in set_nest_host, and for a ConstantPoolHandle in nest_host_error. Neither of these codepaths are hot so we can just manifest Thread::current() when needed there.
>> Then you can also remove the thread parameter from print_nest_host_error_on.
>
> You're right. I can remove a lot of thread arguments this way.

Done.  Reran runtime/Nestmates tests and tier1.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3157

From coleenp at openjdk.java.net  Wed Mar 24 03:22:05 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 24 Mar 2021 03:22:05 GMT
Subject: RFR: 8264051: Remove unused TRAPS parameters from runtime
 functions [v2]
In-Reply-To: <QilnkRJZ0jTihZLCVVaOduS_DDY8tf5AsniNIdfhkEA=.ea89688e-e158-47bd-92b8-979ee1d84c59@github.com>
References: <QilnkRJZ0jTihZLCVVaOduS_DDY8tf5AsniNIdfhkEA=.ea89688e-e158-47bd-92b8-979ee1d84c59@github.com>
Message-ID: <yagx1vYMUXLTNsYf0CgM7EooFWjFODri1FVAVaZVO-w=.9f281c78-ba32-480b-a3ce-8a767a0bbf3f@github.com>

> This change removes the TRAPS parameter from compute_modifier_flags(), lookup_instance_method_in_klasses and nest_host_error.
> 
> There's a progressive effort to remove cases where the last parameter of a function is THREAD, and it's unclear why it is ignoring an exception or whether an exception is expected, if it doesn't subsequently have a check for HAS_PENDING_EXCEPTION.
> 
> Tested locally with tier1 tests and tier1 tests on 4 Oracle platforms in progress.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  removed thread parameter from nest_host_error and callers.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3157/files
  - new: https://git.openjdk.java.net/jdk/pull/3157/files/57f5254e..3ce07844

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3157&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3157&range=00-01

  Stats: 15 lines in 5 files changed: 0 ins; 0 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3157.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3157/head:pull/3157

PR: https://git.openjdk.java.net/jdk/pull/3157

From dholmes at openjdk.java.net  Wed Mar 24 03:52:40 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 24 Mar 2021 03:52:40 GMT
Subject: RFR: 8264051: Remove unused TRAPS parameters from runtime
 functions [v2]
In-Reply-To: <yagx1vYMUXLTNsYf0CgM7EooFWjFODri1FVAVaZVO-w=.9f281c78-ba32-480b-a3ce-8a767a0bbf3f@github.com>
References: <QilnkRJZ0jTihZLCVVaOduS_DDY8tf5AsniNIdfhkEA=.ea89688e-e158-47bd-92b8-979ee1d84c59@github.com>
 <yagx1vYMUXLTNsYf0CgM7EooFWjFODri1FVAVaZVO-w=.9f281c78-ba32-480b-a3ce-8a767a0bbf3f@github.com>
Message-ID: <qWI-jJ9_akBmb0yiZxbgnXesDlMTO9dRHNjVu5MD81k=.5800c4ea-5d10-4d78-a9b9-04416b3f6cd1@github.com>

On Wed, 24 Mar 2021 03:22:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the TRAPS parameter from compute_modifier_flags(), lookup_instance_method_in_klasses and nest_host_error.
>> 
>> There's a progressive effort to remove cases where the last parameter of a function is THREAD, and it's unclear why it is ignoring an exception or whether an exception is expected, if it doesn't subsequently have a check for HAS_PENDING_EXCEPTION.
>> 
>> Tested locally with tier1 tests and tier1 tests on 4 Oracle platforms in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed thread parameter from nest_host_error and callers.

Looks good!

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3157

From haosun at openjdk.java.net  Wed Mar 24 04:08:39 2021
From: haosun at openjdk.java.net (Hao Sun)
Date: Wed, 24 Mar 2021 04:08:39 GMT
Subject: RFR: 8264028: Typo in
 javax.management.relation.RelationService::purgeRelations
In-Reply-To: <TmTRqpzkXsCeS5IZ3bcxRmFwhBvW-4P4xnLpefPkEAE=.f2fbb000-2ce0-4d43-ab09-0b5b0e290a1d@github.com>
References: <9LcMa_awvTUUQUrc8y_D3kQl2wFTraWLYfK_prqwsvI=.9a10ef23-f23d-4e1d-8833-c25af1067deb@github.com>
 <_saybEKJgMmhSIcPF2amITOmcj8GsOVzsD9iJxTXuy0=.48822974-c90e-4d7a-8597-c875ce1e6eb6@github.com>
 <RQnGNAJ4-qQ5Y2pG94JiO3W68Hemswbu_Otm-OGP1lM=.88abfda8-7336-41ef-8cec-b7825e55690c@github.com>
 <C2Ebw8FLQOZXOB3gF5N8CeMzWG2JEr2Zz8xuZHCU_VY=.097b1ddc-f3fe-46f9-82a0-23336f275cc3@github.com>
 <xoAzn6-QEfjIwJEogjpYL2Ez8LS3Q2-eLQRG_PUavbE=.fcd0cd37-e0cb-48c1-b0f7-4e9d3e4740e8@github.com>
 <TmTRqpzkXsCeS5IZ3bcxRmFwhBvW-4P4xnLpefPkEAE=.f2fbb000-2ce0-4d43-ab09-0b5b0e290a1d@github.com>
Message-ID: <s5a2mXs_Dpfj2bC7EUgwspsxmHUuxf1BZ-FrOe1wO0k=.46f05247-31ed-4bc3-9076-7851036b0b0b@github.com>

On Tue, 23 Mar 2021 11:35:45 GMT, ?? <github.com+22524871+horizonzy at openjdk.org> wrote:

>> Hi, I have submitted the bug for it: https://bugs.openjdk.java.net/browse/JDK-8264028 -- please change the PR synopsis to "8264028: Typo in javax.management.relation.RelationService::purgeRelations" to get it properly hooked to PR metadata. After that, bots should tell what is next.
>
>> Hi, I have submitted the bug for it: https://bugs.openjdk.java.net/browse/JDK-8264028 -- please change the PR synopsis to "8264028: Typo in javax.management.relation.RelationService::purgeRelations" to get it properly hooked to PR metadata. After that, bots should tell what is next.
> 
> ok, thanks.

You may want to enable the GitHub Actions. Please go to https://github.com/horizonzy/jdk/actions and then trigger the test workflow on your branch.

It would be fine if you do not run the test for this PR since only typo errors are fixed. 
But I suggest enabling this and in this way all the necessary tests would be run automatically for your new PRs in the near future once they are submitted.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2765

From github.com+22524871+horizonzy at openjdk.java.net  Wed Mar 24 05:01:38 2021
From: github.com+22524871+horizonzy at openjdk.java.net (=?UTF-8?B?6LW15bu2?=)
Date: Wed, 24 Mar 2021 05:01:38 GMT
Subject: RFR: 8264028: Typo in
 javax.management.relation.RelationService::purgeRelations
In-Reply-To: <s5a2mXs_Dpfj2bC7EUgwspsxmHUuxf1BZ-FrOe1wO0k=.46f05247-31ed-4bc3-9076-7851036b0b0b@github.com>
References: <9LcMa_awvTUUQUrc8y_D3kQl2wFTraWLYfK_prqwsvI=.9a10ef23-f23d-4e1d-8833-c25af1067deb@github.com>
 <_saybEKJgMmhSIcPF2amITOmcj8GsOVzsD9iJxTXuy0=.48822974-c90e-4d7a-8597-c875ce1e6eb6@github.com>
 <RQnGNAJ4-qQ5Y2pG94JiO3W68Hemswbu_Otm-OGP1lM=.88abfda8-7336-41ef-8cec-b7825e55690c@github.com>
 <C2Ebw8FLQOZXOB3gF5N8CeMzWG2JEr2Zz8xuZHCU_VY=.097b1ddc-f3fe-46f9-82a0-23336f275cc3@github.com>
 <xoAzn6-QEfjIwJEogjpYL2Ez8LS3Q2-eLQRG_PUavbE=.fcd0cd37-e0cb-48c1-b0f7-4e9d3e4740e8@github.com>
 <TmTRqpzkXsCeS5IZ3bcxRmFwhBvW-4P4xnLpefPkEAE=.f2fbb000-2ce0-4d43-ab09-0b5b0e290a1d@github.com>
 <s5a2mXs_Dpfj2bC7EUgwspsxmHUuxf1BZ-FrOe1wO0k=.46f05247-31ed-4bc3-9076-7851036b0b0b@github.com>
Message-ID: <wuP6WHLeNLptZyC7NQWuKFgcxkULK5_670HvK9rE3pE=.fd72babb-5642-4927-92d2-91e74a63ffc3@github.com>

On Wed, 24 Mar 2021 04:04:50 GMT, Hao Sun <haosun at openjdk.org> wrote:

> You may want to enable the GitHub Actions. Please go to https://github.com/horizonzy/jdk/actions and then trigger the test workflow on your branch.
> 
> It would be fine if you do not run the test for this PR since only typo errors are fixed.
> But I suggest enabling this and in this way all the necessary tests would be run automatically for your new PRs in the near future once they are submitted.

thanks for your suggest.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2765

From iklam at openjdk.java.net  Wed Mar 24 05:44:39 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 24 Mar 2021 05:44:39 GMT
Subject: RFR: 8264004: Don't use TRAPS if no exceptions are thrown [v5]
In-Reply-To: <n2HdYApTaHGqyN89hvKmg_3Hk-SUNRGczIpjphj3nRw=.15335430-5776-48ad-bbe1-d18aa8473660@github.com>
References: <1KBghJAnPzq1F4LTwaaa8sUTy-BiLlO4uXSmYC1XGPA=.46cc3327-0af0-409f-bf1a-07066c60b0de@github.com>
 <n2HdYApTaHGqyN89hvKmg_3Hk-SUNRGczIpjphj3nRw=.15335430-5776-48ad-bbe1-d18aa8473660@github.com>
Message-ID: <Ra17fVVMpEk8kxITKmcbnJLVq8pFiFPoKmnfZQZ_VTY=.c569948c-e82f-4d9c-8bdc-977163396575@github.com>

On Wed, 24 Mar 2021 02:10:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Removed the TRAPS in function declarations in jvmtiRedefineClasses and in ConstantPool merging functions.
>> Tested with vmTestbase/nsk/jvmti and tier1 (in progress).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add ExceptionMarks.

Marked as reviewed by iklam (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3141

From lzang at openjdk.java.net  Wed Mar 24 06:49:47 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 24 Mar 2021 06:49:47 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out
In-Reply-To: <TtVA6VOakuJJl48mLXYCmwjTil7Ys1r7YLTGwA70ZRo=.9af751e7-4958-4df8-8edf-e638bd78314e@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
 <Zvf7GN59hJdc7SgVRao3cEbcpU99CbGceULIfJnDJOE=.4bd79c51-6b9b-4ff9-9ada-dc43fd6ca6e8@github.com>
 <e6bMvI_trIEXu7SAiM98-OpZug3Mwli00owZzLXxJNo=.fa0b5857-28b8-428d-9477-61044e32ad49@github.com>
 <oaMRL-GuwQKYlGByJvPhHH63A4LTvQLsL2W6BOIS6cc=.5ee0e7f9-bdc3-4e51-9fcf-999d607730c1@github.com>
 <7p7PD78B0fKuSonRZ44rQWvBKHabsz4n9VT4WbVluFI=.e4248320-f134-4ed0-b073-a3466970932c@github.com>
 <cedPjc6Gumib0S_yqDLAm8up9lPEGguw5w5LJblpKHM=.cad805fe-ab47-4eb4-8c78-e2a17109a2ce@github.com>
 <69h5uaXSdgc4Fkhla6QdtoezGPyVcFMNasVI8iNxYWI=.3a7c3e6a-8dfa-4ff1-a7cf-db71d3ea7bbf@github.com>
 <2J1CEmVaXJuvU3fseIBYDcJCihqoeAf07bt0hgvJWWE=.259496ed-1883-4035-a4e5-e6c45f511707@github.com>
 <rFBFEymgIrkLQdW4dLSSRthpE6vu629ScEsMmO8YM3w=.a8182d50-bb9e-4a2a-9cec-c965f80cca80@github.com>
 <mzZdkiwtjfisDNUd2cN9YNDYeFDFrj92wsX5tnaqzxA=.96a75c19-42a1-4dfa-960f-910476447ffd@github.com>
 <cj2qtJhobkpGMwLJ7BFF601v7lknxONwm2l
 nzHHe8gA=.ad2a9371-f39c-4099-b879-882f27f9a9a9@github.com>
 <yqd0Jb9DZkjgxXV8qWHjBoDIIttmvON85ZfsWrP7-gg=.36b85cd4-acdd-475b-bc5f-3c882ea99358@github.com>
 <TtVA6VOakuJJl48mLXYCmwjTil7Ys1r7YLTGwA70ZRo=.9af751e7-4958-4df8-8edf-e638bd78314e@github.com>
Message-ID: <cAcMYVZcunS3ArIH4XGCUHua4kzuIxC2pbzLEFd9Piw=.dd40626b-ab85-479e-9a6d-266b98371a4d@github.com>

On Tue, 23 Mar 2021 23:25:10 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Dear Chris?
>> 
>>> I guess I don't understand why you would want write-through for small arrays but not large objects.
>> 
>> I think it is because that the current implementation does not have code which could calculate the object size before scan it. but it has the logic for calculate array length (`calculateArrayMaxLength()`) ahead of scaning.  ( BTW, I am planing to add the logic for object, and then rewrite the whole heap dump impl to use writeThrough also for compressed dump, I think that should be in a separate PR)
>> 
>>> But all this seems to be doing is grouping the HPROF_HEAP_DUMP records into an array rather than having them interspersed with other types of records. How does this help, and why would this mode not always be enabled?
>> 
>> I think the original pupose of SEGMENT heap dump is to handle the case for large heap. In the hprof format spec, the size slot of the heap dump is 32bit, which means it has limitation of dump 4GB used heap.  so use segmental dump could help resolve the problem. And IMO the reason for not always enable it is because every segment has a header and tail, which may introduce extra memory, althogh it is not much.
>> 
>>> It looks like both HPROF_HEAP_DUMP_SEGMENT and HPROF_HEAP_DUMP_END are followed by a 4-byte size and 4-byte timestamp, although the timestamp seems to always be 0, and the size for END is also always 0.
>> 
>> My understand  from code is that 4-byte size and 4-byte timestamp only exist after HPROF_HEAP_DUMP_SEGMENT, and the HPROF_HEAP_DUMP_END actually is the end of the segment.  So I think the specification is not accurate.
>> 
>> Thanks,
>> Lin
>
>> > I guess I don't understand why you would want write-through for small arrays but not large objects.
>> 
>> I think it is because that the current implementation does not have code which could calculate the object size before scan it. but it has the logic for calculate array length (`calculateArrayMaxLength()`) ahead of scaning. ( BTW, I am planing to add the logic for object, and then rewrite the whole heap dump impl to use writeThrough also for compressed dump, I think that should be in a separate PR)
> 
> Can't you just call `Oop.getObjectSize()`?
> 
>> > But all this seems to be doing is grouping the HPROF_HEAP_DUMP records into an array rather than having them interspersed with other types of records. How does this help, and why would this mode not always be enabled?
>> 
>> I think the original pupose of SEGMENT heap dump is to handle the case for large heap. In the hprof format spec, the size slot of the heap dump is 32bit, which means it has limitation of dump 4GB used heap. so use segmental dump could help resolve the problem. And IMO the reason for not always enable it is because every segment has a header and tail, which may introduce extra memory, althogh it is not much.
> 
> Ok. So `HPROF_HEAP_DUMP` is just a record, and records have a 32-bit size limit. I assume that previously only one such record was allowed. So `HPROF_HEAP_DUMP_SEGMENT` was created, and the only difference between it and `HPROF_HEAP_DUMP` is that you can have more than one `HPROF_HEAP_DUMP_SEGMENT`. Am I understanding it correctly?

Dear Chris,

> Can't you just call `Oop.getObjectSize()`?

Yes, I can use it, then I think there is no need to use segmental heap dump when heap used bytes is not large than 4G. so there may be lots of code change. do you think it is ok to include change in this bug fix? or I just keep the segmental heap dump codes and use the write through mode for object dump in this fix.


> Ok. So `HPROF_HEAP_DUMP` is just a record, and records have a 32-bit size limit. I assume that previously only one such record was allowed. So `HPROF_HEAP_DUMP_SEGMENT` was created, and the only difference between it and `HPROF_HEAP_DUMP` is that you can have more than one `HPROF_HEAP_DUMP_SEGMENT`. Am I understanding it correctly?

Yes, I think so.

Thanks,
Lin

-------------

PR: https://git.openjdk.java.net/jdk/pull/2803

From lzang at openjdk.java.net  Wed Mar 24 06:51:43 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 24 Mar 2021 06:51:43 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v18]
In-Reply-To: <TMLpyyopaWJfO3qZh-e8oSeuBH-3oNlTbSruLH-pED4=.ecaeda71-c56a-42b7-8eb2-61c658620c3e@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <fMCSwROv0RqaM7hs3ZZR0veUjagjo8hQ7O3iUS64vWs=.77a61291-4eae-406f-8d15-8990bf86085f@github.com>
 <TMLpyyopaWJfO3qZh-e8oSeuBH-3oNlTbSruLH-pED4=.ecaeda71-c56a-42b7-8eb2-61c658620c3e@github.com>
Message-ID: <Ja4vN-10d3w4qd5ocOPdvOTUuWZdKLSn_NBPDpKz3pA=.befa0271-c21d-4f6d-861d-a74f97444675@github.com>

On Tue, 23 Mar 2021 23:33:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Lin Zang has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - remove parallel option and dumpheapext command
>>  - Revert "hide the dumpheapext error message"
>>    
>>    This reverts commit 1af0e1e2bfab4f5d079c03ff0cb25067acacdac4.
>
> I've only had a chance to skim over the code, so I just noted a few comment and wording related fixes while doing that. I'll need to set aside some more time for a more in depth review since the changes are pretty extensive.

Hi Chris,
Thanks a lot for your patience! please take your time.
I will update the PR based on your comments.

BRs,
Lin

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From shade at openjdk.java.net  Wed Mar 24 06:53:40 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 24 Mar 2021 06:53:40 GMT
Subject: Integrated: 8264050: Remove unused field
 VM_HeapWalkOperation::_collecting_heap_roots
In-Reply-To: <jx3PUDxkUXv-UzofQAxxTlVGfipkCCPaXXEaZZ96OHM=.13a22fe4-25f2-4eb1-b4ee-af0394d4392a@github.com>
References: <jx3PUDxkUXv-UzofQAxxTlVGfipkCCPaXXEaZZ96OHM=.13a22fe4-25f2-4eb1-b4ee-af0394d4392a@github.com>
Message-ID: <pPzaZ5stysyk25bh6Au8bAEK7t-jnou-3pBKmc5PZZM=.39e4bf60-7203-4a6b-a9b9-a63a30feaa66@github.com>

On Tue, 23 Mar 2021 15:06:02 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports field `_collecting_heap_roots` is not initialized after constructor ends. In fact, that field is not used anywhere. It was like that since the initial load. We can trivially remove it.

This pull request has now been integrated.

Changeset: da512bf5
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/da512bf5
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8264050: Remove unused field VM_HeapWalkOperation::_collecting_heap_roots

Reviewed-by: coleenp, tschatzl

-------------

PR: https://git.openjdk.java.net/jdk/pull/3153

From coleenp at openjdk.java.net  Wed Mar 24 12:19:41 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 24 Mar 2021 12:19:41 GMT
Subject: RFR: 8264004: Don't use TRAPS if no exceptions are thrown [v5]
In-Reply-To: <Ra17fVVMpEk8kxITKmcbnJLVq8pFiFPoKmnfZQZ_VTY=.c569948c-e82f-4d9c-8bdc-977163396575@github.com>
References: <1KBghJAnPzq1F4LTwaaa8sUTy-BiLlO4uXSmYC1XGPA=.46cc3327-0af0-409f-bf1a-07066c60b0de@github.com>
 <n2HdYApTaHGqyN89hvKmg_3Hk-SUNRGczIpjphj3nRw=.15335430-5776-48ad-bbe1-d18aa8473660@github.com>
 <Ra17fVVMpEk8kxITKmcbnJLVq8pFiFPoKmnfZQZ_VTY=.c569948c-e82f-4d9c-8bdc-977163396575@github.com>
Message-ID: <0T26-UOgZBHAhgtrUuJHstrWl-GdyZ-CiqqowSrGdHI=.d837da6e-b8ee-43ef-b92d-4bf9fcc2d530@github.com>

On Wed, 24 Mar 2021 05:42:06 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add ExceptionMarks.
>
> Marked as reviewed by iklam (Reviewer).

Thanks for reviewing!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3141

From coleenp at openjdk.java.net  Wed Mar 24 12:19:42 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 24 Mar 2021 12:19:42 GMT
Subject: Integrated: 8264004: Don't use TRAPS if no exceptions are thrown
In-Reply-To: <1KBghJAnPzq1F4LTwaaa8sUTy-BiLlO4uXSmYC1XGPA=.46cc3327-0af0-409f-bf1a-07066c60b0de@github.com>
References: <1KBghJAnPzq1F4LTwaaa8sUTy-BiLlO4uXSmYC1XGPA=.46cc3327-0af0-409f-bf1a-07066c60b0de@github.com>
Message-ID: <Q-DG1QzNlwJZJb7K5qEOb6n0_rkL_qCQWFSdqz6BLgY=.4053707c-4a26-416a-b26b-304502a32733@github.com>

On Tue, 23 Mar 2021 01:04:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Removed the TRAPS in function declarations in jvmtiRedefineClasses and in ConstantPool merging functions.
> Tested with vmTestbase/nsk/jvmti and tier1 (in progress).

This pull request has now been integrated.

Changeset: 5d7e93c8
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5d7e93c8
Stats:     209 lines in 4 files changed: 7 ins; 41 del; 161 mod

8264004: Don't use TRAPS if no exceptions are thrown

Reviewed-by: dholmes, iklam, hseigel, dcubed

-------------

PR: https://git.openjdk.java.net/jdk/pull/3141

From coleenp at openjdk.java.net  Wed Mar 24 12:22:41 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 24 Mar 2021 12:22:41 GMT
Subject: Integrated: 8264051: Remove unused TRAPS parameters from runtime
 functions
In-Reply-To: <QilnkRJZ0jTihZLCVVaOduS_DDY8tf5AsniNIdfhkEA=.ea89688e-e158-47bd-92b8-979ee1d84c59@github.com>
References: <QilnkRJZ0jTihZLCVVaOduS_DDY8tf5AsniNIdfhkEA=.ea89688e-e158-47bd-92b8-979ee1d84c59@github.com>
Message-ID: <6a-CuUWVEzmQ3dbzXYGI6wCB0nnWEJGiSABpwRDSaMQ=.d5cd639f-040c-4a6d-87ef-6189dcb84c03@github.com>

On Tue, 23 Mar 2021 16:40:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the TRAPS parameter from compute_modifier_flags(), lookup_instance_method_in_klasses and nest_host_error.
> 
> There's a progressive effort to remove cases where the last parameter of a function is THREAD, and it's unclear why it is ignoring an exception or whether an exception is expected, if it doesn't subsequently have a check for HAS_PENDING_EXCEPTION.
> 
> Tested locally with tier1 tests and tier1 tests on 4 Oracle platforms in progress.

This pull request has now been integrated.

Changeset: bc91596c
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bc91596c
Stats:     52 lines in 16 files changed: 0 ins; 17 del; 35 mod

8264051: Remove unused TRAPS parameters from runtime functions

Reviewed-by: iklam, dholmes

-------------

PR: https://git.openjdk.java.net/jdk/pull/3157

From coleenp at openjdk.java.net  Wed Mar 24 12:22:40 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 24 Mar 2021 12:22:40 GMT
Subject: RFR: 8264051: Remove unused TRAPS parameters from runtime
 functions [v2]
In-Reply-To: <qWI-jJ9_akBmb0yiZxbgnXesDlMTO9dRHNjVu5MD81k=.5800c4ea-5d10-4d78-a9b9-04416b3f6cd1@github.com>
References: <QilnkRJZ0jTihZLCVVaOduS_DDY8tf5AsniNIdfhkEA=.ea89688e-e158-47bd-92b8-979ee1d84c59@github.com>
 <yagx1vYMUXLTNsYf0CgM7EooFWjFODri1FVAVaZVO-w=.9f281c78-ba32-480b-a3ce-8a767a0bbf3f@github.com>
 <qWI-jJ9_akBmb0yiZxbgnXesDlMTO9dRHNjVu5MD81k=.5800c4ea-5d10-4d78-a9b9-04416b3f6cd1@github.com>
Message-ID: <vkeho808jN_jZQyTDesTwvdmJLPPZSqLhR30nkhgRCA=.80e45fd3-7111-4247-8db3-e7d156b19e0d@github.com>

On Wed, 24 Mar 2021 03:50:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed thread parameter from nest_host_error and callers.
>
> Looks good!
> 
> Thanks,
> David

Thanks for reviewing!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3157

From minqi at openjdk.java.net  Wed Mar 24 15:35:55 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 24 Mar 2021 15:35:55 GMT
Subject: RFR: 8259070: Add jcmd option to dump CDS [v6]
In-Reply-To: <hwrc1zAz8G180ToL-C3EuUIF-5R17F5Gm1zcPMBpOtE=.e002a377-e0e2-485b-a08e-b63675a9746b@github.com>
References: <hwrc1zAz8G180ToL-C3EuUIF-5R17F5Gm1zcPMBpOtE=.e002a377-e0e2-485b-a08e-b63675a9746b@github.com>
Message-ID: <mqqiZ6EOrup7-XsdnxAUR1oq6gmwpRbWoPIlAjksJ20=.9beba68b-9cbe-47fe-9a6b-0fd38f410495@github.com>

> Hi, Please review
> 
>   Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with
>   `java -XX:DumpLoadedClassList=<classlist> .... `  
>  to collect shareable class names and saved in file `<classlist>` , then 
>   `java -Xshare:dump -XX:SharedClassListFile=<classlist> -XX:SharedArchiveFile=<archivefile> ...`
>   With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime  to dump an archive.
>    The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved.
>    New added jcmd option:
>    `jcmd <pid or AppName> VM.cds static_dump <filename>`
>    or
>     `jcmd <pid or AppName> VM.cds dynamic_dump <filename>`
>   To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. 
>    The file name is optional, if the file name is not supplied, the file name will take format of `java_pid<number>_static.jsa` or `java_pid<number>_dynamic.jsa` for static and dynamic respectively. The `<number>` is the application process ID.
> 
>   Tests: tier1,tier2,tier3,tier4
> 
> Thanks
> Yumin

Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:

  Remove redundant check for if a class is shareable

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2737/files
  - new: https://git.openjdk.java.net/jdk/pull/2737/files/e882a074..3834f042

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2737&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2737&range=04-05

  Stats: 52 lines in 2 files changed: 1 ins; 33 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2737.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2737/head:pull/2737

PR: https://git.openjdk.java.net/jdk/pull/2737

From github.com+168222+mgkwill at openjdk.java.net  Wed Mar 24 18:04:41 2021
From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Wed, 24 Mar 2021 18:04:41 GMT
Subject: RFR: 8176026: SA: Huge heap sizes cause a negative value to be
 displayed in the jhisto heap total [v2]
In-Reply-To: <-OxCoBAqyBOqOS5DP3C4NPkq8PFLwwCL6wBXmiqeEzU=.f62e8e0f-418e-4129-a91a-c10e1571466e@github.com>
References: <h_pqXvxIEJRhxH3sEA5fO8Z1XidOU3aZZij_ZVUx1kw=.1cf3982e-7dac-4d2d-80a0-9629eb50c203@github.com>
 <-OxCoBAqyBOqOS5DP3C4NPkq8PFLwwCL6wBXmiqeEzU=.f62e8e0f-418e-4129-a91a-c10e1571466e@github.com>
Message-ID: <BkFGfr0e7nPjWsavu4uIUw-DJRVxVR8Nkrz10ibr9XI=.301d7768-a8d7-40e2-a637-69108831707b@github.com>

On Tue, 23 Mar 2021 13:35:05 GMT, Koichi Sakata <ksakata at openjdk.org> wrote:

>> When a heap is used more than about 2.1GB, clhsdb jhisto shows a negative number in the total field.
>> 
>> $ java -Xmx20g Sample
>> 
>> $ jhsdb clhsdb --pid 5773
>> Attaching to process 5773, please wait...
>> hsdb> jhisto
>> ...
>> 299:            1       16      jdk.internal.misc.Unsafe
>> 300:            3402    10737610256     byte[]
>> Total :         15823   -2146661280
>> Heap traversal took 1.793 seconds.
>> (Incidentally, the Sample is a program that only allocates many objects.)
>> 
>> #### Details
>> This is because in ObjectHistogram class the totalSize variable is int type.
>> 
>> The total size is the total of ObjectHistogramElement#getSize() and getSize() returns long. So I changed int to long in the ObjectHistogram class.
>> 
>> Additionally, I changed the type of the totalCount. This doesn't cause a bug, but ObjectHistogramElement#getCount() also returns long. So it doesn't need to treat it as int, I think. ObjectHistogramElement#compare() also do the same thing, so a class that is a huge size show the bottom of the list.
>> 
>> #### Tests
>> The jtreg test was successful.
>> $ sudo make run-test TEST=serviceability/sa/ClhsdbJhisto.java
>> 
>> $ cat build/linux-x86_64-server-fastdebug/test-results/jtreg_test_hotspot_jtreg_serviceability_sa_ClhsdbJhisto_java/text/summary.txt
>> serviceability/sa/ClhsdbJhisto.java  Passed. Execution successful
>> 
>> I confirmed the output with the same program.
>> 
>> $ ./jdk/build/linux-x86_64-server-fastdebug/jdk/bin/java -Xmx20g Sample
>> $ ./jdk/build/linux-x86_64-server-fastdebug/jdk/bin/jhsdb clhsdb --pid 10196
>> Attaching to process 10196, please wait...
>> hsdb> jhisto
>> Object Histogram:
>> 
>> num       #instances    #bytes  Class description
>> --------------------------------------------------------------------------
>> 1:              3405    13958838400     byte[]
>> 2:              887     109032  java.lang.Class
>> ...
>> 300:            1       16      jdk.internal.misc.Unsafe
>> Total :         15827   13959470288
>> Heap traversal took 1.72 seconds.
>
> Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the sort bug for huge bytes in jhisto

Marked as reviewed by mgkwill at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3087

From ccheung at openjdk.java.net  Wed Mar 24 21:20:41 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Wed, 24 Mar 2021 21:20:41 GMT
Subject: RFR: 8259070: Add jcmd option to dump CDS [v6]
In-Reply-To: <mqqiZ6EOrup7-XsdnxAUR1oq6gmwpRbWoPIlAjksJ20=.9beba68b-9cbe-47fe-9a6b-0fd38f410495@github.com>
References: <hwrc1zAz8G180ToL-C3EuUIF-5R17F5Gm1zcPMBpOtE=.e002a377-e0e2-485b-a08e-b63675a9746b@github.com>
 <mqqiZ6EOrup7-XsdnxAUR1oq6gmwpRbWoPIlAjksJ20=.9beba68b-9cbe-47fe-9a6b-0fd38f410495@github.com>
Message-ID: <JulVdEJStTfVzAZ3_k25vZaEswM4tQJcdTRJx7IETsA=.7c22b2c0-37ad-4e24-977b-32e02e822c82@github.com>

On Wed, 24 Mar 2021 15:35:55 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Hi, Please review
>> 
>>   Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with
>>   `java -XX:DumpLoadedClassList=<classlist> .... `  
>>  to collect shareable class names and saved in file `<classlist>` , then 
>>   `java -Xshare:dump -XX:SharedClassListFile=<classlist> -XX:SharedArchiveFile=<archivefile> ...`
>>   With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime  to dump an archive.
>>    The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved.
>>    New added jcmd option:
>>    `jcmd <pid or AppName> VM.cds static_dump <filename>`
>>    or
>>     `jcmd <pid or AppName> VM.cds dynamic_dump <filename>`
>>   To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. 
>>    The file name is optional, if the file name is not supplied, the file name will take format of `java_pid<number>_static.jsa` or `java_pid<number>_dynamic.jsa` for static and dynamic respectively. The `<number>` is the application process ID.
>> 
>>   Tests: tier1,tier2,tier3,tier4
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant check for if a class is shareable

src/hotspot/share/oops/instanceKlass.cpp line 4269:

> 4267:         }
> 4268: 
> 4269:         if (class_loader == NULL && ClassLoader::contains_append_entry(stream->source())) {

Since the above has been removed, I think the `ClassLoader::contains_append_entry()` function can be removed too.

test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTest.java line 59:

> 57: public class JCmdTest {
> 58:     static final String TEST_CLASS[] = {"LingeredTestApp", "jdk/test/lib/apps/LingeredApp"};
> 59:     static final String TEST_JAR   = "test.jar";

`TEST_JAR` is unused.

test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTest.java line 168:

> 166:          "-XX:ArchiveClassesAtExit=tmp.jsa",
> 167:          "-Xshare:auto",
> 168:          "-Xshare:on"};

The `excludeFlags` doesn't match the ones in CDS.java.

226     private static String[] excludeFlags = {
227          "-XX:DumpLoadedClassList=",
228          "-XX:+DumpSharedSpaces",
229          "-XX:+DynamicDumpSharedSpaces",
230          "-XX:+RecordDynamicDumpInfo",
231          "-Xshare:",
232          "-XX:SharedClassListFile=",
233          "-XX:SharedArchiveFile=",
234          "-XX:ArchiveClassesAtExit=",
235          "-XX:+UseSharedSpaces",
236          "-XX:+RequireSharedSpaces"};

-------------

PR: https://git.openjdk.java.net/jdk/pull/2737

From ccheung at openjdk.java.net  Wed Mar 24 21:25:42 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Wed, 24 Mar 2021 21:25:42 GMT
Subject: RFR: 8259070: Add jcmd option to dump CDS [v6]
In-Reply-To: <mqqiZ6EOrup7-XsdnxAUR1oq6gmwpRbWoPIlAjksJ20=.9beba68b-9cbe-47fe-9a6b-0fd38f410495@github.com>
References: <hwrc1zAz8G180ToL-C3EuUIF-5R17F5Gm1zcPMBpOtE=.e002a377-e0e2-485b-a08e-b63675a9746b@github.com>
 <mqqiZ6EOrup7-XsdnxAUR1oq6gmwpRbWoPIlAjksJ20=.9beba68b-9cbe-47fe-9a6b-0fd38f410495@github.com>
Message-ID: <fPl81ci3xpjOsDkQcaTXfAyNOh9T62FRtxEmHPxgeiQ=.b646dc5e-5211-4253-9c26-730bb37f8550@github.com>

On Wed, 24 Mar 2021 15:35:55 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Hi, Please review
>> 
>>   Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with
>>   `java -XX:DumpLoadedClassList=<classlist> .... `  
>>  to collect shareable class names and saved in file `<classlist>` , then 
>>   `java -Xshare:dump -XX:SharedClassListFile=<classlist> -XX:SharedArchiveFile=<archivefile> ...`
>>   With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime  to dump an archive.
>>    The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved.
>>    New added jcmd option:
>>    `jcmd <pid or AppName> VM.cds static_dump <filename>`
>>    or
>>     `jcmd <pid or AppName> VM.cds dynamic_dump <filename>`
>>   To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. 
>>    The file name is optional, if the file name is not supplied, the file name will take format of `java_pid<number>_static.jsa` or `java_pid<number>_dynamic.jsa` for static and dynamic respectively. The `<number>` is the application process ID.
>> 
>>   Tests: tier1,tier2,tier3,tier4
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant check for if a class is shareable

test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTest.java line 184:

> 182:             test(SUBCMD_STATIC_DUMP, null, pid, EXPECT_PASS);
> 183:         }
> 184:         app.stopApp();

For successful dumping cases like the above, you may want to add a runtime case making sure one of the classes in the jar is loaded from the archive.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2737

From kbarrett at openjdk.java.net  Thu Mar 25 07:33:55 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 25 Mar 2021 07:33:55 GMT
Subject: RFR: 8264166: OopStorage should support specifying MEMFLAGS for
 allocations
Message-ID: <FRPMmvoMVevCP3CwsJBVW3F3wpa7b93MI_Yu3BKMZiQ=.6536f661-6860-438b-998a-b1fcc853973a@github.com>

Please review this change to OopStorage to allow the MEMFLAGS value for associated allocations to be specified when the storage object is constructed.  This allows a subsystem that needs an OopStorage object to associate its allocation with others for that subsystem in NMT tracking and reporting.

Testing:
mach5 tier1.
Manually compared NMT output before and after this change for a test that generated a lot of one particular OopStorage entries.

-------------

Commit messages:
 - add MEMFLAGS support to OopStorage

Changes: https://git.openjdk.java.net/jdk/pull/3188/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3188&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264166
  Stats: 64 lines in 16 files changed: 30 ins; 0 del; 34 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3188.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3188/head:pull/3188

PR: https://git.openjdk.java.net/jdk/pull/3188

From tschatzl at openjdk.java.net  Thu Mar 25 08:23:39 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 25 Mar 2021 08:23:39 GMT
Subject: RFR: 8264166: OopStorage should support specifying MEMFLAGS for
 allocations
In-Reply-To: <FRPMmvoMVevCP3CwsJBVW3F3wpa7b93MI_Yu3BKMZiQ=.6536f661-6860-438b-998a-b1fcc853973a@github.com>
References: <FRPMmvoMVevCP3CwsJBVW3F3wpa7b93MI_Yu3BKMZiQ=.6536f661-6860-438b-998a-b1fcc853973a@github.com>
Message-ID: <rjjVwsqN7gpWPaJ13obNpd96iTlY9CIalB6GImajaa8=.905a5dcb-581b-4e9b-910d-3a87fd59f23d@github.com>

On Thu, 25 Mar 2021 07:27:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to OopStorage to allow the MEMFLAGS value for associated allocations to be specified when the storage object is constructed.  This allows a subsystem that needs an OopStorage object to associate its allocation with others for that subsystem in NMT tracking and reporting.
> 
> Testing:
> mach5 tier1.
> Manually compared NMT output before and after this change for a test that generated a lot of one particular OopStorage entries.

Lgtm.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3188

From stefank at openjdk.java.net  Thu Mar 25 08:44:44 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Thu, 25 Mar 2021 08:44:44 GMT
Subject: RFR: 8264166: OopStorage should support specifying MEMFLAGS for
 allocations
In-Reply-To: <FRPMmvoMVevCP3CwsJBVW3F3wpa7b93MI_Yu3BKMZiQ=.6536f661-6860-438b-998a-b1fcc853973a@github.com>
References: <FRPMmvoMVevCP3CwsJBVW3F3wpa7b93MI_Yu3BKMZiQ=.6536f661-6860-438b-998a-b1fcc853973a@github.com>
Message-ID: <4UnYhJAxCldsUhFA9awgPMJyvm9jHFZZRW6pVTYYOc0=.f7b45db1-fe2c-492d-a999-e1a6f529b66e@github.com>

On Thu, 25 Mar 2021 07:27:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to OopStorage to allow the MEMFLAGS value for associated allocations to be specified when the storage object is constructed.  This allows a subsystem that needs an OopStorage object to associate its allocation with others for that subsystem in NMT tracking and reporting.
> 
> Testing:
> mach5 tier1.
> Manually compared NMT output before and after this change for a test that generated a lot of one particular OopStorage entries.

Looks good. Just one nit

src/hotspot/share/gc/shared/oopStorage.inline.hpp line 28:

> 26: #define SHARE_GC_SHARED_OOPSTORAGE_INLINE_HPP
> 27: 
> 28: #include "memory/allocation.hpp"

Sort order

-------------

Marked as reviewed by stefank (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3188

From kbarrett at openjdk.java.net  Thu Mar 25 10:56:40 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 25 Mar 2021 10:56:40 GMT
Subject: RFR: 8264166: OopStorage should support specifying MEMFLAGS for
 allocations
In-Reply-To: <4UnYhJAxCldsUhFA9awgPMJyvm9jHFZZRW6pVTYYOc0=.f7b45db1-fe2c-492d-a999-e1a6f529b66e@github.com>
References: <FRPMmvoMVevCP3CwsJBVW3F3wpa7b93MI_Yu3BKMZiQ=.6536f661-6860-438b-998a-b1fcc853973a@github.com>
 <4UnYhJAxCldsUhFA9awgPMJyvm9jHFZZRW6pVTYYOc0=.f7b45db1-fe2c-492d-a999-e1a6f529b66e@github.com>
Message-ID: <VAgMRUO4mks3nH2XbYqK0qbxM_vP6XwIq4L6jXQu0cg=.37d3a0b8-5dc9-4323-b357-8d0f1a004db2@github.com>

On Thu, 25 Mar 2021 08:42:06 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Please review this change to OopStorage to allow the MEMFLAGS value for associated allocations to be specified when the storage object is constructed.  This allows a subsystem that needs an OopStorage object to associate its allocation with others for that subsystem in NMT tracking and reporting.
>> 
>> Testing:
>> mach5 tier1.
>> Manually compared NMT output before and after this change for a test that generated a lot of one particular OopStorage entries.
>
> src/hotspot/share/gc/shared/oopStorage.inline.hpp line 28:
> 
>> 26: #define SHARE_GC_SHARED_OOPSTORAGE_INLINE_HPP
>> 27: 
>> 28: #include "memory/allocation.hpp"
> 
> Sort order

Oops, will fix.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3188

From rehn at openjdk.java.net  Thu Mar 25 13:18:54 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Thu, 25 Mar 2021 13:18:54 GMT
Subject: RFR: 8257831: Suspend with handshakes
Message-ID: <xv1j0DkGolookgzzyT7w9hz5-mlD0QaeHfqL3b9HJ6I=.c33a0757-1f6e-4a7c-afa4-2d531849d4fc@github.com>

A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request.

Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread).
Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. 

Suspend:
Requesting thread -> synchronous handshake -> target thread
Inside synchronus handshake (HandshakeState lock is locked while
executing any handshake):
	- Set suspended flag
	- Install asynchronous handshake

Target thread -> tries to leave dormant state -> Executes handshakes
Target only executes asynchronous handshake:
	- While suspended
	- Go to blocked
	- Wait on HandshakeState lock

Resume:
Resuming thread:
	- Lock HandshakeState lock
	- Clear suspended flag
	- Notify HandshakeState lock
	- Unlock HandshakeState lock

The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set.

----
Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors.

----
Regarding the changed test, the documentation says:
"If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it."

But the code:
  LOG("suspendTestedThreads: before JVMTI SuspendThreadList");
  err = jvmti->SuspendThreadList(threads_count, threads, results);
  ...
  // Allow the Main thread to inspect the result of tested threads suspension	
  agent_unlock(jni);
  
The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock().
Thus main thread is stuck forever on:
  // Block until the suspender thread competes the tested threads suspension	
  agent_lock(jni);

And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state.

----

This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp.
(Pre-review comments here:
https://github.com/openjdk/jdk/pull/2625)

---- 
Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and
combinations like running with -XX:ZCollectionInterval=0.01 -
XX:ZFragmentationLimit=0.
Running above some of above concurrently (load ~240), slow debug,
etc...

-------------

Commit messages:
 - 8257831: Suspend with handshake (review baseline)

Changes: https://git.openjdk.java.net/jdk/pull/3191/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3191&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257831
  Stats: 1315 lines in 38 files changed: 271 ins; 855 del; 189 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3191.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3191/head:pull/3191

PR: https://git.openjdk.java.net/jdk/pull/3191

From ccheung at openjdk.java.net  Thu Mar 25 13:23:46 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 25 Mar 2021 13:23:46 GMT
Subject: RFR: 8259070: Add jcmd option to dump CDS [v6]
In-Reply-To: <mqqiZ6EOrup7-XsdnxAUR1oq6gmwpRbWoPIlAjksJ20=.9beba68b-9cbe-47fe-9a6b-0fd38f410495@github.com>
References: <hwrc1zAz8G180ToL-C3EuUIF-5R17F5Gm1zcPMBpOtE=.e002a377-e0e2-485b-a08e-b63675a9746b@github.com>
 <mqqiZ6EOrup7-XsdnxAUR1oq6gmwpRbWoPIlAjksJ20=.9beba68b-9cbe-47fe-9a6b-0fd38f410495@github.com>
Message-ID: <c5Lv5012nw8R1YiZ38djn8z94mwGiWBt_izFYR-u1l8=.13508b82-4d45-4a06-a593-e2d43aa4e0c4@github.com>

On Wed, 24 Mar 2021 15:35:55 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Hi, Please review
>> 
>>   Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with
>>   `java -XX:DumpLoadedClassList=<classlist> .... `  
>>  to collect shareable class names and saved in file `<classlist>` , then 
>>   `java -Xshare:dump -XX:SharedClassListFile=<classlist> -XX:SharedArchiveFile=<archivefile> ...`
>>   With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime  to dump an archive.
>>    The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved.
>>    New added jcmd option:
>>    `jcmd <pid or AppName> VM.cds static_dump <filename>`
>>    or
>>     `jcmd <pid or AppName> VM.cds dynamic_dump <filename>`
>>   To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. 
>>    The file name is optional, if the file name is not supplied, the file name will take format of `java_pid<number>_static.jsa` or `java_pid<number>_dynamic.jsa` for static and dynamic respectively. The `<number>` is the application process ID.
>> 
>>   Tests: tier1,tier2,tier3,tier4
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant check for if a class is shareable

Looks good. Few comments below.
Also, the vmSymbols.h and diagnosticCommand.hpp need copyright update.

Thanks,
Calvin

-------------

Changes requested by ccheung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2737

From dfuchs at openjdk.java.net  Thu Mar 25 17:37:49 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 25 Mar 2021 17:37:49 GMT
Subject: RFR: 8264124: Update MXBean specification and implementation to
 extend mapping of CompositeType to records
Message-ID: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com>

This RFE proposes to extend the MXBean framework to define a mapping to records.

The MXBean framework already defines a mapping of `CompositeType` to plain java objects. Records are a natural representation of CompositeTypes. A record can be easily reconstructed from a `CompositeData` through the record canonical constructor. A clear advantage of records over plain java objects is that the canonical constructor will not need to be annotated in order to map composite data property names to constructor parameter names.

With this RFE, here is an example comparing coding a composite type `NamedNumber` that consists of an `int` and a `String`, using records and using a plain java class. In both case, the `CompositeType` looks like this:

CompositeType(
    "NamedNumber",                      // typeName
    "NamedNumber",                      // description
    new String[] {"number", "name"},    // itemNames
    new String[] {"number", "name"},    // itemDescriptions
    new OpenType[] {SimpleType.INTEGER,
                    SimpleType.STRING}  // itemTypes
);

The plain Java class needs a public constructor annotated with `@ConstructorParameters` annotation:

public class NamedNumber {
    public int getNumber() {return number;}
    public String getName() {return name;}
    @ConstructorParameters({"number", "name"})
    public NamedNumber(int number, String name) {
        this.number = number;
        this.name = name;
    }
    private final int number;
    private final String name;
}

And the equivalent with a record class: 

public record NamedNumber(int number, String name) {}

-------------

Commit messages:
 - 8264124: Update MXBean specification and implementation to extend mapping of CompositeType to records

Changes: https://git.openjdk.java.net/jdk/pull/3201/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3201&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264124
  Stats: 679 lines in 3 files changed: 647 ins; 12 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3201.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3201/head:pull/3201

PR: https://git.openjdk.java.net/jdk/pull/3201

From akozlov at openjdk.java.net  Thu Mar 25 18:14:03 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 25 Mar 2021 18:14:03 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v30]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <Jrz4tirzLXG971FqxgjEXuaXq0W2bgIfFIdmHi7iTxE=.5f3847bc-e82d-49b7-829d-b160167e6ef2@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 117 commits:

 - JDK-8261397: bsd_aarch64 part
 - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
 - Merge branch 'master' into jdk-macos
 - JDK-8262491: bsd_aarch64 part
 - JDK-8263002: bsd_aarch64 part
 - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
 - Wider #ifdef block
 - Fix most of issues in java/foreign/ tests
   
   Failures related to va_args are tracked in JDK-8263512.
 - Add Azul copyright
 - Update Oracle copyright years
 - ... and 107 more: https://git.openjdk.java.net/jdk/compare/b006f22f...d3629967

-------------

Changes: https://git.openjdk.java.net/jdk/pull/2200/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=29
  Stats: 2960 lines in 75 files changed: 2851 ins; 27 del; 82 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

PR: https://git.openjdk.java.net/jdk/pull/2200

From akozlov at openjdk.java.net  Thu Mar 25 18:14:06 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 25 Mar 2021 18:14:06 GMT
Subject: Integrated: 8253795: Implementation of JEP 391: macOS/AArch64 Port
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <n4vzkDG9kXNf_qMitLPTjoo8F7Zxd2W6FwBS2P-v5WA=.d5639e5b-2912-4d6f-9b8a-1f1bf79669a7@github.com>

On Fri, 22 Jan 2021 18:49:42 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

This pull request has now been integrated.

Changeset: dbc9e4b5
Author:    Anton Kozlov <akozlov at openjdk.org>
Committer: Vladimir Kempik <vkempik at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dbc9e4b5
Stats:     2960 lines in 75 files changed: 2851 ins; 27 del; 82 mod

8253795: Implementation of JEP 391: macOS/AArch64 Port
8253816: Support macOS W^X
8253817: Support macOS Aarch64 ABI in Interpreter
8253818: Support macOS Aarch64 ABI for compiled wrappers
8253819: Implement os/cpu for macOS/AArch64
8253839: Update tests and JDK code for macOS/Aarch64
8254941: Implement Serviceability Agent for macOS/AArch64
8255776: Change build system for macOS/AArch64
8262903: [macos_aarch64] Thread::current() called on detached thread

Co-authored-by: Vladimir Kempik <vkempik at openjdk.org>
Co-authored-by: Bernhard Urban-Forster <burban at openjdk.org>
Co-authored-by: Ludovic Henry <luhenry at openjdk.org>
Co-authored-by: Monica Beckwith <mbeckwit at openjdk.org>
Reviewed-by: erikj, ihse, prr, cjplummer, stefank, gziemski, aph, mbeckwit, luhenry

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From akozlov at openjdk.java.net  Thu Mar 25 18:14:03 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 25 Mar 2021 18:14:03 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: <HVuUWfsnr8fqATnVU2b4S7VdSOwuKg1xxEZW-islB2g=.56d118c4-745d-4371-91a9-3bb250c9b7a3@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
 <RIXlvES_OOQ47-4YI1CLX7kLG4JJ70NRr0g0G0X6zb0=.4a106aa2-8e76-4b5a-9206-cebc6f17472e@github.com>
 <HVuUWfsnr8fqATnVU2b4S7VdSOwuKg1xxEZW-islB2g=.56d118c4-745d-4371-91a9-3bb250c9b7a3@github.com>
Message-ID: <AZT2E7ZueFv02oR3VekvtEzPUeXZ9gYvzBo-9ImCMqg=.4e988c58-da72-4824-b86e-10c6b035b17a@github.com>

On Tue, 23 Mar 2021 16:33:50 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Marked as reviewed by luhenry (Author).
>
>> > > > [ Back-porting this patch to JDK 11] depends on the will of openjdk11 maintainers to accept this (and few other, like jep-388, as we depend on it) contribution.
>> > > 
>> > > 
>> > > To the extent that 11u has fixed policies :) we definitely have a policy of accepting patches to keep 11u working on current hardware. So yes.
>> > 
>> > 
>> > @lewurm That sounds like a green flag for you and jep-388 (with its R18_RESERVED functionality) ;)
>> 
>> Thanks, @theRealAph, and @VladimirKempik . We are on it!
> 
> It's going to be tricky to do in a really clean way, given some of the weirdnesses of the ABI. However, I think there's probably a need for it

The JEP was targeted to JDK17. So I propose to integrate this. 

Thank you all for the reviews, suggestions, discussions, and support!

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From amenkov at openjdk.java.net  Thu Mar 25 19:51:27 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 25 Mar 2021 19:51:27 GMT
Subject: Integrated: 8262081:
 vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter001/TestDescription.java
 failed with "ERROR: eventSet1.size() != 3 :: 2"
In-Reply-To: <-WEaFWU7bEOckY-ltHYclBwZMbgrKw5ye8TaZ7cryn4=.2ef514f2-9881-400b-b53f-fc1b3465b177@github.com>
References: <-WEaFWU7bEOckY-ltHYclBwZMbgrKw5ye8TaZ7cryn4=.2ef514f2-9881-400b-b53f-fc1b3465b177@github.com>
Message-ID: <AqkJLcilvu_4V659AtM9oaqKXIbvDrg3D0Ck2NmbdN8=.f458b65b-7e5a-40db-9518-d18c6f5a8380@github.com>

On Mon, 22 Mar 2021 21:56:01 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates the test to use special method to wait for ThreadDeathEvent for the specific thread, ignoring event from other threads

This pull request has now been integrated.

Changeset: 2a5e0dd3
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2a5e0dd3
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8262081: vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter001/TestDescription.java failed with "ERROR: eventSet1.size() != 3 :: 2"

Reviewed-by: cjplummer, lmesnik, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3133

From github.com+76791+alblue at openjdk.java.net  Thu Mar 25 20:02:26 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Thu, 25 Mar 2021 20:02:26 GMT
Subject: RFR: 8264087: Use the blessed modifier order in jdk.jconsole
In-Reply-To: <uYAxme-SvM9eepxk7ZJfI8_6qmVbtcCrhx7z_Vj_gEw=.e6392a25-ee6c-40a5-9808-1ae1e42b3428@github.com>
References: <uYAxme-SvM9eepxk7ZJfI8_6qmVbtcCrhx7z_Vj_gEw=.e6392a25-ee6c-40a5-9808-1ae1e42b3428@github.com>
Message-ID: <evta37Ph_euZPSfjoVecWS2yqrrLC2jFHPz3RYGIQhE=.1a11deeb-f16d-4bbd-80df-ea84dce9a6cf@github.com>

On Tue, 23 Mar 2021 21:43:47 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> 8264087: Use the blessed modifier order in jdk.jconsole

Is anyone able to review this change? The only change in 31 lines are modifier orders.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3164

From alanb at openjdk.java.net  Fri Mar 26 06:50:25 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 26 Mar 2021 06:50:25 GMT
Subject: RFR: 8264087: Use the blessed modifier order in jdk.jconsole
In-Reply-To: <uYAxme-SvM9eepxk7ZJfI8_6qmVbtcCrhx7z_Vj_gEw=.e6392a25-ee6c-40a5-9808-1ae1e42b3428@github.com>
References: <uYAxme-SvM9eepxk7ZJfI8_6qmVbtcCrhx7z_Vj_gEw=.e6392a25-ee6c-40a5-9808-1ae1e42b3428@github.com>
Message-ID: <go8CI-04B7HnxYR-85lKPAJ20TBj48uw3Nole_FkJkQ=.dca1d07d-f60f-48da-b7a9-ca160c069c04@github.com>

On Tue, 23 Mar 2021 21:43:47 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> 8264087: Use the blessed modifier order in jdk.jconsole

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3164

From kbarrett at openjdk.java.net  Fri Mar 26 07:47:46 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 26 Mar 2021 07:47:46 GMT
Subject: RFR: 8264166: OopStorage should support specifying MEMFLAGS for
 allocations [v2]
In-Reply-To: <FRPMmvoMVevCP3CwsJBVW3F3wpa7b93MI_Yu3BKMZiQ=.6536f661-6860-438b-998a-b1fcc853973a@github.com>
References: <FRPMmvoMVevCP3CwsJBVW3F3wpa7b93MI_Yu3BKMZiQ=.6536f661-6860-438b-998a-b1fcc853973a@github.com>
Message-ID: <7sMGu0o72hVvkvsdpInVQ5Wkvxo6Qiv1K-V-y8Kz6BA=.70a8297c-0717-4130-82b5-b5293a5a5408@github.com>

> Please review this change to OopStorage to allow the MEMFLAGS value for associated allocations to be specified when the storage object is constructed.  This allows a subsystem that needs an OopStorage object to associate its allocation with others for that subsystem in NMT tracking and reporting.
> 
> Testing:
> mach5 tier1.
> Manually compared NMT output before and after this change for a test that generated a lot of one particular OopStorage entries.

Kim Barrett 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 oopstorage_memflags
 - fix include sort order
 - add MEMFLAGS support to OopStorage

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3188/files
  - new: https://git.openjdk.java.net/jdk/pull/3188/files/a9c808be..6a30454f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3188&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3188&range=00-01

  Stats: 7366 lines in 175 files changed: 6712 ins; 240 del; 414 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3188.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3188/head:pull/3188

PR: https://git.openjdk.java.net/jdk/pull/3188

From kbarrett at openjdk.java.net  Fri Mar 26 07:47:46 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 26 Mar 2021 07:47:46 GMT
Subject: Integrated: 8264166: OopStorage should support specifying MEMFLAGS
 for allocations
In-Reply-To: <FRPMmvoMVevCP3CwsJBVW3F3wpa7b93MI_Yu3BKMZiQ=.6536f661-6860-438b-998a-b1fcc853973a@github.com>
References: <FRPMmvoMVevCP3CwsJBVW3F3wpa7b93MI_Yu3BKMZiQ=.6536f661-6860-438b-998a-b1fcc853973a@github.com>
Message-ID: <0lZbxFyo0UuHHM2ew5Nz_YhCj75hw_3VGG2oGeMEZdU=.d60f7968-1cba-4a6b-97a4-1043f8ab1bb9@github.com>

On Thu, 25 Mar 2021 07:27:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to OopStorage to allow the MEMFLAGS value for associated allocations to be specified when the storage object is constructed.  This allows a subsystem that needs an OopStorage object to associate its allocation with others for that subsystem in NMT tracking and reporting.
> 
> Testing:
> mach5 tier1.
> Manually compared NMT output before and after this change for a test that generated a lot of one particular OopStorage entries.

This pull request has now been integrated.

Changeset: bb354b9d
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bb354b9d
Stats:     64 lines in 16 files changed: 30 ins; 0 del; 34 mod

8264166: OopStorage should support specifying MEMFLAGS for allocations

Reviewed-by: tschatzl, stefank

-------------

PR: https://git.openjdk.java.net/jdk/pull/3188

From rrich at openjdk.java.net  Fri Mar 26 11:15:27 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Fri, 26 Mar 2021 11:15:27 GMT
Subject: RFR: 8257831: Suspend with handshakes
In-Reply-To: <xv1j0DkGolookgzzyT7w9hz5-mlD0QaeHfqL3b9HJ6I=.c33a0757-1f6e-4a7c-afa4-2d531849d4fc@github.com>
References: <xv1j0DkGolookgzzyT7w9hz5-mlD0QaeHfqL3b9HJ6I=.c33a0757-1f6e-4a7c-afa4-2d531849d4fc@github.com>
Message-ID: <TwWb5CHE-xU251ZogolO5er1huqqetDmHXiMdzmuTxs=.29fab1e7-cc18-4c89-aa11-d3b263302da9@github.com>

On Thu, 25 Mar 2021 10:56:23 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request.
> 
> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread).
> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. 
> 
> Suspend:
> Requesting thread -> synchronous handshake -> target thread
> Inside synchronus handshake (HandshakeState lock is locked while
> executing any handshake):
> 	- Set suspended flag
> 	- Install asynchronous handshake
> 
> Target thread -> tries to leave dormant state -> Executes handshakes
> Target only executes asynchronous handshake:
> 	- While suspended
> 	- Go to blocked
> 	- Wait on HandshakeState lock
> 
> Resume:
> Resuming thread:
> 	- Lock HandshakeState lock
> 	- Clear suspended flag
> 	- Notify HandshakeState lock
> 	- Unlock HandshakeState lock
> 
> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set.
> 
> ----
> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors.
> 
> ----
> Regarding the changed test, the documentation says:
> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it."
> 
> But the code:
>   LOG("suspendTestedThreads: before JVMTI SuspendThreadList");
>   err = jvmti->SuspendThreadList(threads_count, threads, results);
>   ...
>   // Allow the Main thread to inspect the result of tested threads suspension	
>   agent_unlock(jni);
>   
> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock().
> Thus main thread is stuck forever on:
>   // Block until the suspender thread competes the tested threads suspension	
>   agent_lock(jni);
> 
> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state.
> 
> ----
> 
> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp.
> (Pre-review comments here:
> https://github.com/openjdk/jdk/pull/2625)
> 
> ---- 
> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and
> combinations like running with -XX:ZCollectionInterval=0.01 -
> XX:ZFragmentationLimit=0.
> Running above some of above concurrently (load ~240), slow debug,
> etc...

Hi Robbin,
I think the preview/pre-review #2625 of this was affected by mailing-list hick-up as I've not received a notification about it and I could not find it in the archives either. Just wanted to let you know in case you aren't already aware.
Looks promising though :)

-------------

PR: https://git.openjdk.java.net/jdk/pull/3191

From rehn at openjdk.java.net  Fri Mar 26 12:09:24 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Fri, 26 Mar 2021 12:09:24 GMT
Subject: RFR: 8257831: Suspend with handshakes
In-Reply-To: <TwWb5CHE-xU251ZogolO5er1huqqetDmHXiMdzmuTxs=.29fab1e7-cc18-4c89-aa11-d3b263302da9@github.com>
References: <xv1j0DkGolookgzzyT7w9hz5-mlD0QaeHfqL3b9HJ6I=.c33a0757-1f6e-4a7c-afa4-2d531849d4fc@github.com>
 <TwWb5CHE-xU251ZogolO5er1huqqetDmHXiMdzmuTxs=.29fab1e7-cc18-4c89-aa11-d3b263302da9@github.com>
Message-ID: <0WFPM3DcN_hflUOsvql5afaRQZQDbrB47PmYaBuN4ok=.22d77e47-9f97-4daa-8946-057ed2e916ff@github.com>

On Fri, 26 Mar 2021 11:12:38 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> Hi Robbin,
> I think the preview/pre-review #2625 of this was affected by mailing-list hick-up as I've not received a notification about it and I could not find it in the archives either. Just wanted to let you know in case you aren't already aware.
> Looks promising though :)

Hi @reinrich, I think that is because that PR was only in draft state.

Good! :)

Thanks, Robbin

-------------

PR: https://git.openjdk.java.net/jdk/pull/3191

From rehn at openjdk.java.net  Fri Mar 26 13:21:43 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Fri, 26 Mar 2021 13:21:43 GMT
Subject: RFR: 8257831: Suspend with handshakes [v2]
In-Reply-To: <xv1j0DkGolookgzzyT7w9hz5-mlD0QaeHfqL3b9HJ6I=.c33a0757-1f6e-4a7c-afa4-2d531849d4fc@github.com>
References: <xv1j0DkGolookgzzyT7w9hz5-mlD0QaeHfqL3b9HJ6I=.c33a0757-1f6e-4a7c-afa4-2d531849d4fc@github.com>
Message-ID: <a6Fjizolorcan3_uaH8QqfAmw6LqdOwC02DG2Yp6ZNg=.d8ebe170-cdda-42d7-912c-0210f9643da6@github.com>

> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request.
> 
> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread).
> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. 
> 
> Suspend:
> Requesting thread -> synchronous handshake -> target thread
> Inside synchronus handshake (HandshakeState lock is locked while
> executing any handshake):
> 	- Set suspended flag
> 	- Install asynchronous handshake
> 
> Target thread -> tries to leave dormant state -> Executes handshakes
> Target only executes asynchronous handshake:
> 	- While suspended
> 	- Go to blocked
> 	- Wait on HandshakeState lock
> 
> Resume:
> Resuming thread:
> 	- Lock HandshakeState lock
> 	- Clear suspended flag
> 	- Notify HandshakeState lock
> 	- Unlock HandshakeState lock
> 
> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set.
> 
> ----
> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors.
> 
> ----
> Regarding the changed test, the documentation says:
> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it."
> 
> But the code:
>   LOG("suspendTestedThreads: before JVMTI SuspendThreadList");
>   err = jvmti->SuspendThreadList(threads_count, threads, results);
>   ...
>   // Allow the Main thread to inspect the result of tested threads suspension	
>   agent_unlock(jni);
>   
> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock().
> Thus main thread is stuck forever on:
>   // Block until the suspender thread competes the tested threads suspension	
>   agent_lock(jni);
> 
> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state.
> 
> ----
> 
> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp.
> (Pre-review comments here:
> https://github.com/openjdk/jdk/pull/2625)
> 
> ---- 
> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and
> combinations like running with -XX:ZCollectionInterval=0.01 -
> XX:ZFragmentationLimit=0.
> Running above some of above concurrently (load ~240), slow debug,
> etc...

Robbin Ehn 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 SuspendInHandshake
 - 8257831: Suspend with handshake (review baseline)

-------------

Changes: https://git.openjdk.java.net/jdk/pull/3191/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3191&range=01
  Stats: 1313 lines in 38 files changed: 271 ins; 855 del; 187 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3191.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3191/head:pull/3191

PR: https://git.openjdk.java.net/jdk/pull/3191

From ksakata at openjdk.java.net  Fri Mar 26 13:51:40 2021
From: ksakata at openjdk.java.net (Koichi Sakata)
Date: Fri, 26 Mar 2021 13:51:40 GMT
Subject: RFR: 8176026: SA: Huge heap sizes cause a negative value to be
 displayed in the jhisto heap total [v3]
In-Reply-To: <h_pqXvxIEJRhxH3sEA5fO8Z1XidOU3aZZij_ZVUx1kw=.1cf3982e-7dac-4d2d-80a0-9629eb50c203@github.com>
References: <h_pqXvxIEJRhxH3sEA5fO8Z1XidOU3aZZij_ZVUx1kw=.1cf3982e-7dac-4d2d-80a0-9629eb50c203@github.com>
Message-ID: <2nwnR_h9DuOC_2rdT9z7j3ickPchjK9ozWv9obWCP_M=.018c90ea-1fc8-4ee5-b1a6-6b1a65a308e4@github.com>

> When a heap is used more than about 2.1GB, clhsdb jhisto shows a negative number in the total field.
> 
> $ java -Xmx20g Sample
> 
> $ jhsdb clhsdb --pid 5773
> Attaching to process 5773, please wait...
> hsdb> jhisto
> ...
> 299:            1       16      jdk.internal.misc.Unsafe
> 300:            3402    10737610256     byte[]
> Total :         15823   -2146661280
> Heap traversal took 1.793 seconds.
> (Incidentally, the Sample is a program that only allocates many objects.)
> 
> #### Details
> This is because in ObjectHistogram class the totalSize variable is int type.
> 
> The total size is the total of ObjectHistogramElement#getSize() and getSize() returns long. So I changed int to long in the ObjectHistogram class.
> 
> Additionally, I changed the type of the totalCount. This doesn't cause a bug, but ObjectHistogramElement#getCount() also returns long. So it doesn't need to treat it as int, I think. ObjectHistogramElement#compare() also do the same thing, so a class that is a huge size show the bottom of the list.
> 
> #### Tests
> The jtreg test was successful.
> $ sudo make run-test TEST=serviceability/sa/ClhsdbJhisto.java
> 
> $ cat build/linux-x86_64-server-fastdebug/test-results/jtreg_test_hotspot_jtreg_serviceability_sa_ClhsdbJhisto_java/text/summary.txt
> serviceability/sa/ClhsdbJhisto.java  Passed. Execution successful
> 
> I confirmed the output with the same program.
> 
> $ ./jdk/build/linux-x86_64-server-fastdebug/jdk/bin/java -Xmx20g Sample
> $ ./jdk/build/linux-x86_64-server-fastdebug/jdk/bin/jhsdb clhsdb --pid 10196
> Attaching to process 10196, please wait...
> hsdb> jhisto
> Object Histogram:
> 
> num       #instances    #bytes  Class description
> --------------------------------------------------------------------------
> 1:              3405    13958838400     byte[]
> 2:              887     109032  java.lang.Class
> ...
> 300:            1       16      jdk.internal.misc.Unsafe
> Total :         15827   13959470288
> Heap traversal took 1.72 seconds.

Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3087/files
  - new: https://git.openjdk.java.net/jdk/pull/3087/files/248d49fe..4d3b6f88

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3087&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3087&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3087.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3087/head:pull/3087

PR: https://git.openjdk.java.net/jdk/pull/3087

From ksakata at openjdk.java.net  Fri Mar 26 13:59:28 2021
From: ksakata at openjdk.java.net (Koichi Sakata)
Date: Fri, 26 Mar 2021 13:59:28 GMT
Subject: RFR: 8176026: SA: Huge heap sizes cause a negative value to be
 displayed in the jhisto heap total [v2]
In-Reply-To: <BkFGfr0e7nPjWsavu4uIUw-DJRVxVR8Nkrz10ibr9XI=.301d7768-a8d7-40e2-a637-69108831707b@github.com>
References: <h_pqXvxIEJRhxH3sEA5fO8Z1XidOU3aZZij_ZVUx1kw=.1cf3982e-7dac-4d2d-80a0-9629eb50c203@github.com>
 <-OxCoBAqyBOqOS5DP3C4NPkq8PFLwwCL6wBXmiqeEzU=.f62e8e0f-418e-4129-a91a-c10e1571466e@github.com>
 <BkFGfr0e7nPjWsavu4uIUw-DJRVxVR8Nkrz10ibr9XI=.301d7768-a8d7-40e2-a637-69108831707b@github.com>
Message-ID: <naNp5Gfz6-7byH9fp98I9mxx26hLk_5wxHH7a_EHVp4=.09b59ba0-5887-43ef-b788-b6d682798e47@github.com>

On Wed, 24 Mar 2021 18:01:30 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

>> Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix the sort bug for huge bytes in jhisto
>
> Marked as reviewed by mgkwill at github.com (no known OpenJDK username).

I just updated the copyright.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3087

From rrich at openjdk.java.net  Fri Mar 26 14:10:24 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Fri, 26 Mar 2021 14:10:24 GMT
Subject: RFR: 8257831: Suspend with handshakes
In-Reply-To: <0WFPM3DcN_hflUOsvql5afaRQZQDbrB47PmYaBuN4ok=.22d77e47-9f97-4daa-8946-057ed2e916ff@github.com>
References: <xv1j0DkGolookgzzyT7w9hz5-mlD0QaeHfqL3b9HJ6I=.c33a0757-1f6e-4a7c-afa4-2d531849d4fc@github.com>
 <TwWb5CHE-xU251ZogolO5er1huqqetDmHXiMdzmuTxs=.29fab1e7-cc18-4c89-aa11-d3b263302da9@github.com>
 <0WFPM3DcN_hflUOsvql5afaRQZQDbrB47PmYaBuN4ok=.22d77e47-9f97-4daa-8946-057ed2e916ff@github.com>
Message-ID: <e3k-CHM4_CwXbh5_qaInTLL-GsUxsis4q5SiCjYhZ4s=.aa2dfde3-77b6-4f05-b3aa-54ba27b19bba@github.com>

On Fri, 26 Mar 2021 12:06:31 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> 
> 
> > Hi Robbin,
> > I think the preview/pre-review #2625 of this was affected by mailing-list hick-up as I've not received a notification about it and I could not find it in the archives either. Just wanted to let you know in case you aren't already aware.
> > Looks promising though :)
> 
> Hi @reinrich, I think that is because that PR was only in draft state.
> 

Ah, alright, makes sense :)

Thanks, Richard.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3191

From alanb at openjdk.java.net  Fri Mar 26 14:47:25 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 26 Mar 2021 14:47:25 GMT
Subject: RFR: 8264124: Update MXBean specification and implementation to
 extend mapping of CompositeType to records
In-Reply-To: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com>
References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com>
Message-ID: <-EtiIDRMVgkZHFkgQNRXOFTlrWolfgt_YJaOiidM2BM=.a023dd02-072f-4613-bcd9-3dc21cede688@github.com>

On Thu, 25 Mar 2021 17:30:52 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> This RFE proposes to extend the MXBean framework to define a mapping to records.
> 
> The MXBean framework already defines a mapping of `CompositeType` to plain java objects. Records are a natural representation of CompositeTypes. A record can be easily reconstructed from a `CompositeData` through the record canonical constructor. A clear advantage of records over plain java objects is that the canonical constructor will not need to be annotated in order to map composite data property names to constructor parameter names.
> 
> With this RFE, here is an example comparing coding a composite type `NamedNumber` that consists of an `int` and a `String`, using records and using a plain java class. In both case, the `CompositeType` looks like this:
> 
> CompositeType(
>     "NamedNumber",                      // typeName
>     "NamedNumber",                      // description
>     new String[] {"number", "name"},    // itemNames
>     new String[] {"number", "name"},    // itemDescriptions
>     new OpenType[] {SimpleType.INTEGER,
>                     SimpleType.STRING}  // itemTypes
> );
> 
> The plain Java class needs a public constructor annotated with `@ConstructorParameters` annotation:
> 
> public class NamedNumber {
>     public int getNumber() {return number;}
>     public String getName() {return name;}
>     @ConstructorParameters({"number", "name"})
>     public NamedNumber(int number, String name) {
>         this.number = number;
>         this.name = name;
>     }
>     private final int number;
>     private final String name;
> }
> 
> And the equivalent with a record class: 
> 
> public record NamedNumber(int number, String name) {}

src/java.management/share/classes/javax/management/MXBean.java line 792:

> 790:        accessor for a record component {@code name} of type <em>T</em>,
> 791:        then the item in the {@code CompositeType} has the same name
> 792:        than the record component, and has type <em>opentype(T)</em>.</p>

The update to the MXBean spec looks good. Do you have a typo here, I assume it should say "as the record component".

-------------

PR: https://git.openjdk.java.net/jdk/pull/3201

From dfuchs at openjdk.java.net  Fri Mar 26 15:15:49 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 26 Mar 2021 15:15:49 GMT
Subject: RFR: 8264124: Update MXBean specification and implementation to
 extend mapping of CompositeType to records [v2]
In-Reply-To: <-EtiIDRMVgkZHFkgQNRXOFTlrWolfgt_YJaOiidM2BM=.a023dd02-072f-4613-bcd9-3dc21cede688@github.com>
References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com>
 <-EtiIDRMVgkZHFkgQNRXOFTlrWolfgt_YJaOiidM2BM=.a023dd02-072f-4613-bcd9-3dc21cede688@github.com>
Message-ID: <TlflCKHKd12userPEmS-FhKqSnnRBU1ZOJomvohTgnk=.56c692ec-1c70-4d7b-bf0d-96348046b497@github.com>

On Fri, 26 Mar 2021 14:45:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed typo. Moved example with record after example with from method to respect the logical order of precedence.
>
> src/java.management/share/classes/javax/management/MXBean.java line 792:
> 
>> 790:        accessor for a record component {@code name} of type <em>T</em>,
>> 791:        then the item in the {@code CompositeType} has the same name
>> 792:        than the record component, and has type <em>opentype(T)</em>.</p>
> 
> The update to the MXBean spec looks good. Do you have a typo here, I assume it should say "as the record component".

Right, thanks. Qualifying it as "a typo" was too kind ;-)
I have updated the PR. I also moved the `record` example after the `from` example to respect the order of precedence.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3201

From dfuchs at openjdk.java.net  Fri Mar 26 15:15:48 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 26 Mar 2021 15:15:48 GMT
Subject: RFR: 8264124: Update MXBean specification and implementation to
 extend mapping of CompositeType to records [v2]
In-Reply-To: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com>
References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com>
Message-ID: <cAwbOBwhGERyBUbreMVPVsCabpDTPi3oqSDQ53FTVlk=.70a98535-36bb-4483-b461-5de840998d06@github.com>

> This RFE proposes to extend the MXBean framework to define a mapping to records.
> 
> The MXBean framework already defines a mapping of `CompositeType` to plain java objects. Records are a natural representation of CompositeTypes. A record can be easily reconstructed from a `CompositeData` through the record canonical constructor. A clear advantage of records over plain java objects is that the canonical constructor will not need to be annotated in order to map composite data property names to constructor parameter names.
> 
> With this RFE, here is an example comparing coding a composite type `NamedNumber` that consists of an `int` and a `String`, using records and using a plain java class. In both case, the `CompositeType` looks like this:
> 
> CompositeType(
>     "NamedNumber",                      // typeName
>     "NamedNumber",                      // description
>     new String[] {"number", "name"},    // itemNames
>     new String[] {"number", "name"},    // itemDescriptions
>     new OpenType[] {SimpleType.INTEGER,
>                     SimpleType.STRING}  // itemTypes
> );
> 
> The plain Java class needs a public constructor annotated with `@ConstructorParameters` annotation:
> 
> public class NamedNumber {
>     public int getNumber() {return number;}
>     public String getName() {return name;}
>     @ConstructorParameters({"number", "name"})
>     public NamedNumber(int number, String name) {
>         this.number = number;
>         this.name = name;
>     }
>     private final int number;
>     private final String name;
> }
> 
> And the equivalent with a record class: 
> 
> public record NamedNumber(int number, String name) {}

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Fixed typo. Moved example with record after example with from method to respect the logical order of precedence.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3201/files
  - new: https://git.openjdk.java.net/jdk/pull/3201/files/bf8b437f..1c3292ce

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3201&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3201&range=00-01

  Stats: 19 lines in 1 file changed: 9 ins; 9 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3201.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3201/head:pull/3201

PR: https://git.openjdk.java.net/jdk/pull/3201

From chegar at openjdk.java.net  Fri Mar 26 17:09:27 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 26 Mar 2021 17:09:27 GMT
Subject: RFR: 8264124: Update MXBean specification and implementation to
 extend mapping of CompositeType to records
In-Reply-To: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com>
References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com>
Message-ID: <4E-rd6ZdQdNUrnJ2qyEX1fqbowM_0KgcppdNzNc81Cc=.705d5233-bb66-474e-ad1e-7f4b5fa364c7@github.com>

On Thu, 25 Mar 2021 17:30:52 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> This RFE proposes to extend the MXBean framework to define a mapping to records.
> 
> The MXBean framework already defines a mapping of `CompositeType` to plain java objects. Records are a natural representation of CompositeTypes. A record can be easily reconstructed from a `CompositeData` through the record canonical constructor. A clear advantage of records over plain java objects is that the canonical constructor will not need to be annotated in order to map composite data property names to constructor parameter names.
> 
> With this RFE, here is an example comparing coding a composite type `NamedNumber` that consists of an `int` and a `String`, using records and using a plain java class. In both case, the `CompositeType` looks like this:
> 
> CompositeType(
>     "NamedNumber",                      // typeName
>     "NamedNumber",                      // description
>     new String[] {"number", "name"},    // itemNames
>     new String[] {"number", "name"},    // itemDescriptions
>     new OpenType[] {SimpleType.INTEGER,
>                     SimpleType.STRING}  // itemTypes
> );
> 
> The plain Java class needs a public constructor annotated with `@ConstructorParameters` annotation:
> 
> public class NamedNumber {
>     public int getNumber() {return number;}
>     public String getName() {return name;}
>     @ConstructorParameters({"number", "name"})
>     public NamedNumber(int number, String name) {
>         this.number = number;
>         this.name = name;
>     }
>     private final int number;
>     private final String name;
> }
> 
> And the equivalent with a record class: 
> 
> public record NamedNumber(int number, String name) {}

Generally, I think that this is a good change. It nice to see that the semantics of record classes can be leverage to build the CompositeType in this way. And equally how that maps back to the canonical constructor.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3201

From amenkov at openjdk.java.net  Fri Mar 26 20:06:32 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Fri, 26 Mar 2021 20:06:32 GMT
Subject: RFR: 8264087: Use the blessed modifier order in jdk.jconsole
In-Reply-To: <uYAxme-SvM9eepxk7ZJfI8_6qmVbtcCrhx7z_Vj_gEw=.e6392a25-ee6c-40a5-9808-1ae1e42b3428@github.com>
References: <uYAxme-SvM9eepxk7ZJfI8_6qmVbtcCrhx7z_Vj_gEw=.e6392a25-ee6c-40a5-9808-1ae1e42b3428@github.com>
Message-ID: <2vrmmwaEoPZ4iXbdOK9qkM8SEatKGJkUOENNPaP8kNI=.57b74242-c39e-47da-acc4-91866f50de9c@github.com>

On Tue, 23 Mar 2021 21:43:47 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> 8264087: Use the blessed modifier order in jdk.jconsole

Marked as reviewed by amenkov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3164

From redestad at openjdk.java.net  Fri Mar 26 21:28:25 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 26 Mar 2021 21:28:25 GMT
Subject: RFR: 8264087: Use the blessed modifier order in jdk.jconsole
In-Reply-To: <uYAxme-SvM9eepxk7ZJfI8_6qmVbtcCrhx7z_Vj_gEw=.e6392a25-ee6c-40a5-9808-1ae1e42b3428@github.com>
References: <uYAxme-SvM9eepxk7ZJfI8_6qmVbtcCrhx7z_Vj_gEw=.e6392a25-ee6c-40a5-9808-1ae1e42b3428@github.com>
Message-ID: <R3CWDJfR8aJfyFpO83ZSAOlfnpDqs1qd1CQtaUj5t_M=.d4e44b93-8c31-4043-8c6c-2339abe232f1@github.com>

On Tue, 23 Mar 2021 21:43:47 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> 8264087: Use the blessed modifier order in jdk.jconsole

Marked as reviewed by redestad (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3164

From github.com+76791+alblue at openjdk.java.net  Fri Mar 26 21:28:26 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Fri, 26 Mar 2021 21:28:26 GMT
Subject: Integrated: 8264087: Use the blessed modifier order in jdk.jconsole
In-Reply-To: <uYAxme-SvM9eepxk7ZJfI8_6qmVbtcCrhx7z_Vj_gEw=.e6392a25-ee6c-40a5-9808-1ae1e42b3428@github.com>
References: <uYAxme-SvM9eepxk7ZJfI8_6qmVbtcCrhx7z_Vj_gEw=.e6392a25-ee6c-40a5-9808-1ae1e42b3428@github.com>
Message-ID: <Mv4ACs6dXV6qLXaYWWpyFl5lqHaZUhKcnCrdk8mzJaM=.d4dd26e2-be64-4d40-a41e-04fd6688aa25@github.com>

On Tue, 23 Mar 2021 21:43:47 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> 8264087: Use the blessed modifier order in jdk.jconsole

This pull request has now been integrated.

Changeset: 59ed1fa2
Author:    Alex Blewitt <alex.blewitt at gmail.com>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/59ed1fa2
Stats:     31 lines in 11 files changed: 0 ins; 0 del; 31 mod

8264087: Use the blessed modifier order in jdk.jconsole

Reviewed-by: alanb, amenkov, redestad

-------------

PR: https://git.openjdk.java.net/jdk/pull/3164

From david.holmes at oracle.com  Sat Mar 27 00:08:20 2021
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 27 Mar 2021 10:08:20 +1000
Subject: os_windows.cpp : simplify is_thread_cpu_time_supported ?
In-Reply-To: <AM0PR02MB5412C4FEE4987351D831400393619@AM0PR02MB5412.eurprd02.prod.outlook.com>
References: <AM0PR02MB541282AE5F6043A9260A2EF093629@AM0PR02MB5412.eurprd02.prod.outlook.com>
 <d8e462ed-8338-b197-194f-2a982728361c@oracle.com>
 <3fbc20cb-02ff-178a-32c8-18934a5949e9@oracle.com>
 <AM0PR02MB5412C4FEE4987351D831400393619@AM0PR02MB5412.eurprd02.prod.outlook.com>
Message-ID: <3b9acb57-c17f-c767-efcd-4e3c929118d5@oracle.com>

On 26/03/2021 6:06 pm, Baesken, Matthias wrote:
> Hi David, thanks for the info .
> 
> I found  https://docs.microsoft.com/en-us/windows/win32/procthread/thread-security-and-access-rights
>    so it looks like  we  need  THREAD_QUERY_INFORMATION or THREAD_QUERY_LIMITED_INFORMATION access right   for  GetThreadTimes .
> 
> On the other hand ,   the test in os::is_thread_cpu_time_supported()   on Windows      might  (temporary ?)  fail for  other reasons too , it  is not clear to me if this  is really always
>   related to the wrong access rights ?

Sure it could fail for other reasons (unfortunately win32 docs don't 
actually list them). So I tend to agree that this kind of check as a 
global "do we support thread cpu times" is not the right test to do. The 
question is really about "does this platform provide an API for getting 
the thread cpu time" - and it does. Whether you can query a given target 
thread at runtime is a different matter altogether.

I wish I knew exactly what caused this check to be put in place as it 
doesn't seem appropriate. Maybe someone from serviceablity (cc'd) remembers?

> And at some places in HS code like  jfrThreadCPULoadEvent.cpp  ,    os::thread_cpu_time  is called anyway without checking  for  os::is_thread_cpu_time_supported()  ;
>   same for thread.cpp  / Thread::print_on  but this is just printing some output so it is most likely not really a big issue  on Windows .

As long as they can tolerate the -1 return if it fails then it is up to 
that code whether or not to bother with the check. But I think the check 
is primarily for the M&M/JVMTI capability checking.

Cheers,
David

> Best regards, Matthias
> 
> 
> 
> 
>>> On 25/03/2021 11:49 pm, Baesken, Matthias wrote:
>>>> Hello,? I wonder , should we just return? true? in
>>>> os::is_thread_cpu_time_supported()?? on Windows? ?
>>>>
>>>> See
>>>>
>>>> https://github.com/openjdk/jdk/blob/master/src/hotspot/os/windows/os_windows.cpp#L4588
>>>>
>>>> According to? MSDN
>>>> https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-getthreadtimes
>>>>
>>>> GetThreadTimes is supported? on Win2003/XP and higher . This should be
>>>> fine for OpenJDK .
>>>
>>> Yes it should be fine. There may be other Windows archaisms in the code
>>> that could be cleaned up now.
>>
>> The issue was not API availability (we got rid of that check a long time
>> ago) but security permissions. We actually just returned "true" prior to
>> JDK 5 but that was changed by JDK-4884677 when the JVM TI support was added.
>>
>> It is a bit messy. We use the result of
>> os::is_thread_cpu_time_supported() at initialization time, on the main
>> thread to then decide the global availability of this feature. And via
>> the normal launcher that thread will have all access bits set and so we
>> will flag thread_cpu_time as being available. At runtime we might
>> encounter a thread for which the access bits are not present and so the
>> actual get_thread_cpu_time call may return -1. In theory the JVM could
>> be loaded on a thread without full permissions and so we would then
>> globally disable thread_cpu_time.
>>
>> So I think this code has to stay.
> 
> 

From mchung at openjdk.java.net  Sat Mar 27 01:52:27 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Sat, 27 Mar 2021 01:52:27 GMT
Subject: RFR: 8264124: Update MXBean specification and implementation to
 extend mapping of CompositeType to records [v2]
In-Reply-To: <cAwbOBwhGERyBUbreMVPVsCabpDTPi3oqSDQ53FTVlk=.70a98535-36bb-4483-b461-5de840998d06@github.com>
References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com>
 <cAwbOBwhGERyBUbreMVPVsCabpDTPi3oqSDQ53FTVlk=.70a98535-36bb-4483-b461-5de840998d06@github.com>
Message-ID: <C0e13BnsgJfRQvS86QICp_CwhR4PIaC498P5FnjazjE=.4e8467e1-8b8b-4899-bf22-470328d31007@github.com>

On Fri, 26 Mar 2021 15:15:48 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This RFE proposes to extend the MXBean framework to define a mapping to records.
>> 
>> The MXBean framework already defines a mapping of `CompositeType` to plain java objects. Records are a natural representation of CompositeTypes. A record can be easily reconstructed from a `CompositeData` through the record canonical constructor. A clear advantage of records over plain java objects is that the canonical constructor will not need to be annotated in order to map composite data property names to constructor parameter names.
>> 
>> With this RFE, here is an example comparing coding a composite type `NamedNumber` that consists of an `int` and a `String`, using records and using a plain java class. In both case, the `CompositeType` looks like this:
>> 
>> CompositeType(
>>     "NamedNumber",                      // typeName
>>     "NamedNumber",                      // description
>>     new String[] {"number", "name"},    // itemNames
>>     new String[] {"number", "name"},    // itemDescriptions
>>     new OpenType[] {SimpleType.INTEGER,
>>                     SimpleType.STRING}  // itemTypes
>> );
>> 
>> The plain Java class needs a public constructor annotated with `@ConstructorParameters` annotation:
>> 
>> public class NamedNumber {
>>     public int getNumber() {return number;}
>>     public String getName() {return name;}
>>     @ConstructorParameters({"number", "name"})
>>     public NamedNumber(int number, String name) {
>>         this.number = number;
>>         this.name = name;
>>     }
>>     private final int number;
>>     private final String name;
>> }
>> 
>> And the equivalent with a record class: 
>> 
>> public record NamedNumber(int number, String name) {}
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed typo. Moved example with record after example with from method to respect the logical order of precedence.

src/java.management/share/classes/javax/management/MXBean.java line 757:

> 755: 
> 756:     <p>If the class is a {@link Record}, its getters are the
> 757:       accessors for the record components. Otherwise, the

It may be good to add a link like {@linkplain RecordComponent record components}

-------------

PR: https://git.openjdk.java.net/jdk/pull/3201

From mchung at openjdk.java.net  Sat Mar 27 01:52:28 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Sat, 27 Mar 2021 01:52:28 GMT
Subject: RFR: 8264124: Update MXBean specification and implementation to
 extend mapping of CompositeType to records [v2]
In-Reply-To: <C0e13BnsgJfRQvS86QICp_CwhR4PIaC498P5FnjazjE=.4e8467e1-8b8b-4899-bf22-470328d31007@github.com>
References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com>
 <cAwbOBwhGERyBUbreMVPVsCabpDTPi3oqSDQ53FTVlk=.70a98535-36bb-4483-b461-5de840998d06@github.com>
 <C0e13BnsgJfRQvS86QICp_CwhR4PIaC498P5FnjazjE=.4e8467e1-8b8b-4899-bf22-470328d31007@github.com>
Message-ID: <0RxhjEDdg8ZZRNLjbknHs_sa71hn6ax3LAtv_-pZGqY=.a3e1631a-4280-4b2e-95c0-794785b9d165@github.com>

On Sat, 27 Mar 2021 01:40:17 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed typo. Moved example with record after example with from method to respect the logical order of precedence.
>
> src/java.management/share/classes/javax/management/MXBean.java line 757:
> 
>> 755: 
>> 756:     <p>If the class is a {@link Record}, its getters are the
>> 757:       accessors for the record components. Otherwise, the
> 
> It may be good to add a link like {@linkplain RecordComponent record components}

You add record in "Mappings for other types".  I think it deserves a separate section "Mappings for record classes" (maybe after primitive types).   It's useful to add a row for record in the summary table above "Mappings for primitive types"

-------------

PR: https://git.openjdk.java.net/jdk/pull/3201

From ysuenaga at openjdk.java.net  Sat Mar 27 11:18:28 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sat, 27 Mar 2021 11:18:28 GMT
Subject: Integrated: 8263670: pmap and pstack in jhsdb do not work on debug
 server
In-Reply-To: <OzFp9WFONUqIUYqdZ78D04bfnhgOSaeB1WqmPtyUdA0=.7dcf74d3-6819-4c9c-b878-a26cfcd0cbc6@github.com>
References: <OzFp9WFONUqIUYqdZ78D04bfnhgOSaeB1WqmPtyUdA0=.7dcf74d3-6819-4c9c-b878-a26cfcd0cbc6@github.com>
Message-ID: <Ib2SPT7bze9nDkOKpa-77v-CmPGo1XJBiVrMEwCXqxs=.272dbb53-e251-432d-bdb8-bf50ada96d7a@github.com>

On Tue, 16 Mar 2021 12:01:30 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> jhsdb supports pmap (jhsdb jmap) and pstack (jhsdb jstack --mixed), and they work fine if they attach to live process or to coredump, however they do not work on debug server as following:
> 
> $ jhsdb jmap --connect localhost
> Attaching to remote server localhost, please wait...
> Debugger attached successfully.
> Server compiler detected.
> JVM version is 11.0.10+9
> remote configuration is not yet implemented
> 
> pmap and pstack depend on CDebugger in SA, however it would not be set in case of remote debugger client. We can avoid it if we can delegate the process to debug server.

This pull request has now been integrated.

Changeset: a209ed01
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a209ed01
Stats:     190 lines in 10 files changed: 146 ins; 26 del; 18 mod

8263670: pmap and pstack in jhsdb do not work on debug server

Reviewed-by: cjplummer, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3027

From ysuenaga at openjdk.java.net  Mon Mar 29 01:20:48 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Mon, 29 Mar 2021 01:20:48 GMT
Subject: RFR: 8263636: Add --disableregistry option to jhsdb debugd
Message-ID: <EZGTcFz1D0U_0kUXlkiszkSJjBwMw15PMWoT7NHENLc=.c499f47e-f8aa-44c9-abc9-9b11813f704d@github.com>

`jhsdb debugd` will start RMI registry by default, but we want to prevent it due to port confliction in some cases. We can control it with `sun.jvm.hotspot.rmi.startRegistry` system property. However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option.

This PR introduces `--disableregistry` to `jhsdb debugd`. Please review [CSR](https://bugs.openjdk.java.net/browse/JDK-8264021) too.

-------------

Commit messages:
 - 8263636: Add --disableregistry option to jhsdb debugd

Changes: https://git.openjdk.java.net/jdk/pull/3233/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3233&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263636
  Stats: 162 lines in 4 files changed: 151 ins; 0 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3233.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3233/head:pull/3233

PR: https://git.openjdk.java.net/jdk/pull/3233

From lzang at openjdk.java.net  Mon Mar 29 11:27:49 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 29 Mar 2021 11:27:49 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v19]
In-Reply-To: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
Message-ID: <IzLkrTZv5Mw_rvkk3SUw-J1C0jLl6Owj0XYcRdx2TIk=.52b42f8b-8bcc-4872-b8b3-b6c6e699dcfc@github.com>

> 8252842: Extend jmap to support parallel heap dump

Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:

 - Merge branch 'master' into par-dump
 - Typo fix
 - remove parallel option and dumpheapext command
 - Revert "hide the dumpheapext error message"
   
   This reverts commit 1af0e1e2bfab4f5d079c03ff0cb25067acacdac4.
 - resize large object threshold
 - Merge branch 'master' into par-dump
 - Merge branch 'master' into par-dump
 - code clean
 - fix trailing white space issue
 - reduce memory consumption and fix memory leak issue
 - ... and 14 more: https://git.openjdk.java.net/jdk/compare/aefc1560...301cf8cd

-------------

Changes: https://git.openjdk.java.net/jdk/pull/2261/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=18
  Stats: 864 lines in 6 files changed: 662 ins; 60 del; 142 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2261.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2261/head:pull/2261

PR: https://git.openjdk.java.net/jdk/pull/2261

From hseigel at openjdk.java.net  Mon Mar 29 17:45:56 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 29 Mar 2021 17:45:56 GMT
Subject: RFR: 8264193: Remove TRAPS parameters for modules and defaultmethods
Message-ID: <6WUbVyj36re-dOR20BOerxSJckUtyoHjwo6z9r1g-as=.fddf28f1-8cdd-4954-b734-65b36f5b8de4@github.com>

Please review this change for JDK-8264193 to remove unneeded TRAPS parameters from modules and default methods files.  Besides removing TRAPS, Modules::get_named_module() was changed to return an oop instead of a jobject, removing its need for a TRAPS parameter.

This change was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.

Thanks, Harold

-------------

Commit messages:
 - 8264193: Remove TRAPS parameters for modules and defaultmethods

Changes: https://git.openjdk.java.net/jdk/pull/3247/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3247&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264193
  Stats: 61 lines in 8 files changed: 1 ins; 13 del; 47 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3247.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3247/head:pull/3247

PR: https://git.openjdk.java.net/jdk/pull/3247

From lfoltan at openjdk.java.net  Mon Mar 29 19:20:36 2021
From: lfoltan at openjdk.java.net (Lois Foltan)
Date: Mon, 29 Mar 2021 19:20:36 GMT
Subject: RFR: 8264193: Remove TRAPS parameters for modules and
 defaultmethods
In-Reply-To: <6WUbVyj36re-dOR20BOerxSJckUtyoHjwo6z9r1g-as=.fddf28f1-8cdd-4954-b734-65b36f5b8de4@github.com>
References: <6WUbVyj36re-dOR20BOerxSJckUtyoHjwo6z9r1g-as=.fddf28f1-8cdd-4954-b734-65b36f5b8de4@github.com>
Message-ID: <xPalium_BqftMLC_mnuiiq8Y7ju8UEFpr8Ad2ge6m_8=.4bbbe25d-6d3b-4dad-b322-3a038c8c7bf5@github.com>

On Mon, 29 Mar 2021 17:40:09 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this change for JDK-8264193 to remove unneeded TRAPS parameters from modules and default methods files.  Besides removing TRAPS, Modules::get_named_module() was changed to return an oop instead of a jobject, removing its need for a TRAPS parameter.
> 
> This change was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.
> 
> Thanks, Harold

Looks good Harold!
Lois

-------------

Marked as reviewed by lfoltan (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3247

From ccheung at openjdk.java.net  Mon Mar 29 20:34:41 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Mon, 29 Mar 2021 20:34:41 GMT
Subject: RFR: 8264193: Remove TRAPS parameters for modules and
 defaultmethods
In-Reply-To: <6WUbVyj36re-dOR20BOerxSJckUtyoHjwo6z9r1g-as=.fddf28f1-8cdd-4954-b734-65b36f5b8de4@github.com>
References: <6WUbVyj36re-dOR20BOerxSJckUtyoHjwo6z9r1g-as=.fddf28f1-8cdd-4954-b734-65b36f5b8de4@github.com>
Message-ID: <HRUwtdB_2fgRVoIIkTLxfoDj1RWaflA6DdaCPo96iQs=.71425f5e-b428-4981-ba16-f9e5ff117963@github.com>

On Mon, 29 Mar 2021 17:40:09 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this change for JDK-8264193 to remove unneeded TRAPS parameters from modules and default methods files.  Besides removing TRAPS, Modules::get_named_module() was changed to return an oop instead of a jobject, removing its need for a TRAPS parameter.
> 
> This change was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.
> 
> Thanks, Harold

LGTM.

-------------

Marked as reviewed by ccheung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3247

From github.com+76791+alblue at openjdk.java.net  Mon Mar 29 21:07:01 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Mon, 29 Mar 2021 21:07:01 GMT
Subject: RFR: 8263854: Use the blessed modifier in jdk.internal.jvmstat
Message-ID: <rrSdxlrv3z-oVhRNkDd5XTcgCl3MfGMh2pUxHl2uCTc=.5790a3c6-9b78-4e96-bb45-bace638ebae8@github.com>

8263854: Use the blessed modifier in jdk.internal.jvmstat

-------------

Commit messages:
 - 8263854: Use the blessed modifier in jdk.internal.jvmstat

Changes: https://git.openjdk.java.net/jdk/pull/3252/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3252&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263854
  Stats: 78 lines in 5 files changed: 0 ins; 0 del; 78 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3252.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3252/head:pull/3252

PR: https://git.openjdk.java.net/jdk/pull/3252

From smarks at openjdk.java.net  Mon Mar 29 21:21:02 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Mon, 29 Mar 2021 21:21:02 GMT
Subject: RFR: 8264148: Update spec for exceptions retrofitted for
 exception chaining
In-Reply-To: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
Message-ID: <6OMPZyYBcENA0hYJp2fEMiwyhvAIT7cXwPoMVQ0TIUc=.65348cfa-1afe-4a3d-8d18-002f2be28d7d@github.com>

On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8264148: Update spec for exceptions retrofitted for exception chaining

The removal of the obsolescent "As of release 1.4, this exception has been retrofitted..." is good. Changing the calls from the other exception-getting methods to `getCause()` is also good. I'm less sure of the utility of deprecating these older methods. The deprecation will issue warning messages; is there any benefit to the calling code to migrating from the older methods to `getCause()`? If they're exactly equivalent, then I think the benefits are small, compared to the cost of dealing with warnings. Thus for most of these cases I think that not deprecating the older methods is reasonable, and perhaps the explanation should be converted to an `@apiNote`.

(The considerations for the JDK itself are different, though, which is why I support changing the call sites.)

One special case is the **public field** in `WriteAbortedException`. This is really bad and something ought to be done about this, including deprecation, and maybe more. This implies that the exception is mutable, right? Hrrmph. Isn't there a general rule that once the cause has been set (either via a constructor or via initCause) the exception is immutable? Maybe the field should be deprecated, and `getCause()` should return the cause from the superclass. That's a behavior change of course, and I don't know how to assess the compatibility impact. But the current situation just seems wrong.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3182

From darcy at openjdk.java.net  Mon Mar 29 21:21:02 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 29 Mar 2021 21:21:02 GMT
Subject: RFR: 8264148: Update spec for exceptions retrofitted for exception
 chaining
Message-ID: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>

8264148: Update spec for exceptions retrofitted for exception chaining

-------------

Commit messages:
 - Respond to review feedback.
 - Respond to review feedback.
 - Merge branch 'master' into 8264148
 - Merge branch 'master' into 8264148
 - 8264148: Update spec for exceptions retrofitted for exception chaining

Changes: https://git.openjdk.java.net/jdk/pull/3182/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3182&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264148
  Stats: 84 lines in 22 files changed: 8 ins; 44 del; 32 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3182.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3182/head:pull/3182

PR: https://git.openjdk.java.net/jdk/pull/3182

From darcy at openjdk.java.net  Mon Mar 29 21:21:03 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 29 Mar 2021 21:21:03 GMT
Subject: RFR: 8264148: Update spec for exceptions retrofitted for
 exception chaining
In-Reply-To: <6OMPZyYBcENA0hYJp2fEMiwyhvAIT7cXwPoMVQ0TIUc=.65348cfa-1afe-4a3d-8d18-002f2be28d7d@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
 <6OMPZyYBcENA0hYJp2fEMiwyhvAIT7cXwPoMVQ0TIUc=.65348cfa-1afe-4a3d-8d18-002f2be28d7d@github.com>
Message-ID: <YGY3e5JZUid7DXjezumgNg-peG8xsYydHM1F_ZVbZ7o=.f2c5de76-0340-43aa-9698-dec84018dc6a@github.com>

On Thu, 25 Mar 2021 18:52:54 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> 8264148: Update spec for exceptions retrofitted for exception chaining
>
> The removal of the obsolescent "As of release 1.4, this exception has been retrofitted..." is good. Changing the calls from the other exception-getting methods to `getCause()` is also good. I'm less sure of the utility of deprecating these older methods. The deprecation will issue warning messages; is there any benefit to the calling code to migrating from the older methods to `getCause()`? If they're exactly equivalent, then I think the benefits are small, compared to the cost of dealing with warnings. Thus for most of these cases I think that not deprecating the older methods is reasonable, and perhaps the explanation should be converted to an `@apiNote`.
> 
> (The considerations for the JDK itself are different, though, which is why I support changing the call sites.)
> 
> One special case is the **public field** in `WriteAbortedException`. This is really bad and something ought to be done about this, including deprecation, and maybe more. This implies that the exception is mutable, right? Hrrmph. Isn't there a general rule that once the cause has been set (either via a constructor or via initCause) the exception is immutable? Maybe the field should be deprecated, and `getCause()` should return the cause from the superclass. That's a behavior change of course, and I don't know how to assess the compatibility impact. But the current situation just seems wrong.

Some discussion of the proposed changes here. While the history with respect to the introduction of the chained exception mechanism may have been relevant in times past, those comments have little utility today. Per guidance from Dr. Deprecator, I've removed deprecation of the redundant methods and only kept deprecation of the mutable field in WriteAbortedException.

The legacy wrapped exception accessing methods in ClassNotFoundException, ExceptionInInitializerError, and UndeclaredThrowableException are equivalent to getCause. The legacy method in PrivilegedActionException returns the same value, but narrowed to Exception rather than Throwable.

Once the rest of the change is agree to, I'll update copyrights and do a CSR for the deprecation and other spec changes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3182

From iklam at openjdk.java.net  Mon Mar 29 21:47:02 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 29 Mar 2021 21:47:02 GMT
Subject: RFR: 8264285: Clean the modification of ccstr JVM flags
Message-ID: <zbVfsuLhNzhIneQusCRIO86lU9dRUOuUWMsiR9_TDas=.9c136bfd-81f1-4168-986c-43721178444e@github.com>

There are two versions of JVMFlagAccess::ccstrAtPut() for modifying JVM flags of the ccstr type (i.e., strings).

- One version requires the caller to free the old value, but some callers don't do that (writeableFlags.cpp).
- The other version frees the old value on behalf of the caller. However, this version is accessible only via FLAG_SET_XXX macros and is currently unused. So it's unclear whether it actually works.

We should combine these two versions into a single function, fix problems in the callers, and add test cases. The old value should be freed automatically, because typically the caller isn't interested in the old value.

Note that the FLAG_SET_XXX macros do not return the old value. Requiring the caller of FLAG_SET_XXX to free the old value would be tedious and error prone.

-------------

Commit messages:
 - restored SET_FLAG_XXX for ccstr type, and fixed bugs in existing ccstr modification code
 - 8264285: Do not support FLAG_SET_XXX for VM flags of string type

Changes: https://git.openjdk.java.net/jdk/pull/3254/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3254&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264285
  Stats: 205 lines in 9 files changed: 160 ins; 24 del; 21 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3254.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3254/head:pull/3254

PR: https://git.openjdk.java.net/jdk/pull/3254

From dfuchs at openjdk.java.net  Mon Mar 29 22:15:47 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 29 Mar 2021 22:15:47 GMT
Subject: RFR: 8264124: Update MXBean specification and implementation to
 extend mapping of CompositeType to records [v2]
In-Reply-To: <0RxhjEDdg8ZZRNLjbknHs_sa71hn6ax3LAtv_-pZGqY=.a3e1631a-4280-4b2e-95c0-794785b9d165@github.com>
References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com>
 <cAwbOBwhGERyBUbreMVPVsCabpDTPi3oqSDQ53FTVlk=.70a98535-36bb-4483-b461-5de840998d06@github.com>
 <C0e13BnsgJfRQvS86QICp_CwhR4PIaC498P5FnjazjE=.4e8467e1-8b8b-4899-bf22-470328d31007@github.com>
 <0RxhjEDdg8ZZRNLjbknHs_sa71hn6ax3LAtv_-pZGqY=.a3e1631a-4280-4b2e-95c0-794785b9d165@github.com>
Message-ID: <UvPmdS6Nn0PhWonjYS_YTnhwc8SXhElST7Y3f844WNM=.d1c7e494-97c8-44ad-ac2b-469121ef54f9@github.com>

On Sat, 27 Mar 2021 01:49:38 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> src/java.management/share/classes/javax/management/MXBean.java line 757:
>> 
>>> 755: 
>>> 756:     <p>If the class is a {@link Record}, its getters are the
>>> 757:       accessors for the record components. Otherwise, the
>> 
>> It may be good to add a link like {@linkplain RecordComponent record components}
>
> You add record in "Mappings for other types".  I think it deserves a separate section "Mappings for record classes" (maybe after primitive types).   It's useful to add a row for record in the summary table above "Mappings for primitive types"

Link added. With respect to adding a section for records, it's a bit difficult to separate that from the "Mapping for other types" without a lot of duplication. I can add a row in the summary table, and then add a new section "Mapping for records" just before "Mapping for other types", that just gives a brief overview and refers to the mapping for other types below. 

Something like this - what do you think?

    <h3 id="records">Mappings for Records</h3>

    <p>A {@linkplain Record record} <em>R</em> whose {@linkplain
      Class#getRecordComponents() components} are
      all convertible to open types, is itself convertible to a
      {@link CompositeType} as follows.
      The type name of this {@code CompositeType}
      is determined by the same <a href="#type-names">type name rules</a>
      defined by the <a href="#composite-map">Mapping for other types</a>
      below. Its getters are the accessors for the {@linkplain
      RecordComponent record components}, and the record is reconstructed
      using its canonical constructor, without needing any annotation.</p>

    <p>A record may also expose additional non-canonical constructors, which
      can be used to reconstruct the record if the composite data does
      not exactly contain all the components expected by the
      canonical constructor. However, in order to be taken into account
      by the MXBean framework, such non-canonical constructors
      need to be annotated with either the {@link ConstructorParameters
      &#64;javax.management.ConstructorParameters} or
     {@code @java.beans.ConstructorProperties} annotation.</p>

    <p>The complete rules for the mapping are detailed as part
      of the <a href="#composite-map">Mapping for other types</a>
      below.</p>

    <h3 id="composite-map">Mappings for other types</h3>

    <p>Given a record, or a Java class or interface <em>J</em> that does not match the other
      rules in the table above, the MXBean framework will attempt to map
      it to a {@link CompositeType} as follows.  [....]

-------------

PR: https://git.openjdk.java.net/jdk/pull/3201

From coleenp at openjdk.java.net  Mon Mar 29 23:10:42 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 29 Mar 2021 23:10:42 GMT
Subject: RFR: 8264193: Remove TRAPS parameters for modules and
 defaultmethods
In-Reply-To: <6WUbVyj36re-dOR20BOerxSJckUtyoHjwo6z9r1g-as=.fddf28f1-8cdd-4954-b734-65b36f5b8de4@github.com>
References: <6WUbVyj36re-dOR20BOerxSJckUtyoHjwo6z9r1g-as=.fddf28f1-8cdd-4954-b734-65b36f5b8de4@github.com>
Message-ID: <zwAt-H0cLSVvcRNjz56KmCldy4x-PrMDeiwtkQI4XZg=.51ddf502-12c9-4a3c-b784-8d6b159c210d@github.com>

On Mon, 29 Mar 2021 17:40:09 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this change for JDK-8264193 to remove unneeded TRAPS parameters from modules and default methods files.  Besides removing TRAPS, Modules::get_named_module() was changed to return an oop instead of a jobject, removing its need for a TRAPS parameter.
> 
> This change was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.
> 
> Thanks, Harold

Looks good!!

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3247

From dholmes at openjdk.java.net  Tue Mar 30 01:42:46 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 30 Mar 2021 01:42:46 GMT
Subject: RFR: 8264193: Remove TRAPS parameters for modules and
 defaultmethods
In-Reply-To: <6WUbVyj36re-dOR20BOerxSJckUtyoHjwo6z9r1g-as=.fddf28f1-8cdd-4954-b734-65b36f5b8de4@github.com>
References: <6WUbVyj36re-dOR20BOerxSJckUtyoHjwo6z9r1g-as=.fddf28f1-8cdd-4954-b734-65b36f5b8de4@github.com>
Message-ID: <CiN5zxtdvQIH9rFzmfhkpRklkKWbisqyDEHa7DXDmEI=.bfc9a1ff-3afe-40a4-81a4-655256d03d84@github.com>

On Mon, 29 Mar 2021 17:40:09 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this change for JDK-8264193 to remove unneeded TRAPS parameters from modules and default methods files.  Besides removing TRAPS, Modules::get_named_module() was changed to return an oop instead of a jobject, removing its need for a TRAPS parameter.
> 
> This change was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.
> 
> Thanks, Harold

Great cleanup Harold!

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3247

From minqi at openjdk.java.net  Tue Mar 30 03:48:08 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 30 Mar 2021 03:48:08 GMT
Subject: RFR: 8259070: Add jcmd option to dump CDS [v7]
In-Reply-To: <hwrc1zAz8G180ToL-C3EuUIF-5R17F5Gm1zcPMBpOtE=.e002a377-e0e2-485b-a08e-b63675a9746b@github.com>
References: <hwrc1zAz8G180ToL-C3EuUIF-5R17F5Gm1zcPMBpOtE=.e002a377-e0e2-485b-a08e-b63675a9746b@github.com>
Message-ID: <ZOFUPmirnvl49Qk6vc7CzrRfuE882WDhxkOQR8d3H_Y=.ab2eb8ee-e3a0-46bc-8517-ca06073f81cd@github.com>

> Hi, Please review
> 
>   Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with
>   `java -XX:DumpLoadedClassList=<classlist> .... `  
>  to collect shareable class names and saved in file `<classlist>` , then 
>   `java -Xshare:dump -XX:SharedClassListFile=<classlist> -XX:SharedArchiveFile=<archivefile> ...`
>   With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime  to dump an archive.
>    The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved.
>    New added jcmd option:
>    `jcmd <pid or AppName> VM.cds static_dump <filename>`
>    or
>     `jcmd <pid or AppName> VM.cds dynamic_dump <filename>`
>   To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. 
>    The file name is optional, if the file name is not supplied, the file name will take format of `java_pid<number>_static.jsa` or `java_pid<number>_dynamic.jsa` for static and dynamic respectively. The `<number>` is the application process ID.
> 
>   Tests: tier1,tier2,tier3,tier4
> 
> Thanks
> Yumin

Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:

  Remove CDS.getVMArguments, changed to use VM.getRuntimeVMArguments. Removed unused function from ClassLoader. Improved InstanceKlass::is_shareable() and related test. Added more test scenarios.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2737/files
  - new: https://git.openjdk.java.net/jdk/pull/2737/files/3834f042..cef6328f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2737&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2737&range=05-06

  Stats: 236 lines in 12 files changed: 89 ins; 69 del; 78 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2737.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2737/head:pull/2737

PR: https://git.openjdk.java.net/jdk/pull/2737

From dholmes at openjdk.java.net  Tue Mar 30 03:51:43 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 30 Mar 2021 03:51:43 GMT
Subject: RFR: 8264285: Clean the modification of ccstr JVM flags
In-Reply-To: <zbVfsuLhNzhIneQusCRIO86lU9dRUOuUWMsiR9_TDas=.9c136bfd-81f1-4168-986c-43721178444e@github.com>
References: <zbVfsuLhNzhIneQusCRIO86lU9dRUOuUWMsiR9_TDas=.9c136bfd-81f1-4168-986c-43721178444e@github.com>
Message-ID: <71SWS17lpVrTS_4--6mimeyjCYjYzP_VO_lJ-rImnxg=.a75340ae-d17e-4f0d-8868-21d4449d64f6@github.com>

On Mon, 29 Mar 2021 21:35:52 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> There are two versions of JVMFlagAccess::ccstrAtPut() for modifying JVM flags of the ccstr type (i.e., strings).
> 
> - One version requires the caller to free the old value, but some callers don't do that (writeableFlags.cpp).
> - The other version frees the old value on behalf of the caller. However, this version is accessible only via FLAG_SET_XXX macros and is currently unused. So it's unclear whether it actually works.
> 
> We should combine these two versions into a single function, fix problems in the callers, and add test cases. The old value should be freed automatically, because typically the caller isn't interested in the old value.
> 
> Note that the FLAG_SET_XXX macros do not return the old value. Requiring the caller of FLAG_SET_XXX to free the old value would be tedious and error prone.

Hi Ioi,

This looks good to me. Thanks for fixing it up.

One minor nit below.

Thanks,
David

src/hotspot/share/services/writeableFlags.cpp line 250:

> 248:   if (err == JVMFlag::SUCCESS) {
> 249:     assert(value == NULL, "old value is freed automatically and not returned");
> 250:   }

The whole block should be ifdef DEBUG.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3254

From cjplummer at openjdk.java.net  Tue Mar 30 03:59:40 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 30 Mar 2021 03:59:40 GMT
Subject: RFR: 8263854: Use the blessed modifier in jdk.internal.jvmstat
In-Reply-To: <rrSdxlrv3z-oVhRNkDd5XTcgCl3MfGMh2pUxHl2uCTc=.5790a3c6-9b78-4e96-bb45-bace638ebae8@github.com>
References: <rrSdxlrv3z-oVhRNkDd5XTcgCl3MfGMh2pUxHl2uCTc=.5790a3c6-9b78-4e96-bb45-bace638ebae8@github.com>
Message-ID: <j2AwhiEAspUUfINVMP_TB9QZiTuDvM2anlzVDY3XAyM=.cb38139f-cfeb-4a05-9c59-2b1deb14a296@github.com>

On Mon, 29 Mar 2021 21:00:20 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> 8263854: Use the blessed modifier in jdk.internal.jvmstat

The changes look fine, but you need to fix the CR number. It should be JDK-8264396. Also copyrights need updating.

-------------

Changes requested by cjplummer (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3252

From github.com+28367473+jmehrens at openjdk.java.net  Tue Mar 30 04:01:57 2021
From: github.com+28367473+jmehrens at openjdk.java.net (jmehrens)
Date: Tue, 30 Mar 2021 04:01:57 GMT
Subject: RFR: 8264148: Update spec for exceptions retrofitted for
 exception chaining
In-Reply-To: <6OMPZyYBcENA0hYJp2fEMiwyhvAIT7cXwPoMVQ0TIUc=.65348cfa-1afe-4a3d-8d18-002f2be28d7d@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
 <6OMPZyYBcENA0hYJp2fEMiwyhvAIT7cXwPoMVQ0TIUc=.65348cfa-1afe-4a3d-8d18-002f2be28d7d@github.com>
Message-ID: <dGNio-0tGjN8jEVGIMK8y212esY7r1g9L8CjyJYbcDE=.a43a1fd2-9dba-4971-96c1-d84a716f746a@github.com>

On Thu, 25 Mar 2021 18:52:54 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> One special case is the **public field** in `WriteAbortedException`. This is really bad and something ought to be done about this, including deprecation, and maybe more. This implies that the exception is mutable, right? Hrrmph. Isn't there a general rule that once the cause has been set (either via a constructor or via initCause) the exception is immutable? Maybe the field should be deprecated, and `getCause()` should return the cause from the superclass. That's a behavior change of course, and I don't know how to assess the compatibility impact. But the current situation just seems wrong.


Agreed. WriteAbortedException should get similar treatment as the others like it:

- http://cr.openjdk.java.net/~dmeetry/8009581/webrev.5/
- http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/016908.html
- http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017594.html
- https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-February/051341.html

The only twist is that we would have to keep the public field as deprecated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3182

From kevinw at openjdk.java.net  Tue Mar 30 09:52:42 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Tue, 30 Mar 2021 09:52:42 GMT
Subject: RFR: 8263854: Use the blessed modifier in jdk.internal.jvmstat
In-Reply-To: <rrSdxlrv3z-oVhRNkDd5XTcgCl3MfGMh2pUxHl2uCTc=.5790a3c6-9b78-4e96-bb45-bace638ebae8@github.com>
References: <rrSdxlrv3z-oVhRNkDd5XTcgCl3MfGMh2pUxHl2uCTc=.5790a3c6-9b78-4e96-bb45-bace638ebae8@github.com>
Message-ID: <-FX4hSx4557kmJ30LCop4HbCfG55KC9yWPG5PhSO3CA=.d48230a9-ddc6-4f21-aa96-be53a8ac0238@github.com>

On Mon, 29 Mar 2021 21:00:20 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> 8263854: Use the blessed modifier in jdk.internal.jvmstat

Agreed, change looks good.

-------------

Marked as reviewed by kevinw (Committer).

PR: https://git.openjdk.java.net/jdk/pull/3252

From hseigel at openjdk.java.net  Tue Mar 30 12:16:31 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 30 Mar 2021 12:16:31 GMT
Subject: RFR: 8264193: Remove TRAPS parameters for modules and
 defaultmethods
In-Reply-To: <CiN5zxtdvQIH9rFzmfhkpRklkKWbisqyDEHa7DXDmEI=.bfc9a1ff-3afe-40a4-81a4-655256d03d84@github.com>
References: <6WUbVyj36re-dOR20BOerxSJckUtyoHjwo6z9r1g-as=.fddf28f1-8cdd-4954-b734-65b36f5b8de4@github.com>
 <CiN5zxtdvQIH9rFzmfhkpRklkKWbisqyDEHa7DXDmEI=.bfc9a1ff-3afe-40a4-81a4-655256d03d84@github.com>
Message-ID: <3SIedhLpUax0_zUv_0UU6Qokqi8YiatPxwgCvGKbJYM=.c89d8306-e980-4268-a51c-54e76b1bc16d@github.com>

On Tue, 30 Mar 2021 01:40:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this change for JDK-8264193 to remove unneeded TRAPS parameters from modules and default methods files.  Besides removing TRAPS, Modules::get_named_module() was changed to return an oop instead of a jobject, removing its need for a TRAPS parameter.
>> 
>> This change was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.
>> 
>> Thanks, Harold
>
> Great cleanup Harold!
> 
> Thanks,
> David

Thanks Lois, Calvin, Coleen, and David for the reviews!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3247

From hshi at openjdk.java.net  Tue Mar 30 12:16:59 2021
From: hshi at openjdk.java.net (Hui Shi)
Date: Tue, 30 Mar 2021 12:16:59 GMT
Subject: RFR: 8264411: serviceability/jvmti/HeapMonitor tests intermittently
 fail due to large TLAB size
Message-ID: <aR6ewOCBxOa4jyVfichHlksI_yapG-uQ32uAlBQ48WI=.7e0dfa14-e1bf-459b-8e0c-38133b330020@github.com>

?ue to large TLAB size

serviceability/jvmti/HeapMonitor tests intermittently fail when using PS/Serial GC, original test has implicit assumptions on TLAB size and depends on allocate fix amount of objects to consume TLAB and trigger object sampling. These tests will fail if TLAB is above 20M (this can easily happen when using PS/Serial GC and heap is large), when allocation can not consume current TLAB and _byte_until_sample.

Fix in tests is adding an explicit GC to consume current TLAB.
Running on 256G memory machine, make run-test CONF=release TEST="test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/" 'JTREG=JOBS=12;VM_OPTIONS=-XX:ActiveProcessorCount=1'

before fix: 6 or 7 tests in 20 tests intermittently fail
after fix: no failure in 100 runs release/fastdebug

This might also fix https://bugs.openjdk.java.net/browse/JDK-8225313

-------------

Commit messages:
 - 8264411: serviceability/jvmti/HeapMonitor tests intermittently fail due to large TLAB size

Changes: https://git.openjdk.java.net/jdk/pull/3265/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3265&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264411
  Stats: 22 lines in 2 files changed: 17 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3265.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3265/head:pull/3265

PR: https://git.openjdk.java.net/jdk/pull/3265

From hseigel at openjdk.java.net  Tue Mar 30 12:23:23 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 30 Mar 2021 12:23:23 GMT
Subject: Integrated: 8264193: Remove TRAPS parameters for modules and
 defaultmethods
In-Reply-To: <6WUbVyj36re-dOR20BOerxSJckUtyoHjwo6z9r1g-as=.fddf28f1-8cdd-4954-b734-65b36f5b8de4@github.com>
References: <6WUbVyj36re-dOR20BOerxSJckUtyoHjwo6z9r1g-as=.fddf28f1-8cdd-4954-b734-65b36f5b8de4@github.com>
Message-ID: <oKY8Caq0a9en2gSf20IYnA4dahoq_4lvVZtIElnQ8m4=.b48de117-8e86-4c40-a1b9-4daf68f240f4@github.com>

On Mon, 29 Mar 2021 17:40:09 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this change for JDK-8264193 to remove unneeded TRAPS parameters from modules and default methods files.  Besides removing TRAPS, Modules::get_named_module() was changed to return an oop instead of a jobject, removing its need for a TRAPS parameter.
> 
> This change was tested with Mach5 tiers 1 and 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: 6e74c3ab
Author:    Harold Seigel <hseigel at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6e74c3ab
Stats:     61 lines in 8 files changed: 1 ins; 13 del; 47 mod

8264193: Remove TRAPS parameters for modules and defaultmethods

Reviewed-by: lfoltan, ccheung, coleenp, dholmes

-------------

PR: https://git.openjdk.java.net/jdk/pull/3247

From rriggs at openjdk.java.net  Tue Mar 30 13:29:23 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 30 Mar 2021 13:29:23 GMT
Subject: RFR: 8264148: Update spec for exceptions retrofitted for
 exception chaining
In-Reply-To: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
Message-ID: <-rMQxHXFk7yEM-DmoZOmE9eePkkvaklW5YyWhsJEek4=.8456ad76-b965-4098-a66b-1e80f396cf7c@github.com>

On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8264148: Update spec for exceptions retrofitted for exception chaining

I agree that the public field in WriteAbortedException could be remediated.
But it is also mostly harmless.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VMObjectFactory.java line 62:

> 60:     catch (java.lang.reflect.InvocationTargetException ite) {
> 61:         if (ite.getCause() instanceof RuntimeException) {
> 62:             throw (RuntimeException)ite.getCause();

This might be a place to use the new instanceof pattern form:
`if (ite.getCause() instanceof RuntimeException rex)
        throw rex.getCause();
`

src/jdk.jconsole/share/classes/sun/tools/jconsole/inspector/Utils.java line 293:

> 291:             Throwable t = e.getCause();
> 292:             if (t instanceof Exception) {
> 293:                 throw (Exception) t;

Ditto:
 ` if (t instanceof Exception ex) throw ex`

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3182

From github.com+28367473+jmehrens at openjdk.java.net  Tue Mar 30 13:43:22 2021
From: github.com+28367473+jmehrens at openjdk.java.net (jmehrens)
Date: Tue, 30 Mar 2021 13:43:22 GMT
Subject: RFR: 8264148: Update spec for exceptions retrofitted for
 exception chaining
In-Reply-To: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
Message-ID: <k1pS0P2Zl6vFFpNo2Fq30IZYZjel2QSHPDAqPZFlFik=.c94d3533-7b16-42ec-b803-d4725851de35@github.com>

On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8264148: Update spec for exceptions retrofitted for exception chaining

src/java.base/share/classes/java/io/WriteAbortedException.java line 86:

> 84:     @Override
> 85:     public Throwable getCause() {
> 86:         return detail;

Use SuppressWarnings??

-------------

PR: https://git.openjdk.java.net/jdk/pull/3182

From joe.darcy at oracle.com  Tue Mar 30 15:55:20 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 30 Mar 2021 08:55:20 -0700
Subject: RFR: 8264148: Update spec for exceptions retrofitted for
 exception chaining
In-Reply-To: <k1pS0P2Zl6vFFpNo2Fq30IZYZjel2QSHPDAqPZFlFik=.c94d3533-7b16-42ec-b803-d4725851de35@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
 <k1pS0P2Zl6vFFpNo2Fq30IZYZjel2QSHPDAqPZFlFik=.c94d3533-7b16-42ec-b803-d4725851de35@github.com>
Message-ID: <76cee601-67a3-adbd-ea45-ded1f2dc592e@oracle.com>


On 3/30/2021 6:43 AM, jmehrens wrote:
> On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:
>
>> 8264148: Update spec for exceptions retrofitted for exception chaining
> src/java.base/share/classes/java/io/WriteAbortedException.java line 86:
>
>> 84:     @Override
>> 85:     public Throwable getCause() {
>> 86:         return detail;
> Use SuppressWarnings??


There is no warning to suppress since the detail field is defined in the 
same class.

-Joe


From joe.darcy at oracle.com  Tue Mar 30 16:00:50 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 30 Mar 2021 09:00:50 -0700
Subject: RFR: 8264148: Update spec for exceptions retrofitted for
 exception chaining
In-Reply-To: <-rMQxHXFk7yEM-DmoZOmE9eePkkvaklW5YyWhsJEek4=.8456ad76-b965-4098-a66b-1e80f396cf7c@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
 <-rMQxHXFk7yEM-DmoZOmE9eePkkvaklW5YyWhsJEek4=.8456ad76-b965-4098-a66b-1e80f396cf7c@github.com>
Message-ID: <0627b7e4-6db3-50bc-fba5-35877647d038@oracle.com>


On 3/30/2021 6:29 AM, Roger Riggs wrote:
> On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:
>
>> 8264148: Update spec for exceptions retrofitted for exception chaining
> I agree that the public field in WriteAbortedException could be remediated.
> But it is also mostly harmless.
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VMObjectFactory.java line 62:
>
>> 60:     catch (java.lang.reflect.InvocationTargetException ite) {
>> 61:         if (ite.getCause() instanceof RuntimeException) {
>> 62:             throw (RuntimeException)ite.getCause();
> This might be a place to use the new instanceof pattern form:
> `if (ite.getCause() instanceof RuntimeException rex)
>          throw rex.getCause();
> `
>
> src/jdk.jconsole/share/classes/sun/tools/jconsole/inspector/Utils.java line 293:
>
>> 291:             Throwable t = e.getCause();
>> 292:             if (t instanceof Exception) {
>> 293:                 throw (Exception) t;
> Ditto:
>   ` if (t instanceof Exception ex) throw ex`
>

I think the use of the new instanceof form would be better left for a 
follow-up refactoring.

Thanks,

-Joe


From smarks at openjdk.java.net  Tue Mar 30 17:06:32 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 30 Mar 2021 17:06:32 GMT
Subject: RFR: 8264148: Update spec for exceptions retrofitted for
 exception chaining
In-Reply-To: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
Message-ID: <XaOfh6DMc2x_a0qsP15eZNL4BNIlr5sZdA5in2dfBVo=.ae0724db-ccc6-4f84-ab43-d698b3042113@github.com>

On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8264148: Update spec for exceptions retrofitted for exception chaining

Marked as reviewed by smarks (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3182

From cjplummer at openjdk.java.net  Tue Mar 30 17:16:11 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 30 Mar 2021 17:16:11 GMT
Subject: RFR: 8264311: Heap object statistics
In-Reply-To: <elD7YoD5xbRC9TqkFWH6_kVcnsowTKjGs_YgdSLMVck=.80d78d4f-4fe0-4c76-8255-90abb8034c4d@github.com>
References: <elD7YoD5xbRC9TqkFWH6_kVcnsowTKjGs_YgdSLMVck=.80d78d4f-4fe0-4c76-8255-90abb8034c4d@github.com>
Message-ID: <Arkh-UYMyS0A6DUzpB73qPk0_5c1wCfRu3X294EC15s=.28e7d41b-943e-48f6-bfc5-99551de5715e@github.com>

On Tue, 30 Mar 2021 15:04:57 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> For Lilliput evaluation, it would be useful to be able to get some statistics about heap objects, e.g. how many objects there typically are, what is their (average) size, how big is the live data set, how many objecs have an identity hash code and how many objects are locked. Some of that information may be useful for general purpose too, e.g. the avg live data set and object size/count information might be quite useful to have.
> Testing:
>  - [x] Some manual tests, verifying the plausability of the output by hand
>  - [ ] tier1
>  - [ ] tier2

You'll need a CSR for this enhancement.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3271

From sspitsyn at openjdk.java.net  Tue Mar 30 17:16:33 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 30 Mar 2021 17:16:33 GMT
Subject: RFR: 8264028: Typo in
 javax.management.relation.RelationService::purgeRelations
In-Reply-To: <9LcMa_awvTUUQUrc8y_D3kQl2wFTraWLYfK_prqwsvI=.9a10ef23-f23d-4e1d-8833-c25af1067deb@github.com>
References: <9LcMa_awvTUUQUrc8y_D3kQl2wFTraWLYfK_prqwsvI=.9a10ef23-f23d-4e1d-8833-c25af1067deb@github.com>
Message-ID: <NukBpr8xswEk3vWW09_FhiOLZS_4VIQWMmth98lkeDw=.812c587c-908f-49f8-a091-6da077ae009c@github.com>

On Sun, 28 Feb 2021 10:48:55 GMT, ?? <github.com+22524871+horizonzy at openjdk.org> wrote:

> 8264028: Typo in javax.management.relation.RelationService::purgeRelations

Looks good.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2765

From dcubed at openjdk.java.net  Tue Mar 30 17:19:18 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 30 Mar 2021 17:19:18 GMT
Subject: RFR: 8257831: Suspend with handshakes [v2]
In-Reply-To: <a6Fjizolorcan3_uaH8QqfAmw6LqdOwC02DG2Yp6ZNg=.d8ebe170-cdda-42d7-912c-0210f9643da6@github.com>
References: <xv1j0DkGolookgzzyT7w9hz5-mlD0QaeHfqL3b9HJ6I=.c33a0757-1f6e-4a7c-afa4-2d531849d4fc@github.com>
 <a6Fjizolorcan3_uaH8QqfAmw6LqdOwC02DG2Yp6ZNg=.d8ebe170-cdda-42d7-912c-0210f9643da6@github.com>
Message-ID: <lfoWy9GAZC-tp75AqoATcaOOwWhHfoQjHZ236wmhL64=.628619cf-5e45-475b-958e-70dccef9bcb6@github.com>

On Fri, 26 Mar 2021 13:21:43 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request.
>> 
>> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread).
>> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. 
>> 
>> Suspend:
>> Requesting thread -> synchronous handshake -> target thread
>> Inside synchronus handshake (HandshakeState lock is locked while
>> executing any handshake):
>> 	- Set suspended flag
>> 	- Install asynchronous handshake
>> 
>> Target thread -> tries to leave dormant state -> Executes handshakes
>> Target only executes asynchronous handshake:
>> 	- While suspended
>> 	- Go to blocked
>> 	- Wait on HandshakeState lock
>> 
>> Resume:
>> Resuming thread:
>> 	- Lock HandshakeState lock
>> 	- Clear suspended flag
>> 	- Notify HandshakeState lock
>> 	- Unlock HandshakeState lock
>> 
>> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set.
>> 
>> ----
>> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors.
>> 
>> ----
>> Regarding the changed test, the documentation says:
>> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it."
>> 
>> But the code:
>>   LOG("suspendTestedThreads: before JVMTI SuspendThreadList");
>>   err = jvmti->SuspendThreadList(threads_count, threads, results);
>>   ...
>>   // Allow the Main thread to inspect the result of tested threads suspension	
>>   agent_unlock(jni);
>>   
>> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock().
>> Thus main thread is stuck forever on:
>>   // Block until the suspender thread competes the tested threads suspension	
>>   agent_lock(jni);
>> 
>> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state.
>> 
>> ----
>> 
>> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp.
>> (Pre-review comments here:
>> https://github.com/openjdk/jdk/pull/2625)
>> 
>> ---- 
>> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and
>> combinations like running with -XX:ZCollectionInterval=0.01 -
>> XX:ZFragmentationLimit=0.
>> Running above some of above concurrently (load ~240), slow debug,
>> etc...
>
> Robbin Ehn 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 SuspendInHandshake
>  - 8257831: Suspend with handshake (review baseline)

This is an elegant evolution of the suspend/resume mechanism.

It is so nice to see all the suspend-equivalent stuff go away!

src/hotspot/os/posix/signals_posix.cpp line 1587:

> 1585:   // destructor has completed.
> 1586: 
> 1587:   if (thread->is_Java_thread() && thread->as_Java_thread()->is_terminated()) {

We need @dholmes-ora to verify that this version of the code will
still solve the bug he was fixing when he added old L1610.

src/hotspot/share/runtime/handshake.hpp line 37:

> 35: class JavaThread;
> 36: class ThreadSuspensionHandshake;
> 37: class SuspendThreadHandshake;

Should these be in alpha sort order?

src/hotspot/share/runtime/handshake.hpp line 147:

> 145:   bool handshake_suspend();
> 146:   // Called from the async handshake (the trap)
> 147:   // to stop a thread from continuing executing when suspended.

nit typo: s/continuing executing/continuing execution/

src/hotspot/share/runtime/objectMonitor.cpp line 422:

> 420:         _recursions = 0;
> 421:         _succ = NULL;
> 422:         exit(false, current);

You'll have a conflict with @pchilano recent fix.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3191

From rkennke at openjdk.java.net  Tue Mar 30 17:41:17 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 30 Mar 2021 17:41:17 GMT
Subject: RFR: 8264311: Heap object statistics
In-Reply-To: <Arkh-UYMyS0A6DUzpB73qPk0_5c1wCfRu3X294EC15s=.28e7d41b-943e-48f6-bfc5-99551de5715e@github.com>
References: <elD7YoD5xbRC9TqkFWH6_kVcnsowTKjGs_YgdSLMVck=.80d78d4f-4fe0-4c76-8255-90abb8034c4d@github.com>
 <Arkh-UYMyS0A6DUzpB73qPk0_5c1wCfRu3X294EC15s=.28e7d41b-943e-48f6-bfc5-99551de5715e@github.com>
Message-ID: <kxrIz9odOHuC-gVl3i8VQsjvIQPkdPkE572BQuCQVx4=.8ff729c1-9f90-4cb0-a877-4731a023b41e@github.com>

On Tue, 30 Mar 2021 17:12:52 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> You'll need a CSR for this enhancement.

Hmm, yeah.
I'm wondering if this should rather go into the Lilliput repository once it is created (I'd expect in ~1week or so). Then it would be refined during Lilliput project live time, and eventually merged upstream (and CSR'ed) when all is ready.

I only wanted to get this out ASAP so that people can tinker with it, and do their own measurements.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3271

From dcubed at openjdk.java.net  Tue Mar 30 19:37:31 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 30 Mar 2021 19:37:31 GMT
Subject: RFR: 8262881: port JVM/DI tests from JDK-4413752 to JVM/TI [v3]
In-Reply-To: <XOECrKnBcmSRjfY2cM-GqFs3jMr0fTy7KJUCUHZ0HGw=.54872a68-97e9-481a-871e-eade80a51604@github.com>
References: <XOECrKnBcmSRjfY2cM-GqFs3jMr0fTy7KJUCUHZ0HGw=.54872a68-97e9-481a-871e-eade80a51604@github.com>
Message-ID: <dCyHeiVU2olZMqNk0D_Fyey84BcZLk7PJPHg4XdsM-g=.22bfcc79-f170-49ee-883b-76c3ffc5acb8@github.com>

> Add three tests from JDK-4413752 ported to JVM/TI:
> 
> - RawMonitorEnter() with SuspendThread()
>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithRawMonitorEnter/SuspendWithRawMonitorEnter.java
>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithRawMonitorEnter/libSuspendWithRawMonitorEnter.cpp
> 
> - ObjectMonitor enter() with SuspendThread()
>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorEnter/SuspendWithObjectMonitorEnter.java
>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorEnter/libSuspendWithObjectMonitorEnter.cpp
> 
> - ObjectMonitor wait() with SuspendThread
>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java
>   - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/libSuspendWithObjectMonitorWait.cpp
> 
> The Java files have a transaction diagram to show what each of the
> threads in the test is doing.

Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge branch 'master' into JDK-8262881
 - sspitsyn - fix white space indents problems.
 - 8262881: port JVM/DI tests from JDK-4413752 to JVM/TI

-------------

Changes: https://git.openjdk.java.net/jdk/pull/2899/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2899&range=02
  Stats: 1599 lines in 6 files changed: 1599 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2899.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2899/head:pull/2899

PR: https://git.openjdk.java.net/jdk/pull/2899

From darcy at openjdk.java.net  Tue Mar 30 20:03:18 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 30 Mar 2021 20:03:18 GMT
Subject: Integrated: 8264148: Update spec for exceptions retrofitted for
 exception chaining
In-Reply-To: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
Message-ID: <DLYKwabnY95L4xZ2RniMmrgFe7bbxZx5oq6uzIP-wvE=.8605c32a-3628-444e-bc16-8546bfaa87c1@github.com>

On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8264148: Update spec for exceptions retrofitted for exception chaining

This pull request has now been integrated.

Changeset: 815248ab
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/815248ab
Stats:     84 lines in 22 files changed: 8 ins; 44 del; 32 mod

8264148: Update spec for exceptions retrofitted for exception chaining

Reviewed-by: rriggs, smarks

-------------

PR: https://git.openjdk.java.net/jdk/pull/3182

From cjplummer at openjdk.java.net  Tue Mar 30 20:32:16 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 30 Mar 2021 20:32:16 GMT
Subject: RFR: 8264311: Heap object statistics
In-Reply-To: <kxrIz9odOHuC-gVl3i8VQsjvIQPkdPkE572BQuCQVx4=.8ff729c1-9f90-4cb0-a877-4731a023b41e@github.com>
References: <elD7YoD5xbRC9TqkFWH6_kVcnsowTKjGs_YgdSLMVck=.80d78d4f-4fe0-4c76-8255-90abb8034c4d@github.com>
 <Arkh-UYMyS0A6DUzpB73qPk0_5c1wCfRu3X294EC15s=.28e7d41b-943e-48f6-bfc5-99551de5715e@github.com>
 <kxrIz9odOHuC-gVl3i8VQsjvIQPkdPkE572BQuCQVx4=.8ff729c1-9f90-4cb0-a877-4731a023b41e@github.com>
Message-ID: <nbFq41PKkjGH8ltO88ixZF16vc9qL-M49LlmgwUqfFc=.f5474f13-7ea8-462c-af6f-92bb6449ad47@github.com>

On Tue, 30 Mar 2021 17:38:40 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> You'll need a CSR for this enhancement.
>
>> You'll need a CSR for this enhancement.
> 
> Hmm, yeah.
> I'm wondering if this should rather go into the Lilliput repository once it is created (I'd expect in ~1week or so). Then it would be refined during Lilliput project live time, and eventually merged upstream (and CSR'ed) when all is ready.
> 
> I only wanted to get this out ASAP so that people can tinker with it, and do their own measurements.

I'm not involved in the Lilliput project, but as long as the stakeholders are ok with that approach, it's probably the way to go, especially since you seem to think the feature might still evolve some.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3271

From github.com+76791+alblue at openjdk.java.net  Tue Mar 30 20:37:45 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Tue, 30 Mar 2021 20:37:45 GMT
Subject: RFR: 8264396: Use the blessed modifier order in
 jdk.internal.jvmstat [v2]
In-Reply-To: <rrSdxlrv3z-oVhRNkDd5XTcgCl3MfGMh2pUxHl2uCTc=.5790a3c6-9b78-4e96-bb45-bace638ebae8@github.com>
References: <rrSdxlrv3z-oVhRNkDd5XTcgCl3MfGMh2pUxHl2uCTc=.5790a3c6-9b78-4e96-bb45-bace638ebae8@github.com>
Message-ID: <G-gSp_dmxlvF4yzZNu3CZ6vNtBoPCbNhKvyeLYXmxjM=.578aff42-9ba7-4719-8450-3cf75e56fe7b@github.com>

> 8264396: Use the blessed modifier order in jdk.internal.jvmstat

Alex Blewitt has updated the pull request incrementally with one additional commit since the last revision:

  Updated copyright dates

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3252/files
  - new: https://git.openjdk.java.net/jdk/pull/3252/files/0583ebcc..244dac6f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3252&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3252&range=00-01

  Stats: 5 lines in 5 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3252.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3252/head:pull/3252

PR: https://git.openjdk.java.net/jdk/pull/3252

From rrich at openjdk.java.net  Tue Mar 30 21:16:37 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Tue, 30 Mar 2021 21:16:37 GMT
Subject: RFR: 8257831: Suspend with handshakes [v2]
In-Reply-To: <a6Fjizolorcan3_uaH8QqfAmw6LqdOwC02DG2Yp6ZNg=.d8ebe170-cdda-42d7-912c-0210f9643da6@github.com>
References: <xv1j0DkGolookgzzyT7w9hz5-mlD0QaeHfqL3b9HJ6I=.c33a0757-1f6e-4a7c-afa4-2d531849d4fc@github.com>
 <a6Fjizolorcan3_uaH8QqfAmw6LqdOwC02DG2Yp6ZNg=.d8ebe170-cdda-42d7-912c-0210f9643da6@github.com>
Message-ID: <xkbt1_7eYWyZFFtBMkAJjFucqtWs2p10Kn0fZ-GhlCc=.227f9c51-7bf8-437d-8577-dfb6bf669eea@github.com>

On Fri, 26 Mar 2021 13:21:43 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request.
>> 
>> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread).
>> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. 
>> 
>> Suspend:
>> Requesting thread -> synchronous handshake -> target thread
>> Inside synchronus handshake (HandshakeState lock is locked while
>> executing any handshake):
>> 	- Set suspended flag
>> 	- Install asynchronous handshake
>> 
>> Target thread -> tries to leave dormant state -> Executes handshakes
>> Target only executes asynchronous handshake:
>> 	- While suspended
>> 	- Go to blocked
>> 	- Wait on HandshakeState lock
>> 
>> Resume:
>> Resuming thread:
>> 	- Lock HandshakeState lock
>> 	- Clear suspended flag
>> 	- Notify HandshakeState lock
>> 	- Unlock HandshakeState lock
>> 
>> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set.
>> 
>> ----
>> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors.
>> 
>> ----
>> Regarding the changed test, the documentation says:
>> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it."
>> 
>> But the code:
>>   LOG("suspendTestedThreads: before JVMTI SuspendThreadList");
>>   err = jvmti->SuspendThreadList(threads_count, threads, results);
>>   ...
>>   // Allow the Main thread to inspect the result of tested threads suspension	
>>   agent_unlock(jni);
>>   
>> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock().
>> Thus main thread is stuck forever on:
>>   // Block until the suspender thread competes the tested threads suspension	
>>   agent_lock(jni);
>> 
>> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state.
>> 
>> ----
>> 
>> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp.
>> (Pre-review comments here:
>> https://github.com/openjdk/jdk/pull/2625)
>> 
>> ---- 
>> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and
>> combinations like running with -XX:ZCollectionInterval=0.01 -
>> XX:ZFragmentationLimit=0.
>> Running above some of above concurrently (load ~240), slow debug,
>> etc...
>
> Robbin Ehn 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 SuspendInHandshake
>  - 8257831: Suspend with handshake (review baseline)

Hi Robbin,

this is a great simplification. Excellent work! :)

Thanks, Richard.

src/hotspot/share/prims/jvmtiRawMonitor.cpp line 318:

> 316:   if (self->is_Java_thread()) {
> 317:     jt = self->as_Java_thread();
> 318:     while (true) {

>From the PR description:

> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors.

I read this section but then forgot about it. So you can skip the following comment.

Possible follow-up: It could be worth the attempt to make use of the generic state transition classes provided by interface.hpp. Directly I don't see why this wouldn't be feasible and I doubt the [old comment in JvmtiEnv::RawMonitorEnter()](https://github.com/reinrich/jdk/blob/aefc1560b51f0ce96d8f5ce396ba0d2fe08fd650/src/hotspot/share/prims/jvmtiEnv.cpp#L3208-L3214).
This would make the custom suspend logic here superfluous.
If ThreadBlockInVM was changed to take a generic callback for unlocking, then this could replace the custom logic in L360-L374.

src/hotspot/share/prims/jvmtiRawMonitor.cpp line 323:

> 321:       // Suspend request flag can only be set in handshakes.
> 322:       // By blocking handshakes, suspend request flag cannot change its value.
> 323:       if (!jt->handshake_state()->is_suspend_requested()) {

Shouldn't `jt->handshake_state()->is_suspend_requested()` be replaced with `jt->is_suspended()`? See also comment on declaration of `_suspend_requested`.

src/hotspot/share/prims/jvmtiRawMonitor.cpp line 364:

> 362:     for (;;) {
> 363:       simple_enter(jt);
> 364:       if (!SafepointMechanism::should_process(jt)) {

It seems to be likely that the condition is false in the first loop iteration and the thread has to do another iteration even if not suspended. Wouldn't it be ok to break from the loop if `!jt->is_suspended()`?
I'm asking because in ObjectMonitor::enter() L414 there is similar code and the condition there is `SafepointMechanism::should_process(current) && current->suspend_request_pending()`

src/hotspot/share/prims/jvmtiRawMonitor.cpp line 421:

> 419:     guarantee(jt->thread_state() == _thread_in_native, "invariant");
> 420:     for (;;) {
> 421:       if (!SafepointMechanism::should_process(jt)) {

Potential follow-up enhancement: there's a very similar for(;;) loop in JvmtiRawMonitor::raw_enter(). It looks as if it was possible to merge both loops into just one loop in simple_enter().

src/hotspot/share/runtime/handshake.cpp line 485:

> 483:       } else {
> 484:         // Asynchronous may block so they may not execute ~PreserveExceptionMark before safepointing
> 485:         // in outer loop.

Sorry, I don't understand the comment.

src/hotspot/share/runtime/handshake.cpp line 486:

> 484:         // Asynchronous may block so they may not execute ~PreserveExceptionMark before safepointing
> 485:         // in outer loop.
> 486:         op->do_handshake(_handshakee);

Maybe add PauseNoSafepointVerifier to document that the current thread can transition to a safe state?

src/hotspot/share/runtime/handshake.cpp line 492:

> 490:       }
> 491:     } else {
> 492:       return true;

`true` as return value means that the caller does _not_ need to check again for a safepoint, correct? Maybe this could be added as comment to the method declaration?

src/hotspot/share/runtime/handshake.cpp line 617:

> 615:     {
> 616:       MutexLocker ml(&_lock, Mutex::_no_safepoint_check_flag);
> 617:       if (!is_suspend_requested()) {

The current thread is _thread_in_vm. Can it be suspended then? For a suspend it has to be in a safe thread state which it cannot leave while suspended. So it must have reached _thread_in_vm not suspended and it cannot be suspended while in that state.

src/hotspot/share/runtime/handshake.cpp line 715:

> 713: bool HandshakeState::resume() {
> 714:   // Can't be suspended if there is no suspend request.
> 715:   if (!is_suspend_requested()) {

Shouldn't `is_suspend_requested()` be replaced with `is_suspended()`? See also comment on declaration of `_suspend_requested`.

src/hotspot/share/runtime/handshake.cpp line 720:

> 718:   MutexLocker ml(&_lock, Mutex::_no_safepoint_check_flag);
> 719:   // Can't be suspended if there is no suspend request.
> 720:   if (!is_suspend_requested()) {

Shouldn't `is_suspend_requested()` be replaced with `is_suspended()`? See also comment on declaration of `_suspend_requested`.

src/hotspot/share/runtime/handshake.hpp line 142:

> 140:  private:
> 141:   volatile bool _suspended;
> 142:   volatile bool _suspend_requested;

According to the PR description `_suspend_requested` is an optimization.

> The "suspend requested" flag is an optimization, without it a dormant thread
> could be suspended and resumed many times and each would add a new
> asynchronous handshake. Suspend requested flag means there is already an
> asynchronous suspend handshake in queue which can be re-used, only the suspend
> flag needs to be set.

I think there are a few places where _suspend_requested is queried by mistake instead of _suspended. Maybe it would help to prevent this if _suspend_requested was renamed to something that better describes its purpose, e.g. _has_async_suspend_handshake or similar.

src/hotspot/share/runtime/mutex.cpp line 244:

> 242:     wait_status = _lock.wait(timeout);
> 243:     in_flight_mutex = this;  // save for ~ThreadBlockInVM
> 244: 

Empty line can be removed.

src/hotspot/share/runtime/mutexLocker.hpp line 260:

> 258: 
> 259:   bool wait(int64_t timeout = 0,
> 260:             bool as_suspend_equivalent = !Mutex::_as_suspend_equivalent_flag) {

The declaration of Mutex::_as_suspend_equivalent_flag should be removed. You might want to grep for 'equivalent' to find more that can be removed.

src/hotspot/share/runtime/objectMonitor.cpp line 415:

> 413:       current->set_thread_state_fence(_thread_blocked_trans);
> 414:       if (SafepointMechanism::should_process(current) &&
> 415:         current->suspend_request_pending()) {

Shouldn't `suspend_request_pending()` be replaced with `is_suspended()`? See also comment on declaration of `_suspend_requested`.
And isn't checking `SafepointMechanism::should_process(current)` redundant?

src/hotspot/share/runtime/objectMonitor.cpp line 973:

> 971:       if (SafepointMechanism::should_process(current)) {
> 972:         if (_succ == current) {
> 973:             _succ = NULL;

IIUC then this is now not only executed if a thread is suspended but also when there's a safepoint / handshake. I tried to understand the effect of this but failed with timeout ;)

src/hotspot/share/runtime/os.cpp line 874:

> 872: 
> 873: void os::start_thread(Thread* thread) {
> 874:   if (thread->is_Java_thread()) {

Then and else blocks seem to do the very same things.

src/hotspot/share/runtime/safepointMechanism.cpp line 101:

> 99:         !thread->handshake_state()->process_by_self()) {
> 100:       need_rechecking = true;
> 101:     }

What about this version
    if (thread->handshake_state()->should_process()) {
      need_rechecking = !thread->handshake_state()->process_by_self();
    }
or even 
    need_rechecking =
        thread->handshake_state()->should_process() && !thread->handshake_state()->process_by_self();
With the latter you could eliminate L82
      need_rechecking = false;
Also I'd find it more natural if `process_by_self()` could return true if rechecking is needed.

src/hotspot/share/runtime/sweeper.cpp line 276:

> 274: 
> 275:     ThreadBlockInVM tbivm(thread);
> 276:     thread->java_suspend_self();

In the baseline version of NMethodSweeper::handle_safepoint_request() there is a call `thread->java_suspend_self()`. This call will immediately return, won't it? Do you know what the purpose of this call was? The destructor of ThreadBlockInVM will block the current thread for the safepoint. So `java_suspend_self()` seems redundant.

-------------

Changes requested by rrich (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3191

From rrich at openjdk.java.net  Tue Mar 30 21:16:38 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Tue, 30 Mar 2021 21:16:38 GMT
Subject: RFR: 8257831: Suspend with handshakes [v2]
In-Reply-To: <xkbt1_7eYWyZFFtBMkAJjFucqtWs2p10Kn0fZ-GhlCc=.227f9c51-7bf8-437d-8577-dfb6bf669eea@github.com>
References: <xv1j0DkGolookgzzyT7w9hz5-mlD0QaeHfqL3b9HJ6I=.c33a0757-1f6e-4a7c-afa4-2d531849d4fc@github.com>
 <a6Fjizolorcan3_uaH8QqfAmw6LqdOwC02DG2Yp6ZNg=.d8ebe170-cdda-42d7-912c-0210f9643da6@github.com>
 <xkbt1_7eYWyZFFtBMkAJjFucqtWs2p10Kn0fZ-GhlCc=.227f9c51-7bf8-437d-8577-dfb6bf669eea@github.com>
Message-ID: <Dl6xZ2vIgSs-GuumyWuiimyexX2qd6GEwo-8gpyHzb8=.511d7713-8efb-4a0c-bd81-6fa015c305b2@github.com>

On Tue, 30 Mar 2021 09:33:19 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Robbin Ehn 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 SuspendInHandshake
>>  - 8257831: Suspend with handshake (review baseline)
>
> src/hotspot/share/runtime/handshake.cpp line 617:
> 
>> 615:     {
>> 616:       MutexLocker ml(&_lock, Mutex::_no_safepoint_check_flag);
>> 617:       if (!is_suspend_requested()) {
> 
> The current thread is _thread_in_vm. Can it be suspended then? For a suspend it has to be in a safe thread state which it cannot leave while suspended. So it must have reached _thread_in_vm not suspended and it cannot be suspended while in that state.

Shouldn't `is_suspend_requested()` be replaced with `is_suspended()`? See also comment on declaration of `_suspend_requested`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3191

From mseledtsov at openjdk.java.net  Tue Mar 30 21:49:13 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Tue, 30 Mar 2021 21:49:13 GMT
Subject: RFR: 8264311: Heap object statistics
In-Reply-To: <nbFq41PKkjGH8ltO88ixZF16vc9qL-M49LlmgwUqfFc=.f5474f13-7ea8-462c-af6f-92bb6449ad47@github.com>
References: <elD7YoD5xbRC9TqkFWH6_kVcnsowTKjGs_YgdSLMVck=.80d78d4f-4fe0-4c76-8255-90abb8034c4d@github.com>
 <Arkh-UYMyS0A6DUzpB73qPk0_5c1wCfRu3X294EC15s=.28e7d41b-943e-48f6-bfc5-99551de5715e@github.com>
 <kxrIz9odOHuC-gVl3i8VQsjvIQPkdPkE572BQuCQVx4=.8ff729c1-9f90-4cb0-a877-4731a023b41e@github.com>
 <nbFq41PKkjGH8ltO88ixZF16vc9qL-M49LlmgwUqfFc=.f5474f13-7ea8-462c-af6f-92bb6449ad47@github.com>
Message-ID: <Ol21QrLvjvaHB8NF7KkJGwnzbkJG1UYafXLYARFNvf4=.176a77fc-79f3-405f-8ebb-5d825b6a40f0@github.com>

On Tue, 30 Mar 2021 20:29:18 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>>> You'll need a CSR for this enhancement.
>> 
>> Hmm, yeah.
>> I'm wondering if this should rather go into the Lilliput repository once it is created (I'd expect in ~1week or so). Then it would be refined during Lilliput project live time, and eventually merged upstream (and CSR'ed) when all is ready.
>> 
>> I only wanted to get this out ASAP so that people can tinker with it, and do their own measurements.
>
> I'm not involved in the Lilliput project, but as long as the stakeholders are ok with that approach, it's probably the way to go, especially since you seem to think the feature might still evolve some.

If you are planning to integrate this change to jdk/jdk, please make sure to provide tests for this enhancement.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3271

From hshi at openjdk.java.net  Tue Mar 30 23:51:41 2021
From: hshi at openjdk.java.net (Hui Shi)
Date: Tue, 30 Mar 2021 23:51:41 GMT
Subject: RFR: 8264411: serviceability/jvmti/HeapMonitor tests
 intermittently fail due to large TLAB size [v2]
In-Reply-To: <aR6ewOCBxOa4jyVfichHlksI_yapG-uQ32uAlBQ48WI=.7e0dfa14-e1bf-459b-8e0c-38133b330020@github.com>
References: <aR6ewOCBxOa4jyVfichHlksI_yapG-uQ32uAlBQ48WI=.7e0dfa14-e1bf-459b-8e0c-38133b330020@github.com>
Message-ID: <653aJgBTTTvZWbRDrROT_5QzhkI6HO074qhVBkM-3ik=.aacec9d5-fd2f-407e-9d44-605664d30689@github.com>

> ?ue to large TLAB size
> 
> serviceability/jvmti/HeapMonitor tests intermittently fail when using PS/Serial GC, original test has implicit assumptions on TLAB size and depends on allocate fix amount of objects to consume TLAB and trigger object sampling. These tests will fail if TLAB is above 20M (this can easily happen when using PS/Serial GC and heap is large), when allocation can not consume current TLAB and _byte_until_sample.
> 
> Fix in tests is adding an explicit GC to consume current TLAB.
> Running on 256G memory machine, make run-test CONF=release TEST="test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/" 'JTREG=JOBS=12;VM_OPTIONS=-XX:ActiveProcessorCount=1'
> 
> before fix: 6 or 7 tests in 20 tests intermittently fail
> after fix: no failure in 100 runs release/fastdebug
> 
> This might also fix https://bugs.openjdk.java.net/browse/JDK-8225313

Hui Shi has updated the pull request incrementally with one additional commit since the last revision:

  update copyright year

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3265/files
  - new: https://git.openjdk.java.net/jdk/pull/3265/files/0b098656..3dd108d5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3265&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3265&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3265.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3265/head:pull/3265

PR: https://git.openjdk.java.net/jdk/pull/3265

From david.holmes at oracle.com  Wed Mar 31 00:03:07 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 31 Mar 2021 10:03:07 +1000
Subject: RFR: 8264311: Heap object statistics
In-Reply-To: <kxrIz9odOHuC-gVl3i8VQsjvIQPkdPkE572BQuCQVx4=.8ff729c1-9f90-4cb0-a877-4731a023b41e@github.com>
References: <elD7YoD5xbRC9TqkFWH6_kVcnsowTKjGs_YgdSLMVck=.80d78d4f-4fe0-4c76-8255-90abb8034c4d@github.com>
 <Arkh-UYMyS0A6DUzpB73qPk0_5c1wCfRu3X294EC15s=.28e7d41b-943e-48f6-bfc5-99551de5715e@github.com>
 <kxrIz9odOHuC-gVl3i8VQsjvIQPkdPkE572BQuCQVx4=.8ff729c1-9f90-4cb0-a877-4731a023b41e@github.com>
Message-ID: <7788604a-e6e4-2b2b-fa0e-822d884f1eb6@oracle.com>

On 31/03/2021 3:41 am, Roman Kennke wrote:
> On Tue, 30 Mar 2021 17:12:52 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:
> 
>> You'll need a CSR for this enhancement.
> 
> Hmm, yeah.
> I'm wondering if this should rather go into the Lilliput repository once it is created (I'd expect in ~1week or so). Then it would be refined during Lilliput project live time, and eventually merged upstream (and CSR'ed) when all is ready.

Diagnostic flags don't need a CSR request.

Cheers,
David

> I only wanted to get this out ASAP so that people can tinker with it, and do their own measurements.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3271
> 

From iklam at openjdk.java.net  Wed Mar 31 04:08:13 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 31 Mar 2021 04:08:13 GMT
Subject: RFR: 8259070: Add jcmd option to dump CDS [v7]
In-Reply-To: <ZOFUPmirnvl49Qk6vc7CzrRfuE882WDhxkOQR8d3H_Y=.ab2eb8ee-e3a0-46bc-8517-ca06073f81cd@github.com>
References: <hwrc1zAz8G180ToL-C3EuUIF-5R17F5Gm1zcPMBpOtE=.e002a377-e0e2-485b-a08e-b63675a9746b@github.com>
 <ZOFUPmirnvl49Qk6vc7CzrRfuE882WDhxkOQR8d3H_Y=.ab2eb8ee-e3a0-46bc-8517-ca06073f81cd@github.com>
Message-ID: <Qme3QkpGFuryS2EjwcVnx_0i8jo1NHleSgL16hosiEc=.c9fdf377-a02e-4cfc-a917-d9e550a53a6d@github.com>

On Tue, 30 Mar 2021 03:48:08 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Hi, Please review
>> 
>>   Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with
>>   `java -XX:DumpLoadedClassList=<classlist> .... `  
>>  to collect shareable class names and saved in file `<classlist>` , then 
>>   `java -Xshare:dump -XX:SharedClassListFile=<classlist> -XX:SharedArchiveFile=<archivefile> ...`
>>   With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime  to dump an archive.
>>    The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved.
>>    New added jcmd option:
>>    `jcmd <pid or AppName> VM.cds static_dump <filename>`
>>    or
>>     `jcmd <pid or AppName> VM.cds dynamic_dump <filename>`
>>   To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. 
>>    The file name is optional, if the file name is not supplied, the file name will take format of `java_pid<number>_static.jsa` or `java_pid<number>_dynamic.jsa` for static and dynamic respectively. The `<number>` is the application process ID.
>> 
>>   Tests: tier1,tier2,tier3,tier4
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove CDS.getVMArguments, changed to use VM.getRuntimeVMArguments. Removed unused function from ClassLoader. Improved InstanceKlass::is_shareable() and related test. Added more test scenarios.

src/java.base/share/classes/jdk/internal/misc/CDS.java line 311:

> 309:             // done, delete classlist file.
> 310:             if (fileList.exists()) {
> 311:                 // fileList.delete();

Is the comment unintentional?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2737

From minqi at openjdk.java.net  Wed Mar 31 04:39:10 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 31 Mar 2021 04:39:10 GMT
Subject: RFR: 8259070: Add jcmd option to dump CDS [v4]
In-Reply-To: <x6lHyc-dfQ7nvJWtJQG0hUWTbGe8NlfZmzDkEBNGcjk=.dba20bd5-693b-4bc2-957c-781dcf4e5bc2@github.com>
References: <hwrc1zAz8G180ToL-C3EuUIF-5R17F5Gm1zcPMBpOtE=.e002a377-e0e2-485b-a08e-b63675a9746b@github.com>
 <9EU_DwWh3XcyBxJkxgPH1qzvbaa2hvWQYuccdRXWKj0=.c6816df0-6e73-45bc-9e52-caa70b0611fd@github.com>
 <x6lHyc-dfQ7nvJWtJQG0hUWTbGe8NlfZmzDkEBNGcjk=.dba20bd5-693b-4bc2-957c-781dcf4e5bc2@github.com>
Message-ID: <_E_YlWz1Bg93lHfN9I50a1p7lm6Wtf9NjqSHSzqWdgM=.ddc13b21-69a7-40d3-9c35-918792584a29@github.com>

On Fri, 19 Mar 2021 05:39:25 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Yumin Qi 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 filter more flags to exclude in static dump, add more test cases
>>  - Merge branch 'master' into jdk-8259070
>>  - Fix white space in CDS.java
>>  - Add function CDS.dumpSharedArchive in java to dump shared archive
>>  - 8259070: Add jcmd option to dump CDS
>
> Changes requested by iklam (Reviewer).

@iklam Thanks. Yes, the comment out for the deletion is unintentional for test only and forgot to revert. I will revert it. Also I will merge with upstream. Since this repo has no merge from upstream for long time, it may cause conflicts. If too many conflicts to  resolve I would like to withdraw this one and resubmit as a new PR. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2737

From shade at openjdk.java.net  Wed Mar 31 06:11:07 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 31 Mar 2021 06:11:07 GMT
Subject: RFR: 8264396: Use the blessed modifier order in
 jdk.internal.jvmstat [v2]
In-Reply-To: <G-gSp_dmxlvF4yzZNu3CZ6vNtBoPCbNhKvyeLYXmxjM=.578aff42-9ba7-4719-8450-3cf75e56fe7b@github.com>
References: <rrSdxlrv3z-oVhRNkDd5XTcgCl3MfGMh2pUxHl2uCTc=.5790a3c6-9b78-4e96-bb45-bace638ebae8@github.com>
 <G-gSp_dmxlvF4yzZNu3CZ6vNtBoPCbNhKvyeLYXmxjM=.578aff42-9ba7-4719-8450-3cf75e56fe7b@github.com>
Message-ID: <CLCpgmHyYnf6Fh4FjW9E3Jsu-yF9DBeAbvwJ9O26sXk=.c7c9dd47-ae15-494c-b8ab-2e76d835596d@github.com>

On Tue, 30 Mar 2021 20:37:45 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

>> 8264396: Use the blessed modifier order in jdk.internal.jvmstat
>
> Alex Blewitt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyright dates

Looks fine to me as well.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3252

From dholmes at openjdk.java.net  Wed Mar 31 07:02:35 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 31 Mar 2021 07:02:35 GMT
Subject: RFR: 8257831: Suspend with handshakes [v2]
In-Reply-To: <a6Fjizolorcan3_uaH8QqfAmw6LqdOwC02DG2Yp6ZNg=.d8ebe170-cdda-42d7-912c-0210f9643da6@github.com>
References: <xv1j0DkGolookgzzyT7w9hz5-mlD0QaeHfqL3b9HJ6I=.c33a0757-1f6e-4a7c-afa4-2d531849d4fc@github.com>
 <a6Fjizolorcan3_uaH8QqfAmw6LqdOwC02DG2Yp6ZNg=.d8ebe170-cdda-42d7-912c-0210f9643da6@github.com>
Message-ID: <qECYENgo-noFUVcExYlTP7CBEYajuKMU51JdiI6vPUw=.c19b7a63-49a4-40a4-b04f-1c4e0537078a@github.com>

On Fri, 26 Mar 2021 13:21:43 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request.
>> 
>> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread).
>> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. 
>> 
>> Suspend:
>> Requesting thread -> synchronous handshake -> target thread
>> Inside synchronus handshake (HandshakeState lock is locked while
>> executing any handshake):
>> 	- Set suspended flag
>> 	- Install asynchronous handshake
>> 
>> Target thread -> tries to leave dormant state -> Executes handshakes
>> Target only executes asynchronous handshake:
>> 	- While suspended
>> 	- Go to blocked
>> 	- Wait on HandshakeState lock
>> 
>> Resume:
>> Resuming thread:
>> 	- Lock HandshakeState lock
>> 	- Clear suspended flag
>> 	- Notify HandshakeState lock
>> 	- Unlock HandshakeState lock
>> 
>> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set.
>> 
>> ----
>> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors.
>> 
>> ----
>> Regarding the changed test, the documentation says:
>> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it."
>> 
>> But the code:
>>   LOG("suspendTestedThreads: before JVMTI SuspendThreadList");
>>   err = jvmti->SuspendThreadList(threads_count, threads, results);
>>   ...
>>   // Allow the Main thread to inspect the result of tested threads suspension	
>>   agent_unlock(jni);
>>   
>> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock().
>> Thus main thread is stuck forever on:
>>   // Block until the suspender thread competes the tested threads suspension	
>>   agent_lock(jni);
>> 
>> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state.
>> 
>> ----
>> 
>> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp.
>> (Pre-review comments here:
>> https://github.com/openjdk/jdk/pull/2625)
>> 
>> ---- 
>> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and
>> combinations like running with -XX:ZCollectionInterval=0.01 -
>> XX:ZFragmentationLimit=0.
>> Running above some of above concurrently (load ~240), slow debug,
>> etc...
>
> Robbin Ehn 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 SuspendInHandshake
>  - 8257831: Suspend with handshake (review baseline)

Hi Robbin,

This is a great piece of work with a lot of code simplifications. Unfortunately some new complexities that need to be hidden by appropriate abstractions. Lots of comments, queries and suggestions below.

Thanks,
David

src/hotspot/share/prims/jvmtiEnv.cpp line 946:

> 944: // java_thread - pre-checked
> 945: jvmtiError
> 946: JvmtiEnv::SuspendThread(JavaThread* java_thread) {

The comment above this still states:

// Threads_lock NOT held, java_thread not protected by lock

but the java_thread is protected by a TLH so we should document that so we know it is always safe to refer to java_thread below.

src/hotspot/share/prims/jvmtiEnv.cpp line 1009:

> 1007:   if (self_index >= 0) {
> 1008:     if (!JvmtiSuspendControl::suspend(current)) {
> 1009:       results[self_index] = JVMTI_ERROR_THREAD_NOT_ALIVE;

Surely impossible when dealing with the current thread!

src/hotspot/share/prims/jvmtiImpl.cpp line 767:

> 765: //
> 766: 
> 767: bool JvmtiSuspendControl::suspend(JavaThread *java_thread) {

Future RFE: JvmtiSuspendControl is no longer needed

src/hotspot/share/prims/jvmtiRawMonitor.cpp line 319:

> 317:     jt = self->as_Java_thread();
> 318:     while (true) {
> 319:       // To pause suspend requests while in native we must block handshakes.

The earlier comment says we must be _thread_blocked in this code, so we won't be "native". But that is not a _thread_blocked that is managed by a thread-state transition so that is why this code has to "manually" manage the handshake state.

src/hotspot/share/prims/jvmtiRawMonitor.cpp line 428:

> 426:       jt->set_thread_state_fence(_thread_in_native_trans);
> 427:       SafepointMechanism::process_if_requested(jt);
> 428:       if (jt->is_interrupted(true)) {

A thread must be _thread_in_vm to safely query is_interrupted() as it accesses the threadObj.

src/hotspot/share/runtime/handshake.cpp line 415:

> 413:   // Adds are done lock free and so is arming.
> 414:   // Calling this method with lock held is considered an error.
> 415:   assert(!_lock.owned_by_self(), "Lock should not be held");

If adds are still lock-free then why was this assertion removed?

src/hotspot/share/runtime/handshake.cpp line 463:

> 461:   ThreadInVMForHandshake tivm(_handshakee);
> 462:   {
> 463:     ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id());

Why is this needed when it is inside ThreadInVMForHandshake constructor ??

src/hotspot/share/runtime/handshake.cpp line 633:

> 631: bool HandshakeState::suspend_request_pending() {
> 632:   assert(JavaThread::current()->thread_state() != _thread_blocked, "should not be in a blocked state");
> 633:   assert(JavaThread::current()->thread_state() != _thread_in_native, "should not be in native");

Not clear why we care about the state of the current thread here ??

src/hotspot/share/runtime/handshake.cpp line 677:

> 675:     } else {
> 676:       // Target is going to wake up and leave suspension.
> 677:       // Let's just stop the thread from doing that.

IIUC this would be the case where the target was hit with a suspend request but has not yet processed the actual suspension handshake op, then a resume comes in so suspended is no longer true, and then another suspend request is made (this one) which simply turns the suspended flag back on - is that right?
Overall I'm finding it very hard to see what the two suspend state flags actually signify. I'd like to see that written up somewhere.

src/hotspot/share/runtime/handshake.hpp line 139:

> 137:   Thread* active_handshaker() const { return _active_handshaker; }
> 138: 
> 139:   // Suspend/resume support

This would be a good place to describe the operation of these two state fields

src/hotspot/share/runtime/handshake.hpp line 148:

> 146:   // Called from the async handshake (the trap)
> 147:   // to stop a thread from continuing executing when suspended.
> 148:   void suspend_in_handshake();

I'm finding the terminology very confusing here: handshake_suspend versus suspend_in_handshake ? It isn't at all clear which method is used in which part of the protocol. The same goes for the different closures.

src/hotspot/share/runtime/nonJavaThread.cpp line 326:

> 324: 
> 325:   while (watcher_thread() != NULL) {
> 326:     // This wait should make safepoint checks, wait without a timeout.

Nit: s/checks, wait/checks and wait/

src/hotspot/share/runtime/objectMonitor.cpp line 411:

> 409:     OrderAccess::storestore();
> 410:     for (;;) {
> 411:       current->set_thread_state(_thread_blocked);

So IIUC because ThreadblockInVM  is now responsible for handling thread suspension checks, but those checks need to be done at a lower level, we can no longer use ThreadBlockInVM in some places. That both undermines the value of ThreadBlockInVM and make this manual management code much more complex.
I agree with Richard that a TBIVM that took an unlock function would make this kind of code much clearer.

src/hotspot/share/runtime/sweeper.cpp line 276:

> 274: 
> 275:     ThreadBlockInVM tbivm(thread);
> 276:     thread->java_suspend_self();

AFAICS the only change needed in this function was to delete the java_suspend_self as it is not handled in the TBIVM.

src/hotspot/share/runtime/sweeper.cpp line 276:

> 274:   }
> 275:   MutexUnlocker mu(CodeCache_lock, Mutex::_no_safepoint_check_flag);
> 276:   ThreadBlockInVM tbiv(JavaThread::current());

You already have the current thread.

src/hotspot/share/runtime/thread.cpp line 460:

> 458:   delete metadata_handles();
> 459: 
> 460:   // SR_handler uses this as a termination indicator -

As noted previously we need a replacement for this as a proxy for a Thread (not JavaThread) terminating.

src/hotspot/share/runtime/thread.cpp line 667:

> 665: 
> 666:       // We wait for the thread to transition to a more usable state.
> 667:       for (int i = 1; i <= SuspendRetryCount; i++) {

You will need to obsolete SuspendRetryCount and SuspendRetryDelay. This will need a CSR request indicating why there is no deprecation step.

src/hotspot/share/runtime/thread.cpp line 1442:

> 1440: 
> 1441:     // The careful dance between thread suspension and exit is handled here:
> 1442:     _handshake.thread_exit();

I don't like the fact this hides the set_terminating call.

In fact I think I'd rather keep this in-line rather than tucking it away inside the handshake code. This looks too much like we're informing the handshake that the thread  is exiting rather then coordinating thread termination with a late suspension request.

src/hotspot/share/runtime/thread.cpp line 2099:

> 2097:   do {
> 2098:     set_thread_state(_thread_blocked);
> 2099:     // Check if _external_suspend was set in the previous loop iteration.

Note that the comment for this method at line 1806 needs updating as it refers to a now deleted method.

src/hotspot/share/runtime/thread.cpp line 2102:

> 2100:     if (is_external_suspend()) {
> 2101:       java_suspend_self();
> 2102:     }

It is not at all clear to me how this method should interact with thread suspension ??

src/hotspot/share/runtime/thread.hpp line 1146:

> 1144:   // if external|deopt suspend is present.
> 1145:   bool is_suspend_after_native() const {
> 1146:     return (_suspend_flags & (_obj_deopt JFR_ONLY(| _trace_flag))) != 0;

Comment at line 1144 needs updating.

src/hotspot/share/runtime/thread.inline.hpp line 194:

> 192: 
> 193: inline void JavaThread::set_exiting() {
> 194:   // use release-store so the setting of _terminated is seen more quickly

Pre-existing: A release doesn't push changes to main memory more quickly it only establishes ordering with previous loads and stores. Why do we need release semantics here - what state are with ordering with? What load-acquire are we pairing with?

src/hotspot/share/runtime/thread.inline.hpp line 207:

> 205: }
> 206: 
> 207: inline void JavaThread::set_terminated(TerminatedTypes t) {

I prefer set_terminated(arg) over the new set of methods.

src/hotspot/share/runtime/vmStructs.cpp line 764:

> 762:                                                                                                                                      \
> 763:   /*********************************/                                                                                                \
> 764:   /* JavaThread (NOTE: incomplete) */                                                                                                \

???

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Thread.java line 79:

> 77:   }
> 78: 
> 79:   public boolean isExternalSuspend() {

I assume a new SA API for thread suspension is needed here.

test/hotspot/jtreg/serviceability/jvmti/SuspendWithCurrentThread/SuspendWithCurrentThread.java line 132:

> 130:             ThreadToSuspend.setAllThreadsReady();
> 131: 
> 132:             while (!checkSuspendedStatus()) {

The changes to this test are still quite unclear to me. Too hard to figure out what the test was originally trying to do!

-------------

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3191

From dholmes at openjdk.java.net  Wed Mar 31 07:02:36 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 31 Mar 2021 07:02:36 GMT
Subject: RFR: 8257831: Suspend with handshakes [v2]
In-Reply-To: <lfoWy9GAZC-tp75AqoATcaOOwWhHfoQjHZ236wmhL64=.628619cf-5e45-475b-958e-70dccef9bcb6@github.com>
References: <xv1j0DkGolookgzzyT7w9hz5-mlD0QaeHfqL3b9HJ6I=.c33a0757-1f6e-4a7c-afa4-2d531849d4fc@github.com>
 <a6Fjizolorcan3_uaH8QqfAmw6LqdOwC02DG2Yp6ZNg=.d8ebe170-cdda-42d7-912c-0210f9643da6@github.com>
 <lfoWy9GAZC-tp75AqoATcaOOwWhHfoQjHZ236wmhL64=.628619cf-5e45-475b-958e-70dccef9bcb6@github.com>
Message-ID: <RzUniZabptKFS1qhpsmktmsqmVKML7lGerSDyv723Ro=.fb8300d8-11a8-40b1-b275-dbce9d9c14a5@github.com>

On Tue, 30 Mar 2021 16:50:50 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Robbin Ehn 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 SuspendInHandshake
>>  - 8257831: Suspend with handshake (review baseline)
>
> src/hotspot/os/posix/signals_posix.cpp line 1587:
> 
>> 1585:   // destructor has completed.
>> 1586: 
>> 1587:   if (thread->is_Java_thread() && thread->as_Java_thread()->is_terminated()) {
> 
> We need @dholmes-ora to verify that this version of the code will
> still solve the bug he was fixing when he added old L1610.

Thanks @dcubed-ojdk - no it won't. The problem is that the signal can hit very late in a thread's termination process, after the JavaThread destructor has executed, so no query of JavaThread state is possible. So we needed something in the Thread state and the SR_lock was a good enough proxy for that. It may be possible to use a different Thread field (perhaps _ParkEvent but encapsulated in a Thread::has_terminated() helper method).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3191

From dholmes at openjdk.java.net  Wed Mar 31 07:02:37 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 31 Mar 2021 07:02:37 GMT
Subject: RFR: 8257831: Suspend with handshakes [v2]
In-Reply-To: <xkbt1_7eYWyZFFtBMkAJjFucqtWs2p10Kn0fZ-GhlCc=.227f9c51-7bf8-437d-8577-dfb6bf669eea@github.com>
References: <xv1j0DkGolookgzzyT7w9hz5-mlD0QaeHfqL3b9HJ6I=.c33a0757-1f6e-4a7c-afa4-2d531849d4fc@github.com>
 <a6Fjizolorcan3_uaH8QqfAmw6LqdOwC02DG2Yp6ZNg=.d8ebe170-cdda-42d7-912c-0210f9643da6@github.com>
 <xkbt1_7eYWyZFFtBMkAJjFucqtWs2p10Kn0fZ-GhlCc=.227f9c51-7bf8-437d-8577-dfb6bf669eea@github.com>
Message-ID: <PadtsT2KtkBLJc1tqSbJblZjW12VWUtYBet_T5Ocsbo=.e87a04cd-a611-4482-87cb-6592395d2862@github.com>

On Mon, 29 Mar 2021 17:30:32 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Robbin Ehn 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 SuspendInHandshake
>>  - 8257831: Suspend with handshake (review baseline)
>
> src/hotspot/share/runtime/handshake.cpp line 485:
> 
>> 483:       } else {
>> 484:         // Asynchronous may block so they may not execute ~PreserveExceptionMark before safepointing
>> 485:         // in outer loop.
> 
> Sorry, I don't understand the comment.

I think this relates to why the PEM was moved from the loop-scope to the sync op case only. That said it isn't clear why we need the HM or PEM.

> src/hotspot/share/runtime/os.cpp line 874:
> 
>> 872: 
>> 873: void os::start_thread(Thread* thread) {
>> 874:   if (thread->is_Java_thread()) {
> 
> Then and else blocks seem to do the very same things.

Agreed - no need to distinguish between thread types here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3191

From rrich at openjdk.java.net  Wed Mar 31 07:51:34 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Wed, 31 Mar 2021 07:51:34 GMT
Subject: RFR: 8257831: Suspend with handshakes [v2]
In-Reply-To: <qECYENgo-noFUVcExYlTP7CBEYajuKMU51JdiI6vPUw=.c19b7a63-49a4-40a4-b04f-1c4e0537078a@github.com>
References: <xv1j0DkGolookgzzyT7w9hz5-mlD0QaeHfqL3b9HJ6I=.c33a0757-1f6e-4a7c-afa4-2d531849d4fc@github.com>
 <a6Fjizolorcan3_uaH8QqfAmw6LqdOwC02DG2Yp6ZNg=.d8ebe170-cdda-42d7-912c-0210f9643da6@github.com>
 <qECYENgo-noFUVcExYlTP7CBEYajuKMU51JdiI6vPUw=.c19b7a63-49a4-40a4-b04f-1c4e0537078a@github.com>
Message-ID: <zh-q9GNGDppcpYqr8kZGYR5F4Lzkq8wO-hYkDMEnqkc=.08ef3008-eee0-4379-96df-d3163a36e032@github.com>

On Wed, 31 Mar 2021 03:40:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Robbin Ehn 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 SuspendInHandshake
>>  - 8257831: Suspend with handshake (review baseline)
>
> src/hotspot/share/prims/jvmtiEnv.cpp line 1009:
> 
>> 1007:   if (self_index >= 0) {
>> 1008:     if (!JvmtiSuspendControl::suspend(current)) {
>> 1009:       results[self_index] = JVMTI_ERROR_THREAD_NOT_ALIVE;
> 
> Surely impossible when dealing with the current thread!

Another thread can win the race to suspend the current thread (if claim_handshake() in try_process() fails). Then JVMTI_ERROR_THREAD_SUSPENDED should be returned.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3191

From rrich at openjdk.java.net  Wed Mar 31 08:04:41 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Wed, 31 Mar 2021 08:04:41 GMT
Subject: RFR: 8257831: Suspend with handshakes [v2]
In-Reply-To: <PadtsT2KtkBLJc1tqSbJblZjW12VWUtYBet_T5Ocsbo=.e87a04cd-a611-4482-87cb-6592395d2862@github.com>
References: <xv1j0DkGolookgzzyT7w9hz5-mlD0QaeHfqL3b9HJ6I=.c33a0757-1f6e-4a7c-afa4-2d531849d4fc@github.com>
 <a6Fjizolorcan3_uaH8QqfAmw6LqdOwC02DG2Yp6ZNg=.d8ebe170-cdda-42d7-912c-0210f9643da6@github.com>
 <xkbt1_7eYWyZFFtBMkAJjFucqtWs2p10Kn0fZ-GhlCc=.227f9c51-7bf8-437d-8577-dfb6bf669eea@github.com>
 <PadtsT2KtkBLJc1tqSbJblZjW12VWUtYBet_T5Ocsbo=.e87a04cd-a611-4482-87cb-6592395d2862@github.com>
Message-ID: <KtfYSSZ2AUOMh70BMn_2dHQuHHgMTmz4_Lr7ezyFMqU=.5f32dc39-ac56-4773-9dba-162e643123b8@github.com>

On Wed, 31 Mar 2021 05:27:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/handshake.cpp line 485:
>> 
>>> 483:       } else {
>>> 484:         // Asynchronous may block so they may not execute ~PreserveExceptionMark before safepointing
>>> 485:         // in outer loop.
>> 
>> Sorry, I don't understand the comment.
>
> I think this relates to why the PEM was moved from the loop-scope to the sync op case only. That said it isn't clear why we need the HM or PEM.

I guess it should be "... must not execute ~PreserveExceptionMark ..."
~PreserveExceptionMark calls _thread->pending_exception() which is an oop and that would be illegal as the vm could be at a safepoint when the async handshake returns.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3191

From github.com+77011692+actuallyasmartname at openjdk.java.net  Wed Mar 31 08:09:44 2021
From: github.com+77011692+actuallyasmartname at openjdk.java.net (actuallyasmartname)
Date: Wed, 31 Mar 2021 08:09:44 GMT
Subject: RFR: 8264484: Replace uses of StringBuffer with StringBuilder in
 jdk.hotspot.agent
In-Reply-To: <JG1dWhnHiime4ikiR6s-b6GTe7G7RpG_EI3W46Z1XL4=.66f74e8d-5dcc-4263-96c9-9d4e0e7b1822@github.com>
References: <JG1dWhnHiime4ikiR6s-b6GTe7G7RpG_EI3W46Z1XL4=.66f74e8d-5dcc-4263-96c9-9d4e0e7b1822@github.com>
Message-ID: <8f5pMe9Csq0bSryg5KI4iyAl5vV0tJ5tttnRtJCciTA=.bc722edc-0fef-4ddb-91b5-57b3e4448ec4@github.com>

On Tue, 30 Mar 2021 18:58:24 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Found by IntelliJ IDEA inspection `Java | Java language level migration aids | Java 5 | 'StringBuffer' may be 'StringBuilder'`
> As suggested in https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created separate PR for module `jdk.hotspot.agent`
> Similar cleanups in the past: https://bugs.openjdk.java.net/browse/JDK-8041679 https://bugs.openjdk.java.net/browse/JDK-8264029

Marked as reviewed by actuallyasmartname at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3275

From github.com+741251+turbanoff at openjdk.java.net  Wed Mar 31 08:09:44 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 31 Mar 2021 08:09:44 GMT
Subject: RFR: 8264484: Replace uses of StringBuffer with StringBuilder in
 jdk.hotspot.agent
Message-ID: <JG1dWhnHiime4ikiR6s-b6GTe7G7RpG_EI3W46Z1XL4=.66f74e8d-5dcc-4263-96c9-9d4e0e7b1822@github.com>

Found by IntelliJ IDEA inspection `Java | Java language level migration aids | Java 5 | 'StringBuffer' may be 'StringBuilder'`
As suggested in https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created separate PR for module `jdk.hotspot.agent`
Similar cleanups in the past: https://bugs.openjdk.java.net/browse/JDK-8041679 https://bugs.openjdk.java.net/browse/JDK-8264029

-------------

Commit messages:
 - [PATCH] Replace uses of StringBuffer with StringBuilder in jdk.hotspot.agent

Changes: https://git.openjdk.java.net/jdk/pull/3275/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3275&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264484
  Stats: 117 lines in 37 files changed: 0 ins; 5 del; 112 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3275.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3275/head:pull/3275

PR: https://git.openjdk.java.net/jdk/pull/3275

From shade at openjdk.java.net  Wed Mar 31 08:09:44 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 31 Mar 2021 08:09:44 GMT
Subject: RFR: 8264484: Replace uses of StringBuffer with StringBuilder in
 jdk.hotspot.agent
In-Reply-To: <8f5pMe9Csq0bSryg5KI4iyAl5vV0tJ5tttnRtJCciTA=.bc722edc-0fef-4ddb-91b5-57b3e4448ec4@github.com>
References: <JG1dWhnHiime4ikiR6s-b6GTe7G7RpG_EI3W46Z1XL4=.66f74e8d-5dcc-4263-96c9-9d4e0e7b1822@github.com>
 <8f5pMe9Csq0bSryg5KI4iyAl5vV0tJ5tttnRtJCciTA=.bc722edc-0fef-4ddb-91b5-57b3e4448ec4@github.com>
Message-ID: <C_xSMFDsBI-hv5-cVRdtesw7O7HO-hgr6zxpGAhqqc0=.a93dd7df-1a0b-4f73-b3cf-2f401efe7090@github.com>

On Tue, 30 Mar 2021 19:41:32 GMT, actuallyasmartname <github.com+77011692+actuallyasmartname at openjdk.org> wrote:

>> Found by IntelliJ IDEA inspection `Java | Java language level migration aids | Java 5 | 'StringBuffer' may be 'StringBuilder'`
>> As suggested in https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created separate PR for module `jdk.hotspot.agent`
>> Similar cleanups in the past: https://bugs.openjdk.java.net/browse/JDK-8041679 https://bugs.openjdk.java.net/browse/JDK-8264029
>
> Marked as reviewed by actuallyasmartname at github.com (no known OpenJDK username).

Created https://bugs.openjdk.java.net/browse/JDK-8264484 for it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3275

From ysuenaga at openjdk.java.net  Wed Mar 31 08:26:19 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 31 Mar 2021 08:26:19 GMT
Subject: RFR: 8264484: Replace uses of StringBuffer with StringBuilder in
 jdk.hotspot.agent
In-Reply-To: <JG1dWhnHiime4ikiR6s-b6GTe7G7RpG_EI3W46Z1XL4=.66f74e8d-5dcc-4263-96c9-9d4e0e7b1822@github.com>
References: <JG1dWhnHiime4ikiR6s-b6GTe7G7RpG_EI3W46Z1XL4=.66f74e8d-5dcc-4263-96c9-9d4e0e7b1822@github.com>
Message-ID: <yPTHAxsTcu2Ox_8KC1o8O9KVwfPLB9yN-6_db5UDyaQ=.ad351027-42ea-466b-a8d7-f18b20fc54bd@github.com>

On Tue, 30 Mar 2021 18:58:24 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Found by IntelliJ IDEA inspection `Java | Java language level migration aids | Java 5 | 'StringBuffer' may be 'StringBuilder'`
> As suggested in https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created separate PR for module `jdk.hotspot.agent`
> Similar cleanups in the past: https://bugs.openjdk.java.net/browse/JDK-8041679 https://bugs.openjdk.java.net/browse/JDK-8264029

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VMVersionMismatchException.java line 40:

> 38:                 ". Target VM is " + targetVersion;
> 39:         return msg;
> 40:     }

Why don't you return `msg` directly? I think `msg` is not needed.
I saw similar codes in other places.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3275

From rehn at openjdk.java.net  Wed Mar 31 08:27:35 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 31 Mar 2021 08:27:35 GMT
Subject: RFR: 8257831: Suspend with handshakes [v3]
In-Reply-To: <xv1j0DkGolookgzzyT7w9hz5-mlD0QaeHfqL3b9HJ6I=.c33a0757-1f6e-4a7c-afa4-2d531849d4fc@github.com>
References: <xv1j0DkGolookgzzyT7w9hz5-mlD0QaeHfqL3b9HJ6I=.c33a0757-1f6e-4a7c-afa4-2d531849d4fc@github.com>
Message-ID: <bPEyMhsMlH16rk-0RyisJsny5DqtBfFbjXN4H4HnYC8=.3eb80b7d-4ee9-4233-8306-d14e9b2a1c4e@github.com>

> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request.
> 
> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread).
> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. 
> 
> Suspend:
> Requesting thread -> synchronous handshake -> target thread
> Inside synchronus handshake (HandshakeState lock is locked while
> executing any handshake):
> 	- Set suspended flag
> 	- Install asynchronous handshake
> 
> Target thread -> tries to leave dormant state -> Executes handshakes
> Target only executes asynchronous handshake:
> 	- While suspended
> 	- Go to blocked
> 	- Wait on HandshakeState lock
> 
> Resume:
> Resuming thread:
> 	- Lock HandshakeState lock
> 	- Clear suspended flag
> 	- Notify HandshakeState lock
> 	- Unlock HandshakeState lock
> 
> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set.
> 
> ----
> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors.
> 
> ----
> Regarding the changed test, the documentation says:
> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it."
> 
> But the code:
>   LOG("suspendTestedThreads: before JVMTI SuspendThreadList");
>   err = jvmti->SuspendThreadList(threads_count, threads, results);
>   ...
>   // Allow the Main thread to inspect the result of tested threads suspension	
>   agent_unlock(jni);
>   
> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock().
> Thus main thread is stuck forever on:
>   // Block until the suspender thread competes the tested threads suspension	
>   agent_lock(jni);
> 
> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state.
> 
> ----
> 
> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp.
> (Pre-review comments here:
> https://github.com/openjdk/jdk/pull/2625)
> 
> ---- 
> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and
> combinations like running with -XX:ZCollectionInterval=0.01 -
> XX:ZFragmentationLimit=0.
> Running above some of above concurrently (load ~240), slow debug,
> etc...

Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge branch 'master' into SuspendInHandshake
 - Merge branch 'master' into SuspendInHandshake
 - 8257831: Suspend with handshake (review baseline)

-------------

Changes: https://git.openjdk.java.net/jdk/pull/3191/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3191&range=02
  Stats: 1313 lines in 38 files changed: 271 ins; 855 del; 187 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3191.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3191/head:pull/3191

PR: https://git.openjdk.java.net/jdk/pull/3191

From rehn at openjdk.java.net  Wed Mar 31 08:27:36 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 31 Mar 2021 08:27:36 GMT
Subject: RFR: 8257831: Suspend with handshakes [v2]
In-Reply-To: <lfoWy9GAZC-tp75AqoATcaOOwWhHfoQjHZ236wmhL64=.628619cf-5e45-475b-958e-70dccef9bcb6@github.com>
References: <xv1j0DkGolookgzzyT7w9hz5-mlD0QaeHfqL3b9HJ6I=.c33a0757-1f6e-4a7c-afa4-2d531849d4fc@github.com>
 <a6Fjizolorcan3_uaH8QqfAmw6LqdOwC02DG2Yp6ZNg=.d8ebe170-cdda-42d7-912c-0210f9643da6@github.com>
 <lfoWy9GAZC-tp75AqoATcaOOwWhHfoQjHZ236wmhL64=.628619cf-5e45-475b-958e-70dccef9bcb6@github.com>
Message-ID: <k1FufoCLH7KGAfVkBeKxtU4kMbFt9A68sck3YlnxFbU=.36c943c1-3da2-4d47-9321-c21281af7bf2@github.com>

On Tue, 30 Mar 2021 17:08:07 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Robbin Ehn 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 SuspendInHandshake
>>  - 8257831: Suspend with handshake (review baseline)
>
> src/hotspot/share/runtime/objectMonitor.cpp line 422:
> 
>> 420:         _recursions = 0;
>> 421:         _succ = NULL;
>> 422:         exit(false, current);
> 
> You'll have a conflict with @pchilano recent fix.

Fixed with a merge with master.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3191

From dholmes at openjdk.java.net  Wed Mar 31 09:22:27 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 31 Mar 2021 09:22:27 GMT
Subject: RFR: 8257831: Suspend with handshakes [v2]
In-Reply-To: <zh-q9GNGDppcpYqr8kZGYR5F4Lzkq8wO-hYkDMEnqkc=.08ef3008-eee0-4379-96df-d3163a36e032@github.com>
References: <xv1j0DkGolookgzzyT7w9hz5-mlD0QaeHfqL3b9HJ6I=.c33a0757-1f6e-4a7c-afa4-2d531849d4fc@github.com>
 <a6Fjizolorcan3_uaH8QqfAmw6LqdOwC02DG2Yp6ZNg=.d8ebe170-cdda-42d7-912c-0210f9643da6@github.com>
 <qECYENgo-noFUVcExYlTP7CBEYajuKMU51JdiI6vPUw=.c19b7a63-49a4-40a4-b04f-1c4e0537078a@github.com>
 <zh-q9GNGDppcpYqr8kZGYR5F4Lzkq8wO-hYkDMEnqkc=.08ef3008-eee0-4379-96df-d3163a36e032@github.com>
Message-ID: <L_bT7G_UmsPKQfgxAoUujZZYg3wFqBeKWXPDIdXL-7c=.bb20229f-1c6e-48d0-80a9-30d6444bdbc2@github.com>

On Wed, 31 Mar 2021 07:48:00 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiEnv.cpp line 1009:
>> 
>>> 1007:   if (self_index >= 0) {
>>> 1008:     if (!JvmtiSuspendControl::suspend(current)) {
>>> 1009:       results[self_index] = JVMTI_ERROR_THREAD_NOT_ALIVE;
>> 
>> Surely impossible when dealing with the current thread!
>
> Another thread can win the race to suspend the current thread (if claim_handshake() in try_process() fails). Then JVMTI_ERROR_THREAD_SUSPENDED should be returned.

My comment was about JVMTI_ERROR_THREAD_NOT_ALIVE

-------------

PR: https://git.openjdk.java.net/jdk/pull/3191

From github.com+76791+alblue at openjdk.java.net  Wed Mar 31 09:27:29 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Wed, 31 Mar 2021 09:27:29 GMT
Subject: RFR: 8264396: Use the blessed modifier order in
 jdk.internal.jvmstat [v2]
In-Reply-To: <CLCpgmHyYnf6Fh4FjW9E3Jsu-yF9DBeAbvwJ9O26sXk=.c7c9dd47-ae15-494c-b8ab-2e76d835596d@github.com>
References: <rrSdxlrv3z-oVhRNkDd5XTcgCl3MfGMh2pUxHl2uCTc=.5790a3c6-9b78-4e96-bb45-bace638ebae8@github.com>
 <G-gSp_dmxlvF4yzZNu3CZ6vNtBoPCbNhKvyeLYXmxjM=.578aff42-9ba7-4719-8450-3cf75e56fe7b@github.com>
 <CLCpgmHyYnf6Fh4FjW9E3Jsu-yF9DBeAbvwJ9O26sXk=.c7c9dd47-ae15-494c-b8ab-2e76d835596d@github.com>
Message-ID: <rtFSInRIG0lBeWgvuESZ9MqbyX-Tb2uo_FR4JPFD7bU=.8c98b84d-4fec-4286-9beb-1389364e8672@github.com>

On Wed, 31 Mar 2021 06:07:57 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Alex Blewitt has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated copyright dates
>
> Looks fine to me as well.

Going to upstream this patch into opendjk/panama-foreign

-------------

PR: https://git.openjdk.java.net/jdk/pull/3252

From github.com+76791+alblue at openjdk.java.net  Wed Mar 31 09:27:30 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Wed, 31 Mar 2021 09:27:30 GMT
Subject: Withdrawn: 8264396: Use the blessed modifier order in
 jdk.internal.jvmstat
In-Reply-To: <rrSdxlrv3z-oVhRNkDd5XTcgCl3MfGMh2pUxHl2uCTc=.5790a3c6-9b78-4e96-bb45-bace638ebae8@github.com>
References: <rrSdxlrv3z-oVhRNkDd5XTcgCl3MfGMh2pUxHl2uCTc=.5790a3c6-9b78-4e96-bb45-bace638ebae8@github.com>
Message-ID: <H1NVhpnM2m_P7uitpqhX_0svIQQsVzfcIMakvr7FPv4=.2dc4de00-0fe8-4e8d-ac7a-beea1dfce878@github.com>

On Mon, 29 Mar 2021 21:00:20 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> 8264396: Use the blessed modifier order in jdk.internal.jvmstat

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3252

From github.com+76791+alblue at openjdk.java.net  Wed Mar 31 09:35:28 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Wed, 31 Mar 2021 09:35:28 GMT
Subject: RFR: 8264396: Use the blessed modifier order in
 jdk.internal.jvmstat [v2]
In-Reply-To: <rtFSInRIG0lBeWgvuESZ9MqbyX-Tb2uo_FR4JPFD7bU=.8c98b84d-4fec-4286-9beb-1389364e8672@github.com>
References: <rrSdxlrv3z-oVhRNkDd5XTcgCl3MfGMh2pUxHl2uCTc=.5790a3c6-9b78-4e96-bb45-bace638ebae8@github.com>
 <G-gSp_dmxlvF4yzZNu3CZ6vNtBoPCbNhKvyeLYXmxjM=.578aff42-9ba7-4719-8450-3cf75e56fe7b@github.com>
 <CLCpgmHyYnf6Fh4FjW9E3Jsu-yF9DBeAbvwJ9O26sXk=.c7c9dd47-ae15-494c-b8ab-2e76d835596d@github.com>
 <rtFSInRIG0lBeWgvuESZ9MqbyX-Tb2uo_FR4JPFD7bU=.8c98b84d-4fec-4286-9beb-1389364e8672@github.com>
Message-ID: <4yLCYpqveaT2MmhtDoEkyHUIVwO1Pk3EreDoZVrih48=.fcf83dc4-02b7-4133-810e-35647fe780d3@github.com>

On Wed, 31 Mar 2021 09:24:46 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

>> Looks fine to me as well.
>
> Going to upstream this patch into opendjk/panama-foreign

Sorry, closed the wrong PR. This one should be good to go ??

-------------

PR: https://git.openjdk.java.net/jdk/pull/3252

From rrich at openjdk.java.net  Wed Mar 31 09:40:26 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Wed, 31 Mar 2021 09:40:26 GMT
Subject: RFR: 8257831: Suspend with handshakes [v3]
In-Reply-To: <qECYENgo-noFUVcExYlTP7CBEYajuKMU51JdiI6vPUw=.c19b7a63-49a4-40a4-b04f-1c4e0537078a@github.com>
References: <xv1j0DkGolookgzzyT7w9hz5-mlD0QaeHfqL3b9HJ6I=.c33a0757-1f6e-4a7c-afa4-2d531849d4fc@github.com>
 <a6Fjizolorcan3_uaH8QqfAmw6LqdOwC02DG2Yp6ZNg=.d8ebe170-cdda-42d7-912c-0210f9643da6@github.com>
 <qECYENgo-noFUVcExYlTP7CBEYajuKMU51JdiI6vPUw=.c19b7a63-49a4-40a4-b04f-1c4e0537078a@github.com>
Message-ID: <UQi9A9EtODwrpVNg_vmzEnSKAx_y2oPOe8GqvDFoHmw=.d25430b3-8b43-46d3-adfb-c88845fcd71a@github.com>

On Wed, 31 Mar 2021 06:42:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - Merge branch 'master' into SuspendInHandshake
>>  - Merge branch 'master' into SuspendInHandshake
>>  - 8257831: Suspend with handshake (review baseline)
>
> src/hotspot/share/runtime/thread.cpp line 2105:
> 
>> 2103:     if (is_external_suspend()) {
>> 2104:       java_suspend_self();
>> 2105:     }
> 
> It is not at all clear to me how this method should interact with thread suspension ??

In JavaThread::wait_for_object_deoptimization() the current thread can transition to the safe state _thread_blocked. In that state it can be suspended. In the baseline version wait_for_object_deoptimization() checks for suspension explicitly and self suspends if positive. With this enhancement it happens implicitly by calling SafepointMechanism::process_if_requested().

-------------

PR: https://git.openjdk.java.net/jdk/pull/3191

From rrich at openjdk.java.net  Wed Mar 31 10:25:26 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Wed, 31 Mar 2021 10:25:26 GMT
Subject: RFR: 8257831: Suspend with handshakes [v2]
In-Reply-To: <L_bT7G_UmsPKQfgxAoUujZZYg3wFqBeKWXPDIdXL-7c=.bb20229f-1c6e-48d0-80a9-30d6444bdbc2@github.com>
References: <xv1j0DkGolookgzzyT7w9hz5-mlD0QaeHfqL3b9HJ6I=.c33a0757-1f6e-4a7c-afa4-2d531849d4fc@github.com>
 <a6Fjizolorcan3_uaH8QqfAmw6LqdOwC02DG2Yp6ZNg=.d8ebe170-cdda-42d7-912c-0210f9643da6@github.com>
 <qECYENgo-noFUVcExYlTP7CBEYajuKMU51JdiI6vPUw=.c19b7a63-49a4-40a4-b04f-1c4e0537078a@github.com>
 <zh-q9GNGDppcpYqr8kZGYR5F4Lzkq8wO-hYkDMEnqkc=.08ef3008-eee0-4379-96df-d3163a36e032@github.com>
 <L_bT7G_UmsPKQfgxAoUujZZYg3wFqBeKWXPDIdXL-7c=.bb20229f-1c6e-48d0-80a9-30d6444bdbc2@github.com>
Message-ID: <m4Pevdd5jNKLfOij_iJBbsHvrM0dEJ0E7gWQd6vCj54=.116f3703-300c-46e3-98e7-98e045d74cb5@github.com>

On Wed, 31 Mar 2021 09:18:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Another thread can win the race to suspend the current thread (if claim_handshake() in try_process() fails). Then JVMTI_ERROR_THREAD_SUSPENDED should be returned.
>
> My comment was about JVMTI_ERROR_THREAD_NOT_ALIVE

Sure. I agree with your comment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3191

From rehn at openjdk.java.net  Wed Mar 31 10:51:31 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 31 Mar 2021 10:51:31 GMT
Subject: RFR: 8257831: Suspend with handshakes [v2]
In-Reply-To: <RzUniZabptKFS1qhpsmktmsqmVKML7lGerSDyv723Ro=.fb8300d8-11a8-40b1-b275-dbce9d9c14a5@github.com>
References: <xv1j0DkGolookgzzyT7w9hz5-mlD0QaeHfqL3b9HJ6I=.c33a0757-1f6e-4a7c-afa4-2d531849d4fc@github.com>
 <a6Fjizolorcan3_uaH8QqfAmw6LqdOwC02DG2Yp6ZNg=.d8ebe170-cdda-42d7-912c-0210f9643da6@github.com>
 <lfoWy9GAZC-tp75AqoATcaOOwWhHfoQjHZ236wmhL64=.628619cf-5e45-475b-958e-70dccef9bcb6@github.com>
 <RzUniZabptKFS1qhpsmktmsqmVKML7lGerSDyv723Ro=.fb8300d8-11a8-40b1-b275-dbce9d9c14a5@github.com>
Message-ID: <3hnHTIU7h2VZ8ZcubYBQV7L-T8yyoJ1VUdQH5RK8eWE=.afc11483-37d2-4cc6-9177-13c6cb709e88@github.com>

On Wed, 31 Mar 2021 02:43:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/os/posix/signals_posix.cpp line 1587:
>> 
>>> 1585:   // destructor has completed.
>>> 1586: 
>>> 1587:   if (thread->is_Java_thread() && thread->as_Java_thread()->is_terminated()) {
>> 
>> We need @dholmes-ora to verify that this version of the code will
>> still solve the bug he was fixing when he added old L1610.
>
> Thanks @dcubed-ojdk - no it won't. The problem is that the signal can hit very late in a thread's termination process, after the JavaThread destructor has executed, so no query of JavaThread state is possible. So we needed something in the Thread state and the SR_lock was a good enough proxy for that. It may be possible to use a different Thread field (perhaps _ParkEvent but encapsulated in a Thread::has_terminated() helper method).

SR_handler is used for OS-level suspend/resume (not to conflict with this change-set).
This feature is only used by JFR (AFAIK), and JFR only samples threads on it's ThreadsList.
This means the JavaThread can never be terminated, hence this code will always pass.

If someone else is using OS-level suspend/resume without a ThreadsList, the bug is there is no ThreadsList AFAICT.

Since ThreadLocalStorage::thread() is cleared last in ~Thread with Thread::clear_thread_current(); may be in the ~Thread destructor.
So the argument is that would be safe to read stuff from Thread but not JavaThread?
Since the compiler (and CPU) may reorder and optimize away code, so I argue reading from a half destroyed object is not a great idea.
E.g. Monitor* _SR_lock; is not a volatile pointer; since reading from this memory is UB after destruction, compiler is free to remove or not publish the store to NULL.

So I suggest either to remove this check, since the only user is using a ThreadsList and any other should also be using that too.
Or call Thread::clear_thread_current() before the JavaThread destructor is called, that way we can be certain that there is no UB.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3191

From rehn at openjdk.java.net  Wed Mar 31 10:58:32 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 31 Mar 2021 10:58:32 GMT
Subject: RFR: 8257831: Suspend with handshakes [v2]
In-Reply-To: <lfoWy9GAZC-tp75AqoATcaOOwWhHfoQjHZ236wmhL64=.628619cf-5e45-475b-958e-70dccef9bcb6@github.com>
References: <xv1j0DkGolookgzzyT7w9hz5-mlD0QaeHfqL3b9HJ6I=.c33a0757-1f6e-4a7c-afa4-2d531849d4fc@github.com>
 <a6Fjizolorcan3_uaH8QqfAmw6LqdOwC02DG2Yp6ZNg=.d8ebe170-cdda-42d7-912c-0210f9643da6@github.com>
 <lfoWy9GAZC-tp75AqoATcaOOwWhHfoQjHZ236wmhL64=.628619cf-5e45-475b-958e-70dccef9bcb6@github.com>
Message-ID: <tTPWxwonxbWExr1-g5MjB2RAXI-qxaWBIJjEdoKCjJk=.ad50e53f-1be1-4927-8a3c-588a91e02657@github.com>

On Tue, 30 Mar 2021 17:15:52 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This is an elegant evolution of the suspend/resume mechanism.
> 
> It is so nice to see all the suspend-equivalent stuff go away!

Thanks Dan!

> src/hotspot/share/runtime/handshake.hpp line 37:
> 
>> 35: class JavaThread;
>> 36: class ThreadSuspensionHandshake;
>> 37: class SuspendThreadHandshake;
> 
> Should these be in alpha sort order?

Thanks, fixed.

> src/hotspot/share/runtime/handshake.hpp line 147:
> 
>> 145:   bool handshake_suspend();
>> 146:   // Called from the async handshake (the trap)
>> 147:   // to stop a thread from continuing executing when suspended.
> 
> nit typo: s/continuing executing/continuing execution/

Thanks, Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3191

From rehn at openjdk.java.net  Wed Mar 31 11:02:18 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 31 Mar 2021 11:02:18 GMT
Subject: RFR: 8257831: Suspend with handshakes [v2]
In-Reply-To: <xkbt1_7eYWyZFFtBMkAJjFucqtWs2p10Kn0fZ-GhlCc=.227f9c51-7bf8-437d-8577-dfb6bf669eea@github.com>
References: <xv1j0DkGolookgzzyT7w9hz5-mlD0QaeHfqL3b9HJ6I=.c33a0757-1f6e-4a7c-afa4-2d531849d4fc@github.com>
 <a6Fjizolorcan3_uaH8QqfAmw6LqdOwC02DG2Yp6ZNg=.d8ebe170-cdda-42d7-912c-0210f9643da6@github.com>
 <xkbt1_7eYWyZFFtBMkAJjFucqtWs2p10Kn0fZ-GhlCc=.227f9c51-7bf8-437d-8577-dfb6bf669eea@github.com>
Message-ID: <qi3z2rq-Ni_KxWXZYUVfXCm0eJu5wIbhQfYeSVS6ZHU=.2e9ed18f-024b-4531-9f0d-895766931a05@github.com>

On Tue, 30 Mar 2021 21:12:47 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> Hi Robbin,
> 
> this is a great simplification. Excellent work! :)
> 
> Thanks, Richard.

Thanks Richard!

> src/hotspot/share/prims/jvmtiRawMonitor.cpp line 421:
> 
>> 419:     guarantee(jt->thread_state() == _thread_in_native, "invariant");
>> 420:     for (;;) {
>> 421:       if (!SafepointMechanism::should_process(jt)) {
> 
> Potential follow-up enhancement: there's a very similar for(;;) loop in JvmtiRawMonitor::raw_enter(). It looks as if it was possible to merge both loops into just one loop in simple_enter().

Yes!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3191

From rehn at openjdk.java.net  Wed Mar 31 11:11:20 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 31 Mar 2021 11:11:20 GMT
Subject: RFR: 8257831: Suspend with handshakes [v2]
In-Reply-To: <xkbt1_7eYWyZFFtBMkAJjFucqtWs2p10Kn0fZ-GhlCc=.227f9c51-7bf8-437d-8577-dfb6bf669eea@github.com>
References: <xv1j0DkGolookgzzyT7w9hz5-mlD0QaeHfqL3b9HJ6I=.c33a0757-1f6e-4a7c-afa4-2d531849d4fc@github.com>
 <a6Fjizolorcan3_uaH8QqfAmw6LqdOwC02DG2Yp6ZNg=.d8ebe170-cdda-42d7-912c-0210f9643da6@github.com>
 <xkbt1_7eYWyZFFtBMkAJjFucqtWs2p10Kn0fZ-GhlCc=.227f9c51-7bf8-437d-8577-dfb6bf669eea@github.com>
Message-ID: <4w_pkKBQnmhsjg3oo-WDcnezSUM1QWBElso0pHfndaw=.4d034611-580d-423f-9e36-d4d2d0838c93@github.com>

On Mon, 29 Mar 2021 17:23:11 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Robbin Ehn 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 SuspendInHandshake
>>  - 8257831: Suspend with handshake (review baseline)
>
> src/hotspot/share/runtime/handshake.cpp line 492:
> 
>> 490:       }
>> 491:     } else {
>> 492:       return true;
> 
> `true` as return value means that the caller does _not_ need to check again for a safepoint, correct? Maybe this could be added as comment to the method declaration?

Yes, added comment!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3191

From rehn at openjdk.java.net  Wed Mar 31 11:15:25 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 31 Mar 2021 11:15:25 GMT
Subject: RFR: 8257831: Suspend with handshakes [v2]
In-Reply-To: <KtfYSSZ2AUOMh70BMn_2dHQuHHgMTmz4_Lr7ezyFMqU=.5f32dc39-ac56-4773-9dba-162e643123b8@github.com>
References: <xv1j0DkGolookgzzyT7w9hz5-mlD0QaeHfqL3b9HJ6I=.c33a0757-1f6e-4a7c-afa4-2d531849d4fc@github.com>
 <a6Fjizolorcan3_uaH8QqfAmw6LqdOwC02DG2Yp6ZNg=.d8ebe170-cdda-42d7-912c-0210f9643da6@github.com>
 <xkbt1_7eYWyZFFtBMkAJjFucqtWs2p10Kn0fZ-GhlCc=.227f9c51-7bf8-437d-8577-dfb6bf669eea@github.com>
 <PadtsT2KtkBLJc1tqSbJblZjW12VWUtYBet_T5Ocsbo=.e87a04cd-a611-4482-87cb-6592395d2862@github.com>
 <KtfYSSZ2AUOMh70BMn_2dHQuHHgMTmz4_Lr7ezyFMqU=.5f32dc39-ac56-4773-9dba-162e643123b8@github.com>
Message-ID: <Y3894ySgM-PSWklrhbvJRTcUXpvZnWvF5XQ5LpwBSvg=.a72d6f82-9ff9-450b-964b-3990789542b9@github.com>

On Wed, 31 Mar 2021 08:01:27 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> I think this relates to why the PEM was moved from the loop-scope to the sync op case only. That said it isn't clear why we need the HM or PEM.
>
> I guess it should be "... must not execute ~PreserveExceptionMark ..."
> ~PreserveExceptionMark calls _thread->pending_exception() which is an oop and that would be illegal as the vm could be at a safepoint when the async handshake returns.

I don't think we need HM or PEM.
PEM was added if the handshake would execute code that did throw an exception.

Yes, exactly we don't want to be touching "_thread->pending_exception()" during a safepoint.

Updating comment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3191

From rehn at openjdk.java.net  Wed Mar 31 11:22:32 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 31 Mar 2021 11:22:32 GMT
Subject: RFR: 8257831: Suspend with handshakes [v2]
In-Reply-To: <xkbt1_7eYWyZFFtBMkAJjFucqtWs2p10Kn0fZ-GhlCc=.227f9c51-7bf8-437d-8577-dfb6bf669eea@github.com>
References: <xv1j0DkGolookgzzyT7w9hz5-mlD0QaeHfqL3b9HJ6I=.c33a0757-1f6e-4a7c-afa4-2d531849d4fc@github.com>
 <a6Fjizolorcan3_uaH8QqfAmw6LqdOwC02DG2Yp6ZNg=.d8ebe170-cdda-42d7-912c-0210f9643da6@github.com>
 <xkbt1_7eYWyZFFtBMkAJjFucqtWs2p10Kn0fZ-GhlCc=.227f9c51-7bf8-437d-8577-dfb6bf669eea@github.com>
Message-ID: <7gtRPNlSCZjHnknkLT81ZALG8FOYqw19GfHWF3p_yBM=.22900dab-2a4e-4798-ac31-c272cd5c19e8@github.com>

On Tue, 30 Mar 2021 08:20:21 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Robbin Ehn 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 SuspendInHandshake
>>  - 8257831: Suspend with handshake (review baseline)
>
> src/hotspot/share/prims/jvmtiRawMonitor.cpp line 318:
> 
>> 316:   if (self->is_Java_thread()) {
>> 317:     jt = self->as_Java_thread();
>> 318:     while (true) {
> 
> From the PR description:
> 
>> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors.
> 
> I read this section but then forgot about it. So you can skip the following comment.
> 
> Possible follow-up: It could be worth the attempt to make use of the generic state transition classes provided by interface.hpp. Directly I don't see why this wouldn't be feasible and I doubt the [old comment in JvmtiEnv::RawMonitorEnter()](https://github.com/reinrich/jdk/blob/aefc1560b51f0ce96d8f5ce396ba0d2fe08fd650/src/hotspot/share/prims/jvmtiEnv.cpp#L3208-L3214).
> This would make the custom suspend logic here superfluous.
> If ThreadBlockInVM was changed to take a generic callback for unlocking, then this could replace the custom logic in L360-L374.

You are right on, this has been briefly discussed off-line.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3191

From coleenp at openjdk.java.net  Wed Mar 31 13:02:23 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 31 Mar 2021 13:02:23 GMT
Subject: RFR: 8264285: Clean the modification of ccstr JVM flags
In-Reply-To: <zbVfsuLhNzhIneQusCRIO86lU9dRUOuUWMsiR9_TDas=.9c136bfd-81f1-4168-986c-43721178444e@github.com>
References: <zbVfsuLhNzhIneQusCRIO86lU9dRUOuUWMsiR9_TDas=.9c136bfd-81f1-4168-986c-43721178444e@github.com>
Message-ID: <RfhOyilJToqc-vpjYA5jzD8OuQExhCznJ6ByNUEHEUU=.08409c9d-25b7-4fe4-b99b-66828d9acfc0@github.com>

On Mon, 29 Mar 2021 21:35:52 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> There are two versions of JVMFlagAccess::ccstrAtPut() for modifying JVM flags of the ccstr type (i.e., strings).
> 
> - One version requires the caller to free the old value, but some callers don't do that (writeableFlags.cpp).
> - The other version frees the old value on behalf of the caller. However, this version is accessible only via FLAG_SET_XXX macros and is currently unused. So it's unclear whether it actually works.
> 
> We should combine these two versions into a single function, fix problems in the callers, and add test cases. The old value should be freed automatically, because typically the caller isn't interested in the old value.
> 
> Note that the FLAG_SET_XXX macros do not return the old value. Requiring the caller of FLAG_SET_XXX to free the old value would be tedious and error prone.

I had a question but overall nice cleanup!

src/hotspot/share/runtime/flags/debug_globals.hpp line 38:

> 36: // have any MANAGEABLE flags of the ccstr type, but we really need to
> 37: // make sure the implementation is correct (in terms of memory allocation)
> 38: // just in case someone may add such a flag in the future.

Could you have just added a develop flag to the manageable flags instead?

src/hotspot/share/runtime/flags/jvmFlagAccess.cpp line 327:

> 325:   // The callers typically don't care what the old value is.
> 326:   // If the caller really wants to know the old value, read it (and make a copy if necessary)
> 327:   // before calling this API.

good comment!

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3254

From david.holmes at oracle.com  Wed Mar 31 13:59:49 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 31 Mar 2021 23:59:49 +1000
Subject: RFR: 8257831: Suspend with handshakes [v2]
In-Reply-To: <3hnHTIU7h2VZ8ZcubYBQV7L-T8yyoJ1VUdQH5RK8eWE=.afc11483-37d2-4cc6-9177-13c6cb709e88@github.com>
References: <xv1j0DkGolookgzzyT7w9hz5-mlD0QaeHfqL3b9HJ6I=.c33a0757-1f6e-4a7c-afa4-2d531849d4fc@github.com>
 <a6Fjizolorcan3_uaH8QqfAmw6LqdOwC02DG2Yp6ZNg=.d8ebe170-cdda-42d7-912c-0210f9643da6@github.com>
 <lfoWy9GAZC-tp75AqoATcaOOwWhHfoQjHZ236wmhL64=.628619cf-5e45-475b-958e-70dccef9bcb6@github.com>
 <RzUniZabptKFS1qhpsmktmsqmVKML7lGerSDyv723Ro=.fb8300d8-11a8-40b1-b275-dbce9d9c14a5@github.com>
 <3hnHTIU7h2VZ8ZcubYBQV7L-T8yyoJ1VUdQH5RK8eWE=.afc11483-37d2-4cc6-9177-13c6cb709e88@github.com>
Message-ID: <e37c252e-5942-3b5d-1eb0-73a2f7025f70@oracle.com>

On 31/03/2021 8:51 pm, Robbin Ehn wrote:
> On Wed, 31 Mar 2021 02:43:21 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> src/hotspot/os/posix/signals_posix.cpp line 1587:
>>>
>>>> 1585:   // destructor has completed.
>>>> 1586:
>>>> 1587:   if (thread->is_Java_thread() && thread->as_Java_thread()->is_terminated()) {
>>>
>>> We need @dholmes-ora to verify that this version of the code will
>>> still solve the bug he was fixing when he added old L1610.
>>
>> Thanks @dcubed-ojdk - no it won't. The problem is that the signal can hit very late in a thread's termination process, after the JavaThread destructor has executed, so no query of JavaThread state is possible. So we needed something in the Thread state and the SR_lock was a good enough proxy for that. It may be possible to use a different Thread field (perhaps _ParkEvent but encapsulated in a Thread::has_terminated() helper method).
> 
> SR_handler is used for OS-level suspend/resume (not to conflict with this change-set).
> This feature is only used by JFR (AFAIK), and JFR only samples threads on it's ThreadsList.
> This means the JavaThread can never be terminated, hence this code will always pass.

I need to dig up the exact details but from memory the problem we were 
fixing was that the signal was seemingly not being delivered to the 
target thread until it modified its own signal mask sometime during 
thread termination. IIRC JFR may have a target thread on a ThreadList 
and try to suspend it, but the signal may not get delivered, 
consequently JFR will timeout and cancel the suspend request. After that 
the thread can continue on its way and may start to terminate, at which 
point the signal gets delivered and the SR_handler runs.

> If someone else is using OS-level suspend/resume without a ThreadsList, the bug is there is no ThreadsList AFAICT.
> 
> Since ThreadLocalStorage::thread() is cleared last in ~Thread with Thread::clear_thread_current(); may be in the ~Thread destructor.
> So the argument is that would be safe to read stuff from Thread but not JavaThread?

If the SR_handler gets a non-null value from 
Thread::current_or_null_safe() then we know that the signal got 
delivered before we called clear_current_thread() in the Thread 
destructor. We don't exactly where, but we know that it could be after 
the JavaThread destructor and so trying to treat the thread as a 
JavaThread is definitely not safe (hence the way the bug was 
discovered!). We deliberately nulled _SR_lock so that we could query it 
as a termination indicator and we do that while we still have a valid 
osThread. Hence if you see a non-NULL _SR_lock you know you can safely 
interact with the osthread.

> Since the compiler (and CPU) may reorder and optimize away code, so I argue reading from a half destroyed object is not a great idea.

The Thread object itself is not destroyed at this point, only objects 
referred to there-from.

> E.g. Monitor* _SR_lock; is not a volatile pointer; since reading from this memory is UB after destruction, compiler is free to remove or not publish the store to NULL.

It may well be free to do so but that wasn't what we found. Perhaps it 
should have been volatile with a storestore() for good measure.

> So I suggest either to remove this check, since the only user is using a ThreadsList and any other should also be using that too.
> Or call Thread::clear_thread_current() before the JavaThread destructor is called, that way we can be certain that there is no UB.

That would be very fragile IMO as it would require that no code 
executing from the destructors can require access to Thread:current() to 
work. It would certainly take some analysis to determine if it could be 
done that way. (Crash reporting would be affected.)

There is no UB in what we currently do AFAICS.

David
-----

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3191
> 

From dcubed at openjdk.java.net  Wed Mar 31 14:07:20 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 31 Mar 2021 14:07:20 GMT
Subject: RFR: 8257831: Suspend with handshakes [v2]
In-Reply-To: <qECYENgo-noFUVcExYlTP7CBEYajuKMU51JdiI6vPUw=.c19b7a63-49a4-40a4-b04f-1c4e0537078a@github.com>
References: <xv1j0DkGolookgzzyT7w9hz5-mlD0QaeHfqL3b9HJ6I=.c33a0757-1f6e-4a7c-afa4-2d531849d4fc@github.com>
 <a6Fjizolorcan3_uaH8QqfAmw6LqdOwC02DG2Yp6ZNg=.d8ebe170-cdda-42d7-912c-0210f9643da6@github.com>
 <qECYENgo-noFUVcExYlTP7CBEYajuKMU51JdiI6vPUw=.c19b7a63-49a4-40a4-b04f-1c4e0537078a@github.com>
Message-ID: <TAGwCKyiyFiFf-Sf77T__JmMFe59c8jxBpbQl6osB54=.1c27297f-c0df-4174-ad42-f6c7229b9d74@github.com>

On Wed, 31 Mar 2021 03:47:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Robbin Ehn 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 SuspendInHandshake
>>  - 8257831: Suspend with handshake (review baseline)
>
> src/hotspot/share/prims/jvmtiEnv.cpp line 946:
> 
>> 944: // java_thread - pre-checked
>> 945: jvmtiError
>> 946: JvmtiEnv::SuspendThread(JavaThread* java_thread) {
> 
> The comment above this still states:
> 
> // Threads_lock NOT held, java_thread not protected by lock
> 
> but the java_thread is protected by a TLH so we should document that so we know it is always safe to refer to java_thread below.

These `Threads_lock NOT held ...` comments in JVM/TI are a left over
issue from the Thread-SMR project and I think I forgot to file a follow-up
bug to clean those up.

I recommend handling that in a general cleanup issue for all of these
comments in JVM/TI (and possibly elsewhere). Please let me know if I
should go ahead and file that bug.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3191

From dcubed at openjdk.java.net  Wed Mar 31 14:07:21 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 31 Mar 2021 14:07:21 GMT
Subject: RFR: 8257831: Suspend with handshakes [v2]
In-Reply-To: <m4Pevdd5jNKLfOij_iJBbsHvrM0dEJ0E7gWQd6vCj54=.116f3703-300c-46e3-98e7-98e045d74cb5@github.com>
References: <xv1j0DkGolookgzzyT7w9hz5-mlD0QaeHfqL3b9HJ6I=.c33a0757-1f6e-4a7c-afa4-2d531849d4fc@github.com>
 <a6Fjizolorcan3_uaH8QqfAmw6LqdOwC02DG2Yp6ZNg=.d8ebe170-cdda-42d7-912c-0210f9643da6@github.com>
 <qECYENgo-noFUVcExYlTP7CBEYajuKMU51JdiI6vPUw=.c19b7a63-49a4-40a4-b04f-1c4e0537078a@github.com>
 <zh-q9GNGDppcpYqr8kZGYR5F4Lzkq8wO-hYkDMEnqkc=.08ef3008-eee0-4379-96df-d3163a36e032@github.com>
 <L_bT7G_UmsPKQfgxAoUujZZYg3wFqBeKWXPDIdXL-7c=.bb20229f-1c6e-48d0-80a9-30d6444bdbc2@github.com>
 <m4Pevdd5jNKLfOij_iJBbsHvrM0dEJ0E7gWQd6vCj54=.116f3703-300c-46e3-98e7-98e045d74cb5@github.com>
Message-ID: <H0Y_ACIQmnlzsspT2fr8XNleKxxleh9RdIgPUhOjRhs=.5634f9b6-52ac-4399-b253-730476ee67a3@github.com>

On Wed, 31 Mar 2021 10:22:28 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> My comment was about JVMTI_ERROR_THREAD_NOT_ALIVE
>
> Sure. I agree with your comment.

It depends on how late we can call into an event handler during the
JavaThread exit code path. Is it possible to post an event on a thread
that has passed the `terminated` point in JavaThread::exit()?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3191

From rehn at openjdk.java.net  Wed Mar 31 14:35:32 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 31 Mar 2021 14:35:32 GMT
Subject: RFR: 8257831: Suspend with handshakes [v2]
In-Reply-To: <3hnHTIU7h2VZ8ZcubYBQV7L-T8yyoJ1VUdQH5RK8eWE=.afc11483-37d2-4cc6-9177-13c6cb709e88@github.com>
References: <xv1j0DkGolookgzzyT7w9hz5-mlD0QaeHfqL3b9HJ6I=.c33a0757-1f6e-4a7c-afa4-2d531849d4fc@github.com>
 <a6Fjizolorcan3_uaH8QqfAmw6LqdOwC02DG2Yp6ZNg=.d8ebe170-cdda-42d7-912c-0210f9643da6@github.com>
 <lfoWy9GAZC-tp75AqoATcaOOwWhHfoQjHZ236wmhL64=.628619cf-5e45-475b-958e-70dccef9bcb6@github.com>
 <RzUniZabptKFS1qhpsmktmsqmVKML7lGerSDyv723Ro=.fb8300d8-11a8-40b1-b275-dbce9d9c14a5@github.com>
 <3hnHTIU7h2VZ8ZcubYBQV7L-T8yyoJ1VUdQH5RK8eWE=.afc11483-37d2-4cc6-9177-13c6cb709e88@github.com>
Message-ID: <REwQNt8SR7DMqwaQJ4b2yNza607drE92BFvwRmpT76o=.c0f8885e-5394-4aca-ab8f-7edc11589f6a@github.com>

On Wed, 31 Mar 2021 10:48:11 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Thanks @dcubed-ojdk - no it won't. The problem is that the signal can hit very late in a thread's termination process, after the JavaThread destructor has executed, so no query of JavaThread state is possible. So we needed something in the Thread state and the SR_lock was a good enough proxy for that. It may be possible to use a different Thread field (perhaps _ParkEvent but encapsulated in a Thread::has_terminated() helper method).
>
> SR_handler is used for OS-level suspend/resume (not to conflict with this change-set).
> This feature is only used by JFR (AFAIK), and JFR only samples threads on it's ThreadsList.
> This means the JavaThread can never be terminated, hence this code will always pass.
> 
> If someone else is using OS-level suspend/resume without a ThreadsList, the bug is there is no ThreadsList AFAICT.
> 
> Since ThreadLocalStorage::thread() is cleared last in ~Thread with Thread::clear_thread_current(); may be in the ~Thread destructor.
> So the argument is that would be safe to read stuff from Thread but not JavaThread?
> Since the compiler (and CPU) may reorder and optimize away code, so I argue reading from a half destroyed object is not a great idea.
> E.g. Monitor* _SR_lock; is not a volatile pointer; since reading from this memory is UB after destruction, compiler is free to remove or not publish the store to NULL.
> 
> So I suggest either to remove this check, since the only user is using a ThreadsList and any other should also be using that too.
> Or call Thread::clear_thread_current() before the JavaThread destructor is called, that way we can be certain that there is no UB.

I got some offline input from David, there seem to be an issue with signal being delivered after the ThreadsListHandle destructor. If that is the case a ThreadsList doesn't help here.

So I suggested we keep this out of this change-set and just take another suitable field to mirror what we have today.

`ParkEvent * _ParkEvent;` ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3191

From dfuchs at openjdk.java.net  Wed Mar 31 15:35:53 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 31 Mar 2021 15:35:53 GMT
Subject: RFR: 8264124: Update MXBean specification and implementation to
 extend mapping of CompositeType to records [v3]
In-Reply-To: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com>
References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com>
Message-ID: <2mt02-hwVOJDUEygnx0n3fs5qRu_cRXdqsrSPwyO4Wg=.d64c3751-290f-4506-9ba0-d5c7fc325d59@github.com>

> This RFE proposes to extend the MXBean framework to define a mapping to records.
> 
> The MXBean framework already defines a mapping of `CompositeType` to plain java objects. Records are a natural representation of CompositeTypes. A record can be easily reconstructed from a `CompositeData` through the record canonical constructor. A clear advantage of records over plain java objects is that the canonical constructor will not need to be annotated in order to map composite data property names to constructor parameter names.
> 
> With this RFE, here is an example comparing coding a composite type `NamedNumber` that consists of an `int` and a `String`, using records and using a plain java class. In both case, the `CompositeType` looks like this:
> 
> CompositeType(
>     "NamedNumber",                      // typeName
>     "NamedNumber",                      // description
>     new String[] {"number", "name"},    // itemNames
>     new String[] {"number", "name"},    // itemDescriptions
>     new OpenType[] {SimpleType.INTEGER,
>                     SimpleType.STRING}  // itemTypes
> );
> 
> The plain Java class needs a public constructor annotated with `@ConstructorParameters` annotation:
> 
> public class NamedNumber {
>     public int getNumber() {return number;}
>     public String getName() {return name;}
>     @ConstructorParameters({"number", "name"})
>     public NamedNumber(int number, String name) {
>         this.number = number;
>         this.name = name;
>     }
>     private final int number;
>     private final String name;
> }
> 
> And the equivalent with a record class: 
> 
> public record NamedNumber(int number, String name) {}

Daniel Fuchs 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 seven additional commits since the last revision:

 - Merge branch 'master' into mxbeans-8264124
 - Minor tweaks. Improved test.
 - Merge branch 'master' into mxbeans-8264124
 - Integrated review feedback. Updated the section for Mapping to records.
 - Integrated review feedback. Added a section for Mapping to records.
 - Fixed typo. Moved example with record after example with from method to respect the logical order of precedence.
 - 8264124: Update MXBean specification and implementation to extend mapping of CompositeType to records

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3201/files
  - new: https://git.openjdk.java.net/jdk/pull/3201/files/1c3292ce..59965133

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3201&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3201&range=01-02

  Stats: 15001 lines in 575 files changed: 11278 ins; 1193 del; 2530 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3201.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3201/head:pull/3201

PR: https://git.openjdk.java.net/jdk/pull/3201

From dfuchs at openjdk.java.net  Wed Mar 31 15:41:19 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 31 Mar 2021 15:41:19 GMT
Subject: RFR: 8264124: Update MXBean specification and implementation to
 extend mapping of CompositeType to records [v2]
In-Reply-To: <UvPmdS6Nn0PhWonjYS_YTnhwc8SXhElST7Y3f844WNM=.d1c7e494-97c8-44ad-ac2b-469121ef54f9@github.com>
References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com>
 <cAwbOBwhGERyBUbreMVPVsCabpDTPi3oqSDQ53FTVlk=.70a98535-36bb-4483-b461-5de840998d06@github.com>
 <C0e13BnsgJfRQvS86QICp_CwhR4PIaC498P5FnjazjE=.4e8467e1-8b8b-4899-bf22-470328d31007@github.com>
 <0RxhjEDdg8ZZRNLjbknHs_sa71hn6ax3LAtv_-pZGqY=.a3e1631a-4280-4b2e-95c0-794785b9d165@github.com>
 <UvPmdS6Nn0PhWonjYS_YTnhwc8SXhElST7Y3f844WNM=.d1c7e494-97c8-44ad-ac2b-469121ef54f9@github.com>
Message-ID: <GSkZtrq04srGDZDlPzAKPaD_-MpoxBKfsnv8DMFkeSg=.ac9d73de-2c91-471a-9307-d7ea7a492b1e@github.com>

On Mon, 29 Mar 2021 22:12:01 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> You add record in "Mappings for other types".  I think it deserves a separate section "Mappings for record classes" (maybe after primitive types).   It's useful to add a row for record in the summary table above "Mappings for primitive types"
>
> Link added. With respect to adding a section for records, it's a bit difficult to separate that from the "Mapping for other types" without a lot of duplication. I can add a row in the summary table, and then add a new section "Mapping for records" just before "Mapping for other types", that just gives a brief overview and refers to the mapping for other types below. 
> 
> Something like this - what do you think?
> 
>     <h3 id="records">Mappings for Records</h3>
> 
>     <p>A {@linkplain Record record} <em>R</em> whose {@linkplain
>       Class#getRecordComponents() components} are
>       all convertible to open types, is itself convertible to a
>       {@link CompositeType} as follows.
>       The type name of this {@code CompositeType}
>       is determined by the same <a href="#type-names">type name rules</a>
>       defined by the <a href="#composite-map">Mapping for other types</a>
>       below. Its getters are the accessors for the {@linkplain
>       RecordComponent record components}, and the record is reconstructed
>       using its canonical constructor, without needing any annotation.</p>
> 
>     <p>A record may also expose additional non-canonical constructors, which
>       can be used to reconstruct the record if the composite data does
>       not exactly contain all the components expected by the
>       canonical constructor. However, in order to be taken into account
>       by the MXBean framework, such non-canonical constructors
>       need to be annotated with either the {@link ConstructorParameters
>       &#64;javax.management.ConstructorParameters} or
>      {@code @java.beans.ConstructorProperties} annotation.</p>
> 
>     <p>The complete rules for the mapping are detailed as part
>       of the <a href="#composite-map">Mapping for other types</a>
>       below.</p>
> 
>     <h3 id="composite-map">Mappings for other types</h3>
> 
>     <p>Given a record, or a Java class or interface <em>J</em> that does not match the other
>       rules in the table above, the MXBean framework will attempt to map
>       it to a {@link CompositeType} as follows.  [....]

Hi Mandy, I have updated the PR with a revised version of the text above. Is that more in line what you had in mind?

best regards,
-- daniel

-------------

PR: https://git.openjdk.java.net/jdk/pull/3201

From kevinw at openjdk.java.net  Wed Mar 31 15:45:09 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Wed, 31 Mar 2021 15:45:09 GMT
Subject: RFR: 8264484: Replace uses of StringBuffer with StringBuilder in
 jdk.hotspot.agent
In-Reply-To: <JG1dWhnHiime4ikiR6s-b6GTe7G7RpG_EI3W46Z1XL4=.66f74e8d-5dcc-4263-96c9-9d4e0e7b1822@github.com>
References: <JG1dWhnHiime4ikiR6s-b6GTe7G7RpG_EI3W46Z1XL4=.66f74e8d-5dcc-4263-96c9-9d4e0e7b1822@github.com>
Message-ID: <DeRueynB--Kb-z9Jgr37XRw-MzOmoYu3HaVHSQtmR6k=.c27d0bf7-3280-4144-8ec0-8383d2444a67@github.com>

On Tue, 30 Mar 2021 18:58:24 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Found by IntelliJ IDEA inspection `Java | Java language level migration aids | Java 5 | 'StringBuffer' may be 'StringBuilder'`
> As suggested in https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created separate PR for module `jdk.hotspot.agent`
> Similar cleanups in the past: https://bugs.openjdk.java.net/browse/JDK-8041679 https://bugs.openjdk.java.net/browse/JDK-8264029

Changes requested by kevinw (Committer).

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java line 887:

> 885:    protected String genMultPCHref(String pcs) {
> 886:       String buf = genBaseHref() + "pc_multiple=" + pcs;
> 887:       return buf;

This is like VMVersionMismatchException.java above, where as it is reduced to two lines, we may as well reduce it to one line with:
return genBaseHref() + ..etc... 

With these two minor changes, I think this looks good.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3275

From github.com+741251+turbanoff at openjdk.java.net  Wed Mar 31 16:11:42 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 31 Mar 2021 16:11:42 GMT
Subject: RFR: 8264484: Replace uses of StringBuffer with StringBuilder in
 jdk.hotspot.agent [v2]
In-Reply-To: <JG1dWhnHiime4ikiR6s-b6GTe7G7RpG_EI3W46Z1XL4=.66f74e8d-5dcc-4263-96c9-9d4e0e7b1822@github.com>
References: <JG1dWhnHiime4ikiR6s-b6GTe7G7RpG_EI3W46Z1XL4=.66f74e8d-5dcc-4263-96c9-9d4e0e7b1822@github.com>
Message-ID: <Pll5Uy6mFIsgUb8Zx_ZlVkOq1CB1oORBClyU_WSFlqg=.a1d00620-7205-4ac6-9a1f-63a3e59deedf@github.com>

> Found by IntelliJ IDEA inspection `Java | Java language level migration aids | Java 5 | 'StringBuffer' may be 'StringBuilder'`
> As suggested in https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created separate PR for module `jdk.hotspot.agent`
> Similar cleanups in the past: https://bugs.openjdk.java.net/browse/JDK-8041679 https://bugs.openjdk.java.net/browse/JDK-8264029

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8264484: Replace uses of StringBuffer with StringBuilder in jdk.hotspot.agent
  
  remove redundant local variables as suggested by reviewers

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3275/files
  - new: https://git.openjdk.java.net/jdk/pull/3275/files/cd4fbf1d..75e4f6b0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3275&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3275&range=00-01

  Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3275.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3275/head:pull/3275

PR: https://git.openjdk.java.net/jdk/pull/3275

From github.com+741251+turbanoff at openjdk.java.net  Wed Mar 31 16:11:44 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 31 Mar 2021 16:11:44 GMT
Subject: RFR: 8264484: Replace uses of StringBuffer with StringBuilder in
 jdk.hotspot.agent [v2]
In-Reply-To: <yPTHAxsTcu2Ox_8KC1o8O9KVwfPLB9yN-6_db5UDyaQ=.ad351027-42ea-466b-a8d7-f18b20fc54bd@github.com>
References: <JG1dWhnHiime4ikiR6s-b6GTe7G7RpG_EI3W46Z1XL4=.66f74e8d-5dcc-4263-96c9-9d4e0e7b1822@github.com>
 <yPTHAxsTcu2Ox_8KC1o8O9KVwfPLB9yN-6_db5UDyaQ=.ad351027-42ea-466b-a8d7-f18b20fc54bd@github.com>
Message-ID: <fF6SI-74_aOhWSCQGuS-qIPLhrwXRb4p1dKlxE3boQ0=.a6676669-d82e-49cd-a58c-f51610237d2c@github.com>

On Wed, 31 Mar 2021 08:23:24 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8264484: Replace uses of StringBuffer with StringBuilder in jdk.hotspot.agent
>>   
>>   remove redundant local variables as suggested by reviewers
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VMVersionMismatchException.java line 40:
> 
>> 38:                 ". Target VM is " + targetVersion;
>> 39:         return msg;
>> 40:     }
> 
> Why don't you return `msg` directly? I think `msg` is not needed.
> I saw similar codes in other places.

inlined

-------------

PR: https://git.openjdk.java.net/jdk/pull/3275

From github.com+741251+turbanoff at openjdk.java.net  Wed Mar 31 16:11:45 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 31 Mar 2021 16:11:45 GMT
Subject: RFR: 8264484: Replace uses of StringBuffer with StringBuilder in
 jdk.hotspot.agent [v2]
In-Reply-To: <DeRueynB--Kb-z9Jgr37XRw-MzOmoYu3HaVHSQtmR6k=.c27d0bf7-3280-4144-8ec0-8383d2444a67@github.com>
References: <JG1dWhnHiime4ikiR6s-b6GTe7G7RpG_EI3W46Z1XL4=.66f74e8d-5dcc-4263-96c9-9d4e0e7b1822@github.com>
 <DeRueynB--Kb-z9Jgr37XRw-MzOmoYu3HaVHSQtmR6k=.c27d0bf7-3280-4144-8ec0-8383d2444a67@github.com>
Message-ID: <K-112sid1keEJgj0lZfu5WFRhGfDC_gPzmTOt9gE6oA=.5003a0be-61b7-484f-a1a2-3c23234f090b@github.com>

On Wed, 31 Mar 2021 15:41:42 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8264484: Replace uses of StringBuffer with StringBuilder in jdk.hotspot.agent
>>   
>>   remove redundant local variables as suggested by reviewers
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java line 887:
> 
>> 885:    protected String genMultPCHref(String pcs) {
>> 886:       String buf = genBaseHref() + "pc_multiple=" + pcs;
>> 887:       return buf;
> 
> This is like VMVersionMismatchException.java above, where as it is reduced to two lines, we may as well reduce it to one line with:
> return genBaseHref() + ..etc... 
> 
> With these two minor changes, I think this looks good.

done

-------------

PR: https://git.openjdk.java.net/jdk/pull/3275

From cjplummer at openjdk.java.net  Wed Mar 31 16:33:11 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 31 Mar 2021 16:33:11 GMT
Subject: RFR: 8264396: Use the blessed modifier order in
 jdk.internal.jvmstat [v2]
In-Reply-To: <G-gSp_dmxlvF4yzZNu3CZ6vNtBoPCbNhKvyeLYXmxjM=.578aff42-9ba7-4719-8450-3cf75e56fe7b@github.com>
References: <rrSdxlrv3z-oVhRNkDd5XTcgCl3MfGMh2pUxHl2uCTc=.5790a3c6-9b78-4e96-bb45-bace638ebae8@github.com>
 <G-gSp_dmxlvF4yzZNu3CZ6vNtBoPCbNhKvyeLYXmxjM=.578aff42-9ba7-4719-8450-3cf75e56fe7b@github.com>
Message-ID: <inyhj8jZk_LBYXTpcyKs4aUI76eOXKqyYwN7iI2X0vo=.3ba9b4c6-7a2c-4926-b1a8-f4568af54d12@github.com>

On Tue, 30 Mar 2021 20:37:45 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

>> 8264396: Use the blessed modifier order in jdk.internal.jvmstat
>
> Alex Blewitt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyright dates

Marked as reviewed by cjplummer (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3252

From kevinw at openjdk.java.net  Wed Mar 31 16:38:26 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Wed, 31 Mar 2021 16:38:26 GMT
Subject: RFR: 8264484: Replace uses of StringBuffer with StringBuilder in
 jdk.hotspot.agent [v2]
In-Reply-To: <K-112sid1keEJgj0lZfu5WFRhGfDC_gPzmTOt9gE6oA=.5003a0be-61b7-484f-a1a2-3c23234f090b@github.com>
References: <JG1dWhnHiime4ikiR6s-b6GTe7G7RpG_EI3W46Z1XL4=.66f74e8d-5dcc-4263-96c9-9d4e0e7b1822@github.com>
 <DeRueynB--Kb-z9Jgr37XRw-MzOmoYu3HaVHSQtmR6k=.c27d0bf7-3280-4144-8ec0-8383d2444a67@github.com>
 <K-112sid1keEJgj0lZfu5WFRhGfDC_gPzmTOt9gE6oA=.5003a0be-61b7-484f-a1a2-3c23234f090b@github.com>
Message-ID: <-7aC0wLiBIh_dh9mpnErYePb71ymzbJj1PWSUFUmHrI=.dff49eee-b9f5-4d9f-853a-23d6785ce305@github.com>

On Wed, 31 Mar 2021 16:07:56 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java line 887:
>> 
>>> 885:    protected String genMultPCHref(String pcs) {
>>> 886:       String buf = genBaseHref() + "pc_multiple=" + pcs;
>>> 887:       return buf;
>> 
>> This is like VMVersionMismatchException.java above, where as it is reduced to two lines, we may as well reduce it to one line with:
>> return genBaseHref() + ..etc... 
>> 
>> With these two minor changes, I think this looks good.
>
> done

Thanks - just a nit, looks like an extra space means "return genBaseHref() ..etc.." is not aligned.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3275

From github.com+76791+alblue at openjdk.java.net  Wed Mar 31 16:45:19 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Wed, 31 Mar 2021 16:45:19 GMT
Subject: Integrated: 8264396: Use the blessed modifier order in
 jdk.internal.jvmstat
In-Reply-To: <rrSdxlrv3z-oVhRNkDd5XTcgCl3MfGMh2pUxHl2uCTc=.5790a3c6-9b78-4e96-bb45-bace638ebae8@github.com>
References: <rrSdxlrv3z-oVhRNkDd5XTcgCl3MfGMh2pUxHl2uCTc=.5790a3c6-9b78-4e96-bb45-bace638ebae8@github.com>
Message-ID: <f0Ng95TsI_2sJL11vXmh3hhDVXJD68MQqRyd8TlhoqU=.92816f1f-6d5b-49ee-b58e-4509701c7ce6@github.com>

On Mon, 29 Mar 2021 21:00:20 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> 8264396: Use the blessed modifier order in jdk.internal.jvmstat

This pull request has now been integrated.

Changeset: f43d14a2
Author:    Alex Blewitt <alex.blewitt at gmail.com>
Committer: Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f43d14a2
Stats:     83 lines in 5 files changed: 0 ins; 0 del; 83 mod

8264396: Use the blessed modifier order in jdk.internal.jvmstat

Reviewed-by: cjplummer, kevinw, shade

-------------

PR: https://git.openjdk.java.net/jdk/pull/3252

From github.com+741251+turbanoff at openjdk.java.net  Wed Mar 31 17:45:33 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 31 Mar 2021 17:45:33 GMT
Subject: RFR: 8264484: Replace uses of StringBuffer with StringBuilder in
 jdk.hotspot.agent [v3]
In-Reply-To: <JG1dWhnHiime4ikiR6s-b6GTe7G7RpG_EI3W46Z1XL4=.66f74e8d-5dcc-4263-96c9-9d4e0e7b1822@github.com>
References: <JG1dWhnHiime4ikiR6s-b6GTe7G7RpG_EI3W46Z1XL4=.66f74e8d-5dcc-4263-96c9-9d4e0e7b1822@github.com>
Message-ID: <aXMLZK9LuflkQUBPQoPtwoM-jBBdEmBM_hXeBmEKBo4=.7caee984-3afd-4798-a2ee-f0044bb17ed5@github.com>

> Found by IntelliJ IDEA inspection `Java | Java language level migration aids | Java 5 | 'StringBuffer' may be 'StringBuilder'`
> As suggested in https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created separate PR for module `jdk.hotspot.agent`
> Similar cleanups in the past: https://bugs.openjdk.java.net/browse/JDK-8041679 https://bugs.openjdk.java.net/browse/JDK-8264029

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8264484: Replace uses of StringBuffer with StringBuilder in jdk.hotspot.agent
  
  fix indentation

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3275/files
  - new: https://git.openjdk.java.net/jdk/pull/3275/files/75e4f6b0..32274cbc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3275&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3275&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3275.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3275/head:pull/3275

PR: https://git.openjdk.java.net/jdk/pull/3275

From github.com+741251+turbanoff at openjdk.java.net  Wed Mar 31 17:45:34 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 31 Mar 2021 17:45:34 GMT
Subject: RFR: 8264484: Replace uses of StringBuffer with StringBuilder in
 jdk.hotspot.agent [v3]
In-Reply-To: <-7aC0wLiBIh_dh9mpnErYePb71ymzbJj1PWSUFUmHrI=.dff49eee-b9f5-4d9f-853a-23d6785ce305@github.com>
References: <JG1dWhnHiime4ikiR6s-b6GTe7G7RpG_EI3W46Z1XL4=.66f74e8d-5dcc-4263-96c9-9d4e0e7b1822@github.com>
 <DeRueynB--Kb-z9Jgr37XRw-MzOmoYu3HaVHSQtmR6k=.c27d0bf7-3280-4144-8ec0-8383d2444a67@github.com>
 <K-112sid1keEJgj0lZfu5WFRhGfDC_gPzmTOt9gE6oA=.5003a0be-61b7-484f-a1a2-3c23234f090b@github.com>
 <-7aC0wLiBIh_dh9mpnErYePb71ymzbJj1PWSUFUmHrI=.dff49eee-b9f5-4d9f-853a-23d6785ce305@github.com>
Message-ID: <6rlDh3t9B8-JQ-iGHnKBlbpql9vQQ0cf3laHhoCFiwE=.2a732d62-6763-4dc0-9f7d-37228cb0ca71@github.com>

On Wed, 31 Mar 2021 16:35:32 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> done
>
> Thanks - just a nit, looks like an extra space means "return genBaseHref() ..etc.." is not aligned.

fixed

-------------

PR: https://git.openjdk.java.net/jdk/pull/3275

From dfuchs at openjdk.java.net  Wed Mar 31 17:46:40 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 31 Mar 2021 17:46:40 GMT
Subject: RFR: 8264124: Update MXBean specification and implementation to
 extend mapping of CompositeType to records [v4]
In-Reply-To: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com>
References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com>
Message-ID: <wSzqKPPpAOUo7BlRwb1YQzQlEu1WoeiqVm1Yvh2uTZ0=.a326fe3d-a74a-46fe-b3be-c6d33e79a93a@github.com>

> This RFE proposes to extend the MXBean framework to define a mapping to records.
> 
> The MXBean framework already defines a mapping of `CompositeType` to plain java objects. Records are a natural representation of CompositeTypes. A record can be easily reconstructed from a `CompositeData` through the record canonical constructor. A clear advantage of records over plain java objects is that the canonical constructor will not need to be annotated in order to map composite data property names to constructor parameter names.
> 
> With this RFE, here is an example comparing coding a composite type `NamedNumber` that consists of an `int` and a `String`, using records and using a plain java class. In both case, the `CompositeType` looks like this:
> 
> CompositeType(
>     "NamedNumber",                      // typeName
>     "NamedNumber",                      // description
>     new String[] {"number", "name"},    // itemNames
>     new String[] {"number", "name"},    // itemDescriptions
>     new OpenType[] {SimpleType.INTEGER,
>                     SimpleType.STRING}  // itemTypes
> );
> 
> The plain Java class needs a public constructor annotated with `@ConstructorParameters` annotation:
> 
> public class NamedNumber {
>     public int getNumber() {return number;}
>     public String getName() {return name;}
>     @ConstructorParameters({"number", "name"})
>     public NamedNumber(int number, String name) {
>         this.number = number;
>         this.name = name;
>     }
>     private final int number;
>     private final String name;
> }
> 
> And the equivalent with a record class: 
> 
> public record NamedNumber(int number, String name) {}

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Moved mapping for records just before Mapping for MXBean interface; Improved test.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3201/files
  - new: https://git.openjdk.java.net/jdk/pull/3201/files/59965133..7d478dec

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3201&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3201&range=02-03

  Stats: 127 lines in 2 files changed: 81 ins; 44 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3201.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3201/head:pull/3201

PR: https://git.openjdk.java.net/jdk/pull/3201

From kevinw at openjdk.java.net  Wed Mar 31 17:50:09 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Wed, 31 Mar 2021 17:50:09 GMT
Subject: RFR: 8264484: Replace uses of StringBuffer with StringBuilder in
 jdk.hotspot.agent [v3]
In-Reply-To: <DeRueynB--Kb-z9Jgr37XRw-MzOmoYu3HaVHSQtmR6k=.c27d0bf7-3280-4144-8ec0-8383d2444a67@github.com>
References: <JG1dWhnHiime4ikiR6s-b6GTe7G7RpG_EI3W46Z1XL4=.66f74e8d-5dcc-4263-96c9-9d4e0e7b1822@github.com>
 <DeRueynB--Kb-z9Jgr37XRw-MzOmoYu3HaVHSQtmR6k=.c27d0bf7-3280-4144-8ec0-8383d2444a67@github.com>
Message-ID: <w89TnZoj5O-9FFqtamEJ-K6jhujOd8BAL6Dn5xpJX8U=.b8595a36-36e7-4704-8291-a111303017c1@github.com>

On Wed, 31 Mar 2021 15:42:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8264484: Replace uses of StringBuffer with StringBuilder in jdk.hotspot.agent
>>   
>>   fix indentation
>
> Changes requested by kevinw (Committer).

Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3275

From kevinw at openjdk.java.net  Wed Mar 31 17:50:08 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Wed, 31 Mar 2021 17:50:08 GMT
Subject: RFR: 8264484: Replace uses of StringBuffer with StringBuilder in
 jdk.hotspot.agent [v3]
In-Reply-To: <aXMLZK9LuflkQUBPQoPtwoM-jBBdEmBM_hXeBmEKBo4=.7caee984-3afd-4798-a2ee-f0044bb17ed5@github.com>
References: <JG1dWhnHiime4ikiR6s-b6GTe7G7RpG_EI3W46Z1XL4=.66f74e8d-5dcc-4263-96c9-9d4e0e7b1822@github.com>
 <aXMLZK9LuflkQUBPQoPtwoM-jBBdEmBM_hXeBmEKBo4=.7caee984-3afd-4798-a2ee-f0044bb17ed5@github.com>
Message-ID: <EPePNsBOZIZGckhtPRmHDgAcjz64tq4RilgxcI9mYpk=.d63f5821-051f-4876-9d82-ea6b7e28045b@github.com>

On Wed, 31 Mar 2021 17:45:33 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> Found by IntelliJ IDEA inspection `Java | Java language level migration aids | Java 5 | 'StringBuffer' may be 'StringBuilder'`
>> As suggested in https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created separate PR for module `jdk.hotspot.agent`
>> Similar cleanups in the past: https://bugs.openjdk.java.net/browse/JDK-8041679 https://bugs.openjdk.java.net/browse/JDK-8264029
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8264484: Replace uses of StringBuffer with StringBuilder in jdk.hotspot.agent
>   
>   fix indentation

Marked as reviewed by kevinw (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3275

From mchung at openjdk.java.net  Wed Mar 31 18:35:16 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 31 Mar 2021 18:35:16 GMT
Subject: RFR: 8264124: Update MXBean specification and implementation to
 extend mapping of CompositeType to records [v2]
In-Reply-To: <GSkZtrq04srGDZDlPzAKPaD_-MpoxBKfsnv8DMFkeSg=.ac9d73de-2c91-471a-9307-d7ea7a492b1e@github.com>
References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com>
 <cAwbOBwhGERyBUbreMVPVsCabpDTPi3oqSDQ53FTVlk=.70a98535-36bb-4483-b461-5de840998d06@github.com>
 <C0e13BnsgJfRQvS86QICp_CwhR4PIaC498P5FnjazjE=.4e8467e1-8b8b-4899-bf22-470328d31007@github.com>
 <0RxhjEDdg8ZZRNLjbknHs_sa71hn6ax3LAtv_-pZGqY=.a3e1631a-4280-4b2e-95c0-794785b9d165@github.com>
 <UvPmdS6Nn0PhWonjYS_YTnhwc8SXhElST7Y3f844WNM=.d1c7e494-97c8-44ad-ac2b-469121ef54f9@github.com>
 <GSkZtrq04srGDZDlPzAKPaD_-MpoxBKfsnv8DMFkeSg=.ac9d73de-2c91-471a-9307-d7ea7a492b1e@github.com>
Message-ID: <6QvyGXdDKhrOjFZ0GuVsiig5fp5Mo1cCjuI3UvshX20=.dc5fa768-f6e7-4066-a51c-8c21b51b531b@github.com>

On Wed, 31 Mar 2021 15:38:22 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Link added. With respect to adding a section for records, it's a bit difficult to separate that from the "Mapping for other types" without a lot of duplication. I can add a row in the summary table, and then add a new section "Mapping for records" just before "Mapping for other types", that just gives a brief overview and refers to the mapping for other types below. 
>> 
>> Something like this - what do you think?
>> 
>>     <h3 id="records">Mappings for Records</h3>
>> 
>>     <p>A {@linkplain Record record} <em>R</em> whose {@linkplain
>>       Class#getRecordComponents() components} are
>>       all convertible to open types, is itself convertible to a
>>       {@link CompositeType} as follows.
>>       The type name of this {@code CompositeType}
>>       is determined by the same <a href="#type-names">type name rules</a>
>>       defined by the <a href="#composite-map">Mapping for other types</a>
>>       below. Its getters are the accessors for the {@linkplain
>>       RecordComponent record components}, and the record is reconstructed
>>       using its canonical constructor, without needing any annotation.</p>
>> 
>>     <p>A record may also expose additional non-canonical constructors, which
>>       can be used to reconstruct the record if the composite data does
>>       not exactly contain all the components expected by the
>>       canonical constructor. However, in order to be taken into account
>>       by the MXBean framework, such non-canonical constructors
>>       need to be annotated with either the {@link ConstructorParameters
>>       &#64;javax.management.ConstructorParameters} or
>>      {@code @java.beans.ConstructorProperties} annotation.</p>
>> 
>>     <p>The complete rules for the mapping are detailed as part
>>       of the <a href="#composite-map">Mapping for other types</a>
>>       below.</p>
>> 
>>     <h3 id="composite-map">Mappings for other types</h3>
>> 
>>     <p>Given a record, or a Java class or interface <em>J</em> that does not match the other
>>       rules in the table above, the MXBean framework will attempt to map
>>       it to a {@link CompositeType} as follows.  [....]
>
> Hi Mandy, I have updated the PR with a revised version of the text above. Is that more in line what you had in mind?
> 
> best regards,
> -- daniel

This looks better.  I like a separate mapping section for records since the mapping rules are straight-forward.   The complexity comes if we want to support a record to implement `CompositeDataView` that allows a type to support more flexible conversion to `CompositeData` which is why you add records in the "Mappings for other types".   I am wondering if we really want to support records to implement `CompositeDataView` but we may want to avoid such a special case.

I suggest add subsections in "Mappings for other types":   There are two mapping rules: (1) _opentype(J)_ maps `J` to `CompositeType` (2) _opendata(J)_ maps `J` to `CompositeData`.   _opentype(J)_ for record class does not need to refer to other types.   The common cases for _opendata(J)_ for record class is using the canonical constructors.   The other less common cases like using non-canonical constructors and `CompositeDataView` can state that it follows the same rules as specified for other types.   "Mappings for other types" does not need any change for records.   

"Reconstructing an instance of Java type J from a CompositeData" section should be renamed to "Reconstructing an instance of Java type or record class J from a CompositeData"

Here is a minor tweaking on "Mappings for Records"

A record is convertible to a CompositeType if and only if all its components are 
convertible to open types. Otherwise, it is not convertible.

A record class is converted to a CompositeType with one item for every record component as follows.
- The type name of this CompositeType is determined by the type name rules detailed below. 
- Each record component of type T, the item in the CompositeType has the same name 
  as the record component and of type opentype(T).

The mapping from an instance of a record class to a CompositeData corresponding to 
the CompositeType is the same as specified as for other types (add a link).

A record is reconstructed from a CompositeData using its canonical constructor. 
The canonical constructor doesn't require the presence of @javax.management.ConstructorParameters 
or @java.beans.ConstructorProperties annotations. If these annotations are present on
the canonical constructor, they will be ignored.

If the CompositeData from which the record is reconstructed doesn't contain all the record components, 
the MXBean framework will attempt to reconstruct the record in the same way as specified for 
other types (add a link).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3201

From iklam at openjdk.java.net  Wed Mar 31 19:01:48 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 31 Mar 2021 19:01:48 GMT
Subject: RFR: 8264285: Clean the modification of ccstr JVM flags [v2]
In-Reply-To: <zbVfsuLhNzhIneQusCRIO86lU9dRUOuUWMsiR9_TDas=.9c136bfd-81f1-4168-986c-43721178444e@github.com>
References: <zbVfsuLhNzhIneQusCRIO86lU9dRUOuUWMsiR9_TDas=.9c136bfd-81f1-4168-986c-43721178444e@github.com>
Message-ID: <q7D70KR-QXTQttsny99SqkoimnZn-mvGGq0S_g3TlU4=.3ae2dde3-e69c-4c32-ac20-2490dcf0a034@github.com>

> There are two versions of JVMFlagAccess::ccstrAtPut() for modifying JVM flags of the ccstr type (i.e., strings).
> 
> - One version requires the caller to free the old value, but some callers don't do that (writeableFlags.cpp).
> - The other version frees the old value on behalf of the caller. However, this version is accessible only via FLAG_SET_XXX macros and is currently unused. So it's unclear whether it actually works.
> 
> We should combine these two versions into a single function, fix problems in the callers, and add test cases. The old value should be freed automatically, because typically the caller isn't interested in the old value.
> 
> Note that the FLAG_SET_XXX macros do not return the old value. Requiring the caller of FLAG_SET_XXX to free the old value would be tedious and error prone.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  relax flag attributions (ala JDK-7123237)

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3254/files
  - new: https://git.openjdk.java.net/jdk/pull/3254/files/7eca2343..673aaafc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3254&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3254&range=00-01

  Stats: 37 lines in 4 files changed: 0 ins; 36 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3254.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3254/head:pull/3254

PR: https://git.openjdk.java.net/jdk/pull/3254

From iklam at openjdk.java.net  Wed Mar 31 19:05:14 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 31 Mar 2021 19:05:14 GMT
Subject: RFR: 8264285: Clean the modification of ccstr JVM flags [v2]
In-Reply-To: <RfhOyilJToqc-vpjYA5jzD8OuQExhCznJ6ByNUEHEUU=.08409c9d-25b7-4fe4-b99b-66828d9acfc0@github.com>
References: <zbVfsuLhNzhIneQusCRIO86lU9dRUOuUWMsiR9_TDas=.9c136bfd-81f1-4168-986c-43721178444e@github.com>
 <RfhOyilJToqc-vpjYA5jzD8OuQExhCznJ6ByNUEHEUU=.08409c9d-25b7-4fe4-b99b-66828d9acfc0@github.com>
Message-ID: <VvjLKxjUyItP6fpezKfYc9fIp-Ww2Mh8Bn_hjTCKlpc=.2e02a61c-089e-4a2c-a6d0-69d2e9ec6c09@github.com>

On Wed, 31 Mar 2021 12:58:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   relax flag attributions (ala JDK-7123237)
>
> src/hotspot/share/runtime/flags/debug_globals.hpp line 38:
> 
>> 36: // have any MANAGEABLE flags of the ccstr type, but we really need to
>> 37: // make sure the implementation is correct (in terms of memory allocation)
>> 38: // just in case someone may add such a flag in the future.
> 
> Could you have just added a develop flag to the manageable flags instead?

I had to use a `product` flag due to the following code, which should have been removed as part of [JDK-8243208](https://bugs.openjdk.java.net/browse/JDK-8243208), but I was afraid to do so because I didn't have a test case. I.e., all of our diagnostic/manageable/experimental flags were `product` flags.

With this PR, now I have a test case -- I changed `DummyManageableStringFlag` to a `notproduct` flag, and removed the following code. I am re-running tiers1-4 now.

void JVMFlag::check_all_flag_declarations() {
  for (JVMFlag* current = &flagTable[0]; current->_name != NULL; current++) {
    int flags = static_cast<int>(current->_flags);
    // Backwards compatibility. This will be relaxed/removed in JDK-7123237.
    int mask = JVMFlag::KIND_DIAGNOSTIC | JVMFlag::KIND_MANAGEABLE | JVMFlag::KIND_EXPERIMENTAL;
    if ((flags & mask) != 0) {
      assert((flags & mask) == JVMFlag::KIND_DIAGNOSTIC ||
             (flags & mask) == JVMFlag::KIND_MANAGEABLE ||
             (flags & mask) == JVMFlag::KIND_EXPERIMENTAL,
             "%s can be declared with at most one of "
             "DIAGNOSTIC, MANAGEABLE or EXPERIMENTAL", current->_name);
      assert((flags & KIND_NOT_PRODUCT) == 0 &&
             (flags & KIND_DEVELOP) == 0,
             "%s has an optional DIAGNOSTIC, MANAGEABLE or EXPERIMENTAL "
             "attribute; it must be declared as a product flag", current->_name);
    }
  }
}

-------------

PR: https://git.openjdk.java.net/jdk/pull/3254

From amenkov at openjdk.java.net  Wed Mar 31 19:17:20 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 31 Mar 2021 19:17:20 GMT
Subject: RFR: 8264484: Replace uses of StringBuffer with StringBuilder in
 jdk.hotspot.agent [v3]
In-Reply-To: <aXMLZK9LuflkQUBPQoPtwoM-jBBdEmBM_hXeBmEKBo4=.7caee984-3afd-4798-a2ee-f0044bb17ed5@github.com>
References: <JG1dWhnHiime4ikiR6s-b6GTe7G7RpG_EI3W46Z1XL4=.66f74e8d-5dcc-4263-96c9-9d4e0e7b1822@github.com>
 <aXMLZK9LuflkQUBPQoPtwoM-jBBdEmBM_hXeBmEKBo4=.7caee984-3afd-4798-a2ee-f0044bb17ed5@github.com>
Message-ID: <EGJ3K6UoHXZPbhq23qIv0QO5ZOiW9HZdPOzFaLXDv84=.fd1ee738-e16e-4c49-90e5-a9b29a336e7b@github.com>

On Wed, 31 Mar 2021 17:45:33 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> Found by IntelliJ IDEA inspection `Java | Java language level migration aids | Java 5 | 'StringBuffer' may be 'StringBuilder'`
>> As suggested in https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created separate PR for module `jdk.hotspot.agent`
>> Similar cleanups in the past: https://bugs.openjdk.java.net/browse/JDK-8041679 https://bugs.openjdk.java.net/browse/JDK-8264029
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8264484: Replace uses of StringBuffer with StringBuilder in jdk.hotspot.agent
>   
>   fix indentation

Marked as reviewed by amenkov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3275

From coleenp at openjdk.java.net  Wed Mar 31 19:52:35 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 31 Mar 2021 19:52:35 GMT
Subject: RFR: 8264538: Rename SystemDictionary::parse_stream
Message-ID: <C0Y4xV0yfkqK406HL1iMadMbyGGYdfzNwgz0qBwk-d0=.fd14429f-490a-4ccf-948f-232fb9c54f94@github.com>

This function is used to call the classfile parser for hidden or anonymous classes, and for use with jvmti RedefineClasses. The latter only calls KlassFactory::create_from_stream and skips the rest of the code in SystemDictionary::parse_stream.

Renamed SystemDictionary::parse_stream -> resolve_hidden_class_from_stream
resolve_from_stream -> resolve_class_from_stream
and have SystemDictionary::resolve_from_stream() call the right version depending on ClassLoadInfo flags.  Callers of resolve_from_stream now pass protection domain via. ClassLoadInfo.

So the external API is resolve_from_stream.

Tested with tier1 on 4 Oracle supported platforms.

-------------

Commit messages:
 - Rename parse_stream

Changes: https://git.openjdk.java.net/jdk/pull/3289/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3289&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264538
  Stats: 132 lines in 7 files changed: 37 ins; 23 del; 72 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3289.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3289/head:pull/3289

PR: https://git.openjdk.java.net/jdk/pull/3289

From coleenp at openjdk.java.net  Wed Mar 31 19:57:57 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 31 Mar 2021 19:57:57 GMT
Subject: RFR: 8264538: Rename SystemDictionary::parse_stream [v2]
In-Reply-To: <C0Y4xV0yfkqK406HL1iMadMbyGGYdfzNwgz0qBwk-d0=.fd14429f-490a-4ccf-948f-232fb9c54f94@github.com>
References: <C0Y4xV0yfkqK406HL1iMadMbyGGYdfzNwgz0qBwk-d0=.fd14429f-490a-4ccf-948f-232fb9c54f94@github.com>
Message-ID: <nGVXL-ngfCKxaBol8po_z851UFvasdkUMUJ08qf3VqM=.a98c364d-d2e4-42bd-81fc-c17a1d505924@github.com>

> This function is used to call the classfile parser for hidden or anonymous classes, and for use with jvmti RedefineClasses. The latter only calls KlassFactory::create_from_stream and skips the rest of the code in SystemDictionary::parse_stream.
> 
> Renamed SystemDictionary::parse_stream -> resolve_hidden_class_from_stream
> resolve_from_stream -> resolve_class_from_stream
> and have SystemDictionary::resolve_from_stream() call the right version depending on ClassLoadInfo flags.  Callers of resolve_from_stream now pass protection domain via. ClassLoadInfo.
> 
> So the external API is resolve_from_stream.
> 
> Tested with tier1 on 4 Oracle supported platforms.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  fifix comment

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3289/files
  - new: https://git.openjdk.java.net/jdk/pull/3289/files/ba7532bd..8dfcb093

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3289&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3289&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3289.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3289/head:pull/3289

PR: https://git.openjdk.java.net/jdk/pull/3289

From lfoltan at openjdk.java.net  Wed Mar 31 20:11:24 2021
From: lfoltan at openjdk.java.net (Lois Foltan)
Date: Wed, 31 Mar 2021 20:11:24 GMT
Subject: RFR: 8264538: Rename SystemDictionary::parse_stream [v2]
In-Reply-To: <nGVXL-ngfCKxaBol8po_z851UFvasdkUMUJ08qf3VqM=.a98c364d-d2e4-42bd-81fc-c17a1d505924@github.com>
References: <C0Y4xV0yfkqK406HL1iMadMbyGGYdfzNwgz0qBwk-d0=.fd14429f-490a-4ccf-948f-232fb9c54f94@github.com>
 <nGVXL-ngfCKxaBol8po_z851UFvasdkUMUJ08qf3VqM=.a98c364d-d2e4-42bd-81fc-c17a1d505924@github.com>
Message-ID: <5XkcECxtI-f304vVc6TXjJNXHA5kpzcHORV8q8mPvzk=.da25a174-4c29-4f5a-a639-695043a06067@github.com>

On Wed, 31 Mar 2021 19:57:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This function is used to call the classfile parser for hidden or anonymous classes, and for use with jvmti RedefineClasses. The latter only calls KlassFactory::create_from_stream and skips the rest of the code in SystemDictionary::parse_stream.
>> 
>> Renamed SystemDictionary::parse_stream -> resolve_hidden_class_from_stream
>> resolve_from_stream -> resolve_class_from_stream
>> and have SystemDictionary::resolve_from_stream() call the right version depending on ClassLoadInfo flags.  Callers of resolve_from_stream now pass protection domain via. ClassLoadInfo.
>> 
>> So the external API is resolve_from_stream.
>> 
>> Tested with tier1 on 4 Oracle supported platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fifix comment

Nice clean up Coleen.  One minor comment.

Thanks,
Lois

src/hotspot/share/prims/jvm.cpp line 950:

> 948:   InstanceKlass* ik = NULL;
> 949:   if (!is_hidden) {
> 950:     ClassLoadInfo cl_info(protection_domain);

Minor comment, you could pull the creation of ClassLoadInfo out of this if statement since both the the if and the else sections create a ClassLoadInfo with pretty much the same information.

-------------

Marked as reviewed by lfoltan (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3289

From hseigel at openjdk.java.net  Wed Mar 31 20:25:29 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 31 Mar 2021 20:25:29 GMT
Subject: RFR: 8264538: Rename SystemDictionary::parse_stream [v2]
In-Reply-To: <nGVXL-ngfCKxaBol8po_z851UFvasdkUMUJ08qf3VqM=.a98c364d-d2e4-42bd-81fc-c17a1d505924@github.com>
References: <C0Y4xV0yfkqK406HL1iMadMbyGGYdfzNwgz0qBwk-d0=.fd14429f-490a-4ccf-948f-232fb9c54f94@github.com>
 <nGVXL-ngfCKxaBol8po_z851UFvasdkUMUJ08qf3VqM=.a98c364d-d2e4-42bd-81fc-c17a1d505924@github.com>
Message-ID: <za8cTJQsNmL8FI1mBieIU1v-LBjn9Nvt0gUqqV4TW-w=.a3a0fd0b-9a62-496c-b1e6-454147630f57@github.com>

On Wed, 31 Mar 2021 19:57:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This function is used to call the classfile parser for hidden or anonymous classes, and for use with jvmti RedefineClasses. The latter only calls KlassFactory::create_from_stream and skips the rest of the code in SystemDictionary::parse_stream.
>> 
>> Renamed SystemDictionary::parse_stream -> resolve_hidden_class_from_stream
>> resolve_from_stream -> resolve_class_from_stream
>> and have SystemDictionary::resolve_from_stream() call the right version depending on ClassLoadInfo flags.  Callers of resolve_from_stream now pass protection domain via. ClassLoadInfo.
>> 
>> So the external API is resolve_from_stream.
>> 
>> Tested with tier1 on 4 Oracle supported platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fifix comment

src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1395:

> 1393:                                                       cl_info,
> 1394:                                                       THREAD);
> 1395: 

Could you add a comment above line 1390 saying you can't call resolve_class_from_stream() here because the resulting class should not go in the system dictionary?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3289

From hseigel at openjdk.java.net  Wed Mar 31 20:30:20 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 31 Mar 2021 20:30:20 GMT
Subject: RFR: 8264538: Rename SystemDictionary::parse_stream [v2]
In-Reply-To: <nGVXL-ngfCKxaBol8po_z851UFvasdkUMUJ08qf3VqM=.a98c364d-d2e4-42bd-81fc-c17a1d505924@github.com>
References: <C0Y4xV0yfkqK406HL1iMadMbyGGYdfzNwgz0qBwk-d0=.fd14429f-490a-4ccf-948f-232fb9c54f94@github.com>
 <nGVXL-ngfCKxaBol8po_z851UFvasdkUMUJ08qf3VqM=.a98c364d-d2e4-42bd-81fc-c17a1d505924@github.com>
Message-ID: <I1FQhYSKKPdWyqHovDQX90hyvDRza8eaVvGCDxcoLpg=.b0261848-acee-4959-83ab-d76ab10ff13c@github.com>

On Wed, 31 Mar 2021 19:57:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This function is used to call the classfile parser for hidden or anonymous classes, and for use with jvmti RedefineClasses. The latter only calls KlassFactory::create_from_stream and skips the rest of the code in SystemDictionary::parse_stream.
>> 
>> Renamed SystemDictionary::parse_stream -> resolve_hidden_class_from_stream
>> resolve_from_stream -> resolve_class_from_stream
>> and have SystemDictionary::resolve_from_stream() call the right version depending on ClassLoadInfo flags.  Callers of resolve_from_stream now pass protection domain via. ClassLoadInfo.
>> 
>> So the external API is resolve_from_stream.
>> 
>> Tested with tier1 on 4 Oracle supported platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fifix comment

src/hotspot/share/prims/jvmtiRedefineClasses.hpp line 305:

> 303: // - How do we serialize the RedefineClasses() API without deadlocking?
> 304: //
> 305: // - KlassFactory::create_from_stream() was called with a NULL protection

Maybe delete the comment that goes from lines 305 - 309 ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3289

From dfuchs at openjdk.java.net  Wed Mar 31 20:56:32 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 31 Mar 2021 20:56:32 GMT
Subject: RFR: 8264124: Update MXBean specification and implementation to
 extend mapping of CompositeType to records [v2]
In-Reply-To: <6QvyGXdDKhrOjFZ0GuVsiig5fp5Mo1cCjuI3UvshX20=.dc5fa768-f6e7-4066-a51c-8c21b51b531b@github.com>
References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com>
 <cAwbOBwhGERyBUbreMVPVsCabpDTPi3oqSDQ53FTVlk=.70a98535-36bb-4483-b461-5de840998d06@github.com>
 <C0e13BnsgJfRQvS86QICp_CwhR4PIaC498P5FnjazjE=.4e8467e1-8b8b-4899-bf22-470328d31007@github.com>
 <0RxhjEDdg8ZZRNLjbknHs_sa71hn6ax3LAtv_-pZGqY=.a3e1631a-4280-4b2e-95c0-794785b9d165@github.com>
 <UvPmdS6Nn0PhWonjYS_YTnhwc8SXhElST7Y3f844WNM=.d1c7e494-97c8-44ad-ac2b-469121ef54f9@github.com>
 <GSkZtrq04srGDZDlPzAKPaD_-MpoxBKfsnv8DMFkeSg=.ac9d73de-2c91-471a-9307-d7ea7a492b1e@github.com>
 <6QvyGXdDKhrOjFZ0GuVsiig5fp5Mo1cCjuI3UvshX20=.dc5fa768-f6e7-4066-a51c-8c21b51b531b@github.com>
Message-ID: <r_BMJbvDrKa8pREFnaeEKn5yjOlPxeqSRY8gFiB_78E=.1ac7c98b-a286-41b8-86c1-4bafe6e6d9ef@github.com>

On Wed, 31 Mar 2021 18:32:31 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Hi Mandy, I have updated the PR with a revised version of the text above. Is that more in line what you had in mind?
>> 
>> best regards,
>> -- daniel
>
> This looks better.  I like a separate mapping section for records since the mapping rules are straight-forward.   The complexity comes if we want to support a record to implement `CompositeDataView` that allows a type to support more flexible conversion to `CompositeData` which is why you add records in the "Mappings for other types".   I am wondering if we really want to support records to implement `CompositeDataView` but we may want to avoid such a special case.
> 
> I suggest add subsections in "Mappings for other types":   There are two mapping rules: (1) _opentype(J)_ maps `J` to `CompositeType` (2) _opendata(J)_ maps `J` to `CompositeData`.   _opentype(J)_ for record class does not need to refer to other types.   The common cases for _opendata(J)_ for record class is using the canonical constructors.   The other less common cases like using non-canonical constructors and `CompositeDataView` can state that it follows the same rules as specified for other types.   "Mappings for other types" does not need any change for records.   
> 
> "Reconstructing an instance of Java type J from a CompositeData" section should be renamed to "Reconstructing an instance of Java type or record class J from a CompositeData"
> 
> Here is a minor tweaking on "Mappings for Records"
> 
> A record is convertible to a CompositeType if and only if all its components are 
> convertible to open types. Otherwise, it is not convertible.
> 
> A record class is converted to a CompositeType with one item for every record component as follows.
> - The type name of this CompositeType is determined by the type name rules detailed below. 
> - Each record component of type T, the item in the CompositeType has the same name 
>   as the record component and of type opentype(T).
> 
> The mapping from an instance of a record class to a CompositeData corresponding to 
> the CompositeType is the same as specified as for other types (add a link).
> 
> A record is reconstructed from a CompositeData using its canonical constructor. 
> The canonical constructor doesn't require the presence of @javax.management.ConstructorParameters 
> or @java.beans.ConstructorProperties annotations. If these annotations are present on
> the canonical constructor, they will be ignored.
> 
> If the CompositeData from which the record is reconstructed doesn't contain all the record components, 
> the MXBean framework will attempt to reconstruct the record in the same way as specified for 
> other types (add a link).

I have updated the PR with those changes, plus a few minor adjustments.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3201

From dfuchs at openjdk.java.net  Wed Mar 31 20:56:32 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 31 Mar 2021 20:56:32 GMT
Subject: RFR: 8264124: Update MXBean specification and implementation to
 extend mapping of CompositeType to records [v5]
In-Reply-To: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com>
References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com>
Message-ID: <poZTb8X7e8bX8EWKQg2WjVC_iduKqzQSnNcE0ae5hrE=.09c7f95b-cd4a-4459-a6fd-bf7d3f959a87@github.com>

> This RFE proposes to extend the MXBean framework to define a mapping to records.
> 
> The MXBean framework already defines a mapping of `CompositeType` to plain java objects. Records are a natural representation of CompositeTypes. A record can be easily reconstructed from a `CompositeData` through the record canonical constructor. A clear advantage of records over plain java objects is that the canonical constructor will not need to be annotated in order to map composite data property names to constructor parameter names.
> 
> With this RFE, here is an example comparing coding a composite type `NamedNumber` that consists of an `int` and a `String`, using records and using a plain java class. In both case, the `CompositeType` looks like this:
> 
> CompositeType(
>     "NamedNumber",                      // typeName
>     "NamedNumber",                      // description
>     new String[] {"number", "name"},    // itemNames
>     new String[] {"number", "name"},    // itemDescriptions
>     new OpenType[] {SimpleType.INTEGER,
>                     SimpleType.STRING}  // itemTypes
> );
> 
> The plain Java class needs a public constructor annotated with `@ConstructorParameters` annotation:
> 
> public class NamedNumber {
>     public int getNumber() {return number;}
>     public String getName() {return name;}
>     @ConstructorParameters({"number", "name"})
>     public NamedNumber(int number, String name) {
>         this.number = number;
>         this.name = name;
>     }
>     private final int number;
>     private final String name;
> }
> 
> And the equivalent with a record class: 
> 
> public record NamedNumber(int number, String name) {}

Daniel Fuchs has updated the pull request incrementally with two additional commits since the last revision:

 - Integrated review feedback
 - Improved test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3201/files
  - new: https://git.openjdk.java.net/jdk/pull/3201/files/7d478dec..9227ba58

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3201&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3201&range=03-04

  Stats: 114 lines in 2 files changed: 53 ins; 13 del; 48 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3201.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3201/head:pull/3201

PR: https://git.openjdk.java.net/jdk/pull/3201

From minqi at openjdk.java.net  Wed Mar 31 20:58:46 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 31 Mar 2021 20:58:46 GMT
Subject: RFR: 8259070: Add jcmd option to dump CDS [v8]
In-Reply-To: <hwrc1zAz8G180ToL-C3EuUIF-5R17F5Gm1zcPMBpOtE=.e002a377-e0e2-485b-a08e-b63675a9746b@github.com>
References: <hwrc1zAz8G180ToL-C3EuUIF-5R17F5Gm1zcPMBpOtE=.e002a377-e0e2-485b-a08e-b63675a9746b@github.com>
Message-ID: <VluNGWmlN3SiRcNehdalH8aHH3HUjYbfGoyIUwTmo4A=.e67d7cb6-2289-4680-95e7-46c23ef83883@github.com>

> Hi, Please review
> 
>   Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with
>   `java -XX:DumpLoadedClassList=<classlist> .... `  
>  to collect shareable class names and saved in file `<classlist>` , then 
>   `java -Xshare:dump -XX:SharedClassListFile=<classlist> -XX:SharedArchiveFile=<archivefile> ...`
>   With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime  to dump an archive.
>    The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved.
>    New added jcmd option:
>    `jcmd <pid or AppName> VM.cds static_dump <filename>`
>    or
>     `jcmd <pid or AppName> VM.cds dynamic_dump <filename>`
>   To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. 
>    The file name is optional, if the file name is not supplied, the file name will take format of `java_pid<number>_static.jsa` or `java_pid<number>_dynamic.jsa` for static and dynamic respectively. The `<number>` is the application process ID.
> 
>   Tests: tier1,tier2,tier3,tier4
> 
> Thanks
> Yumin

Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Fix revert unintentionally comment, merge master.
 - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070
 - Remove CDS.getVMArguments, changed to use VM.getRuntimeVMArguments. Removed unused function from ClassLoader. Improved InstanceKlass::is_shareable() and related test. Added more test scenarios.
 - Remove redundant check for if a class is shareable
 - Fix according to review comment and add more tests
 - Fix filter more flags to exclude in static dump, add more test cases
 - Merge branch 'master' into jdk-8259070
 - Fix white space in CDS.java
 - Add function CDS.dumpSharedArchive in java to dump shared archive
 - 8259070: Add jcmd option to dump CDS

-------------

Changes: https://git.openjdk.java.net/jdk/pull/2737/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2737&range=07
  Stats: 830 lines in 21 files changed: 758 ins; 58 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2737.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2737/head:pull/2737

PR: https://git.openjdk.java.net/jdk/pull/2737

From dfuchs at openjdk.java.net  Wed Mar 31 21:02:51 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 31 Mar 2021 21:02:51 GMT
Subject: RFR: 8264124: Update MXBean specification and implementation to
 extend mapping of CompositeType to records [v6]
In-Reply-To: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com>
References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com>
Message-ID: <-HFZga_QfdbwjZcwnYCmvWjaXEACUzdW3fd6D6BhX6I=.38ba198b-70e4-4682-a7f4-13965bb47162@github.com>

> This RFE proposes to extend the MXBean framework to define a mapping to records.
> 
> The MXBean framework already defines a mapping of `CompositeType` to plain java objects. Records are a natural representation of CompositeTypes. A record can be easily reconstructed from a `CompositeData` through the record canonical constructor. A clear advantage of records over plain java objects is that the canonical constructor will not need to be annotated in order to map composite data property names to constructor parameter names.
> 
> With this RFE, here is an example comparing coding a composite type `NamedNumber` that consists of an `int` and a `String`, using records and using a plain java class. In both case, the `CompositeType` looks like this:
> 
> CompositeType(
>     "NamedNumber",                      // typeName
>     "NamedNumber",                      // description
>     new String[] {"number", "name"},    // itemNames
>     new String[] {"number", "name"},    // itemDescriptions
>     new OpenType[] {SimpleType.INTEGER,
>                     SimpleType.STRING}  // itemTypes
> );
> 
> The plain Java class needs a public constructor annotated with `@ConstructorParameters` annotation:
> 
> public class NamedNumber {
>     public int getNumber() {return number;}
>     public String getName() {return name;}
>     @ConstructorParameters({"number", "name"})
>     public NamedNumber(int number, String name) {
>         this.number = number;
>         this.name = name;
>     }
>     private final int number;
>     private final String name;
> }
> 
> And the equivalent with a record class: 
> 
> public record NamedNumber(int number, String name) {}

Daniel Fuchs has updated the pull request incrementally with two additional commits since the last revision:

 - minor style issue
 - minor style issue

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3201/files
  - new: https://git.openjdk.java.net/jdk/pull/3201/files/9227ba58..a624a763

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3201&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3201&range=04-05

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3201.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3201/head:pull/3201

PR: https://git.openjdk.java.net/jdk/pull/3201

From coleenp at openjdk.java.net  Wed Mar 31 21:41:40 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 31 Mar 2021 21:41:40 GMT
Subject: RFR: 8264538: Rename SystemDictionary::parse_stream [v2]
In-Reply-To: <nGVXL-ngfCKxaBol8po_z851UFvasdkUMUJ08qf3VqM=.a98c364d-d2e4-42bd-81fc-c17a1d505924@github.com>
References: <C0Y4xV0yfkqK406HL1iMadMbyGGYdfzNwgz0qBwk-d0=.fd14429f-490a-4ccf-948f-232fb9c54f94@github.com>
 <nGVXL-ngfCKxaBol8po_z851UFvasdkUMUJ08qf3VqM=.a98c364d-d2e4-42bd-81fc-c17a1d505924@github.com>
Message-ID: <wo1ESbmaJtpOm40I4t4iFAUJFh2XOF6TKL1TTwv3R3w=.75e8a8da-5b80-4091-b70d-18fc18fe7a55@github.com>

On Wed, 31 Mar 2021 19:57:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This function is used to call the classfile parser for hidden or anonymous classes, and for use with jvmti RedefineClasses. The latter only calls KlassFactory::create_from_stream and skips the rest of the code in SystemDictionary::parse_stream.
>> 
>> Renamed SystemDictionary::parse_stream -> resolve_hidden_class_from_stream
>> resolve_from_stream -> resolve_class_from_stream
>> and have SystemDictionary::resolve_from_stream() call the right version depending on ClassLoadInfo flags.  Callers of resolve_from_stream now pass protection domain via. ClassLoadInfo.
>> 
>> So the external API is resolve_from_stream.
>> 
>> Tested with tier1 on 4 Oracle supported platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fifix comment

Thank you for reviewing this Lois and Harold.  Some replies attached.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3289

From coleenp at openjdk.java.net  Wed Mar 31 21:41:39 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 31 Mar 2021 21:41:39 GMT
Subject: RFR: 8264538: Rename SystemDictionary::parse_stream [v3]
In-Reply-To: <C0Y4xV0yfkqK406HL1iMadMbyGGYdfzNwgz0qBwk-d0=.fd14429f-490a-4ccf-948f-232fb9c54f94@github.com>
References: <C0Y4xV0yfkqK406HL1iMadMbyGGYdfzNwgz0qBwk-d0=.fd14429f-490a-4ccf-948f-232fb9c54f94@github.com>
Message-ID: <Wo7zTBdUNkFdWxsA0niCJf-BrRnGvnLyLNqZo5mI_Sw=.e4bb4b66-bf76-4c45-8b36-3ab5a9322c9a@github.com>

> This function is used to call the classfile parser for hidden or anonymous classes, and for use with jvmti RedefineClasses. The latter only calls KlassFactory::create_from_stream and skips the rest of the code in SystemDictionary::parse_stream.
> 
> Renamed SystemDictionary::parse_stream -> resolve_hidden_class_from_stream
> resolve_from_stream -> resolve_class_from_stream
> and have SystemDictionary::resolve_from_stream() call the right version depending on ClassLoadInfo flags.  Callers of resolve_from_stream now pass protection domain via. ClassLoadInfo.
> 
> So the external API is resolve_from_stream.
> 
> Tested with tier1 on 4 Oracle supported platforms.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Add and remove comments.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3289/files
  - new: https://git.openjdk.java.net/jdk/pull/3289/files/8dfcb093..cd49552a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3289&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3289&range=01-02

  Stats: 9 lines in 2 files changed: 2 ins; 7 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3289.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3289/head:pull/3289

PR: https://git.openjdk.java.net/jdk/pull/3289

From coleenp at openjdk.java.net  Wed Mar 31 21:41:41 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 31 Mar 2021 21:41:41 GMT
Subject: RFR: 8264538: Rename SystemDictionary::parse_stream [v2]
In-Reply-To: <5XkcECxtI-f304vVc6TXjJNXHA5kpzcHORV8q8mPvzk=.da25a174-4c29-4f5a-a639-695043a06067@github.com>
References: <C0Y4xV0yfkqK406HL1iMadMbyGGYdfzNwgz0qBwk-d0=.fd14429f-490a-4ccf-948f-232fb9c54f94@github.com>
 <nGVXL-ngfCKxaBol8po_z851UFvasdkUMUJ08qf3VqM=.a98c364d-d2e4-42bd-81fc-c17a1d505924@github.com>
 <5XkcECxtI-f304vVc6TXjJNXHA5kpzcHORV8q8mPvzk=.da25a174-4c29-4f5a-a639-695043a06067@github.com>
Message-ID: <aoQ_fzj-MqKRDA76qUAn156cWdBPk2aufeW1XhMAsnY=.8c116bd8-39ef-4ef7-b464-da14a07094a3@github.com>

On Wed, 31 Mar 2021 20:07:50 GMT, Lois Foltan <lfoltan at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fifix comment
>
> src/hotspot/share/prims/jvm.cpp line 950:
> 
>> 948:   InstanceKlass* ik = NULL;
>> 949:   if (!is_hidden) {
>> 950:     ClassLoadInfo cl_info(protection_domain);
> 
> Minor comment, you could pull the creation of ClassLoadInfo out of this if statement since both the the if and the else sections create a ClassLoadInfo with pretty much the same information.

That other ClassLoadInfo cl_info(protection_domain) you see is from another function, so I can't pull it out.
The other side of the 'if' statement creates a ClassLoadInfo with all the hidden class goodies.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3289

From coleenp at openjdk.java.net  Wed Mar 31 21:41:42 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 31 Mar 2021 21:41:42 GMT
Subject: RFR: 8264538: Rename SystemDictionary::parse_stream [v2]
In-Reply-To: <za8cTJQsNmL8FI1mBieIU1v-LBjn9Nvt0gUqqV4TW-w=.a3a0fd0b-9a62-496c-b1e6-454147630f57@github.com>
References: <C0Y4xV0yfkqK406HL1iMadMbyGGYdfzNwgz0qBwk-d0=.fd14429f-490a-4ccf-948f-232fb9c54f94@github.com>
 <nGVXL-ngfCKxaBol8po_z851UFvasdkUMUJ08qf3VqM=.a98c364d-d2e4-42bd-81fc-c17a1d505924@github.com>
 <za8cTJQsNmL8FI1mBieIU1v-LBjn9Nvt0gUqqV4TW-w=.a3a0fd0b-9a62-496c-b1e6-454147630f57@github.com>
Message-ID: <VOY1vZG5MgzHv32x94esYDDz9iwomXg-tVouSqHTZHs=.09213000-3405-4294-8531-a45106646de9@github.com>

On Wed, 31 Mar 2021 20:22:08 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fifix comment
>
> src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1395:
> 
>> 1393:                                                       cl_info,
>> 1394:                                                       THREAD);
>> 1395: 
> 
> Could you add a comment above line 1390 saying you can't call resolve_class_from_stream() here because the resulting class should not go in the system dictionary?

// Parse and create a class from the bytes, but this class isn't added
    // to the dictionary, so do not call resolve_from_stream.

> src/hotspot/share/prims/jvmtiRedefineClasses.hpp line 305:
> 
>> 303: // - How do we serialize the RedefineClasses() API without deadlocking?
>> 304: //
>> 305: // - KlassFactory::create_from_stream() was called with a NULL protection
> 
> Maybe delete the comment that goes from lines 305 - 309 ?

Good idea.  The comment is really old and no longer relevant.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3289

From mchung at openjdk.java.net  Wed Mar 31 21:47:08 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 31 Mar 2021 21:47:08 GMT
Subject: RFR: 8264124: Update MXBean specification and implementation to
 extend mapping of CompositeType to records [v6]
In-Reply-To: <-HFZga_QfdbwjZcwnYCmvWjaXEACUzdW3fd6D6BhX6I=.38ba198b-70e4-4682-a7f4-13965bb47162@github.com>
References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com>
 <-HFZga_QfdbwjZcwnYCmvWjaXEACUzdW3fd6D6BhX6I=.38ba198b-70e4-4682-a7f4-13965bb47162@github.com>
Message-ID: <T1CmwpTcj2TCC7KSDu_OU4SmgA1XoJONDwnJysyniy0=.462d05d2-5100-4ec3-a13e-4d6a44336950@github.com>

On Wed, 31 Mar 2021 21:02:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This RFE proposes to extend the MXBean framework to define a mapping to records.
>> 
>> The MXBean framework already defines a mapping of `CompositeType` to plain java objects. Records are a natural representation of CompositeTypes. A record can be easily reconstructed from a `CompositeData` through the record canonical constructor. A clear advantage of records over plain java objects is that the canonical constructor will not need to be annotated in order to map composite data property names to constructor parameter names.
>> 
>> With this RFE, here is an example comparing coding a composite type `NamedNumber` that consists of an `int` and a `String`, using records and using a plain java class. In both case, the `CompositeType` looks like this:
>> 
>> CompositeType(
>>     "NamedNumber",                      // typeName
>>     "NamedNumber",                      // description
>>     new String[] {"number", "name"},    // itemNames
>>     new String[] {"number", "name"},    // itemDescriptions
>>     new OpenType[] {SimpleType.INTEGER,
>>                     SimpleType.STRING}  // itemTypes
>> );
>> 
>> The plain Java class needs a public constructor annotated with `@ConstructorParameters` annotation:
>> 
>> public class NamedNumber {
>>     public int getNumber() {return number;}
>>     public String getName() {return name;}
>>     @ConstructorParameters({"number", "name"})
>>     public NamedNumber(int number, String name) {
>>         this.number = number;
>>         this.name = name;
>>     }
>>     private final int number;
>>     private final String name;
>> }
>> 
>> And the equivalent with a record class: 
>> 
>> public record NamedNumber(int number, String name) {}
>
> Daniel Fuchs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - minor style issue
>  - minor style issue

Thanks for making the change.  The spec change looks good to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3201

From iklam at openjdk.java.net  Wed Mar 31 22:53:29 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 31 Mar 2021 22:53:29 GMT
Subject: RFR: 8264285: Clean the modification of ccstr JVM flags [v2]
In-Reply-To: <71SWS17lpVrTS_4--6mimeyjCYjYzP_VO_lJ-rImnxg=.a75340ae-d17e-4f0d-8868-21d4449d64f6@github.com>
References: <zbVfsuLhNzhIneQusCRIO86lU9dRUOuUWMsiR9_TDas=.9c136bfd-81f1-4168-986c-43721178444e@github.com>
 <71SWS17lpVrTS_4--6mimeyjCYjYzP_VO_lJ-rImnxg=.a75340ae-d17e-4f0d-8868-21d4449d64f6@github.com>
Message-ID: <Nl6ac7ftjBIHUmD3cn6FLWi5e_GW9M7ePsIQiyY49cQ=.e0d31254-5739-43c1-8186-8f6db3ead632@github.com>

On Tue, 30 Mar 2021 03:44:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   relax flag attributions (ala JDK-7123237)
>
> src/hotspot/share/services/writeableFlags.cpp line 250:
> 
>> 248:   if (err == JVMFlag::SUCCESS) {
>> 249:     assert(value == NULL, "old value is freed automatically and not returned");
>> 250:   }
> 
> The whole block should be ifdef DEBUG.

Since this whole block can be optimized out by the C compiler in product builds, I'd rather leave out the `#ifdef` to avoid clutter.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3254

From david.holmes at oracle.com  Wed Mar 31 23:13:49 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 1 Apr 2021 09:13:49 +1000
Subject: RFR: 8257831: Suspend with handshakes [v2]
In-Reply-To: <H0Y_ACIQmnlzsspT2fr8XNleKxxleh9RdIgPUhOjRhs=.5634f9b6-52ac-4399-b253-730476ee67a3@github.com>
References: <xv1j0DkGolookgzzyT7w9hz5-mlD0QaeHfqL3b9HJ6I=.c33a0757-1f6e-4a7c-afa4-2d531849d4fc@github.com>
 <a6Fjizolorcan3_uaH8QqfAmw6LqdOwC02DG2Yp6ZNg=.d8ebe170-cdda-42d7-912c-0210f9643da6@github.com>
 <qECYENgo-noFUVcExYlTP7CBEYajuKMU51JdiI6vPUw=.c19b7a63-49a4-40a4-b04f-1c4e0537078a@github.com>
 <zh-q9GNGDppcpYqr8kZGYR5F4Lzkq8wO-hYkDMEnqkc=.08ef3008-eee0-4379-96df-d3163a36e032@github.com>
 <L_bT7G_UmsPKQfgxAoUujZZYg3wFqBeKWXPDIdXL-7c=.bb20229f-1c6e-48d0-80a9-30d6444bdbc2@github.com>
 <m4Pevdd5jNKLfOij_iJBbsHvrM0dEJ0E7gWQd6vCj54=.116f3703-300c-46e3-98e7-98e045d74cb5@github.com>
 <H0Y_ACIQmnlzsspT2fr8XNleKxxleh9RdIgPUhOjRhs=.5634f9b6-52ac-4399-b253-730476ee67a3@github.com>
Message-ID: <2086f945-f096-6fff-f9eb-c6e9ceaa06f9@oracle.com>

Hi Dan,

On 1/04/2021 12:07 am, Daniel D.Daugherty wrote:
> On Wed, 31 Mar 2021 10:22:28 GMT, Richard Reingruber <rrich at openjdk.org> wrote:
> 
>>> My comment was about JVMTI_ERROR_THREAD_NOT_ALIVE
>>
>> Sure. I agree with your comment.
> 
> It depends on how late we can call into an event handler during the
> JavaThread exit code path. Is it possible to post an event on a thread
> that has passed the `terminated` point in JavaThread::exit()?

The JVM TI thread_end event is posted before the thread is marked as 
exiting.

David

> 
> PR: https://git.openjdk.java.net/jdk/pull/3191
> 

From david.holmes at oracle.com  Wed Mar 31 23:28:09 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 1 Apr 2021 09:28:09 +1000
Subject: RFR: 8257831: Suspend with handshakes [v2]
In-Reply-To: <REwQNt8SR7DMqwaQJ4b2yNza607drE92BFvwRmpT76o=.c0f8885e-5394-4aca-ab8f-7edc11589f6a@github.com>
References: <xv1j0DkGolookgzzyT7w9hz5-mlD0QaeHfqL3b9HJ6I=.c33a0757-1f6e-4a7c-afa4-2d531849d4fc@github.com>
 <a6Fjizolorcan3_uaH8QqfAmw6LqdOwC02DG2Yp6ZNg=.d8ebe170-cdda-42d7-912c-0210f9643da6@github.com>
 <lfoWy9GAZC-tp75AqoATcaOOwWhHfoQjHZ236wmhL64=.628619cf-5e45-475b-958e-70dccef9bcb6@github.com>
 <RzUniZabptKFS1qhpsmktmsqmVKML7lGerSDyv723Ro=.fb8300d8-11a8-40b1-b275-dbce9d9c14a5@github.com>
 <3hnHTIU7h2VZ8ZcubYBQV7L-T8yyoJ1VUdQH5RK8eWE=.afc11483-37d2-4cc6-9177-13c6cb709e88@github.com>
 <REwQNt8SR7DMqwaQJ4b2yNza607drE92BFvwRmpT76o=.c0f8885e-5394-4aca-ab8f-7edc11589f6a@github.com>
Message-ID: <c28d877c-a027-d471-2f7e-ed181e0ce048@oracle.com>



On 1/04/2021 12:35 am, Robbin Ehn wrote:
> On Wed, 31 Mar 2021 10:48:11 GMT, Robbin Ehn <rehn at openjdk.org> wrote:
> 
>>> Thanks @dcubed-ojdk - no it won't. The problem is that the signal can hit very late in a thread's termination process, after the JavaThread destructor has executed, so no query of JavaThread state is possible. So we needed something in the Thread state and the SR_lock was a good enough proxy for that. It may be possible to use a different Thread field (perhaps _ParkEvent but encapsulated in a Thread::has_terminated() helper method).
>>
>> SR_handler is used for OS-level suspend/resume (not to conflict with this change-set).
>> This feature is only used by JFR (AFAIK), and JFR only samples threads on it's ThreadsList.
>> This means the JavaThread can never be terminated, hence this code will always pass.
>>
>> If someone else is using OS-level suspend/resume without a ThreadsList, the bug is there is no ThreadsList AFAICT.
>>
>> Since ThreadLocalStorage::thread() is cleared last in ~Thread with Thread::clear_thread_current(); may be in the ~Thread destructor.
>> So the argument is that would be safe to read stuff from Thread but not JavaThread?
>> Since the compiler (and CPU) may reorder and optimize away code, so I argue reading from a half destroyed object is not a great idea.
>> E.g. Monitor* _SR_lock; is not a volatile pointer; since reading from this memory is UB after destruction, compiler is free to remove or not publish the store to NULL.
>>
>> So I suggest either to remove this check, since the only user is using a ThreadsList and any other should also be using that too.
>> Or call Thread::clear_thread_current() before the JavaThread destructor is called, that way we can be certain that there is no UB.
> 
> I got some offline input from David, there seem to be an issue with signal being delivered after the ThreadsListHandle destructor. If that is the case a ThreadsList doesn't help here.
> 
> So I suggested we keep this out of this change-set and just take another suitable field to mirror what we have today.
> 
> `ParkEvent * _ParkEvent;` ?

Yes nicely packaged as:

bool Thread::has_terminated() {
   return _ParkEvent == NULL;
}

Also note:

  // It's possible we can encounter a null _ParkEvent, etc., in 
stillborn threads.
   // We NULL out the fields for good hygiene.
   ParkEvent::Release(_ParkEvent); _ParkEvent   = NULL;

the comment is wrong as it can't be NULL even if stillborn. And now we 
NULL it out for good hygiene and as a late-stage termination indicator.

And yes we can make _ParkEvent volatile to dissuade the compiler from 
eliding the NULLing out.

Thanks,
David

> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3191
> 

From iklam at openjdk.java.net  Wed Mar 31 23:30:42 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 31 Mar 2021 23:30:42 GMT
Subject: RFR: 8259070: Add jcmd option to dump CDS [v8]
In-Reply-To: <VluNGWmlN3SiRcNehdalH8aHH3HUjYbfGoyIUwTmo4A=.e67d7cb6-2289-4680-95e7-46c23ef83883@github.com>
References: <hwrc1zAz8G180ToL-C3EuUIF-5R17F5Gm1zcPMBpOtE=.e002a377-e0e2-485b-a08e-b63675a9746b@github.com>
 <VluNGWmlN3SiRcNehdalH8aHH3HUjYbfGoyIUwTmo4A=.e67d7cb6-2289-4680-95e7-46c23ef83883@github.com>
Message-ID: <3yTFtGkXVbbpeMoqSZjS8Gu_iYUmDVFzUjqX6hCI0Ro=.942e390b-672f-4090-bf0a-59b937b23e60@github.com>

On Wed, 31 Mar 2021 20:58:46 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Hi, Please review
>> 
>>   Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with
>>   `java -XX:DumpLoadedClassList=<classlist> .... `  
>>  to collect shareable class names and saved in file `<classlist>` , then 
>>   `java -Xshare:dump -XX:SharedClassListFile=<classlist> -XX:SharedArchiveFile=<archivefile> ...`
>>   With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime  to dump an archive.
>>    The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved.
>>    New added jcmd option:
>>    `jcmd <pid or AppName> VM.cds static_dump <filename>`
>>    or
>>     `jcmd <pid or AppName> VM.cds dynamic_dump <filename>`
>>   To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. 
>>    The file name is optional, if the file name is not supplied, the file name will take format of `java_pid<number>_static.jsa` or `java_pid<number>_dynamic.jsa` for static and dynamic respectively. The `<number>` is the application process ID.
>> 
>>   Tests: tier1,tier2,tier3,tier4
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Fix revert unintentionally comment, merge master.
>  - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070
>  - Remove CDS.getVMArguments, changed to use VM.getRuntimeVMArguments. Removed unused function from ClassLoader. Improved InstanceKlass::is_shareable() and related test. Added more test scenarios.
>  - Remove redundant check for if a class is shareable
>  - Fix according to review comment and add more tests
>  - Fix filter more flags to exclude in static dump, add more test cases
>  - Merge branch 'master' into jdk-8259070
>  - Fix white space in CDS.java
>  - Add function CDS.dumpSharedArchive in java to dump shared archive
>  - 8259070: Add jcmd option to dump CDS

Changes requested by iklam (Reviewer).

src/hotspot/share/classfile/vmSymbols.hpp line 304:

> 302:   template(generateLambdaFormHolderClasses_signature, "([Ljava/lang/String;)[Ljava/lang/Object;") \
> 303:   template(dumpSharedArchive, "dumpSharedArchive")                                                \
> 304:   template(dumpSharedArchive_signature, "(ZLjava/lang/String;)V")                                 \

Need to align the "dumpSharedArchive" part with the previous line.

src/hotspot/share/prims/jvm.cpp line 3745:

> 3743: #if INCLUDE_CDS
> 3744:   assert(UseSharedSpaces && RecordDynamicDumpInfo, "already checked in arguments.cpp?");
> 3745:   if (DynamicArchive::has_been_dumped_once()) {

Maybe add a comment like this:? 
// During dynamic archive dumping, some of the data structures are overwritten so
// we cannot dump the dynamic archive again. TODO: this should be fixed.

src/hotspot/share/prims/jvm.cpp line 3754:

> 3752:   assert(ArchiveClassesAtExit == nullptr, "already checked in arguments.cpp?");
> 3753:   Handle file_handle(THREAD, JNIHandles::resolve_non_null(archiveName));
> 3754:   char* archive_name  = java_lang_String::as_utf8_string(file_handle());

A ResourceMark is needed before calling java_lang_String::as_utf8_string().

In general, I think the code in jvm.cpp should only marshall the jobject argument (e.g., convert `jstring` to `char*`.). The main functionality of JVM_DumpDynamicArchive should be moved to dynamicArchive.cpp. Similarly, most of the work in JVM_DumpClassListToFile should be moved to metaspaceShared.cpp.

src/hotspot/share/prims/jvm.cpp line 3759:

> 3757:     DynamicArchive::dump();
> 3758:   } else {
> 3759:     THROW_MSG(vmSymbols::java_lang_RuntimeException(),

Need to set ArchiveClassesAtExit to NULL before throwing the exception, since dynamic dump may not work anymore after the failure.

test/hotspot/jtreg/runtime/cds/appcds/jcmd/LingeredTestApp.java line 28:

> 26: public class LingeredTestApp extends LingeredApp {
> 27:     // Do not use default test.class.path in class path.
> 28:     public boolean useDefaultClasspath() { return false; }

It's not obvious that you're changing the behavior of the base class by overriding a member function. It's better to have 

public LingeredTestApp() {
   setUseDefaultClasspath(false);
}

Also, the name of LingeredTestApp is kind of generic. How about renaming it to JCmdTestLingeredApp?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2737

From ysuenaga at openjdk.java.net  Wed Mar 31 23:50:33 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 31 Mar 2021 23:50:33 GMT
Subject: RFR: 8264484: Replace uses of StringBuffer with StringBuilder in
 jdk.hotspot.agent [v3]
In-Reply-To: <aXMLZK9LuflkQUBPQoPtwoM-jBBdEmBM_hXeBmEKBo4=.7caee984-3afd-4798-a2ee-f0044bb17ed5@github.com>
References: <JG1dWhnHiime4ikiR6s-b6GTe7G7RpG_EI3W46Z1XL4=.66f74e8d-5dcc-4263-96c9-9d4e0e7b1822@github.com>
 <aXMLZK9LuflkQUBPQoPtwoM-jBBdEmBM_hXeBmEKBo4=.7caee984-3afd-4798-a2ee-f0044bb17ed5@github.com>
Message-ID: <PdKpQVXcnHd0biLN8ZJhej_a6OlXnJhhc2Mx-jpdA2g=.f781b5c8-3e08-4122-ba88-002f8f597d86@github.com>

On Wed, 31 Mar 2021 17:45:33 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> Found by IntelliJ IDEA inspection `Java | Java language level migration aids | Java 5 | 'StringBuffer' may be 'StringBuilder'`
>> As suggested in https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created separate PR for module `jdk.hotspot.agent`
>> Similar cleanups in the past: https://bugs.openjdk.java.net/browse/JDK-8041679 https://bugs.openjdk.java.net/browse/JDK-8264029
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8264484: Replace uses of StringBuffer with StringBuilder in jdk.hotspot.agent
>   
>   fix indentation

Looks good!
BTW have you found sponsor? I can sponsor you if you need.

-------------

Marked as reviewed by ysuenaga (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3275